Mailing list for users of libevent ()

Catalin Patulea | 7 Jul 2012 00:06

evdns timeout behaviour

Hi,

I'm interested in what happens when a freshly created evdns with more than one nameserver encounters a timeout on the first request.

It seems evdns distinguishes between retransmits and reissues. Retransmits are triggered by timeouts and always point to the same ns, chosen at first-transmit time. Reissues, on the other hand, are triggered by bad responses from nameservers, like NOTIMPL or REFUSED, and do cause a new ns to be picked in a round-robin fashion.

The net effect is that on a fresh evdns with 2 nameservers, a single evdns_resolve is tried only against one nameserver. A second evdns_resolve is needed to talk to the second ns.

This is different from glibc (2.7), where a new nameserver appears to be chosen before each retransmit. I'm not sure whether glibc makes any distinction between retransmit and reissue.

Can anyone comment on these semantics? What was the rationale? Is there any way to get evdns to behave like glibc without significant code changes? (I don't see anything obvious in evdns_set_option.)

Catalin

headers

Nick Mathewson | 7 Jul 2012 22:42

Re: evdns timeout behaviour

On Fri, Jul 6, 2012 at 6:06 PM, Catalin Patulea <catalinp <at> google.com> wrote:
> Hi,
>
> I'm interested in what happens when a freshly created evdns with more than
> one nameserver encounters a timeout on the first request.
>
> It seems evdns distinguishes between retransmits and reissues. Retransmits
> are triggered by timeouts and always point to the same ns, chosen at
> first-transmit time. Reissues, on the other hand, are triggered by bad
> responses from nameservers, like NOTIMPL or REFUSED, and do cause a new ns
> to be picked in a round-robin fashion.
>
> The net effect is that on a fresh evdns with 2 nameservers, a single
> evdns_resolve is tried only against one nameserver. A second evdns_resolve
> is needed to talk to the second ns.
>
> This is different from glibc (2.7), where a new nameserver appears to be
> chosen before each retransmit. I'm not sure whether glibc makes any
> distinction between retransmit and reissue.
>
> Can anyone comment on these semantics? What was the rationale? Is there any
> way to get evdns to behave like glibc without significant code changes? (I
> don't see anything obvious in evdns_set_option.)

I'm not aware of any deep reason for the current behavior; if somebody
wanted to do a patch so that retransmission happened to a different
nameserver on timeout too, that would be fine with me.  (Unless
somebody knows a reason why that would be a terrible idea.)

yrs,
--

-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

headers

Adrian Chadd | 7 Jul 2012 22:54

Re: evdns timeout behaviour

.. what do other operating systems do?

Eg, what does the bind "libc" implementation of name lookups do? (ie,
what user applications can do, not what BIND itself does.)

Adrian
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

headers

Catalin Patulea | 9 Jul 2012 20:16

Re: evdns timeout behaviour

On Sat, Jul 7, 2012 at 4:54 PM, Adrian Chadd <adrian <at> creative.net.au> wrote:
> Eg, what does the bind "libc" implementation of name lookups do? (ie,
> what user applications can do, not what BIND itself does.)
Any idea what Debian package has this implementation? The only
user-accessible resolver I can find in libbind-dev is lwres. lwres
rotates for each rexmit (grouped to show bursts):

14:08:44.281278 IP 172.29.33.50.55508 > 2.3.4.5.53: 10299+% [1au] A?
www.google.ca. (42)
14:08:44.281362 IP 172.29.33.50.24086 > 2.3.4.5.53: 39714+ [1au] NS? . (28)

14:08:46.281595 IP 172.29.33.50.29057 > 1.2.3.4.53: 23708+% [1au] A?
www.google.ca. (42)
14:08:46.281645 IP 172.29.33.50.10276 > 1.2.3.4.53: 65136+ [1au] NS? . (28)

14:08:48.324396 IP 172.29.33.50.62960 > 2.3.4.5.53: 32037+% [1au] A?
www.google.ca. (42)

14:08:50.324731 IP 172.29.33.50.22628 > 1.2.3.4.53: 53006+% [1au] A?
www.google.ca. (42)
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.

headers

Catalin Patulea | 9 Jul 2012 20:29

Re: evdns timeout behaviour

On Sat, Jul 7, 2012 at 4:54 PM, Adrian Chadd <adrian <at> creative.net.au> wrote:
> .. what do other operating systems do?
BTW, glibc has a "rotate" option that load-balances across the list of
nameservers - but this option only applies when starting a new lookup
[1]. In the timeout case, a new nameserver is always tried [2].

My understanding is that multiple nameservers in glibc were originally
intended for failover only, and client-side load-balancing (the rotate
option) was added later as a feature.

[1] http://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/res_send.c;h=0a28cd784b99d45eb70150f3ac50b75b14203976;hb=HEAD#l460
[2] http://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/res_send.c;h=0a28cd784b99d45eb70150f3ac50b75b14203976;hb=HEAD#l563
***********************************************************************
To unsubscribe, send an e-mail to majordomo <at> freehaven.net with
unsubscribe libevent-users    in the body.