<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.6 -->
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-schwartz-ds-glue-02" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.9.1 -->
  <front>
    <title abbrev="DS Glue">Authenticated delegation information using DS records</title>
    <seriesInfo name="Internet-Draft" value="draft-schwartz-ds-glue-02"/>
    <author initials="B." surname="Schwartz" fullname="Benjamin Schwartz">
      <organization>Google LLC</organization>
      <address>
        <email>bemasc@google.com</email>
      </address>
    </author>
    <date year="2021" month="August" day="19"/>
    <area>General</area>
    <workgroup>dprive</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This draft describes a mechanism for conveying arbitrary authenticated DNS data from a parent nameserver to a recursive resolver as part of a delegation response.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
      mailing list (ds@ietf.org),
    which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ds/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/bemasc/ds-glue"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="conventions-and-definitions" numbered="true" toc="default">
      <name>Conventions and Definitions</name>
      <t>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&nbsp;14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here.</t>
    </section>
    <section anchor="background" numbered="true" toc="default">
      <name>Background</name>
      <t>The DPRIVE working group has been pursuing designs for authenticated encryption of recursive-to-authoritative communication.  Recursive resolvers could enable authenticated encryption most easily and efficiently if they received authenticated information about the target nameserver's configuration during the in-bailiwick delegation that precedes the direct connection.  However, there are several obstacles to this.</t>
      <section anchor="obstacle-1-authentication" numbered="true" toc="default">
        <name>Obstacle 1: Authentication</name>
        <t>Glue records in DNS referral responses are unauthenticated.  Parents do not generally provide RRSIGs for these records in their responses, and resolvers do not expect such signatures to be present.  An in-path attacker can modify or remove records in the delegation response without detection.</t>
        <t>If the parent zone also implements authenticated encryption, this provides sufficient protection for the glue records, but many important parent zones seem unlikely to implement authenticated encryption in the near future.</t>
      </section>
      <section anchor="obstacle-2-flexibility" numbered="true" toc="default">
        <name>Obstacle 2: Flexibility</name>
        <t>Existing nameserver deployments assume that the delegation response includes only a fixed set of existing RR types (NS, A, AAAA, DS, RRSIG, etc.).  These systems are slow to upgrade, and the working group would like to be able to begin deploying authenticated encryption without first requiring a significant change in these parents.</t>
      </section>
    </section>
    <section anchor="proposal" numbered="true" toc="default">
      <name>Proposal</name>
      <t>This draft proposes a way to convey a glue RRSet inside a DS record, enabling authenticated delivery of arbitrary RR types as part of the delegation response.</t>
      <t>There are three main records or RRSets involved in this process:</t>
      <ul spacing="normal">
        <li>A Source RRSet to be conveyed, which may be of any RR type and anywhere below the zone cut.</li>
        <li>A Virtual DNSKEY Record encapsulating the Source RRSet.</li>
        <li>The DSGLUE Record, a DS record derived from the Virtual DNSKEY Record and published in the parent.</li>
      </ul>
      <section anchor="encoding" numbered="true" toc="default">
        <name>Encoding</name>
        <t>To encode a Source RRSet, a zone operator first transforms it into a Virtual DNSKEY Record as follows:</t>
        <ul spacing="normal">
          <li>Owner Name = The Owner Name of the Source RRSet relative to the child zone apex.</li>
          <li>Flags = 0x0001, i.e. only SEP (bit 15) is set.</li>
          <li>Protocol = 3</li>
          <li>Algorithm = DS Glue (see IANA registration in <xref target="iana" format="default"/>)</li>
          <li>
            <t>Public Key = The following fields, concatenated
            </t>
            <ul spacing="normal">
              <li>The RR type (uint16)</li>
              <li>The RRSet TTL (uint32)</li>
              <li>
                <t>For each Source Record in canonical order (<xref section="6.3" sectionFormat="comma" target="RFC4034" format="default"/>),
                </t>
                <ul spacing="normal">
                  <li>A length prefix (uint16)</li>
                  <li>The canonicalized RDATA (<xref section="6.2" sectionFormat="comma" target="RFC4034" format="default"/>).</li>
                </ul>
              </li>
            </ul>
          </li>
        </ul>
        <t>For example, this Source RRSet:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
$ORIGIN example.com.
@ 3600 IN NS ns1
       IN NS ns2
       IN NS NS.OTHER.EXAMPLE.
]]></artwork>
        <t>would be represented as the following Virtual DNSKEY Record:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
; Public Key =
; \000\002 ; Type = NS
; \000\000\014\016 ; TTL=3600
; \000\018 \002ns\005other\007example\000 ; Len=18, ns.other.example.
; \000\017 \003ns1\007example\003com\000 ; Len=17, ns1.example.com.
; \000\017 \003ns2\007example\003com\000 ; Len=17, ns2.example.com.

