BIND 8.2.3 T1A and Notify

[Mark.Andrews at nominum.com]

> Paul,
> 
> We have tested BIND 8.2.3 T1A IXFR here on Linux and HP/UX, it looks great!!
> 
> There is a problem we found with Notify. The feature of a slave sending out a
> notify after loading a zone is back.  This at one time was removed and in 
> 8.2.3 T1A is back.
> Looking at the RFC it looks like you put it back for  RFC compliance.
> 
> I am not sure that this is a good thing. Here is an example of why:
> 
> master.zone.com hosts zone.com
> 
> The slaves for zone.com are slave1.zone.com, slave2.zone.com, 
> and  slave3.offsite.com.
> 
> Someone updates zone.com on the master, and the serial number is
> incremented. master.zone.com sends a notify to slave1, slave2, and
> slave3. This is proper behavior, and it is a "good thing".
> However, with this feature put back in, the following happens:
> slave1.zone.com gets the notify, and performs an IXFR or AXFR. When
> slave1 loads the zone, it sends a notify to slave2 and slave3.
> slave2.zone.com and slave3.offsite.com do exactly the same thing, and
> slave2 notifies slave1 and slave3 - slave3 notifies slave1 and slave2.
> Now, on each of the slaves, we have something like:
> 
> // comments inline
> 
> rcvd NOTIFY (zone.com, IN, SOA) from [master.zone.com].53
> 
> // this is the notify from the master
> IXFR Success zone.com.db.bak.ixfr.tmp
> 
> // the IXFR process starts here
> NOTIFY(SOA) from non-master server (zone zone.com), from [slave2.zone.com].53
> 
> // this is the notify from the first slave, who has now loaded
> // the zone and is notifying the other slaves. this message
> // tells us that we have had a notify come in from someone who
> // is NOT a known master for that zone.
> 
> IXFR Merge success zone.com.db.bak.ixfr.tmp
> // the IXFR from the master has completed
> 
> NOTIFY(SOA) from non-master server (zone zone.com), from
> [slave3.offsite.com].53
> // another notify from the other slave, who has also just
> // loaded the zone and is now notifying the other slave servers.
> Sent NOTIFY for "zone.com IN SOA" (zone.com); 2 NS, 2 A
> // now that our slave server has loaded the zone, it is going
> // to go back and notify the other slaves (who, incidentally,
> // just got through notifying THIS server.
> 
> As you can see, this will create confusion as to why all the extra
> NOTIFY packets are getting tossed around. Now, imagine what will
> happen with one of our customers with the following configuration - one 
> master,
> 200 slave servers.
> Each of those 200 slave servers will notify each of the other 199.
> 200 servers * 199 notifies each = 38,900 unnecessary notifies. And
> 38,900 unnecessary confusing messages in the log.

	You would only get this many packets if there were 200 NS records
	as well as 200 slaves.  A more realistic senario w/ 200 slaves
	would be that 5-10 of them would be in the NS RRset the rest would
	be stealth servers.  This would lead to 1995-3990 packets. 
> 
> Unfortunately, according to RFC 1996 (DNS NOTIFY), this is absolutely
> correct behavior. I don't know if there's anything we can do about
> this.

	The 8.2.2 code, for slaves, was just bad in that it never
	even looked at the NS RRset, even with "notify yes;" in
	the zone block.

	We could default slaves to "notify no;".  This is consistent
	w/ existing behaviour (though not w/ RFC 1996).

	e.g.
		options {
			notify [slave|master] {yes|no};
		};

	Mark

> -------------------------------------------------------------
>  From RFC 1996:
> 3.10. If a slave receives a NOTIFY request from a host that is not a
> known master for the zone containing the QNAME, it should ignore the
> request and produce an error message in its operations log.
> 
> 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.
> --------------------------------------------------
> 
> Is this an implementation problem? Or should this discussion get moved to 
> Namedroppers?
> 
> -Kevin
> 
> 
> 
--
Mark Andrews, Nominum Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com