notify problems and issues on 8.2.4 (long)

[Paul Vixie]

> So the issues are, in no particular order:
> 
> 1) what factors govern the speed at which the notifies get sent, are
> there tunable parameters, are there any tips for optimizing servers for
> large numbers of zones so that notifies go out quickly?

RFC 1996, may its soul burn in hell, has this to say:

   4.3. If a master server seeks to avoid causing a large number of
   simultaneous outbound zone transfers, it may delay for an arbitrary
   length of time before sending a NOTIFY message to any given slave.
   It is expected that the time will be chosen at random, so that each
   slave will begin its transfer at a unique time.  The delay shall not
   in any case be longer than the SOA REFRESH time.

   Note:
      This delay should be a parameter that each primary master name
      server can specify, perhaps on a per-zone basis.  Random delays
      of between 30 and 60 seconds would seem adequate if the servers
      share a LAN and the zones are of moderate size.

> 2) are the formats of the notify log entries documented anywhere? 

No.

> 3) assuming the current number of named_xfers in progress < transfers_out
> on the primary and < transfers_in on the slave, why wouldn't a slave pick
> up an update after receiving a notify? 

The slave doesn't kick off a transfer right away.  RFC 1996 explains why:

   3.8. In no case shall the answer section of a NOTIFY request be used
   to update a slave's local data, or to indicate that a zone transfer
   needs to be undertaken, or to change the slave's zone refresh timers.

   Only a "data present; data same" condition can lead a slave to act
   differently if ANCOUNT>0 than it would if ANCOUNT=0.

and

   4.7 Slave Receives a NOTIFY Request from a Master

   When a slave server receives a NOTIFY request from one of its locally
   designated masters for the zone enclosing the given QNAME, with
   QTYPE=SOA and QR=0, it should enter the state it would if the zone's
   refresh timer had expired.  It will also send a NOTIFY response ...

What BIND does when a zone's refresh timer expires is: send an SOA query and
based on the serial number of the answer, possibly start a zone transfer.
There is a maximum number of outstanding SOA queries.  With 20,000 zones,
you are probably over quota.  In very recent (8.2.4 and later) BIND we see:

1185.	[bug]		remember if a notify came in while a zone transfer is
			in progress and perform a refresh check after the
			transfer completes.

1184.	[support]	notify delay limit now "nzones" rather than "nzones/5".

1147.	[bug]		handle notify w/ SOA records better.

Therefore I recommend rerunning the test using 8.2.5-T1A on both master and
slave.

> 4) under what circumstances do the slaves also send notifies to the other
> slaves?

Always.  From RFC 1996:

   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.

> 5) why are notifies for a zone that hasn't been modified in months
> floating around?

My guess is, from RFC 1996:

   4.1. Retaining query state information across host reboots is
   optional, but it is reasonable to simply execute an SOA NOTIFY
   transaction on each authority zone when a server first starts.