. 300 IN DNSKEY 1 3 $DSGLUE_NUM ( AAIAAA4QABICbnMFb3RoZXIHZXhhbXBsZ
    QAAEQNuczEHZXhhbXBsZQNjb20AABEDbnMyB2V4YW1wbGUDY29tAA== )
]]></artwork>
        <t>Note that:</t>
        <ul spacing="normal">
          <li>The NS Source Records are "real" records that appear in authoritative Answers and/or delegation glue, but the DNSKEY record is a "virtual record" because it does not appear in any zone or response (in this form).</li>
          <li>The Virtual DNSKEY Record's owner name is "." because the Source RRSet appears at the zone apex.</li>
          <li>The NS RDATA has been reordered and converted to lowercase as specified by the canonicalization algorithm.</li>
        </ul>
        <t>Having constructed a Virtual DNSKEY Record, the DSGLUE Record is constructed as usual, but always using the VERBATIM digest type <xref target="I-D.draft-vandijk-dnsop-ds-digest-verbatim" format="default"/>.  Thus, the DSGLUE Record's wire format RDATA forms the following concatenation:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Key Tag | Algorithm = DSGLUE | Digest Type = VERBATIM | Digest = (
  DNSKEY owner name = name prefix | DNSKEY RDATA = (
    Flags = 1 | Protocol = 3 | Algorithm = DSGLUE | Public Key = (
      RR Type | TTL | Len(1) | RDATA(1) | Len(2) | RDATA(2) | ...
    )
  )
)
]]></artwork>
        <t>The DSGLUE record is a real DS record that appears in the usual DS RRSet, whose owner name is the child apex.</t>
        <ul empty="true">
          <li>
            <t>QUESTION: Should we skip the virtual DNSKEY record, and construct the fake DS directly?  This would save 4-6 bytes per RRSet, but would lose the ability to reuse DNSKEY-&gt;DS construction codepaths (unchanged except for a new digest type).</t>
          </li>
        </ul>
      </section>
      <section anchor="interpretation" numbered="true" toc="default">
        <name>Interpretation</name>
        <t>Upon receiving a delegation response, resolvers implementing this specification SHALL compute the Adjusted Delegation Response as follows:</t>
        <ol spacing="normal" type="1"><li>Copy the delegation response.</li>
          <li>Reverse the encoding process of any DSGLUE records to reconstruct the source RRSets.</li>
          <li>Add each of these reconstructed RRSets to the Adjusted Delegation Response, replacing any RRSet with the same owner name and type.</li>
        </ol>
        <t>Note that a Source RRSet MAY be empty, indicating that there are no records of the corresponding type at this name.  After reconstructing an empty Source RRSet, recipients MUST remove any matching RRSets from the Adjusted Delegation Response and any glue cache, and MAY cache the negative result for the indicated TTL.</t>
        <t>Resolution then proceeds as usual, using the Adjusted Delegation Response.  When processing the DS RRSet, the recipient will verify the DS RRSIGs as usual, and abort the resolution as Bogus if DNSSEC validation fails.</t>
        <t>Resolvers that do not implement this specification will ignore the DSGLUE records due to the unrecognized algorithm.  Thus, these records are safe to use for both signed and unsigned child zones.</t>
        <t>Source Records reconstructed from DSGLUE SHOULD be processed exactly like ordinary unauthenticated glue records.  For example, they MAY be cached for use in future delegations but MUST NOT be returned in any responses (c.f. <xref section="5.4.1" sectionFormat="of" target="RFC2181" format="default"/>).</t>
      </section>
      <section anchor="allowed-rr-types" numbered="true" toc="default">
        <name>Allowed RR types</name>
        <t>DSGLUE records are capable of containing any record type.  However, the meaning of certain record types (e.g. NSEC) is not yet clear in the DSGLUE context.  To avoid ambiguity, child zones MUST only publish DSGLUE records containing RR types that have been registered for use with DSGLUE (<xref target="iana" format="default"/>), and recipients MUST ignore DSGLUE records indicating unexpected record types.</t>
        <t>Recipients implementing this specification MUST accept the NS, A, and AAAA RR types in DSGLUE.  Support for the other allowed RR types is OPTIONAL.</t>
        <t>Recipients MUST ignore any unauthenticated TLSA records.</t>
      </section>
    </section>
    <section anchor="examples" numbered="true" toc="default">
      <name>Examples</name>
      <t>For these examples, the macro <tt>$DSGLUE(prefix, RR type, TTL, [RDATAs])</tt> constructs a DSGLUE DS record as described in <xref target="encoding" format="default"/>.</t>
      <section anchor="out-of-bailiwick-referral" numbered="true" toc="default">
        <name>Out-of-bailiwick referral</name>
        <t>An out-of-bailiwick referral contains only NS records, e.g.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
$ORIGIN com.
example 3600 IN NS ns1.example.net.
             IN NS ns2.example.net.
]]></artwork>
        <t>These Source Records would be encoded in DSGLUE as:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
$ORIGIN com.
example 3600 IN DS $DSGLUE(., NS, 3600,
    [ns1.example.net., ns2.example.net.])
]]></artwork>
      </section>
      <section anchor="in-bailiwick-referral" numbered="true" toc="default">
        <name>In-bailiwick referral</name>
        <t>An in-bailiwick referral contains NS records and at least one kind of address record.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
