]> The Swedish Internet Foundation

johan.stenstam@internetstiftelsen.se

Internet DNSOP Working Group DNSSEC algorithm numbers post-quantum private use experimental The DNSSEC Algorithm Numbers registry contains two code points, 253 (PRIVATEDNS) and 254 (PRIVATEOID), intended for private and experimental algorithms. These code points identify the algorithm by prepending a domain name or an object identifier to the "Public Key" field of the DNSKEY RDATA, overloading the semantics of that field and forcing every implementation to special-case algorithm dispatch. Because all such algorithms share a single code point, they cannot be distinguished on the wire by the algorithm number alone. This document reserves two small ranges of DNSSEC algorithm numbers: one for Private Use, requiring no IANA registration, and one for experimental algorithms, registered on a First Come First Served basis. Code points drawn from these ranges behave identically to ordinary algorithm numbers and require no overloading of the DNSKEY RDATA. This enables clean experimentation with the growing set of post-quantum and other candidate signature algorithms. This document updates RFC 6014 and RFC 9157. Status information for this document may be found at . Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (), which is archived at . Subscribe at .

Introduction The "DNS Security Algorithm Numbers" registry assigns the values used in the Algorithm field of the DNSKEY, RRSIG, and related resource records. Its allocation policy was established by and subsequently revised by ; values in the range 123-251 are currently marked "Reserved". Two code points are set aside for non-standardized algorithms: 253 (PRIVATEDNS), where the algorithm is identified by a domain name, and 254 (PRIVATEOID), where the algorithm is identified by an ISO Object Identifier (OID). As detailed in , these two code points are poorly suited to the kind of experimentation the community now needs. There are two converging reasons why a cleaner mechanism is required now: The transition to post-quantum cryptography (PQC) is driving active experimentation in DNS. Whether or not PQC migration becomes urgent for DNSSEC in the near term, the experimentation is already happening. A large and growing set of candidate signature algorithms is under evaluation and discussion. NIST has standardized ML-DSA and SLH-DSA , with FN-DSA (Falcon) and additional families following, and several other candidates (for example MAYO and SNOVA) remain under study. Implementers need to deploy and interoperate with several such algorithms concurrently, well before any of them warrants a permanent, standardized code point. The experimental range defined here is anticipated to be useful in particular for two emerging deployment scenarios: The kind of large-KSK algorithm experimentation described in , where post-quantum candidate algorithms with different size and strength trade-offs are evaluated as DNSKEY/RRSIG/DS algorithms in real zones. The SIG(0) key used to sign cross-zone-cut DNS UPDATE messages between a child and the parent's UPDATE Receiver in the delegation-management mechanism of . That path is infrequent and uses TCP, so it imposes no significant wire-size constraint on the SIG(0) signature and is a natural low-risk environment for trying experimental algorithms. Both scenarios benefit from distinct code points: validators and UPDATE Receivers can dispatch on the algorithm number alone, multiple candidates can coexist for interoperability testing, and experiments can be conducted across organizations without collisions or out-of-band coordination. This document carves two small ranges out of the Reserved block of the DNSSEC Algorithm Numbers registry: an experimental range registered on a First Come First Served basis, and a Private Use range that requires no IANA action. Algorithms using code points from these ranges are dispatched by algorithm number alone, exactly like standardized algorithms, and impose no special parsing on the DNSKEY RDATA.

Conventions and Definitions 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.

Why Code Points 253 and 254 Are Insufficient Code points 253 and 254 do not change the DNSKEY wire format: the RDATA remains Flags | Protocol | Algorithm | Public Key. Instead, per Appendix A.1.1 of , the discriminator (a domain name for 253, or an OID for 254) is prepended to the bytes that the format calls the "Public Key" field. The semantics of that field are thereby overloaded: the leading bytes are not key material at all. This design has several practical drawbacks that are amplified when more than one private algorithm is in use:

Single code point for many algorithms:

All algorithms that use 253 (or 254) share that one code point. Software that dispatches coarsely on the algorithm number cannot tell them apart; they are all "253" or "254". An operator running several concurrent algorithms (for example, six post-quantum candidates) cannot place them in the same zone and distinguish them by code point.

Hot-path special-casing:

For 253/254 an implementation cannot simply switch on the algorithm number to select a verifier. On every operation touching a DNSKEY it must first parse the prepended name or OID, look it up in an implementation-private table mapping names/OIDs to crypto code, strip those bytes, and only then hand the remainder to the verifier. This logic lands on the signing and validation hot path.

RRSIG/DNSKEY out-of-band agreement:

