[dns-operations] BIND, Knot and NSD behaviour when serial number goes backwards

[Jan Včelák]

On Mon, Feb 20, 2017 at 10:00 PM, Robert Edmonds wrote:
> It could be interpreted like this to end up with BIND's behavior:
>
>     "If the secondary finds it impossible to perform a [successful]
>     serial [equality] check for the EXPIRE interval, it must assume that
>     its copy of the zone is obsolete an discard it."

> Or it could be interpreted like this to end up with Knot's current
> behavior:
>
>     "If the secondary finds it impossible to perform a [query to the
>     primary for the SOA RR of the zone] for the EXPIRE interval, it must
>     assume that its copy of the zone is obsolete an discard it."

Thanks Robert. This is exactly where I see the conflict.

> Knot's behavior can be justified by the sentence two sentences prior,
> which describes the check as a poll, not an arithmetic comparison: "The
> check is a simple query to the primary for the SOA RR of the zone." But
> that raises the question of whether there is a difference between
> "check" and "serial check" in that paragraph.

My interpretation of "serial check" is scoped to the ability to
retrieve the SOA and thus being able to say whether the master's zone
was older, up-to-date, or newer.

On Mon, Feb 20, 2017 at 10:06 PM, Mark Andrews <marka at isc.org> wrote:
> You can only have a successful refresh if the serial match.  That
> should be obvious.  You are not up-to-date if the serial does not
> match.

Should be but it's not. :) But right, the zone is not up-to-date if
serial doesn't match.

Thanks for the responses. Whatever the RFC says, the BIND's behaviour
seems to be the most desired by the operators. To me it's a clear call
how the RFC should be interpreted.

Jan