slave to slave zone transfers HOWTO?

[Cricket Liu]

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
by default.

> 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!  ;-)

It's "gedankenexperiment."

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

cricket

Men & Mice
DNS Software, Training and Consulting
www.menandmice.com

The DNS and BIND Cookbook, available now!
http://www.oreilly.com/catalog/dnsbindckbk/