<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.12 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-schwartz-dprive-name-signal-00" category="exp" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.47.0 -->
  <front>
    <title abbrev="NAMEHACK">Nameserver Access Modes with Encryption Held in Alphanumeric Configuration Keys</title>
    <seriesInfo name="Internet-Draft" value="draft-schwartz-dprive-name-signal-00"/>
    <author initials="B." surname="Schwartz" fullname="Benjamin M. Schwartz">
      <organization>Google LLC</organization>
      <address>
        <email>bemasc@google.com</email>
      </address>
    </author>
    <author initials="W." surname="Kumari" fullname="Warren Kumari">
      <organization>Google LLC</organization>
      <address>
        <email>warren@kumari.net</email>
      </address>
    </author>
    <date year="2021" month="June" day="08"/>
    <area>General</area>
    <workgroup>dprive</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>Some recent proposals to the DPRIVE working group rely on the use of SVCB records to provide instructions about how to reach an authoritative nameserver over an encrypted transport.  These proposals will be difficult to deploy until the parent domain's delegation software has been modified to support these records.  As an interim solution for these domains, this draft proposes encoding relevant signals in the child's NS-name.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    mailing list (dns-privacy@ietf.org),
  which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/dns-privacy/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/wkumari/draft-schwartz-dprive-name-signal"/>.</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><xref target="I-D.draft-schwartz-svcb-dns" format="default"/> defines how to use SVCB records to describe the secure transport protocols supported by a DNS server.  <xref target="I-D.draft-ietf-dprive-unauth-to-authoritative" format="default"/> describes the use of such records on the names of nameservers (the "NS name") to enable opportunistic encryption of recursive-to-authoritative DNS queries.  Resolvers are permitted to fetch SVCB records asynchronously and cache them, resulting in "partial opportunistic encryption": even without an active adversary forcing a downgrade, queries will sometimes be sent in cleartext.  Participating authoritative nameservers and recursive resolvers would have to be modified to make use of these records.</t>
      <t>When the child zone is DNSSEC-signed, publishing a SVCB record of this kind is technically sufficient to enable authenticated encryption.  However, in order to support reliable authentication, recursive resolvers would have to query for a SVCB record on every signed delegation, and wait for a response before issuing their intended query.  We call this behavior a "synchronous binding check".</t>
      <t>Many validating resolvers might not be willing to enable a "synchronous binding check" behavior, as this would slow down resolution of many existing domains in order to enable a new feature (authenticated encryption) that is not yet used at all.  To enable authenticated encryption without this general performance loss, <xref target="I-D.draft-rescorla-dprive-adox-latest" format="default"/> proposes to deliver the SVCB records from the parent, in the delegation response.  This avoids the need for a binding check, at the cost of additionally requiring modifications to the parent nameserver, which must provide these extra records in delegation responses.</t>
      <t>Providing these additional records is sufficient to enable "full opportunistic encryption": the transport is always encrypted in the absence of an active adversary.  However, these records are not protected by DNSSEC, so the child can only achieve fully authenticated encryption if the parent also implements fully authenticated encryption or otherwise protects the delivery of these records.</t>
      <t>Even if this approach is standardized, many parent zones may not support delivery of SVCB records in delegation responses in the near future.  To enable the broadest use of encrypted transport, we may need an interim solution that can be deployed more easily.</t>
    </section>
    <section anchor="proposal" numbered="true" toc="default">
      <name>Proposal</name>
      <t>We propose to indicate a nameserver's support for encrypted transports using a signal encoded in its name.  This signal takes two forms: a "flag" and a "menu".</t>
      <ul empty="true" spacing="normal">
        <li>QUESTION: Do we need both of these forms, or should we drop one?</li>
      </ul>
      <t>We note that encoding semantics in DNS labels is a hack, but believe that the privacy benefits outweigh the ick factor.</t>
      <t>In either form, the signal helps resolvers to acquire a SVCB RRSet for the nameserver.  Resolvers use this RRSet as specified in <xref target="I-D.draft-rescorla-dprive-adox-latest" format="default"/>.</t>
      <section anchor="flag-form" numbered="true" toc="default">
        <name>Flag form</name>
        <t>If the NS name's first label is <tt>svcb</tt>, this is regarded as a "flag".  When contacting a flagged nameserver, participating resolvers SHOULD perform a synchronous binding check, and upgrade to a secure transport if appropriate, before issuing the query.</t>
        <t>The presence of this flag does not guarantee that the corresponding SVCB records are actually present.</t>
      </section>
      <section anchor="menu-form" numbered="true" toc="default">
        <name>Menu form</name>
        <t>If the NS name's first label starts with <tt>svcb--</tt>, the label's subsequent characters represent a "menu" of connection options, which can be decoded into a SVCB RRSet.  To decode the RRSet, each character is transformed into a SVCB RR with the following components:</t>
        <ul spacing="normal">
          <li>The owner name is the NS name plus the prefix label "_dns".</li>
          <li>The SvcPriority is the character's order in the list (starting at 1)</li>
          <li>The TargetName is the NS name</li>
          <li>The SvcParams are indicated in the registry entry for this menu character (<xref target="iana" format="default"/>).</li>
        </ul>
        <t>For example, the name "svcb-qt.ns3.example." would be decoded to this RRSet:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
