nsd
nsd copied to clipboard
NSD serves RRsets with differing TTLs in them
NSD serves RRsets with differing TTLs in them which, according to RFC 2181, section 5.2 is not permitted:
In no case may a server send an RRSet with TTLs not all equal.
to reproduce:
- I configure the following zone in NSD 4.3.6
zone:
name: "example"
zonefile: "dot.example"
provide-xfr: 0.0.0.0/0 NOKEY
- The zone contains an NS RRset with differing TTL on the records
example. 3600 IN SOA localhost. . 1 10800 3600 604800 3600
example. 3600 IN NS ns1.somewhere.
example. 10800 IN NS ns2.somewhere.
- I launch NSD, and it "sees" and reports the issue
$ nsd -d -V9
[2021-05-14 14:10:04.586] nsd[12861]: notice: nsd starting (NSD 4.3.6)
[2021-05-14 14:10:04.586] nsd[12861]: notice: listen on ip-address 0.0.0.0@53 (udp) with server(s): *
[2021-05-14 14:10:04.586] nsd[12861]: notice: listen on ip-address 0.0.0.0@53 (tcp) with server(s): *
[2021-05-14 14:10:04.587] nsd[12861]: info: creating unix socket /run/nsd/nsd.ctl
[2021-05-14 14:10:04.604] nsd[12862]: warning: dot.example:3: example. TTL 10800 does not match the TTL 3600 of the NS RRset
[2021-05-14 14:10:04.604] nsd[12862]: info: zone example read with success
[2021-05-14 14:10:04.615] nsd[12862]: notice: nsd started (NSD 4.3.6), pid 12861
At this point I would have expected NSD to fix the differing TTLs while reading the zone into core, but it doesn't:
- I query the zone
$ dig @192.168.1.177 example. NS +norec
;; ANSWER SECTION:
example. 10800 IN NS ns2.somewhere.
example. 3600 IN NS ns1.somewhere.
- And if I ask for the XFR, I get it with differing TTL as well
$ dig @192.168.1.177 example. AXFR +onesoa
example. 3600 IN SOA localhost. . 1 10800 3600 604800 3600
example. 3600 IN NS ns1.somewhere.
example. 10800 IN NS ns2.somewhere.
;; Query time: 0 msec
;; SERVER: 192.168.1.177#53(192.168.1.177)
;; WHEN: Fri May 14 16:20:57 CEST 2021
;; XFR size: 4 records (messages 1, bytes 160)
my expectation
I would expect NSD to "fix" the TTLs upon loading the zone, somewhat in the manner that BIND has done in the last 20 years or so. :-)
$ named-checkzone example dot.example
dot.example:3: TTL set to prior TTL (3600)
zone example/IN: loaded serial 1
OK
BIND then serves the "fixed" TTL.
Would it not be easier to just fix the zone?
Easier for whom? :-)
Seriously, I think the issue is in the fact that NSD serves the violation.