Question about recursion queries

[Kevin Darcy]

On 7/19/2010 5:12 AM, Zhang Meng wrote:
>
> The question is given that
>
> When I ask the bind server, what's the A record of google.com 
> <http://google.com>?
>
> for the ROOT name server, there're several NS record
>
> /.// //60493// //IN// //NS// //g.root-servers.net 
> <http://g.root-servers.net>./
> /.// //60493// //IN// //NS// //b.root-servers.net 
> <http://b.root-servers.net>./
> /.// //60493// //IN// //NS// //m.root-servers.net 
> <http://m.root-servers.net>./
> /.// //60493// //IN// //NS// //d.root-servers.net 
> <http://d.root-servers.net>./
> /.// //60493// //IN// //NS// //j.root-servers.net 
> <http://j.root-servers.net>./
> /.// //60493// //IN// //NS// //c.root-servers.net 
> <http://c.root-servers.net>./
> /.// //60493// //IN// //NS// //i.root-servers.net 
> <http://i.root-servers.net>./
> /.// //60493// //IN// //NS// //a.root-servers.net 
> <http://a.root-servers.net>./
> /.// //60493// //IN// //NS// //h.root-servers.net 
> <http://h.root-servers.net>./
> /.// //60493// //IN// //NS// //k.root-servers.net 
> <http://k.root-servers.net>./
> /.// //60493// //IN// //NS// //l.root-servers.net 
> <http://l.root-servers.net>./
> /.// //60493// //IN// //NS// //f.root-servers.net 
> <http://f.root-servers.net>./
> /.// //60493// //IN// //NS// //e.root-servers.net 
> <http://e.root-servers.net>./
>
> How does the bind handle these multiple NS records?
>
> A).Select one of them to ask the NS records for com. ?

Yes, one of them will be selected either because it has a recorded 
history (based on RTT = Round Trip Time) of responding faster than 
others, or at random, if there is no history, or insufficient history, 
because named just started up, or some combination of the two factors, 
because the RTT calculations are grouped together in "bands" and 
additionally there is some random "jitter" applied so that named can 
adapt to changing network conditions.

> If fails, try the second one?

If that query fails, that particular target nameserver will be penalized 
so that it is less likely to be used for a while, and some other 
nameserver will be selected, using the same criteria, i.e. by recorded 
RTT, with perhaps random variation due to "banding" and/or jitter.

Note that if you're ultimately trying to resolve "google.com" your 
queries would generally be only for "google.com" and not ancestors of 
that name, such as "com". The only exceptions would be if 
(hypothetically) google.com were an alias to something else, in which 
case the lookup would be "restarted" with that other name, if "glue 
records" need to be resolved while following down the delegation chain, 
or if you're doing DNSSEC validation and need to fetch keys/signatures.

> B).Or send several queries concurrently, and get the first one responsed?
No, that would be very wasteful of Internet DNS infrastructure resources.

The failover from one nameserver target to another is quite fast 
(measured typically in milliseconds), but the queries are not sent 
*simultaneously*. This quick-failover strategy provides a good balance 
between query efficiency and resiliency.
>
>
> Could you show me the related code in Bind9.7.1-P2?
>
The code to do _what_, specifically? I suspect the resolution process is 
a little more complex than you originally thought, and the code doesn't 
exactly help to clarify things either, since it includes a lot of 
"housekeeping" junk, e.g. memory management, quotas, task control, 
locking, key-generation/validation, socket management, etc. If you're 
interested in specifically the routine that sorts the candidate 
nameservers according to their RTT values (with some random "jitter" 
applied), take a look at sort_finds() and/or sort_adbfind() in 
lib/dns/resolver.c. But all you'll really see there is (according to the 
comments) "Lame N^2 bubble sort"s. The real "magic" is in how named 
records those RTTs on every query it generates (see dns_adb_adjustsrtt() 
in lib/dns/adb.c for some of the specifics), and this is something that 
is defined in the protocol specification, not just some nifty piece of 
code that's part of BIND. You might be better served by reading some 
more high-level, abstract explanations of how DNS resolution works, 
instead of, or at least in preparation for staring at disparate chunks 
of BIND code.

                                                                         
                                                                         
                                                                         
                         - Kevin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20100720/247d40cb/attachment.html>