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 [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
