General DNSSEC

Canonical RR Form

RFC 4034, Section 6.2 describes the canonical form of resource records. Point 3 describes that for certain types, including NSEC in the DNS name embedded in the RDATA, the upper case letters have to be changed to lower case.

In a confusing way, RFC 6840, Section 5.1 requires that NSEC has to be taken out of this list and NSEC RDATA be kept as is.

Signer’s Name

RFC 4034, Section 5.3.1: The RRSIG RR’s Signer’s Name field MUST be the name of the zone that contains the RRset.

This is quite hard. How would a validator know if there is a zone cut below the signer’s name? So instead, just check if the signer’s name is a prefix of the owner name of the RRset.

Duplicate Resource Records

RFC 4034, Section 6.3 allows removing all but one of duplicate records when constructing an RRset in canonical order. However, there does not seem to be any requirement to remove those duplicates from the response as passed to the requestor. It is nice to do so, to avoid problems in downstream users of the data.

Inception Time

RFC 6781, Section 4.4.2.2, introduces an “inception offset” for signers. For validation, it is also good to apply some fuzz to account for wrong time zones, etc. Unbound uses a fraction of the total signature lifetime.

DS Record At the Root

A DS record is a parent-side record. So for the root, the query should go to the parent for the root. The algorithm described in Section 4.2 of RFC 4035 can be interprated in such a way that the parent of the root is the root zone itself. This creates an exception in validator implementations that the apex NSEC (or in theory NSEC3) record of the root zone can prove that no DS records exists for the root.

NSEC3 With Opt-Out Does Not Prove NODATA

A name with a hash value that falls in an NSEC3 range where the opt-out bit is set in the NSEC3 record can be assumed to either not-exist (because of the range) or to be an insecure delegation. But it cannot be NODATA. For it to be NODATA it cannot be a delegation, otherwise we would be looking at the apex of the child. So there has to another record type. But then there would have been an NSEC3 record.