RFC 9615

RFC 9615: Automatic DNSSEC Bootstrapping Using Authenticated Signals from the Zone's Operator ✨🎀

okay bestie, let's get into it 🦋 this is an IETF Standards Track doc (so it's the real deal, not a suggestion 💅), written by P. Thomassen and N. Wisiol from deSEC, Secure Systems Engineering (SSE) and Technische Universität Berlin 🌸. It came out in July 2024 and it's ISSN 2070-1721. It updates RFC 7344 and RFC 8078 🔥, so if you've read those, this one is literally coming in to level them up 👑.

Quick rundown of the vibe: this doc gives DNS operators an in-band way to publish info about their zones in an authenticated way, per zone 🧚. The big payoff is that it lets a parent (registry or registrar) cryptographically check the CDS/CDNSKEY records at a child's apex 💖, so you can set up DS records without the sketchy "Accept after Delay" shortcut or out-of-band checks 😭. Also, Section 4 is now the preferred enrollment method over Section 3 of RFC 8078 💜.

---

1. Introduction 🌸

okay so first, why is this even needed? 🙈 Setting up DNSSEC for the first time means the child's key params have to get to the parent through some trusted channel. Usually that's the child DNS operator, and sometimes the registrar (maybe through the registrant too) 💅. RFC 7344 pointed out that all this manual back-and-forth is error-prone and annoying, so people just... skip it 💀.

RFC 8078 tried to automate DS provisioning by having the parent fetch CDS and CDNSKEY records from the child's apex and validate them somehow ✨. Validation is easy if you already have a DNSSEC chain of trust (like for a key rollover), but for bootstrapping? There's no existing path yet, so the validation is the hard part 😩. Folks ended up doing out-of-band stuff or going with "Accept after Delay" (Section 3.3 of RFC 8078), and RFC 8078 itself doesn't have an in-band validation method. Iconic gap 🫠.

So this document closes that gap 🎀. It adds an in-band, authenticated way for operators to publish info per zone. The parent uses that signal to validate the CDS/CDNSKEY RRsets at an insecure child zone's apex and then secure the delegation 🦋.

It's not for every edge case though. It doesn't support excessively long child zone names, or bootstrapping for domains that only have in-domain nameservers (more on that in Section 4.4) 🙈.

Also, DNSSEC bootstrapping is just one use of this generic signaling mechanism. Later on, people could use it for operational metadata or extra info, like API endpoints for third parties 🌈.

Readers are expected to know DNSSEC [BCP237] 💜.

1.1. Terminology 📖

Here's the vocab, babe 💅:

• CDS/CDNSKEY: shorthand for CDS, CDNSKEY, or both 🌸.
• Child: see Section 7 of [RFC9499] 🦋.
• Child DNS operator: the entity that maintains and publishes the zone info for the child DNS 🧚.
• Parent: see Section 7 of [RFC9499] ✨.
• Parental agent: the entity that can insert DS records into the parent zone for the child. This could be the registry, registrar, a reseller, or another authorized entity 👑.
• Signaling domain: a domain made by sticking the label _signal onto a hostname from a delegation's NS RRset. There are as many signaling domains as there are distinct NS targets 🎀.
• Signaling name: the labels stuck onto a signaling domain to identify a signaling type and a child zone's name (see Section 3.2) 💖.
• Signaling record: a DNS record at a signaling name under a signaling domain. The child DNS operator uses these to publish info about the child 🔥.
• Signaling type: a signal type identifier, like _dsboot for DNSSEC bootstrapping 🌈.
• Signaling zone: the zone that's authoritative for a given signaling record 🫶.

1.2. Requirements Notation 💅

The BCP 14 key words are the ones that matter here, and they only count when they show up in ALL CAPS, like this: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". They're interpreted as described in BCP 14 [RFC2119] [RFC8174] 🌸.

2. Updates to RFCs 🦋

