[dns-operations] BIND, Knot and NSD behaviour on zone expiry
petrasch at denic.de
Tue Feb 11 08:18:23 UTC 2014
i discussed this topic with a bunch of guys of our DNS team. And my and my
teammates humble opinion is,
that the behaviour of knot is sth. we should have a second look. There are
a few words ..
At first the zone data this server is delievering after expiring the zone
is old data and it could be possible that the domains have changed the
there is new content for the domains.. that could be critical.
As a second point, if i would link to RFC 1537, the topic about timers and
SOA includes a description about "Expire" and the content is the
- Expire: If for "expire" time the primary server cannot
be reached, all information about the zone is
invalidated on the secondary servers (i.e., they
are no longer authoritative for that zone).
So "our" server answers with an ( per definition ) invalidated zone. That
should not happen..
The third point is, that it is possible without monitoring the nameservice
well, that nobody will notice the problem with the serial and the
will answer with the old data perhaps a long time.
What do you think ?
60329 Frankfurt am Main
E-Mail: petrasch at denic.de
PGP-KeyID: 17613DFA, Fingerprint: 791A 40DF 47EF DBBD D8E3 72D0 9A6A 846E
Angaben nach § 25a Absatz 1 GenG: DENIC eG (Sitz: Frankfurt am Main)
Vorstand: Sabine Dolderer, Helga Krüger, Carsten Schiefner, Dr. Jörg
Vorsitzender des Aufsichtsrats: Thomas Keller
Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht
Frankfurt am Main
Von: Anand Buddhdev <anandb at ripe.net>
An: dns-operations at lists.dns-oarc.net,
Datum: 10.02.2014 23:53
Betreff: [dns-operations] BIND, Knot and NSD behaviour on zone
Gesendet von: dns-operations-bounces at lists.dns-oarc.net
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
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
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
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
 nsd: info: xfrd: zone Z ignoring old serial
 nsd: info: xfrd: zone Z bad transfer 0 from
 nsd: 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?
dns-operations mailing list
dns-operations at lists.dns-oarc.net
dns-jobs mailing list
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 8597 bytes
Desc: S/MIME Cryptographic Signature
More information about the dns-operations