<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="bcp" consensus="true" docName="draft-ietf-dnsop-dnssec-bcp-06" indexInclude="true" ipr="trust200902" number="9364" prepTime="2023-02-14T14:58:46" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bcp-06" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9364" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="DNSSEC">DNS Security Extensions (DNSSEC)</title>
    <seriesInfo name="RFC" value="9364" stream="IETF"/>
    <seriesInfo name="BCP" value="237" stream="IETF"/>
    <author initials="P." surname="Hoffman" fullname="Paul Hoffman">
      <organization showOnFrontPage="true">ICANN</organization>
      <address>
        <email>paul.hoffman@icann.org</email>
      </address>
    </author>
    <date month="02" year="2023"/>
    <area>ops</area>
    <workgroup>dnsop</workgroup>
    <keyword>DNSSEC</keyword>
    <keyword>DNS Security Extensions</keyword>
    <keyword>DNS</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document describes the DNS Security Extensions (commonly called "DNSSEC") that are
specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce
all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC.
This document does not update any of those RFCs.
A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice.
      A third purpose is to provide a single reference for other documents that want to refer to DNSSEC.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This memo documents an Internet Best Current Practice.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            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 BCPs is available in Section 2 of RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9364" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dnssec-as-a-best-current-pr">DNSSEC as a Best Current Practice</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-implementing-dnssec">Implementing DNSSEC</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dnssec-core-documents">DNSSEC Core Documents</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-addition-to-the-dnssec-core">Addition to the DNSSEC Core</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-additional-cryptographic-al">Additional Cryptographic Algorithms and DNSSEC</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extensions-to-dnssec">Extensions to DNSSEC</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-additional-documents-of-int">Additional Documents of Interest</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The core specification for what we know as DNSSEC (the combination of <xref target="RFC4033" format="default" sectionFormat="of" derivedContent="RFC4033"/>,
<xref target="RFC4034" format="default" sectionFormat="of" derivedContent="RFC4034"/>, and <xref target="RFC4035" format="default" sectionFormat="of" derivedContent="RFC4035"/>) describes a set of protocols that provide origin
authentication of DNS data. <xref target="RFC6840" format="default" sectionFormat="of" derivedContent="RFC6840"/> updates and extends those core RFCs
but does not fundamentally change the way that DNSSEC works.</t>
      <t indent="0" pn="section-1-2">This document lists RFCs that should be considered by someone
creating an implementation of, or someone deploying, DNSSEC as it is currently standardized.
Although an effort was made to be thorough, the reader should not assume this list is comprehensive.
It uses terminology from those documents without defining that terminology.
It also points to the relevant IANA registry groups that relate to DNSSEC.
It does not, however, point to standards that rely on zones needing to be signed by DNSSEC,
such as DNS-Based Authentication of Named Entities (DANE) <xref target="RFC6698" format="default" sectionFormat="of" derivedContent="RFC6698"/>.</t>
      <section anchor="dnssec-as-a-best-current-practice" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-dnssec-as-a-best-current-pr">DNSSEC as a Best Current Practice</name>
        <t indent="0" pn="section-1.1-1">Using the DNSSEC set of protocols is the best current practice for adding
origin authentication of DNS data. To date, no Standards Track RFCs offer any other
method for such origin authentication of data in the DNS.</t>
        <t indent="0" pn="section-1.1-2">More than 15 years after the DNSSEC specification was published,
it is still not widely deployed. Recent estimates are that fewer than 10% of the domain names
used for websites are signed, and only around a third of queries to recursive resolvers
are validated. However, this low level of deployment does not affect whether using DNSSEC
is a best current practice; it just indicates that the value of deploying DNSSEC is often
considered lower than the cost.
Nonetheless, the significant deployment of DNSSEC beneath some top-level domains (TLDs)
and the near-universal deployment of DNSSEC for the TLDs in the DNS root zone
demonstrate that DNSSEC is applicable for implementation by both ordinary and highly sophisticated domain owners.</t>
      </section>
      <section anchor="implementing-dnssec" numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-implementing-dnssec">Implementing DNSSEC</name>
        <t indent="0" pn="section-1.2-1">Developers of validating resolvers and authoritative servers,
as well as operators of validating resolvers and authoritative servers,
need to know the parts of the DNSSEC protocol that would affect them.
They should read the DNSSEC core documents and probably at least be familiar
with the extensions.
Developers will probably need to be very familiar with the algorithm documents as well.</t>
        <t indent="0" pn="section-1.2-2">As a side note, some of the DNSSEC-related RFCs have significant errata, so reading the
RFCs should also include looking for the related errata.</t>
      </section>
    </section>
    <section anchor="dnssec-core-documents" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-dnssec-core-documents">DNSSEC Core Documents</name>
      <t indent="0" pn="section-2-1">What we refer to as "DNSSEC" is the third iteration of the DNSSEC specification;