_dns.svcb--qt.ns3.example. IN SVCB 1 svcb--qt.ns3.example. alpn=doq
_dns.svcb--qt.ns3.example. IN SVCB 2 svcb--qt.ns3.example. alpn=dot
]]></artwork>
        <t>The menu characters are a-z and 0-9; all other characters are reserved for future use.  Upon encountering any character outside these ranges, parsers MUST stop and return successfully.  Parsers MUST ignore characters that are allowed but not recognized.</t>
        <ul empty="true" spacing="normal">
          <li>QUESTION: Do we need more than 36 codepoints?  Is there a nice simple format that would give us a lot more codepoints?</li>
        </ul>
        <ul empty="true" spacing="normal">
          <li>QUESTION: Should we consider a format that actually encodes the SvcParams in the label instead?</li>
        </ul>
      </section>
      <section anchor="implementation-requirements" numbered="true" toc="default">
        <name>Implementation requirements</name>
        <t>Resolvers that implement support for "menu" mode MUST also support the "flag" mode.  Resolvers that support either mode MUST also support <xref target="I-D.draft-rescorla-dprive-adox-latest" format="default"/>, and ignore the in-name signal if any SVCB records are included in a delegation response.</t>
        <t>When possible, zones SHOULD use SVCB records in the delegation response and omit any in-name signal.</t>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>NS names received during delegation are not protected by DNSSEC.  Therefore, just like in <xref target="I-D.draft-rescorla-dprive-adox-latest" format="default"/>, this scheme only enables authenticated encryption if the parent domain can provide authentication without DNSSEC validation, e.g. using a secure transport or Zone Digest <xref target="RFC8976" format="default"/>.</t>
      <ul empty="true" spacing="normal">
        <li>QUESTION: Do we expect to have parent zones that can provide authenticated NS names but cannot provide authenticated SVCB records in delegation responses?  (Maybe the root, with ZONEMD?)  If not, does this proposal provide enough value?</li>
      </ul>
    </section>
    <section anchor="operational-considerations" numbered="true" toc="default">
      <name>Operational Considerations</name>
      <t>It is possible that an existing NS name already matches the "flag" pattern.  Such a "false positive flag" will result in a small performance loss due to the unnecessary synchronous binding check, but will not otherwise impair functionality.</t>
      <t>If a pre-existing NS name contains the menu pattern, that nameserver will become unreachable by resolvers implementing this specification.  The authors believe that no such nameservers are currently deployed, and such servers are unlikely to be deployed by accident.</t>
    </section>
    <section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is requested to create a new registry entitled "Authoritative Server Transport In-Name Signal Characters", with the following fields:</t>
      <ul spacing="normal">
        <li>Character: a digit or lower-case letter</li>
        <li>SvcParams: a valid SVCB SvcParams set in presentation format</li>
      </ul>
      <t>The registry policy is <strong>TBD</strong>.</t>
      <t>The initial contents (<strong>DO NOT USE</strong>, subject to change) are as follows:</t>
      <table align="center">
        <thead>
          <tr>
            <th align="left">Character</th>
            <th align="left">SvcParams</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">t</td>
            <td align="left">alpn=dot</td>
          </tr>
          <tr>
            <td align="left">h</td>
            <td align="left">alpn=h2 dohpath=/dns-query{?dns}</td>
          </tr>
          <tr>
            <td align="left">3</td>
            <td align="left">alpn=h3 dohpath=/dns-query{?dns}</td>
          </tr>
          <tr>
            <td align="left">q</td>
            <td align="left">alpn=doq</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
            <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>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <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>
        </reference>
        <reference anchor="I-D.draft-schwartz-svcb-dns" target="https://www.ietf.org/archive/id/draft-schwartz-svcb-dns-03.txt">
          <front>
            <title>Service Binding Mapping for DNS Servers</title>
            <seriesInfo name="Internet-Draft" value="draft-schwartz-svcb-dns-03"/>
            <author fullname="Benjamin Schwartz">
              <organization>Google LLC</organization>
            </author>
            <date month="April" day="19" 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>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.draft-ietf-dprive-unauth-to-authoritative" target="https://www.ietf.org/archive/id/draft-ietf-dprive-unauth-to-authoritative-01.txt">
          <front>
            <title>Recursive to Authoritative DNS with Unauthenticated Encryption</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-dprive-unauth-to-authoritative-01"/>
            <author fullname="Paul Hoffman">
              <organization>ICANN</organization>
            </author>
            <author fullname="Peter van Dijk">
              <organization>PowerDNS</organization>
            </author>
            <date month="May" day="19" year="2021"/>
            <abstract>
              <t>   This document describes a use case and a method for a DNS recursive
   resolver to use unauthenticated encryption when communicating with
   authoritative servers.  The motivating use case for this method is
   that more encryption on the Internet is better, and some resolver
   operators believe that unauthenticated encryption is better than no
   encryption at all.  The method described here is optional for both
   the recursive resolver and the authoritative server.  This method
   supports unauthenticated encryption using the same mechanism for
   discovery of encryption support for the server as [FULL-AUTH].

              </t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.draft-rescorla-dprive-adox-latest" target="https://www.ietf.org/archive/id/draft-rescorla-dprive-adox-latest-00.txt">
          <front>
            <title>Signaling Authoritative DNS Encryption</title>
            <seriesInfo name="Internet-Draft" value="draft-rescorla-dprive-adox-latest-00"/>
            <author fullname="Tommy Pauly">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="Eric Rescorla">
              <organization>Mozilla</organization>
            </author>
            <author fullname="David Schinazi">
              <organization>Google LLC</organization>
            </author>
            <author fullname="Christopher A. Wood">
              <organization>Cloudflare</organization>
            </author>
            <date month="February" day="26" year="2021"/>
            <abstract>
              <t>   This document defines a mechanism for signaling that a given
   authoritative DNS server is reachable by encrypted DNS.

