DNSSEC automation
draft-ietf-dnsop-dnssec-automation-05

Domain Name System Operations (dnsop)                          U. Wisser
Internet-Draft                                                     ICANN
Intended status: Standards Track                                S. Huque
Expires: 6 January 2027                                       Salesforce
                                                             J. Stenstam
                                         The Swedish Internet Foundation
                                                             5 July 2026

                           DNSSEC automation
                 draft-ietf-dnsop-dnssec-automation-05

Abstract

   This document describes an algorithm and protocol to automate the
   setup, operations, and decommissioning of Multi-Signer DNSSEC
   [RFC8901] configurations.  To accomplish this, it employs Model 2 of
   the multi-signer specification (where each operator has their own
   distinct KSK and ZSK sets, or CSK sets), management of DS records
   from the parent via CDS/CDNSKEY [RFC8078], and Child-to-Parent
   Synchronization in DNS [RFC7477].

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-dnssec-automation.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 6 January 2027.

Wisser, et al.           Expires 6 January 2027                 [Page 1]
Internet-Draft              DNSSEC automation                  July 2026

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Out-Of-Scope  . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Permanent Multi-Signer Operation  . . . . . . . . . . . .   5
     3.2.  Secure DNS Operator Transition  . . . . . . . . . . . . .   5
   4.  Automation Models . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Centralized . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Decentralized . . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Capabilities  . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Algorithms  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Prerequisites . . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Setting up a new multi-signer group . . . . . . . . . . .   7
     5.3.  A signer joins the multi-signer group . . . . . . . . . .   7
     5.4.  A signer leaves the multi-signer group  . . . . . . . . .   8
     5.5.  A signer performs a ZSK rollover  . . . . . . . . . . . .   9
     5.6.  A signer performs a CSK or KSK rollover . . . . . . . . .   9
     5.7.  Algorithm rollover for the whole multi-signer group . . .  10
   6.  Signers with different algorithms in a multi-signer group . .  11
   7.  Operational Considerations  . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   10. Implementation Status . . . . . . . . . . . . . . . . . . . .  13
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  13
   12. Informative References  . . . . . . . . . . . . . . . . . . .  14
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

Wisser, et al.           Expires 6 January 2027                 [Page 2]
Internet-Draft              DNSSEC automation                  July 2026

1.  Introduction

   [RFC8901] describes the necessary steps and API for a multi-signer
   DNSSEC configuration.  In this document we will combine Model 2 of
   [RFC8901] with [RFC8078] and [RFC7477] to define an automatable
   algorithm for setting up, operating, and decommissioning a multi-
   signer DNSSEC configuration.  Besides steady state multi-signer
   operation, one of the special use cases of this protocol is to enable
   non-disruptive migration of a signed DNS zone from one provider to
   another, which employs a transitory state of a multi-signer
   configuration.

1.1.  Out-Of-Scope

   In order for any multi-signer group to give consistent answers across
   all nameservers, the data contents of the zone also have to be
   synchronized (in addition to infrastructure records like NS, DNSKEY,
   CDS etc).  This content synchronization is out-of-scope for this
   document.

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

   *KSK*

   Key Signing Key: a DNSSEC key used to sign the DNSKEY RRset.

   *ZSK*

   Zone Signing Key: a DNSSEC key used to sign the other RRsets in a
   zone.

   *CSK*

   Combined Signing Key: a single key serving both the KSK and ZSK
   roles.

   *DNSKEY*

   The DNS public key record ([RFC4034]).

   *DS*

Wisser, et al.           Expires 6 January 2027                 [Page 3]
Internet-Draft              DNSSEC automation                  July 2026

   The Delegation Signer record published by the parent ([RFC4034]).

   *CDS/CDNSKEY*

   Child-published records signaling the desired DS state to the parent
   ([RFC7344], [RFC8078]).

   *CSYNC*

   The Child-to-Parent Synchronization record ([RFC7477]).

   *Signer*

   An entity signing a zone

   *Multi-signer Group*

   A group of signers that sign the same zone

   *Controller*

   An entity controlling the multi-signer group.  Used in the
   centralized model.

   *Parent*

   See [RFC8499]

   *Trust mechanism*

   An authenticated channel used to apply control-plane changes (DNSKEY,
   CDS/CDNSKEY, CSYNC, NS) on each signer, possibly mediated by the zone
   owner or a controller.  The detailed mechanism is out of scope for
   this document.

   *DS-Wait-Time*

   Once the parent has picked up and published the new DS record set,
   any further changes MUST be delayed until the new DS set has
   propagated.

   The minimum DS-Wait-Time is the TTL of the DS RRset.

   *DNSKEY-Wait-Time*

   Once the DNSKEY sets of all signers are updated, any further changes
   MUST be delayed until the new DNSKEY set has propagated.