<xref target="RFC2065" format="default" sectionFormat="of" derivedContent="RFC2065"/> was the first, and <xref target="RFC2535" format="default" sectionFormat="of" derivedContent="RFC2535"/> was the second.
Earlier iterations have not been deployed on a significant scale.
Throughout this document, "DNSSEC" means the protocol initially defined in <xref target="RFC4033" format="default" sectionFormat="of" derivedContent="RFC4033"/>, <xref target="RFC4034" format="default" sectionFormat="of" derivedContent="RFC4034"/>, and  <xref target="RFC4035" format="default" sectionFormat="of" derivedContent="RFC4035"/>.</t>
      <t indent="0" pn="section-2-2">The three initial core documents generally cover different topics:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-3">
        <li pn="section-2-3.1">
          <xref target="RFC4033" format="default" sectionFormat="of" derivedContent="RFC4033"/> is an overview of DNSSEC, including how it might change the resolution of DNS queries.</li>
        <li pn="section-2-3.2">
          <xref target="RFC4034" format="default" sectionFormat="of" derivedContent="RFC4034"/> specifies the DNS resource records used in DNSSEC.
It obsoletes many RFCs about earlier versions of DNSSEC.</li>
        <li pn="section-2-3.3">
          <xref target="RFC4035" format="default" sectionFormat="of" derivedContent="RFC4035"/> covers the modifications to the DNS protocol incurred by DNSSEC.
These include signing zones, serving signed zones, resolving in light of
DNSSEC, and authenticating DNSSEC-signed data.</li>
      </ul>
      <t indent="0" pn="section-2-4">At the time this set of core documents was published, someone could create a DNSSEC
implementation of signing software, of a DNSSEC-aware authoritative server, and/or of
a DNSSEC-aware recursive resolver from the three core documents, plus a few older
      RFCs specifying the cryptography used. Those two older documents are the following:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-5">
        <li pn="section-2-5.1">
          <xref target="RFC2536" format="default" sectionFormat="of" derivedContent="RFC2536"/> defines how to use the DSA signature algorithm (although it refers to other
documents for the details).
DSA was thinly implemented and can safely be ignored by DNSSEC implementations.</li>
        <li pn="section-2-5.2">
          <xref target="RFC3110" format="default" sectionFormat="of" derivedContent="RFC3110"/> defines how to use the RSA signature algorithm (although refers to other
documents for the details).
RSA is still among the most popular signing algorithms for DNSSEC.</li>
      </ul>
      <t indent="0" pn="section-2-6">It is important to note that later RFCs update the core documents. As just one example,
<xref target="RFC9077" format="default" sectionFormat="of" derivedContent="RFC9077"/> changes how TTL values are calculated in DNSSEC processing.</t>
      <section anchor="addition-to-the-dnssec-core" numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-addition-to-the-dnssec-core">Addition to the DNSSEC Core</name>
        <t indent="0" pn="section-2.1-1">As with any major protocol, developers and operators discovered issues with the original
core documents over the years.
<xref target="RFC6840" format="default" sectionFormat="of" derivedContent="RFC6840"/> is an omnibus update to the original core documents and thus itself has
become a core document.
In addition to covering new requirements from new DNSSEC RFCs, it describes many important
security and interoperability issues that arose during the deployment of the initial
specifications, particularly after the DNS root was signed in 2010.
It also lists some errors in the examples of the core specifications.</t>
        <t indent="0" pn="section-2.1-2"><xref target="RFC6840" format="default" sectionFormat="of" derivedContent="RFC6840"/> brings a few additions into the core of DNSSEC.
	It makes NSEC3 <xref target="RFC5155" format="default" sectionFormat="of" derivedContent="RFC5155"/> as much a part of DNSSEC as NSEC is.
It also makes the SHA-256 and SHA-512 hash functions defined in <xref target="RFC4509" format="default" sectionFormat="of" derivedContent="RFC4509"/> and <xref target="RFC5702" format="default" sectionFormat="of" derivedContent="RFC5702"/> part of the core.</t>
      </section>
    </section>
    <section anchor="additional-cryptographic-algorithms-and-dnssec" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-additional-cryptographic-al">Additional Cryptographic Algorithms and DNSSEC</name>
      <t indent="0" pn="section-3-1">Current cryptographic algorithms typically weaken over time as computing power improves and new cryptoanalysis emerges.
Two new  signing algorithms have been adopted by the DNSSEC community: Elliptic Curve Digital Signature Algorithm (ECDSA) <xref target="RFC6605" format="default" sectionFormat="of" derivedContent="RFC6605"/> and Edwards-curve Digital Signature Algorithm (EdDSA) <xref target="RFC8080" format="default" sectionFormat="of" derivedContent="RFC8080"/>.
ECDSA and EdDSA have become very popular signing algorithms in recent years.
The GOST signing algorithm <xref target="I-D.ietf-dnsop-rfc5933-bis" format="default" sectionFormat="of" derivedContent="GOST-SIGN"/> was also adopted but has seen very limited use, likely
because it is a national algorithm specific to a very small number of countries.</t>
      <t indent="0" pn="section-3-2">Implementation developers who want to know which algorithms to implement in DNSSEC software
      should refer to <xref target="RFC8624" format="default" sectionFormat="of" derivedContent="RFC8624"/>.
   Note that
   this specification is only about what algorithms should and should
   not be included in implementations, i.e., it is not advice about which
   algorithms zone operators should or should not use for signing, nor
   which algorithms recursive resolver operators should or should not use
   for validation.</t>
    </section>
    <section anchor="extensions-to-dnssec" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-extensions-to-dnssec">Extensions to DNSSEC</name>
      <t indent="0" pn="section-4-1">The DNSSEC community has extended the DNSSEC core and the cryptographic algorithms, both