Discussion Venues

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

   Discussion of this document takes place on the DNS PRIVate Exchange
   Working Group mailing list (dns-privacy@ietf.org), which is archived
   at https://mailarchive.ietf.org/arch/browse/dns-privacy/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ekr/draft-rescorla-dprive-adox.

              </t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8976" target="https://www.rfc-editor.org/info/rfc8976">
          <front>
            <title>Message Digest for DNS Zones</title>
            <seriesInfo name="DOI" value="10.17487/RFC8976"/>
            <seriesInfo name="RFC" value="8976"/>
            <author initials="D." surname="Wessels" fullname="D. Wessels">
              <organization/>
            </author>
            <author initials="P." surname="Barber" fullname="P. Barber">
              <organization/>
            </author>
            <author initials="M." surname="Weinberg" fullname="M. Weinberg">
              <organization/>
            </author>
            <author initials="W." surname="Kumari" fullname="W. Kumari">
              <organization/>
            </author>
            <author initials="W." surname="Hardaker" fullname="W. Hardaker">
              <organization/>
            </author>
            <date year="2021" month="February"/>
            <abstract>
              <t>This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest. The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received.  When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes. </t>
              <t>ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets (DNS data with fine granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications. </t>
              <t>As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, the ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.draft-levine-dprive-signal-02" target="http://www.ietf.org/internet-drafts/draft-levine-dprive-signal-02.txt">
          <front>
            <title>Signaling That an Authoritative DNS server offers DoT</title>
            <seriesInfo name="Internet-Draft" value="draft-levine-dprive-signal-02"/>
            <author initials="J" surname="Levine" fullname="John Levine">
              <organization/>
            </author>
            <date month="November" day="17" year="2019"/>
            <abstract>
              <t>DNS resolvers that wish to use DNS over TLS to authoritative servers (ADoT) need some way to tell whether server offers DoT.  This document describes some ways that a server might signal that it uses DoT.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.draft-bretelle-dprive-dot-spki-in-ns-name" target="https://www.ietf.org/archive/id/draft-bretelle-dprive-dot-spki-in-ns-name-00.txt">
          <front>
            <title>Encoding DNS-over-TLS (DoT) Subject Public Key Info (SPKI) in Name Server name</title>
            <seriesInfo name="Internet-Draft" value="draft-bretelle-dprive-dot-spki-in-ns-name-00"/>
            <author fullname="Emmanuel Bretelle">
              <organization>Facebook</organization>
            </author>
            <date month="March" day="11" year="2019"/>
            <abstract>
              <t>   This document describes a mechanism to exchange the Subject Public
   Key Info (SPKI) ([RFC5280] Section 4.1.2.7) fingerprint associated
   with a DNS-over-TLS (DoT [RFC7858]) authoritative server by encoding
   it as part of its name.  The fingerprint can thereafter be used to
   validate the certificate received from the DoT server as well as
   being able to discover support for DoT on the server.

              </t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.draft-vandijk-dprive-ds-dot-signal-and-pin" target="https://www.ietf.org/archive/id/draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt">
          <front>
            <title>Signalling Authoritative DoT support in DS records, with key pinning</title>
            <seriesInfo name="Internet-Draft" value="draft-vandijk-dprive-ds-dot-signal-and-pin-01"/>
            <author fullname="Peter van Dijk">
              <organization>PowerDNS</organization>
            </author>
            <author fullname="Robin Geuze">
              <organization>TransIP</organization>
            </author>
            <author fullname="Emmanuel Bretelle">
              <organization>Facebook</organization>
            </author>
            <date month="July" day="13" year="2020"/>
            <abstract>
              <t>   This document specifies a way to signal the usage of DoT, and the
   pinned keys for that DoT usage, in authoritative servers.  This
   signal lives on the parent side of delegations, in DS records.  To
   ensure easy deployment, the signal is defined in terms of (C)DNSKEY.

              </t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.draft-fujiwara-dnsop-delegation-information-signer" target="https://www.ietf.org/archive/id/draft-fujiwara-dnsop-delegation-information-signer-00.txt">
          <front>
            <title>Delegation Information (Referrals) Signer for DNSSEC</title>
            <seriesInfo name="Internet-Draft" value="draft-fujiwara-dnsop-delegation-information-signer-00"/>
            <author fullname="Kazunori Fujiwara">
              <organization>JPRS</organization>
            </author>
            <date month="November" day="2" year="2020"/>
            <abstract>
              <t>   DNSSEC does not protect delegation information, it contains NS RRSet
   on the parent side and glue records.  This document defines
   delegation information signer (DiS) resource record for protecting
   the delegation information, by inserting on the parent side of zone
   cut to hold a hash of delegation information.  The DiS resource
   record reuses the type code and wire format of DS resource record,
   and distinguishes it from existing DS RRSet by using a new digest
   type.  This document also describes the usage of DiS resource record
   and shows the implications on security-aware resolvers.  The
   definition and usage are compatible with current DNSSEC.

              </t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.draft-vandijk-dnsop-ds-digest-verbatim" target="https://www.ietf.org/archive/id/draft-vandijk-dnsop-ds-digest-verbatim-00.txt">
          <front>
            <title>The VERBATIM Digest Algorithm for DS records</title>
            <seriesInfo name="Internet-Draft" value="draft-vandijk-dnsop-ds-digest-verbatim-00"/>
            <author fullname="Peter van Dijk">
              <organization>PowerDNS</organization>
            </author>
            <date month="September" day="25" year="2020"/>
            <abstract>
              <t>   The VERBATIM DS Digest is defined as a direct copy of the input data
   without any hashing.

              </t>
            </abstract>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="comparison-with-related-designs" numbered="true" toc="default">
      <name>Comparison with related designs</name>
      <t>Several other designs have been proposed to encode a transport upgrade signal in an existing record type.</t>
      <section anchor="indicating-dot-support-with-a-name-prefix" numbered="true" toc="default">
        <name>Indicating DoT support with a name prefix</name>
        <t>Section 3.6 of <xref target="I-D.draft-levine-dprive-signal-02" format="default"/> discusses using the "xs-" name prefix to indicate support for DNS over TLS.  This is equivalent to a "svcb-t" label in this formulation.  This draft may be seen as an expansion of that proposal, harmonized with the SVCB-based discovery drafts.</t>
      </section>
      <section anchor="encoding-the-spki-pin-in-the-leaf-label" numbered="true" toc="default">
        <name>Encoding the SPKI pin in the leaf label</name>
        <t><xref target="I-D.draft-bretelle-dprive-dot-spki-in-ns-name" format="default"/> also proposes to encode a signal in the leaf label.  The signal includes an SPKI pin, for authentication of the TLS connection.</t>
        <t>Including an SPKI pin allows authentication of the nameserver without relying on DANE or PKI validation.  However, like this draft, it does not achieve authenticated encryption unless the NS name can be delivered securely during delegation.  It may also create operational challenges when rotating TLS keys, due to the need to update the parent zone.</t>
      </section>
      <section anchor="encoding-the-signal-in-an-additional-ns-record" numbered="true" toc="default">
        <name>Encoding the signal in an additional NS record</name>
        <t>It would be possible to encode the signal by adding a special NS record to the RRSet.  This would avoid the need to rename any existing nameservers.  However, this arrangement has different semantics: it is scoped to the entire child zone, rather than a specific nameserver.  It also relies heavily on existing resolvers having robust and performant fallback behavior, which may not be a safe assumption.</t>
        <t>(Credit: Paul Hoffman)</t>
      </section>
      <section anchor="extending-the-ds-record" numbered="true" toc="default">
        <name>Extending the DS record</name>
        <t><xref target="I-D.draft-vandijk-dprive-ds-dot-signal-and-pin" format="default"/> encodes a signal and pin in a DS record by allocating a new fake "signature algorithm" and encoding the TLS SPKI in a DNSKEY record.  This enables fully authenticated encryption (only requiring that the parent zone is signed).  However, it has very limited flexibility for representing different transport configurations, and creates challenges during TLS key rotation.</t>
      </section>
      <section anchor="enabling-authentication-of-delegation-data" numbered="true" toc="default">
        <name>Enabling authentication of delegation data</name>
        <t><xref target="I-D.draft-fujiwara-dnsop-delegation-information-signer" format="default"/> adds a DS record over the delegation information.  When combined with this draft, this would enable fully authenticated encrypted transport.  However, this approach requires very tight coherence between the child and parent (e.g. when removing a nameserver) that may not be achievable in practice.</t>
        <t><xref target="I-D.draft-vandijk-dnsop-ds-digest-verbatim" format="default"/> allows children to push arbitrary authenticated delegation data into the parent.  This could be used to convey SVCB RRSets for the delegation securely.  However, it requires parents to accept a new digest type, and bends the usual DS semantics even further.</t>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t><strong>TODO</strong></t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAHiCv2AAA41a7XIbx7H9v08xF/4RioXl1UfKueYtR6FIOmJJJBVBiiu5
lbIHuwNgxMXOameWIETbz3KfJU+W092zXyApk+WySOzsTH+ePt2DNE2TYENh
DtXkQq+NN/W1qdVRlhnv1bnLjVcbG1bqtMzqbRWsK9VrU+TKluqoqFa6bNam
tpk6duXCLpta85I3ZusniZ7Pa3NNOx+dn74+On4zSXKXlTjmUOW1XoTUZ6uN
rsOXNK9qe21SepZ6uyx1kT59mmQ6mKWrt4fK3FRJYqv6UIW68eH506ffPX2e
6NroQ/VXU5paF8nG1VfL2jUVduftkiuzxYf5oTorg6lLE9ITOjZJfNBl/pMu
XAlRtsYnfg0xfvrcuGD8oSpdUtlD9X/BZVPlXR1qs/D4bbumX/6VJLoJK1cf
JipNFH5siZdeHahZVIc/FD1fmfKTXsNa5zuPXb3Upf3C9oIOzi0Lo96+PeaH
Zq1tcajm+Ndnf1nyw4PMrUcH/nig3jSQ2w6O+1HXtSmHnz/mnA2/9ZcrfusA
dkqS0tVrvHNtDmH3cjH4K0nSNFV67kOtM6ycubVRtclMGVRVu8p5XXgVnAor
o07evT/7+6ki19hyqdg9WFxsFaKEFjTeKLdQs78fv6JN4C1+Fxtd29yQonB4
RsJ7nOmaoFZuQyvg+myldKnEFzawfGyGGMSO/ocFRkLX5IgdXfoK/jxQ6sMK
6wYCb2xRwOAqt4uFzZoi0CG5qQq3VU0ZbMHiVgg56Jk7GK78g8eCwiwl5r1b
BBjSqJX22AheWDtsZulcp3xT0cG0iTetphDjyJOIluLTrrFH0fBmMHhcKkch
+sLKekmbKDVSE6rhDBgWJjXXGpJJ8njKT5I3W9kih5wXM86tA3He2uZ5YZLk
G0rbaygk5i1zdWIWtrT8d5LARAopRN6DVybnH2cfJlP5V11c8u/vT//28ez9
6Qn9Pnt99PZt90sSV8xeX358e9L/1r95fHl+fnpxIi/jUzX6KJmcH/0DT0iq
yeW7D2eXF0dvJ6IXGcJlQB4oTBaHfedGjFjVhjytfQLoymo7N4xVr47f/fv/
n/1R3d7+1/sfjp8/e/bdr7/GP/7n2Z/+iD82K1PKaa5EeMqfMOE20VVldE27
aIRIpivEWgGHwM0ewViqlanJsjDnK50xBJV5kmD3s/TkYAfo/HU2T/PS48Sc
bA0nxoCmTNhNg1YH9qU3WUPKtkFMYQCEcvB2jC7oOt8qrU4uZkqSABF2e/uy
l8OasGjBtikpddLg0lEKsWRyrB+mqG+Qb61sMXs52+hhn3Ze7dGTCUSgDydP
SA9T6jlgx7GUTWl9QMkwfUnBDjVp50muXYFYnc8NEsRQxrw3yBI+iFxfmXpt
Q5AkW5gAGUdG1H5bZqvala7xcCv5NwNwsEXXUyzzSHXKILh3guwOVhcPyjlB
IUK6cEUkKCL0yVhEnZNEut5S5ma0n0aIbsplrXMzbaUXkPEAzGDJcHNyKmIY
Z2cFYiyYG4KmdyRGZivNgj2Eb5KwndlIlWiXjWtQoVf6us2MIRCt9VXn0jEY
JcmPCPoeNtQXlEeFXIP9Z6fHXJdNPlVVMy+sX4mSA2PLjlgPqM/pvWCyVWkz
ZM0W0UOwaknbPh5INUIfqvP5wM6wwWu3ganrKdkGewPJByAKtLO7G+C16SOs
QZ5gJ+3KXpJr8Ui0HAC7gMJG2xBfw9YV8NHAsviALOQbMgZEsTWjUJljBz4J
mvwIcxJwsGnmBoJY3mYyiEw1h8loD0RmdjWBK851uVXXurC5REGvz9ouVwEU
JZBnKaD47N6mX9u4O5/RiyUS8/gCIEQBKwc1bVauSQxzQ4mATWItGvmkO7Y0
GySgDoRRew95Fmiw0oGCgxTYmkChCLgOhK1UlX83NrrkY+mXwv0IBpijlJlR
hfNA5xHsQSl4udAt9Onc3aQFdvYBcNeVU0bcwhJvoCwYAcmidusBBZi2FXbA
ANrAYHYB4fS1s7lgaGmghITPyCNTUp0zzvlABtd5zuWXk6Y2nxtb02LJYAnz
jlxFMtJDwhRlywIB16DIHYWSJAey1LpTBrLfIzdBwDt+K4azNwN5+pf9/dk8
WTTFV7GTZO6rFxmo2OitHxC0aFOQS0OeJHvchdghOowQjAsCxRUVRpPFcijo
RTx+AG0Z9uU6j1pgsZUi2bcPB51dDC2O8u+UXVeFIQrif+9luN3hUb2xwjhJ
Nt8Gj2XUuQeMT6nS2Aip4CC1I8JLxqfmRde5/UJozBka5SLABkDoLVuhRcvh
IaOQfiAKWi+UxHoWDSX0KDPp2RzSgCWEtpLcw7ERjEZkodi/j+QyFJAniHYz
08bCNUGq0d4W2wOiVO8iQ0d1auk6AzllEVmakKdLgD90VIiT7R6pPCSWyiVM
WSi0hJ7FU2bJMX/jioCKCXdtHO25RuMFiF0UejnhwoA/EAQNYfaf1d8+ns6I
qR6qE0fqs+pzOL93MO8xpZgAeSToxbIcaiEczUtWEr4zYpuO3ns0ahRZ7Bui
Q4Wem4JTUaO0EY7MGyoIBQczv8zxCrTT2RYPSpBNqAfg3BgUEH5qsyu1QHa5
GsKfoQBailKWcCqMUwywMkXlBxUI1tcZIZNpi+j79zMT2qZl4I8RXaNQ4WCW
1USfK5MJMYFat7ePxGsKi2/UD/AAiwrRJTkj40QMLGyN0GQbkYl+JtL9c+yg
LGmyRPpwl9D5kgo1sZ/MlYEAh0OEniyxboiw1Yic9UaJ3U0sRBRfD1VhIRRN
xdyQjXmX2iPvOeWhPrSe3kM1Ir+QLg1dT4eYrCVJjnJtpM4uG42dgxlEBswr
Cc9yjSkz+TULDZcg2TmIzc8R6I+xORCKMo0HR2z8NP1ZIoqfc5YC4qEBQCtb
aRokkA1rE4/rsooUgktKkwmSMqD6ts512NGmMBuzj0iBLXnMx/OnU8Wjg+5c
pqpkedLszjaiBb28cAVYErvRrWE5gv7DJNmnUYICdcJOZAverjeNqorGx2RE
Dt5EE01+QhMI0JC3Z9fZu9oSy9+2r3fiwVpCtiIsg3sHtccm5igN6tmTuM0H
XS9NuLgrxOAY7LoWH7cI2pVd5AX2RqGAZpEkczCRJwbm2ru9tbrUv/76BFHx
A8HsjaZaOO2SHxSUnf45HJT+xUF8fjCJZHPgMmYyLSTAmL/99ltCljm4dwN1
diFueabuf66Lqvw+d58fs8fzr+8RWBbOrrH+MUHSL5zGT9Pv/pfnAlzhd1fV
AhtC/aSUEgwiLj9WjidTruGqSI5EHe+NDKD2PXtDdC6NZ/DxtDePYHxA1ZAe
EBuX1KDT1JbJiHSR/VoAOeHHQDxGAtaEoprKVCNdBcHAsiRy8XBJ4yKNHUr1
4ltFnqwcssa/VOqM444rA1o/KiFkVSUDRDlUgmBJnK4hAC5wKG842Gh88qyr
lMACMgvx6OGWHVxJNZfY76O9zRwpCKUPRucvGdHOWhLXciAua8zqkqQvXdK0
tGtHHCPi1Joghk3N5HAw7mvJAq0Y1UPetF0Ya+8D2zy6Nkptid7mGl/y4K8t
5VRXEGd38N6WWdFEGqTv7WnidAD0y9s5JbuQzVj27gyvHu6OZMa2toElGcvH
jG9GxZCQ8Dg6W8d5ZAQzz9NmS2mVN5w6g1O+0gLI0LfmSjpVn6hHKuyVEe7x
2GYxsgiPSg6puYUQWuwf2zxIE821q23RxmOMrsMVsbspAI0izMHyoGewu6wB
4fhPmtmc2CVxc2hF883v/vQtk6a7uWxuQMC4hePxyKiL6Mj5PUJCvc4XBBtY
Fm1+z8rHtBwAjr1zvY2Dzto56h6o7v7z8uL0/OTlEwDLgvw6FVLDPmhn9925
BlwL1Bb2aohKf6Muqxg8WLQbTGfcgbbhHGGk7GcdbfnWRQ202KKTCfC5H2Y0
OCBdKyGuZjQbJSqJrDW0qeWWVZbx0E8GjZJefk0FY3dkgWA2bWffEOMBltNA
8Ss8kmzPu5P1+xYTQKUt1ZsyE+WRTAdM2TSRkPSOjkx6abAT2moXVZuKXQaX
KvGaJKNLn6bkSxhuCufbARfukFK4qu2YvgS4JGIcbPpx11I6GTSP5pxUGxq6
ogpIt7ZTFKjjxcOFTUlJjXUy+uz6ShqMZxkiQMisOju6ONoJCnX7DRMbmIoe
cqcAjurjdDmDtqGddA25Et2f5mpyNBrUzsReH7rkPCtTZmYzQeLjrhRPpvdx
TLRFRS78sltKrWdul5Yznap2nWYaDi8MeQsru5JHKxk3JP36UugNB2Hk2bq9
bEJ0C9fp9KpcYTNmo/v7H16d7O/HVoOvhyA/xQwPP/b2908u6VZHfZyd7u9P
idt/irCC4ABxeSI8w0ftSKlfeqXULwPxHvj5BS+k7Y8a/v6VF0L/V0fqHlrP
L6x2X1g9B9yskAur7/8bhDLlluv2JV3f8Asv7rzw4usvfL4r0mf10M8vclk3
R3svV3VI69r6WCBoCM74CrqDiAKizWgkplsmGj8WZOfryDg8yWVkxz2RHhSP
tiFtmUI5gsM4Jg/bykgveCbdAz07cR86psKi6dj5cMNDgkn39uLgW+rnRsW2
MNe2NG2pba/+n9MllPVZ42keJfWOgffGp+lkuPtoFDTkZTQl4RvgD29n7UAH
/xHBQ2LEyaVuO5Uw6dhhbKCRE03Rw1V390oTLb63gUW1FxtVsGEcmDOItZVp
CuvXa8dkus9xysh0rskTpKPj2Rxv7sW0p+3Yh1e/e3OmKppORRJr9EJkpSvG
gSXndPNZFJ0tEe2pr65sShTLM8uCVZlWDgfeXST0fh8fE9G6e8xEkRVvRZvK
ZHtMYmTgRdYfNPA8Z6INpOHpleMmxD+wx6j8CDWirxDQHlh0cnRxSnhIW/VU
aTgkZpbXX59PlQ39bKQdAD/I3lBQ6Lsww5a+mzvwYBXLhYlRcdolpJDjTIKG
LR9riBsQE2AkvEb9HV86g/0ESSsy3ZXZou0bMANuv+i2uMp1MENeSbTtnvgZ
pfNgmg9dJKeZCnWNeU+IutAY7EJFNM8j+6SSPtyoFbEbvfTXS3wTMpIfIjO7
Gl4vDWr+eMZPY86ae2Buv+gLFvQ1DcN6d7PRQ/Irc3OYt5OGfFoPbzSn6KYZ
Ibl/1R01GY8tz+KUn64a6Y7e6Gsr31oZQGLLd+hOjT5wc2oqiJZ05A5gBPcS
hg/u3uItTZzTzzn79IJKpG/WVUyUvWNElg2HaOSbAtZYLLDdE3HwDd0xth4+
6T05AoRrCGI/XXV44AUSBGLxLEXiARHalrlDAJZfAEf3m7PvkaUR8+N9H10m
T/g9nm3oYkkMaLWW2bgZBiKFM+e77Hsxe3P6j7h3GyxtJ/U79yl73Hb1l2P9
uLvPBBXn9yZ/MrpNluhhyC0smlCazRRw6dwSS2Yg66aQnMldnPWVMht+180L
D5XE9sNsjlgQ0zjmNbuWcxSqttf7Y8gbNEjIcb3j1UXzyW5AluhLJK5K+8Vp
9zUt/M6q14T3OXX4Aze69nZzcMzgzX4Ovkaz0ZetHjwHt8bxQugr7tr50tVO
TreXWnHsEv0S+II7c9SrU3M0N2FjRl9M4AgVX+9xRyzAadbuOsZml8rxwnmY
awz4LDgTYZr2Z4Sc9yePWBm5wz11ii3nMNSaSynXLBaJvnRHX1trPNhPPbdQ
ut41yY5fZc7ch22bBFkLxU3kahl9R2s7GGv77qZl+PWzWIJ2or0zrRwSL28y
U4WYwqIXEzuJ5Dmgpf3iTwM4OJkNrp/46y+LpiYA5TbqKLsq3Qb9z1KGZreH
ZbOeU1H8XrrhCdopdBCXJ5f7+8l/AE9EdihvKgAA

-->

</rfc>
