Experimental and Private-Use Ranges in the DNSSEC Algorithm Numbers Registry

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 14 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The "DNS Security Algorithm Numbers" registry [RFC4034] assigns the values used in the Algorithm field of the DNSKEY, RRSIG, and related resource records. Its allocation policy was established by [RFC6014] and subsequently revised by [RFC9157]; 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 Section 3, 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:¶

1. 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.¶

2. A large and growing set of candidate signature algorithms is under evaluation and discussion. NIST has standardized ML-DSA [FIPS204] and SLH-DSA [FIPS205], 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 [I-D.johani-dnsop-dnssec-alg-split], 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 [I-D.ietf-dnsop-delegation-mgmt-via-ddns]. 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.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. 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 [RFC4034], 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.¶

4. 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.¶

5. 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 [RFC4035]. 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 [RFC6840] 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.¶

6. 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, [RFC4034] [RFC6014]). 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.¶

For the range 228-243 ("Experimental algorithms"), the registration procedure is First Come First Served [RFC8126]. 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 Section 4.1).¶

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 Section 4.1);¶

• 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 [RFC8126] 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 [RFC8126]; 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 [RFC6014] and [RFC9157].¶

7. 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 [RFC4035]). 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 [RFC6840] 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.¶

8. References

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.¶

Author's Address