in terms of describing good operational practices and in new protocols. Some of the
RFCs that describe these extensions include the following:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-2">
        <li pn="section-4-2.1">
          <xref target="RFC5011" format="default" sectionFormat="of" derivedContent="RFC5011"/> describes a method to help resolvers update their DNSSEC trust anchors in an
automated fashion. This method was used in 2018 to update the DNS root trust anchor.</li>
        <li pn="section-4-2.2">
          <xref target="RFC6781" format="default" sectionFormat="of" derivedContent="RFC6781"/> is a compendium of operational practices that may not be obvious from reading
just the core specifications.</li>
        <li pn="section-4-2.3">
          <xref target="RFC7344" format="default" sectionFormat="of" derivedContent="RFC7344"/> describes using the CDS and CDNSKEY resource records to help automate the maintenance
of DS records in the parents of signed zones.</li>
        <li pn="section-4-2.4">
          <xref target="RFC8078" format="default" sectionFormat="of" derivedContent="RFC8078"/> extends <xref target="RFC7344" format="default" sectionFormat="of" derivedContent="RFC7344"/> by showing how to do initial setup of trusted relationships
between signed parent and child zones.</li>
        <li pn="section-4-2.5">
          <xref target="RFC8198" format="default" sectionFormat="of" derivedContent="RFC8198"/> describes how a validating resolver can emit fewer queries in signed zones that
use NSEC and NSEC3 for negative caching.</li>
        <li pn="section-4-2.6">
          <xref target="RFC9077" format="default" sectionFormat="of" derivedContent="RFC9077"/> updates <xref target="RFC8198" format="default" sectionFormat="of" derivedContent="RFC8198"/> with respect to the TTL fields in signed records.</li>
      </ul>
    </section>
    <section anchor="additional-documents-of-interest" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-additional-documents-of-int">Additional Documents of Interest</name>
      <t indent="0" pn="section-5-1">The documents listed above constitute the core of DNSSEC, the additional cryptographic algorithms,
and the major extensions to DNSSEC.
This section lists some additional documents that someone interested in implementing or operating
DNSSEC might find of value:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-2">
        <li pn="section-5-2.1">
          <xref target="RFC4470" format="default" sectionFormat="of" derivedContent="RFC4470"/> "describes how to construct DNSSEC NSEC resource records that cover a smaller range of
names than called for by <xref target="RFC4034" format="default" sectionFormat="of" derivedContent="RFC4034"/>. By generating and signing these records on demand, authoritative name
servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a
signed zone".</li>
        <li pn="section-5-2.2">
          <xref target="RFC6975" format="default" sectionFormat="of" derivedContent="RFC6975"/> "specifies a way for validating end-system resolvers to signal to a server which digital signature
and hash algorithms they support".</li>
        <li pn="section-5-2.3">
          <xref target="RFC7129" format="default" sectionFormat="of" derivedContent="RFC7129"/> "provides additional background commentary and some context for the NSEC and NSEC3
mechanisms used by DNSSEC to provide authenticated denial-of-existence responses".
This background is particularly important for understanding NSEC and NSEC3 usage.</li>
        <li pn="section-5-2.4">
          <xref target="RFC7583" format="default" sectionFormat="of" derivedContent="RFC7583"/> "describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone".</li>
        <li pn="section-5-2.5">
          <xref target="RFC7646" format="default" sectionFormat="of" derivedContent="RFC7646"/> "defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling
DNSSEC validation at specified domains".</li>
        <li pn="section-5-2.6">
          <xref target="RFC7958" format="default" sectionFormat="of" derivedContent="RFC7958"/> "describes the format and publication mechanisms IANA has used to distribute the DNSSEC trust anchors".</li>
        <li pn="section-5-2.7">
          <xref target="RFC8027" format="default" sectionFormat="of" derivedContent="RFC8027"/> "describes problems that a Validating DNS resolver, stub-resolver, or application might run into within
a non-compliant infrastructure".</li>
        <li pn="section-5-2.8">
          <xref target="RFC8145" format="default" sectionFormat="of" derivedContent="RFC8145"/> "specifies two different ways for validating resolvers to signal to a server which keys are
referenced in their chain of trust".</li>
        <li pn="section-5-2.9">
          <xref target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/> contains lists of terminology used when talking about DNS; Sections <xref target="RFC8499" section="10" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8499#section-10" derivedContent="RFC8499"/> and <xref target="RFC8499" section="11" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8499#section-11" derivedContent="RFC8499"/> cover DNSSEC.</li>
        <li pn="section-5-2.10">
          <xref target="RFC8509" format="default" sectionFormat="of" derivedContent="RFC8509"/> "specifies a mechanism that will allow an end user and third parties to determine the trusted key
state for the root key of the resolvers that handle that user's DNS queries".</li>
        <li pn="section-5-2.11">
          <xref target="RFC8901" format="default" sectionFormat="of" derivedContent="RFC8901"/> "presents deployment models that accommodate this scenario [when each DNS
provider independently signs zone data with their own keys] and describes these key-management requirements".</li>
        <li pn="section-5-2.12">
          <xref target="RFC9276" format="default" sectionFormat="of" derivedContent="RFC9276"/> "provides guidance on setting NSEC3 parameters based on recent operational
