NSD serves RRsets with differing TTLs in them

[jpmens]

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:

1. I configure the following zone in NSD 4.3.6

zone:
    name: "example"
    zonefile: "dot.example"
    provide-xfr: 0.0.0.0/0 NOKEY

2. 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.

3. 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:

4. 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.

5. 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.

[wtoorop]

Would it not be easier to just fix the zone?

[jpmens]

Easier for whom? :-)

Seriously, I think the issue is in the fact that NSD serves the violation.