Wisser, et al.           Expires 6 January 2027                 [Page 4]
Internet-Draft              DNSSEC automation                  July 2026

   The minimum DNSKEY-Wait-Time is the maximum of all DNSKEY TTL values
   from all signers plus the time it takes to publish the zone on all
   secondaries.

   *NS-Wait-Time*

   Once the parent has picked up and published the new NS record set,
   any further changes MUST be delayed until the new NS set has
   propagated.

   The minimum NS-Wait-Time is the maximum of the TTL value of the NS
   set in the parent zone and all NS sets from all signers.

   *RRSIG-Wait-Time*

   Once a signer stops signing zone data with a key, that key MUST
   remain published in the DNSKEY RRsets of all signers until the
   signatures it generated have expired from resolver caches.  Only then
   can the key be removed.

   The minimum RRSIG-Wait-Time is the time it takes to publish the zone
   on all secondaries plus the maximum TTL of any zone data signed by
   that key.

3.  Use Cases

   In this document we describe, except for the initial trust, how the
   steps in the multi-signer DNSSEC setup can be automated.

   The following two use cases are in the scope of this document.

3.1.  Permanent Multi-Signer Operation

   This is the typical use case described in [RFC8901], where multiple
   DNS providers are used to cooperatively serve a DNS zone, each
   signing independently with their own keys, in a steady state
   configuration to increase availability.

3.2.  Secure DNS Operator Transition

   Changing the nameserver operator of a DNSSEC signed zone can be
   challenging.  Currently the most common method is temporarily "going
   insecure".  This is poor for security, and for users relying on the
   security of the zone.  Furthermore, when DNSSEC is being used for
   application security functions like DANE [RFC6698], it is critical
   that the DNSSEC chain of trust remain unbroken during the transfer.

Wisser, et al.           Expires 6 January 2027                 [Page 5]
Internet-Draft              DNSSEC automation                  July 2026

   Multi-signer DNSSEC Model 2 provides a mechanism for transitioning
   from one nameserver operator to another without "going insecure".  A
   new operator joins the current operator in a temporary multi-signer
   group.  Once that is accomplished and stable, the old operator leaves
   the multi-signer group, completing the transition.

4.  Automation Models

   Automation of the necessary steps can be categorized into two main
   models, centralized and decentralized.  Both have pros and cons, and
   a zone owner should carefully choose the model that works best.

4.1.  Centralized

   In a centralized model a controller executes all steps necessary and
   controls all signers.

   The controller needs to have authorized access to all signers.  This
   can be achieved in a variety of different ways.  For example, many
   service providers offer access through a REST API.  Another
   possibility is access through Dynamic Update [RFC2136] with TSIG
   authentication.

4.2.  Decentralized

   In the decentralized model all signers communicate with each other
   and execute the necessary steps on their own instance.  For this,
   signers need a specialized protocol to communicate configuration
   details that are not part of the zone data.

4.3.  Capabilities

   In order for any of the models to work, the signer must support the
   following capabilities.

   1.  Add DNSKEY records (without the private key)

   2.  Remove (previously added) DNSKEY record(s)

   3.  Add CDS and CDNSKEY records for keys not in the DNSKEY set

   4.  Remove (previously added) CDS and CDNSKEY records

   5.  Add CSYNC record

   6.  Remove CSYNC record

Wisser, et al.           Expires 6 January 2027                 [Page 6]
Internet-Draft              DNSSEC automation                  July 2026

5.  Algorithms

   In a centralized model it is the controller's task to compute all
   waiting times and control the zone in a way that all timing
   restrictions are met.

   In the decentralized model every signer must compute all waiting
   times and adhere to all timing restrictions.

   In both methods, some of the timing restrictions must be specified as
   part of the configuration data.

5.1.  Prerequisites

   Each signer to be added, including the initial signer, must meet the
   following prerequisites before joining the multi-signer group:

   1.  A working setup of the zone, including DNSSEC signing.

   2.  Uses the same algorithms for DNSSEC signing as the multi-signer
       group uses or will use.

   3.  Signer or controller must be able to differentiate between its
       own keys and keys from other signers.

   4.  Signer or controller must be able to differentiate between NS
       records that are updated by itself and NS records that receive
       updates from other signers.

   5.  Typically automated updates to the DS and NS records in the
       parent zone require the parent zone to employ scanning of the
       CDS/CDNSKEY/CSYNC records in its child zones.  Alternatively, the
       use of the Generalized NOTIFY [RFC9859] mechanism could be
       employed.  If neither of these options is available, updates to
       the parent zone need to be made manually.

