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: petra...@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 <ana...@ripe.net>
An: dns-operations@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-boun...@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@53' key 'K': Query
issued.
2014-02-10T02:40:54 SOA query of 'Z.' to 'x.x.x.x@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@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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dns-operations mailing list dns-operations@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
