bind resolver, a/aaaa queries and searchlist behavior

[Kevin Darcy]

Jan Gyselinck wrote:

>Hi,
>
>I was debugging some connection lag and I encountered some query
>behavior which seems unnecessairy in my eyes.  The system in 
>question is running one of the FreeBSD 6.1 prereleases, but since
>it uses the bind resolver code I guess this behavoir is not
>FreeBSD specific.
>
>The queries I see are these:
>
>22:15:29.657232 IP 172.16.21.2.57672 > 172.16.1.22.53:  54355+ A? images.slashdot.org. (37)
>22:15:29.658189 IP 172.16.21.2.64080 > 172.16.1.22.53:  46066+ AAAA? images.slashdot.org. (37)
>22:15:29.659407 IP 172.16.1.22.53 > 172.16.21.2.57672:  54355 1/13/1 A 66.35.250.55 (280)
>22:15:29.659674 IP 172.16.1.22.53 > 172.16.21.2.64080:  46066 0/1/0 (96)
>22:15:29.660514 IP 172.16.21.2.55636 > 172.16.1.22.53:  46067+ AAAA? images.slashdot.org.b0rken.net. (48)
>22:15:29.661438 IP 172.16.1.22.53 > 172.16.21.2.55636:  46067 NXDomain* 0/1/0 (99)
>22:15:29.661847 IP 172.16.21.2.58524 > 172.16.1.22.53:  46068+ AAAA? images.slashdot.org.bureau.b0rken.net. (55)
>22:15:29.662720 IP 172.16.1.22.53 > 172.16.21.2.58524:  46068 NXDomain* 0/1/0 (106)
>
>So it sends out A and AAAA queries, so far so good.  It gets an answer
>for the A record query, however the AAAA query retuns an empty answer.  
>What I find strange though, is the fact it's now applying the searchlist
>to get an answer on the AAAA query.  Other than the fact this could
>potentially give unpredictable results in specific situations, I find
>this rather illogical.  Since one of the queries (A or AAAA) succeeded
>we _know_ the host in question exists (and the searchlist is there to
>make non-fqdn queries work for 'local' hosts, by applying the searchlist
>if the host does not seem to exist).  So, in short, isn't this a bug?
>
I'm not sure what you find "buggy" here. That the searchlist is being 
used even for an FQDN lookup? That's common behavior in many resolver 
implementations. Note that if the resolver implementation is BIND-based 
and relatively modern, this searchlisting behavior is somewhat 
controllable by the invoking user/process via the RES_DEFNAMES and 
RES_DNSEARCH resolver flags.

Or, do you find it buggy that the AAAA lookup considered the first 
response it got (with 0 answers) to be a "failure" at all, thus 
triggering the searchlist logic? That's also a very common 
implementation detail; since there are 0 answers to the query, it's not 
a *usable*, acceptable result, even if in a pure sense the "name" that 
was looked up has been confirmed to exist.

Lastly, do you think it's a "bug" that, once the images.slashdot.org/A 
lookup got a proper, usable result, the images.slashdot.org/AAAA lookup 
still chugged along through its searchlist? I don't know (because you 
didn't say) whether these were two separate and independent lookups 
coincidentally running on the same box at the same time, or whether 
these were two separate "threads" spawned from some "generic" A-or-AAAA 
lookup, but even if they were closely related to each other, I don't 
know that the presumption can be made that the "master" lookup mechanism 
would automatically give precedence to an "exact" result, i.e. where the 
name in the lookup result is identical to the name in the lookup itself, 
e.g. "images.slashdot.org", over an "inexact" result, i.e. where the 
name in the lookup result was the result of appending the default domain 
or a searchlist element, e.g. "images.slashdot.org.b0rken.net". Without 
that presumption, I can't see how it would be appropriate to disable 
searchlist matching for the AAAA lookup once the exact result was 
obtained for the A lookup, and, from an implementation standpoint, if 
these lookups are being made in parallel, for performance reasons, it 
could be non-trivial to cancel the searchlist part of a lookup that's 
already in progress. Even if the presumption is true, given the 
technical complexity/difficulty, at most I would consider this proposed 
change to be an *optimization* of the current behavior, rather than 
calling its absence a "bug". That's a bit of a fine line, I know...

- Kevin