RFC 8078

Managing DS Records from the Parent via CDS/CDNSKEY

📅 published March 2017, from ietf

RFC 8078: Managing DS Records from the Parent via CDS/CDNSKEY 🎀

Part 1 of 2 💅

Okay bestie, so this is RFC 8078 💖. It's called Managing DS Records from the Parent via CDS/CDNSKEY. O. Gudmundsson (CloudFlare) and P. Wouters (Red Hat) wrote it. It's a Standards Track doc (ISSN 2070-1721) from March 2017 🗓️. It updates RFC 7344, and it's the one that finally pushes 7344 up to Standards Track 🚀.

Abstract ✨

RFC 7344 explains how DNS trust can survive key rollovers, done in-band between parent and child 🔑. This doc bumps 7344 from Informational to Standards Track 🎉. It also adds a way to set up initial trust and to remove a secure entry point, which is honestly iconic 👑.

Changing a domain's DNSSEC status is messy. There can be a bunch of unrelated parties involved, and some of them (like the DNS operator) might not even be known to everyone else in the mix 🙈. Not being able to turn DNSSEC off with in-band signaling is seen as a liability, and it's a big reason DNSSEC hasn't spread at a large scale 😭. So this doc adds in-band signaling for those status changes 🫶.

It also describes some reasonable policies that make it easier to accept new secure entry points (DS records) the first time 🌸.

Ideally, operators work together when a domain moves or transfers 🤝. The best method is a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that's not possible, the unsigned intermediate state described here can move the domain between two parties 🦋. Yes, the domain is temporarily unsigned and open to DNS spoofing, but that's still preferred over validation failures from a mismatched DS and DNSKEY record 💀.

Status of This Memo 🧾

This is an Internet Standards Track document 🔥.

It's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 💜. More info on Internet Standards is in Section 2 of RFC 7841 🍓.

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc8078 🌈.

Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) as they stand on the publication date. Read those carefully, since they spell out your rights and restrictions for this document 🧐. Code Components pulled from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 📜.

Table of Contents 📚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Introducing a DS Record . . . . . . . . . . . . . . . . .   3
  1.2.  Removing a DS Record  . . . . . . . . . . . . . . . . . .   4
  1.3.  Notation  . . . . . . . . . . . . . . . . . . . . . . . .   4
  1.4.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
2.  The Three Uses of CDS . . . . . . . . . . . . . . . . . . . .   5
  2.1.  The Meaning of the CDS RRset  . . . . . . . . . . . . . .   5
3.  Enabling DNSSEC via CDS/CDNSKEY . . . . . . . . . . . . . . .   6
  3.1.  Accept Policy via Authenticated Channel . . . . . . . . .   6
  3.2.  Accept with Extra Checks  . . . . . . . . . . . . . . . .   6
  3.3.  Accept after Delay  . . . . . . . . . . . . . . . . . . .   7
  3.4.  Accept with Challenge . . . . . . . . . . . . . . . . . .   7
  3.5.  Accept from Inception . . . . . . . . . . . . . . . . . .   7
4.  DNSSEC Delete Algorithm . . . . . . . . . . . . . . . . . . .   7
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
  6.1.  Promoting RFC 7344 to Standards Track . . . . . . . . . .   9
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction 🎀

CDS (Child DS) and CDNSKEY (Child DNSKEY) records, defined in [RFC7344], are how a child signals changes to its secure entry points 🔐. This is one way to keep delegations up to date, and it's handy when the DNS operator has no other way to tell the parent that something needs to change 💌. This document bumps [RFC7344] from Informational to Standards Track 🚀.

RFC 7344 is missing two things if you want full automated operation 🤖. First, it doesn't define a way to set up initial trust, so every parent has to invent its own acceptance policy 🤷‍♀️. Second, it doesn't have a "delete" signal, which means the child has no way to tell the parent that DNSSEC needs to be removed from its domain 🙅‍♀️.

1.1. Introducing a DS Record 🦋

Automated insertion of DS records has been blocked for a lot of zones by the rule that every change has to go through a "Registry" of the child zone's parent 🚧. That's really slowed DNSSEC deployment at scale for DNS hosters, since the child zone owner is often not aware of the DS record or can't update it 😩.

This document describes a few ways the parent can accept a child's request to add a DS record to its zone 💜. Each method has different security properties for different deployment scenarios, and they all lead to an automated way of introducing trust ✨.

1.2. Removing a DS Record 🧹

This document adds a delete option for both CDS and CDNSKEY, so a child can tell the parent to turn DNSSEC off 🙃. Sometimes, when a domain moves from one DNS operator to another, DNSSEC has to be turned off to make the switch happen 🚚. Common scenarios include:

  1. Doing a proper DNSSEC algorithm rollover is not an option because of operational limits, like software limitations 🛠️.
  2. Moving from a DNSSEC operator to one that can't do DNSSEC 📦.
  3. Moving to an operator that can't or won't do a proper DNSSEC rollover 🙅‍♀️.
  4. Moving between two DNS operators that use disjoint sets of algorithms to sign the zone, where an algorithm rollover can't be performed 🧩.
  5. The domain holder doesn't want DNSSEC enabled anymore 👋.

