RFC 10026

Operational Recommendations for DNSSEC Delegation Signer (DS) Automation

๐Ÿ“… published July 2026, from ietf

RFC 10026: Operational Recommendations for DNSSEC Delegation Signer (DS) Automation ๐ŸŽ€

Okay bestie, this one is a Best Current Practice, so it's BCP 246 ๐ŸŒธ. It's written by S. Sheng and P. Thomassen (both from deSEC), it was published by the Internet Engineering Task Force (IETF) in July 2026, and it's ISSN 2070-1721 โœจ. The header doesn't list anything it obsoletes or updates, so nothing gets replaced or patched here ๐Ÿซถ.

Abstract โœจ

Okay so, letting a Parental Agent (often a registry or registrar) automatically accept DNSSEC Delegation Signer (DS) parameters from the Child DNS operator, using [RFC7344], [RFC8078], and [RFC9615], means it has to make a bunch of technical calls. Those include acceptance checks, error and success reporting, and multi-party stuff like concurrent updates ๐Ÿ’…. This document is basically the best-practice guide for handling all of that.

Status of This Memo โœจ

This memo documents an Internet Best Current Practice ๐ŸŒˆ.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication ๐Ÿซถ. If you want more info on BCPs, check out Section 2 of RFC 7841.

For the current status, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc10026 ๐Ÿ’Œ.

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 read these carefully, because they describe your rights and restrictions for 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 they're provided without warranty as described in the Revised BSD License ๐Ÿ”’.

Table of Contents ๐Ÿงš

   1.  Introduction
   2.  Terminology
     2.1.  Requirements Notation
   3.  Recommendations for Deployments of DS Automation
   4.  Acceptance Checks and Safety Measures
     4.1.  Recommendations
     4.2.  Analysis
       4.2.1.  Continuity of Resolution
       4.2.2.  Timing, TTLs, and Caching
       4.2.3.  CDS vs. CDNSKEY
   5.  Reporting and Transparency
     5.1.  Recommendations
     5.2.  Analysis
   6.  Registration Locks
     6.1.  Recommendations
     6.2.  Analysis
       6.2.1.  Registrar vs. Registry Lock
       6.2.2.  Detailed Rationale
   7.  Multiple Submitting Parties and Suspension of Automation
     7.1.  Recommendations
     7.2.  Analysis
       7.2.1.  Necessity of Non-Automatic Updates
       7.2.2.  Impact of Non-Automatic Updates: When to Suspend
               Automation
       7.2.3.  Concurrent Automatic Updates
   8.  IANA Considerations
   9.  Operational Considerations
   10. Security Considerations
   11. References
     11.1.  Normative References
     11.2.  Informative References
   Appendix A.  Recommendations Overview
     A.1.  Acceptance Checks and Safety Measures
     A.2.  Reporting and Transparency
     A.3.  Registration Locks
     A.4.  Multiple Submitting Parties and Suspension of Automation
   Acknowledgments
   Authors' Addresses

1. Introduction ๐Ÿฆ‹

Okay so [RFC7344], [RFC8078], and [RFC9615] are the protocols that automate DNSSEC [RFC9364] delegation trust maintenance. They do this by having the child publish Child DS (CDS) and/or Child DNSKEY (CDNSKEY) records, which show the delegation's desired DNSSEC parameters. That's what we mean by "DS automation" ๐Ÿ’–.

Parental Agents using these protocols have to make a bunch of technical decisions about acceptance checks, timing, error reporting, locks, and more ๐Ÿ˜ญ. Plus, when you're using the registrant-registrar-registry (RRR) model (which is super common across top-level domains (TLDs)), both the registrar and the registry can make parent-side changes to the delegation. So now there are even more chances for implementations to differ ๐Ÿ™ˆ.

Not every existing DS automation deployment has made the same choices on these questions, so the behavior is kinda inconsistent. From a domain holder's point of view, with domain names under different TLDs, that can be unexpected and confusing ๐Ÿ’€.

In the sections that follow, each operational question comes first, followed by its matching recommendations. Each section ends with an analysis of those recommendations and related considerations. You'll find a combined view of all the recommendations in Appendix A โœจ.

Readers are expected to already know their DNSSEC stuff from [RFC9364], [RFC9615], [RFC9859], and [RFC9975] ๐Ÿง .

The core issues in this document come from Section 4.4 of [SAC126]. If you want more background, check out that report ๐Ÿ“š.

2. Terminology ๐ŸŒธ

The term "Parental Agent" is used as defined in Section 1.1 of [RFC7344]. This document also uses terms defined in [RFC9499], in particular:

  • DNS operator
  • Registry
  • Registrant
  • Registrar

It also uses these terms:

  • Child zone: DNS zone whose delegation is in the Parent zone.
  • Child (DNS operator): DNS operator responsible for a Child zone.
  • Parent zone: DNS zone that holds a delegation for a Child zone.
  • Parent: The operator responsible for a Parent zone, and therefore involved in maintaining the delegation's DNSSEC parameters. This especially covers accepting those parameters and publishing the matching DS records ๐Ÿซถ.
  • RRR Model: The registrant-registrar-registry (RRR) interaction framework. Registrants work with a registrar to register and manage domain names, and registrars work with the domain's registry to provide and manage domain names on the registrant's behalf. This model is common across TLDs ๐ŸŒˆ.

