]> Incrementally Deployable DNSSEC Delegation NLnet Labs
philip@nlnetlabs.nl
NLnet Labs
willem@nlnetlabs.nl
int DNS Delegation Internet-Draft DNS Resolver Delegation Authoritative Deployable Extensible This document proposes a DNSSEC delegation mechanism that complements . In addition this mechanism simplifies multi-signer setups by removing the need to coordinate for signers during key rollovers. About This Document Status information for this document may be found at . Discussion of this document takes place on the deleg Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction This document describes a DNSSEC delegation mechanism that complements . In particular, this mechanism makes it possible to store the contents of DS records as 'ds' parameters in SVCB-style records. This way, a single mechanism can specify both name servers and DNSSEC delegations. In addition to a replacement for DS records, this document also introduces a 'dnskeyref' parameter that provides more flexibility and reduces the need to coordinate both for key rollovers and for multi-signer setups. There are two main problems with the current DS record. The first is a DS record refers to a key in a DNSKEY RRset. Updating this keys (during a key rollover) requires updating the corresponding DS record. At the moment there is no widespread mechanism to update DS records automatically. However, even if such an update mechanism would become widespread, the signer also has to track to propagation of the new DS record to the secondaries of the parent zone. This is needed to make sure that all old DS records are expired in caches before moving to the next stage of a key roll. The second problem is that DS records enforce the use of a single DNSKEY RRset (at the apex of the zone). This means that in a multi-signer setup, signers have to coordinate when rolling their signing keys. There is one minor problem that can be solved as well. Currently every signed zone has to have a DNSKEY RRset at the apex. If a collection of zones share the same keys then this can be burden to maintain. The solution to these problems is to introduce a dnskeyref parameter that contains the names of DNSKEY RRsets that are allowed to sign a zone. This extra level of indirection avoids the need to involve the parent during key rolls. Multiple DNSKEY RRsets make it possible to perform key rolls in a multi-signer setup without coordination. Finally, this allows a single DNSKEY RRset to be used for multiple domains. The charter for the Deleg working group has the following:
The DNS protocol has limited ability for authoritative servers to signal their capabilities to recursive resolvers. In part, this stems from the lack of a mechanism for parents (often registries) to specify additional information about child delegations (often registrants) beyond NS, DS, and glue records. Further complicating matters is the similar lack of a mechanism for a registrant to signal that the operation of a delegation point is being outsourced to a different operator, leaving a challenge when operators need to update parental information that is only in the control of the child. Data is often out of synchronization between parents and children, which causes significant operational problems.
The main focus to date has been on making it possible to update the name servers of a delegation without involving the registrant. However, DNSSEC has a similar problem. The introduction of the dnskeyref parameter make it possible to manage DNSSEC without involving the registrant. One extra feature that becomes possible with the use of SVCB-style records is to let the zone manage downgrade attacks. By introducing ds or dnskeyref parameters at different priority level, the zone can signal which algorithm is preferred. This document updates Section 2.1.1 of in the following way: the sentence "If bit 7 has value 0, then the DNSKEY record holds some other type of DNS public key and MUST NOT be used to verify RRSIGs that cover RRsets." is replaced by "If bit 7 has value 0, then the DNSKEY record holds some other type of DNS public key and can be used to verify RRSIGs that cover RRsets if required." This document updates Section 5.3.1 of and replaces the sentence "The RRSIG RR's Signer's Name field MUST be the name of the zone that contains the RRset." with "The RRSIG RR's Signer's Name field MUST be the name of any DNSKEY RRset that is allowed to sign the zone."
Incremental Deleg This document builds on so examples will show _deleg labels. This document does however assume a new SVCB-style type called DELEG to be able to make clear that some semantics are different from SVCB records. The mechanisms described in this document can work with as well. However, this will create a deployment issue. If a validator that implements this document and forwards requests to a recursive resolver that does not implement then validation will fail if the delegation uses DELEG records. In contrast the same setup but then with will work.
Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document follows terminology as defined in . Throughout this document we will also use terminology with the meaning as defined below:
Incremental deleg:
The delegation mechanism as specified in .
Incremental delegation:
A delegation as specified in .
AliasMode:
An SVCB mode as specified in .
ServiceMode:
An SVCB mode as specified in .
SvcParamKey:
An SVCB field as specified in .
SvcParamValue:
An SVCB field as specified in .
New parameters Two new SVCB-style parameters are introduced: ds and dnskeyref. To limit validation resources and avoid accidentally delegating security, these two parameters are not valid after following an SVCB-style record in AliasMode. For DELEG records, these parameters are allowed to be added to DELEG records in AliasMode. To increase flexibility, a DELEG record in ServiceMode can be created with just ds or dnskeyref parameters but without name server delegation. In that case the TargetName has to be set to ".". Unlike SVCB records, for DELEG we allow mixing of AliasMode and ServiceMode records.
The ds parameter The ds parameter puts the equivalent of multiple DS records in one parameter. To simplify parsing, the presentation format is a space separated list of strings where each string is in the form <key-tag>:<algorithm>:<igest-type>:<digest>. The parts key-tag, algorithm, digest-type and digest have their meaning and encoding as described for the presentation format of the DS record (See , Section 5.3). A parameters start with a 2-octet field that contains the SvcParamKey following by a 2-octet field containing the length of the SvcParamValue. For the ds parameter, the SvcParamValue field consists of a sequence of DS record RDATA octet sequences prefixed by a 1-octet length field. The length field contains the length of the DS record RDATA. The encoding of the RDATA octet sequence is the same as for an equivalent DS record (with the exact same owner name as the SVCB-style record that contains the ds parameter).
The dnskeyref parameter The dnskeyref parameter names one or more DNSKEY RRsets. The presentation format of the value is a space separated list of DNS names. The wire format starts with a 2-octet field that contains that SvcParamKey followed by a 2-octet filed than contains the length of SvcParamValue. For dnskeyref, the SvcParamValue consists of just a concontenated list of uncompressed DNS names in wire format. DNS names are self terminating so there is no need for extra length fields.
Validator behavior When following a delegation, a validator MUST first look for an Incremental delegation. If presence or absence is not DNSSEC Secure (i.e., the status is Insecure, Bogus or Indeterminate) then the child is not secure and the algorithm stops here. If absence of an Incremental delegation is proven to be Secure then then validator MAY continue validating using DS records. If a secure Incremental delegation is found then the validator MUST ignore any DS records and solely rely on what is found in the Incremental deleg records. If the Incremental deleg records contain no ds or dnskeyref parameters or these do not lead to any key with an algorithm that the validator supports then the delegation is considered insecure. A validator MUST NOT use any ds or dnskeyref parameters found after following an SVCB-style record in AliasMode. Restricting ds and dnskeyref to the top level is essential in preventing a DNS operator (who is supposed to only serve a zone, not sign it) from adding additional ds or dnskeyref parameters. To support protection against downgrade attacks, a validator SHOULD consider only SVCB-style records with the highest priority that either have a ds parameter that has a least one algrithm supported by the validator or in the case of dnskeyref, a DNSKEY RRset that contains at least one key with an algorithm that is supported. After selecting priority level, the validator uses any ds parameters to validate the DNSKEY RRset the apex of the child zone. The DNSKEY RRsets that dnskeyref paramters refer need to be DNSSEC Secure to be used. Any DNSKEY RRsets that are not DNSSEC Secure according to the validator MUST be ignored. [Note, to be removed for publication. Should the validator check if the Zone Key flag is zero if the DNSKEY RRset is not at the apex. For now assume that it is just like the SEP flag and can be ignored.] To limit validator resources, when validating a name that refers to a DNSKEY RRset, the validator should only use ds parameters (and DS records) and ignore any dnskeyref parameters. Validator SHOULD allow for a DNAME and CNAME chain of reasonable length when resolving a name to a DNSKEY RRset. Now that there are multiple DNSKEY RRsets that may be used to sign an RRset, the validator uses the Signer's Name in a signature to select a DNSKEY RRset to validate the signature. If the name does not match any of the DNSKEY RRset selected in the previous step then the signature MUST be ignored.
Signer behavior Signer MUST put ds and dnskeyref parameters only in DELEG records at an Incremental delegation and not in SVCB-style records that follow a DELEG record in AliasMode. The ds parameter affects signers in one small way: the priority system of SVCB-style records can be used to provide protection again downgrades. The signer can put a ds parameter with a more secure algorithm in a DELEG record with a higher priority and expect fallback to the less secure algorithm only if the validator does not understand the more secure algorithm. The dnskeyref parameter requires that the validator puts the name of the DNSKEY RRset in the Signer's Name field of the signature. This is a small but significant change to how signers operate. The DNSKEY RRset MUST be DNSSEC Secure and the validation chain MUST only involve ds parameters or DS records. In addition DNSKEY records that are not at the apex of a zone MUST have the Zone Key flag set to 0 (bit 7 of the flags field, see , Section 2.1.1) The dnskeyref parameter also supports downgrade protection but has a number of additinal features that can be used by signers. The first is that because dnskeyref directly refers to a DNSKEY RRset there is no longer any need for Key Signing Keys (KSK). Those DNSKEY RRsets only contain Zone Signing Keys (ZSK). This means that KSK rollovers are no longer necessary. It is also no longer necessary to coordinate with the parent zone for key rollovers. The second is that dnskeyref can refer to a DNSKEY RRset that is used to sign multiple zones. Zones do no need to have their own copies of key material. Instead a single DNSKEY RRset can be used for as many zones as needed. Third, in a multi-signer setup, each signer can maintain its own DNSKEY RRset independent of other signers. This means that each signer can perform key rollovers without any need to coordinate with other signers.
Examples
One ds parameter that is part of a delegation
One ds parameter that is part of a delegation
One separate DELEG record with a ds parameter
One separate DELEG record with a ds parameter
One separate DELEG record with a dnskeyref parameter
One separate DELEG record with a dnskeyref parameter
Two operators with dnskeyref parameters
Two operators with dnskeyref parameters
Security Considerations The ds parameter is a slight improvement over the DS record because it allows SVCB priorities to be used for downgrade protection. Otherwise, the semantics are the same. This relies on the restriction that ds (and dnskeyref) parameters can only appear the top level and not after following an SVCB-style record in AliasMode. The dnskeyref parameter breaks the traditional chain semantics of DNSSEC. With the ds parameter (or the DS record) the validity of a signature depends only on a chain of cryptographic primitives. With dnskeyref, a DNS lookup is inserted. This DNS lookup is protected by a traditional DNSSEC chain, but the presence of the name means that it is no longer a cryptographic chain. This trade-off between struct security and flexibility is left to the zone operator. A new risk that needs to be considered is old and forgotten dnskeyref parameters. Old DS records or ds parameters are mostly safe. An attacker can only assume then if the attacker can obtain the private key that can sign for the public key that the DS record or ds parameter refers to. This is not impossible but very unlikely. And the use of hardware security modules (HSM) can make this almost impossible. In contrast if a dnskeyref refers to a name in a forgotten domain and the registration of the domain is expired then an attacker may register the name and set up a DNSKEY RRset at the name listed in the dnskeyref parameter. The risk of this can be reduced by two operational practices. The first is to put the dnskeyref parameter in the same (AliasMode) DELEG record that provides the name server delegation. This will make it likely that dnskeyref parameter will be removed once the name servers no long serve the zone. The second practice is that domains that allow registrations (mostly top level domains (TLD) but also others) could install a policy that a dnskeyref parameter MUST refer to a DNSSEC Secure DNSKEY RRsets. Additionally each DNSKEY RRset that is referred to by a dnskeyref parameter has to be used to sign the zone as served by at least one of the name servers that serves the zone. This makes it possible to detect forgotten or misconfigured dnskeyref paramters early on.
IANA Considerations Per , IANA is requested to add the following entry to the DNS "Service Parameter Keys (SvcParamKeys)" registry: Entry in the Service Parameter Keys (SvcParamKeys) registry
Number Name Meaning Reference Change Controller  
TBD ds DNSSEC delegations [this document] IETF  
TBD dnskeyref Names of DNSKEY RRsets [this document] IETF  
References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Incrementally Deployable Extensible Delegation for DNS NLnet Labs Cox Communications University of Amsterdam NLnet Labs This document proposes a mechanism for extensible delegations in the DNS. The mechanism realizes delegations with resource record sets placed below a _deleg label in the apex of the delegating zone. This authoritative delegation point can be aliased to other names using CNAME and DNAME. This document proposes a new DNS resource record type, DELEG, which is based on the SVCB and inherits extensibility from it. Support in recursive resolvers suffices for the mechanism to be fully functional. The number of subsequent interactions between the recursive resolver and the authoritative name servers is comparable with those for DNS Query Name Minimisation. Additionally, but not required, support in the authoritative name servers enables optimized behavior with reduced (simultaneous) queries. None, mixed or full deployment of the mechanism on authoritative name servers are all fully functional, allowing for the mechanism to be incrementally deployed. Resource Records for the DNS Security Extensions This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] Protocol Modifications for the DNS Security Extensions This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] Extensible Delegation for DNS Google, LLC ISC Akamai Technologies Salesforce A delegation in the Domain Name System (DNS) is a mechanism that enables efficient and distributed management of the DNS namespace. It involves delegating authority over subdomains to specific DNS servers via NS records, allowing for a hierarchical structure and distributing the responsibility for maintaining DNS records. An NS record contains the hostname of the nameserver for the delegated namespace. Any facilities of that nameserver must be discovered through other mechanisms. This document proposes a new extensible DNS record type, DELEG, which contains additional information about the delegated namespace and the capabilities of authoritative nameservers for the delegated namespace. DNS Terminology The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.
Acknowledgments Jens Finkhäuser, Havard Eidnes, Edward Lewis, Petr Špaček, Johan Stenstam