Not having a "remove my DNSSEC" option is one reason some operators can't deploy DNSSEC at all, because they see it as an operational risk 😬.

Turning off DNSSEC lowers the security of the domain, so it should only be done carefully, and the child domain should be fully in charge of that decision 🔒.

1.3. Notation 📝

Signaling can happen with CDS or CDNSKEY records 📡. The only differences between them are how the information is represented and who calculates the DS digest 🧮. To keep things clear, this document uses "CDS" to mean "either CDS or CDNSKEY" 💅.

When this document says "parent", it means an entity that's authorized to insert DS records into the parent zone on behalf of the child domain 👑. It doesn't matter exactly which entity that is. It could be the Registrar or Reseller the child domain was bought from, or the Registry where the domain is registered when that's allowed, or some other entity entirely 🌍.

1.4. Terminology 💬

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 [RFC2119] 🧠.

2. The Three Uses of CDS 🔑

Generally, a domain wants its parent to do one of three things 📋:

  1. Enable DNSSEC validation, which means placing an initial DS Resource Record Set (RRset) in the parent 🎉.
  2. Roll over the KSK. This means updating the DS records in the parent so they match the new set of KSKs at the child 🔄. This could be an ADD operation, a DELETE operation on one or more records while keeping at least one DS RR, or a full REPLACE operation 🧩.
  3. Turn off DNSSEC validation, which means deleting all the DS records 🙈.

KSK rollover is covered in [RFC7344], and it's considered the safest use of a CDS/CDNSKEY record because it doesn't change the trust relationship between parent and child 🛡️. Introducing and removing DS records are defined in this document. Since these CDS/CDNSKEY use cases create or end the trust relationship between parent and child, they should be carefully implemented and monitored 👀.

2.1. The Meaning of the CDS RRset 💌

Publishing a CDS RRset means something specific 📣:

Publishing a CDS or CDNSKEY record signals to the parent that the child desires that the corresponding DS records be synchronized. Every parent or parental agent should have an acceptance policy for these records covering the three use cases: Initial DS publication, Key rollover, and Returning to Insecure.

In short, the CDS RRset is a request telling the parent to update the DS RRset whenever the CDS and DS RRsets differ 🫶.

For a key rollover, the acceptance policy for CDS is "seeing", according to [RFC7344]. For a Delete, the acceptance policy is seeing a validly signed CDS RRset that uses the delete operation specified in this document ✨.

3. Enabling DNSSEC via CDS/CDNSKEY 🚀

There are a number of different models for managing initial trust, but in the general case the child wants global validation enabled 🌐. Until the child is signed, DNS answers can be forged, so the goal is to move the child from insecure to secure as soon as reasonably possible for the parent 🏃‍♀️. That means the gap between the child publishing its CDS/CDNSKEY RRset and the parent publishing the synchronized DS RRset should be as short as possible ⏱️.

One big use case is a third-party DNS operator uploading its DNSSEC information to the parent, so the parent can publish a DS record for the child 📤. In that case, there's a chance to set up some kind of authentication mechanism and submission mechanism, but that's outside the scope of this document 🔐.

Below are some policies parents can use. These policies assume the notifications can be verified or authenticated ✅.

3.1. Accept Policy via Authenticated Channel 🔏

In this case, the parent gets notified through an authenticated channel (UI/API) that a CDS/CDNSKEY RRset exists 📬. For a CDS RRset, the parent retrieves it and inserts the corresponding DS RRset as requested 📥. For CDNSKEY, the parent retrieves the CDNSKEY RRset and calculates the DS record(s) 🧮. Parents may limit the DS record type based on local policy 🎛️.

Parents SHOULD NOT refuse CDS/CDNSKEY updates that don't (yet) have a matching DNSKEY in the child zone 🙅‍♀️. This lets the child pre-publish a spare DNSKEY, which could even be kept offline 🧊✨.

3.2. Accept with Extra Checks ✨

okay so this one is giving "trust but verify, bestie" 🫶 The parent checks that the source of the notification is allowed to request the DS insertion 🔍 The checks could include stuff like whether this is a trusted entity, whether the nameservers match up with the requester, whether there have been any changes in registration in the last few days, etc. 💅 The parent can also send a notification asking for a confirmation, like emailing the registrant to ask "hey, did you mean this?" 📧 The end result is that the CDS RRset gets accepted once the checks are done or when that out-of-band confirmation comes back ✅ And any extra checks should have proper rate limiting in place to prevent abuse 🚦 no cap, that part is so important 🔥

3.3. Accept after Delay 🕰️

In this case, if the parent decides the request is valid, it starts keeping an eye on the CDS RRset at the child nameservers over a period of time to make sure nothing changes 👀 After some time, or after a number of checks, ideally from different vantage points in the network 🌍, the parent accepts the CDS RRset as a valid signal to update its DS RRset for this child 🎀

3.4. Accept with Challenge 🧩