5.2.  Setting up a new multi-signer group

   The zone is already authoritatively served by one DNS operator and is
   DNSSEC signed.  For full automation, both the KSK and ZSK (or CSK)
   must be online.

   This can be viewed as an initial state where the multi-signer group
   has only one signer.  The group is then grown to its intended size by
   applying the procedure in Section 5.3 to add each additional signer.

5.3.  A signer joins the multi-signer group

Wisser, et al.           Expires 6 January 2027                 [Page 7]
Internet-Draft              DNSSEC automation                  July 2026

   1.   Confirm that the incoming signer meets the prerequisites.

   2.   Establish a trust mechanism between the multi-signer group and
        the signer.

   3.   Add the zone-data-signing key (ZSK, or CSK) of each signer to
        the DNSKEY RRsets of all the other signers.

   4.   Calculate CDS/CDNSKEY Records for all KSKs/CSKs represented in
        the multi-signer group.

   5.   Configure all signers with the compiled CDS/CDNSKEY RRset.

   6.   Wait for Parent to publish the combined DS RRset, based on
        observation of the CDS/CDNSKEY RRsets.

   7.   Remove CDS/CDNSKEY Records from all signers. (optional)

   8.   Wait for the maximum of DS-Wait-Time and DNSKEY-Wait-Time.

   9.   Compile NS RRset including all NS records from all signers.

   10.  Configure all signers with the compiled NS RRset.

   11.  Compare NS RRset of the signers to the Parent.  If there is a
        difference, publish a CSYNC record with the NS bit set on all
        signers.  The A and AAAA bits are also set if any of the
        nameservers are in-domain and thus require glue address records
        at the Parent.

   12.  Wait for Parent to publish updates to the delegating NS RRset
        based on observation of the CSYNC RRsets.

   13.  Remove CSYNC record from all signers. (optional)

5.4.  A signer leaves the multi-signer group

   1.   Remove exiting signer's NS records from remaining signers

   2.   Compare NS RRset of the signers to the Parent.  If there is a
        difference, publish a CSYNC record with the NS bit set on the
        remaining signers.  The A and AAAA bits are also set if any of
        the nameservers are in-domain and thus require glue address
        records at the Parent.

   3.   Wait for Parent to publish NS RRset.

   4.   Remove CSYNC record from all signers. (optional)

Wisser, et al.           Expires 6 January 2027                 [Page 8]
Internet-Draft              DNSSEC automation                  July 2026

   5.   Wait for NS-Wait-Time.

   6.   Stop the exiting signer from answering queries.

   7.   Calculate CDS/CDNSKEY Records for KSKs/CSKs published by the
        remaining signers.

   8.   Configure remaining signers with the compiled CDS/CDNSKEY RRset.

   9.   Wait for RRSIG-Wait-Time, measured from when the exiting signer
        stopped answering queries, so that any zone data it signed has
        expired from resolver caches.

   10.  Remove ZSK/CSK of the exiting signer from remaining signers.

   11.  Wait for Parent to publish the updated DS RRset.

   12.  Remove CDS/CDNSKEY set from all signers.  (Optional)

5.5.  A signer performs a ZSK rollover

   1.  The signer introduces the new ZSK in its own DNSKEY RRset.

   2.  Update all signers with the new ZSK.

   3.  Wait for DNSKEY-Wait-Time.

   4.  Signer can start using the new ZSK, and stops signing with the
       old ZSK.

   5.  Wait for RRSIG-Wait-Time, so that data signed with the old ZSK
       has expired from resolver caches.  The old ZSK MUST remain
       published in the DNSKEY RRsets of all signers until then.

   6.  Remove the old ZSK from the signer's own DNSKEY RRset, and from
       the DNSKEY RRsets of all other signers.

5.6.  A signer performs a CSK or KSK rollover

   1.   Signer publishes new CSK / KSK in its own DNSKEY RRset.

   2.   In the case of a CSK, add CSK to DNSKEY set of all other
        signers.

   3.   Signer signs DNSKEY RRset with old and new CSK / KSK.

   4.   Calculate new CDS/CDNSKEY RRset and publish on all signers.