$ORIGIN com.
example    3600 IN NS    ns1.example
                IN NS    ns2.example
ns1.example 600 IN A     192.0.2.1
                IN AAAA  2001:db8::1
ns2.example 600 IN A     192.0.2.2
                IN AAAA  2001:db8::2
]]></artwork>
        <t>These records would be encoded in DSGLUE as:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
$ORIGIN com.
example 600 IN DS $DSGLUE(., NS, 3600, [ns1.example.com.,
                                        ns2.example.com.])
            IN DS $DSGLUE(ns1., A, 600, [192.0.2.1])
            IN DS $DSGLUE(ns1., AAAA, 600, [2001:db8::1])
            IN DS $DSGLUE(ns2., A, 600, [192.0.2.1])
            IN DS $DSGLUE(ns2., AAAA, 600, [2001:db8::2])
]]></artwork>
      </section>
      <section anchor="in-bailiwick-referral-without-ipv4" numbered="true" toc="default">
        <name>In-bailiwick referral without IPv4</name>
        <t>Consider a delegation to a nameserver that is only reachable with IPv6:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
$ORIGIN com.
example    3600 IN NS    ns1.example
ns1.example 600 IN AAAA  2001:db8::1
]]></artwork>
        <t>A zone in this configuration can optionally use an empty DSGLUE record to indicate that there is no IPv4 address:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
$ORIGIN com.
example 600 IN DS $DSGLUE(., NS, 3600, [ns1.example.com.])
            IN DS $DSGLUE(ns1., AAAA, 600, [2001:db8::1])
            IN DS $DSGLUE(ns1., A, 7200, [])
]]></artwork>
        <t>This arrangement prevents an adversary from inserting forged A records for ns1.example.com into the delegation response.</t>
        <t>Note that this negative answer is treated as glue that only applies during delegation, so A records for ns1.example.com can still be resolved if they exist.</t>
      </section>
      <section anchor="delegation-with-authenticated-encryption" numbered="true" toc="default">
        <name>Delegation with authenticated encryption</name>
        <t>Assuming a SVCB-based signaling mechanism similar to <xref target="I-D.draft-schwartz-svcb-dns" format="default"/>, an in-bailiwick referral with support for authenticated encryption is indicated as follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
$ORIGIN com.
example 600 IN DS $DSGLUE(., NS, 3600, [ns1.example.com.])
            IN DS $DSGLUE(ns1., A, 600, [192.0.2.1])
            IN DS $DSGLUE(ns1., AAAA, 600, [2001:db8::1])
            IN DS $DSGLUE(_dns.ns1., SVCB, 3600,
                          [1 ns1.example.com. alpn=dot])
]]></artwork>
        <section anchor="no-dane" numbered="true" toc="default">
          <name>Disabling DANE</name>
          <t>Resolvers check whether a nameserver supports DANE by resolving a TLSA record during the delegation process (<xref target="tlsa" format="default"/>).  However, this adds unnecessary latency to the delegation if the nameserver does not implement DANE.  As an optimization, such nameservers can add an empty DSGLUE RRSet to indicate that there is no such TLSA record, e.g.:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
