No notify-refresh: bug or feature.

Lars-Johan Liman liman at
Mon Mar 17 14:03:02 UTC 2008

paul at
>> ("RTFM at http://...../" is a perfectly good answer. ;-)

>    3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0,
>    ADCOUNT>=0.  If ANCOUNT>0, then the answer section represents an
>    unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>.  A
>    slave receiving such a hint is free to treat equivilence of this
>    answer section with its local data as a "no further work needs to be
>    done" indication.  If ANCOUNT=0, or ANCOUNT>0 and the answer section
>    differs from the slave's local data, then the slave should query its
>    known masters to retrieve the new data.

> so the spec seems to support bind9's actions in this regard, as long as
> you overstated the problem:

Well, OK, hmm. I understand what you mean, and I do agree that it
supports BIND's behaviour when the serial numbers are equal, but I
do find those sections to a minor degree contradictory. Not disturbing
enough to do anything about, though. ;-)

Thanks for the pointer, though.

>> it makes the expected refresh to the master only if the serial in the notify
>> message is higher than its own current serial for the zone in question.

> if it really is doing a "higher than" check then it's wrong.

That's what it does, AFAICT. First I forced notifies using the same
serial as the slave. No refresh from the slave. Then I tried to lower
the serial on the master, and the slave still did not do a refresh after
having received the notify. If I increased the serial number above
that of the slave, it all worked just fine (which is, of course, the
99.99999 % case).

> the spec says "equivilence" and means every word of that.
> there is no support in RFC 1996 for doing serial number comparisons.
> notify responders ought to be doing a bit-for-bit comparison with
> the received answer against the stored answer's wire format,
> allowing for compression of course.

This thing is just a minor curiosity to me. I just wondered whether
there was a logical reason for doing the serial comparison (e.g., to
avoid some strange corner case which would generate notify storms) but
that seem not to be the case. I think I understand the situation now.
(Famous last words(TM) ... ;-)


More information about the bind-workers mailing list