]> Cloudflare

jabley@cloudflare.com

Operations and Management Registration Protocols Extensions dnssec epp The Extensible Provisioning Protocol (EPP) is used to submit DNSSEC parameters for domain names to domain name registries. Registries and registrars often restrict the values they accept, and those restrictions vary from registry to registry. The resulting uncertainty makes it difficult for DNS operators to adopt new algorithms. This document recommends that registries and registrars base their acceptance policies on the IANA registries for DNSSEC algorithms and digest types. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Registration Protocols Extensions Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction DNS Security Extensions (DNSSEC) are described in . The Extensible Provisioning Protocol (EPP) is used by registrars to manage domain names in domain registries, and specifies how DNSSEC parameters are conveyed in EPP. For a signed zone to have a secure delegation, DS data must be submitted to the parent registry, usually by a registrar using EPP. That data identifies the algorithm used to sign the zone and the digest type used to construct the DS record. When the algorithm changes, new DS data must be submitted. Guidance on suitable algorithms changes over time. Advances in cryptanalysis weaken existing algorithms, and new algorithms are being developed, for example to resist cryptanalysis by quantum computers. Each new algorithm or digest type specified for DNSSEC is assigned a new codepoint, and following current guidance is only possible if registries and registrars accept those codepoints. Registries and registrars often constrain the values they accept using allowlists. What those allowlists contain, whether they are published and how they are maintained varies, and this inconsistency makes new algorithms difficult to deploy. [CITATIONS NEEDED] The inconsistency is felt most by DNS operators. The algorithm used for a zone is generally chosen by the DNS operator that signs it, which may or may not be the registrar, and that choice is typically made once for many zones in many top-level domains, before any EPP transaction takes place. A DNS operator that cannot predict whether a registry will accept a new algorithm risks leaving zones stuck partway through an algorithm rollover, unable to retire the old algorithm because DS data for the new one was rejected. Where DS data is provisioned automatically, there may be nobody in a position to notice the rejection. Faced with this uncertainty, a DNS operator can use only algorithms that every relevant registry is known to accept, limiting registrants to what the most conservative registry allows. Alternatively, it can sign only zones whose registries have known policies, or not sign zones at all. DNSSEC deployment faces many obstacles, most of which are outside the scope of this document. Unpredictable registry policy is one of them, and removing it is a modest but real reduction in the friction associated with deploying DNSSEC. The IANA registries and already record which values are suitable for use with DNSSEC, and are updated as guidance changes . If registries base their acceptance policies on those IANA registries, DNS operators can know in advance which algorithms will be accepted, and newly assigned algorithms become usable across registries at approximately the same time. This document recommends a consistent and liberal policy, based on those IANA registries, for the DNSSEC parameters that registries and registrars accept in EPP.

Conventions and Definitions This document assumes familiarity with DNS and domain name registration terminology as defined in . In this document, "registry" refers to a domain name registry as described in . Registries maintained by IANA are always referred to as "IANA registries". 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.

DNSSEC Parameters in EPP This document is concerned only with which <secDNS:alg> and <secDNS:digestType> values registries and registrars accept in the DS data interface. The key data interface described in is out of scope. This document does not change the contents of the IANA registries or the requirement levels they record. defines two child elements of the <secDNS:dsData> element that are relevant to this document:

• <secDNS:alg> contains the algorithm number of the DNSKEY referenced by the DS record, as described in ; and
• <secDNS:digestType> contains the algorithm used to construct the digest, as described in .

Values for these elements are drawn from the IANA registries and respectively. Following , those IANA registries are the canonical source of requirement levels for each value, and those requirement levels are expected to change over time. This document refers to the following columns in :

• "Zone Signing", which indicates whether an algorithm may appear in DNSKEY, RRSIG and DS records;
• "Use for DNSSEC Signing", which gives the requirement level for using an algorithm to sign zones; and
• "Use for DNSSEC Validation", which gives the requirement level for using an algorithm in DNSSEC validators.

This document refers to the following columns in :

• "Use for DNSSEC Delegation", which gives the requirement level for using a digest type in DS records published by authoritative servers; and
• "Use for DNSSEC Validation", which gives the requirement level for using a digest type in DNSSEC validators.

The "Implement for" columns in those IANA registries describe requirements for software implementations rather than for the operation of a zone, and are not used by this document.

Recommendations for Registries and Registrars

Default Policy Registries and registrars SHOULD accept any value of the <secDNS:alg> and <secDNS:digestType> elements that is not excluded by , and SHOULD NOT reject values on any other basis. For a registrar, this applies to values received from registrants and DNS operators through whatever interface the registrar provides. In particular, registries and registrars SHOULD NOT reject a value solely because they do not themselves implement the corresponding algorithm. A validator that does not support the algorithm or digest type specified in a DS record disregards that record (, ), so accepting such values cannot cause validation failures for the zone concerned. Similarly, registries and registrars that check the length of the <secDNS:digest> element SHOULD do so only for digest types whose digest length they know. A registrar SHOULD NOT apply restrictions beyond those applied by the registry for the domain name concerned. A registrar is not expected to accept a value that the registry would reject, and can instead report the registry's rejection to its customer.