The RRSIG carries only the algorithm number (253/254), not the discriminator. To verify, an implementation must fetch the DNSKEY, extract the embedded name/OID, and confirm it matches the algorithm the signer used; the signer and verifier must agree on the private algorithm out of band of the wire format.

These three are load-bearing; the overloading also carries lesser costs (the prepended name or OID is pure wire overhead in every DNSKEY, and key file formats, test harnesses, and tooling must all special-case 253/254 because the algorithm number alone does not identify a keypair). The net effect is that an implementation supporting several private algorithms via 253/254 pays a permanent special-casing tax internally, while still gaining no interoperability outside its own deployment, since general-purpose validators that implement 253/254 are rare. A small range of ordinary code points avoids all of this.

Allocation of Experimental and Private-Use Code Points This document designates two ranges within the DNSSEC Algorithm Numbers registry. Code points in either range are used in the Algorithm field exactly as standardized algorithm numbers are: dispatch is by code point alone, and the DNSKEY "Public Key" field carries only key material.

Experimental Range The range 228-243 is designated for experimental algorithms and is registered on a First Come First Served basis (Section 4.7 of ). Code points in this range are recorded by IANA, so that independent experimenters can choose distinct code points and run interoperability tests without colliding. Registration is deliberately low-friction: a registrant supplies a short description and a point of contact (see ). Code points in this range are for experimentation and interoperability testing only, and MUST NOT be relied upon for production deployments. The lifecycle of an algorithm -- how a candidate is evaluated and eventually standardized -- is outside the scope of this document; this document governs only the experimental range itself. The relationship between the two is simple and exclusive: an algorithm is either experimental or standardized, never both. When an algorithm is assigned a code point under the registry's normal policy , any experimental code point it was using is removed from the experimental range at the same time. There is no overlap period and no deprecation window; a standardized algorithm always receives a new, ordinary code point rather than retaining its experimental one. A code point freed in this way -- whether because the algorithm graduated, the registrant released it, or the experiment was abandoned and reclaimed -- returns to the pool of values available for First Come First Served assignment within the experimental range. Because the range is a finite shared resource, this document defines a lightweight process for releasing and reclaiming code points; see .

Private Use Range The range 244-251 is designated for Private Use, as defined in Section 4.1 of . No IANA registration is made for these values, and no IANA action is required to use one. Private Use code points are intended for use within a single administrative domain (one operator, one test lab, one deployment). The mapping from a Private Use code point to an actual algorithm is a local matter. Unlike the Experimental range, no central registry exists, so two deployments MAY use the same Private Use code point for different algorithms; implementations MUST NOT assume any particular meaning for a Private Use code point across administrative boundaries. This range is appropriate for an operator that wishes to run several algorithms concurrently and distinguish them by code point, without any coordination overhead.

Relationship to RFC 8126 "Experimental Use" defines an "Experimental Use" policy (Section 4.2) under which, as with Private Use, IANA makes no assignments. This document deliberately does not use that policy for the experimental range. The goal of the experimental range is shared, collision-free interoperability testing across multiple parties, which requires that IANA record the assignments; the First Come First Served policy provides exactly that with minimal friction. The Private Use range in terms covers the no-registration case.

Relationship to Code Points 252, 253, and 254 This document does not change the meaning of code points 252 (INDIRECT), 253 (PRIVATEDNS), or 254 (PRIVATEOID). Implementations MAY continue to use 253 and 254. The ranges defined here are an alternative that avoids overloading the DNSKEY "Public Key" field and allows several private or experimental algorithms to coexist on the wire, distinguishable by code point alone.

Operational Considerations A validating resolver that does not recognize the algorithm of an RRSIG or DNSKEY treats the corresponding data as unsigned/insecure, per Section 5.2 of . Consequently, a zone signed solely with a Private Use or experimental algorithm is insecure from the perspective of any resolver outside the deployment that does not implement that algorithm. This is the intended and desirable behavior for private and experimental use. When a zone is signed with multiple algorithms, the multi-algorithm rules in Section 5.11 of apply. A validator that does not recognize an experimental or Private Use algorithm in the DNSKEY RRset can still validate the zone using any standardized algorithm present in the same RRset; the unknown algorithm does not, by itself, render the zone bogus. Within an experimental or private deployment, code points from these ranges will appear in the Algorithm field of DS records published at the parent, exactly as standardized algorithm numbers do. A validating resolver outside the deployment that does not recognize the algorithm will treat the delegation as insecure, as it would for any unknown algorithm.

