No notify-refresh: bug or feature.

Paul Vixie Paul_Vixie at
Tue Mar 18 00:04:57 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.

More information about the bind-workers mailing list