Values to Deny Registries and registrars SHOULD reject a <secDNS:alg> value unless its "Zone Signing" column in is "Y" and its "Use for DNSSEC Validation" column is not "MUST NOT". This admits the values reserved for private algorithms. Registries and registrars SHOULD reject a <secDNS:digestType> value unless its "Use for DNSSEC Validation" column in contains a requirement level other than "MUST NOT", or the value is reserved for private use. These rules exclude values that are unassigned, cannot appear in DS records, or are no longer expected to be validated. DS data containing such values provides no security benefit and could suggest that a zone is protected when it is not, and rejecting them also catches errors in submitted data. The rules apply to the current contents of the IANA registries, which are expected to change over time, not to a fixed snapshot of them.

Existing DS Data The contents of the IANA registries change over time, so DS data that was accepted in the past may later include values that would exclude. Registries and registrars MUST NOT reject a request to remove DS data on the grounds that it contains values that would be denied under . Registries and registrars SHOULD NOT reject an otherwise acceptable request on the grounds that DS data already associated with the domain name contains values that would be denied under .

Keeping Current Registries and registrars SHOULD reflect changes to and in their acceptance policy within 30 days of those changes being published.

Publication Registries and registrars SHOULD publish their policy for accepting <secDNS:alg> and <secDNS:digestType> values at a stable and publicly accessible location, so that registrants and DNS operators can make informed choices. The published policy SHOULD state whether it follows this document and SHOULD describe any respect in which it does not. For registries that publish a DNSSEC Practice Statement , that document is a suitable location.

Operational Considerations Registry and registrar systems that process DS data, including systems that generate zone data or publish registration data, may encounter algorithm and digest type values they have not seen before. Such systems need to handle unfamiliar values without failure, for example by treating them as opaque numbers. A failure in a registry's own systems caused by an unfamiliar value could affect many delegations, not only the one concerned, and is a more significant risk than any effect on validation.

Security Considerations

Unsupported Algorithms and Digest Types The recommendations in cause registries and registrars to accept algorithm and digest type values that they, and some validators, may not implement. A validator that does not support the algorithm specified in a DS record, or that does not support its digest type, disregards that record (, ). If no remaining DS record for a delegation uses a supported algorithm and digest type, the validator treats the child zone as unsigned. Accepting such values therefore cannot cause a validator to treat a correctly signed zone as bogus. The worst outcome is that the zone is unsigned from the point of view of validators that lack support. This is no worse than if the DS data had been rejected. Registrants and DNS operators who submit DS data using only algorithms that are not yet widely supported should understand that their zones are unlikely to be successfully validated. Validators also generally do not support the private algorithm values (253 and 254) in , and different parties may interpret them differently.

Weak Algorithms and Digest Types A validator may accept any valid chain of trust from the parent to the child, regardless of what other algorithms are present (). The security of a signed delegation is therefore limited by the weakest algorithm and digest type in its DS data that validators still accept. Publishing DS data that uses a weak algorithm or digest type alongside DS data that uses a strong one does not preserve the strength of the stronger combination. The values denied in add no assurance. Values that are deprecated for signing or delegation but are still validated represent a greater risk. This document does not recommend rejecting them, since doing so would interfere with DNS operators and registrants who have not yet completed an algorithm rollover. The risk of using a weak algorithm or digest type falls mainly on the zone concerned and the zones beneath it.

Unauthorised Changes An attacker who can submit DS data for a domain name, for example by compromising a registrant's account at a registrar, could submit DS data containing arbitrary values. Accepting a wider range of values does not materially change the impact of such an attack. An attacker with that access could already remove the DS data or change the delegation itself.

Algorithm Agility Policies that are too restrictive, or that are not kept current (), can prevent DNS operators and registrants from moving away from algorithms that are becoming weaker or from adopting new ones, such as those designed to resist cryptanalysis by quantum computers. This prolongs exposure to the weaknesses that algorithm agility is meant to address. The recommendations in this document are intended to remove that obstacle while still allowing registries and registrars to exclude values that offer no security benefit.

IANA Considerations This document has no IANA actions.

References Normative References IANA n.d. IANA n.d. This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK] This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security (DNSSEC) extensions for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. This document obsoletes RFC 4310. [STANDARDS-TRACK] 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. 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. 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. 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] The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document replaces and obsoletes RFC 8624 and moves the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from RFC 8624 to the IANA DNSSEC algorithm registries. This is done to allow the list of requirements to be more easily updated and referenced. Extensions to these registries can be made in future RFCs. This document also updates RFC 9157 and incorporates the revised IANA DNSSEC considerations from that RFC. This document does not change the recommendation status (MUST, MAY, RECOMMENDED, etc.) of the algorithms listed in RFC 8624; that is the work of future documents. 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] This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing. This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification. Informative References This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. This document is not an Internet Standards Track specification; it is published for informational purposes.

Acknowledgments Bas Westerbaan provided post-quantum energy. Scott Hollenbeck and Gavin Brown provided welcome encouragement.