Okay this section is the "we're changing other RFCs" part 🙈. The DS enrollment methods in Section 3 of [RFC8078] are less secure than the one in Section 4 of this doc. So child DNS operators and parental agents who want to use CDS/CDNSKEY records for initial DS enrollment SHOULD support the authentication protocol described here 💖.

Also, to make publishing signaling records for DNSSEC bootstrapping work (see Section 4.1), the first bullet ("Location") of Section 4.1 of [RFC7344] gets removed 🔥.

3. Signaling 🧚

This section explains the general way a child DNS operator can publish an authenticated signal about a child zone ✨. Parental agents (or anyone else) can then find and process that signal 👑. Authenticity comes from standard DNSSEC validation, so no magic required 💅.

3.1. Chain of Trust 🔗

If a child DNS operator implements this spec, each signaling zone MUST be signed and MUST be validatable by the parental agent. In other words, it has to have a valid publicly resolvable DNSSEC chain of trust 🌈. This is usually done by securely delegating each signaling zone 🎀.

For example, say you're publishing a signal for a child zone with NS records ns1.example.net and ns2.example.org. The child DNS operator needs to make sure the parental agent has a valid DNSSEC chain of trust for the zone(s) authoritative for the signaling domains _signal.ns1.example.net and _signal.ns2.example.org 💖.

3.2. Signaling Names 🌸

Okay this is the naming part, and it's important 🫶. To publish info about the child zone in an authenticated way, the child DNS operator MUST publish one or more signaling records at a signaling name under each signaling domain 🔥.

Signaling records MUST be accompanied by RRSIG records created with the corresponding signaling zone's key(s) 🦋. What the type and contents of those signaling records look like depends on the type of signal 🧚.

The signaling name identifies both the child and the signaling type. It's the child name (with the final root label dropped) with an extra label on the front that holds the signaling type 👑.

4. Bootstrapping a DNSSEC Delegation ✨

This is the main event, bestie 🎀. When the child zone's CDS/CDNSKEY RRsets are used to set up initial trust, they need to be authenticated 🔥. That's done by copublishing the child's CDS/CDNSKEY RRsets as an authenticated signal (see Section 3) 💅. The parent can then discover and validate it, which transfers trust from the child DNS operator nameservers' chain of trust over to the child zone 💖.

This protocol is NOT meant for updating an existing DS RRset 🙈. For that, the parental agent can validate the child's CDS/CDNSKEY RRsets directly, using the chain of trust from the existing DS RRset (Section 4 of [RFC7344]) 🦋.

---

That's the end of part 1 of 3, so more is coming! Stay tuned, bestie 💜🌈

4.1. Signaling Consent to Act as the Child's Signer ✨

Okay bestie, so the child DNS operator is basically saying "yep, I'm down to be this child's signer" 💅 by publishing its CDS/CDNSKEY RRsets at the matching signaling name under each signaling domain. To confirm that and authenticate the child's CDS/CDNSKEY RRsets 🫶, the child DNS operator MUST copublish them at the corresponding signaling name under each signaling domain, except the ones that would fall within the child domain (Section 3.2). Lowkey extra, but for simplicity the child DNS operator MAY also copublish the child's CDS/CDNSKEY RRsets under signaling domains within the child domain 🌸. Those in-child signaling domains aren't used for validation though (Section 4.2).

Unlike the CDS/CDNSKEY RRsets at the child's apex, a signaling RRset MUST be signed with the corresponding signaling zone's key(s) 🔐. Its contents MUST be identical to the corresponding RRset published at the child's apex. No cap, these have to match 100%.

Here's the tea 🍵: CDS/CDNSKEY records were originally only used at the child apex (Section 4.1 of [RFC7344]). This protocol stretches them to non-apex owner names for DNSSEC bootstrapping 🦋. To avoid any semantic collision, there MUST NOT be a zone cut at a signaling name. Bestie, don't let that happen 🙅‍♀️.

4.1.1. Example