In this case, the parent tells the requester to insert some record into the child domain to prove they have the ability to do so (basically, that they are the operator of the zone) 🔐 This method gives the parent a new job: monitoring the child zone to see if the challenge has been added 📋 The parent should verify that the challenge is published by all of the child's nameservers 🖥️ and should test for this challenge from various diverse network locations to make the security of this method as strong as possible 💪 it's giving fortress energy 🏰

3.5. Accept from Inception 🐣

If a parent is adding a new child domain that isn't delegated at all yet, it could use the child CDS/CDNSKEY RRset to publish a DS RRset right away, along with the new NS RRset 🚀 This would make sure the new child domain is never active in an insecure state 🛡️ main character debut, honestly 👑

4. DNSSEC Delete Algorithm 🗑️

This document defines the previously reserved DNS Security Algorithm Number of value 0 in the context of CDS and CDNSKEY records to mean that the entire DS RRset at the parent must be removed 🧹 The value 0 stays reserved for the DS and DNSKEY records 🔒

No DNSSEC validator can treat algorithm 0 as a valid signature algorithm 🙅‍♀️ If a validator sees a DNSKEY or DS record with this algorithm value, it MUST treat it as unknown. Accordingly, the zone is treated as unsigned unless there are other algorithms present 🫥 In general, the value 0 should never be used in the context of DNSKEY and DS records 🚫

The CERT record [RFC4398] defines the value 0 similarly, to mean the algorithm in the CERT record is not defined in DNSSEC 📜

The contents of the CDS or CDNSKEY RRset MUST contain one RR and only contain the exact fields shown below 💖

CDS 0 0 0 0

CDNSKEY 0 3 0 0

The keying material payload is represented by a single 0 🔢 This record is signed in the same way as regular CDS/CDNSKEY RRsets are signed ✍️

Strictly speaking, the CDS record could be CDS X 0 X 0, since only the DNSKEY algorithm is what signals the DELETE operation 🤓 But for clarity, the "0 0 0 0" notation is MANDATED. This is not a definition of DS digest algorithm 0 🙅‍♀️ The same argument applies to CDNSKEY 0 3 0 0, where the value 3 in the second field is mandated by [RFC4034], Section 2.1.2 📖

Once the parent has verified the CDS/CDNSKEY RRset and it has passed the other acceptance tests, the parent MUST remove the DS RRset 🗑️ After waiting a sufficient amount of time (depending on the parental TTLs) ⏳, the child can start the process of turning off DNSSEC 🌙

5. Security Considerations 🚨

⚠️ Turning off DNSSEC reduces the security of the domain, so it should only be done as a last resort to prevent DNSSEC validation errors caused by mismatched DS and DNSKEY records. Seriously, bestie, this is not the move unless you've got no other choice 😭

Users should keep in mind that re-establishing trust in a delegation can be hard and takes time ⏰ Before deciding to finish the rollover via an unsigned state, all other options should be considered first 🙏

A parent SHOULD ensure that when it allows a child to become securely delegated, it has reasonable assurance that the CDS/CDNSKEY RRset used to bootstrap the security is visible from a geographically and topologically diverse view 🌐 It SHOULD also ensure that the zone validates correctly if the parent publishes the DS record ✅ A parent zone might also consider emailing its contact addresses to warn the child zone that security will be enabled after a certain amount of wait time, which gives the child administrator a chance to cancel the request 📨

This document describes a few possible acceptance criteria for the initial trust establishment. Due to the large variety of legal frameworks surrounding parent domains (Top-Level Domains (TLDs) in particular), this document cannot give a definitive list of valid acceptance criteria 🌍 Parental zones should look at the listed methods and pick the most secure method possible within their legal and technical scenario, possibly further securing the acceptance criteria 🔐, as long as the deployed method still enables a fully automated method for non-direct parties such as third-party DNS hosters 🤖

6. IANA Considerations 🏛️

IANA has assigned entry number 0 in the "DNS Security Algorithm Numbers" registry as follows 📋

+--------+--------------+----------+----------+---------+-----------+
| Number | Description  | Mnemonic | Zone     | Trans.  | Reference |
|        |              |          | Signing  | Sec.    |           |
+--------+--------------+----------+----------+---------+-----------+
| 0      | Delete DS    | DELETE   | N        | N       | [RFC4034] |
|        |              |          |          |         | [RFC4398] |
|        |              |          |          |         | [RFC8078] |
+--------+--------------+----------+----------+---------+-----------+

6.1. Promoting RFC 7344 to Standards Track 🎓

Experience has shown that CDS and CDNSKEY are useful in the deployment of DNSSEC 🙌 [RFC7344] was published as Informational, and this document elevates RFC 7344 to Standards Track 🚀✨

7. References 📚

7.1. Normative References

7.2. Informative References

Acknowledgments 🫶

We thank a number of people who gave feedback and useful comments, including Bob Harold, John Levine, Dan York, Shane Kerr, Jacques Latour, and especially Matthijs Mekking 💜

Authors' Addresses 💌

Olafur Gudmundsson CloudFlare

Email: olafur+ietf@cloudflare.com

Paul Wouters Red Hat

Email: pwouters@redhat.com 🦋

📦 where this page comes from