slave to slave zone transfers HOWTO?
cricket at menandmice.com
Fri Oct 11 20:46:20 UTC 2002
Joseph S D Yao wrote:
> On Fri, Oct 11, 2002 at 01:20:58PM -0600, Cricket Liu wrote:
>> Slaves send NOTIFYs to all authoritative name servers except the one
>> in the MNAME field by default. To really tune your NOTIFY setup,
>> you could set the "superslave" to use "notify explicit" and send
>> NOTIFY messages only to the "subslave." Then you'd set "notify no"
>> on all slaves that weren't themselves masters.
> This suprises me.
It surprised me, too, the first time I read through the RFC. But that's
the way it works. Actually, older BIND 8 name servers didn't follow
the RFC. I believe 8.2.3 was the first in which slaves sent NOTIFYs
> Let's say you have three peer servers, A, B, and C. Internally, A has
> the "master" role, and appears in the MNAME field of the SOA.
> Cricket changes the zone on A. A sends out NOTIFYs to B and C. B and
> C respond by checking serial numbers and then requesting a zone
> transfer from A.
> So now, per what you have said, B and C each send NOTIFYs to each
> other. What do they do? Check serial numbers with A a second time?
No, they'd ignore the NOTIFYs, since they don't come from the address
of their master name server(s) for the zone.
> Say, instead of 3 servers, you have 30. Yeah, yeah, don't quibble,
> this is a Gnedenken experiment. The 29 non-masters all send each
Man alive, Joe, now you're mangling German, too! ;-)
> other NOTIFYs. So each non-master receives 28 NOTIFYs after already
> updating their zone files.
> Can this really be correct?
It can be, and it is. The issue is that the name servers don't know what
the zone transfer dependency graph looks like, and you have this safeguard
that says that slaves only accept NOTIFYs from their masters. If you're
going to be sure that every slave receives a NOTIFY from its master, then
every slave needs to send NOTIFYs to every other slave, just in case.
Here's RFC 1996, section 4.2:
4.2. Each slave is likely to receive several copies of the same
NOTIFY request: One from the primary master, and one from each other
slave as that slave transfers the new zone and notifies its potential
peers. The NOTIFY protocol supports this multiplicity by requiring
that NOTIFY be sent by a slave/master only AFTER it has updated the
SOA RR or has determined that no update is necessary, which in
practice means after a successful zone transfer. Thus, barring
delivery reordering, the last NOTIFY any slave receives will be the
one indicating the latest change. Since a slave always requests SOAs
and AXFR/IXFRs only from its known masters, it will have an
opportunity to retry its QUERY for the SOA after each of its masters
have completed each zone update.
Men & Mice
DNS Software, Training and Consulting
The DNS and BIND Cookbook, available now!
More information about the bind-users