No notify-refresh: bug or feature.

[Mark Andrews]

> > > > 	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 i
> s
> > > in BIND and so this is the right place to discuss it.
> > 
> > 	It's a bug in the specification.
> 
> before i'd call it a bug, the impact would have to be an incorrect result
> rather than an extra/wasted transaction.
> 
> > 	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
> > 	condition.
> 
> in that case you should stop including the new RR in the NOTIFY-Q, and stop
> believing it in the NOTIFY-R, and we should fix the spec to say that sending
> the new RR is not an option after all.  the bug we'd be fixing is that 1996
> says you can include the new RR in NOTIFY-Q, but fails to describe what's to
> be done by the responder when this RR is present.
> 
> > 	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
> > 	yours.
> 
> that's a decision to be made after you do the query.  NOTIFY only governs
> whether you do the query, not whether you would subsequently do anything
> else.
> 
> > 	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.
> 
> then, see above, let's just remove the "include new RR in NOTIFY-Q" logic,
> and simulate that removal in our notify responders.

	That's throwing the baby out with the bath water.

	Just allow the record to be used as a hint about whether
	refresh processing should be performed or not.  Leave it
	up to the implementation to decide what parts of the hint
	it listens to.

	A implementation MAY use the answer section to decide if
	refresh query processing needs to be initiated.

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