deployment experience".</li>
      </ul>
      <t indent="0" pn="section-5-3">There will certainly be other RFCs related to DNSSEC that are published after this one.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">IANA already has three registry groups that relate to DNSSEC:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6-2">
        <li pn="section-6-2.1">
          <eref target="https://www.iana.org/assignments/dns-sec-alg-numbers" brackets="none">DNSSEC algorithm numbers</eref></li>
        <li pn="section-6-2.2">
          <eref target="https://www.iana.org/assignments/dnssec-nsec3-parameters" brackets="none">DNSSEC NSEC3 parameters</eref></li>
        <li pn="section-6-2.3">
          <eref target="https://www.iana.org/assignments/ds-rr-types" brackets="none">DNSSEC DS RRtype digest algorithms</eref></li>
      </ul>
      <t indent="0" pn="section-6-3">The rules for the DNSSEC algorithm registry were set in the core RFCs and
updated by <xref target="RFC6014" format="default" sectionFormat="of" derivedContent="RFC6014"/>, <xref target="RFC6725" format="default" sectionFormat="of" derivedContent="RFC6725"/>, and <xref target="RFC9157" format="default" sectionFormat="of" derivedContent="RFC9157"/>.</t>
      <t indent="0" pn="section-6-4">This document does not update or create any registry groups or registries.</t>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">All of the security considerations from all of the RFCs referenced in this document