IN DS $DSGLUE(_853._tcp.ns1., TLSA, 7200, [])
]]></artwork>
        </section>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Resolvers that process DSGLUE MUST perform DNSSEC validation.</t>
      <t>Source Records published as DSGLUE have owner names within the child zone, but are signed only by the parent.  This makes them fully authenticated, but provides different cryptographic guarantees than a direct signature by the child.  For example, these records might not appear in any key use logs maintained by the child.</t>
    </section>
    <section anchor="operational-considerations" numbered="true" toc="default">
      <name>Operational Considerations</name>
      <section anchor="compatibility-with-existing-resolvers" numbered="true" toc="default">
        <name>Compatibility with existing resolvers</name>
        <t>Resolver support for DSGLUE is OPTIONAL, so child zones MUST continue to place ordinary NS, A, and AAAA records in the parent zone as needed for non-DSGLUE resolution.</t>
      </section>
      <section anchor="publishing-dsglue-records" numbered="true" toc="default">
        <name>Publishing DSGLUE records</name>
        <t>In order for the child to publish DSGLUE records, the parent must allow the child to publish arbitrary DS records or have specific support for this specification.</t>
        <t>If the parent supports CDS <xref target="RFC8078" format="default"/>, child zones MAY use CDS to push DSGLUE records into the parent.  Note that CDNSKEY records cannot be used, because (1) the child cannot publish CDNSKEY records with the required owner name and (2) the child cannot guarantee that the parent will use the VERBATIM digest to produce the DS record.</t>
        <t>Child zones SHOULD publish all Source Records as ordinary records of the specified type at the indicated owner name, in order to enable revalidation <xref target="I-D.draft-ietf-dnsop-ns-revalidation" format="default"/> and simplify debugging.</t>
      </section>
      <section anchor="referral-response-size" numbered="true" toc="default">
        <name>Referral response size</name>
        <t>When records are present in both ordinary glue and DSGLUE, the response size is approximately doubled.  This could cause performance issues due to response truncation when the initial query is over UDP.</t>
      </section>
      <section anchor="tlsa" numbered="true" toc="default">
        <name>PKI and DANE for Authenticated Encryption</name>
        <ul empty="true">
          <li>
            <t>TODO: Move some of this text into a different draft.</t>
          </li>
        </ul>
        <t>Nameservers supporting authenticated encryption MAY indicate any DANE mode, or none at all.</t>
        <t>As an optimization, nameservers using DANE MAY place a TLSA record in the DSGLUE to avoid the latency of a TLSA lookup during delegation.  However, child zones should be aware that this adds complexity and delay to the process of TLSA key rotation.</t>
        <ul empty="true">
          <li>
            <t>QUESTION: Should we recommend for or against including nonempty TLSA in DSGLUE?  If CDS-like update mechanisms work well, and ADoT-DANE is widely deployed, this could warrant a positive recommendation.  Conversely, if rotation is error-prone, and ADoT-DANE is rare, a negative recommendation might be better.</t>
          </li>
        </ul>
        <t>Nameservers that support PKI-based authentication but not DANE SHOULD deny the TLSA RRSet in the DSGLUE, as shown in <xref target="no-dane" format="default"/>, to avoid an unnecessary delay.</t>
        <t>Resolvers that support authenticated encryption MAY implement support for PKI-based authentication, DANE, or both.  PKI-only resolvers MUST nonetheless resolve TLSA records, and MUST NOT require authentication if the DANE mode is DANE-TA(2) or DANE-EE(3) <xref target="RFC7671" format="default"/>.  DANE-only resolvers MUST NOT require authentication if the TLSA record does not exist.</t>
      </section>
    </section>
    <section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is requested to add a new entry to the DNS Security Algorithm Numbers registry:</t>
      <table align="center">
        <thead>
          <tr>
            <th align="left">Number</th>
            <th align="left">Description</th>
            <th align="left">Mnemonic</th>
            <th align="left">Zone Signing</th>
            <th align="left">Trans. Sec.</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">$DSGLUE_NUM</td>
            <td align="left">Authenticated Glue</td>
            <td align="left">DSGLUE</td>
            <td align="left">N</td>
            <td align="left">?</td>
            <td align="left">(This document)</td>
          </tr>
        </tbody>
      </table>
      <t>IANA is requested to open a new registry named "Authenticated Glue Allowed Record Types", with a policy of "Standards Action" and the following fields:</t>
      <ul spacing="normal">
        <li>Record Type: The name of a registered DNS record type</li>
        <li>Interpretation Reference: The standards document defining how to interpret this RR type in the Authenticated Glue context.</li>
      </ul>
      <t>The initial contents are as follows:</t>
      <table align="center">
        <thead>
          <tr>
            <th align="left">Record Type</th>
            <th align="left">Interpretation Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">NS</td>
            <td align="left">(This document)</td>
          </tr>
          <tr>
            <td align="left">A</td>
            <td align="left">(This document)</td>
          </tr>
          <tr>
            <td align="left">AAAA</td>
            <td align="left">(This document)</td>
          </tr>
          <tr>
            <td align="left">SVCB</td>
            <td align="left">(This document)</td>
          </tr>
          <tr>
            <td align="left">TLSA</td>
            <td align="left">(This document)</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC4034">
          <front>
            <title>Resource Records for the DNS Security Extensions</title>
            <author fullname="R. Arends" initials="R." surname="Arends">
              <organization/>
            </author>
            <author fullname="R. Austein" initials="R." surname="Austein">
              <organization/>
            </author>
            <author fullname="M. Larson" initials="M." surname="Larson">
              <organization/>
            </author>
            <author fullname="D. Massey" initials="D." surname="Massey">
              <organization/>
            </author>
            <author fullname="S. Rose" initials="S." surname="Rose">
              <organization/>
            </author>
            <date month="March" year="2005"/>
            <abstract>
              <t>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> 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="I-D.draft-vandijk-dnsop-ds-digest-verbatim">
          <front>
            <title>The VERBATIM Digest Algorithm for DS records</title>
            <author fullname="Peter van Dijk">
              <organization>PowerDNS</organization>
            </author>
            <date day="10" month="August" year="2021"/>
            <abstract>
              <t>   The VERBATIM DS Digest is defined as a direct copy of the input data
   without any hashing.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-vandijk-dnsop-ds-digest-verbatim-01"/>
        </reference>
        <reference anchor="RFC8078">
          <front>
            <title>Managing DS Records from the Parent via CDS/CDNSKEY</title>
            <author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson">
              <organization/>
            </author>
            <author fullname="P. Wouters" initials="P." surname="Wouters">
              <organization/>
            </author>
            <date month="March" year="2017"/>
            <abstract>
              <t>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>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>This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records).</t>
              <t>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="RFC7671">
          <front>
            <title>The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance</title>
            <author fullname="V. Dukhovni" initials="V." surname="Dukhovni">
              <organization/>
            </author>
            <author fullname="W. Hardaker" initials="W." surname="Hardaker">
              <organization/>
            </author>
            <date month="October" year="2015"/>
            <abstract>
              <t>This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience.  It also contains guidance for implementers, operators, and protocol developers who want to use DANE records.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7671"/>
          <seriesInfo name="DOI" value="10.17487/RFC7671"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC2181">
          <front>
            <title>Clarifications to the DNS Specification</title>
            <author fullname="R. Elz" initials="R." surname="Elz">
              <organization/>
            </author>
            <author fullname="R. Bush" initials="R." surname="Bush">
              <organization/>
            </author>
            <date month="July" year="1997"/>
            <abstract>
              <t>This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2181"/>
          <seriesInfo name="DOI" value="10.17487/RFC2181"/>
        </reference>
        <reference anchor="I-D.draft-schwartz-svcb-dns">
          <front>
            <title>Service Binding Mapping for DNS Servers</title>
            <author fullname="Benjamin Schwartz">
              <organization>Google LLC</organization>
            </author>
            <date day="26" month="July" year="2021"/>
            <abstract>
              <t>   The SVCB DNS record type expresses a bound collection of endpoint
   metadata, for use when establishing a connection to a named service.
   DNS itself can be such a service, when the server is identified by a
   domain name.  This document provides the SVCB mapping for named DNS
   servers, allowing them to indicate support for new transport
   protocols.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-schwartz-svcb-dns-04"/>
        </reference>
        <reference anchor="I-D.draft-ietf-dnsop-ns-revalidation">
          <front>
            <title>Delegation Revalidation by DNS Resolvers</title>
            <author fullname="Shumon Huque">
              <organization>Salesforce</organization>
            </author>
            <author fullname="Paul Vixie">
              <organization>Farsight Security</organization>
            </author>
            <author fullname="Ralph Dolmans">
              <organization>NLnet Labs</organization>
            </author>
            <date day="12" month="July" year="2021"/>
            <abstract>
              <t>   This document recommends improved DNS [RFC1034] [RFC1035] resolver
   behavior with respect to the processing of Name Server (NS) resource
   record sets (RRset) during iterative resolution.  When following a
   referral response from an authoritative server to a child zone, DNS
   resolvers should explicitly query the authoritative NS RRset at the
   apex of the child zone and cache this in preference to the NS RRset
   on the parent side of the zone cut.  Resolvers should also
   periodically revalidate the child delegation by re-quering the parent
   zone at the expiration of the TTL of the parent side NS RRset.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-ns-revalidation-01"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>Thanks to Paul Hoffman, Ilari Liusvaara, Puneet Sood, and Alexandar Mayrhofer for detailed comments.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAHCOHmEAA71b63LbRpb+j6foladqpS2SK1KO7WjKk6Ek2lZFF1uSM3Gy