IANA Considerations IANA is requested to update the "DNS Security Algorithm Numbers" registry within the "Domain Name System Security (DNSSEC) Algorithm Numbers" registry group. The values 228-251 are currently part of the "Reserved" block (123-251, ). IANA is requested to remove these values from that Reserved block and to record them as follows. After this change, the Reserved block is 123-227. Number Description Mnemonic Reference 228-243 Experimental algorithms   (this document) 244-251 Private Use   (this document) For the range 228-243 ("Experimental algorithms"), the registration procedure is First Come First Served . Each registration request must include: the requested code point (or a request that IANA assign the next available value in the range); a short descriptive name for the algorithm; a brief description and/or a stable reference; and a point of contact. Registrations in this range are understood to be experimental: assignment of a code point does not imply any standardization status, and an entry is removed from the experimental range when its algorithm is standardized under the registry's normal policy (see ). Because the experimental range is a finite, shared resource, code points are intended to be returned to availability rather than held indefinitely. A code point in this range is released -- its entry removed and the value returned to the pool available for First Come First Served assignment -- in any of the following cases: the algorithm is standardized and receives an ordinary code point under the registry's normal policy (the entry is removed at the same time, as described in ); the registrant requests release, via the registered point of contact; or the entry is reclaimed as abandoned (see below). To support release and the curation of abandoned entries, IANA is requested to appoint a Designated Expert for this range. The Designated Expert is not consulted for ordinary First Come First Served assignments, which remain low-friction; the Expert's role is limited to confirming releases and to reclaiming entries that have been standardized or whose point of contact has become unresponsive and whose entry shows no sign of continued use. Before reclaiming an entry as abandoned, the Designated Expert SHOULD attempt to reach the registered point of contact. A released code point carries no record of its prior experimental use and MAY subsequently be assigned to an unrelated experiment. For the range 244-251 ("Private Use"), the policy is Private Use ; IANA makes no assignments and takes no further action for these values. IANA is requested to add this document as a reference for the "DNS Security Algorithm Numbers" registry, alongside and .

Security Considerations This document allocates code point ranges and does not define or endorse any cryptographic algorithm; the security properties of any algorithm that uses a code point from these ranges are out of scope. A validator that does not implement the algorithm associated with a Private Use or experimental code point treats the data as insecure (Section 5.2 of ). This containment property is intentional: data signed with a private or experimental algorithm cannot be mistaken for securely validated data by a resolver that does not understand the algorithm. Because Private Use code points carry no globally agreed meaning, a code point that denotes a strong algorithm in one deployment may denote a different (possibly weaker, broken, or absent) algorithm in another. Implementations MUST NOT rely on Private Use code points across administrative boundaries, and operators MUST ensure that Private Use code points and the associated key material do not leak beyond the deployment in which they are meaningful. Experimental algorithms have, by definition, received limited analysis. They MUST NOT be used to protect production data on the assumption that they provide the security of a standardized algorithm. The multi-algorithm considerations of Section 5.11 of apply when a zone mixes algorithms from these ranges with standardized algorithms; in particular, the presence of an unknown algorithm in a DNSKEY RRset does not on its own make a zone bogus.

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] This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the requirement from "standard required" to "RFC Required". It does not change the list of algorithms that are recommended or required for DNSSEC implementations. [STANDARDS-TRACK] Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014 to include hash algorithms for Delegation Signer (DS) records and NextSECure version 3 (NSEC3) parameters (for Hashed Authenticated Denial of Existence). It also updates RFCs 5155 and 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to clarify the implementation recommendation related to the algorithms described in RFCs that are not on the standards track. The rationale for these changes is to bring the requirements for DS records and hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms. 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 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. National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) The Swedish Internet Foundation The Swedish Internet Foundation The Swedish Internet Foundation Delegation information (i.e. the NS RRset, possible glue, possible DS records) should always be kept in sync between child zone and parent zone. However, in practice that is not always the case. When the delegation information is not in sync the child zone is usually working fine, but without the amount of redundancy that the zone owner likely expects to have. Hence, should any further problems ensue it could have catastrophic consequences. The DNS name space has lived with this problem for decades and it never goes away. Or, rather, it will never go away until a fully automated mechanism for how to keep the information in sync automatically is deployed. This document proposes such a mechanism based on DNS Dynamic Updates (DDNS) secured with SIG(0) signatures, sent from the child to the parent across the zone cut. The target of the update is discovered via the DSYNC record defined in [RFC9859]. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-ietf-dnsop-delegation-mgmt-via-ddns (https://github.com/johanix/draft-ietf-dnsop-delegation-mgmt-via- ddns). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests.

Acknowledgments The author thanks Peter Thomassen (deSEC), Ondřej Surý (Internet Systems Consortium), Benno Overeinder (NLnet Labs), and Erik Bergström (Swedish Internet Foundation) for valuable insights and discussions on the need for distinct experimental algorithm code points.