No notify-refresh: bug or feature.

Mark Andrews Mark_Andrews at
Tue Mar 18 00:40:55 UTC 2008

> since it's been several weeks since The BIND Company's last public
> demonstration that its employees don't always march jowl to jowl, marka and i
> have arranged the following demonstration.  we hope you enjoy our play.
> > 	The serial comparision is to prevent excessive refresh
> > 	queries which go nowhere.
> there is no specification of serial number meaning or arithmetic in 1996.
> if they are different then you should query.  if they are the same then
> you should not.
> > 	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.
> those sound like bugs.  using any kind of RR-specific processing to decide
> whether to follow up a NOTIFY with a query, is however not allowed, and its
> absence from 1996 is not a bug.
> > 	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?
> i never heard of multiple refresh timers per zone before now, so i don't know
> .
> >                       Do we have to retain refesh timers for all
> > 	masters now?
> not in my opinion.  1996 says "if you get one of these, then unless it
> includes a copy of the new data that's the same as what you've got now,
> you should query for the new data, and when you get it, do whatever you
> would normally do with that kind of new data."
> >                     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.
> my interpretation would be, if you query SOA after a NOTIFY SOA and you see
> (from the query, not from the NOTIFY) that the serial is later than what 
> you've got, then you should pretend that your refresh timer had gone off
> and that you queried for the SOA and it was later than what you had.  but
> i would in no way reset any timers, nor maintain any more timers than before,
> except the ones governing NOTIFY retries.
> > 	Some of these questions may be better for namedroppers than
> > 	for bind-workers.
> no doubt the bugs you mentioned should be.  but the bug liman mentioned is
> in BIND and so this is the right place to discuss it.

	It's a bug in the specification.

	If you have two masters and the second master has fallen
	behind / delayed the NOTIFY, then there is no point in doing
	a SOA refresh query when the serial in the notify <= the
	current serial.  It is just wasted effort and a expected

	There is also no point when you have one master as you won't
	perform a AXFR/IXFR from a master with a serial less than

	There are also NOTIFY implementations that don't extract
	the SOA record when sending NOTIFY messages.  They fake the
	SOA record except for the owner and serial.  Looking at
	fields other than the serial leads to excessive SOA processing.

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