[dns-operations] Client retry behavour?
Paul Vixie
paul at vix.com
Wed May 9 16:07:52 UTC 2007
> The timeout parameter can be tweaked (at least on resolvers based
> on bind 8.x and later). I usually put the following in resolv.conf
> on the UNIX machines:
>
> options timeout:1
>
> I think modern windows resolvers fail over in 1 second also.
i've been thinking for about a decade that we need a blast protocol for the
stub resolver. state one: use all servers in parallel, switch to state two
when you get an answer. state two: use the fastest server learned in state
one, switch to state three if it ever fails to answer. state three: ask a
nonrecursive question guaranteed to be answerable from cache, if it times
out go to state one, else go to state two.
it's dimly possible that this should also be used when making nonrecursive
upstream queries from full resolvers to authority servers, but that seems
dangerous since it's more likely to be a wide-area-network activity. but i
would welcome some sponsorship interest (that is, funding) in this idea, as
an experimental feature in the BIND stub resolvers.
> > This certainly makes a case for having a very reliable name server, by
> > using clustering or anycasting. (Or to install a full resolver on any
> > Unix machine.)
>
> One option for making a more reliable primary resolver, is to deploy
> multiple servers using the same anycast address.
most folks who care about this put a full resolver ("recursive nameserver")
on 127.0.0.1 and wrap it in a restart script and let it handle their
upstream parallelism for them. BIND9's "lwresd" was designed with this
exact thing in mind.
More information about the dns-operations
mailing list