Wisser, et al.           Expires 6 January 2027                 [Page 9]
Internet-Draft              DNSSEC automation                  July 2026

   5.   Wait for Parent to pick up and publish the new DS RRset.

   6.   Wait for DS-Wait-Time + DNSKEY-Wait-Time.

   7.   In the case of a CSK, additionally wait for RRSIG-Wait-Time, so
        that zone data signed with the old CSK has expired from resolver
        caches.  (This is not required for a KSK-only rollover, since a
        KSK signs only the DNSKEY RRset, which is covered by DNSKEY-
        Wait-Time.)

   8.   Signer removes old CSK/KSK from its DNSKEY RRset, and removes
        all signatures made with this key.

   9.   In the case of a CSK, remove old CSK from DNSKEY set of all
        other signers.

   10.  Calculate new CDS/CDNSKEY RRset and publish on all signers.

   11.  Wait for Parent to pick up and publish the new DS RRset.

   12.  Remove CDS/CDNSKEY RRsets from all signers.

5.7.  Algorithm rollover for the whole multi-signer group

   1.   All signers publish KSK and ZSK or CSK using the new algorithm.

   2.   All signers sign all zone data with the new keys, while
        retaining the signatures made with the old-algorithm keys, so
        that the zone data is signed with both algorithms throughout the
        rollover (as required by Section 2.2 of [RFC4035]).

   3.   Wait until all signers have signed all data with the new key(s).

   4.   Add new ZSK of each signer to all other signers.

   5.   Calculate new CDS/CDNSKEY RRset and publish on all signers.

   6.   Wait for Parent to pick up and publish the new DS RRset.

   7.   Wait for DS-Wait-Time + DNSKEY-Wait-Time.

   8.   Wait for RRSIG-Wait-Time, so that any data signed only with the
        old-algorithm keys has expired from resolver caches.

   9.   Remove all keys and signatures that use the old algorithm.

   10.  Calculate new CDS/CDNSKEY RRset and publish on all signers.

Wisser, et al.           Expires 6 January 2027                [Page 10]
Internet-Draft              DNSSEC automation                  July 2026

   11.  Wait for Parent to pick up and publish the new DS RRset.

   12.  Remove CDS/CDNSKEY RRsets from all signers.

6.  Signers with different algorithms in a multi-signer group

   Only when all signers use the same algorithm(s) can all resolvers
   validate zone data with consistency.

   This section tries to summarize why that is the case and what trade-
   offs can be made in situations where using the same algorithm isn't
   possible.

   Section 2.2 of [RFC4035] requires that there be an RRSIG for each
   RRset using at least one DNSKEY of each algorithm in the zone apex
   DNSKEY RRset, and that the apex DNSKEY RRset itself be signed by each
   algorithm appearing in the DS RRset at the delegating parent.  A
   setup where different signers use different key algorithms, each
   signing only with its own algorithm, therefore violates [RFC4035].

   According to Section 5.11 of [RFC6840] validators SHOULD NOT insist
   that all algorithms signaled in the DS RRset work, and they MUST NOT
   insist that all algorithms signaled in the DNSKEY RRset work.

   So a multi-signer setup where different signers use different key
   algorithms should still validate.

   This could be an acceptable risk in situations where going insecure
   is undesirable or impossible, and nameservers must be changed between
   operators that only support disjoint sets of key algorithms.

   We have to consider the following scenarios:

   *Validator supports both algorithms*

   Validation should be stable through all stages of the multi-signer
   algorithms.

   *Validator supports none of the algorithms*

   The validator will treat the zone as unsigned.  Resolution should
   work through all stages of the multi-signer algorithms.

   *Validator supports only one of the algorithms*

Wisser, et al.           Expires 6 January 2027                [Page 11]
Internet-Draft              DNSSEC automation                  July 2026

   The validator will not be able to validate the DNSKEY RRset or any
   data from one of the signers, and will typically retry other
   nameservers for the zone until it can find another signer that it
   does recognize, or return a SERVFAIL response code otherwise.

   The latter scenario can be mitigated by selecting only well-supported
   algorithms.  [MULTI-ALG-RULES] proposes to formally define such
   "universal" algorithms and sanction such configurations.

