RFC 4955

RFC 4955: DNS Security (DNSSEC) Experiments 🎀

• Series: Network Working Group 💖
• Author: D. Blacka, VeriSign, Inc. 💅
• Category: Standards Track ✨
• Date: July 2007 🦋
• Obsoletes/Updates: the title block doesn't list anything this one obsoletes or updates 🙈

Status of This Memo 📋

This document is an Internet standards track protocol spec for the Internet community, and it's open for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited. 🌸

Copyright Notice ©️

Copyright (C) The IETF Trust (2007). 💜

Abstract 🧚

okay so this doc lays out a way to test out new, non-backwards-compatible DNS Security (DNSSEC) ideas as experiments, without messing up regular DNSSEC rollouts. it's giving "try the new thing but nobody gets hurt" 🫶

Table of Contents 🍓

1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Definitions and Terminology . . . . . . . . . . . . . . . . . . 2
3.  Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.  Method  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5.  Defining an Experiment  . . . . . . . . . . . . . . . . . . . . 4
6.  Considerations  . . . . . . . . . . . . . . . . . . . . . . . . 5
7.  Use in Non-Experiments  . . . . . . . . . . . . . . . . . . . . 5
8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
  9.2.  Informative References  . . . . . . . . . . . . . . . . . . 6

1. Overview 🌈

so historically, trying out DNSSEC alternatives has been kinda messy, ngl 😭 people usually want two things at once: make non-backwards-compatible changes to DNSSEC, and test them on real zones in the public DNS. the problem is that the change can make all or part of the zone look bogus (bad) or just plain broken to existing security-aware resolvers. literally the worst 💀

this doc describes a standard way to set up DNSSEC experiments. the trick for coexisting with standard DNSSEC and DNS is to use unknown algorithm identifiers, which hides the experimental protocol changes from standard security-aware resolvers. it's so clever it's iconic 👑

2. Definitions and Terminology 📚

bestie, this doc assumes you already know the DNS system (RFC 1035 [5]) and the DNS security extensions (RFC 4033 [2], RFC 4034 [3], and RFC 4035 [4]). no cap, you need that background 🤓

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 🫶

3. Experiments 🧪

when we talk about DNSSEC experiments, we need to sort them into two big categories:

• Backwards-Compatible: experimental changes that don't strictly follow the DNSSEC standard, but still work fine with clients and servers that do implement it. 🌸
• Non-Backwards-Compatible: experiments that would make a standard security-aware resolver (incorrectly) decide that all or part of a zone is bogus, or otherwise stop interoperating with standard DNSSEC clients and servers. 💀

experiments with the core DNS protocol itself aren't part of these terms, so they're not included. 🙈

the methodology in this doc isn't necessary for backwards-compatible experiments, although you certainly may use it if you want 💖

4. Method ✨

the core of the methodology is using strictly unknown algorithm identifiers when signing the experimental zone. even more important, the DS records for the delegation to the zone at the parent should have only unknown algorithm identifiers in them. it's the main character move 🦋

this works because of how DNSSEC-compliant validators are expected to behave when they see a DS set with only unknown algorithm identifiers. here's what RFC 4035 [4], Section 5.2 says:

If the validator does not support any of the algorithms listed in an authenticated DS RRset, then the resolver has no supported authentication path leading from the parent to the child. The resolver should treat this case as it would the case of an authenticated NSEC RRset proving that no DS RRset exists, as described above.

and further:

If the resolver does not support any of the algorithms listed in an authenticated DS RRset, then the resolver will not be able to verify the authentication path to the child zone. In this case, the resolver SHOULD treat the child zone as if it were unsigned.

ok so this behavior isn't strictly mandatory (that's what the MUST in the spec is about), but it's super unlikely for a validator to do something substantially different 👀 basically, if the validator doesn't have a usable chain of trust to a child zone, it can only do one of two things: treat the responses from the zone as insecure (the recommended behavior), or treat them as bogus. if it picks the second option, that wrecks the zone owner's expectations and defeats the whole purpose of the rule above. 😤 still, a validator is totally allowed, through local policy, to refuse to trust certain zones based on any criteria, including the use of unknown signing algorithms. it's giving "my house, my rules" 🏠

