primary&secondary

Kevin Darcy kcd at daimlerchrysler.com
Fri Jul 14 21:56:06 UTC 2000


Mark E. Drummond wrote:

> Jim Reid wrote:
> >
> > There is no distinction between "primary" and "secondary" - the
> > current terminology is master and slave - when it comes to
> > resolving. A name server just follows the NS records. It can't tell by
>
> That's why I said primary & secondary, and not master/slave. My bad for
> lack of explanation. I meant primary/secondary/tertiary WRT the
> resolv.conf.

"Primary" and "secondary" were used by BIND (previous to BIND 8) to denote
"master" and "slave", so your nomenclature understandably caused confusion.
Just something to keep in mind for future communication...

> And my point still stands. If your "primary" (first IP in your
> resolv.conf or equivalent) is down, the resolver will wait for ~60 secs
> before "failing over" to the "secondary". The next time the resolver
> wants to do a query, it does _not_ stick with the known functioning
> secondary, rather it goes back to the primary again as per the
> resolv.conf, ergo another ~60sec timeout. This is unlike NIS/NIS+/LDAP
> where the clients fail over "permanently". (da boss tells me that maybe
> Windows - eek - does handle this better but that begs confirmation).

Sixty seconds? That's bogus. Resolver failover on Solaris is more on the
order of 5 seconds.

> The end result is that, unless you go in a change, by hand, your
> resolv.conf, all you DNS queries will be slowed until the "primary"
> comes back online.

This is why I run caching-only nameservers everywhere I can, even on
"client"-type machines. It makes name resolution *far* more robust.

By the way, the newer resolver libraries allow you to specify "rotate" in
the resolver configuration, which causes queries to be spread amongst the
configured nameservers -- no more "primary" and "secondary", eh? -- and
this should in theory make name resolution more robust. But I still think
caching-only nameservers is a superior solution.


- Kevin




More information about the bind-users mailing list