No notify-refresh: bug or feature.
Paul_Vixie at isc.org
Mon Mar 17 13:19:03 UTC 2008
> ("RTFM at http://...../" is a perfectly good answer. ;-)
3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0,
ADCOUNT>=0. If ANCOUNT>0, then the answer section represents an
unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>. A
slave receiving such a hint is free to treat equivilence of this
answer section with its local data as a "no further work needs to be
done" indication. If ANCOUNT=0, or ANCOUNT>0 and the answer section
differs from the slave's local data, then the slave should query its
known masters to retrieve the new data.
so the spec seems to support bind9's actions in this regard, as long as
you overstated the problem:
> 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 question.
if it really is doing a "higher than" check then it's wrong. the spec
says "equivilence" and means every word of that. there is no support in
RFC 1996 for doing serial number comparisons. notify responders ought to
be doing a bit-for-bit comparison with the received answer against the
stored answer's wire format, allowing for compression of course.
More information about the bind-workers