Let's do the child zone example.co.uk, which has NS records ns1.example.net, ns2.example.org, and ns3.example.co.uk. The signaling domains it needs are _signal.ns1.example.net and _signal.ns2.example.org 🧚.

In the zones that hold these domains, the child DNS operator authenticates the CDS/CDNSKEY RRsets at the child's apex by copublishing them as CDS/CDNSKEY RRsets at these names:

_dsboot.example.co.uk._signal.ns1.example.net
_dsboot.example.co.uk._signal.ns2.example.org

These RRsets are signed with DNSSEC just like any other zone data 💜. Publishing signaling records under the in-domain name _signal.ns3.example.co.uk is not required, so you can skip that one 🙈.

4.2. Validating CDS/CDNSKEY Records for DNSSEC Bootstrapping

Time for the validation glow-up ✨. To validate a child's CDS/CDNSKEY RRset for DNSSEC bootstrapping, the parental agent MUST run the following steps. It already knows the child zone name and its NS hostnames, so it's ready to go 👑:

1. Step 1: verify that the child has no DS records published at the parent and that at least one of its nameservers is outside the child domain;
2. Step 2: query the CDS/CDNSKEY RRset at the child zone apex directly from each of the authoritative servers as determined by the delegation's (parent-side) NS RRset, without caching;
3. Step 3: query the CDS/CDNSKEY RRset located at the signaling name under each signaling domain (except those falling within the child domain) using a trusted DNS resolver, and enforce DNSSEC validation 🔥;
4. Step 4: check (separately by record type) that all RRsets retrieved in Steps 2 and 3 have equal contents.

If the above steps succeed without error, the CDS/CDNSKEY RRsets are successfully verified 🎉. The parental agent can then publish the DS RRset, following the precautions in Section 5 of [RFC8078].

The parental agent MUST abort the procedure if an error condition occurs. The big ones are:

• in Step 1: the child is already securely delegated, or it has in-domain nameservers only;
• in Step 2: any failure while retrieving the CDS/CDNSKEY RRset at the child apex from any of the authoritative nameservers;
• in Step 3: any failure to retrieve the CDS/CDNSKEY RRsets at the signaling name under any signaling domain, including a DNSSEC validation failure, or unauthenticated data (AD bit not set) 🙅‍♀️;
• in Step 4: inconsistent responses (for at least one of the types), including an RRset that is empty in one of Steps 2 or 3 but non-empty in the other.

4.2.1. Example

Let's verify the CDS/CDNSKEY RRsets for example.co.uk 🔍. The child delegation's NS records are ns1.example.net, ns2.example.org, and ns3.example.co.uk, and the parental agent does this:

