Re: [cobalt-users] RAQ3 as primary AND secondary DNS ??

[Brent Sims <brent@xxxxxxxxxxx>]

On Sat, 27 May 2000, Gerald Waugh so wrote:

} I definitely could be wrong about this, if so please provide some
} illumination. Also, I don't understand how this can lighten the
} load on the nameservers, other than the fact that the look-up, may
} be, in the users cache. And, the onus is on the user, not the
} nameservers or the Web Server.

Hi Gerald,

	Sometimes we miss the basic simplicity of things. A primary
name server does not have to be down in order for a querying name
server to decide to use one of the secondary name servers which is
authoritative for that zone.

	A namer server looking up a doman name first obtains the
list of NS (Name Server) records for the domain name it is trying to
find. As part of the process the querying name server calculates and
stores the RTT - Round Trip Time - for each authoritative name server
for a zone. When faced with multiple authoritative Name Servers the
one with the lowest RTT is automatically selected. The RTT is
recalculated on each successive query thereby making the system
somewhat (it's not perfect) self managing.

	Thus if more than one name server is authoritative for a zone
the name servers querying that zone will automatically seek out the
fastest responding authoritative name server for that zone - the 
one with the lowest RTT. This just happens as a matter of
course. The functionality is built into Bind.

	It makes no difference if the name server being queried is
listed as primary or secondary - if the name server is authoritative
for the zone and there is more than one name server which is
authoritative for the zone then all the name servers which are
authoritative for the zone will be queried each and every time that
zone is queried by a remote name server and, while the previous
queries do enter into the equation, the authoritative name server with
the lowest RTT will be selected to answer the query.

	All I'm suggesting is that one simply take advantage of how
Bind does it's thing.

	So then, lets put this to work here in the real world.

	More name servers translates into more opportunities for
querying name servers to locate the name server with the lowest RTT
time. As the name servers are loaded their RTT times will change as
a result of the load they shoulder individually. All other factors
being equal, spreading that load over more name servers translates
into a lower RTT time for all the name servers - the more that load
is shared, the lower the over all RTT time. That translates into
faster response time, less load on name server as some of it's load
will be assumed by the other name servers and that translates into
better performance and a much more reliable network. 

	While I am aware that there is much more to this than I'm
going to say here, please humor me for the sake of this explanation.

	Let's assume that I have three name servers. one is
located on the East Coast, another is in middle America and the
other is on the West Coast. Things are humming right along, and have
been for some time, and then suddenly the name server I have in
middle America takes a nose dive.

	All of the people who visit my sites whose connectivity
is supplied by ISP's whose name servers have found that the name 
servers name servers I have on the East Coast and the West Coast RTT
is the lower than that of the name server I had in middle America 
won't even be effected by the loss of the name server I had in
middle America. Over time, the people who are effected queries will
cause their ISP's name servers to make the necessary adjustments and
then eventually everyone will be using the remaining two name
servers.

	All other factors being equal, if I add more name servers
then less viewers will be effected by the loss of any one of those
name servers.

	Yes, it is indeed much more complex than this. But it is
also simple and effective enough to at least warrant a bit of
consideration and perhaps even be worth considering as a viable way 
of easily increasing the overall performance and reliability of the 
web site(s) one hosts.

	Peace be with you,
	
	Brent
	
	Brent Sims
	WebOkay Internet Services
	http://www.WebOkay.net
	Brent@xxxxxxxxxxx
	(719) 595-1427 (Voice/Fax)