DNS Security Extension Clarification on Zone Status
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-3658 — Delegation Signer (DS) Resource Record (RR)
updates
- rfc-2535 — Domain Name System Security Extensions
Extracted elements (23)
RFC 2535 defined zone security on a per-algorithm basis (e.g., secured with RSA but not DSA). RFC 3090 changes this so a zone is either secured or unsecured regardless of which key algorithms are used, simplifying zone status determination.
The closest security root is used rather than starting from the highest known secure root in order to avoid encountering a NULL key in an intermediate unsecured zone that would incorrectly cause a resolver to conclude that a more-specific secured subzone is unsecured.
The 'experimentally secure' zone status defined in RFC 2535 is deprecated. Its purpose—facilitating migration from unsecured to secured—can be achieved via locally secured zones by publishing signatures and pre-configuring test resolvers, without needing a separate designation.
The labels 'global' and 'local' for zone security status are chosen to assist zone administrators in understanding what actions to take, not to convey compliance with DNS security standards. Resolvers ultimately see only a binary secured/unsecured distinction.
In RFC 2535, a secured parent signals that a child is secured by silence—the absence of a KEY RR declaring the child unsecured. While counter-intuitive operationally, this mechanism is retained as it functions correctly and no sufficient need for a change has been demonstrated.
Overlapping islands of security are possible as islands grow, and are expected to result from configuration problems. Implementers are advised to ensure their code handles overlaps without failure, even though overlaps introduce no new conceptual or protocol complexity.
Resolvers following the most restrictive DNSSEC verification rules will see only globally secured zones as secured; locally secured zones appear unsecured to them. Resolvers implementing additional algorithms beyond the mandatory set may see some locally secured zones as secured.
The root zone is a special case for global security: it is considered globally secured if it conforms to locally secured rules AND meets the mandatory-to-implement algorithm requirement (rule 2.1.a), since it has no parent zone to provide a conforming signature.
A globally secured zone's apex KEY RR set MUST be signed by a private key belonging to the parent zone, whose public companion MUST be a zone signing KEY RR of a mandatory-to-implement algorithm owned by the parent's apex. If a conforming parent signature cannot be obtained, the child zone cannot be considered globally secured.
A globally secured zone's apex MUST have a KEY RR set containing at least one zone signing KEY RR of a mandatory-to-implement algorithm.
A locally secured zone's apex KEY RR set MUST be signed by a private key, and either the public companion MUST be pre-configured in all resolvers of interest, or the public companion MUST be a zone signing KEY RR authorized to provide validation as recognized by those resolvers (allowing trusted third-party validation).
A locally secured zone's apex MUST have a KEY RR set containing at least one zone signing KEY RR.
Each RR set qualifying for zone membership in a locally secured zone MUST be signed by a key that is in the apex's KEY RR set and is a zone signing KEY RR. This updates RFC 2535 section 2.3.1.
NXT records MUST be deployed throughout a globally secured zone, clarifying RFC 2535 section 2.3.2. This requirement is open to modification if an alternate mechanism to NXT is defined along with a means for a zone to indicate its use.
NXT records MUST be deployed throughout a locally secured zone.
A globally secured zone uses only mandatory-to-implement algorithms (per RFC 2535 section 3.2) and on-tree validation, relying on a key certification chain that parallels the delegation tree up to the root.
A locally secured zone complies with globally secured rules except that signing keys may use non-mandatory algorithms and/or verification may rely on off-tree validation. Only resolvers pre-configured for the zone will see it as secured.
A 'zone signing KEY RR' is a KEY RR whose flag field indicates name type 01 (zone key) and key type 00 or 01 (permitted to authenticate data), with a protocol octet value of DNSSEC (3) or ALL (255). The protocol octet requirement is a new addition updating RFC 2535 section 3.1.3.
An 'island of security' is a contiguous collection of secured zones at or below a zone whose public key is pre-configured in resolvers. It is bounded at the bottom by delegations to unsecured zones. Resolvers not pre-configured for the island's root key will see it as unsecured.
Off-tree Validation is any authorization model permitting domain names other than the parent to provide a signature over a child's zone keys enabling a resolver to trust those keys.
On-tree Validation is the authorization model where only the parent zone may supply a DNSSEC-meaningful signature to build a chain of trust from child keys to a recognized root, following the DNS delegation hierarchy upward.
The 'closest security root' for a given domain is the top of the island of security whose name shares the most matching right-most labels with the domain. This is used to begin chain-of-trust validation and to avoid false insecurity conclusions due to NULL keys in intermediate zones.
Declaring a DNS zone 'completely secured' is impossible without enforcement mechanisms. A misbehaving resolver can be duped by bad data even if all zones are properly configured. A non-compliant or subverted parent can interrupt operations. The realistic goal is that all parties are prepared to be judged secure and that incidents can be traced quickly.