2.1. Requirements Notation ๐Ÿ“œ

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document should be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in ALL CAPS, just like here ๐Ÿ”ฅ.

3. Recommendations for Deployments of DS Automation ๐Ÿ’…

The guidelines for deploying DS automation in this document are all about getting more uniform treatment across suffixes. The goal is to minimize user surprise and provide baseline safety and consistent behavior. They also exist to prevent disruption of DNS and DNSSEC functionality ๐Ÿซถ. At a minimum, compliance with this RFC requires support for both DNSSEC bootstrapping [RFC9615] and subsequent updates [RFC7344] [RFC8078], following the implementation guidance below โœจ.

The recommendations are there to optimize interoperability and safety. In some cases, local policy can take precedence, for example when a registry is subject to national cryptographic policy requirements. But if you don't follow a requirement marked with the "SHOULD" key word, you'll generally get undesirable effects like ambiguity and interoperability issues ๐Ÿ˜ฌ. When implementing these recommendations, operators MUST mitigate issues that come from any particular deviation ๐Ÿ›ก๏ธ.

Registries with additional requirements on DS update checks MAY implement any extra checks that line up with local policy ๐Ÿ’œ.

4. Acceptance Checks and Safety Measures โœจ

This section gives recommendations for these operational questions:

  • What kind of acceptance checks should be performed on DS parameters?
  • Should these checks be performed upon acceptance or also continually when in place?
  • How do TTLs and caching impact DS provisioning? How important is timing in a child key change?
  • Are parameters for DS automation best conveyed as CDNSKEY or CDS records or both?

4.1. Recommendations ๐ŸŽ€

  1. Entities performing automated DS maintenance MUST verify: a. the unambiguous intent of each DS bootstrapping or update request as per [RFC9975], by checking its consistency both
    • between any published CDS and CDNSKEY records, and
    • across all authoritative nameservers in the delegation, and b. that the resulting DS record set would allow continued DNSSEC validation if deployed

and cancel the update if the verifications do not succeed.

  1. Parent-side entities (such as registries) SHOULD allow for effective rollback. They do this by reducing a DS record set's TTL to a value between 5-15 minutes when a new set of records is published. Later, they restore the previous (or, if that's unavailable, default) TTL value, but not before the previous DS RRset's TTL has expired ๐ŸŒท.