apply here.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-dnsop-rfc5933-bis" to="GOST-SIGN"/>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC3110" target="https://www.rfc-editor.org/info/rfc3110" quoteTitle="true" derivedAnchor="RFC3110">
          <front>
            <title>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <date month="May" year="2001"/>
            <abstract>
              <t indent="0">This document describes how to produce RSA/SHA1 SIG resource records (RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3110"/>
          <seriesInfo name="DOI" value="10.17487/RFC3110"/>
        </reference>
        <reference anchor="RFC4033" target="https://www.rfc-editor.org/info/rfc4033" quoteTitle="true" derivedAnchor="RFC4033">
          <front>
            <title>DNS Security Introduction and Requirements</title>
            <author fullname="R. Arends" initials="R." surname="Arends"/>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <author fullname="M. Larson" initials="M." surname="Larson"/>
            <author fullname="D. Massey" initials="D." surname="Massey"/>
            <author fullname="S. Rose" initials="S." surname="Rose"/>
            <date month="March" year="2005"/>
            <abstract>
              <t indent="0">The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System.  This document introduces these extensions and describes their capabilities and limitations.  This document also discusses the services that the DNS security extensions do and do not provide.  Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4033"/>
          <seriesInfo name="DOI" value="10.17487/RFC4033"/>
        </reference>
        <reference anchor="RFC4034" target="https://www.rfc-editor.org/info/rfc4034" quoteTitle="true" derivedAnchor="RFC4034">
          <front>
            <title>Resource Records for the DNS Security Extensions</title>
            <author fullname="R. Arends" initials="R." surname="Arends"/>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <author fullname="M. Larson" initials="M." surname="Larson"/>
            <author fullname="D. Massey" initials="D." surname="Massey"/>
            <author fullname="S. Rose" initials="S." surname="Rose"/>
            <date month="March" year="2005"/>
            <abstract>
              <t indent="0">This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.</t>
              <t indent="0">This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4034"/>
          <seriesInfo name="DOI" value="10.17487/RFC4034"/>
        </reference>
        <reference anchor="RFC4035" target="https://www.rfc-editor.org/info/rfc4035" quoteTitle="true" derivedAnchor="RFC4035">
          <front>
            <title>Protocol Modifications for the DNS Security Extensions</title>
            <author fullname="R. Arends" initials="R." surname="Arends"/>
            <author fullname="R. Austein" initials="R." surname="Austein"/>
            <author fullname="M. Larson" initials="M." surname="Larson"/>
            <author fullname="D. Massey" initials="D." surname="Massey"/>
            <author fullname="S. Rose" initials="S." surname="Rose"/>
            <date month="March" year="2005"/>
            <abstract>
              <t indent="0">This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.</t>
              <t indent="0">This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4035"/>
          <seriesInfo name="DOI" value="10.17487/RFC4035"/>
        </reference>
        <reference anchor="RFC4509" target="https://www.rfc-editor.org/info/rfc4509" quoteTitle="true" derivedAnchor="RFC4509">
          <front>
            <title>Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)</title>
            <author fullname="W. Hardaker" initials="W." surname="Hardaker"/>
            <date month="May" year="2006"/>
            <abstract>
              <t indent="0">This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs).  DS records, when stored in a parent zone, point to DNSKEYs in a child zone. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4509"/>
          <seriesInfo name="DOI" value="10.17487/RFC4509"/>
        </reference>
        <reference anchor="RFC5155" target="https://www.rfc-editor.org/info/rfc5155" quoteTitle="true" derivedAnchor="RFC5155">
          <front>
            <title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</title>
            <author fullname="B. Laurie" initials="B." surname="Laurie"/>
            <author fullname="G. Sisson" initials="G." surname="Sisson"/>
            <author fullname="R. Arends" initials="R." surname="Arends"/>
            <author fullname="D. Blacka" initials="D." surname="Blacka"/>
            <date month="March" year="2008"/>
            <abstract>
              <t indent="0">The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence.  This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence.  However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5155"/>
          <seriesInfo name="DOI" value="10.17487/RFC5155"/>
        </reference>
        <reference anchor="RFC5702" target="https://www.rfc-editor.org/info/rfc5702" quoteTitle="true" derivedAnchor="RFC5702">
          <front>
            <title>Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC</title>
            <author fullname="J. Jansen" initials="J." surname="Jansen"/>
            <date month="October" year="2009"/>
            <abstract>
              <t indent="0">This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (RFC 4033, RFC 4034, and RFC 4035). [STANDARDS TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5702"/>
          <seriesInfo name="DOI" value="10.17487/RFC5702"/>
        </reference>
        <reference anchor="RFC6840" target="https://www.rfc-editor.org/info/rfc6840" quoteTitle="true" derivedAnchor="RFC6840">
          <front>
            <title>Clarifications and Implementation Notes for DNS Security (DNSSEC)</title>
            <author fullname="S. Weiler" initials="S." role="editor" surname="Weiler"/>
            <author fullname="D. Blacka" initials="D." role="editor" surname="Blacka"/>
            <date month="February" year="2013"/>
            <abstract>
              <t indent="0">This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing.</t>
              <t indent="0">This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6840"/>
          <seriesInfo name="DOI" value="10.17487/RFC6840"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-dnsop-rfc5933-bis" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis-13" derivedAnchor="GOST-SIGN">
          <front>
            <title>Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC</title>
            <author initials="D." surname="Belyavsky" fullname="Dmitry Belyavsky">
              <organization showOnFrontPage="true">TCINET</organization>
            </author>
            <author initials="V." surname="Dolmatov" fullname="Vasily Dolmatov" role="editor">
              <organization showOnFrontPage="true">JSC "NPK Kryptonite"</organization>
            </author>
            <author initials="B." surname="Makarenko" fullname="Boris Makarenko" role="editor">
              <organization showOnFrontPage="true">The Technical center of Internet, LLC</organization>
            </author>
            <date month="November" day="30" year="2022"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-rfc5933-bis-13"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC2065" target="https://www.rfc-editor.org/info/rfc2065" quoteTitle="true" derivedAnchor="RFC2065">
          <front>
            <title>Domain Name System Security Extensions</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="C. Kaufman" initials="C." surname="Kaufman"/>
            <date month="January" year="1997"/>
            <abstract>
              <t indent="0">The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication.  Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2065"/>
          <seriesInfo name="DOI" value="10.17487/RFC2065"/>
        </reference>
        <reference anchor="RFC2535" target="https://www.rfc-editor.org/info/rfc2535" quoteTitle="true" derivedAnchor="RFC2535">
          <front>
            <title>Domain Name System Security Extensions</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <date month="March" year="1999"/>
            <abstract>
              <t indent="0">This document incorporates feedback on RFC 2065 from early implementers and potential users. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2535"/>
          <seriesInfo name="DOI" value="10.17487/RFC2535"/>
        </reference>
        <reference anchor="RFC2536" target="https://www.rfc-editor.org/info/rfc2536" quoteTitle="true" derivedAnchor="RFC2536">
          <front>
            <title>DSA KEYs and SIGs in the Domain Name System (DNS)</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <date month="March" year="1999"/>
            <abstract>
              <t indent="0">A standard method for storing US Government Digital Signature Algorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2536"/>
          <seriesInfo name="DOI" value="10.17487/RFC2536"/>
        </reference>
        <reference anchor="RFC4470" target="https://www.rfc-editor.org/info/rfc4470" quoteTitle="true" derivedAnchor="RFC4470">
          <front>
            <title>Minimally Covering NSEC Records and DNSSEC On-line Signing</title>
            <author fullname="S. Weiler" initials="S." surname="Weiler"/>
            <author fullname="J. Ihren" initials="J." surname="Ihren"/>
            <date month="April" year="2006"/>
            <abstract>
              <t indent="0">This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034.  By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4470"/>
          <seriesInfo name="DOI" value="10.17487/RFC4470"/>
        </reference>
        <reference anchor="RFC5011" target="https://www.rfc-editor.org/info/rfc5011" quoteTitle="true" derivedAnchor="RFC5011">
          <front>
            <title>Automated Updates of DNS Security (DNSSEC) Trust Anchors</title>
            <author fullname="M. StJohns" initials="M." surname="StJohns"/>
            <date month="September" year="2007"/>
            <abstract>
              <t indent="0">This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).</t>
              <t indent="0">This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="74"/>
          <seriesInfo name="RFC" value="5011"/>
          <seriesInfo name="DOI" value="10.17487/RFC5011"/>
        </reference>
        <reference anchor="RFC6014" target="https://www.rfc-editor.org/info/rfc6014" quoteTitle="true" derivedAnchor="RFC6014">
          <front>
            <title>Cryptographic Algorithm Identifier Allocation for DNSSEC</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="November" year="2010"/>
            <abstract>
              <t indent="0">This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated.  It changes the requirement from "standard required" to "RFC Required".  It does not change the list of algorithms that are recommended or required for DNSSEC implementations. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6014"/>
          <seriesInfo name="DOI" value="10.17487/RFC6014"/>
        </reference>
        <reference anchor="RFC6605" target="https://www.rfc-editor.org/info/rfc6605" quoteTitle="true" derivedAnchor="RFC6605">
          <front>
            <title>Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="W.C.A. Wijngaards" initials="W.C.A." surname="Wijngaards"/>
            <date month="April" year="2012"/>
            <abstract>
              <t indent="0">This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC).  It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6605"/>
          <seriesInfo name="DOI" value="10.17487/RFC6605"/>
        </reference>
        <reference anchor="RFC6698" target="https://www.rfc-editor.org/info/rfc6698" quoteTitle="true" derivedAnchor="RFC6698">
          <front>
            <title>The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="J. Schlyter" initials="J." surname="Schlyter"/>
            <date month="August" year="2012"/>
            <abstract>
              <t indent="0">Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used.  This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers.  This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6698"/>
          <seriesInfo name="DOI" value="10.17487/RFC6698"/>
        </reference>
        <reference anchor="RFC6725" target="https://www.rfc-editor.org/info/rfc6725" quoteTitle="true" derivedAnchor="RFC6725">
          <front>
            <title>DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates</title>
            <author fullname="S. Rose" initials="S." surname="Rose"/>
            <date month="August" year="2012"/>
            <abstract>
              <t indent="0">The DNS Security Extensions (DNSSEC) require the use of cryptographic algorithm suites for generating digital signatures over DNS data.  The algorithms specified for use with DNSSEC are reflected in an IANA-maintained registry.  This document presents a set of changes for some entries of the registry. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6725"/>
          <seriesInfo name="DOI" value="10.17487/RFC6725"/>
        </reference>
        <reference anchor="RFC6781" target="https://www.rfc-editor.org/info/rfc6781" quoteTitle="true" derivedAnchor="RFC6781">
          <front>
            <title>DNSSEC Operational Practices, Version 2</title>
            <author fullname="O. Kolkman" initials="O." surname="Kolkman"/>
            <author fullname="W. Mekking" initials="W." surname="Mekking"/>
            <author fullname="R. Gieben" initials="R." surname="Gieben"/>
            <date month="December" year="2012"/>
            <abstract>
              <t indent="0">This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.</t>
              <t indent="0">The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.</t>
              <t indent="0">This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6781"/>
          <seriesInfo name="DOI" value="10.17487/RFC6781"/>
        </reference>
        <reference anchor="RFC6975" target="https://www.rfc-editor.org/info/rfc6975" quoteTitle="true" derivedAnchor="RFC6975">
          <front>
            <title>Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)</title>
            <author fullname="S. Crocker" initials="S." surname="Crocker"/>
            <author fullname="S. Rose" initials="S." surname="Rose"/>
            <date month="July" year="2013"/>
            <abstract>
              <t indent="0">The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures.  These digital signatures can be generated using different algorithms.  This document specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support.  The extensions allow the signaling of new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in a DNSSEC-signed zone.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6975"/>
          <seriesInfo name="DOI" value="10.17487/RFC6975"/>
        </reference>
        <reference anchor="RFC7129" target="https://www.rfc-editor.org/info/rfc7129" quoteTitle="true" derivedAnchor="RFC7129">
          <front>
            <title>Authenticated Denial of Existence in the DNS</title>
            <author fullname="R. Gieben" initials="R." surname="Gieben"/>
            <author fullname="W. Mekking" initials="W." surname="Mekking"/>
            <date month="February" year="2014"/>
            <abstract>
              <t indent="0">Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists but does not have the specific resource record (RR) type you were asking for. When returning a negative DNS Security Extensions (DNSSEC) response, a name server usually includes up to two NSEC records. With NSEC version 3 (NSEC3), this amount is three.</t>
              <t indent="0">This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7129"/>
          <seriesInfo name="DOI" value="10.17487/RFC7129"/>
        </reference>
        <reference anchor="RFC7344" target="https://www.rfc-editor.org/info/rfc7344" quoteTitle="true" derivedAnchor="RFC7344">
          <front>
            <title>Automating DNSSEC Delegation Trust Maintenance</title>
            <author fullname="W. Kumari" initials="W." surname="Kumari"/>
            <author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson"/>
            <author fullname="G. Barwood" initials="G." surname="Barwood"/>
            <date month="September" year="2014"/>
            <abstract>
              <t indent="0">This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel.  The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7344"/>
          <seriesInfo name="DOI" value="10.17487/RFC7344"/>
        </reference>
        <reference anchor="RFC7583" target="https://www.rfc-editor.org/info/rfc7583" quoteTitle="true" derivedAnchor="RFC7583">
          <front>
            <title>DNSSEC Key Rollover Timing Considerations</title>
            <author fullname="S. Morris" initials="S." surname="Morris"/>
            <author fullname="J. Ihren" initials="J." surname="Ihren"/>
            <author fullname="J. Dickinson" initials="J." surname="Dickinson"/>
            <author fullname="W. Mekking" initials="W." surname="Mekking"/>
            <date month="October" year="2015"/>
            <abstract>
              <t indent="0">This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone.  It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7583"/>
          <seriesInfo name="DOI" value="10.17487/RFC7583"/>
        </reference>
        <reference anchor="RFC7646" target="https://www.rfc-editor.org/info/rfc7646" quoteTitle="true" derivedAnchor="RFC7646">
          <front>
            <title>Definition and Use of DNSSEC Negative Trust Anchors</title>
            <author fullname="P. Ebersman" initials="P." surname="Ebersman"/>
            <author fullname="W. Kumari" initials="W." surname="Kumari"/>
            <author fullname="C. Griffiths" initials="C." surname="Griffiths"/>
            <author fullname="J. Livingood" initials="J." surname="Livingood"/>
            <author fullname="R. Weber" initials="R." surname="Weber"/>
            <date month="September" year="2015"/>
            <abstract>
              <t indent="0">DNS Security Extensions (DNSSEC) is now entering widespread deployment.  However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes.  This document defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7646"/>
          <seriesInfo name="DOI" value="10.17487/RFC7646"/>
        </reference>
        <reference anchor="RFC7958" target="https://www.rfc-editor.org/info/rfc7958" quoteTitle="true" derivedAnchor="RFC7958">
          <front>
            <title>DNSSEC Trust Anchor Publication for the Root Zone</title>
            <author fullname="J. Abley" initials="J." surname="Abley"/>
            <author fullname="J. Schlyter" initials="J." surname="Schlyter"/>
            <author fullname="G. Bailey" initials="G." surname="Bailey"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="August" year="2016"/>
            <abstract>
              <t indent="0">The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC).</t>
              <t indent="0">In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA has used to distribute the DNSSEC trust anchors.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7958"/>
          <seriesInfo name="DOI" value="10.17487/RFC7958"/>
        </reference>
        <reference anchor="RFC8027" target="https://www.rfc-editor.org/info/rfc8027" quoteTitle="true" derivedAnchor="RFC8027">
          <front>
            <title>DNSSEC Roadblock Avoidance</title>
            <author fullname="W. Hardaker" initials="W." surname="Hardaker"/>
            <author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson"/>
            <author fullname="S. Krishnaswamy" initials="S." surname="Krishnaswamy"/>
            <date month="November" year="2016"/>
            <abstract>
              <t indent="0">This document describes problems that a Validating DNS resolver, stub-resolver, or application might run into within a non-compliant infrastructure.  It outlines potential detection and mitigation techniques.  The scope of the document is to create a shared approach to detect and overcome network issues that a DNSSEC software/system may face.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="207"/>
          <seriesInfo name="RFC" value="8027"/>
          <seriesInfo name="DOI" value="10.17487/RFC8027"/>
        </reference>
        <reference anchor="RFC8078" target="https://www.rfc-editor.org/info/rfc8078" quoteTitle="true" derivedAnchor="RFC8078">
          <front>
            <title>Managing DS Records from the Parent via CDS/CDNSKEY</title>
            <author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson"/>
            <author fullname="P. Wouters" initials="P." surname="Wouters"/>
            <date month="March" year="2017"/>
            <abstract>
              <t indent="0">RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevates RFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point.</t>
              <t indent="0">Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes.</t>
              <t indent="0">This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records).</t>
              <t indent="0">It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8078"/>
          <seriesInfo name="DOI" value="10.17487/RFC8078"/>
        </reference>
        <reference anchor="RFC8080" target="https://www.rfc-editor.org/info/rfc8080" quoteTitle="true" derivedAnchor="RFC8080">
          <front>
            <title>Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC</title>
            <author fullname="O. Sury" initials="O." surname="Sury"/>
            <author fullname="R. Edmonds" initials="R." surname="Edmonds"/>
            <date month="February" year="2017"/>
            <abstract>
              <t indent="0">This document describes how to specify Edwards-curve Digital Security Algorithm (EdDSA) keys and signatures in DNS Security (DNSSEC).  It uses EdDSA with the choice of two curves: Ed25519 and Ed448.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8080"/>
          <seriesInfo name="DOI" value="10.17487/RFC8080"/>
        </reference>
        <reference anchor="RFC8145" target="https://www.rfc-editor.org/info/rfc8145" quoteTitle="true" derivedAnchor="RFC8145">
          <front>
            <title>Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)</title>
            <author fullname="D. Wessels" initials="D." surname="Wessels"/>
            <author fullname="W. Kumari" initials="W." surname="Kumari"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="April" year="2017"/>
            <abstract>
              <t indent="0">The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures.  These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS.  This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust.  The data from such signaling allow zone administrators to monitor the progress of rollovers in a DNSSEC-signed zone.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8145"/>
          <seriesInfo name="DOI" value="10.17487/RFC8145"/>
        </reference>
        <reference anchor="RFC8198" target="https://www.rfc-editor.org/info/rfc8198" quoteTitle="true" derivedAnchor="RFC8198">
          <front>
            <title>Aggressive Use of DNSSEC-Validated Cache</title>
            <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
            <author fullname="A. Kato" initials="A." surname="Kato"/>
            <author fullname="W. Kumari" initials="W." surname="Kumari"/>
            <date month="July" year="2017"/>
            <abstract>
              <t indent="0">The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances.</t>
              <t indent="0">This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8198"/>
          <seriesInfo name="DOI" value="10.17487/RFC8198"/>
        </reference>
        <reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8499" quoteTitle="true" derivedAnchor="RFC8499">
          <front>
            <title>DNS Terminology</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
            <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
            <date month="January" year="2019"/>
            <abstract>
              <t indent="0">The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</t>
              <t indent="0">This document obsoletes RFC 7719 and updates RFC 2308.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="219"/>
          <seriesInfo name="RFC" value="8499"/>
          <seriesInfo name="DOI" value="10.17487/RFC8499"/>
        </reference>
        <reference anchor="RFC8509" target="https://www.rfc-editor.org/info/rfc8509" quoteTitle="true" derivedAnchor="RFC8509">
          <front>
            <title>A Root Key Trust Anchor Sentinel for DNSSEC</title>
            <author fullname="G. Huston" initials="G." surname="Huston"/>
            <author fullname="J. Damas" initials="J." surname="Damas"/>
            <author fullname="W. Kumari" initials="W." surname="Kumari"/>
            <date month="December" year="2018"/>
            <abstract>
              <t indent="0">The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures.  These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS.  This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries.  Note that this method is only applicable for determining which keys are in the trust store for the root key.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8509"/>
          <seriesInfo name="DOI" value="10.17487/RFC8509"/>
        </reference>
        <reference anchor="RFC8624" target="https://www.rfc-editor.org/info/rfc8624" quoteTitle="true" derivedAnchor="RFC8624">
          <front>
            <title>Algorithm Implementation Requirements and Usage Guidance for DNSSEC</title>
            <author fullname="P. Wouters" initials="P." surname="Wouters"/>
            <author fullname="O. Sury" initials="O." surname="Sury"/>
            <date month="June" year="2019"/>
            <abstract>
              <t indent="0">The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence.  To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support.  This document defines the current algorithm implementation requirements and usage guidance for DNSSEC.  This document obsoletes RFC 6944.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8624"/>
          <seriesInfo name="DOI" value="10.17487/RFC8624"/>
        </reference>
        <reference anchor="RFC8901" target="https://www.rfc-editor.org/info/rfc8901" quoteTitle="true" derivedAnchor="RFC8901">
          <front>
            <title>Multi-Signer DNSSEC Models</title>
            <author fullname="S. Huque" initials="S." surname="Huque"/>
            <author fullname="P. Aras" initials="P." surname="Aras"/>
            <author fullname="J. Dickinson" initials="J." surname="Dickinson"/>
            <author fullname="J. Vcelak" initials="J." surname="Vcelak"/>
            <author fullname="D. Blacka" initials="D." surname="Blacka"/>
            <date month="September" year="2020"/>
            <abstract>
              <t indent="0">Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service.  Deploying DNSSEC in such an environment may present some challenges, depending on the configuration and feature set in use.  In particular, when each DNS provider independently signs zone data with their own keys, additional key-management mechanisms are necessary.  This document presents deployment models that accommodate this scenario and describes these key-management requirements.  These models do not require any changes to the behavior of validating resolvers, nor do they impose the new key-management requirements on authoritative servers not involved in multi-signer configurations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8901"/>
          <seriesInfo name="DOI" value="10.17487/RFC8901"/>
        </reference>
        <reference anchor="RFC9077" target="https://www.rfc-editor.org/info/rfc9077" quoteTitle="true" derivedAnchor="RFC9077">
          <front>
            <title>NSEC and NSEC3: TTLs and Aggressive Use</title>
            <author fullname="P. van Dijk" initials="P." surname="van Dijk"/>
            <date month="July" year="2021"/>
            <abstract>
              <t indent="0">Due to a combination of unfortunate wording in earlier documents, aggressive use of NSEC and NSEC3 records may deny the existence of names far beyond the intended lifetime of a denial.  This document changes the definition of the NSEC and NSEC3 TTL to correct that situation.  This document updates RFCs 4034, 4035, 5155, and 8198.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9077"/>
          <seriesInfo name="DOI" value="10.17487/RFC9077"/>
        </reference>
        <reference anchor="RFC9157" target="https://www.rfc-editor.org/info/rfc9157" quoteTitle="true" derivedAnchor="RFC9157">
          <front>
            <title>Revised IANA Considerations for DNSSEC</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="December" year="2021"/>
            <abstract>
              <t indent="0">This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries.  It updates RFC 6014 to include hash algorithms for Delegation Signer (DS) records and NextSECure version 3 (NSEC3) parameters (for Hashed Authenticated Denial of Existence).  It also updates RFCs 5155 and 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to clarify the implementation recommendation related to the algorithms described in RFCs that are not on the standards track.  The rationale for these changes is to bring the requirements for DS records and hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9157"/>
          <seriesInfo name="DOI" value="10.17487/RFC9157"/>
        </reference>
        <reference anchor="RFC9276" target="https://www.rfc-editor.org/info/rfc9276" quoteTitle="true" derivedAnchor="RFC9276">
          <front>
            <title>Guidance for NSEC3 Parameter Settings</title>
            <author fullname="W. Hardaker" initials="W." surname="Hardaker"/>
            <author fullname="V. Dukhovni" initials="V." surname="Dukhovni"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">NSEC3 is a DNSSEC mechanism providing proof of nonexistence by asserting that there are no names that exist between two domain names within a zone.  Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding domain name pairs.  This document provides guidance on setting NSEC3 parameters based on recent operational deployment experience.  This document updates RFC 5155 with guidance about selecting NSEC3 iteration and salt parameters.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="236"/>
          <seriesInfo name="RFC" value="9276"/>
          <seriesInfo name="DOI" value="10.17487/RFC9276"/>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgements" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The DNS world owes a depth of gratitude to the authors and other contributors
to the core DNSSEC documents and to the notable DNSSEC extensions.</t>
      <t indent="0" pn="section-appendix.a-2">In addition, the following people made significant contributions to early draft versions
of this document: <contact fullname="Ben Schwartz"/> and <contact fullname="Duane Wessels"/>.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author initials="P." surname="Hoffman" fullname="Paul Hoffman">
        <organization showOnFrontPage="true">ICANN</organization>
        <address>
          <email>paul.hoffman@icann.org</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