7.  Operational Considerations

   Full automation of the procedures described in this document depends
   on all of the relevant parties -- the signers, the zone owner or
   controller, and the Parent -- supporting the protocol mechanisms
   these procedures rely on.  Several of these mechanisms are not yet
   universally implemented or deployed.  On the Parent side, automated
   management of DS records requires the Parent to perform CDS/CDNSKEY
   scanning (or to accept Generalized NOTIFY [RFC9859] signaling), and
   automated updates of the delegation's NS records require CSYNC
   scanning; neither is offered by every registry or registrar today.
   On the signer side, not all DNS providers support the ability to
   import and publish the DNSKEY and CDS/CDNSKEY records of the other
   signers in the group, as required by the capabilities in Section 4.3.
   Where a required mechanism is unavailable, the corresponding step
   must be performed by other means, typically a manual update, until
   support becomes available.  A multi-signer group can still operate in
   such an environment, but with manual steps interposed where
   automation is not yet possible.

   Several steps require waiting for the Parent to publish updated DS or
   NS RRsets in response to CDS/CDNSKEY or CSYNC records (or Generalized
   NOTIFY signaling).  The timing of this publication is controlled by
   the Parent, not by the multi-signer group, and depends on the
   Parent's scanning cadence or notification handling.  The Parent MAY
   also decline to act, for example if the CDS/CDNSKEY records do not
   satisfy the Parent's acceptance policy (see [RFC8078]).
   Implementations MUST NOT proceed to subsequent steps until the
   expected DS or NS RRset change is observed at the Parent, and SHOULD
   bound each such wait with a timeout after which the operation is
   flagged for operator attention rather than continuing.  A premature
   transition to a later step, particularly one that removes a key or
   signature, while the Parent still publishes the old delegation can
   break the chain of trust and cause resolution failures.

8.  IANA Considerations

   This document has no IANA actions.

Wisser, et al.           Expires 6 January 2027                [Page 12]
Internet-Draft              DNSSEC automation                  July 2026

9.  Security Considerations

   Multi-signer DNSSEC inherits the security considerations of
   [RFC7477], [RFC8078] and [RFC8901].

   Every step of the multi-signer algorithms has to be carefully
   executed at the right time.  Failures could result in the loss of
   resolution for the domain.

   Independent of the chosen model, it is crucial that only authorized
   entities are able to change the zone data.  Some providers or
   software installations allow finer-grained configuration of which
   changes are permitted.  Access to modify zone data should be
   restricted as much as possible.

   Multi-signer configurations can strengthen DNS security by avoiding a
   DNS zone "going insecure" during a DNS operator transition.  A steady
   state multi-signer configuration can also greatly strengthen
   availability by having multiple distinct DNS providers cooperatively
   serving the same signed zone.  A catastrophic failure of any single
   provider then cannot take down the zone.

10.  Implementation Status

   The Swedish Internet Foundation has implemented a centralized
   controller that supports updates via Dynamic DNS or the REST APIs of
   several vendors.

   The code can be found as part of the multi-signer project on GitHub
   https://github.com/DNSSEC-Provisioning/multi-signer-controller

11.  Normative References

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

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/info/rfc4034>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <https://www.rfc-editor.org/info/rfc4035>.

Wisser, et al.           Expires 6 January 2027                [Page 13]
Internet-Draft              DNSSEC automation                  July 2026

   [RFC6840]  Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
              Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
              DOI 10.17487/RFC6840, February 2013,
              <https://www.rfc-editor.org/info/rfc6840>.

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

   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", RFC 8499, DOI 10.17487/RFC8499, January
              2019, <https://www.rfc-editor.org/info/rfc8499>.

12.  Informative References

   [MULTI-ALG-RULES]
              Huque, S., Thomassen, P., Dukhovni, V., Wessels, D., and
              C. Elmerot, "Multiple Algorithm Rules in DNSSEC",
              <https://datatracker.ietf.org/doc/html/draft-huque-dnsop-
              multi-alg-rules>.

   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, DOI 10.17487/RFC2136, April 1997,
              <https://www.rfc-editor.org/info/rfc2136>.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
              2012, <https://www.rfc-editor.org/info/rfc6698>.

Wisser, et al.           Expires 6 January 2027                [Page 14]
Internet-Draft              DNSSEC automation                  July 2026

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

   [RFC9859]  Stenstam, J., Thomassen, P., and J. Levine, "Generalized
              DNS Notifications", RFC 9859, DOI 10.17487/RFC9859,
              September 2025, <https://www.rfc-editor.org/info/rfc9859>.

Appendix A.  Acknowledgements

   The authors would like to thank the following for their review of
   this work and their valuable comments: Steve Crocker, Eric Osterweil,
   Roger Murray, Jonas Andersson, Peter Thomassen.

Authors' Addresses

   Ulrich Wisser
   ICANN
   Email: ulrich@wisser.se

   Shumon Huque
   Salesforce
   Email: shuque@gmail.com

   Johan Stenstam
   The Swedish Internet Foundation
   Email: johan.stenstam@internetstiftelsen.se

Wisser, et al.           Expires 6 January 2027                [Page 15]