doc: Add RFC documents

1 files changed, 618 insertions, 0 deletions

diff --git a/doc/rfc/rfc9615.txt b/doc/rfc/rfc9615.txt
new file mode 100644
index 0000000..563fb59
--- /dev/null
+++ b/doc/rfc/rfc9615.txt
@@ -0,0 +1,618 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                      P. Thomassen
+Request for Comments: 9615       deSEC, Secure Systems Engineering (SSE)
+Updates: 7344, 8078                                            N. Wisiol
+Category: Standards Track           deSEC, Technische Universität Berlin
+ISSN: 2070-1721                                                July 2024
+
+
+  Automatic DNSSEC Bootstrapping Using Authenticated Signals from the
+                            Zone's Operator
+
+Abstract
+
+   This document introduces an in-band method for DNS operators to
+   publish arbitrary information about the zones for which they are
+   authoritative, in an authenticated fashion and on a per-zone basis.
+   The mechanism allows managed DNS operators to securely announce
+   DNSSEC key parameters for zones under their management, including for
+   zones that are not currently securely delegated.
+
+   Whenever DS records are absent for a zone's delegation, this signal
+   enables the parent's registry or registrar to cryptographically
+   validate the CDS/CDNSKEY records found at the child's apex.  The
+   parent can then provision DS records for the delegation without
+   resorting to out-of-band validation or weaker types of cross-checks
+   such as "Accept after Delay".
+
+   This document establishes the DS enrollment method described in
+   Section 4 of this document as the preferred method over those from
+   Section 3 of RFC 8078.  It also updates RFC 7344.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9615.
+
+Copyright Notice
+
+   Copyright (c) 2024 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
+     1.1.  Terminology
+     1.2.  Requirements Notation
+   2.  Updates to RFCs
+   3.  Signaling
+     3.1.  Chain of Trust
+     3.2.  Signaling Names
+   4.  Bootstrapping a DNSSEC Delegation
+     4.1.  Signaling Consent to Act as the Child's Signer
+       4.1.1.  Example
+     4.2.  Validating CDS/CDNSKEY Records for DNSSEC Bootstrapping
+       4.2.1.  Example
+     4.3.  Triggers
+     4.4.  Limitations
+   5.  Operational Recommendations
+     5.1.  Child DNS Operator
+     5.2.  Parental Agent
+   6.  Security Considerations
+   7.  IANA Considerations
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   Securing a DNS delegation for the first time requires that the
+   child's DNSSEC parameters be conveyed to the parent through some
+   trusted channel.  While the communication conceptually has to occur
+   between the parent registry and the DNSSEC key holder, what that
+   means exactly and how communication is coordinated traditionally
+   depends on the relationship the child has with the parent.
+
+   A typical situation is that the key is held by the child DNS
+   operator; thus, the communication often involves this entity.  In
+   addition, depending on the circumstances, it may also involve the
+   registrar, possibly via the registrant (for details, see Appendix A
+   of [RFC7344].
+
+   As observed in [RFC7344], these dependencies often result in a manual
+   process that is susceptible to mistakes and/or errors.  In addition,
+   due to the annoyance factor of the process, involved parties may
+   avoid the process of getting a DS resource record set (RRset)
+   published in the first place.
+
+   To alleviate these problems, automated provisioning of DS records has
+   been specified in [RFC8078].  It is based on the parental agent
+   (registry or registrar) fetching DNSSEC key parameters from the CDS
+   and CDNSKEY records ([RFC7344]) located at the child zone's apex, and
+   validating them somehow.  This validation can be done using the
+   child's existing DNSSEC chain of trust if the objective is to update
+   an existing DS RRset (such as during key rollover).  However, when
+   bootstrapping a DNSSEC delegation, the child zone has no existing
+   DNSSEC validation path, so other means to ensure the CDS/CDNSKEY
+   records' legitimacy must be found.
+
+   Due to the lack of a comprehensive DNS-innate solution, either out-
+   of-band methods have been used so far to complete the chain of trust,
+   or cryptographic validation has been entirely dispensed with, in
+   exchange for weaker types of cross-checks such as "Accept after
+   Delay" (Section 3.3 of [RFC8078]).  [RFC8078] does not define an in-
+   band validation method for enabling DNSSEC.
+
+   This document aims to close this gap by introducing an in-band method
+   for DNS operators to publish arbitrary information about the zones
+   for which they are authoritative, in an authenticated manner and on a
+   per-zone basis.  The mechanism allows managed DNS operators to
+   securely announce DNSSEC key parameters for zones under their
+   management.  The parent can then use this signal to cryptographically
+   validate the CDS/CDNSKEY RRsets found at an insecure child zone's
+   apex and, upon success, secure the delegation.
+
+   While applicable to the vast majority of domains, the protocol does
+   not support certain edge cases, such as excessively long child zone
+   names, or DNSSEC bootstrapping for domains with in-domain nameservers
+   only (see Section 4.4).
+
+   DNSSEC bootstrapping is just one application of the generic signaling
+   mechanism specified in this document.  Other applications might arise
+   in the future, such as publishing operational metadata or auxiliary
+   information that the DNS operator likes to make known (e.g., API
+   endpoints for third-party interaction).
+
+   Readers are expected to be familiar with DNSSEC [BCP237].
+
+1.1.  Terminology
+
+   This section defines the terminology used in this document.
+
+   CDS/CDNSKEY:  This notation refers to CDS and/or CDNSKEY, i.e., one
+      or both.
+
+   Child:  See Section 7 of [RFC9499].
+
+   Child DNS operator:  The entity that maintains and publishes the zone
+      information for the child DNS.
+
+   Parent:  See Section 7 of [RFC9499].
+
+   Parental agent:  The entity that has the authority to insert DS
+      records into the parent zone on behalf of the child.  (It could be
+      the registry, registrar, a reseller, or some other authorized
+      entity.)
+
+   Signaling domain:  A domain name constructed by prepending the label
+      _signal to a hostname taken from a delegation's NS RRset.  There
+      are as many signaling domains as there are distinct NS targets.
+
+   Signaling name:  The labels that are prefixed to a signaling domain
+      in order to identify a signaling type and a child zone's name (see
+      Section 3.2).
+
+   Signaling record:  A DNS record located at a signaling name under a
+      signaling domain.  Signaling records are used by the child DNS
+      operator to publish information about the child.
+
+   Signaling type:  A signal type identifier, such as _dsboot for DNSSEC
+      bootstrapping.
+
+   Signaling zone:  The zone that is authoritative for a given signaling
+      record.
+
+1.2.  Requirements Notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "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.
+
+2.  Updates to RFCs
+
+   The DS enrollment methods described in Section 3 of [RFC8078] are
+   less secure than the method described in Section 4 of this document.
+   Therefore, child DNS operators and parental agents wishing to use
+   CDS/CDNSKEY records for initial DS enrollment SHOULD support the
+   authentication protocol described here.
+
+   In order to facilitate publication of signaling records for the
+   purpose of DNSSEC bootstrapping (see Section 4.1), the first bullet
+   ("Location") of Section 4.1 of [RFC7344] is removed.
+
+3.  Signaling
+
+   This section describes the general mechanism by which a child DNS
+   operator can publish an authenticated signal about a child zone.
+   Parental agents (or any other party) can then discover and process
+   the signal.  Authenticity is ensured through standard DNSSEC
+   validation.
+
+3.1.  Chain of Trust
+
+   If a child DNS operator implements this specification, each signaling
+   zone MUST be signed and be validatable by the parental agent (i.e.,
+   have a valid publicly resolvable DNSSEC chain of trust).  This is
+   typically achieved by securely delegating each signaling zone.
+
+   For example, when publishing a signal that relates to a child zone
+   with NS records ns1.example.net and ns2.example.org, the child DNS
+   operator needs to ensure that the parental agent has a valid DNSSEC
+   chain of trust for the zone(s) that are authoritative for the
+   signaling domains _signal.ns1.example.net and
+   _signal.ns2.example.org.
+
+3.2.  Signaling Names
+
+   To publish information about the child zone in an authenticated
+   fashion, the child DNS operator MUST publish one or more signaling
+   records at a signaling name under each signaling domain.
+
+   Signaling records MUST be accompanied by RRSIG records created with
+   the corresponding signaling zone's key(s).  The type and contents of
+   these signaling records depend on the type of signal.
+
+   The signaling name identifies the child and the signaling type.  It
+   is identical to the child name (with the final root label removed),
+   prefixed with a label containing the signaling type.
+
+4.  Bootstrapping a DNSSEC Delegation
+
+   When the child zone's CDS/CDNSKEY RRsets are used for setting up
+   initial trust, they need to be authenticated.  This is achieved by
+   copublishing the child's CDS/CDNSKEY RRsets as an authenticated
+   signal as described in Section 3.  The parent can discover and
+   validate it, thus transferring trust from the child DNS operator
+   nameservers' chain of trust to the child zone.
+
+   This protocol is not intended for updating an existing DS RRset.  For
+   this purpose, the parental agent can validate the child's CDS/CDNSKEY
+   RRsets directly, using the chain of trust established by the existing
+   DS RRset (Section 4 of [RFC7344]).
+
+4.1.  Signaling Consent to Act as the Child's Signer
+
+   To confirm its willingness to act as the child's delegated signer and
+   authenticate the child's CDS/CDNSKEY RRsets, the child DNS operator
+   MUST copublish them at the corresponding signaling name under each
+   signaling domain, excluding those that would fall within the child
+   domain (Section 3.2).  For simplicity, the child DNS operator MAY
+   also copublish the child's CDS/CDNSKEY RRsets under signaling domains
+   within the child domain, although those signaling domains are not
+   used for validation (Section 4.2).
+
+   Unlike the CDS/CDNSKEY RRsets at the child's apex, a signaling RRset
+   MUST be signed with the corresponding signaling zone's key(s).  Its
+   contents MUST be identical to the corresponding RRset published at
+   the child's apex.
+
+   Existing use of CDS/CDNSKEY records was specified at the child apex
+   only (Section 4.1 of [RFC7344]).  This protocol extends the use of
+   these record types to non-apex owner names for the purpose of DNSSEC
+   bootstrapping.  To exclude the possibility of semantic collision,
+   there MUST NOT be a zone cut at a signaling name.
+
+4.1.1.  Example
+
+   For the purposes of bootstrapping the child zone example.co.uk with
+   NS records ns1.example.net, ns2.example.org, and ns3.example.co.uk,
+   the required signaling domains are _signal.ns1.example.net and
+   _signal.ns2.example.org.
+
+   In the zones containing these domains, the child DNS operator
+   authenticates the CDS/CDNSKEY RRsets found at the child's apex by
+   copublishing them as CDS/CDNSKEY RRsets at the names:
+
+   _dsboot.example.co.uk._signal.ns1.example.net
+   _dsboot.example.co.uk._signal.ns2.example.org
+
+   These RRsets are signed with DNSSEC just like any other zone data.
+
+   Publication of signaling records under the in-domain name
+   _signal.ns3.example.co.uk is not required.
+
+4.2.  Validating CDS/CDNSKEY Records for DNSSEC Bootstrapping
+
+   To validate a child's CDS/CDNSKEY RRset for DNSSEC bootstrapping, the
+   parental agent, knowing both the child zone name and its NS
+   hostnames, MUST execute the following steps:
+
+   Step 1:  verify that the child has no DS records published at the
+            parent and that at least one of its nameservers is outside
+            the child domain;
+
+   Step 2:  query the CDS/CDNSKEY RRset at the child zone apex directly
+            from each of the authoritative servers as determined by the
+            delegation's (parent-side) NS RRset, without caching;
+
+   Step 3:  query the CDS/CDNSKEY RRset located at the signaling name
+            under each signaling domain (except those falling within the
+            child domain) using a trusted DNS resolver and enforce
+            DNSSEC validation;
+
+   Step 4:  check (separately by record type) that all RRsets retrieved
+            in Steps 2 and 3 have equal contents;
+
+   If the above steps succeed without error, the CDS/CDNSKEY RRsets are
+   successfully verified, and the parental agent can proceed with the
+   publication of the DS RRset under the precautions described in
+   Section 5 of [RFC8078].
+
+   The parental agent MUST abort the procedure if an error condition
+   occurs, in particular:
+
+   *  in Step 1: the child is already securely delegated or has in-
+      domain nameservers only;
+
+   *  in Step 2: any failure during the retrieval of the CDS/CDNSKEY
+      RRset located at the child apex from any of the authoritative
+      nameservers;
+
+   *  in Step 3: any failure to retrieve the CDS/CDNSKEY RRsets located
+      at the signaling name under any signaling domain, including
+      failure of DNSSEC validation, or unauthenticated data (AD bit not
+      set);
+
+   *  in Step 4: inconsistent responses (for at least one of the types),
+      including an RRset that is empty in one of Steps 2 or 3, but non-
+      empty in the other.
+
+4.2.1.  Example
+
+   To verify the CDS/CDNSKEY RRsets for the child example.co.uk, the
+   parental agent (assuming that the child delegation's NS records are
+   ns1.example.net, ns2.example.org, and ns3.example.co.uk)
+
+   1.  checks that the child domain is not yet securely delegated;
+
+   2.  queries the CDS/CDNSKEY RRsets for example.co.uk directly from
+       ns1.example.net, ns2.example.org, and ns3.example.co.uk (without
+       caching);
+
+   3.  queries and validates the CDS/CDNSKEY RRsets located at (see
+       Section 3.2; ns3.example.co.uk is ignored because it is in-
+       domain)
+
+      _dsboot.example.co.uk._signal.ns1.example.net
+      _dsboot.example.co.uk._signal.ns2.example.org
+
+   4.  checks that the CDS/CDNSKEY RRsets retrieved in Steps 2 and 3
+       agree across responses.
+
+   If all of these steps succeed, the parental agent can proceed to
+   publish a DS RRset as indicated by the validated CDS/CDNSKEY RRset.
+
+   As in-domain signaling names do not have a chain of trust at
+   bootstrapping time, the parental agent does not consider them during
+   validation.  Consequently, if all NS hostnames are in-domain,
+   validation cannot be completed and DS records are not published.
+
+4.3.  Triggers
+
+   Parental agents SHOULD trigger the procedure described in Section 4.2
+   once one of the following conditions is fulfilled:
+
+   *  The parental agent receives a new or updated NS RRset for a child;
+
+   *  The parental agent receives a notification indicating that the
+      child wishes to have its CDS/CDNSKEY RRset processed;
+
+   *  The parental agent encounters a signaling record during a
+      proactive, opportunistic scan (e.g., daily queries of signaling
+      records for some or all of its delegations);
+
+   *  The parental agent encounters a signaling record during an NSEC
+      walk or when parsing a signaling zone (e.g., when made available
+      via AXFR by the child DNS operator);
+
+   *  Any other condition deemed appropriate by local policy.
+
+   Timer-based trigger mechanisms (such as scans) exhibit undesirable
+   properties with respect to processing delay and scaling; on-demand
+   triggers (like notifications) are preferable.  Whenever possible,
+   child DNS operators and parental agents are thus encouraged to use
+   them, reducing both delays and the amount of scanning traffic.
+
+   Most types of discovery (such as daily scans of delegations) are
+   based directly on the delegation's NS RRset.  In this case, these NS
+   names can be used as is by the bootstrapping algorithm (Section 4.2)
+   for querying signaling records.
+
+   Some discovery methods, however, do not imply reliable knowledge of
+   the delegation's NS RRset.  For example, when discovering signaling
+   names by performing an NSEC walk or zone transfer of a signaling
+   zone, the parental agent MUST NOT assume that a nameserver under
+   whose signaling domain a signaling record appears is actually
+   authoritative for the corresponding child.
+
+   Instead, whenever a list of "bootstrappable domains" is obtained by
+   means other than directly from the parent, the parental agent MUST
+   ascertain that the delegation actually contains the nameserver
+   hostname seen during discovery, and ensure that signaling-record
+   queries are only made against the proper set of nameservers as listed
+   in the child's delegation from the parent.
+
+4.4.  Limitations
+
+   As a consequence of Step 3 in Section 4.2, DS bootstrapping does not
+   work for fully in-domain delegations, as no preexisting chain of
+   trust to the child domain is available during bootstrapping.  (As a
+   workaround, one can add an out-of-domain nameserver to the initial NS
+   RRset and remove it once bootstrapping is completed.  Automation for
+   this is available via CSYNC records, see [RFC7477].)
+
+   Fully qualified signaling names must by valid DNS names.  Label count
+   and length requirements for DNS names (Section 3.1 of [RFC1035])
+   imply that the protocol does not work for unusually long child domain
+   names or NS hostnames.
+
+5.  Operational Recommendations
+
+5.1.  Child DNS Operator
+
+   It is possible to add CDS/CDNSKEY records and corresponding signaling
+   records to a zone without the domain owner's explicit knowledge.  To
+   spare domain owners from being caught off guard by the ensuing DS
+   changes, child DNS operators following this practice are advised to
+   make that transparent, such as by informing the domain owner during
+   zone creation (e.g., in a GUI) or by notifying them via email.
+
+   When transferring a zone to another DNS operator, the old and new
+   child DNS operators need to cooperate to achieve a smooth transition,
+   e.g., by using the multi-signer protocols described in [RFC8901].  If
+   all else fails, the domain owner might have to request the removal of
+   all DS records and have the transfer performed insecurely (see
+   [INSEC]).
+
+   Signaling domains SHOULD be delegated as standalone zones, so that
+   the signaling zone's apex coincides with the signaling domain (such
+   as _signal.ns1.example.net).  While it is permissible for the
+   signaling domain to be contained in a signaling zone of fewer labels
+   (such as example.net), a zone cut ensures that bootstrapping
+   activities do not require modifications of the zone containing the
+   nameserver hostname.
+
+   Once a child DNS operator determines that specific signaling record
+   sets have been processed (e.g., by seeing the result in the parent
+   zone), they are advised to remove them.  This will reduce the size of
+   the signaling zone and facilitate more efficient bulk processing
+   (such as via zone transfers).
+
+5.2.  Parental Agent
+
+   In order to ensure timely DNSSEC bootstrapping of insecure domains,
+   stalemate situations due to mismatch of stale cached records (Step 4
+   of Section 4.2) need to be avoided.  It is thus RECOMMENDED that
+   queries into signaling domains be performed with an (initially) empty
+   resolver cache, or that some other method for retrieving fresh data
+   from authoritative servers be used.
+
+   It is also RECOMMENDED that QNAME minimization [RFC9156] be used when
+   resolving queries for signaling records to guard against certain
+   attacks (see Section 6).
+
+6.  Security Considerations
+
+   The DNSSEC bootstrapping method introduced in this document is based
+   on the approaches described in Section 3 of [RFC8078], but adds
+   authentication to the CDS/CDNSKEY concept.  Its security level is
+   therefore strictly higher than that of existing approaches described
+   in that document (e.g., "Accept after Delay").  Apart from this
+   general improvement, the same Security Considerations apply as in
+   [RFC8078].
+
+   The level of rigor in Section 4.2 is needed to prevent publication of
+   an ill-conceived DS RRset (authorized only under a subset of NS
+   hostnames).  This ensures, for example, that an operator in a multi-
+   homed setup cannot enable DNSSEC unless all other operators agree.
+
+   In any case, as the child DNS operator has authoritative knowledge of
+   the child's CDS/CDNSKEY records, it can readily detect fraudulent
+   provisioning of DS records.
+
+   In order to prevent the parents of nameserver hostnames from becoming
+   a single point of failure for a delegation (both in terms of
+   resolution availability and for the trust model of this protocol),
+   diversifying the path from the root to the child's nameserver
+   hostnames is advisable.  For example, different and independently
+   operated TLDs may be used for each one.
+
+   If QNAME minimization [RFC9156] is not used when querying for
+   signaling records, an upstream parent of a signaling domain will see
+   those CDS/CDNSKEY queries and could respond with an authoritative
+   answer signed with its own key, instead of sending the referral.
+   Enabling QNAME minimization reduces the attack surface for such
+   forgery.
+
+7.  IANA Considerations
+
+   IANA has added the following entries to the "Underscored and Globally
+   Scoped DNS Node Names" registry [RFC8552]:
+
+                   +=========+============+===========+
+                   | RR Type | _NODE NAME | Reference |
+                   +=========+============+===========+
+                   | CDS     | _signal    | RFC 9615  |
+                   +---------+------------+-----------+
+                   | CDNSKEY | _signal    | RFC 9615  |
+                   +---------+------------+-----------+
+
+                                 Table 1
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+              November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC7344]  Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
+              DNSSEC Delegation Trust Maintenance", RFC 7344,
+              DOI 10.17487/RFC7344, September 2014,
+              <https://www.rfc-editor.org/info/rfc7344>.
+
+   [RFC7477]  Hardaker, W., "Child-to-Parent Synchronization in DNS",
+              RFC 7477, DOI 10.17487/RFC7477, March 2015,
+              <https://www.rfc-editor.org/info/rfc7477>.
+
+   [RFC8078]  Gudmundsson, O. and P. Wouters, "Managing DS Records from
+              the Parent via CDS/CDNSKEY", RFC 8078,
+              DOI 10.17487/RFC8078, March 2017,
+              <https://www.rfc-editor.org/info/rfc8078>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8552]  Crocker, D., "Scoped Interpretation of DNS Resource
+              Records through "Underscored" Naming of Attribute Leaves",
+              BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
+              <https://www.rfc-editor.org/info/rfc8552>.
+
+   [RFC9156]  Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
+              Name Minimisation to Improve Privacy", RFC 9156,
+              DOI 10.17487/RFC9156, November 2021,
+              <https://www.rfc-editor.org/info/rfc9156>.
+
+   [RFC9499]  Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
+              RFC 9499, DOI 10.17487/RFC9499, March 2024,
+              <https://www.rfc-editor.org/info/rfc9499>.
+
+8.2.  Informative References
+
+   [BCP237]   Best Current Practice 237,
+              <https://www.rfc-editor.org/info/bcp237>.
+              At the time of writing, this BCP comprises the following:
+
+              Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
+              RFC 9364, DOI 10.17487/RFC9364, February 2023,
+              <https://www.rfc-editor.org/info/rfc9364>.
+
+   [INSEC]    Hardaker, W., "Intentionally Temporarily Degraded or
+              Insecure", Work in Progress, Internet-Draft, draft-
+              hardaker-dnsop-intentionally-temporary-insec-01, 21
+              October 2021, <https://datatracker.ietf.org/doc/html/
+              draft-hardaker-dnsop-intentionally-temporary-insec-01>.
+
+   [RFC8901]  Huque, S., Aras, P., Dickinson, J., Vcelak, J., and D.
+              Blacka, "Multi-Signer DNSSEC Models", RFC 8901,
+              DOI 10.17487/RFC8901, September 2020,
+              <https://www.rfc-editor.org/info/rfc8901>.
+
+Acknowledgements
+
+   Thanks to Brian Dickson, Ondřej Caletka, John R. Levine, Christian
+   Elmerot, Oli Schacher, Donald Eastlake, Libor Peltan, Warren Kumari,
+   Scott Rose, Linda Dunbar, Tim Wicinski, Paul Wouters, Paul Hoffman,
+   Peter Yee, Benson Muite, Roman Danyliw, Éric Vyncke, and Joe Abley
+   for reviewing draft proposals and offering comments and suggestions.
+
+   Thanks also to Steve Crocker, Hugo Salgado, and Ulrich Wisser for
+   early-stage brainstorming.
+
+Authors' Addresses
+
+   Peter Thomassen
+   deSEC, Secure Systems Engineering (SSE)
+   Berlin
+   Germany
+   Email: peter@desec.io
+
+
+   Nils Wisiol
+   deSEC, Technische Universität Berlin
+   Berlin
+   Germany
+   Email: nils@desec.io