Besides picking a sensible TTL, prompt DS changes also need timely discovery of update requests. For the recommended methods, see Section 4.2.2 โฐ.

  1. DNS operators MUST publish both CDNSKEY and CDS records (unless the parent's preference is known), and they should follow best practice for choosing the hash digest type [DS-IANA] ๐Ÿ“.

4.2. Analysis ๐Ÿ”

4.2.1. Continuity of Resolution ๐Ÿซง

To keep the basic resolution function working, it's really critical to avoid deploying flawed DS record sets in the Parent zone ๐Ÿ˜ค. So it's necessary for the Parent to verify that the DS record set coming from an automated (or even manual) update won't break DNSSEC validation if it gets deployed. If it would, the Parent should cancel the update ๐Ÿ’….

This is best achieved by:

  1. verifying that consistent CDS/CDNSKEY responses are served by all of the delegation's nameservers [RFC9975];
  2. verifying that the resulting DS Resource Record set (RRset) doesn't break the delegation if applied ([RFC7344], Section 4.1). That means it gives validators at least one valid path to use ([RFC6840], Section 5.11). This is the case if the child's DNSKEY RRset has a valid RRSIG signature from a key that's referenced by at least one DS record, with the digest type and signing algorithm values designated as "RECOMMENDED" or "MUST" in the "Use for DNSSEC Validation" columns of the relevant IANA registries ([DS-IANA] and [DNSKEY-IANA]). Note that these checks don't need to be enforced when you provision DS records manually to enable other digest types or algorithms for potentially non-interoperable purposes ๐Ÿงช.

Even when no update has been requested, Parents may occasionally check whether the current DS contents would still be acceptable if they were newly submitted in CDS/CDNSKEY form (see Section 4) ๐Ÿ”. Any failures, like a missing DNSKEY caused by improper rollover timing ([RFC6781], Section 4.1) or changed algorithm requirements, can then be reported as described in Section 5.1. The existing DS RRset doesn't get changed or removed in that case ๐ŸŒˆ.

4.2.2. Timing, TTLs, and Caching โฐ

okay so timing is everything for DS provisioning requests, bestie ๐Ÿ’… you need to find them reasonably quickly. The best way to do that is for the Child DNS operator to send an [RFC9859] notification to the parent (Sections 4.1 and 4.2 of [RFC9859]). Publishing the notification targets isn't enough on its own, though. The advertised endpoint also has to actually listen (Sections 3 and 4.3 of [RFC9859]). By explicitly naming a responsible endpoint, this method also resolves potential contention between registry and registrar when the RRR model is used (see Section 7.2.3). Note that periodic scanning is a suboptimal alternative, ngl, because it introduces policy-dependent delays and does not scale well for large zones ๐Ÿ™ˆ

To further reduce the impact of any misconfigured DS record set (whether it came from automation or from manual provisioning ๐Ÿ’€), the option to quickly roll back the delegation's DNSSEC parameters is literally so important ๐Ÿ”ฅ. The trick is setting a comparatively low TTL on the DS record set in the parent domain. The tradeoff is reduced resiliency against nameserver unreachability, because cached records expire earlier. The availability risk can be mitigated by limiting those TTLs to a brief time period after a change to the DS configuration, which is when rollbacks are most likely to occur โœจ

So registries therefore should significantly lower the DS RRset's TTL for some time following bootstrapping or an update. Pragmatic values for the reduced TTL range between 5-15 minutes ๐Ÿฆ‹ Using values below 5 minutes risks excessive queries, and using values greater than 15 minutes may impact recovery from operational mistakes.

Note that recent measurements have demonstrated low TTLs like the above to have negligible impact on the overall load of a registry's authoritative nameserver infrastructure [LowTTL]. Not gonna lie, that's a very reassuring plot twist ๐ŸŒธ

The reduction should be in effect at least for a couple of days and until the previous DS record set has expired from caches, i.e., the period during which the low-TTL is applied typically will significantly exceed the normal TTL value. When using the Extensible Provisioning Protocol (EPP) [RFC5730], the domain <info> command described in Section 2.1.1.2 of [RFC9803] can be used by the registrar to obtain the registry's TTL policy ๐Ÿ“‹

the low TTL is a rollback button, not a speed button ๐Ÿ”ฅ

While this approach enables quick rollbacks, timing of the desired DS update process itself is largely governed by the previous DS RRset's TTL. It therefore does not generally benefit from an overall speed-up. Note also that nothing is gained from first lowering the TTL of the old DS RRset: such an additional step would, in fact, require another wait period while resolver caches adjust. For the sake of completeness, there likewise is no point to increasing any DS TTL values beyond their normal value ๐Ÿ™ƒ

4.2.3. CDS vs. CDNSKEY ๐ŸฅŠ

DS records can be generated from information provided either in DS format (CDS) or in DNSKEY format (CDNSKEY). The format of CDS records is identical to that of DS records, so the record data can be taken verbatim. Generating a DS record from CDNSKEY information, on the other hand, involves computing a hash ๐Ÿงฎ

Whether a Parent processes CDS or CDNSKEY records depends on their preference:

  • Processing (and storing) CDNSKEY information allows the Parent to control the choice of hash algorithms. The Parent may then unilaterally regenerate DS records with a different choice of hash algorithm(s) whenever deemed appropriate.
  • Processing CDS information allows the Child DNS operator to control the hash digest type used in DS records, enabling the Child DNS operator to deploy (for example) experimental hash digests and removing the need for registry-side changes when additional digest types become available.

The need to make a choice in the face of this dichotomy is not specific to DS automation. Even when DNSSEC parameters are relayed to the Parent through conventional channels, the Parent has to make some choice about which format(s) to accept ๐Ÿคทโ€โ™€๏ธ

As there exists no protocol for Child DNS operators to discover a Parent's input format preference, interoperability requires publication of both CDNSKEY as well as CDS records, in line with Section 5 of [RFC7344]. The choice of hash digest type should follow current best practice [DS-IANA].

Publishing the same information in two different formats is not ideal, I know ๐Ÿ˜ญ Still, it is much less complex and costly than burdening the Child DNS operator with discovering each Parent's current policy. Also, it is very easily automated. Operators should ensure that published RRsets are consistent with each other ๐Ÿซถ

If both RRsets are published, Parents are expected to verify consistency between them by verifying that they refer to the same set of keys [RFC9975]. By not second-guessing inconsistencies (such as by RRset recency) and instead rejecting them, responsibility to clearly express each update request is placed on the Child DNS operator. Main character energy for the operator, honestly ๐Ÿ‘‘

CDS records need only be considered for CDNSKEY consistency when their digest type field is designated as "MUST" in the "Implement for DNSSEC Delegation" column of the "Digest Algorithms" registry [DS-IANA]. Consistency of records with other digest types need not be verified, especially when the digest type is unsupported; such records can be ignored. Note that this does not imply a restriction on the DS hash digest types. If no inconsistencies are found, the parent can publish DS records with whatever digest type(s) it prefers ๐ŸŒˆ

5. Reporting and Transparency ๐Ÿ“ฃ

This section provides recommendations to address the following operational question:

  • Should a failed (or even successful) DS update trigger a notification to anyone?

5.1. Recommendations ๐Ÿ’Œ

  1. For certain DS updates (see analysis (Section 5.2)) and for DS deactivation, relevant points of contact known to the parent-side entity (registry or registrar) SHOULD be notified.
  2. For error conditions, the child DNS operator and the domain's technical contact (if applicable) SHOULD be notified first. The registrant SHOULD NOT be notified unless the problem persists for a prolonged amount of time (e.g., three days) ๐Ÿ™ˆ
  3. Child DNS operators SHOULD be notified of errors using a report query [RFC9567] to the agent domain as described in Section 4 of [RFC9859]. Note that this requires listening to notifications and that appropriate notification targets are in place (Section 3 of [RFC9859]).

Notifications to humans (domain holder) will be performed in accordance with the communication preferences established with the parent-side entity. The same condition SHOULD NOT be reported unnecessarily frequently to the same recipient ๐Ÿ“จ

  1. In the RRR model, registries performing DS automation SHOULD inform the registrar of any DS record changes via the EPP Change Poll Extension [RFC8590] or a similar channel.
  2. The currently active DS configuration SHOULD be made accessible to the registrant (or their designated party) through the customer portal available for domain management. The DS update history MAY be made available in the same way ๐Ÿฆ‹

5.2. Analysis ๐Ÿ”

okay so when a DS update gets accepted or rejected, it is a big mistake to assume everyone knows what's happening ๐Ÿ’€. A registrar might have no idea the registry just did an automatic DS update ๐Ÿ™ˆ. And a Child DNS operator might not notice that their CDS/CDNSKEY RRsets are out of sync across nameservers, so they get ignored and nobody says a word ๐Ÿ˜ฉ.

So to keep everyone in the loop ๐Ÿซถ, entities doing automated DS maintenance should report the conditions they run into. These success situations are lowkey the most interesting:

  1. A DS RRset has been provisioned: a. manually; b. due to commencing DS automation (either via DNSSEC bootstrapping or for the first time after a manual change; see Section 7); c. automatically, as an update to an existing DS RRset that had itself been automatically provisioned.
  2. The DS RRset has been removed: a. manually; b. automatically, using a delete signal ([RFC8078], Section 4).

Then there are the error conditions that are absolutely worth reporting ๐Ÿšจ:

  1. A pending DS update cannot be applied due to an error condition. There are a bunch of situations where an automated DS update gets requested but can't actually be fulfilled. These include: a. The new DS record set would break validation/resolution or is not acceptable to the Parent for some other reason (see Section 4). b. A lock prevents DS automation (see Section 6).
  2. No DS update is due, but it was determined that the Child zone is no longer compatible with the existing DS record set (e.g., DS RRset only references non-existing keys).

For those last two cases, the entity doing DS automation would be justified in trying to communicate the situation ๐Ÿ’Œ. Potential recipients are:

  • Child DNS operator, preferably by making a report query [RFC9567] to the agent domain listed in the EDNS0 Report-Channel option of the DS update notification that triggered the DS update ([RFC9859], Section 4) or else via email to the address contained in the Child zone's SOA RNAME field (see Sections 3.3.13 and 8 of [RFC1035]);
  • Registrar (if DS automation is performed by the registry);
  • Registrant (domain holder; in non-technical language, such as "DNSSEC security for your domain has been enabled and will be maintained automatically"), or technical contact, in accordance with the communication preferences established with the parent-side entity.

For manual updates (case 1a), commencing DS automation (case 1b), and deactivating DNSSEC (case 2), it seems worthwhile to notify both the domain's technical contact (if applicable) and the registrant โœจ. This will typically lead to one notification during normal operation of a domain. (Case 1c, the regular operation of automation, is not an interesting condition to report to a human ๐Ÿ˜ด.)

For error conditions (cases 3 and 4), the registrant doesn't always need to be involved ๐Ÿ™Œ. It seems advisable to first notify the domain's technical contact and the DNS operator serving the affected Child zone. Only if the problem persists for a prolonged amount of time (e.g., three days) should you notify the registrant.

When the RRR model is used and the registry performs DS automation, the registrar should always stay informed of any DS record changes, e.g., via the EPP Change Poll Extension [RFC8590] ๐Ÿ“ฌ.

Overly frequent reporting of the same condition to the same recipient is discouraged (e.g., no more than twice in a row) ๐Ÿ™…โ€โ™€๏ธ. For example, when CDS and CDNSKEY records are inconsistent and prevent DS initialization, the registrant may be notified twice. Additional notifications may be sent with some back-off mechanism (in increasing intervals), so nobody gets spammed into oblivion.

The registrant (or their designated party) should be able to retrieve the current DS configuration through the customer portal available for domain management ๐Ÿ’ป. Failing to give the registrant a way to inspect the current configuration after it has changed may hinder recovery from operational incidents, because the registrant may have out-of-date information. That's a whole mess ๐Ÿ˜ญ.

Ideally, the history of DS updates would also be available ๐Ÿ—‚๏ธ. However, due to the associated state requirements and the lack of direct operational impact, implementing this is optional. If the registry supports it, the DS TTL currently in effect can be obtained using the RDAP TTL extension [RDAP-TTL].

For troubleshooting, dispute resolution, and post-incident analysis, it is instrumental for the Parental Agent to retain structured records of each DS automation decision ๐Ÿ“. That means keeping the timestamp, the triggering CDS/CDNSKEY RRsets, the notification channel, the authoritative nameservers consulted, the verification results, the decision outcome, and either the applied DS RRset or the cancellation reason.

6. Registration Locks ๐Ÿ”

This section provides recommendations to address the following operational question:

  • How does DS automation interact with other registration state parameters, such as registration locks?

6.1. Recommendations ๐Ÿ“‹

  1. To secure ongoing operations, automated DS maintenance MUST NOT be suspended based on a registrar update lock alone (such as EPP status clientUpdateProhibited [RFC5731]).
  2. When performed by the registry, automated DS maintenance MUST NOT be suspended based on a registry update lock alone (such as EPP status serverUpdateProhibited [RFC5731]).

6.2. Analysis ๐Ÿง 

Registries and registrars can set various types of locks for domain registrations, usually upon the registrant's request ๐Ÿ™‹โ€โ™€๏ธ. An overview of standardized locks using EPP is given in Section 2.3 of [RFC5731], for example. Some registries may offer additional (or other) types of locks, and their meaning and set/unset mechanisms are defined according to a proprietary policy.

While some locks clearly should have no impact on DS automation (such as transfer or deletion locks), other types of locks, in particular "update locks", deserve a closer look ๐Ÿ”Ž.

6.2.1. Registrar vs. Registry Lock ๐Ÿ”’

A registrar-side update lock (such as clientUpdateProhibited in EPP) protects against various types of accidental or malicious change, like unintended changes through the registrar's customer portal ๐Ÿ›ก๏ธ. Its security model does not prevent the registrar's (nor the registry's) actions. That's because a registrar-side lock can be removed by the registrar without an out-of-band interaction.

Under that security model, no tangible security benefit is gained by blocking automated DS maintenance based on a registrar lock alone. Blocking it would only make maintenance needlessly difficult ๐Ÿ˜ค. It is therefore not justified to suspend automation when such a lock is present.

When a registry-side update lock is in place, the registrar cannot apply any changes (for security or delinquency or other reasons) ๐Ÿšซ. However, it does not protect against changes made by the registry itself. This is exemplified by the serverUpdateProhibited EPP status, which demands only that the registrar's "[r]equests to update the object [...] MUST be rejected" (Section 2.3 of [RFC5731]). This type of lock therefore precludes DS automation by the registrar, while registry-side automation remains unaffected.

DS automation by the registry is consistent with Section 2.3 of [RFC5731], which explicitly notes that an EPP server (registry) may override status values set by an EPP client (registrar), subject to local server policies. The risk that DS changes from registry-side automation might go unnoticed by the registrar is mitigated by sending change notifications to the registrar; see Recommendation 4 of Section 5 ๐Ÿ“ฃ.

6.2.2. Detailed Rationale ๐Ÿ“–

Pre-DNSSEC, a registration could be set up once, then locked and left alone with no maintenance required ๐Ÿฆ‹. DNSSEC changed that operational model: the configuration may have to be maintained in order to stay secure and operational. For example, the Child DNS operator may switch to another signing algorithm if the previous one is no longer deemed appropriate, or roll its Secure Entry Point (SEP) key for other reasons. Such changes entail updating the delegation's DS records.

If authenticated, these operations don't count as accidental or malicious changes. They're legitimate and normal activity for keeping things secure ๐Ÿ’ช. The CDS/CDNSKEY method provides an automatic, authenticated means to convey DS bootstrapping and update requests [RFC9615] [RFC7344]. The resulting operation is subject to the parent's acceptance checks. In particular, it is not applied when it would break the delegation (see Section 4) โœ….

Registrar locks protect against unintended changes (such as through the customer portal), but they don't prevent actions done by the registrar (or the registry) itself. So such a lock isn't suitable for defending against actions performed illegitimately by the registrar or registry (e.g., due to compromise) ๐Ÿ•ต๏ธ. Any attack on the registration data that is feasible in the presence of a registrar lock is also feasible regardless of whether DS maintenance is done automatically. In other words, DS automation is orthogonal to the attack vector that a registrar lock protects against.

Considering that automated DS bootstrapping and update requests are required to be authenticated and validated for correctness, honoring such requests is in the registrant's interest ๐Ÿฅฐ. Doing so comes with no additional associated risk compared to other authenticated update methods. Suspending automated DS maintenance therefore is not justified.

Following this line of thought, at the time of writing, some registries (e.g., .ch/.cz/.li) perform automated DS maintenance even when an "update lock" is in place ๐Ÿ‡จ๐Ÿ‡ญ. Registries offering proprietary locks should carefully consider, for each lock, whether its scope warrants suspension.

For a domain not yet secured with DNSSEC, automatic DS initialization is not required to maintain ongoing operation. However, authenticated DNSSEC bootstrapping [RFC9615] might be requested. Besides being in the interest of security, the fact that a Child is requesting DS initialization through an authenticated method expresses the registrant's intent to have the delegation secured ๐ŸŽ€.

Some domains also come with an update lock by default ๐Ÿ™ƒ. Not honoring DNSSEC bootstrapping requests then puts an additional burden on the registrant, who has to unlock and relock the domain in order to get DS provisioning going after registration. That's a needless cost, especially for large domain portfolios. It's also unexpected, since the registrant already arranged for the necessary CDS/CDNSKEY records to be published. DS initialization and rollovers therefore should be treated the same way with respect to locks ๐Ÿ‘‘.

7. Multiple Submitting Parties and Suspension of Automation ๐ŸŽญ

This section provides recommendations to address the following operational questions:

  • How are conflicts resolved when DS parameters are accepted through multiple channels (e.g., via a conventional channel and via automation)?
  • In case both the registry and the registrar are automating DS provisioning, how are potential collisions resolved?

7.1. Recommendations ๐Ÿ’…

Okay bestie, here are the five golden rules ๐Ÿ‘‘

  1. Registries and registrars MUST provide another (e.g., manual) channel for DS maintenance ๐Ÿ”‘, so that recovery is possible when the Child has lost access to its signing key(s). This out-of-band channel is also needed when a DNS operator does not support DS automation or refuses to cooperate ๐Ÿ™ˆ.
  2. DS bootstrapping and update requests MUST be executed at the next publication opportunity after their authenticity has been verified โœจ. This applies whether they arrive in-band or through an out-of-band channel.
  3. When processing a CDS/CDNSKEY "delete" signal to remove the entire DS record set ([RFC8078], Section 4), DS automation MUST NOT be suspended ๐Ÿฆ‹. For all other removal requests (such as ones received via EPP or a web form), DS automation SHOULD be suspended until a new DS record set has been provisioned. The point is to prevent accidental re-initialization when the registrant actually meant to disable DNSSEC ๐Ÿซถ.
  4. Whenever a non-empty DS record set is provisioned, through whichever channel, DS automation SHOULD NOT (or no longer) be suspended, including after an earlier removal ๐ŸŒธ.
  5. In the RRR model, a registry MUST NOT automatically initialize DS records when it is known that the registrar does not provide a way for the domain holder to later disable DNSSEC ๐Ÿšซ. If the registrar has declared that it performs automated DS maintenance, the registry SHOULD publish the registrar's notification endpoint [RFC9859] (if applicable) instead of its own, and refrain from registry-side DS automation ๐Ÿ’œ.

7.2. Analysis ๐Ÿ”

In the RRR model, there are multiple channels through which DS parameters can be accepted:

  • The registry can retrieve information about an intended DS provisioning request automatically from the Child DNS operator and apply it directly โšก.
  • The registrar can retrieve the same information and relay it to the registry ๐Ÿ“จ.
  • The registrar can obtain the information from the registrant through another channel (such as a non-automated "manual update" via web form submission) and relay it to the registry ๐Ÿงš.

There are several considerations in this context, as discussed in the following subsections. Let's get into it ๐ŸŽ€.

7.2.1. Necessity of Non-Automatic Updates

Under special circumstances, it may be necessary to perform a non-automatic DS update ๐Ÿ˜ฌ. One important example is when the key used for authentication of DS updates is destroyed. In that case, an automatic key rollover is impossible, because the Child DNS operator can no longer authenticate the associated information ๐Ÿ’€. Another example is when several providers are involved, but one of them no longer cooperates (e.g., when removing a provider from a multi-provider setup). Disabling all other DS management interfaces therefore poses significant operational risk ๐Ÿšจ.

Similarly, when the registrar is known to not support DNSSEC (especially to not provide a means to remove a DS RRset), registries are cautioned against automatically initializing DS records ๐Ÿ™…โ€โ™€๏ธ. The reason is to prevent situations in which a misconfigured or undesired DS RRset cannot be repaired by the registrant.

7.2.2. Impact of Non-Automatic Updates: When to Suspend Automation

When an out-of-band (e.g., manual) DS update is performed while CDS/CDNSKEY records referencing the previous DS RRset's keys are still present, the delegation's DS records may be reset to their previous state at the next run of the automation process ๐Ÿ˜ฑ. This section discusses in which situations it is appropriate to suspend DS automation after such a non-automatic update.

One option is to suspend DS automation after a manual DS update, but only until a resumption signal is observed. In the past, it was proposed that seeing an updated SOA serial in the Child zone may serve as a resumption signal. However, any arbitrary modification of zone contents, including the regular updating of DNSSEC signature validity timestamps, typically causes an SOA serial change. So resuming DS automation after a serial change comes with a high risk of surprise ๐Ÿ™€. Additional issues arise if nameservers have different serial offsets (e.g., in a multi-provider setup). This practice therefore is NOT RECOMMENDED. ๐Ÿšซ

Note also that "automatic rollback" due to old CDS/CDNSKEY RRsets can only occur if they are signed with a key authorized by one of the new DS records. Acceptance checks described in Section 4 further ensure that updates do not break validation ๐Ÿ›ก๏ธ.

Removal of a DS record set is triggered either through a CDS/CDNSKEY "delete" signal observed by the party performing the automation ([RFC8078], Section 4), or by receiving a removal request out-of-band (e.g., via EPP or a web form). In the first case, the registrant can expect automation to be kept active for the delegation, to facilitate later DS bootstrapping ๐ŸŒˆ. In the second case, it is likely that the registrant intends to disable DNSSEC for the domain, so DS automation is best suspended (until a new DS record is provisioned somehow) ๐Ÿซ .

One may ask how a registry can know whether a removal request received via EPP was the result of the registrar observing a CDS/CDNSKEY "delete" signal. It turns out the registry does not need to know that. In fact, the advice works out nicely regardless of who does the automation ๐Ÿช„:

  • a. Only registry: If the registry performs automation, then the registry will consider any request received from the registrar as out-of-band (in the context of this automation). When such requests demand removal of the entire DS record set, the registry therefore should suspend automation.
  • b. Only registrar: The registrar can always distinguish between removal requests obtained from a CDS/CDNSKEY "delete" signal and other registrant requests, and can suspend automation as appropriate ๐Ÿง .
  • c. In the (undesirable) case that both parties automate, there are two cases:
    • If the registrant submits a manual removal request to the registrar, it is out-of-band from the registrar's perspective (e.g., web form) and also for the registry (e.g., EPP). As a consequence, both will suspend automation, which is the correct result โœ….
    • If a CDS/CDNSKEY "delete" signal causes the registrar to request DS removal from the registry, then the registry will suspend automation, because the removal request is received out-of-band (such as via EPP). This is independent of whether the registry's automation has already seen the signal. The registrar, however, will be aware of the in-band nature of the request and will not suspend automation, which is also the correct result ๐Ÿ‘.

As a side effect, this works towards avoiding redundant automation at the registry โœจ.

All in all:

  • It is advisable to generally not suspend in-band DS automation when an out-of-band DS update has occurred ๐ŸŒท.
  • An exception to this rule is when the entire DS record set was removed through an out-of-band request. In that case, the registrant likely wants to disable DNSSEC for the domain, so DS automation should be suspended so that automatic re-initialization (bootstrapping) does not occur ๐Ÿ™….
  • In all other cases, any properly authenticated DS updates received, including through an automated method, are to be considered the current intent of the domain holder ๐Ÿ’–.

7.2.3. Concurrent Automatic Updates

When the RRR model is used, there is a potential for collision if both the registry and the registrar are automating DS provisioning by scanning the child for CDS/CDNSKEY records ๐Ÿ‘ฏ. No disruptive consequences are expected if both parties perform DS automation. An exception is when, during a key rollover, the registry and registrar see different versions of the Child's DS update requests, such as when CDS/CDNSKEY records are retrieved from different vantage points. Although unlikely due to Recommendation 1a of Section 4, this may lead to flapping of DS updates. However, it is not expected to be harmful, as either DS RRset will allow the validation function to continue working, as ensured by Recommendation 1b of Section 4 ๐Ÿ›Ÿ. The effect subsides as the Child's state eventually becomes consistent (roughly within the child's replication delay). Any flapping until then will be a minor nuisance only ๐Ÿ˜Œ.

The issue disappears entirely when scanning is replaced by notifications that trigger DS maintenance through one party's designated endpoint [RFC9859]. It can otherwise be mitigated if the registry and registrar agree that only one of them will perform scanning ๐Ÿค.

As a standard aspect of key rollovers [RFC6781], the Child DNS operator is expected to monitor propagation of Child zone updates to all authoritative nameserver instances. It should only proceed to the next step once replication has succeeded everywhere and the DS record set was subsequently updated, and in no case before the DS RRset's TTL has passed โณ. Any breakage resulting from improper timing on the Child side is outside the Parent's sphere of influence, and thus cannot be handled with only parent-side changes ๐Ÿ™ƒ.

8. IANA Considerations ๐ŸŽ€

This document has no IANA actions.

9. Operational Considerations ๐Ÿ› ๏ธ

The document provides operational recommendations for DNSSEC DS automation. There are no additional operational considerations beyond those listed in Appendix A.

10. Security Considerations ๐Ÿšจ

The recommendations in this document are designed to improve the safety and interoperability of DNSSEC delegation maintenance. Relevant security implications and various trade-offs are explained in the analysis subsections above. This section notes additional aspects worth considering ๐Ÿ‘€.

When inconsistencies between CDS/CDNSKEY RRsets are ignored (contrary to Recommendation 4.1.1.a), a number of security risks result. For example, when a nameserver domain expires and is re-registered maliciously, the adversary may be able to initialize a DS RRset and subsequently redelegate the domain using CSYNC synchronization [RFC7477], resulting in a full hijack of the domain ๐Ÿ˜ญโ˜ ๏ธ. For details, refer to Appendix A of [RFC9975].

Similar risks of total adversarial control exist when the child's SEP key is compromised, as this key can authorize DS update or removal requests if it is consistently published on all nameservers. This reinforces that loss of key control poses severe risks, so utmost care must be taken when managing SEP keys ๐Ÿ”.

When a domain is stripped of its DNSSEC protection by removing the DS RRset, either manually or using an automatic delete signal (Recommendation 7.1.3), DNSSEC security guarantees and associated benefits are no longer in effect. For example, an email operator may enforce DNS-Based Authentication of Named Entities (DANE) [RFC7672] for domains previously observed to support it and, as a result, experience a service disruption in email delivery ๐Ÿ“ญ. Both child and parent DNS operators MUST take such service disruptions into account when considering removal of the DS RRset for their zone. ๐Ÿ’…

11. References ๐Ÿ“š

11.1. Normative References ๐Ÿ“šโœจ

Bestie, these are the references the spec leans on hard ๐Ÿซถ

11.2. Informative References ๐Ÿง ๐ŸŒธ

Extra-credit reading for the curious. Not required to get the gist, but so worth a peek ๐Ÿฆ‹

Appendix A. Recommendations Overview ๐Ÿ“‹๐Ÿ’…

Quick recap time! Every recommendation from this document, reproduced here with zero extra commentary. Want the backstory and analysis? Head to Sections 4-7 ๐Ÿงš

A.1. Acceptance Checks and Safety Measures ๐Ÿ›ก๏ธ

  1. Entities performing automated DS maintenance MUST verify:
    • a. the unambiguous intent of each DS bootstrapping or update request as per [RFC9975], by checking its consistency both
      • between any published CDS and CDNSKEY records and
      • across all authoritative nameservers in the delegation,
    • and
    • b. that the resulting DS record set would allow continued DNSSEC validation if deployed

and cancel the update if the verifications do not succeed.

  1. Parent-side entities (such as registries) SHOULD allow for effective rollback by reducing a DS record set's TTL to a value between 5-15 minutes when a new set of records is published, and restore the previous (or, if unavailable, default) TTL value at a later occasion (but not before the previous DS RRset's TTL has expired).

Besides a prudent choice of TTL, prompt DS changes also require timely discovery of update requests. For recommended methods, see Section 4.2.2.

  1. DNS operators MUST publish both CDNSKEY and CDS records (unless the parent's preference is known) and follow best practice for the choice of hash digest type [DS-IANA].

A.2. Reporting and Transparency ๐Ÿ“ฃ

  1. For certain DS updates (see analysis (Section 5.2)) and for DS deactivation, relevant points of contact known to the parent-side entity (registry or registrar) SHOULD be notified.
  2. For error conditions, the child DNS operator and the domain's technical contact (if applicable) SHOULD be notified first. The registrant SHOULD NOT be notified unless the problem persists for a prolonged amount of time (e.g., three days).
  3. Child DNS operators SHOULD be notified of errors using a report query [RFC9567] to the agent domain as described in Section 4 of [RFC9859]. Note that this requires listening to notifications and that appropriate notification targets are in place (Section 3 of [RFC9859]).

Notifications to humans (domain holder) will be performed in accordance with the communication preferences established with the parent-side entity. The same condition SHOULD NOT be reported unnecessarily frequently to the same recipient.

  1. In the RRR model, registries performing DS automation SHOULD inform the registrar of any DS record changes via the EPP Change Poll Extension [RFC8590] or a similar channel.
  2. The currently active DS configuration SHOULD be made accessible to the registrant (or their designated party) through the customer portal available for domain management. The DS update history MAY be made available in the same way.

A.3. Registration Locks ๐Ÿ”’

  1. To secure ongoing operations, automated DS maintenance MUST NOT be suspended based on a registrar update lock alone (such as EPP status clientUpdateProhibited [RFC5731]).
  2. When performed by the registry, automated DS maintenance MUST NOT be suspended based on a registry update lock alone (such as EPP status serverUpdateProhibited [RFC5731]).

A.4. Multiple Submitting Parties and Suspension of Automation ๐ŸŽ€

  1. Registries and registrars MUST provide another (e.g., manual) channel for DS maintenance in order to enable recovery when the Child has lost access to its signing key(s). This out-of-band channel is also needed when a DNS operator does not support DS automation or refuses to cooperate.
  2. DS bootstrapping and update requests MUST be executed at the next publication opportunity after verification of their authenticity, regardless of whether they are received in-band or via an out-of-band channel.
  3. When processing a CDS/CDNSKEY "delete" signal to remove the entire DS record set ([RFC8078], Section 4), DS automation MUST NOT be suspended. For all other removal requests (such as when received via EPP or a web form), DS automation SHOULD be suspended until a new DS record set has been provisioned, in order to prevent accidental re-initialization when the registrant intended to disable DNSSEC.
  4. Whenever a non-empty DS record set is provisioned, through whichever channel, DS automation SHOULD NOT (or no longer) be suspended (including after an earlier removal).
  5. In the RRR model, a registry MUST NOT automatically initialize DS records when it is known that the registrar does not provide a way for the domain holder to later disable DNSSEC. If the registrar has declared that it performs automated DS maintenance, the registry SHOULD publish the registrar's notification endpoint [RFC9859] (if applicable) instead of their own and refrain from registry-side DS automation.

Acknowledgments ๐Ÿซถ

The authors would like to thank the members of ICANN's Security and Stability Advisory Committee (SSAC) who wrote the [SAC126] report on which this document is based.

Additional thanks are extended to the following individuals (in the order of their first contribution or review): Barbara Jantzen, Matt Pounsett, Matthijs Mekking, Ondล™ej Caletka, Oli Schacher, Kim Davies, Jim Reid, Q Misell, Scott Hollenbeck, Tamรกs Csillag, Philip Homburg, Shumon Huque (Document Shepherd), Libor Peltan, Josh Simpson, Johan Stenstam, Stefan Ubbink, Viktor Dukhovni, Hugo Salgado, Wes Hardaker, Mohamed Boucadair (responsible Area Director), Meir Goldman, Thomas Fossati, Peter van Dijk, Jiankang Yao, Donald Eastlake, James Gannon, Roman Danyliw, Andy Newton, ร‰ric Vyncke, Mike Bishop, Mahesh Jethanandani, Deb Cooley, Charles Eckel, Christopher Inacio, and Ketan Talaulikar.

Authors' Addresses โœ‰๏ธ

Steve Sheng Email: steve.sheng@gmail.com

Peter Thomassen deSEC Email: peter@desec.io

๐Ÿ“ฆ where this page comes from