Malformed hashes are silently loaded

[anandb-ripencc]

When NSD loads a zone from disk, and the zone has records such as DS or ZONEMD, where the hash is malformed, NSD appears to silently load the zone, including the malformed hashes, and serve them. When I query such an NSD server with BIND's dig, dig warns of a malformed packet.

;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.16.25 <<>> +norec @localhost . zonemd
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12926
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: Message has 64 extra bytes at end

;; QUESTION SECTION:
;.                              IN      ZONEMD

;; Query time: 1 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Jan 24 13:48:37 UTC 2022
;; MSG SIZE  rcvd: 92

The nsd-checkzone utility also doesn't catch this syntax error. On the other hand, BIND's named-checkzone and Knot DNS's kzonecheck both catch these errors. In the example below, both the ZONEMD record and the DS record for aaa are malformed. They are each missing a byte.

# nsd-checkzone . /var/lib/nsd/.zone
zone . is ok

# named-checkzone . /var/lib/nsd/.zone
dns_rdata_fromtext: /var/lib/nsd/.zone:26: near eol: unexpected end of input
dns_rdata_fromtext: /var/lib/nsd/.zone:33: near eol: unexpected end of input
zone ./IN: loading from master file /var/lib/nsd/.zone failed: unexpected end of input
zone ./IN: not loaded due to errors.

# kzonecheck -o . /var/lib/nsd/.zone
[.] missing RRSIG (record type ZONEMD)
[.] incorrect type bitmap in NSEC
[aaa.] invalid digest length in DS (keytag 1657)
[aaa.] unverifiable signature (record type DS)

Error summary:
   1    missing RRSIG
   1    unverifiable signature
   1    incorrect type bitmap in NSEC
   1    invalid digest length in DS

[wcawijngaards]

NSD loads the data and does not inspect the data content for validity. It just serves the content to the clients. This means a lot of records, also like, DNSKEY records that could have malformed content. And the only way to know is to cast it into its verification type object, and interpret the content type. Or records loaded with unknown type syntax could have specified some different type of byte content. The nsd-checkzone utility reports if the zone can be loaded by NSD, which is okay.

If you want more zone checks, utilities like ldns-verifyzone, or the ones you use, may be able to catch more errors in the zone.

That said, for common, or useful, errors it could be possible to add checks where needed. But NSD just by design does not want to go into the records themselves, just send them to the client. So right now, for hashes in type DS or ZONEMD, it does not know anything about them, just loads them, unaltered.