Clarifications and Implementation Notes for DNS Security (DNSSEC)
Extracted elements (27)
Always setting the CD bit on upstream queries is recommended because it ensures only one resolver performs validation (predictable behavior) and populates the cache with all DNSSEC data so subsequent CD=1 queries can be satisfied locally. The downside is that the resolver forgoes stricter validation or additional trust anchors at an upstream validator.
NSEC3 (RFC 5155) and SHA-2 (RFC 4509, RFC 5702) are elevated to core DNSSEC protocol documents because a number of highly visible zones use them; validators not supporting NSEC3 will be unable to validate large portions of DNS space.
The SEP (Secure Entry Point) bit in DNSKEY RRs has no effect on validation — RFC 4034 Section 2.1.2 explicitly prohibits validators from using it. Any DNSKEY in the signed DNSKEY RRset may authenticate any RRset in the zone regardless of the SEP bit.
RFC 4034 Appendix B.1 incorrectly describes the Key Tag field for algorithm 1 as using the fourth-to-last and third-to-last octets of the public key modulus; the correct octets are the third-to-last and second-to-last.
RFC 5155 Section 3.2.1 contains a contradiction: it states 'Blocks with no types present MUST NOT be included' but the accompanying regular expression uses '+' (one or more), implying at least one window block is required. The correct regular expression uses '*' (zero or more) to allow an empty type bitmap for NSEC3 records matching Empty Non-Terminals.
RFC 4034 Section 6.2 erroneously lists HINFO as requiring DNS name conversion to lowercase for canonicalization; HINFO records contain no domain names and are not subject to case conversion.
When canonicalizing DNS names, names in NSEC RDATA are NOT converted to lowercase, while names in RRSIG RDATA ARE converted to lowercase. This differs from RFC 4034 Section 6.2 (which says both should be lowercased) and RFC 3755 (which says neither should be); current practice follows neither fully.
A signed zone MUST include a DNSKEY for each algorithm present in the zone's DS RRset and expected trust anchors, and MUST be signed with each such algorithm. Validators SHOULD accept any single valid path and MUST NOT insist that all algorithms signaled in the DNSKEY RRset work.
An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used to assume the nonexistence of any subdomain of that RR's owner name. Without this check, an attacker could falsely prove nonexistence beneath a DNAME.
Ancestor delegation NSEC or NSEC3 RRs (NS bit set, SOA bit clear, signer field shorter than owner name) MUST NOT be used to assume nonexistence of any RRs below the zone cut, including all RRs at that owner name other than DS RRs.
DS records using unknown or unsupported message digest algorithms MUST be treated the same as DS records referring to DNSKEY RRs of unknown or unsupported public key algorithms — they are disregarded, and if none remain, the zone is treated as unsigned.
Security-aware resolvers SHOULD implement a BAD cache as described in RFC 4035. This guidance upgrades the previous permissive 'may implement' to a SHOULD, based on operational experience showing DNSSEC administrative errors cause significant DNS traffic increases.
The DNSSEC OK (DO) bit of a query MUST be copied into the response per RFC 3225, but resolvers MUST ignore the DO bit in responses they receive, to interoperate with implementations that fail to copy it.
Validating resolvers MUST disregard RRSIGs that do not have a corresponding DNSKEY in the zone, and MUST disregard RRSIGs with algorithm types not present in the DNSKEY RRset. Such signatures may legitimately appear during key or algorithm rollovers.
Validating resolvers SHOULD only set the AD bit in a response when the response meets the conditions of RFC 4035 Section 3.2.3 AND the request contained either a set DO bit or a set AD bit, to avoid confusing legacy stub resolvers and middleboxes.
Validating resolvers SHOULD set the CD bit on every upstream query regardless of whether the incoming query had CD set or whether a trust anchor covers the QNAME. This ensures predictable single-validator behavior and full DNSSEC data availability in cache.
Validators supporting algorithm identifiers DSA-NSEC3-SHA1, RSASHA1-NSEC3-SHA1, RSASHA256, or RSASHA512 MUST support both NSEC3 and NSEC responses, as these algorithm identifiers signal only that a zone might use NSEC3 rather than NSEC.
When multiple RRSIGs cover a given RRset, a resolver SHOULD accept any single valid RRSIG as sufficient and only determine an RRset is Bogus if all RRSIGs fail validation. More restrictive policies risk cache timing failures and incompatibility with ZSK rollover techniques.
When multiple trust anchors apply to a response, the recommended default policy ('Accept Any Success') is to try all applicable trust anchors; the result is Secure if any yields Secure, Insecure only if all yield Insecure, and Bogus if one or more yield Bogus with no Secure result.
When private algorithm DS records are present and might be supported, the resolver MUST retrieve the corresponding DNSKEY for each and MUST verify the hash of the DNSKEY RR's owner name and RDATA matches the DS digest before using it to determine zone security status.
When proving a delegation is insecure, a validator MUST check for the presence of the NS bit in the matching NSEC or NSEC3 RR, or verify the delegation is covered by an NSEC3 RR with the Opt-Out flag set, in addition to checking absence of DS and SOA bits.
When validating a NOERROR/NODATA response, validators MUST check the CNAME bit in the matching NSEC or NSEC3 RR's type bitmap in addition to the bit for the query type. Without this, an attacker can strip a CNAME RRset to forge a NODATA response.
When validating a response to QTYPE=*, all received RRsets matching QNAME and QCLASS MUST be validated; if any fail, the answer is Bogus. If there are no matching RRsets, that fact MUST be validated per RFC 4035 Section 5.4 nonexistence rules.
Setting the AD bit in a DNS query is defined as a signal that the requester understands and is interested in the AD bit value in the response. This allows requesting AD-bit semantics without also requesting DNSSEC data via the DO bit.
Always setting the CD bit on upstream queries (Section 5.9) means a resolver will not benefit from more stringent validation rules or a more complete set of trust anchors at an upstream validator, which is a security tradeoff for predictability.
Failure to address the interoperability concerns in Section 5, particularly around algorithm handling, could limit the ability to change or expand DNSSEC in the future, including the addition of new algorithms.
The validation algorithm clarifications in Section 4 (ancestor NSEC, ANY queries, CNAME check, insecure delegation proofs) are critical for preserving DNSSEC security properties; failing to implement them could allow attackers to spoof nonexistence or forge delegation status.