[dns-operations] BIND, Knot and NSD behaviour on zone expiry

[Anand Buddhdev]

Hi folks,

Today while scanning log files, I discovered that BIND, Knot and NSD all
behave differently with zone expiry. First up, BIND. We slave a zone,
let's say Z, for which BIND had been logging:

31-Jan-2014 03:49:51.886 general: zone Z/IN/default: serial number
(2014012900) received from master x.x.x.x#53 < ours (2014100100)

The zone's operator had accidentally set its serial in the future, and
then set it back, not realising that they should have performed a serial
roll-over.

Eventually, BIND expired the zone, and then immediately transferred it:

01-Feb-2014 02:53:45.000 general: zone Z/IN/default: expired
01-Feb-2014 02:53:45.001 general: zone Z/IN/default: Transfer
started.
01-Feb-2014 02:53:45.002 xfer-in: transfer of 'Z/IN/default' from
x.x.x.x#53: connected using x.x.x.x#54317
01-Feb-2014 02:53:45.020 general: zone Z/IN/default: transferred
serial 2014012900: TSIG 'K'


On a second server, I have Knot DNS 1.4.2 configured for this same
zone. Knot transferred the zone with the future serial, and has kept
serving it, and thinks the zone is up to date:

2014-02-10T02:40:54 SOA query of 'Z.' to 'x.x.x.x at 53' key 'K': Query issued.
2014-02-10T02:40:54 SOA query of 'Z.' to 'x.x.x.x at 53' key 'K': Zone is
up-to-date. (serial 2014100100)


On a third server, I have NSD 4.0.1, also slaving this zone. It had also
picked up the future serial, and thereafter was ignoring the older
serial. Eventually, NSD expired the zone, and is now SERVFAILing for
this zone:

[1391526889] nsd[28557]: info: xfrd: zone Z ignoring old serial
from x.x.x.x
[1391526889] nsd[28557]: info: xfrd: zone Z bad transfer 0 from
x.x.x.x
[1391526896] nsd[28557]: error: xfrd: zone Z has expired


In my opinion, BIND has done the pragmatic thing here and recovered by
itself. NSD needed a helping hand with a "force_transfer Z" command
using nsd-control. With Knot, there's no way to recover gracefully. I
had to stop Knot, delete the zone file from disk, and restart it, to
make it transfer the zone again.

Regardless of the recovery method, I'm more interested in opinion about
zone expiry. All the servers were able to query the master for the SOA
record, as well as transfer from it. However, after seeing an older
serial for an extended period, both BIND and NSD expired the zone,
presumably because they couldn't synchronise the zone with the master.
Knot seems to think that it's okay to serve the zone as long as it can
query the master, even if the master's serial number is different.

Is Knot's behaviour acceptable?

Regards,
Anand Buddhdev