primary&secondary

[Kevin Darcy]

Stefan Probst wrote:

> 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?)

If that's true, then they are not actually "slaves".

> 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?

The slaves normally wouldn't query other slaves, since the queries they
usually receive are "iterative". If they had nothing in their authoritative
data or cache for the zone, then they would give back a *referral* to the
closest ancestor of the zone they know about (this might be the root zone).
Other nameservers, receiving this from a supposedly-authoritative server for
the zone, would then realize that these "slaves" were lame. If the master is
down and all of the slaves are lame and don't happen to have the data cached,
then the names in the zone just don't resolve.

> 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?

See above. The referrals comes back and the originating server can therefore
tell who is lame and who isn't. Eventually, it should find the master, if it
is up, and get the answer. Better DNS implementations avoid servers known to
be "lame" for a while so that they don't cause too much query latency.


- Kevin