No notify-refresh: bug or feature.

Lars-Johan Liman liman at
Mon Mar 17 13:04:19 UTC 2008

[Please keep Srinivasa in the Cc:, since I don't know if he's on


Srinivasa Adapa of Neustar and I were setting up a slave relationship,
and he noted that even though they were sending out notifies, our
slaves didn't respond with the expected refresh queries.

After having looked at the behaviour under magnifying glass, it seems
as a BIND slave that receives an apropriate notify message from a
master checks the serial number in the notify, and it makes the
expected refresh to the master only if the serial in the notify
message is higher than its own current serial for the zone in

This sounds like a somewhat understandable optimization, but I do
believe that it is a deviation from the spec.

According to RFC 1996, sec 3.11, the slave is supposed to act as

   "Upon completion of a NOTIFY transaction for QTYPE=SOA,
   the slave should behave as though the zone given in the QNAME had
   reached its REFRESH interval (see [RFC1035]), i.e., it should query
   its masters for the SOA of the zone given in the NOTIFY QNAME, and
   check the answer to see if the SOA SERIAL has been incremented since
   the last time the zone was fetched.  If so, a zone transfer (either
   AXFR or IXFR) should be initiated."

There is no mentioning of using the serial in the notify message
itself, and I'm a true believer in "adhering to the spec", but since
the code is there, I'm rather sure this is "by design", so - what's
the rationale behind this? Anything more than just avoiding a few

("RTFM at http://...../" is a perfectly good answer. ;-)

# There are 10 kinds of people in the world. Those who understand
# binary numbers, and those who don't.
# Lars-Johan Liman, M.Sc.	! E-mail: liman at
# Senior Systems Specialist     ! HTTP  : //
# Autonomica AB, Stockholm 	! Voice : +46 8 - 615 85 72

More information about the bind-workers mailing list