which Name sever is selected?

houguanghua houguanghua at hotmail.com
Mon Mar 3 13:24:34 UTC 2014

Hi Ben,
What's the meaning of bind "decaying"? Where can I find the detailed description? Thanks!
Date: Fri, 28 Feb 2014 11:39:54 -0500
From: Ben Croswell <ben.croswell at gmail.com>
To: bind-users at lists.isc.org
Subject: Re: which Name sever is selected?
	<CAJga8ZsUG2NRznufuXEtbPKvZqKjcZZred5U2QxW+UQw0PMzqA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
RTT banding was removed in early versions of 9.8 due to the performance hit
being larger than any security benefit.
So it would depend what version of bind is being used in this case.
It is important to note that all ns records will take some percent of the
traffic even if they are not the fastest.  This is due to bind "decaying"
the RTT on the ns records that were not used when it gets a successful
query from the fastest ns. That way if there is a failure on a box it can
eventually be tried again and make back into the top position.
On Feb 28, 2014 11:07 AM, "Barry Margolin" <barmar at alum.mit.edu> wrote:
> In article <mailman.2368.1393596895.20661.bind-users at lists.isc.org>,
>  houguanghua <houguanghua at hotmail.com> wrote:
> > If there is a list of NS records, the local name server uses the RTT
> (round
> > trip time) algorithm to find the fatest, and queries that server.
> > But I found it's not right. In the testing, the local name server doesn't
> > query the fastest authority name server. Some one tells me that if the
> local
> > name server gets the RTT to one remote server is les than 30ms, it will
> not
> > test RTT to other remote servers, even if the RTT is more less. In other
> > words, the local server will only query the first remote server with the
> > less than 30ms. Who would tell me the truth? Thanks! Guanghua
> I believe the RTT values are grouped into ranges, and it prefers servers
> that are in a better range. 30 ms might be in the lowest range, so
> another server can't be better.
> --
> Barry Margolin
> Arlington, MA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140303/c16fabd5/attachment.html>

More information about the bind-users mailing list