primary&secondary

Stefan Probst stefan.probst at opticom.v-nam.net
Sat Jul 15 04:05:28 UTC 2000


Sorry for Newbie question...

Supposed I have a Master_1 which specifies Slave_1 and Slave_2 to be
authoritative for the own zone. Now, for whatever reason, both slaves
don't do zone transfers from the master, i.e. they are "lame" (is that the
correct terminology?)

I know, it is weird, but that's the real "grown" situation of one of my
clients - which shall remain nameless.

If a resolver somewhere in the Net asks the next DNS server, this DNS
server might ask e.g. Slave_1, correct? Slave_1 would work only as caching
DNS server (?), get the real answer from the Master_1 and cache it for
possible future requests (?).

Now what happens, if the Master_1 goes belly-up and the info in the cache
of Slave_1 has expired? Slave_1 would probably query Slave_2. Would it be
satisfied with an answer out of Slave2's cache?

Same Scenario/Client, but other situation:
We have not only 2, but 4 "lame" Slaves, i.e. 1 authoritative Master, and
4 supposed-to-be authoritative Slaves, but in fact they aren't. If one of
the slave receives a query, which is not in its chache, it will ask any of
the 4 other hosts, corect?. Are there any provisions, that this query
doesn't end up in a (nearly) endless loop, i.e. one lame one asking
another lame one, ... until by chance the Master is queried?

We are trying to debug eMail failures and suspect the DNS system as one of
the main culprits. Some anwers would therefore be greatly appreciated!

Cheers,
Stefan


At 18:21 14.07.00 +0100, 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
> looking at them if the listed servers are master or slave. As for the
> timeout problem, you just make sure that the three name servers that
> are entered in resolv.conf are always up. Resolver clients just fire a
> query at the first server in that list - it doesn't necessarily have
> to be master or slave for anything - and leave it to get the answer.
> That server will traverse the name space, ignoring any dead servers
> along the way and eventually return an answer to the resolver tht made
> the initial query. That resolver has no way of telling how the name
> server got that answer.
> 



More information about the bind-users mailing list