qUwTaJKIQACDBkTRkvIs+yz7ZPud091AgxfHtZdhTcYk0JfT5/qd00fdbjco
4zJRh2JnWJUzlZZxKEsViUglairLOEtFnE6yYm6+VzpOp+LkWhQqzIpI7wRy
PC7UHebj4dukUjtBlIWpnGPJqJCTsqvD2UIW5edupLtTDOjuDwLaY5oVy0Oh
yygI4rw4FGVR6XKwv/8t3stCyUPxVqWqkEmwyIrbaZFVOZbMi/hOBbdqiYfR
oThNS1Wkquye0F5BoEuZRr/KJEux/1LpII8Pxc9lFnaEzoqyUBONb8s5ffkl
CCTOnBWHgegGAp841YfiqCeuLcn80JzlSKW/yXmctt9lxVSm8WfmDejNsmmi
xNnZMb9Ucxknh2KMf3X41ym/7IXZPAhSw887hZ3F1ZvjQb//7SHY4BhNL/Dp
drtCjnVZyBBHu5nF2rAUwtFhEY+VFlLMVTgDDXouMFmEWXqnliQjWYxjzCyW
QrYEe3JxLSJZSjEpsjnm5+B1WvIptSruVCHKDI8h36rQoATfdJbQc6lpcCmy
Cd57+oEBeZZq1TMUz+MoSlQQPBPHRExKY0Boiq3VJE5j/k3HUQJiFCRHLXbO
P17f7HTMv+Likr9fjT58PL0andD363fDs7P6S2BHXL+7/Hh20nxrZh5fnp+P
Lk7MZDwVrUfBzvnwE94QVTuX729OLy+GZzuQvyiZy1lYzYkr4A2xY6zwCoqW
F4pYKHXgJBDRnKPj9//1n/3n4uHhX6wwn57sj1f9l8/xYwEBmN2yNFnan5DK
MpB5rmRBq8gkEaHM41Im0FEwW8+yRSpmqiDOgp1HMmQzSCPDvZP3V6c/jIiB
tyRwthAxw8SxUqnIIb6KnoPUeAoJkHq0VUGlYbHMWYaQaS3xbpl1jWGAFlJG
aNV8XqU0C2N7UNk15dAYUyW0pBzDBLbuM890KZTUMbhA7FCTSRzGGIrf8YRZ
QoQorB2trOK7ITnOqpJGi1IWU+Wr778SKekknlaFGRtVBbGBBsdpdwybjBdx
eOtrcDmTpchpXzCLR0YxfpW0Uop/zanfZQuFDVhw0AvSDU0PZCIyWKkME5qc
sQpBYs+eiUv7WPQPhedesVwQkK90XpTET3YJr6QKWs+ZlOZdqrTFCZDyno2W
FFWkWSmmxlGCh3mR3cWREldX16dvjcwxU7d2woO4aLYwetkI0q6p7nPigK7C
mSAFkmVVmPPBGsArDQJAyZDiQzeX5UzIEoe9haMIJQk6iidLOEisPM/uVgnY
5D/EIobSVeTeSsv0IDhlpXBe6jP8OgxFZyKe54maMxO2KVvHGLNlCeypcspG
z+wWjkVi6smjI8YgYy7TJe2DuCFpTkMC1lJqDrkk8a0C10uPnu26b0+ekr1P
KmLnipYMDsWbRN3HY6houQyC0X2sS9JdzzlHKk+ypT241nBTRnu38TROw6Si
07PjgdeP70GVVuzGldvg6kqUyxyjdi+uO2KI/+HTQZzvGE3qCFWGvT3I+4a1
SS91qeZGO3WSLYgDVT4tZKSMOhE5bce0YP9ADLM6xI6Cv07BGXMuDlzb+OfU
YxIXcCKF+kcVs2VL1s8YsiUxUTScKsts7TSHDVK8L7I800AUfjDN+SHH0oVk
WZogit+sE2AAuAVoQHYlG+zTMc5unWSIAe4LgZcCZR2FaxZ7YXSL0Hrs362L
KWeFUtDFOK1NCBrLRJEx3ZHVRnXkwmFCpTXgw7+JobjOqiJ0JzBcN2dToH4x
i2HacxwZj4nUtCaSRYjfC6ZirFjCoJXNL6zKHq/+Q1yUFZwVPNf3o08UFEAd
CUzmukpk6byuTwXN5Nh1/fbs48jO6fhsBUMK9v6MT2j+5n2IxLwC//XMnd8J
25jVKA3hg0DDwzNlvz6BsZngXyRKnzCigY+X5XClJVhs1AzCSzUFHjCbtIDB
0RaKyN8m4JVh/+UCTllcwHTFaz6z98DKviWfQiUm2nIIAZ9nMQzGeLxc3RPn
3iRyqrHa/v3+/n6/I+Ke6hnDvh69F7tQNdH/Zk/E5J+Y1VB4YN8swZwDklky
paA+m+O3hetiF65MnA4vhiBgGhPYdM7q4SGWqXx62qOFiNOh+B5mYQ5jTkrs
ncQqIZcJzSL9T8kGAGu7PMwp1C6gSNl/see9oDPf3JyZVwcD8+oNGK8k9NKx
xrAW1MC4M4IgCLYFVETsGoD1fP/geUdcW2f+oncAejsMv7tQ0USlU0QmhCv4
PZ8IR0a9avwZWnR1MrwZblt5gJWhWUzhvSR3bwOML0VI/vfffw/+dHl1+vb0
wg0k1N8L/ioOXuzvCzxGqE91n8nAxz0YtB9cXPcub96NrnqjH4fn789GPV45
MH50TLHKRmFGpKwyjVA2aqgl7s8taeLnf0Cb8N9A/FnckLBeY+/mMf7rP8d/
L+j1zdlrOkT9tv+KvgxSjf//JiNghC8v7bFpCCadqfR1/1UHJ+zxiJ7jSrPK
S/pyAJ60Zx+Ab/4iL2mRfq/F1bU1Bl+xxqC9RtATB0Yyll99cSD+ZHzUrxcf
z8UuAuIpQuLzD8Oj0+Nxev5mfHCV/fTj6buffpzNxj8e6Z9YeB+Gw9GHiyr8
PGpefLj4bTzYHw6PRieYuDwa/PD809/6i/HbjyefBt+Ww+Hr12LPyPYCqITD
OTsQ0k/oQcsSTMjdQXqc7NTxgAGAl0i0sPsw1QuCdfCX/54Vfrih6GaQDumO
Pbl1wjGFw507q0Xm4Q60LpQVgQpgtAyhjHCity8CiHGhDboUuy4ykQ/dc+5/
o3oCuWfsIgnuEAU7vWbLNXdp9gWZZROanJ+0nDPmXGdEhWLPoUzs4EBYkPHA
38JqVBFK7EN5F4Av0ATejJfGEzdOwqYfzo9Cdd7JOzI4LAffWYVsjZvP1zF8
9iMfnbI1U4tKY6IRi0wASLStuXAkHF0dDW9Oz5GeTBUFJ7JWeKvT7knPFFvu
cLT4t9tulOosp4qLGdnFUcegff70xBiu0huIAf8XSHuESbMs90zoazuXxtNT
2cM4FfIlN3IqHleCDK//KE4Mwda91OeoX7wWuzAgyy5PC16bf6wDf6wZyrSZ
SaIOi30M8CPeNmJawWzXel1EKqbukYPSIzmL3f4evvBe5is9GzTP+Guv1+MV
KKrsBdaQPYjjGxSZrYd0PLut8yIWP42xqGQxAzZdsYsGHRiFD/4iPnwcXVMV
41BczzhALADMb+Ocx961tdHBV2sFRvmMiOUt0W2z32T5HekKNjQxR0u4k+fd
FzCLEsYPnOSIJGW1+D6ztipNEkPGVSgyYLN59y9Yvt6UbImwGKWPyD2q1IB3
gMj7UOWlKVkgYVr4Cr9n4N2pK8jYfPpjzgiaSgcmKdgArDtemlsnbMa44tru
TYIuuM5ElY+8Ks2RhtFvleYSWrPylfNzLfDX74njLF9ux/eDHmYSGWZlh08d
fHdwvKVC2vCyLTHtuUTkOAc9UBkZBGUwpk39GxdjMwcLMr90JuJWnsiQ2cnJ
AfldysLM1gxkG8XktA/y6XlxbAVki/PhJ4Iuap6XS8BX+KrQ5QnGj9ukJ82a
ZMdAZfww7GM+mSSlNHKj3akSMYFC+Ic1dJvNVrA+RsV5zEk0FxxtjYJOCdcH
2+KcmBlVpyFfFr9JmEzGGIL9Ng+mA/NPm/pPTVDGUaqkrGsPlhFYG74H/Lsi
La1saYpqeaQWKtJefGiCwpfoAlv+Vi+g6ymNe6FfNTMg2yQRUEuq3DTjqJDU
bMwnHWdFaefWlGLIUTatNNXxYOzXo2Nxh5AZGYomMk60OxobIIvcFpua6skG
S2SqkOFnhfKDllOQqKpTpiqlh9OUwXwTpL2I51XCuHYhJzyZHBQJYwyAytUE
CxKq1P5okjE6xAokaxsYK4yl0ValuWLGEmDfJsm3mlII5scplQdWanytchQO
sJJ1IHJZU2Lliph4RmapLS15fkezf3aFdZM6YEhq0mbS2qbcuBv2Jj1ACpf2
fNN73uuTDX7Hle1XfZMEwf8OydmxPzF1jSBYkQvxN5Q5l3mwAFhUyjh1zsSF
QHIY7dKqmCvJw2gSEFpT+XA1KtWb9oDvRsec6pL+LOFbwsTiUE9HaFN1T3VK
5P3yLosh1vk4nlYx+R9PqIY9nErbosKqmnn016UcVuEZhUULMCmBZoTp5MHe
0q60WyfUruTadkJWxVf29ZxklZqirIpaDGGrqpf6o7jGW8mQ42vJOJkLfkQQ
Ff2aw1FNmkkB966rnMqgtcPiPI5uLFoqQNJwlyltovzzkfRXtf3m7HpYaztV
6kZG17XJt43hWv230HUuwyITf7dZ2q5BiB1HS4c8aUf8zEBN/7L39wZ0aK42
MY8bKAbn1brSeXioa0ZPtkpbld1s4t0fuGJ9EAxTkW176/TGFmAv6pvTjiA1
bpcLOBm1x1wpFtQJa0qVHeF/6vpBe4wDolqtppB1CcFUwqJG1ODD4VeQBL45
vvc6rEH0xpRdfl4ltrNG2i8WJTOK28bReNObhpsNI01EKgXMHwiR0sDbmC7a
AKGiqCA0ZQZ+idf4eOymS9/mEG1m1/zmQfW5Am+CsCsNeXT/20Fvvzfo9Tet
wxYnBvv7/cNo/OrwsB94a25eZ/A16wx86Rf/W7F/WeptidPEzhqJ2z6rlZhf
9lpT25vSNuyrzK41Y79mEl9nmHket/9g5uB/st1g63aDP9L7+obj9P3d8yA4
zvjOoWjnMlyA9m/rKQbF1r0UhPw54nLgwTovviRY8SW136TRa+rK5xma6our
9LSvX+kyMOMLHL6grBgsW1DeTpHpFs0CYT8f4BDPLHEG/X+pq/9vymN19eWA
5/1SFwaoEABhI82dm5tIdWcu8wDFIgLGhAYZQ8LNAf5wiT0rKCuuQyTH4ZWT
mLuJ7TdKTU5mkiaXikiuD3JZAdpji1CMPnmwuTbM8yRW2l2lNxtQV80fkEXy
1yVB+HHdLhDVd/18A2kCrJe+sPJuuweEvtG9p0nyr384PoIlEa7mS2q+jmta
YnQ8jxPJLS0PD981ZbK6J0nfhWMqlj09EQTaEnSYHO1BoO1XvNrL5VolgX+q
wv6zXOSv4FzPTCdB+DBg8+fn/loBHygyT19HWdl4R+hCrO3V6snwYiQenqVZ
N5KpevITSCQ+kNJipgwY9Z2iFZY208dLq3hGZzyw6TeHeGbjyjBA7GWiCbG3
cxSy4Qj6XlF3CAaSySZUEQ2XYt0Ija63LvFd8bzJe4lQKmKwIyB/ObfF5o5p
wWhmazYp7L/mR+t73u1ulNfyGGBQqNXPFeG++uag92sZ5lbCNGvNnz2jCzLw
EES4cCVtg9dKpu94amnljCBXBdWX18sF6zl2c9Ur6zU482oqUJoN1SaATW5n
a+mU7Ztcnl2aLe3bC2Nb55zLW9P/M0cWTdGqZehmobqdJIon8A8kOzb/bFrI
fBaHYlpJuPdSmfwwpehtmonqLpr6XoFo3JDce5htHk9n5YZ7Fuqco1CaZFPN
zQGEir0bC16ZxHOZW4nAj61K6Bm16M1z/LTFWnZ0dVNIXSttZNnyglYKXtLH
4WAtqybMHqemSkP1RK/qsZp8rjQJtbp+KGapyObWaZZ2a/TgSlAmjrw3mmL6
VP1UOghOU3t57PJYQyvRtTHp7/hUzCtdmpR389Sm1aNpj6WrMNZSl4O3GLie
na81PNWO7BiL2pbC/ZevKFy1+Dz8xOpAo5ik9fpFDQ9qlW8QwXHrZoAdDKnc
mK4jWO/tJRzdgjRnt6Pc+VcXqQvFplOHDK9dLKb7k7XVautp2posK7gM6K4C
127CMjLMqApdibBJ+o49Ptl6XC0yrLh6vaob7VwpQTf3gk352a/dNsej0rbV
tDJzPZEAek05tIVGYlVO7I1dqrv+uKcn5pSmOEFF2UiNq+kUqm1U/Wq1XxAj
P6sg4JqvX4eznQJEFpc46yMy0OPeXNYWVxD2VuObqxzMvY/nOCacYpSBfdyG
eGPgfsXiI9FYhy7TkObpStXl2XrNsqhSV9glMg0P4zLGMf5RUdsUJTPkaz6e
vLcW/f2poZGCORlOu1V91OCvh2ccr+lG7Oby5PJQnFNZX2eu5YZQrrqv+3ga
F86CIJTshVlre1/sSSPDq6MtX9kQjfOM+uCMm2JFgaL1CLeuB3c/rtvmelqB
1jW+so1X2uXN0hU16ZkDINyezXOSLLut8nXU7oMZ34vomasQyIVpPXPZAqMd
uguj9sTStO5iPVnDHe/iirem+FRkpXNqmy8o6UxzoB/j0glXT6m2U9qmRe58
BGEMcXjVumDxHZDohLxdl6voVR4R/2vcr7n3EFsk9sJieJLddJmxdJuJGEhq
zB2HKuq4rJWp4tyM7q3yTMf2rsZS6XjHbe2FxhodwnbumLQ0rDErumBGqjZs
jOBAj/1rIH9pG+zHVE0uS1WsqCNLw4UPmIRNe2Srr5ghCvlR3tO6u0ilBhYw
E10/o6dIXrs51z4d2kaUqVUMmuvDXZb++n2Oo+/LBlOjXj8abjtSh8/C5kS+
i7qfMdKWO9zmDDRIWTAzMTU/ftWqLNsrOXcRYuPSKgctXK8NmSRHP7rmxp+A
D/0ajXYP9mxIfvniZZ87K/jNJtL+eL9WVuLygzo9Nh16bQAHb8f3CcAM9JIU
DDsobXtaOEPgy3NsVtSWSn3mNWZv2iMuqvmYqLVNgEukBI/2oUndHpGgU4Hc
iFG4h+ewT2qOwdefyNldUytuSn0gN9Q52aO9etQxodjThsrNDB67/qf9a/3h
49Y3Gydj+VYD1+NKzODWx0fnR+kgF36e+ii+a/3avfH/LGQP1G/meZar1DLd
MZI9fLT651W8f32FZqRO7Sd6p2OrH3BASWzc+c41/VWTpGA+5Gu5nbrHerUN
kxvHvPUOuRcqtT2n0r+iOrloGlEwEvPaLRWNyMwiuiai/vOYiP+gB5vPTAt4
/UcyxqW65k/razZwwN3PmY4ZBwP4KdfEipXGikf/bJDLNopJvYSnDqL1q/Xh
oab6uU3azSsMHX5RMdpDuVz6VUOpfPKVQ9lRfM1Q/mussQxvyX8Mw9s0WwC2
TflvB4KHw5SNW0WvdyYy0WqHmqMRPm+5N+S9rBKAhMkEWK4jThNZxOIsrvSd
BDzvIMdCLlYCO2e2j2gIYMDqIc7lsphlE5tkRRBNnNAFOgc66lH5bxOx59V0
OAAA

-->

</rfc>
