No notify-refresh: bug or feature.
Paul_Vixie at isc.org
Tue Mar 18 00:50:59 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 is
> > 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
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
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.
More information about the bind-workers