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

Tue Feb 11 08:18:23 UTC 2014

Hi Anand,

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 
owner and 
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 
following:

 - 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 
nameserver
will answer with the old data perhaps a long time.

What do you think ?

Best regards

Christian

-- 
Christian Petrasch 
IT-Services

DENIC eG
Kaiserstraße 75-77
60329 Frankfurt am Main
GERMANY

E-Mail: petrasch at denic.de
http://www.denic.de

PGP-KeyID: 17613DFA, Fingerprint: 791A 40DF 47EF DBBD D8E3 72D0 9A6A 846E 
1761 3DFA

Angaben nach § 25a Absatz 1 GenG:       DENIC eG (Sitz: Frankfurt am Main) 
Vorstand: Sabine Dolderer, Helga Krüger, Carsten Schiefner, Dr. Jörg 
Schweiger 
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 
expiry
Gesendet von:   dns-operations-bounces at lists.dns-oarc.net

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
_______________________________________________
dns-operations mailing list
dns-operations at lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 8597 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140211/27b0d2cd/attachment.bin>