since we're talking about experiments, it is RECOMMENDED that private algorithm numbers be used (see RFC 4034 [3], Appendix A.1.1. Note that secure handling of private algorithms requires special handing by the validator logic. See "Clarifications and Implementation Notes for DNSSECbis" [6] for further details.) 🔐 normally, instead of actually inventing new signing algorithms, the recommended path is to create alternate algorithm identifiers that are aliases for the existing, known algorithms. strictly speaking, you only need to make an alternate identifier for the mandatory algorithms, but it's suggested that all optional defined algorithms get aliased too. more is more, periodt 💅

it is RECOMMENDED that, for a particular DNSSEC experiment, you pick one domain name base for all the new algorithms, then prepend the algorithm number (or name) to it. for example, for experiment A, the base name "dnssec-experiment-a.example.com" is chosen. then aliases for algorithms 3 (DSA) and 5 (RSASHA1) are defined as 3.dnssec-experiment-a.example.com and 5.dnssec-experiment-a.example.com. however, any unique identifier will do 🎀

with this method, resolvers (or, more specifically, DNSSEC validators) basically show they can handle the experiment's semantics by understanding what the new algorithm identifiers mean. 🧚

this method creates two classes of security-aware servers and resolvers:

• servers and resolvers that are aware of the experiment (so they recognize its algorithm identifiers and experimental semantics), and 💜
• servers and resolvers that are unaware of the experiment. 🙈

this method also rules out a zone being in an experiment and in a classic DNSSEC island of security. a zone is either in an experiment, where it can only be validated experimentally, or it isn't. no in-between, no vibes-based DNSSEC 😌

5. Defining an Experiment 🔬

the DNSSEC experiment MUST define the particular set of (previously unknown) algorithm identifiers that identify the experiment, and define what each unknown algorithm identifier means. usually, unless the experiment is actually testing a brand-new DNSSEC algorithm, this will be a mapping of private algorithm identifiers to existing, known algorithms. 🍓

normally the experiment picks a DNS name as the algorithm identifier base. this DNS name SHOULD be under the control of the authors of the experiment. then the experiment defines a mapping between the known mandatory and optional algorithms and that private algorithm identifier space. alternately, the experiment MAY use the Object Identifier (OID) private algorithm space instead (using algorithm number 254), or MAY choose non-private algorithm numbers, although that would require an IANA allocation. 🌈

for example, an experiment might say in its description that the DNS name "dnssec-experiment-a.example.com" is the base name, and declare that 3.dnssec-experiment-a.example.com is an alias of DNSSEC algorithm 3 (DSA), and that 5.dnssec-experiment-a.example.com is an alias of DNSSEC algorithm 5 (RSASHA1). ✨

Resolvers MUST only recognize the experiment's semantics when they're present in a zone signed by one or more of these algorithm identifiers. this is necessary so that one experiment's semantics stay isolated from any others that the resolver might understand. it's about boundaries, bestie 🫶

in general, resolvers involved in the experiment are expected to understand both standard DNSSEC and the defined experimental DNSSEC protocol, although this isn't required. 💖

9.2. Informative References ✨

These are the extra-credit reads 📚. They back up the spec but aren't normative, so you don't have to read them to get the main idea.

• [5] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
• [6] Weiler, S. and R. Austein, "Clarifications and Implementation Notes for DNSSECbis", Work in Progress, March 2007.

Author's Address 🦋

David Blacka
VeriSign, Inc.
21355 Ridgetop Circle
Dulles, VA  20166
US

Phone: +1 703 948 3200
EMail: davidb@verisign.com
URI:   http://www.verisignlabs.com

---

Full Copyright Statement 💜

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🌈

The IETF doesn't take a side on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or how far they reach. It also doesn't say whether a license to those rights is available or might not be. It hasn't made any independent effort to find out what rights exist either. If you want the procedures for rights in RFC documents, check BCP 78 and BCP 79 🎀.

Copies of IPR disclosures sent to the IETF Secretariat are available, along with any assurances of licenses. You can also find the result of any attempt to get a general license or permission for implementers or users to use those proprietary rights. All of this lives in the IETF's online IPR repository at http://www.ietf.org/ipr.

The IETF also invites anyone to flag copyrights, patents, patent applications or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. 🌸