1. checks that the child domain is not yet securely delegated;
2. queries the CDS/CDNSKEY RRsets for example.co.uk directly from ns1.example.net, ns2.example.org, and ns3.example.co.uk (without caching);
3. queries and validates the CDS/CDNSKEY RRsets located at the names below (see Section 3.2; ns3.example.co.uk gets ignored because it's in-domain 🙃):

_dsboot.example.co.uk._signal.ns1.example.net
_dsboot.example.co.uk._signal.ns2.example.org

4. checks that the CDS/CDNSKEY RRsets retrieved in Steps 2 and 3 agree across responses.

If all of these steps succeed, the parental agent can publish a DS RRset that matches the validated CDS/CDNSKEY RRset 💖.

In-domain signaling names don't have a chain of trust at bootstrapping time, so the parental agent doesn't consider them during validation 🥲. That means if all NS hostnames are in-domain, validation can't finish and no DS records get published. Sad, but that's the rule.

4.3. Triggers

Parental agents SHOULD trigger the procedure in Section 4.2 once one of these conditions is met ⭐:

• The parental agent receives a new or updated NS RRset for a child;
• The parental agent receives a notification that the child wants its CDS/CDNSKEY RRset processed;
• The parental agent runs into a signaling record during a proactive, opportunistic scan (for example, daily queries of signaling records for some or all of its delegations);
• The parental agent runs into a signaling record during an NSEC walk or while parsing a signaling zone (for example, when the child DNS operator makes it available via AXFR);
• Any other condition that local policy deems appropriate.

Timer-based triggers, like scans, have undesirable properties when it comes to processing delay and scaling 🐢. On-demand triggers, like notifications, are way better 🚀. Whenever possible, child DNS operators and parental agents are encouraged to use them, which cuts down on both delays and scanning traffic.

Most kinds of discovery, like daily scans of delegations, are based directly on the delegation's NS RRset. In that case, the bootstrapping algorithm in Section 4.2 can use those NS names as is for querying signaling records 🙌.

Some discovery methods don't give reliable knowledge of the delegation's NS RRset, though 😬. For example, when a parental agent discovers signaling names by performing an NSEC walk or a zone transfer of a signaling zone, it MUST NOT assume that a nameserver under whose signaling domain a signaling record appears is actually authoritative for the corresponding child.

So, whenever a list of "bootstrappable domains" comes from somewhere other than the parent directly, the parental agent MUST confirm that the delegation actually contains the nameserver hostname it saw during discovery. It also has to make sure that signaling-record queries only go to the proper set of nameservers listed in the child's delegation from the parent 🛡️.

4.4. Limitations

Because of Step 3 in Section 4.2, DS bootstrapping does not work for fully in-domain delegations 🙁. There's no existing chain of trust to the child domain during bootstrapping. (As a workaround, you can add an out-of-domain nameserver to the initial NS RRset and remove it once bootstrapping is finished. Automation for this is available via CSYNC records; see [RFC7477].)

Fully qualified signaling names must be valid DNS names. The label count and length requirements for DNS names (Section 3.1 of [RFC1035]) mean the protocol doesn't work for unusually long child domain names or NS hostnames 📏.

5. Operational Recommendations 🎀

5.1. Child DNS Operator

It's possible to add CDS/CDNSKEY records and matching signaling records to a zone without the domain owner knowing 👀. To spare domain owners from getting caught off guard by the DS changes that follow, child DNS operators doing this are advised to make it transparent. They can do that by telling the domain owner during zone creation (for example, in a GUI) or by notifying them via email 💌.

When a zone moves to another DNS operator, the old and new child DNS operators need to cooperate for a smooth transition. They can do that with the multi-signer protocols described in [RFC8901] 🤝. If all else fails, the domain owner might have to request removal of all DS records and have the transfer done insecurely (see [INSEC]) 😭.

Signaling domains SHOULD be delegated as standalone zones, so the signaling zone's apex matches the signaling domain (like _signal.ns1.example.net) 🍓. A signaling zone with fewer labels, like example.net, is also allowed for the signaling domain. Still, a zone cut means bootstrapping doesn't need changes to the zone containing the nameserver hostname, which is the cleaner move 🧹.

Once a child DNS operator sees that specific signaling record sets have been processed (for example, by seeing the result in the parent zone), it's advised to remove them 🗑️. That shrinks the signaling zone and makes bulk processing, like zone transfers, way more efficient.

5.2. Parental Agent

To make sure DNSSEC bootstrapping of insecure domains happens on time, we have to avoid stalemates caused by mismatched stale cached records (Step 4 of Section 4.2) 😤. So it is RECOMMENDED that queries into signaling domains run against an (initially) empty resolver cache, or that some other method of getting fresh data from authoritative servers is used ✨.

It is also RECOMMENDED that QNAME minimization [RFC9156] is used when resolving queries for signaling records. That helps guard against certain attacks (see Section 6) 🛡️.

6. Security Considerations 💀

Okay, this section is serious, so buckle up 🫣. The DNSSEC bootstrapping method in this document is based on the approaches described in Section 3 of [RFC8078], but it adds authentication to the CDS/CDNSKEY concept. Its security level is therefore strictly higher than that of the existing approaches in that document (for example, "Accept after Delay") 🔒. Apart from this general improvement, the same Security Considerations apply as in [RFC8078].

The level of rigor in Section 4.2 is needed to prevent publication of an ill-conceived DS RRset, one that's only authorized under a subset of NS hostnames 🚫. This makes sure, for example, that an operator in a multi-homed setup can't enable DNSSEC unless all the other operators agree 🤯.

Also, since the child DNS operator has authoritative knowledge of the child's CDS/CDNSKEY records, it can readily detect fraudulent provisioning of DS records 🕵️‍♀️.

To stop the parents of nameserver hostnames from becoming a single point of failure for a delegation (both for resolution availability and for this protocol's trust model), it's advisable to diversify the path from the root to the child's nameserver hostnames 🌈. For example, different and independently operated TLDs can be used for each one.

If QNAME minimization [RFC9156] is not used when querying for signaling records, an upstream parent of a signaling domain will see those CDS/CDNSKEY queries. It could then respond with an authoritative answer signed with its own key, instead of sending the referral 😱. Enabling QNAME minimization reduces the attack surface for that kind of forgery 🙏.

7. IANA Considerations ✨

Okay, bestie, IANA handled the paperwork 💅 They added two entries to the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552], and both of them point to RFC 9615. Here's the lineup:

                   +=========+============+===========+
                   | RR Type | _NODE NAME | Reference |
                   +=========+============+===========+
                   | CDS     | _signal    | RFC 9615  |
                   +---------+------------+-----------+
                   | CDNSKEY | _signal    | RFC 9615  |
                   +---------+------------+-----------+

                                 Table 1

8. References 📚

8.1. Normative References

These are the must-reads, the ones you need to have down before you even try this 🤓

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014, <https://www.rfc-editor.org/info/rfc7344>.

[RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS", RFC 7477, DOI 10.17487/RFC7477, March 2015, <https://www.rfc-editor.org/info/rfc7477>.

[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from the Parent via CDS/CDNSKEY", RFC 8078, DOI 10.17487/RFC8078, March 2017, <https://www.rfc-editor.org/info/rfc8078>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>.

[RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC 9156, DOI 10.17487/RFC9156, November 2021, <https://www.rfc-editor.org/info/rfc9156>.

[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, <https://www.rfc-editor.org/info/rfc9499>.

8.2. Informative References

These are the extra-credit reads 🦋

[BCP237] Best Current Practice 237, <https://www.rfc-editor.org/info/bcp237>. At the time of writing, this BCP comprises the following:

Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, <https://www.rfc-editor.org/info/rfc9364>.

[INSEC] Hardaker, W., "Intentionally Temporarily Degraded or Insecure", Work in Progress, Internet-Draft, draft-hardaker-dnsop-intentionally-temporary-insec-01, 21 October 2021, <https://datatracker.ietf.org/doc/html/draft-hardaker-dnsop-intentionally-temporary-insec-01>.

[RFC8901] Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D. Blacka, "Multi-Signer DNSSEC Models", RFC 8901, DOI 10.17487/RFC8901, September 2020, <https://www.rfc-editor.org/info/rfc8901>.

Acknowledgements 🫶

Huge thanks to Brian Dickson, Ondřej Caletka, John R. Levine, Christian Elmerot, Oli Schacher, Donald Eastlake, Libor Peltan, Warren Kumari, Scott Rose, Linda Dunbar, Tim Wicinski, Paul Wouters, Paul Hoffman, Peter Yee, Benson Muite, Roman Danyliw, Éric Vyncke, and Joe Abley for reviewing draft proposals and offering comments and suggestions. You all are iconic 👑

Thanks also to Steve Crocker, Hugo Salgado, and Ulrich Wisser for early-stage brainstorming 🧚

Authors' Addresses 🎀

Peter Thomassen deSEC, Secure Systems Engineering (SSE) Berlin Germany Email: peter@desec.io

Nils Wisiol deSEC, Technische Universität Berlin Berlin Germany Email: nils@desec.io