No notify-refresh: bug or feature.
Mark_Andrews at isc.org
Tue Mar 18 01:10:56 UTC 2008
> > > > 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
> > > 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
> > 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 Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-workers