No notify-refresh: bug or feature.

Mark Andrews Mark_Andrews at
Mon Mar 17 23:39:59 UTC 2008

> paul at
> >> ("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:
> Well, OK, hmm. I understand what you mean, and I do agree that it
> supports BIND's behaviour when the serial numbers are equal, but I
> do find those sections to a minor degree contradictory. Not disturbing
> enough to do anything about, though. ;-)
> Thanks for the pointer, though.
> >> it makes the expected refresh to the master only if the serial in the noti
> fy
> >> 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.
> That's what it does, AFAICT. First I forced notifies using the same
> serial as the slave. No refresh from the slave. Then I tried to lower
> the serial on the master, and the slave still did not do a refresh after
> having received the notify. If I increased the serial number above
> that of the slave, it all worked just fine (which is, of course, the
> 99.99999 % case).
> > 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.
> This thing is just a minor curiosity to me. I just wondered whether
> there was a logical reason for doing the serial comparison (e.g., to
> avoid some strange corner case which would generate notify storms) but
> that seem not to be the case. I think I understand the situation now.
> (Famous last words(TM) ... ;-)

	The serial comparision is to prevent excessive refresh
	queries which go nowhere.

	There are other bugs with RFC 1996 like completely ignoring
	NOTIFY messages from non-masters.  This leads to lots of
	excess NOTIFY traffic between slaves.  Returning REFUSED
	allows the other slave to stop sending.  Similarly returning
	NOTAUTH for non-zones stops excess NOTIFY traffic.

	Also there is abolutely no guidance of how to integrate
	this change into the standard refresh processing.  Does it
	reset the refresh timer for *all* masters or just for a
	single master?  Do we have to retain refesh timers for all
	masters now?  If you have a single master these questions
	are moot, but there are important for multi-master senarios
	where a NOTIFY stream from one master could prevent you
	from seeing changes that are on a different master.

      Because a deep server dependency graph may have multiple paths
      from the primary master to any given slave, it is possible that
      a slave will receive a NOTIFY from one of its known masters even
      though the rest of its known masters have not yet updated their
      copies of the zone.  Therefore, when issuing a QUERY for the
      zone's SOA, the query should be directed at the known master who
      was the source of the NOTIFY event, and not at any of the other
      known masters.  This represents a departure from [RFC1035],
      which specifies that upon expiry of the SOA REFRESH interval,
      all known masters should be queried in turn.

	Some of these questions may be better for namedroppers than
	for bind-workers.

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at

More information about the bind-workers mailing list