BIND 8.2.3 T1A and Notify

Kevin J. Dunlap kevind at metaip.checkpoint.com
Fri Mar 3 15:52:16 UTC 2000


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.

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




More information about the bind-workers mailing list