Legacy Resolver Compatibility for Delegation Signer (DS)
obsoleted by
- rfc-4033 — DNS Security Introduction and Requirements
- rfc-4034 — Resource Records for the DNS Security Extensions
- rfc-4035 — Protocol Modifications for the DNS Security Extensions
updated by
- rfc-3757 — Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag
- rfc-3845 — DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
updates
Extracted elements (19)
Changing all three type codes (SIG, KEY, NXT) rather than a subset was chosen because it is the cleanest and safest approach: the behavior of resolvers receiving unknown type codes is well understood, it avoids potential new incompatibilities from partial changes, and it leaves legacy resolvers completely blinded to DNSSEC rather than confusingly partially aware.
DS introduced new semantics for the NXT RR incompatible with RFC 2535: unsecure referrals now return an NXT and SIG(NXT) as proof of non-existence of a DS RR. Some widely-deployed 2535-aware resolvers interpret any answer with an NXT as a proof of non-existence of the requested record, causing unsecure delegations to be invisible and violating the principle that DNSSEC must do no harm.
The alternative of replacing the DO bit with a new 'DA' EDNS0 flag to signal DS-awareness was rejected because it requires all 2535-aware resolvers to zero out unknown EDNS0 flags; since this behavior cannot be guaranteed across all DNS implementations, it is not a universal solution.
The mnemonic DNSKEY was chosen over KEY to indicate that these keys are not for application use (per RFC 3445); RRSIG replaces SIG to indicate resource record signatures; NSEC replaces NXT to signal 'Next SECure'. Mnemonic changes were deemed necessary to avoid operational confusion alongside the type code changes.
Legacy RFC 2535-aware resolvers that interpret any answer containing an NXT record as a proof of non-existence will fail to resolve unsecure delegations when querying DS-aware authoritative servers, because DS-aware servers include NXT/SIG(NXT) in unsecure referrals. This is the core incompatibility motivating the type code changes.
A resolver MUST NOT use old-type records for DNSSEC validations or other DNS operational decision making — e.g., MUST NOT use DNSKEYs to validate SIGs or use KEYs to validate RRSIGs.
An RRSIG with a type-covered field of zero has undefined semantics; the meaning of such a resource record may only be defined by IETF Standards Action.
Assignment of new algorithms in the DNS Security Algorithm Numbers registry requires IETF Standards Action. Modification of algorithm mnemonics or applicability also requires IETF Standards Action.
Domain names embedded in RRSIG and NSEC RRs MUST NOT be compressed, consistent with RFC 3597.
If a resolver receives the old types (SIG, KEY, NXT), it SHOULD treat them as unknown RRs and SHOULD NOT assign any special meaning to them or give them any special treatment.
If SIG, KEY, or NXT RRs are included in a zone, they MUST NOT receive special treatment; for example, if a SIG is included in a signed zone, there MUST be an RRSIG for it.
Resolvers MUST NOT treat answers with NSEC RRs as negative answers merely because they contain an NSEC; positive responses such as wildcard proofs and unsecure referrals will legitimately contain NSEC RRs.
Embedded domain names in RRSIG and NSEC RRs are not downcased for purposes of DNSSEC canonical form and ordering nor for equality comparison, differing from the handling specified in RFC 2535.
RRSIG (Resource Record SIGnature) replaces SIG with type code 46; NSEC (Next SECure) replaces NXT with type code 47; DNSKEY replaces KEY with type code 48. SIG(0) and TKEY continue to use the old SIG (type 24) and KEY (type 25).
A new IANA registry is created for the DNSKEY flags field (16 bits). Initially only bit 7 (the ZONE bit) is assigned; bits 0-6 and 8-15 are available for assignment by IETF Standards Action.
The DNSKEY protocol octet field has only one defined value: 3 (DNSSEC). No other values are allowed, and no IANA registry is needed for this field.
The existing 'DNS Security Algorithm Numbers' registry is modified to add two columns indicating whether each algorithm may be used for zone signing, transaction security mechanisms (SIG(0)/TKEY), or both. Only RSA/SHA-1, DSA/SHA-1, and private algorithm types 253 and 254 may be used for zone signing.
The IANA DNS Resource Record Types registry is updated: types 46, 47, and 48 are assigned to RRSIG, NSEC, and DNSKEY respectively; types 24 (SIG) and 25 (KEY) are retained for SIG(0) and TKEY use only; type 30 (NXT) is marked Obsolete.
Changing type codes leaves code paths in legacy resolvers that are never exercised; unexercised code paths are a frequent source of security holes because they do not receive frequent scrutiny. Additionally, attempting to use both new and legacy types together is not well understood and would probably lead to unintended and dangerous results.