Server names for query

[Casey Deccio]

On Mon, Mar 23, 2009 at 3:20 PM, Kevin Darcy <kcd at chrysler.com> wrote:
> For the *initial* NS query, I believe BIND will resolve those names down to
> a flat set of addresses, all of which have equal chance of being tried, so,
> yes, if a given NS name resolves to more addresses than other names, it is
> more likely to be tried on the initial NS query.
>
> But that's just the *initial* NS query. Once BIND, and/or virtually any
> other full-resolver implementation, builds up a history of how fast each
> nameserver responds (based on round-trip-time or RTT), it will start using
> nameservers which respond faster (although there is some "banding" that
> occurs, so that nameservers which respond more-or-less at the same speed get
> tried equally often). So if the point of your question is to try to control
> the distribution of query load to nameservers, be aware that this will be
> determined much more by the speed at which they respond, respectively, to
> clients, than to how the NS names are organized. Clients gravitate to faster
> servers. If the extra volume causes the fast servers to bog down and be
> slower, then clients gravitate away from them, and some sort of query-volume
> equilibrium is achieved between all of the nameservers which are published
> for the zone. In a sense, it is "auto-tuning" in this regard.
>

Thanks, Kevin.  My analysis is more based on collective queries (i.e.,
from clients in diverse geographical/network locations), rather than
from any particular client.  So the point of my question is
determining whether it would be expected that the *total* number of
queries from different clients for a given domain would be distributed
roughly proportional to the number of A records corresponding to each
NS target in the NS RR set for the domain.

The 'rndc dumpdb -cache' command seems pretty useful in looking at the
server stats on client server.  However, it organizes stats by name
(rather than by IP address), so it doesn't help clarify the issue in
the RFC.

Best regards,
Casey