<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" --> version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" category="std" consensus="true" docName="draft-ietf-dprive-xfr-over-tls-12" indexInclude="true" ipr="trust200902" number="9103" prepTime="2021-08-23T21:11:13" scripts="Common,Latin" sortRefs="true" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" symRefs="true" tocDepth="3" tocInclude="true" updates="1995, 5936, 7766" consensus="true"> xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls-12" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9103" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="XFR-over-TLS">DNS abbrev="XFR over TLS">DNS Zone Transfer-over-TLS</title><seriesInfo value="draft-ietf-dprive-xfr-over-tls-12" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo> Transfer over TLS</title>
    <seriesInfo name="RFC" value="9103" stream="IETF"/>
    <author initials="W." surname="Toorop" fullname="Willem Toorop"><organization>NLnet Labs</organization><address><postal><street></street> Toorop">
      <organization showOnFrontPage="true">NLnet Labs</organization>
      <address>
        <postal>
          <street>Science Park 400</street>
          <city>Amsterdam</city>
          <code>1098 XH</code>
<country>The Netherlands</country>
</postal><email>willem@nlnetlabs.nl</email>
</address></author>
          <country>Netherlands</country>
        </postal>
        <email>willem@nlnetlabs.nl</email>
      </address>
    </author>
    <author initials="S." surname="Dickinson" fullname="Sara Dickinson"><organization>Sinodun IT</organization><address><postal><street></street>
<street>Magdalen Centre</street> Dickinson">
      <organization showOnFrontPage="true">Sinodun IT</organization>
      <address>
        <postal>
          <extaddr>Magdalen Centre</extaddr>
          <street>Oxford Science Park</street>
          <city>Oxford</city>
          <code>OX4 4GA</code>
          <country>United Kingdom</country>
</postal><email>sara@sinodun.com</email>
</address></author>
        </postal>
        <email>sara@sinodun.com</email>
      </address>
    </author>
    <author initials="S." surname="Sahib" fullname="Shivan Sahib"><organization>Brave Software</organization><address><postal><street></street>
<city>Vancouver, BC</city> Sahib">
      <organization showOnFrontPage="true">Brave Software</organization>
      <address>
        <postal>
          <city>Vancouver</city>
          <region>BC</region>
          <country>Canada</country>
</postal><email>shivankaulsahib@gmail.com</email>
</address></author>
        </postal>
        <email>shivankaulsahib@gmail.com</email>
      </address>
    </author>
    <author initials="P." surname="Aras" fullname="Pallavi Aras"><organization>Salesforce</organization><address><postal><street></street>
<city>Herndon, VA</city> Aras">
      <organization showOnFrontPage="true">Salesforce</organization>
      <address>
        <postal>
          <city>Herndon</city>
          <region>VA</region>
          <country>United States</country>
</postal><email>paras@salesforce.com</email>
</address></author> States of America</country>
        </postal>
        <email>paras@salesforce.com</email>
      </address>
    </author>
    <author initials="A." surname="Mankin" fullname="Allison Mankin"><organization>Salesforce</organization><address><postal><street></street>
<city>Herndon, VA</city> Mankin">
      <organization showOnFrontPage="true">Salesforce</organization>
      <address>
        <postal>
          <city>Herndon</city>
          <region>VA</region>
          <country>United States</country>
</postal><email>allison.mankin@gmail.com</email>
</address></author> States of America</country>
        </postal>
        <email>allison.mankin@gmail.com</email>
      </address>
    </author>
    <date year="2021" month="May" day="26"></date> month="08" year="2021"/>
    <area>Internet</area>
    <workgroup>dprive</workgroup>
    <keyword>DNS</keyword>
    <keyword>operations</keyword>
    <keyword>privacy</keyword>

<abstract>
<t>DNS
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">DNS zone transfers are transmitted in clear text, cleartext, which gives attackers the
  opportunity to collect the content of a zone by eavesdropping on network
  connections. The DNS Transaction Signature (TSIG) mechanism is specified to
  restrict direct zone transfer to authorized clients only, but it does not add
  confidentiality. This document specifies the use of TLS, rather than clear
text, cleartext,
  to prevent zone content collection via passive monitoring of zone
  transfers: XFR-over-TLS XFR over TLS (XoT). Additionally, this specification updates RFC1995 RFC 1995
  and RFC5936 RFC 5936 with respect to efficient use of TCP connections, connections and RFC7766 RFC 7766 with
  respect to the recommended number of connections between a client and server
  for each transport.</t>
    </abstract>

</front>

<middle>
    <boilerplate>
      <section anchor="introduction"><name>Introduction</name>
<t>DNS has 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 is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a number product of privacy vulnerabilities, as discussed in detail in
<xref target="I-D.ietf-dprive-rfc7626-bis"></xref>. Stub client to recursive resolver query privacy the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received the
most attention to date, with standards track documents for both DNS-over-TLS
(DoT) <xref target="RFC7858"></xref> and DNS-over-HTTPS (DoH) <xref target="RFC8484"></xref>, and a proposal for
DNS-over-QUIC <xref target="I-D.ietf-dprive-dnsoquic"></xref>. There is ongoing work on DNS privacy
requirements for exchanges between recursive resolvers and authoritative
servers <xref target="I-D.ietf-dprive-phase2-requirements"></xref> public review and some suggestions has been approved for how
signaling of DoT support publication by authoritative nameservers might work. However, there
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is currently no available in Section 2 of
            RFC
that specifically defines recursive to authoritative DNS-over-TLS (ADoT).</t>
<t><xref target="I-D.ietf-dprive-rfc7626-bis"></xref> established that stub client DNS query
transactions are not public 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and needed protection, but how to provide feedback on zone transfer
<xref target="RFC1995"></xref> <xref target="RFC5936"></xref> it says only:</t>

<artwork>&quot;Privacy risks for may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9103" 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) 2021 IETF Trust and the holder of a zone (the risk that someone
gets persons identified as the data) are discussed in [RFC5936] and [RFC5155].&quot;
</artwork>
<t>In what way
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is exposing subject to BCP 78 and the full contents 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 a zone a privacy risk? The
contents
            publication of the zone could 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 information such Simplified BSD License text as names of persons used described in
names
            Section 4.e of hosts. Best practice is not to use personal information for domain
names, but many such domain names exist. The contents the Trust Legal Provisions and are provided without
            warranty as described in the Simplified 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>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" 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-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" 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-threat-model">Threat Model</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-design-considerations-for-x">Design Considerations for XoT</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-connection-and-data-flows-i">Connection and Data Flows in Existing XFR Mechanisms</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-axfr-mechanism">AXFR Mechanism</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ixfr-mechanism">IXFR Mechanism</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-data-leakage-of-notify-and-">Data Leakage of NOTIFY and SOA Message Exchanges</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.3.2">
                  <li pn="section-toc.1-1.5.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref derivedContent="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-notify">NOTIFY</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref derivedContent="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-soa">SOA</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </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-updates-to-existing-specifi">Updates to Existing Specifications</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-update-to-rfc-1995-for-ixfr">Update to RFC 1995 for IXFR over TCP</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-update-to-rfc-5936-for-axfr">Update to RFC 5936 for AXFR over TCP</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-updates-to-rfcs-1995-and-59">Updates to RFCs 1995 and 5936 for XFR over TCP</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.3.2">
                  <li pn="section-toc.1-1.6.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.3.2.1.1"><xref derivedContent="6.3.1" format="counter" sectionFormat="of" target="section-6.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-connection-reuse">Connection Reuse</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.3.2.2.1"><xref derivedContent="6.3.2" format="counter" sectionFormat="of" target="section-6.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-axfrs-and-ixfrs-on-the-same">AXFRs and IXFRs on the zone could also
include references Same Connection</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.6.2.3.2.3.1"><xref derivedContent="6.3.3" format="counter" sectionFormat="of" target="section-6.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-xfr-limits">XFR Limits</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.6.2.3.2.4.1"><xref derivedContent="6.3.4" format="counter" sectionFormat="of" target="section-6.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-edns-tcp-keepalive-edns">The edns-tcp-keepalive EDNS(0) Option</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.3.2.5">
                    <t indent="0" pn="section-toc.1-1.6.2.3.2.5.1"><xref derivedContent="6.3.5" format="counter" sectionFormat="of" target="section-6.3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-backwards-compatibility">Backwards Compatibility</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-update-to-rfc-7766">Update to locations that allow inference about location information RFC 7766</xref></t>
              </li>
            </ul>
          </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-xot-specification">XoT Specification</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-connection-establishment">Connection Establishment</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tls-versions">TLS Versions</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-port-selection">Port Selection</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-high-level-xot-descriptions">High-Level XoT Descriptions</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.5">
                <t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-xot-transfers">XoT Transfers</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.6">
                <t indent="0" pn="section-toc.1-1.7.2.6.1"><xref derivedContent="7.6" format="counter" sectionFormat="of" target="section-7.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-xot-connections">XoT Connections</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.7">
                <t indent="0" pn="section-toc.1-1.7.2.7.1"><xref derivedContent="7.7" format="counter" sectionFormat="of" target="section-7.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-xot-vs-adot">XoT vs. ADoT</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.8">
                <t indent="0" pn="section-toc.1-1.7.2.8.1"><xref derivedContent="7.8" format="counter" sectionFormat="of" target="section-7.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-response-rcodes">Response RCODES</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.9">
                <t indent="0" pn="section-toc.1-1.7.2.9.1"><xref derivedContent="7.9" format="counter" sectionFormat="of" target="section-7.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-axot-specifics">AXoT Specifics</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.9.2">
                  <li pn="section-toc.1-1.7.2.9.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.9.2.1.1"><xref derivedContent="7.9.1" format="counter" sectionFormat="of" target="section-7.9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-padding-axot-responses">Padding AXoT Responses</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.10">
                <t indent="0" pn="section-toc.1-1.7.2.10.1"><xref derivedContent="7.10" format="counter" sectionFormat="of" target="section-7.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-ixot-specifics">IXoT Specifics</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.10.2">
                  <li pn="section-toc.1-1.7.2.10.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.10.2.1.1"><xref derivedContent="7.10.1" format="counter" sectionFormat="of" target="section-7.10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-condensation-of-responses">Condensation of the individuals associated with the zone's organization. It could also
include references Responses</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.10.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.10.2.2.1"><xref derivedContent="7.10.2" format="counter" sectionFormat="of" target="section-7.10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fallback-to-axfr">Fallback to other organizations. Examples AXFR</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.10.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.10.2.3.1"><xref derivedContent="7.10.3" format="counter" sectionFormat="of" target="section-7.10.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-padding-of-ixot-responses">Padding of this could be:</t>

<ul>
<li>Person-laptop.example.org</li>
<li>MX-for-Location.example.org</li>
<li>Service-tenant-from-another-org.example.org</li> IXoT Responses</xref></t>
                  </li>
                </ul>
<t>Additionally, the full zone contents expose all
              </li>
              <li pn="section-toc.1-1.7.2.11">
                <t indent="0" pn="section-toc.1-1.7.2.11.1"><xref derivedContent="7.11" format="counter" sectionFormat="of" target="section-7.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-name-compression-and-maximu">Name Compression and Maximum Payload Sizes</xref></t>
              </li>
            </ul>
          </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-multi-primary-configuration">Multi-primary Configurations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authentication-mechanisms">Authentication Mechanisms</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tsig">TSIG</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sig0">SIG(0)</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.3">
                <t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent="9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tls">TLS</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2.3.2">
                  <li pn="section-toc.1-1.9.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.9.2.3.2.1.1"><xref derivedContent="9.3.1" format="counter" sectionFormat="of" target="section-9.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-opportunistic-tls">Opportunistic TLS</xref></t>
                  </li>
                  <li pn="section-toc.1-1.9.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.9.2.3.2.2.1"><xref derivedContent="9.3.2" format="counter" sectionFormat="of" target="section-9.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-strict-tls">Strict TLS</xref></t>
                  </li>
                  <li pn="section-toc.1-1.9.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.9.2.3.2.3.1"><xref derivedContent="9.3.3" format="counter" sectionFormat="of" target="section-9.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mutual-tls">Mutual TLS</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.9.2.4">
                <t indent="0" pn="section-toc.1-1.9.2.4.1"><xref derivedContent="9.4" format="counter" sectionFormat="of" target="section-9.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ip-based-acl-on-the-primary">IP-Based ACL on the Primary</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.5">
                <t indent="0" pn="section-toc.1-1.9.2.5.1"><xref derivedContent="9.5" format="counter" sectionFormat="of" target="section-9.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-zonemd">ZONEMD</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-xot-authentication">XoT Authentication</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-policies-for-both-axot-and-">Policies for Both AXoT and IXoT</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-implementation-consideratio">Implementation Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-considerations">Operational Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" format="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="15" format="counter" sectionFormat="of" target="section-15"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.16">
            <t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="16" format="counter" sectionFormat="of" target="section-16"/>. <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.16.2">
              <li pn="section-toc.1-1.16.2.1">
                <t indent="0" pn="section-toc.1-1.16.2.1.1"><xref derivedContent="16.1" format="counter" sectionFormat="of" target="section-16.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.16.2.2">
                <t indent="0" pn="section-toc.1-1.16.2.2.1"><xref derivedContent="16.2" format="counter" sectionFormat="of" target="section-16.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.17">
            <t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-xot-server-connection-handl">XoT Server Connection Handling</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.17.2">
              <li pn="section-toc.1-1.17.2.1">
                <t indent="0" pn="section-toc.1-1.17.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-listening-only-on-a-specifi">Listening Only on a Specific IP addresses Address for TLS</xref></t>
              </li>
              <li pn="section-toc.1-1.17.2.2">
                <t indent="0" pn="section-toc.1-1.17.2.2.1"><xref derivedContent="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-client-specific-tls-accepta">Client-Specific TLS Acceptance</xref></t>
              </li>
              <li pn="section-toc.1-1.17.2.3">
                <t indent="0" pn="section-toc.1-1.17.2.3.1"><xref derivedContent="A.3" format="counter" sectionFormat="of" target="section-appendix.a.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sni-based-tls-acceptance">SNI-Based TLS Acceptance</xref></t>
              </li>
              <li pn="section-toc.1-1.17.2.4">
                <t indent="0" pn="section-toc.1-1.17.2.4.1"><xref derivedContent="A.4" format="counter" sectionFormat="of" target="section-appendix.a.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-transport-specific-response">Transport-Specific Response Policies</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.17.2.4.2">
                  <li pn="section-toc.1-1.17.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.17.2.4.2.1.1"><xref derivedContent="A.4.1" format="counter" sectionFormat="of" target="section-appendix.a.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sni-based-response-policies">SNI-Based Response Policies</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.18">
            <t indent="0" pn="section-toc.1-1.18.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.19">
            <t indent="0" pn="section-toc.1-1.19.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.20">
            <t indent="0" pn="section-toc.1-1.20.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</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">DNS has a number of endpoints
held privacy vulnerabilities, as discussed in detail in
  <xref target="RFC9076" format="default" sectionFormat="of" derivedContent="RFC9076"/>. Query privacy between stub resolvers and recursive resolvers has received
  the most attention to date, with Standards Track documents for both DNS records which can make reconnaissance over TLS
  (DoT) <xref target="RFC7858" format="default" sectionFormat="of" derivedContent="RFC7858"/> and attack targeting easier, particularly DNS over HTTPS (DoH) <xref target="RFC8484" format="default" sectionFormat="of" derivedContent="RFC8484"/>
  and a proposal for
IPv6 addresses or private networks.
  DNS over QUIC <xref target="I-D.ietf-dprive-dnsoquic" format="default" sectionFormat="of" derivedContent="DPRIVE-DNSOQUIC"/>. There may also be regulatory, policy or other reasons why is ongoing work on DNS
  privacy
  requirements for exchanges between recursive resolvers and authoritative
  servers and some suggestions for
  how signaling of DoT support by authoritative name servers might work. However, there is
  currently no RFC that specifically defines recursive-to-authoritative DNS over TLS
  (ADoT).</t>
      <t indent="0" pn="section-1-2"><xref target="RFC9076" format="default" sectionFormat="of" derivedContent="RFC9076"/> establishes that a stub resolver's DNS query
  transactions are not public and that they need protection, but, on zone transfer
  <xref target="RFC1995" format="default" sectionFormat="of" derivedContent="RFC1995"/> <xref target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/>, it says only:</t>
      <blockquote pn="section-1-3">Privacy risks for the holder of a zone (the risk that someone
  gets the data) are discussed in <xref target="RFC5155" format="default" sectionFormat="of" derivedContent="RFC5155"/> and <xref target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/>.</blockquote>
      <t indent="0" pn="section-1-4">In what way is exposing the full contents of a zone a privacy risk? The
  contents of the zone could include information such as names of persons used in
  names of hosts. Best practice is not to use personal information for domain
  names, but many such domain names exist. The contents of the zone could also
  include references to locations that allow inference about location information
  of the individuals associated with the zone's organization. It could also
  include references to other organizations. Examples of this could be:</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1-5">
        <li pn="section-1-5.1">Person-laptop.example.org</li>
        <li pn="section-1-5.2">MX-for-Location.example.org</li>
        <li pn="section-1-5.3">Service-tenant-from-another-org.example.org</li>
      </ul>
      <t indent="0" pn="section-1-6">Additionally, the full zone contents expose all the IP addresses of endpoints
  held in the DNS records, which can make reconnaissance and attack targeting easier,
  particularly
  for IPv6 addresses or private networks. There may also be regulatory, policy, or other
  reasons why the zone contents in full must be treated as private.</t>
<t>Neither
      <t indent="0" pn="section-1-7">Neither of the RFCs mentioned in <xref target="I-D.ietf-dprive-rfc7626-bis"></xref>
contemplates target="RFC9076" format="default" sectionFormat="of" derivedContent="RFC9076"/>
  contemplate the risk that someone gets the data through eavesdropping on
  network connections, only via enumeration or unauthorized transfer transfer, as described
  in the following paragraphs.</t>
<t>Zone
      <t indent="0" pn="section-1-8">Zone enumeration is trivially possible for DNSSEC zones which that use NSEC; i.e. NSEC, i.e.,
  queries for the authenticated denial of existence denial-of-existence records allow a client to
  walk through the entire zone contents. <xref target="RFC5155"></xref> target="RFC5155" format="default" sectionFormat="of" derivedContent="RFC5155"/> specifies NSEC3, a
  mechanism to provide measures against zone enumeration for DNSSEC signed DNSSEC-signed zones (a goal
  was to make it as hard to enumerate a DNSSEC signed DNSSEC-signed zone as an unsigned zone).
  Whilst this is widely used, it has been demonstrated that zone walking is
  possible for precomputed NSEC3 using attacks attacks, such as those described in
  <xref target="NSEC3-attacks"></xref>. target="NSEC3-attacks" format="default" sectionFormat="of" derivedContent="NSEC3-attacks"/>. This prompted further work on an alternative
  mechanism for DNSSEC authenticated DNSSEC-authenticated denial of existence - NSEC5 (NSEC5
  <xref target="I-D.vcelak-nsec5"></xref> - however target="I-D.vcelak-nsec5" format="default" sectionFormat="of" derivedContent="NSEC5"/>); however, questions remain over the practicality of
  this mechanism.</t>
<t><xref target="RFC5155"></xref>
      <t indent="0" pn="section-1-9"><xref target="RFC5155" format="default" sectionFormat="of" derivedContent="RFC5155"/> does not address data obtained outside zone enumeration (nor
  does <xref target="I-D.vcelak-nsec5"></xref>). target="I-D.vcelak-nsec5" format="default" sectionFormat="of" derivedContent="NSEC5"/>). Preventing eavesdropping of zone transfers (this (as
  described in this document) is orthogonal to preventing zone enumeration, though they aim to
  protect the same information.</t>
<t><xref target="RFC5936"></xref>
      <t indent="0" pn="section-1-10"><xref target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/> specifies using TSIG <xref target="RFC8945"></xref> target="RFC8945" format="default" sectionFormat="of" derivedContent="RFC8945"/> for
  authorization of the clients
  of a zone transfer and for data integrity, integrity but does not express any need for
  confidentiality, and TSIG does not offer encryption.</t>
<t>Section
      <t indent="0" pn="section-1-11">Section 8 of the NIST guide on 'Secure document "Secure Domain Name System (DNS) Deployment' Deployment Guide"
  <xref target="nist-guide"></xref> target="NIST-GUIDE" format="default" sectionFormat="of" derivedContent="NIST-GUIDE"/> discusses restricting access for zone transfers using ACLs
  Access Control Lists (ACLs) and
  TSIG in more detail. It also discusses the possibility that specific deployments
  might choose to use a lower level lower-level network layer to protect zone transfers, e.g., IPSec.</t>
<t>It IPsec.</t>
      <t indent="0" pn="section-1-12">It is noted that in all the common open source open-source implementations
  such ACLs are applied on a per query per-query basis (at the time of writing). Since requests
  typically occur on TCP connections authoritatives connections, authoritative servers must therefore accept any TCP connection
  and then handling handle the authentication of each zone transfer (XFR) request individually.</t>
<t>Because
      <t indent="0" pn="section-1-13">Because both AXFR (authoritative transfer) and IXFR (incremental zone transfer) are
  typically carried out over TCP
  from authoritative DNS protocol implementations, encrypting zone transfers
  using TLS <xref target="RFC8499"></xref>, target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/> -- based closely on DoT <xref target="RFC7858"></xref>, target="RFC7858" format="default" sectionFormat="of" derivedContent="RFC7858"/> -- seems like a simple step forward.
  This document specifies how to use TLS (1.3 or later) as a transport to prevent zone
  collection from zone transfers.</t>
<t>This
      <t indent="0" pn="section-1-14">This document also updates the previous specifications for zone transfers to
  clarify and extend them, mainly with respect to TCP usage:</t>

<ul>
<li><eref target="IXFR">RFC1995</eref> and <eref target="AXFR">RFC5936</eref>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1-15">
        <li pn="section-1-15.1">
          <xref target="RFC1995" format="default" sectionFormat="of" derivedContent="RFC1995"/> (IXFR) and <xref target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/> (AXFR) are both updated to add further
    specification on efficient use of TCP connections</li>
<li>Section 6.2.2 of <eref target="DNS connections.</li>
        <li pn="section-1-15.2">
          <xref target="RFC7766" sectionFormat="of" section="6.2.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7766#section-6.2.2" derivedContent="RFC7766"/> ("DNS Transport over TCP -
    Implementation
Requirements">RFC7766</eref> Requirements") is updated with a new recommendation about
    the number of connections between a client and server for each transport.</li>
      </ul>
    </section>
    <section anchor="document-work-via-github"><name>Document work via GitHub</name>
<t>[THIS SECTION TO BE REMOVED BEFORE PUBLICATION] anchor="terminology" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">
    The Github repository for this
document is at <eref target="https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls">https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls</eref>.
Proposed text and editorial changes are very much welcomed there, but any
functional changes should always first be discussed on the IETF DPRIVE WG (dns-privacy) mailing list.</t>
</section>

<section anchor="terminology"><name>Terminology</name>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;,
&quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and &quot;OPTIONAL&quot; "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119"></xref>
<xref target="RFC8174"></xref> target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t>
<t>Privacy here.
      </t>
      <t indent="0" pn="section-2-2">Privacy terminology is as described in Section 3 of <xref target="RFC6973"></xref>.</t>
<t>DNS target="RFC6973" sectionFormat="of" section="3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6973#section-3" derivedContent="RFC6973"/>.</t>
      <t indent="0" pn="section-2-3">DNS terminology is as described in <xref target="RFC8499"></xref>. target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>. Note that that, as in
	<xref target="RFC8499"></xref>, target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>, the
	terms 'primary' and 'secondary' are used for two servers engaged in zone transfers.</t>
<t>DoT: DNS-over-TLS
      <dl newline="false" spacing="normal" indent="7" pn="section-2-4">
        <dt pn="section-2-4.1">DoT:</dt>
        <dd pn="section-2-4.2">DNS over TLS, as specified in <xref target="RFC7858"></xref></t>
<t>XFR-over-TCP: Used target="RFC7858" format="default" sectionFormat="of" derivedContent="RFC7858"/></dd>
        <dt pn="section-2-4.3">XFR over TCP:</dt>
        <dd pn="section-2-4.4">Used to mean both IXFR-over-TCP IXFR over TCP <xref target="RFC1995"></xref> target="RFC1995" format="default" sectionFormat="of" derivedContent="RFC1995"/>
	  and AXFR-over-TCP AXFR over TCP <xref target="RFC5936"></xref>.</t>
<t>XoT: XFR-over-TLS mechanisms target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/></dd>
        <dt pn="section-2-4.5">XoT:</dt>
        <dd pn="section-2-4.6">XFR-over-TLS mechanisms, as specified in this document document, which apply
	  to both AXFR-over-TLS AXFR over TLS and IXFR-over-TLS</t>
<t>AXoT: AXFR-over-TLS</t>
<t>IXoT: IXFR over-TLS</t> over TLS (XoT is pronounced 'zot' since X here
	  stands for 'zone transfer')</dd>
        <dt pn="section-2-4.7">AXoT:</dt>
        <dd pn="section-2-4.8">AXFR over TLS</dd>
        <dt pn="section-2-4.9">IXoT:</dt>
        <dd pn="section-2-4.10">IXFR over TLS</dd>
      </dl>
    </section>
    <section anchor="threat-model"><name>Threat anchor="threat-model" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-threat-model">Threat Model</name>
<t>The
      <t indent="0" pn="section-3-1">The threat model considered here is one where the current contents and size of the zone are
  considered sensitive and should be protected during transfer.</t>
<t>The
      <t indent="0" pn="section-3-2">The threat model does not, however, consider the existence of a zone, the act of
  zone transfer between two entities, nor the identities of the nameservers name servers
  hosting a zone (including both those acting as hidden primaries/secondaries
  or directly serving the zone) as sensitive information. The proposed mechanism
  does not attempt to obscure such information. The reasons for this include:</t>

<ul>
<li>much
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3-3">
        <li pn="section-3-3.1">much of this information can be obtained by various methods,
    including active scanning of the DNS</li>
<li>an DNS, and</li>
        <li pn="section-3-3.2">an attacker who can monitor network traffic can relatively rather
    easily infer relations between
nameservers name servers simply from traffic
    patterns, even when some or all of the traffic is encrypted
    (in terms of current deployments)</li> deployments).</li>
      </ul>
<t>The
      <t indent="0" pn="section-3-4">The model does not consider attacks on the mechanisms that trigger a zone transfer, e.g.,
  NOTIFY messages.</t>
<t>It
      <t indent="0" pn="section-3-5">It is noted that simply using XoT will indicate a desire by the zone owner that the
  contents of the zone remain confidential and so could be subject to blocking (e.g., via
  blocking of port 853) if an attacker had
  such capabilities. However However, this threat is likely true of any such mechanism that attempts to
  encrypt data passed between nameservers, name servers, e.g., IPsec.</t>
    </section>
    <section anchor="design-considerations-for-xot"><name>Design anchor="design-considerations-for-xot" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-design-considerations-for-x">Design Considerations for XoT</name>
<t>The
      <t indent="0" pn="section-4-1">The following principles were considered in the design for XoT:</t>

<ul>
<li><t>Confidentiality. Clearly
      <dl newline="false" spacing="normal" indent="3" pn="section-4-2">
        <dt pn="section-4-2.1">Confidentiality:</dt>
        <dd pn="section-4-2.2">Clearly using an encrypted transport for zone transfers will
    defeat zone content leakage that can occur via passive surveillance.</t>
</li>
<li><t>Authentication. Use surveillance.</dd>
        <dt pn="section-4-2.3">Authentication:</dt>
        <dd pn="section-4-2.4">Use of single or mutual TLS (mTLS) authentication (in combination
    with access control lists (ACLs)) ACLs) can complement and potentially be an
    alternative to TSIG.</t>
</li>
<li><t>Performance.</t>

<ul>
<li>Existing TSIG.</dd>
        <dt pn="section-4-2.5">Performance:</dt>
        <dd pn="section-4-2.6">
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4-2.6.1">
            <li pn="section-4-2.6.1.1">Existing AXFR and IXFR mechanisms have the burden of backwards
	compatibility with older implementations based on the original specifications
	in <xref target="RFC1034"></xref> target="RFC1034" format="default" sectionFormat="of" derivedContent="RFC1034"/> and <xref target="RFC1035"></xref>. target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/>. For example,
	some older AXFR servers don’t don't
	support using a TCP connection for multiple AXFR sessions or XFRs of different
	zones because they have not been updated to follow the guidance in <xref target="RFC5936"></xref>. target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/>.
	Any implementation of XoT would obviously be required to
	implement optimized and interoperable transfers transfers, as described in <xref target="RFC5936"></xref>, target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/>,
	e.g., transfer of multiple zones over one connection.</li>
<li>Current
            <li pn="section-4-2.6.1.2">Current usage of TCP for IXFR is sub-optimal suboptimal in some cases i.e. cases, i.e.,
	connections are frequently closed after a single IXFR.</li>
</ul></li>
          </ul>
        </dd>
      </dl>
    </section>
    <section anchor="connection-and-data-flows-in-existing-xfr-mechanisms"><name>Connection anchor="connection-and-data-flows-in-existing-xfr-mechanisms" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-connection-and-data-flows-i">Connection and Data Flows in Existing XFR Mechanisms</name>
<t>The
      <t indent="0" pn="section-5-1">The original specification for zone transfers in <xref target="RFC1034"></xref> target="RFC1034" format="default" sectionFormat="of" derivedContent="RFC1034"/> and <xref target="RFC1035"></xref> target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/> was
  based on a polling mechanism: a secondary performed a periodic query for the SOA (start of
  zone authority) record (based
  on the refresh timer) to determine if an AXFR was required.</t>
<t><xref target="RFC1995"></xref>
      <t indent="0" pn="section-5-2"><xref target="RFC1995" format="default" sectionFormat="of" derivedContent="RFC1995"/> and <xref target="RFC1996"></xref> target="RFC1996" format="default" sectionFormat="of" derivedContent="RFC1996"/> introduced the concepts
  of IXFR and NOTIFY NOTIFY,
  respectively, to provide for prompt propagation of zone updates. This has
  largely replaced AXFR where possible, particularly for dynamically updated
  zones.</t>
<t><xref target="RFC5936"></xref>
      <t indent="0" pn="section-5-3"><xref target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/> subsequently redefined the specification of AXFR to improve
  performance and interoperability.</t>
<t>In
      <t indent="0" pn="section-5-4">In this document we use document, the term &quot;XFR mechanism&quot; 'XFR mechanism' is used to describe the entire set of
  message exchanges between a secondary and a primary that concludes in with a
  successful AXFR or IXFR request/response. This set may or may not include</t>

<ul>
<li>NOTIFY include:</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-5-5">
        <li pn="section-5-5.1">NOTIFY messages</li>
<li>SOA
        <li pn="section-5-5.2">SOA queries</li>
<li>Fallback
        <li pn="section-5-5.3">Fallback from IXFR to AXFR</li>
<li>Fallback
        <li pn="section-5-5.4">Fallback from IXFR-over-UDP IXFR over UDP to IXFR-over-TCP</li> IXFR over TCP</li>
      </ul>
<t>The
      <t indent="0" pn="section-5-6">The term is used to encompass the range of permutations that are possible and
  is useful to distinguish the 'XFR mechanism' from a single XFR
  request/response exchange.</t>
      <section anchor="axfr-mechanism"><name>AXFR anchor="axfr-mechanism" numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-axfr-mechanism">AXFR Mechanism</name>
<t>The
        <t indent="0" pn="section-5.1-1">The figure below provides an outline of an AXFR mechanism including NOTIFYs.</t>

<artwork>
        <figure anchor="fig1" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-axfr-mechanism-2">AXFR Mechanism</name>
          <artwork name="" type="" alt="" align="left" pn="section-5.1-2.1">
   Secondary                            Primary

       |              NOTIFY               |
       | &lt;-------------------------------- |  UDP
       | --------------------------------&gt; |
       |          NOTIFY Response          |
       |                                   |
       |                                   |
       |            SOA Request            |
       | --------------------------------&gt; |  UDP (or part of
       | &lt;-------------------------------- |  a TCP session)
       |           SOA Response            |
       |                                   |
       |                                   |
       |                                   |
       |            AXFR Request           | ---
       | --------------------------------&gt; |   |
       | &lt;-------------------------------- |   |
       |          AXFR Response 1          |   |
       |             (Zone data)           |   |
       |                                   |   |
       | &lt;-------------------------------- |   | TCP
       |          AXFR Response 2          |   | Session
       |             (Zone data)           |   |
       |                                   |   |
       | &lt;-------------------------------- |   |
       |          AXFR Response 3          |   |
       |             (Zone data)           | ---
       |                                   |

              Figure 1. AXFR Mechanism
</artwork>

<ol>
<li><t>An
        </figure>
        <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-5.1-3">
  <li pn="section-5.1-3.1" derivedCounter="1.">An AXFR is often (but not always) preceded by a NOTIFY (over UDP) from the
  primary to the secondary. A secondary may also initiate an AXFR based on a
  refresh timer or scheduled/triggered zone maintenance.</t>
</li>
<li><t>The maintenance.</li>
          <li pn="section-5.1-3.2" derivedCounter="2.">The secondary will normally (but not always) make a an SOA query to the primary
  to obtain the serial number of the zone held by the primary.</t>
</li>
<li><t>If primary.</li>
          <li pn="section-5.1-3.3" derivedCounter="3.">If the primary serial is higher than the secondary's serial (using Serial
  Number Arithmetic <xref target="RFC1982"></xref>), target="RFC1982" format="default" sectionFormat="of" derivedContent="RFC1982"/>), the secondary makes an AXFR request
  (over TCP)
  to the primary primary, after which the AXFR data flows in one or more AXFR responses on
  the TCP connection. <xref target="RFC5936"></xref> target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/> defines this specific step as an 'AXFR session'
i.e.
  session',
  i.e., as an AXFR query message and the sequence of AXFR response messages
  returned for it.</t>
</li> it.</li>
        </ol>
<t><xref target="RFC5936"></xref>
        <t indent="0" pn="section-5.1-4"><xref target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/> re-specified AXFR AXFR, providing additional guidance beyond that
provided in <xref target="RFC1034"></xref> target="RFC1034" format="default" sectionFormat="of" derivedContent="RFC1034"/> and <xref target="RFC1035"></xref> target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/> and importantly
specified that AXFR must use TCP as the transport protocol.</t>
<t>Additionally, sections 4.1, 4.1.1 and 4.1.2 of <xref target="RFC5936"></xref>
        <t indent="0" pn="section-5.1-5">Additionally, Sections <xref target="RFC5936" section="4.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5936#section-4.1" derivedContent="RFC5936"/>, <xref target="RFC5936" section="4.1.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5936#section-4.1.1" derivedContent="RFC5936"/>, and <xref target="RFC5936" section="4.1.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5936#section-4.1.2" derivedContent="RFC5936"/> of <xref target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/> provide improved
guidance for AXFR clients and servers with regard to re-use reuse of TCP connections
for multiple AXFRs and AXFRs of different zones. However However, <xref target="RFC5936"></xref> target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/> was
constrained by having to be backwards compatible with some very early basic
implementations of AXFR. For example, it outlines that the SOA query can also
happen on this connection. However, this can cause interoperability problems
with older implementations that support only the trivial case of one AXFR per
connection.</t>
      </section>
      <section anchor="ixfr-mechanism"><name>IXFR anchor="ixfr-mechanism" numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-ixfr-mechanism">IXFR Mechanism</name>
<t>The
        <t indent="0" pn="section-5.2-1">The figure below provides an outline of the IXFR mechanism including NOTIFYs.</t>

<artwork>
        <figure anchor="fig2" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-ixfr-mechanism-2">IXFR Mechanism</name>
          <artwork name="" type="" alt="" align="left" pn="section-5.2-2.1">
   Secondary                            Primary

       |              NOTIFY               |
       | &lt;-------------------------------- |  UDP
       | --------------------------------&gt; |
       |          NOTIFY Response          |
       |                                   |
       |                                   |
       |            SOA Request            |
       | --------------------------------&gt; |  UDP or TCP
       | &lt;-------------------------------- |
       |           SOA Response            |
       |                                   |
       |                                   |
       |                                   |
       |            IXFR Request           |
       | --------------------------------&gt; |  UDP or TCP
       | &lt;-------------------------------- |
       |            IXFR Response          |
       |             (Zone data)           |
       |                                   |
       |                                   | ---
       |            IXFR Request           |    |
       | --------------------------------&gt; |    | Retry over
       | &lt;-------------------------------- |    | TCP if
       |            IXFR Response          |    | required
       |             (Zone data)           | ---

              Figure 2. IXFR Mechanism
</artwork>

<ol>
<li><t>An
        </figure>
        <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-5.2-3">
  <li pn="section-5.2-3.1" derivedCounter="1.">An IXFR is normally (but not always) preceded by a NOTIFY (over UDP) from the
  primary to the secondary. A secondary may also initiate an IXFR based on a
  refresh timer or scheduled/triggered zone maintenance.</t>
</li>
<li><t>The maintenance.</li>
          <li pn="section-5.2-3.2" derivedCounter="2.">The secondary will normally (but not always) make a an SOA query to the primary
  to obtain the serial number of the zone held by the primary.</t>
</li>
<li><t>If primary.</li>
          <li pn="section-5.2-3.3" derivedCounter="3.">If the primary serial is higher than the secondaries secondary's serial (using Serial
  Number Arithmetic <xref target="RFC1982"></xref>), target="RFC1982" format="default" sectionFormat="of" derivedContent="RFC1982"/>), the secondary makes an IXFR request to
  the
primary primary, after which the primary sends an IXFR response.</t>
</li> response.</li>
        </ol>
<t><xref target="RFC1995"></xref>
        <t indent="0" pn="section-5.2-4"><xref target="RFC1995" format="default" sectionFormat="of" derivedContent="RFC1995"/> specifies that Incremental Transfer IXFR may use UDP if the entire IXFR
response can be contained in a single DNS packet, otherwise, TCP is used. In
fact
fact, it says:</t>

<artwork>&quot;Thus,
        <blockquote pn="section-5.2-5">Thus, a client should first make an IXFR query using UDP.&quot;
</artwork>
<t>So UDP.</blockquote>
        <t indent="0" pn="section-5.2-6">So there may be a fourth step above where the client falls back to IXFR-over-TCP. IXFR over TCP.
There may also be a an additional step where the secondary must fall back to AXFR
because, e.g., the primary does not support IXFR.</t>
<t>However
        <t indent="0" pn="section-5.2-7">However, it is noted that most of the widely used open source authoritative nameserver open-source implementations of authoritative name servers
(including both <xref target="BIND"></xref> target="BIND" format="default" sectionFormat="of" derivedContent="BIND"/> and <xref target="NSD"></xref>) target="NSD" format="default" sectionFormat="of" derivedContent="NSD"/>) do IXFR using TCP by default
in their latest releases. For BIND, TCP connections are sometimes used for SOA
queries but
queries, but, in general general, they are not used persistently and close are closed after an IXFR
is completed.</t>
      </section>
      <section anchor="data-leakage-of-notify-and-soa-message-exchanges"><name>Data anchor="data-leakage-of-notify-and-soa-message-exchanges" numbered="true" removeInRFC="false" toc="include" pn="section-5.3">
        <name slugifiedName="name-data-leakage-of-notify-and-">Data Leakage of NOTIFY and SOA Message Exchanges</name>
<t>This
        <t indent="0" pn="section-5.3-1">This section presents a rationale for considering encrypting the encryption of the other
  messages in the XFR mechanism.</t>
<t>Since
        <t indent="0" pn="section-5.3-2">Since the SOA of the published zone can be trivially discovered by simply
  querying the publicly available authoritative servers, leakage of this resource record (RR)
  via such a
  direct query is not discussed in the following sections.</t>
        <section anchor="notify"><name>NOTIFY</name>
<t>Unencrypted anchor="notify" numbered="true" removeInRFC="false" toc="include" pn="section-5.3.1">
          <name slugifiedName="name-notify">NOTIFY</name>
          <t indent="0" pn="section-5.3.1-1">Unencrypted NOTIFY messages identify configured secondaries on the primary.</t>
<t><xref target="RFC1996"></xref>
          <t indent="0" pn="section-5.3.1-2"><xref target="RFC1996" format="default" sectionFormat="of" derivedContent="RFC1996"/> also states:</t>

<artwork>&quot;If
          <blockquote pn="section-5.3.1-3">If ANCOUNT&gt;0, then the answer section represents an
  unsecure hint at the new RRset for this (QNAME,QCLASS,QTYPE).
</artwork>
<t>But &lt;QNAME,QCLASS,QTYPE&gt;.</blockquote>
          <t indent="0" pn="section-5.3.1-4">But since the only QTYPE query type (QTYPE) for NOTIFY defined at the time of this writing
  is SOA, this does not pose a
  potential leak.</t>
        </section>
        <section anchor="soa"><name>SOA</name>
<t>For anchor="soa" numbered="true" removeInRFC="false" toc="include" pn="section-5.3.2">
          <name slugifiedName="name-soa">SOA</name>
          <t indent="0" pn="section-5.3.2-1">For hidden XFR servers (either primaries or secondaries), an SOA response
  directly from that server only additionally leaks the degree of SOA serial
  number lag of any downstream secondary of that server.</t>
        </section>
      </section>
    </section>
    <section anchor="updates-to-existing-specifications"><name>Updates anchor="updates-to-existing-specifications" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-updates-to-existing-specifi">Updates to existing specifications</name>
<t>For Existing Specifications</name>
      <t indent="0" pn="section-6-1">For convenience, the term 'XFR-over-TCP' 'XFR over TCP' is used in this document to mean both
IXFR-over-TCP and AXFR-over-TCP
  IXFR over TCP and therefore AXFR over TCP; therefore, statements that use that term update
  both <xref target="RFC1995"></xref> target="RFC1995" format="default" sectionFormat="of" derivedContent="RFC1995"/> and <xref target="RFC5936"></xref>, target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/> and implicitly also
  apply to XoT. Differences in behavior specific to XoT are discussed in
  <xref target="xot-specification"></xref>.</t>
<t>Both <xref target="RFC1995"></xref> and <xref target="RFC5936"></xref> target="xot-specification" format="default" sectionFormat="of" derivedContent="Section 7"/>.</t>
      <t indent="0" pn="section-6-2">Both <xref target="RFC1995" format="default" sectionFormat="of" derivedContent="RFC1995"/> and <xref target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/> were published
  sometime before TCP was
considered became a first class widely supported transport for DNS. <xref target="RFC1995"></xref>, target="RFC1995" format="default" sectionFormat="of" derivedContent="RFC1995"/>, in fact, says nothing
  with respect to optimizing IXFRs over TCP or re-using reusing already open TCP
  connections to perform IXFRs or other queries. Therefore, there arguably is an
  implicit assumption that a TCP connection is used for
  one and only one IXFR request. Indeed, many major open source open-source implementations
  take this approach (at the time of this writing). And whilst <xref target="RFC5936"></xref> target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/>
  gives guidance on
  connection re-use reuse for AXFR, it pre-dates predates more recent specifications describing
  persistent TCP connections (e.g., <xref target="RFC7766"></xref>, <xref target="RFC7828"></xref>), target="RFC7766" format="default" sectionFormat="of" derivedContent="RFC7766"/>, <xref target="RFC7828" format="default" sectionFormat="of" derivedContent="RFC7828"/>), and AXFR implementations again
  often make less than optimal less-than-optimal use of open connections.</t>
<t>Given
      <t indent="0" pn="section-6-3">Given this, new implementations of XoT will clearly benefit from specific guidance on
  TCP/TLS connection usage for XFR, because this will:</t>

<ul>
<li>result
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6-4">
        <li pn="section-6-4.1">result in more consistent XoT implementations with better interoperability</li>
<li>remove interoperability and</li>
        <li pn="section-6-4.2">remove any need for XoT implementations to support legacy behavior for XoT connections
  that XFR-over-TCP implementations have historically often supported</li> supported.</li>
      </ul>
<t>Therefore
      <t indent="0" pn="section-6-5">Therefore, this document updates both the previous specifications for
XFR-over-TCP ([RFC1995]
XFR over TCP (<xref target="RFC1995" format="default" sectionFormat="of" derivedContent="RFC1995"/> and [RFC5936]) <xref target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/>) to clarify that</t>

<ul>
<li><t>Implementations MUST use <xref target="RFC7766"></xref> (DNS that:</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6-6">
        <li pn="section-6-6.1">Implementations <bcp14>MUST</bcp14> use <xref target="RFC7766" format="default" sectionFormat="of" derivedContent="RFC7766"/> ("DNS Transport
  over TCP - Implementation
Requirements) Requirements") to optimize the use of TCP connections.</t>
</li>
<li><t>Whilst RFC7766 connections.</li>
        <li pn="section-6-6.2">Whilst <xref target="RFC7766" format="default" sectionFormat="of" derivedContent="RFC7766"/> states that 'DNS "DNS clients SHOULD
  <bcp14>SHOULD</bcp14> pipeline their queries’ queries"
  on TCP connections, it did not distinguish between XFRs and other queries for this
  behavior. It is now recognized that XFRs are not as latency sensitive as
  other queries, queries and can be significantly more complex for clients to handle,
  both because of the large amount of state that must be kept and because there
  may be multiple messages in the responses. For these reasons, it is clarified
  here that a valid reason for not pipelining queries is when they are all XFR
queries i.e.
  queries, i.e., clients sending multiple XFRs MAY <bcp14>MAY</bcp14> choose not to pipeline those
  queries. Clients that do not pipeline XFR queries, therefore, queries therefore have no
  additional requirements to handle out-of-order or intermingled responses (as
  described later), since they will never receive them.</t>
</li>
<li><t>Implementations SHOULD them.</li>
        <li pn="section-6-6.3">Implementations <bcp14>SHOULD</bcp14> use <xref target="RFC7828"></xref> (The the
  edns-tcp-keepalive EDNS0 Option) EDNS(0) option <xref target="RFC7828" format="default" sectionFormat="of" derivedContent="RFC7828"/> to manage
  persistent connections (which connections. This is
  more flexible than the alternative of simply using just fixed timeouts).</t>
</li> timeouts.</li>
      </ul>
<t>The
      <t indent="0" pn="section-6-7">The following sections include detailed clarifications on the updates to XFR
behavior implied in <xref target="RFC7766"></xref> target="RFC7766" format="default" sectionFormat="of" derivedContent="RFC7766"/> and how the use of <xref target="RFC7828"></xref> target="RFC7828" format="default" sectionFormat="of" derivedContent="RFC7828"/> applies
specifically to XFR exchanges. They also discuss how IXFR and AXFR can reuse
the same TCP connection.</t>
<t>For
      <t indent="0" pn="section-6-8">For completeness, we also mention here the recent specification of extended
DNS error (EDE) codes <xref target="RFC8914"></xref>. target="RFC8914" format="default" sectionFormat="of" derivedContent="RFC8914"/> is also mentioned here. For zone transfers, when returning REFUSED to a
zone transfer request from an 'unauthorized' client (e.g., where the client is not
listed in an ACL for zone transfers or does not sign the request with a
valid TSIG key), the extended DNS error code 18 (Prohibited) - Prohibited can also be sent.</t>
      <section anchor="update-to-rfc1995-for-ixfr-over-tcp"><name>Update anchor="update-to-rfc1995-for-ixfr-over-tcp" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-update-to-rfc-1995-for-ixfr">Update to RFC1995 RFC 1995 for IXFR-over-TCP</name>
<t>For clarity - IXFR over TCP</name>
        <t indent="0" pn="section-6.1-1">For clarity, an IXFR-over-TCP server compliant with this specification MUST
  <bcp14>MUST</bcp14> be
  able to handle multiple concurrent IXoT requests on a single TCP connection
  (for the same and different zones) and SHOULD <bcp14>SHOULD</bcp14> send the responses as soon as
  they are available, which might be out-of-order out of order compared to the requests.</t>
      </section>
      <section anchor="update-to-rfc5936-for-axfr-over-tcp"><name>Update anchor="update-to-rfc5936-for-axfr-over-tcp" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-update-to-rfc-5936-for-axfr">Update to RFC5936 RFC 5936 for AXFR-over-TCP</name>
<t>For clarity - AXFR over TCP</name>
        <t indent="0" pn="section-6.2-1">For clarity, an AXFR-over-TCP server compliant with this specification MUST
  <bcp14>MUST</bcp14> be
  able to handle multiple concurrent AXoT sessions on a single TCP connection
  (for the same and different zones). The response streams for concurrent AXFRs
MAY
  <bcp14>MAY</bcp14> be intermingled intermingled, and AXFR-over-TCP clients compliant with this specification
  specification, which pipeline AXFR requests MUST requests, <bcp14>MUST</bcp14> be able to handle this.</t>
      </section>
      <section anchor="updates-to-rfc1995-and-rfc5936-for-xfr-over-tcp"><name>Updates anchor="updates-to-rfc1995-and-rfc5936-for-xfr-over-tcp" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-updates-to-rfcs-1995-and-59">Updates to RFC1995 RFCs 1995 and RFC5936 5936 for XFR-over-TCP</name> XFR over TCP</name>
        <section anchor="connection-reuse"><name>Connection reuse</name>
<t>As anchor="connection-reuse" numbered="true" removeInRFC="false" toc="include" pn="section-6.3.1">
          <name slugifiedName="name-connection-reuse">Connection Reuse</name>
          <t indent="0" pn="section-6.3.1-1">As specified, XFR-over-TCP clients SHOULD re-use <bcp14>SHOULD</bcp14> reuse any existing open TCP
    connection when
    starting any new XFR request to the same primary, and for issuing SOA queries,
    instead of opening a new connection. The number of TCP connections between a
    secondary and primary SHOULD <bcp14>SHOULD</bcp14> be minimized (also see <xref target="update-to-rfc7766"></xref>).</t>
<t>Valid target="update-to-rfc7766" format="default" sectionFormat="of" derivedContent="Section 6.4"/>).</t>
          <t indent="0" pn="section-6.3.1-2">Valid reasons for not re-using reusing existing connections might include:</t>

<ul>
<li>as
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6.3.1-3">
            <li pn="section-6.3.1-3.1">As already noted in <xref target="RFC7766"></xref>, target="RFC7766" format="default" sectionFormat="of" derivedContent="RFC7766"/>, separate connections for
      different zones might be preferred for operational reasons. In this case, the number of
      concurrent connections for zone transfers SHOULD <bcp14>SHOULD</bcp14> be limited to the total
      number of zones transferred between the client and server.</li>
<li>reaching a
            <li pn="section-6.3.1-3.2">A configured limit for the number of outstanding queries or XFR requests
      allowed on a single TCP connection</li>
<li>the connection has been reached.</li>
            <li pn="section-6.3.1-3.3">The message ID pool has already been exhausted on an open connection</li>
<li>a connection.</li>
            <li pn="section-6.3.1-3.4">A large number of timeouts or slow responses have occurred on an open
connection</li>
<li>an
      connection.</li>
            <li pn="section-6.3.1-3.5">An edns-tcp-keepalive EDNS0 EDNS(0) option with a timeout of 0 has been received from the
server
      server, and the client is in the process of closing the connection (see <xref target="the-edns-tcp-keepalive-edns0-option"></xref>)</li> target="the-edns-tcp-keepalive-edns0-option" format="default" sectionFormat="of" derivedContent="Section 6.3.4"/>).</li>
          </ul>
<t>If
          <t indent="0" pn="section-6.3.1-4">If no TCP connections are currently open, XFR clients MAY <bcp14>MAY</bcp14> send SOA
    queries over UDP or a new TCP connection.</t>
        </section>
        <section anchor="axfrs-and-ixfrs-on-the-same-connection"><name>AXFRs anchor="axfrs-and-ixfrs-on-the-same-connection" numbered="true" removeInRFC="false" toc="include" pn="section-6.3.2">
          <name slugifiedName="name-axfrs-and-ixfrs-on-the-same">AXFRs and IXFRs on the same connection</name>
<t>Neither <xref target="RFC1995"></xref> Same Connection</name>
          <t indent="0" pn="section-6.3.2-1">Neither <xref target="RFC1995" format="default" sectionFormat="of" derivedContent="RFC1995"/> nor <xref target="RFC5936"></xref> target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/> explicitly
    discuss the use of a single TCP
    connection for both IXFR and AXFR requests. <xref target="RFC5936"></xref> target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/> does make the
    general statement:</t>

<artwork>&quot;Non-AXFR
          <blockquote pn="section-6.3.2-2">Non-AXFR session traffic can also use an open TCP connection.&quot;
</artwork>
<t>We clarify here connection.</blockquote>
          <t indent="0" pn="section-6.3.2-3">In this document, the above is clarified to indicate that implementations capable of both AXFR and IXFR and
    compliant with this specification SHOULD</t>

<ul>
<li>use <bcp14>SHOULD</bcp14>:</t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6.3.2-4">
            <li pn="section-6.3.2-4.1">use the same TCP connection for both AXFR and IXFR requests to the same primary</li>
<li>pipeline
      primary,</li>
            <li pn="section-6.3.2-4.2">pipeline such requests (if they pipeline XFR requests in general) and MAY
      <bcp14>MAY</bcp14> intermingle them</li>
<li>send them, and</li>
            <li pn="section-6.3.2-4.3">send the response(s) for each request as soon as they are available i.e. available, i.e.,
      responses MAY <bcp14>MAY</bcp14> be sent intermingled</li> intermingled.</li>
          </ul>
<t>For
          <t indent="0" pn="section-6.3.2-5">For some current implementations implementations, adding all the above functionality would introduce
    significant code complexity. In such a case, there will need to be an assessment of the
    trade-off between that and the performance benefits of the above for XFR.</t>
        </section>
        <section anchor="xfr-limits"><name>XFR limits</name>
<t>The anchor="xfr-limits" numbered="true" removeInRFC="false" toc="include" pn="section-6.3.3">
          <name slugifiedName="name-xfr-limits">XFR Limits</name>
          <t indent="0" pn="section-6.3.3-1">The server MAY <bcp14>MAY</bcp14> limit the number of concurrent IXFRs, AXFRs AXFRs, or total XFR
    transfers in progress, or progress (or from a given secondary, secondary) to protect server resources.
    Servers SHOULD <bcp14>SHOULD</bcp14> return SERVFAIL if this limit is hit, since it is a
    transient error and a retry at a later time might succeed (there is no previous
    specification for this behavior).</t>
        </section>
        <section anchor="the-edns-tcp-keepalive-edns0-option"><name>The anchor="the-edns-tcp-keepalive-edns0-option" numbered="true" removeInRFC="false" toc="include" pn="section-6.3.4">
          <name slugifiedName="name-the-edns-tcp-keepalive-edns">The edns-tcp-keepalive EDNS0 EDNS(0) Option</name>
<t>XFR
          <t indent="0" pn="section-6.3.4-1">XFR clients that send the edns-tcp-keepalive EDNS0 EDNS(0) option on every XFR request provide
    the server with maximum opportunity to update the edns-tcp-keepalive timeout. The XFR
    server may use the frequency of recent XFRs to calculate an average update rate as
    input to the decision of what edns-tcp-keepalive timeout to use. If the server
    does not support edns-tcp-keepalive, the client MAY <bcp14>MAY</bcp14> keep the connection
    open for a few seconds (<xref target="RFC7766"></xref> target="RFC7766" format="default" sectionFormat="of" derivedContent="RFC7766"/> recommends that servers use
    timeouts of at least a few seconds).</t>
<t>Whilst
          <t indent="0" pn="section-6.3.4-2">Whilst the specification for EDNS0 EDNS(0)  <xref target="RFC6891"></xref> target="RFC6891" format="default" sectionFormat="of" derivedContent="RFC6891"/>  does not
    specifically mention AXFRs, it does say</t>

<artwork>&quot;If say:</t>
          <blockquote pn="section-6.3.4-3">If an OPT record is present in a received request, compliant
    responders MUST <bcp14>MUST</bcp14> include an OPT record in their respective
responses.&quot;
</artwork>
<t>We clarify here
    responses.</blockquote>
          <t indent="0" pn="section-6.3.4-4">In this document, the above is clarified to indicate that if an OPT record is present in a received AXFR request,
    compliant responders MUST <bcp14>MUST</bcp14> include an OPT record in each of the subsequent
    AXFR responses. Note that this requirement, combined with the use of
    edns-tcp-keepalive, enables AXFR servers to signal the desire to close a
    connection (when existing transactions have competed) due to low resources by
    sending an edns-tcp-keepalive EDNS0 EDNS(0) option with a timeout of 0 on any AXFR
    response. This does not signal that the AXFR is aborted, just that the server
    wishes to close the connection as soon as possible.</t>
        </section>
        <section anchor="backwards-compatibility"><name>Backwards compatibility</name>
<t>Certain anchor="backwards-compatibility" numbered="true" removeInRFC="false" toc="include" pn="section-6.3.5">
          <name slugifiedName="name-backwards-compatibility">Backwards Compatibility</name>
          <t indent="0" pn="section-6.3.5-1">Certain legacy behaviors were noted in <xref target="RFC5936"></xref>, target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/>, with provisions
    that implementations may want to offer options to fallback to legacy behavior when
    interoperating with servers known to not support <xref target="RFC5936"></xref>. target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/>. For
    purposes of interoperability, IXFR and AXFR implementations may want to continue offering
    such configuration options, as well as supporting some behaviors that were
    underspecified prior to this work (e.g., performing IXFR and AXFRs on separate
    connections). However, XoT connections should have no need to do so.</t>
        </section>
      </section>
      <section anchor="update-to-rfc7766"><name>Update anchor="update-to-rfc7766" numbered="true" removeInRFC="false" toc="include" pn="section-6.4">
        <name slugifiedName="name-update-to-rfc-7766">Update to RFC7766</name>
<t><xref target="RFC7766"></xref> RFC 7766</name>
        <t indent="0" pn="section-6.4-1"><xref target="RFC7766" format="default" sectionFormat="of" derivedContent="RFC7766"/> made general implementation
  recommendations with regard to TCP/TLS connection handling:</t>

<artwork>&quot;To
        <blockquote pn="section-6.4-2">To mitigate the risk of unintentional server overload, DNS
  clients MUST <bcp14>MUST</bcp14> take care to minimize the number of concurrent TCP
  connections made to any individual server. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14>
  that for any given client/server interaction there SHOULD <bcp14>SHOULD</bcp14> be no
  more than one connection for regular queries, one for zone
  transfers, and one for each protocol that is being used on top
  of TCP (for example, if the resolver was using TLS). However,
  it is noted that certain primary/ secondary configurations with
  many busy zones might need to use more than one TCP connection
  for zone transfers for operational reasons (for example, to
  support concurrent transfers of multiple zones).&quot;
</artwork>
<t>Whilst zones).</blockquote>
        <t indent="0" pn="section-6.4-3">Whilst this recommends a particular behavior for the clients using TCP, it
  does not relax the requirement for servers to handle 'mixed' traffic (regular
  queries and zone transfers) on any open TCP/TLS connection. It also overlooks the
  potential that other transports might want to take the same approach with regard to
  using separate connections for different purposes.</t>
<t>This
        <t indent="0" pn="section-6.4-4">This specification updates the above general guidance in <xref target="RFC7766"></xref> target="RFC7766" format="default" sectionFormat="of" derivedContent="RFC7766"/>
  to provide the same separation of connection purpose (regular queries and zone transfers) for
  all transports being used on top of TCP.</t>
<t>Therefore,
        <t indent="0" pn="section-6.4-5">Therefore, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that for
  each protocol used on top of TCP in any given client/server interaction, interaction there
SHOULD
  <bcp14>SHOULD</bcp14> be no more than one connection for regular queries and one for zone
  transfers.</t>
<t>As
        <t indent="0" pn="section-6.4-6">As an illustration, it could be imagined that in the future such an
  interaction could hypothetically include one or all of the following:</t>

<ul>
<li>one
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6.4-7">
          <li pn="section-6.4-7.1">one TCP connection for regular queries</li>
<li>one
          <li pn="section-6.4-7.2">one TCP connection for zone transfers</li>
<li>one
          <li pn="section-6.4-7.3">one TLS connection for regular queries</li>
<li>one
          <li pn="section-6.4-7.4">one TLS connection for zone transfers</li>
<li>one
          <li pn="section-6.4-7.5">one DoH connection for regular queries</li>
<li>one
          <li pn="section-6.4-7.6">one DoH connection for zone transfers</li>
        </ul>
<t><xref target="connection-reuse"></xref> has provided
        <t indent="0" pn="section-6.4-8"><xref target="connection-reuse" format="default" sectionFormat="of" derivedContent="Section 6.3.1"/> provides specific details of the reasons where why
  more than one connection for a given transport might be required for zone transfers from
  a particular client.</t>
      </section>
    </section>
    <section anchor="xot-specification"><name>XoT specification</name>

<section anchor="connection-establishment"><name>Connection establishment</name>
<t>During anchor="xot-specification" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-xot-specification">XoT Specification</name>
      <section anchor="connection-establishment" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-connection-establishment">Connection Establishment</name>
        <t indent="0" pn="section-7.1-1">During connection establishment establishment, the Application-Layer Protocol Negotiation (ALPN) token “dot”
    "dot" <xref target="DoT-ALPN"></xref> MUST target="DoT-ALPN" format="default" sectionFormat="of" derivedContent="DoT-ALPN"/> <bcp14>MUST</bcp14> be selected in the TLS
    handshake.</t>
      </section>
      <section anchor="tls-versions"><name>TLS versions</name>
<t>All anchor="tls-versions" numbered="true" removeInRFC="false" toc="include" pn="section-7.2">
        <name slugifiedName="name-tls-versions">TLS Versions</name>
        <t indent="0" pn="section-7.2-1">All implementations of this specification MUST <bcp14>MUST</bcp14> use only TLS 1.3 <xref target="RFC8446"></xref> target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> or later.</t>
      </section>
      <section anchor="port-selection"><name>Port selection</name>
<t>The anchor="port-selection" numbered="true" removeInRFC="false" toc="include" pn="section-7.3">
        <name slugifiedName="name-port-selection">Port Selection</name>
        <t indent="0" pn="section-7.3-1">The connection for XoT SHOULD <bcp14>SHOULD</bcp14> be established using port 853, as
    specified in <xref target="RFC7858"></xref>, target="RFC7858" format="default" sectionFormat="of" derivedContent="RFC7858"/>, unless there is mutual agreement between the secondary and
    primary and secondary to use a port other than port 853 for XoT. There MAY <bcp14>MAY</bcp14>
    be agreement to use different ports for AXoT and IXoT, IXoT or for different zones.</t>
      </section>
      <section anchor="high-level-xot-descriptions"><name>High level XoT descriptions</name>
<t>It anchor="high-level-xot-descriptions" numbered="true" removeInRFC="false" toc="include" pn="section-7.4">
        <name slugifiedName="name-high-level-xot-descriptions">High-Level XoT Descriptions</name>
        <t indent="0" pn="section-7.4-1">It is useful to note that in XoT, XoT it is the secondary that initiates
    the TLS connection to the primary for a an XFR request, request so that that, in terms of
    connectivity, the secondary is the TLS client and the primary is the TLS server.</t>
<t>The
        <t indent="0" pn="section-7.4-2">The figure below provides an outline of the AXoT mechanism including NOTIFYs.</t>

<artwork>
        <figure anchor="fig3" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-axot-mechanism">AXoT Mechanism</name>
          <artwork name="" type="" alt="" align="left" pn="section-7.4-3.1">
   Secondary                            Primary

       |              NOTIFY               |
       | &lt;-------------------------------- |  UDP
       | --------------------------------&gt; |
       |          NOTIFY Response          |
       |                                   |
       |                                   |
       |            SOA Request            |
       | --------------------------------&gt; |  UDP (or part of
       | &lt;-------------------------------- |  a TCP/TLS session)
       |           SOA Response            |
       |                                   |
       |                                   |
       |                                   |
       |            AXFR Request           | ---
       | --------------------------------&gt; |   |
       | &lt;-------------------------------- |   |
       |          AXFR Response 1          |   |
       |             (Zone data)           |   |
       |                                   |   |
       | &lt;-------------------------------- |   | TLS
       |          AXFR Response 2          |   | Session
       |             (Zone data)           |   |
       |                                   |   |
       | &lt;-------------------------------- |   |
       |          AXFR Response 3          |   |
       |             (Zone data)           | ---
       |                                   |

              Figure 3. AXoT Mechanism
</artwork>
<t>The
        </figure>
        <t indent="0" pn="section-7.4-4">The figure below provides an outline of the IXoT mechanism including NOTIFYs.</t>

<artwork>
        <figure anchor="fig4" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-ixot-mechanism">IXoT Mechanism</name>
          <artwork name="" type="" alt="" align="left" pn="section-7.4-5.1">
   Secondary                            Primary

       |              NOTIFY               |
       | &lt;-------------------------------- |  UDP
       | --------------------------------&gt; |
       |          NOTIFY Response          |
       |                                   |
       |                                   |
       |            SOA Request            |
       | --------------------------------&gt; |  UDP (or part of
       | &lt;-------------------------------- |  a TCP/TLS session)
       |           SOA Response            |
       |                                   |
       |                                   |
       |                                   |
       |            IXFR Request           | ---
       | --------------------------------&gt; |    |
       | &lt;-------------------------------- |    |
       |            IXFR Response          |    |
       |             (Zone data)           |    |
       |                                   |    | TLS
       |                                   |    | session
       |            IXFR Request           |    |
       | --------------------------------&gt; |    |
       | &lt;-------------------------------- |    |
       |            IXFR Response          |    |
       |             (Zone data)           | ---

              Figure 4. IXoT Mechanism
</artwork>
        </figure>
      </section>
      <section anchor="xot-transfers"><name>XoT transfers</name>
<t>For anchor="xot-transfers" numbered="true" removeInRFC="false" toc="include" pn="section-7.5">
        <name slugifiedName="name-xot-transfers">XoT Transfers</name>
        <t indent="0" pn="section-7.5-1">For a zone transfer between two end points endpoints to be considered protected with XoT XoT,
  all XFR requests and response responses for that zone MUST <bcp14>MUST</bcp14> be sent over TLS connections connections,
  where at a minimum:</t>

<ul>
<li>the
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.5-2">
          <li pn="section-7.5-2.1">The client MUST <bcp14>MUST</bcp14> authenticate the server by use of an authentication
    domain name using a Strict Privacy Profile, profile, as described in <xref target="RFC8310"></xref></li>
<li><t>the target="RFC8310" format="default" sectionFormat="of" derivedContent="RFC8310"/>.</li>
          <li pn="section-7.5-2.2">
            <t indent="0" pn="section-7.5-2.2.1">The server MUST <bcp14>MUST</bcp14> validate the client is authorized to request or proxy
    a zone transfer by using one or both of the following methods:</t>

<ul>
<li>Mutual
            <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.5-2.2.2">
              <li pn="section-7.5-2.2.2.1">mutual TLS (mTLS)</li>
<li>an IP based
              <li pn="section-7.5-2.2.2.2">an IP-based ACL (which can be either per-message per message or per-connection) per connection)
      combined with a valid TSIG/SIG(0) signature on the XFR request</li>
</ul></li>
            </ul>
<t>If
          </li>
        </ul>
        <t indent="0" pn="section-7.5-3">If only one method is selected selected, then mTLS is preferred because it provides strong
  cryptographic protection at both endpoints.</t>
<t>Authentication
        <t indent="0" pn="section-7.5-4">Authentication mechanisms are discussed in full in <xref target="authentication-mechanisms"></xref> target="authentication-mechanisms" format="default" sectionFormat="of" derivedContent="Section 9"/>,
  and the rationale for the above requirement is discussed in <xref target="xot-authentication"></xref>. target="xot-authentication" format="default" sectionFormat="of" derivedContent="Section 10"/>.
  Transfer group policies are discussed in <xref target="policies-for-both-axot-and-ixot"></xref>.</t>
</section>

<section anchor="xot-connections"><name>XoT connections</name>
<t>The target="policies-for-both-axot-and-ixot" format="default" sectionFormat="of" derivedContent="Section 11"/>.</t>
      </section>
      <section anchor="xot-connections" numbered="true" removeInRFC="false" toc="include" pn="section-7.6">
        <name slugifiedName="name-xot-connections">XoT Connections</name>
        <t indent="0" pn="section-7.6-1">The details in <xref target="updates-to-existing-specifications"></xref> target="updates-to-existing-specifications" format="default" sectionFormat="of" derivedContent="Section 6"/> about, e.g.,
  persistent connections and XFR message handling handling, are fully applicable to XoT connections as
  well. However, any behavior specified here takes precedence for XoT.</t>
<t>If
        <t indent="0" pn="section-7.6-2">If no TLS connections are currently open, XoT clients MAY <bcp14>MAY</bcp14> send SOA queries
  over
UDP or UDP, TCP, or TLS.</t>
      </section>
      <section anchor="xot-vs-adot"><name>XoT vs anchor="xot-vs-adot" numbered="true" removeInRFC="false" toc="include" pn="section-7.7">
        <name slugifiedName="name-xot-vs-adot">XoT vs. ADoT</name>
<t>As
        <t indent="0" pn="section-7.7-1">As noted earlier, there is currently no specification for encryption of
  connections from recursive resolvers to authoritative servers. Some
authoritatives
  authoritative servers are experimenting with ADoT ADoT, and opportunistic encryption
  has also been raised as a possibility; therefore, it is therefore highly likely that use
  of encryption by authoritative servers will evolve in the coming years.</t>
<t>This
        <t indent="0" pn="section-7.7-2">This raises questions in the short term with regard to TLS connection and
  message handling for authoritative servers. In particular, there is likely to be
  a class of authoritatives authoritative servers that wish to use XoT in the near future with a
  small number of configured secondaries, secondaries but that do not wish to support DoT for
  regular queries from recursives in that same time frame. These servers have to
  potentially cope with probing and direct queries from recursives and from test
servers,
  servers and also potential attacks that might wish to make use of TLS to
  overload the server.</t>
<t><xref target="RFC5936"></xref>
        <t indent="0" pn="section-7.7-3"><xref target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/> clearly states that non-AXFR session traffic can use an
  open TCP
connection, connection; however, this requirement needs to be re-evaluated reevaluated when considering
applying
  the application of the same model to XoT. Proposing that a server should also start
  responding to all queries received over TLS just because it has enabled XoT
  would be equivalent to defining a form of authoritative DoT. This specification
  does not propose that, but it also does not prohibit servers from answering
  queries unrelated to XFR exchanges over TLS. Rather, this specification
  simply outlines in later sections:</t>

<ul>
<li>how XoT implementations should utilize
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.7-4">
          <li pn="section-7.7-4.1">the utilization of EDE codes by XoT servers in response to queries on TLS
    connections that they are not willing to answer (see <xref target="response-rcodes"></xref>)</li>
<li>the target="response-rcodes" format="default" sectionFormat="of" derivedContent="Section 7.8"/>)</li>
          <li pn="section-7.7-4.2">the operational and policy options that an operator of a XoT server operator has
    with regard to managing TLS connections and messages (see <xref target="xot-server-connection-handling"></xref>)</li> target="xot-server-connection-handling" format="default" sectionFormat="of" derivedContent="Appendix A"/>)</li>
        </ul>
      </section>
      <section anchor="response-rcodes"><name>Response anchor="response-rcodes" numbered="true" removeInRFC="false" toc="include" pn="section-7.8">
        <name slugifiedName="name-response-rcodes">Response RCODES</name>
<t>XoT
        <t indent="0" pn="section-7.8-1">XoT clients and servers MUST <bcp14>MUST</bcp14> implement EDE codes. If a XoT server receives
  non-XoT traffic it is not willing to answer on a TLS connection, it SHOULD <bcp14>SHOULD</bcp14>
  respond with REFUSED and the extended DNS error code 21 - Not Supported
  <xref target="RFC8914"></xref>. target="RFC8914" format="default" sectionFormat="of" derivedContent="RFC8914"/>. XoT clients should not send any further
  queries of this type to the server for a reasonable period of time (for
  example, one hour) hour), i.e., long enough that the server configuration or policy
  might be updated.</t>
<t>Historically,
        <t indent="0" pn="section-7.8-2">Historically, servers have used the REFUSED RCODE for many situations, and so situations; therefore,
  clients often had no detailed information on which to base an error or fallback
  path when queries were refused. As a result, the client behavior could vary
  significantly. XoT servers that refuse queries must cater for to the fact that
  client behavior might vary from continually retrying queries regardless of
  receiving REFUSED to every query, or query or, at the other extreme extreme, clients may decide to
  stop using the server over any transport. This might be because those clients are
  either non-XoT clients or do not implement EDE codes.</t>
      </section>
      <section anchor="axot-specifics"><name>AXoT specifics</name>

<section anchor="padding-axot-responses"><name>Padding anchor="axot-specifics" numbered="true" removeInRFC="false" toc="include" pn="section-7.9">
        <name slugifiedName="name-axot-specifics">AXoT Specifics</name>
        <section anchor="padding-axot-responses" numbered="true" removeInRFC="false" toc="include" pn="section-7.9.1">
          <name slugifiedName="name-padding-axot-responses">Padding AXoT responses</name>
<t>The Responses</name>
          <t indent="0" pn="section-7.9.1-1">The goal of padding AXoT responses is two fold:</t>

<ul>
<li>to
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7.9.1-2">
            <li pn="section-7.9.1-2.1">to obfuscate the actual size of the transferred zone to minimize information
      leakage about the entire contents of the zone.</li>
<li>to zone</li>
            <li pn="section-7.9.1-2.2">to obfuscate the incremental changes to the zone between SOA updates to
      minimize information leakage about zone update activity and growth.</li> growth</li>
          </ul>
<t>Note
          <t indent="0" pn="section-7.9.1-3">Note that the re-use reuse of XoT connections for transfers of multiple different
    zones slightly complicates any attempt to analyze the traffic size and timing to
    extract information.  Also, effective padding may require the state to be kept
as
    because zones may grow and/or shrink over time.</t>
<t>It
          <t indent="0" pn="section-7.9.1-4">It is noted here that, depending on the padding policies eventually developed for XoT,
    the requirement to obfuscate the total zone size might
    require a server to create 'empty' AXoT responses. That responses, that is, AXoT responses that
    contain no RR's RRs apart from an OPT RR containing the EDNS(0) option for padding.
    For example, without this capability capability, the maximum size that a tiny zone could be padded to
    would theoretically be limited if there had to be a minimum of 1 RR per packet.</t>
<t>However,
          <t indent="0" pn="section-7.9.1-5">However, as with existing AXFR, the last AXoT response message sent MUST <bcp14>MUST</bcp14>
    contain the same SOA that was in the first message of the AXoT response series
    in order to signal the conclusion of the zone transfer.</t>
<t><xref target="RFC5936"></xref>
          <t indent="0" pn="section-7.9.1-6"><xref target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/> says:</t>

<artwork>&quot;Each
          <blockquote pn="section-7.9.1-7">Each AXFR response message SHOULD <bcp14>SHOULD</bcp14> contain a sufficient number
    of RRs to reasonably amortize the per-message overhead, up to
    the largest number that will fit within a DNS message (taking
    the required content of the other sections into account, as
    described below).&quot;
</artwork>
<t>'Empty' below).</blockquote>
          <t indent="0" pn="section-7.9.1-8">'Empty' AXoT responses generated in order to meet a padding requirement will be
    exceptions to the above statement. For flexibility, for future proofing proofing, and in
    order to guarantee support for future padding policies, we state it is stated here that
    secondary implementations MUST <bcp14>MUST</bcp14> be resilient to receiving padded AXoT
    responses, including 'empty' AXoT responses that contain only an OPT RR containing the
    EDNS(0) option for padding.</t>
<t>Recommendation
          <t indent="0" pn="section-7.9.1-9">Recommendations of specific policies for padding AXoT responses are out of scope
    for this specification. Detailed considerations of such policies and the
    trade-offs involved are expected to be the subject of future work.</t>
        </section>
      </section>
      <section anchor="ixot-specifics"><name>IXoT specifics</name>

<section anchor="condensation-of-responses"><name>Condensation of responses</name>
<t><xref target="RFC1995"></xref> anchor="ixot-specifics" numbered="true" removeInRFC="false" toc="include" pn="section-7.10">
        <name slugifiedName="name-ixot-specifics">IXoT Specifics</name>
        <section anchor="condensation-of-responses" numbered="true" removeInRFC="false" toc="include" pn="section-7.10.1">
          <name slugifiedName="name-condensation-of-responses">Condensation of Responses</name>
          <t indent="0" pn="section-7.10.1-1"><xref target="RFC1995" format="default" sectionFormat="of" derivedContent="RFC1995"/> says that condensation of responses is optional and MAY
    <bcp14>MAY</bcp14> be done. Whilst
    it does add complexity to generating responses, it can significantly reduce the
    size of responses. However However, any such reduction might be offset by increased
    message size due to padding. This specification does not update the optionality
    of condensation for XoT responses.</t>
        </section>
        <section anchor="fallback-to-axfr"><name>Fallback anchor="fallback-to-axfr" numbered="true" removeInRFC="false" toc="include" pn="section-7.10.2">
          <name slugifiedName="name-fallback-to-axfr">Fallback to AXFR</name>
<t>Fallback
          <t indent="0" pn="section-7.10.2-1">Fallback to AXFR can happen, for example, if the server is not able to provide
    an IXFR for the requested SOA. Implementations differ in how long they store
    zone deltas and how many may be stored at any one time.</t>
<t>Just
          <t indent="0" pn="section-7.10.2-2">Just as with IXFR-over-TCP, IXFR over TCP, after a failed IXFR a IXFR, an IXoT client SHOULD <bcp14>SHOULD</bcp14>
    request the AXFR on the already open XoT connection.</t>
        </section>
        <section anchor="padding-of-ixot-responses"><name>Padding anchor="padding-of-ixot-responses" numbered="true" removeInRFC="false" toc="include" pn="section-7.10.3">
          <name slugifiedName="name-padding-of-ixot-responses">Padding of IXoT responses</name>
<t>The Responses</name>
          <t indent="0" pn="section-7.10.3-1">The goal of padding IXoT responses is to obfuscate the incremental
    changes to the zone between SOA updates to minimize information leakage about
    zone update activity and growth. Both the size and timing of the IXoT responses could
    reveal information.</t>
<t>IXFR
          <t indent="0" pn="section-7.10.3-2">IXFR responses can vary greatly in size from the order of 100 bytes for one or
    two record updates, updates to tens of thousands of bytes for large large, dynamic DNSSEC
signed DNSSEC-signed zones.
    The frequency of IXFR responses can also depend greatly on if and how the zone is DNSSEC
    signed.</t>
<t>In
          <t indent="0" pn="section-7.10.3-3">In order to guarantee support for future padding policies, we state it is stated here
    that
    secondary implementations MUST <bcp14>MUST</bcp14> be resilient to receiving padded IXoT
    responses.</t>
<t>Recommendation
          <t indent="0" pn="section-7.10.3-4">Recommendation of specific policies for padding IXoT responses are out of scope
    for this specification. Detailed considerations of such padding policies, the
    use of traffic obfuscation techniques (such as ‘dummy' generating fake XFR traffic), and
    the trade-offs involved are expected to be the subject of future work.</t>
        </section>
      </section>
      <section anchor="name-compression-and-maximum-payload-sizes"><name>Name compression and maximum payload sizes</name>
<t>It anchor="name-compression-and-maximum-payload-sizes" numbered="true" removeInRFC="false" toc="include" pn="section-7.11">
        <name slugifiedName="name-name-compression-and-maximu">Name Compression and Maximum Payload Sizes</name>
        <t indent="0" pn="section-7.11-1">It is noted here that name compression <xref target="RFC1035"></xref> target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/> can be used in XFR
  responses to reduce the size of the payload, payload; however, the maximum value of the offset that
  can be used in the name compression pointer structure is 16384. For some DNS
implementations
  implementations, this limits the size of an individual XFR response used in
  practice to something around the order of 16kB. 16 KB. In principle, larger
  payload sizes can be supported for some responses with more sophisticated
  approaches (e.g., by pre-calculating precalculating the maximum offset required).</t>
<t>Implementations
        <t indent="0" pn="section-7.11-2">Implementations may wish to offer options to disable name compression for XoT
  responses to enable larger payloads. This might be particularly helpful when
  padding is used used, since minimizing the payload size is not necessarily a useful
  optimization in this case and disabling name compression will reduce the
  resources required to construct the payload.</t>
      </section>
    </section>
    <section anchor="multi-primary-configurations"><name>Multi-primary anchor="multi-primary-configurations" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-multi-primary-configuration">Multi-primary Configurations</name>
<t>This
      <t indent="0" pn="section-8-1">This model can provide flexibility
  and redundancy redundancy, particularly for IXFR. A secondary will receive one or more
  NOTIFY messages and can send an SOA to all of the configured primaries. It can
  then choose to send an XFR request to the primary with the highest SOA (or
  based on other criteria, e.g., RTT).</t>
<t>When
      <t indent="0" pn="section-8-2">When using persistent connections, the secondary may have a XoT connection
  already open to one or more primaries. Should a secondary preferentially
  request an XFR from a primary to which it already has an open XoT connection
  or the one with the highest SOA (assuming it doesn't have a connection open to
  it already)?</t>
<t>Two
      <t indent="0" pn="section-8-3">Two extremes can be envisaged here. The first one can be considered a 'preferred
  primary connection' model. In this case, the secondary continues to use one
  persistent connection to a single primary until it has reason not to. Reasons
  not to might include the primary repeatedly closing the connection, long query/response RTTs
  on
transfers transfers, or the SOA of the primary being an unacceptable lag behind the SOA of
  an alternative primary.</t>
<t>The
      <t indent="0" pn="section-8-4">The other extreme can be considered a 'parallel primary connection' model. Here,
  a secondary could keep multiple persistent connections open to all available
  primaries and only request XFRs from the primary with the highest serial number.
  Since normally the number of secondaries and primaries in direct contact in a
  transfer group is reasonably low low, this might be feasible if latency is the most
  significant concern.</t>
<t>Recommendation
      <t indent="0" pn="section-8-5">Recommendation of a particular scheme is out of scope of this document, but
implementations are encouraged to provide configuration options that allow
operators to make choices about this behavior.</t>
    </section>
    <section anchor="authentication-mechanisms"><name>Authentication mechanisms</name>
<t>To anchor="authentication-mechanisms" numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-authentication-mechanisms">Authentication Mechanisms</name>
      <t indent="0" pn="section-9-1">To provide context to the requirements in <xref target="xot-transfers"></xref>, target="xot-transfers" format="default" sectionFormat="of" derivedContent="Section 7.5"/>, this
  section provides a brief summary of some of the existing authentication and
  validation mechanisms (both transport independent and TLS specific) that are
  available when performing zone transfers.
  <xref target="xot-authentication"></xref> target="xot-authentication" format="default" sectionFormat="of" derivedContent="Section 10"/> then discusses in more details detail specifically how a
  combination of TLS authentication, TSIG TSIG, and IP based IP-based ACLs interact for XoT.</t>
<t>We classify
      <t indent="0" pn="section-9-2">In this document, the mechanisms are classified based on the following properties:</t>

<ul>
<li><t>'Data
      <dl newline="true" spacing="normal" indent="3" pn="section-9-3">
        <dt pn="section-9-3.1">Data Origin Authentication' (DO): Authentication (DO):</dt>
        <dd pn="section-9-3.2">Authentication 1) of the fact that the DNS message originated
    from the party with whom credentials were shared, shared and 2) of the data integrity
    of the message contents (the originating party may or may not be the party
    operating the far end of a TCP/TLS connection in a 'proxy' scenario).</t>
</li>
<li><t>'Channel Confidentiality' (CC): scenario).</dd>
        <dt pn="section-9-3.3">Channel Confidentiality (CC):</dt>
        <dd pn="section-9-3.4">Confidentiality of the communication channel between the
    client and server (i.e. (i.e., the two end points endpoints of a TCP/TLS connection) from passive surveillance.</t>
</li>
<li><t>'Channel Authentication' (CA):
    surveillance.</dd>
        <dt pn="section-9-3.5">Channel Authentication (CA):</dt>
        <dd pn="section-9-3.6">Authentication of the identity of the party to whom a TCP/TLS
    connection is made (this might not be a direct connection between the primary
    and secondary in a proxy scenario).</t>
</li>
</ul> scenario).</dd>
      </dl>
      <section anchor="tsig"><name>TSIG</name>
<t>TSIG <xref target="RFC8945"></xref> anchor="tsig" numbered="true" removeInRFC="false" toc="include" pn="section-9.1">
        <name slugifiedName="name-tsig">TSIG</name>
        <t indent="0" pn="section-9.1-1">TSIG <xref target="RFC8945" format="default" sectionFormat="of" derivedContent="RFC8945"/> provides a mechanism for two or more parties to use
  shared secret keys which that can then be used to create a message digest to protect
  individual DNS messages. This allows each party to authenticate that a request
  or response (and the data in it) came from the other party, even if it was
  transmitted over an unsecured channel or via a proxy.</t>
<t>Properties: Data
        <dl newline="false" spacing="normal" indent="3" pn="section-9.1-2">
          <dt pn="section-9.1-2.1">Properties:</dt>
          <dd pn="section-9.1-2.2">Data origin authentication</t> authentication.</dd>
        </dl>
      </section>
      <section anchor="sig-0"><name>SIG(0)</name>
<t>SIG(0) <xref target="RFC2931"></xref> anchor="sig-0" numbered="true" removeInRFC="false" toc="include" pn="section-9.2">
        <name slugifiedName="name-sig0">SIG(0)</name>
        <t indent="0" pn="section-9.2-1">SIG(0) <xref target="RFC2931" format="default" sectionFormat="of" derivedContent="RFC2931"/> similarly provides a mechanism to digitally sign a
  DNS message but uses public key authentication, where the public keys are stored in
  DNS as KEY RRs and a private key is stored at the signer.</t>
<t>Properties: Data
        <dl newline="false" spacing="normal" indent="3" pn="section-9.2-2">
          <dt pn="section-9.2-2.1">Properties:</dt>
          <dd pn="section-9.2-2.2">Data origin authentication</t> authentication.</dd>
        </dl>
      </section>
      <section anchor="tls"><name>TLS</name>

<section anchor="opportunistic-tls"><name>Opportunistic anchor="tls" numbered="true" removeInRFC="false" toc="include" pn="section-9.3">
        <name slugifiedName="name-tls">TLS</name>
        <section anchor="opportunistic-tls" numbered="true" removeInRFC="false" toc="include" pn="section-9.3.1">
          <name slugifiedName="name-opportunistic-tls">Opportunistic TLS</name>
<t>Opportunistic
          <t indent="0" pn="section-9.3.1-1">Opportunistic TLS for DoT is defined in <xref target="RFC8310"></xref> target="RFC8310" format="default" sectionFormat="of" derivedContent="RFC8310"/> and can provide a
    defense against passive
    surveillance, providing on-the-wire confidentiality. Essentially</t>

<ul>
<li>clients that Essentially:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9.3.1-2">
            <li pn="section-9.3.1-2.1">if clients know authentication information for a server SHOULD server, they
      <bcp14>SHOULD</bcp14> try to authenticate the server</li>
<li>however server,</li>
            <li pn="section-9.3.1-2.2">if this fails or clients do not know the information, they MAY <bcp14>MAY</bcp14>
      fallback to using TLS without authentication and</li>
<li>they MAY authentication, or</li>
            <li pn="section-9.3.1-2.3">clients <bcp14>MAY</bcp14> fallback to using cleartext if TLS is not
      available.</li>
          </ul>
<t>As
          <t indent="0" pn="section-9.3.1-3">As such, it does not offer a defense against active attacks (e.g., an on path on-path active
    attacker on the connection from client to server), server) and is not considered as useful for
    XoT.</t>
<t>Properties: None guaranteed.</t>
</section>

<section anchor="strict-tls"><name>Strict
          <dl newline="false" spacing="normal" indent="3" pn="section-9.3.1-4">
            <dt pn="section-9.3.1-4.1">Properties:</dt>
            <dd pn="section-9.3.1-4.2">None guaranteed.</dd>
          </dl>
        </section>
        <section anchor="strict-tls" numbered="true" removeInRFC="false" toc="include" pn="section-9.3.2">
          <name slugifiedName="name-strict-tls">Strict TLS</name>
<t>Strict
          <t indent="0" pn="section-9.3.2-1">Strict TLS for DoT <xref target="RFC8310"></xref> target="RFC8310" format="default" sectionFormat="of" derivedContent="RFC8310"/> requires that a client is configured
  with an authentication domain name (and/or SPKI pinset) Subject Public Key Info (SPKI) pin set) that MUST
  <bcp14>MUST</bcp14> be used to
  authenticate the TLS handshake with the server. If authentication of the server
  fails, the client will not proceed with the connection. This provides a defense
  for the client against active surveillance, providing client-to-server
  authentication and end-to-end channel confidentiality.</t>
<t>Properties: Channel
          <dl newline="false" spacing="compact" indent="3" pn="section-9.3.2-2">
            <dt pn="section-9.3.2-2.1">Properties:</dt>
            <dd pn="section-9.3.2-2.2">Channel confidentiality and channel authentication (of the server).</t> server).</dd>
          </dl>
        </section>
        <section anchor="mutual-tls"><name>Mutual anchor="mutual-tls" numbered="true" removeInRFC="false" toc="include" pn="section-9.3.3">
          <name slugifiedName="name-mutual-tls">Mutual TLS</name>
<t>This
          <t indent="0" pn="section-9.3.3-1">This is an extension to Strict TLS <xref target="RFC8310"></xref> which target="RFC8310" format="default" sectionFormat="of" derivedContent="RFC8310"/> that requires that a
  client is configured with an authentication domain name (and/or SPKI pinset) pin set) and a client
  certificate. The client offers the certificate for authentication by the server server,
  and the client can authenticate the server the same way as in Strict TLS. This
  provides a defense for both parties against active surveillance, providing
bi-directional
  bidirectional authentication and end-to-end channel confidentiality.</t>
<t>Properties: Channel
          <dl newline="false" spacing="compact" indent="3" pn="section-9.3.3-2">
            <dt pn="section-9.3.3-2.1">Properties:</dt>
            <dd pn="section-9.3.3-2.2">Channel confidentiality and mutual channel authentication.</t> authentication.</dd>
          </dl>
        </section>
      </section>
      <section anchor="ip-based-acl-on-the-primary"><name>IP Based anchor="ip-based-acl-on-the-primary" numbered="true" removeInRFC="false" toc="include" pn="section-9.4">
        <name slugifiedName="name-ip-based-acl-on-the-primary">IP-Based ACL on the Primary</name>
<t>Most
        <t indent="0" pn="section-9.4-1">Most DNS server implementations offer an option to configure an IP based Access
Control List (ACL), IP-based
  ACL, which is often used in combination with TSIG based TSIG-based ACLs to
  restrict access to zone transfers on primary servers on a per query per-query basis.</t>
<t>This
        <t indent="0" pn="section-9.4-2">This is also possible with XoT, but it must be noted that, as with TCP, the
  implementation of such an ACL cannot be enforced on the primary until an XFR
  request is received on an established connection.</t>
<t>As
        <t indent="0" pn="section-9.4-3">As discussed in <xref target="xot-server-connection-handling"></xref>, target="xot-server-connection-handling" format="default" sectionFormat="of" derivedContent="Appendix A"/>, an IP based per connection
  IP-based per-connection ACL could also be implemented where only TLS connections from
  recognized secondaries are accepted.</t>
<t>Properties: Channel
        <dl newline="false" spacing="normal" indent="3" pn="section-9.4-4">
          <dt pn="section-9.4-4.1">Properties:</dt>
          <dd pn="section-9.4-4.2">Channel authentication of the client.</t> client.</dd>
        </dl>
      </section>
      <section anchor="zonemd"><name>ZONEMD</name>
<t>For anchor="zonemd" numbered="true" removeInRFC="false" toc="include" pn="section-9.5">
        <name slugifiedName="name-zonemd">ZONEMD</name>
        <t indent="0" pn="section-9.5-1">For completeness, we also describe Message ZONEMD
  <xref target="RFC8976" format="default" sectionFormat="of" derivedContent="RFC8976"/> ("Message Digest for DNS Zones (ZONEMD)
<xref target="RFC8976"></xref> Zones") is described here.
  The ZONEMD message digest
  is a mechanism that can be used to verify the content of a standalone zone. It
  is designed to be independent of the transmission channel or mechanism, allowing
  a general consumer of a zone to do origin authentication of the entire zone
  contents. Note that the current version of <xref target="RFC8976"></xref> target="RFC8976" format="default" sectionFormat="of" derivedContent="RFC8976"/>
  states:</t>
<t><tt>As
        <blockquote pn="section-9.5-2">As specified herein, ZONEMD is impractical for large, dynamic zones due to the
  time and resources required for digest calculation. However, The the ZONEMD record
  is extensible so that new digest schemes may be added in the future to support
  large, dynamic zones.</tt></t>
<t>It zones.</blockquote>
        <t indent="0" pn="section-9.5-3">It is complementary but orthogonal to the above mechanisms; mechanisms and can be used in
  conjunction with XoT, XoT but is not considered further here.</t>
      </section>
    </section>
    <section anchor="xot-authentication"><name>XoT authentication</name>
<t>It anchor="xot-authentication" numbered="true" removeInRFC="false" toc="include" pn="section-10">
      <name slugifiedName="name-xot-authentication">XoT Authentication</name>
      <t indent="0" pn="section-10-1">It is noted that zone transfer scenarios can vary from a simple single
  primary/secondary relationship where both servers are under the control of a
  single operator to a complex hierarchical structure which that includes proxies and
  multiple operators. Each deployment scenario will require specific analysis to
  determine which combination of authentication methods are best suited to the
  deployment model in question.</t>
<t>The
      <t indent="0" pn="section-10-2">The XoT authentication requirement specified in <xref target="xot-transfers"></xref> target="xot-transfers" format="default" sectionFormat="of" derivedContent="Section 7.5"/>
  addresses the
  issue of ensuring that the transfers are encrypted between the two endpoints
  directly involved in the current transfers. The following table summarizes the
  properties of a selection of the mechanisms discussed in
  <xref target="authentication-mechanisms"></xref>. target="authentication-mechanisms" format="default" sectionFormat="of" derivedContent="Section 9"/>. The two letter acronyms two-letter abbreviations for the properties
  are used below and below: (S) indicates the secondary and (P) indicates
  the primary.</t>
<table>
      <table anchor="table1" align="center" pn="table-1">
        <name slugifiedName="name-properties-of-authenticatio">Properties of Authentication Methods for XoT</name>
        <thead>
          <tr>
            <th align="left">Method</th> align="left" colspan="1" rowspan="1">Method</th>
            <th align="center">DO(S)</th> align="center" colspan="1" rowspan="1">DO(S)</th>
            <th align="center">CC(S)</th> align="center" colspan="1" rowspan="1">CC(S)</th>
            <th align="center">CA(S)</th> align="center" colspan="1" rowspan="1">CA(S)</th>
            <th align="center">DO(P)</th> align="center" colspan="1" rowspan="1">DO(P)</th>
            <th align="center">CC(P)</th> align="center" colspan="1" rowspan="1">CC(P)</th>
            <th align="center">CA(P)</th> align="center" colspan="1" rowspan="1">CA(P)</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">Strict align="left" colspan="1" rowspan="1">Strict TLS</td>
            <td align="center"></td> align="center" colspan="1" rowspan="1"/>
            <td align="center">Y</td> align="center" colspan="1" rowspan="1">Y</td>
            <td align="center">Y</td> align="center" colspan="1" rowspan="1">Y</td>
            <td align="center"></td> align="center" colspan="1" rowspan="1"/>
            <td align="center">Y</td> align="center" colspan="1" rowspan="1">Y</td>
            <td align="center"></td> align="center" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left">Mutual align="left" colspan="1" rowspan="1">Mutual TLS</td>
            <td align="center"></td> align="center" colspan="1" rowspan="1"/>
            <td align="center">Y</td> align="center" colspan="1" rowspan="1">Y</td>
            <td align="center">Y</td> align="center" colspan="1" rowspan="1">Y</td>
            <td align="center"></td> align="center" colspan="1" rowspan="1"/>
            <td align="center">Y</td> align="center" colspan="1" rowspan="1">Y</td>
            <td align="center">Y</td> align="center" colspan="1" rowspan="1">Y</td>
          </tr>
          <tr>
            <td align="left">ACL align="left" colspan="1" rowspan="1">ACL on primary</td>
            <td align="center"></td> align="center" colspan="1" rowspan="1"/>
            <td align="center"></td> align="center" colspan="1" rowspan="1"/>
            <td align="center"></td> align="center" colspan="1" rowspan="1"/>
            <td align="center"></td> align="center" colspan="1" rowspan="1"/>
            <td align="center"></td> align="center" colspan="1" rowspan="1"/>
            <td align="center">Y</td> align="center" colspan="1" rowspan="1">Y</td>
          </tr>
          <tr>
            <td align="left">TSIG</td> align="left" colspan="1" rowspan="1">TSIG</td>
            <td align="center">Y</td> align="center" colspan="1" rowspan="1">Y</td>
            <td align="center"></td> align="center" colspan="1" rowspan="1"/>
            <td align="center"></td> align="center" colspan="1" rowspan="1"/>
            <td align="center">Y</td> align="center" colspan="1" rowspan="1">Y</td>
            <td align="center"></td> align="center" colspan="1" rowspan="1"/>
            <td align="center"></td> align="center" colspan="1" rowspan="1"/>
          </tr>
        </tbody>
</table><t>Table 1: Properties of Authentication methods for XoT</t>
<t>Based
      </table>
      <t indent="0" pn="section-10-4">Based on this analysis analysis, it can be seen that:</t>

<ul>
<li><t>Using
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-10-5">
        <li pn="section-10-5.1">Using just mutual TLS can be considered a standalone solution since both end points endpoints are
    cryptographically authenticated</t>
</li>
<li><t>Using secondary side authenticated.</li>
        <li pn="section-10-5.2">Using secondary-side Strict TLS with a primary side IP primary-side IP-based ACL and TSIG/SIG(0) combination
    provides sufficient protection to be acceptable.</t>
</li> acceptable.</li>
      </ul>
<t>Using
      <t indent="0" pn="section-10-6">Using just an IP IP-based ACL could be susceptible to attacks that can spoof TCP IP
addresses,
  addresses; using TSIG/SIG(0) alone could be susceptible to attacks that were
  able to capture such messages should they be accidentally sent in clear text cleartext by any server
  with the key.</t>
    </section>
    <section anchor="policies-for-both-axot-and-ixot"><name>Policies anchor="policies-for-both-axot-and-ixot" numbered="true" removeInRFC="false" toc="include" pn="section-11">
      <name slugifiedName="name-policies-for-both-axot-and-">Policies for Both AXoT and IXoT</name>
<t>Whilst
      <t indent="0" pn="section-11-1">Whilst the protection of the zone contents in a transfer between two end points endpoints
  can be provided by the XoT protocol, the protection of all the transfers of a
  given zone requires operational administration and policy management.</t>
<t>We call the
      <t indent="0" pn="section-11-2">The entire group of servers involved in XFR for a particular set of
  zones (all the primaries and all the secondaries) is called the 'transfer group'.</t>
<t>In
      <t indent="0" pn="section-11-3">In order to assure the confidentiality of the zone information, the entire
  transfer group MUST <bcp14>MUST</bcp14> have a consistent policy of using XoT. If any do not, this
  is a weak link for attackers to exploit. For clarification, this means that
  within any transfer group both AXFRs and IXFRs for a zone MUST <bcp14>MUST</bcp14> all use
  XoT.</t>
<t>An
      <t indent="0" pn="section-11-4">An individual zone transfer is not considered protected by XoT unless
  both the client and server are configured to use only XoT XoT, and the overall zone
  transfer is not considered protected until all members of the transfer group
  are configured to use only XoT with all other transfers servers (see <xref target="implementation-considerations"></xref>).</t>
<t>A target="implementation-considerations" format="default" sectionFormat="of" derivedContent="Section 12"/>).</t>
      <t indent="0" pn="section-11-5">A XoT policy MUST <bcp14>MUST</bcp14> specify if</t>

<ul>
<li>mutual if:</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-11-6">
        <li pn="section-11-6.1">mutual TLS is used and/or</li>
<li>a IP
        <li pn="section-11-6.2">an IP-based ACL and TSIG/SIG(0) combination is used</li> used.</li>
      </ul>
<t>Since
      <t indent="0" pn="section-11-7">Since this may require configuration of a number of servers who may be under
  the control of different operators operators, the desired consistency could be hard to
  enforce and audit in practice.</t>
<t>Certain
      <t indent="0" pn="section-11-8">Certain aspects of the Policies policies can be relatively easily tested easy to test independently,
  e.g., by requesting zone transfers without TSIG, from unauthorized IP addresses
  or over cleartext DNS. Other aspects aspects, such as if a secondary will accept data
  without a TSIG digest or if secondaries are using Strict as opposed to
  Opportunistic TLS TLS, are more challenging.</t>
<t>The
      <t indent="0" pn="section-11-9">The mechanics of co-ordinating coordinating or enforcing such policies are out of the scope
  of this document but may be the subject of future operational guidance.</t>
    </section>
    <section anchor="implementation-considerations"><name>Implementation anchor="implementation-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-12">
      <name slugifiedName="name-implementation-consideratio">Implementation Considerations</name>
<t>Server
      <t indent="0" pn="section-12-1">Server implementations may want to also offer options that allow ACLs on a zone
  to specify that a specific client can use either XoT or TCP. This would allow
  for flexibility while clients are migrating to XoT.</t>
<t>Client
      <t indent="0" pn="section-12-2">Client implementations may similarly want to offer options to cater for to the
  multi-primary case where the primaries are migrating to XoT.</t>
    </section>
    <section anchor="operational-considerations"><name>Operational anchor="operational-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-13">
      <name slugifiedName="name-operational-considerations">Operational Considerations</name>
<t>If
      <t indent="0" pn="section-13-1">If the options described in <xref target="implementation-considerations"></xref> target="implementation-considerations" format="default" sectionFormat="of" derivedContent="Section 12"/> are
  available,
  such configuration options MUST <bcp14>MUST</bcp14> only be used in a 'migration mode', mode' and
  therefore should be used with great care.</t>
<t>It
      <t indent="0" pn="section-13-2">It is noted that use of a TLS proxy in front of the primary server is a simple
  deployment solution that can enable server side server-side XoT.</t>
    </section>
    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-14">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>None.</t>
</section>

<section anchor="implementation-status"><name>Implementation Status</name>
<t>[THIS SECTION TO BE REMOVED BEFORE PUBLICATION] This section records the status
of known implementations of the protocol defined by this specification at the
time of posting of this Internet-Draft, and is based on a proposal described in
<xref target="RFC7942"></xref>.</t>
<t>A summary of current behavior and implementation status can be found here: <eref target="https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status#DNSPrivacyImplementationStatus-XFR/XoTImplementationstatus">XoT implementation status</eref></t>
<t>Specific recent activity includes:</t>

<ol>
<li><t>The 1.9.2 version of
<eref target="https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/Changelog">Unbound</eref>
includes an option to perform AXoT (instead of AXFR-over-TCP).</t>
</li>
<li><t>There are currently open pull requests against NSD to implement</t>

<ol>
<li>Connection re-use by default during <eref target="https://github.com/NLnetLabs/nsd/pull/145">XFR-over-TCP</eref></li>
<li>Client side <eref target="https://github.com/NLnetLabs/nsd/pull/149">XoT</eref></li>
</ol></li>
<li><t>Version 9.17.7 of BIND contained an initial implementation of DoT, implementation of XoT is planned for early <eref target="https://gitlab.isc.org/isc-projects/bind9/-/issues/1784">2021</eref></t>
</li>
</ol>
<t>Both items 1. and 2.2. listed above require the client (secondary) to
authenticate the server (primary) using a configured authentication domain name
if XoT is used.</t>
      <t indent="0" pn="section-14-1">This document has no IANA actions.</t>
    </section>
    <section anchor="security-considerations"><name>Security anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-15">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
<t>This
      <t indent="0" pn="section-15-1">This document specifies a security measure against a DNS risk: the risk that an
attacker collects entire DNS zones through eavesdropping on clear text cleartext DNS zone
transfers.</t>
<t>This
      <t indent="0" pn="section-15-2">This does not mitigate:</t>

<ul>
<li>the
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-15-3">
        <li pn="section-15-3.1">the risk that some level of zone activity might be inferred by observing zone
  transfer sizes and timing on encrypted connections (even with padding
  applied), in combination with obtaining SOA records by directly querying
  authoritative servers.</li>
<li>the servers,</li>
        <li pn="section-15-3.2">the risk that hidden primaries might be inferred or identified via
  observation of encrypted connections.</li>
<li>the connections, or</li>
        <li pn="section-15-3.3">the risk of zone contents being obtained via zone enumeration techniques.</li>
      </ul>
<t>Security
      <t indent="0" pn="section-15-4">Security concerns of DoT are outlined in <xref target="RFC7858"></xref> target="RFC7858" format="default" sectionFormat="of" derivedContent="RFC7858"/> and <xref target="RFC8310"></xref>.</t> target="RFC8310" format="default" sectionFormat="of" derivedContent="RFC8310"/>.</t>
    </section>

<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>The authors thank Tony Finch, Benno Overeinder, Shumon Huque
and Tim Wicinski
  </middle>
  <back>
    <displayreference target="I-D.ietf-dprive-dnsoquic" to="DPRIVE-DNSOQUIC"/>
    <displayreference target="I-D.ietf-tls-esni" to="TLS-ESNI"/>
    <displayreference target="I-D.vcelak-nsec5" to="NSEC5"/>
    <references pn="section-16">
      <name slugifiedName="name-references"> References</name>
      <references pn="section-16.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="DoT-ALPN" target="https://www.iana.org/assignments/tls-extensiontype-values/" quoteTitle="true" derivedAnchor="DoT-ALPN">
          <front>
            <title>TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034" quoteTitle="true" derivedAnchor="RFC1034">
          <front>
            <title>Domain names - concepts and many other members facilities</title>
            <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1987" month="November"/>
            <abstract>
              <t indent="0">This RFC is the revised basic definition of DPRIVE for review and discussions.</t>
<t>The authors particularly thank Peter van Dijk, Ondrej Sury, Brian Dickson The Domain Name System.  It obsoletes RFC-882.  This memo describes the domain style names and
several other open source DNS implementers their used for valuable discussion host address look up and
clarification on electronic mail forwarding.  It discusses the issue associated with pipelining XFR queries clients and handling
out-of-order/intermingled responses.</t>
</section>

<section anchor="contributors"><name>Contributors</name>
<t>Significant contributions to servers in the document were made by:</t>
<t>Han Zhang <br />
   Salesforce<br />
   San Francisco, CA<br />
   United States</t>
<t>Email: hzhang@salesforce.com</t>
</section>

<section anchor="changelog"><name>Changelog</name>
<t>[THIS SECTION TO BE REMOVED BEFORE PUBLICATION]</t>
<t>draft-ietf-dprive-xfr-over-tls-12</t>

<ul>
<li>Changes from IESG review</li>
<li>Add section 8.1 on domain name system and the requirement to use protocol used between them.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="13"/>
          <seriesInfo name="RFC" value="1034"/>
          <seriesInfo name="DOI" value="10.17487/RFC1034"/>
        </reference>
        <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035" quoteTitle="true" derivedAnchor="RFC1035">
          <front>
            <title>Domain names - implementation and specification</title>
            <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1987" month="November"/>
            <abstract>
              <t indent="0">This RFC is the DoT ALPN</li>
<li><t>Modify revised specification of the one protocol and format used in the implementation of the options for validation Domain Name System.  It obsoletes RFC-883. This memo documents the details of a the domain name client from just an IP ACL - server communication.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="13"/>
          <seriesInfo name="RFC" value="1035"/>
          <seriesInfo name="DOI" value="10.17487/RFC1035"/>
        </reference>
        <reference anchor="RFC1995" target="https://www.rfc-editor.org/info/rfc1995" quoteTitle="true" derivedAnchor="RFC1995">
          <front>
            <title>Incremental Zone Transfer in DNS</title>
            <author initials="M." surname="Ohta" fullname="M. Ohta">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1996" month="August"/>
            <abstract>
              <t indent="0">This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1995"/>
          <seriesInfo name="DOI" value="10.17487/RFC1995"/>
        </reference>
        <reference anchor="RFC1996" target="https://www.rfc-editor.org/info/rfc1996" quoteTitle="true" derivedAnchor="RFC1996">
          <front>
            <title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)</title>
            <author initials="P." surname="Vixie" fullname="P. Vixie">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1996" month="August"/>
            <abstract>
              <t indent="0">This memo describes the NOTIFY opcode for DNS, by which a combination master server advises a set of
IP ACL and TSIG/SIG(0)</t>

<ul>
<li>Update Abstract slave servers that the master's data has been changed and Introduction with clear descriptions of how earlier specifications are updated</li>
<li>Add reference on NSEC3 attacks</li>
<li>Justify that a query should be initiated to discover the new data. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1996"/>
          <seriesInfo name="DOI" value="10.17487/RFC1996"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use of SHOULD in sections 7.3.2 and 7.3.3.</li>
<li>Clarify RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the Appendix is non-normative</li>
<li>Numerous typos and editorial improvements.</li>
<li>Use xml2rfc v3 (some format changes occur as a result)</li>
</ul></li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-11</t>

<ul>
<li>Fix definition update missed in -10</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-10</t>

<ul>
<li>Address issued raised from IETF Last Call</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-09</t>

<ul>
<li>Address issued raised requirements in the AD review</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-08</t>

<ul>
<li>RFC2845 -&gt; (obsoleted by) RFC8945</li>
<li>I-D.ietf-dnsop-dns-zone-digest -&gt; RFC8976</li>
<li>Minor editorial changes + email update</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-07</t>

<ul>
<li>Reference RFC7942 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 implementation status section</li>
<li>Convert 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="RFC2931" target="https://www.rfc-editor.org/info/rfc2931" quoteTitle="true" derivedAnchor="RFC2931">
          <front>
            <title>DNS Request and Transaction Signatures ( SIG(0)s )</title>
            <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2000" month="September"/>
            <abstract>
              <t indent="0">This document describes the URIs that will remain on publication to references</li>
<li>Correct typos minor but non-interoperable changes in acknowledgments</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-06</t>

<ul>
<li>Update text relating to pipelining Request and connection reuse after WGLC comments.</li>
<li>Add link to Transaction signature resource records ( SIG(0)s ) that implementation status matrix</li>
<li>Various typos</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-05</t>

<ul>
<li>Remove experience has deemed necessary.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2931"/>
          <seriesInfo name="DOI" value="10.17487/RFC2931"/>
        </reference>
        <reference anchor="RFC5936" target="https://www.rfc-editor.org/info/rfc5936" quoteTitle="true" derivedAnchor="RFC5936">
          <front>
            <title>DNS Zone Transfer Protocol (AXFR)</title>
            <author initials="E." surname="Lewis" fullname="E. Lewis">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Hoenes" fullname="A. Hoenes" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="June"/>
            <abstract>
              <t indent="0">The standard means within the open questions that received no comments.</li>
<li>Add more detail to Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms.  Authoritative Transfer (AXFR) is one of the implementation section</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-04</t>

<ul>
<li>Add Github repository</li>
<li>Fix typos mechanisms and references is defined in RFC 1034 and improve layout.</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-03</t>

<ul>
<li>Remove propose RFC 1035.</t>
              <t indent="0">The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to use ALPN</li>
<li>Clarify updates be compliant to both RFC1995 make assumptions, impeding interoperability.  Yet today we have a satisfactory set of implementations that do interoperate.  This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5936"/>
          <seriesInfo name="DOI" value="10.17487/RFC5936"/>
        </reference>
        <reference anchor="RFC6973" target="https://www.rfc-editor.org/info/rfc6973" quoteTitle="true" derivedAnchor="RFC6973">
          <front>
            <title>Privacy Considerations for Internet Protocols</title>
            <author initials="A." surname="Cooper" fullname="A. Cooper">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Aboba" fullname="B. Aboba">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Peterson" fullname="J. Peterson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Morris" fullname="J. Morris">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Hansen" fullname="M. Hansen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Smith" fullname="R. Smith">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="July"/>
            <abstract>
              <t indent="0">This document offers guidance for developing privacy considerations for inclusion in protocol specifications.  It aims to make designers, implementers, and RFC5936 by adding users of Internet protocols aware of privacy-related design choices.  It suggests that whether any individual RFC warrants a specific sections privacy considerations section will depend on the document's content.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6973"/>
          <seriesInfo name="DOI" value="10.17487/RFC6973"/>
        </reference>
        <reference anchor="RFC7766" target="https://www.rfc-editor.org/info/rfc7766" quoteTitle="true" derivedAnchor="RFC7766">
          <front>
            <title>DNS Transport over TCP - Implementation Requirements</title>
            <author initials="J." surname="Dickinson" fullname="J. Dickinson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Dickinson" fullname="S. Dickinson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Bellis" fullname="R. Bellis">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Mankin" fullname="A. Mankin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Wessels" fullname="D. Wessels">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="March"/>
            <abstract>
              <t indent="0">This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7766"/>
          <seriesInfo name="DOI" value="10.17487/RFC7766"/>
        </reference>
        <reference anchor="RFC7828" target="https://www.rfc-editor.org/info/rfc7828" quoteTitle="true" derivedAnchor="RFC7828">
          <front>
            <title>The edns-tcp-keepalive EDNS0 Option</title>
            <author initials="P." surname="Wouters" fullname="P. Wouters">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Abley" fullname="J. Abley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Dickinson" fullname="S. Dickinson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Bellis" fullname="R. Bellis">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="April"/>
            <abstract>
              <t indent="0">DNS messages between clients and servers may be received over either UDP or TCP.  UDP transport involves keeping less state on this</li>
<li>Add a section on busy server, but can cause truncation and retries over TCP.  Additionally, UDP can be exploited for reflection attacks.  Using TCP would reduce retransmits and amplification.  However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds.</t>
              <t indent="0">This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout.  This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7828"/>
          <seriesInfo name="DOI" value="10.17487/RFC7828"/>
        </reference>
        <reference anchor="RFC7858" target="https://www.rfc-editor.org/info/rfc7858" quoteTitle="true" derivedAnchor="RFC7858">
          <front>
            <title>Specification for DNS over Transport Layer Security (TLS)</title>
            <author initials="Z." surname="Hu" fullname="Z. Hu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Zhu" fullname="L. Zhu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Heidemann" fullname="J. Heidemann">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Mankin" fullname="A. Mankin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Wessels" fullname="D. Wessels">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="May"/>
            <abstract>
              <t indent="0">This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS.  Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626.  In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.</t>
              <t indent="0">This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group.  It does not prevent future applications of the protocol to recursive-to-authoritative traffic.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7858"/>
          <seriesInfo name="DOI" value="10.17487/RFC7858"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">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="RFC8310" target="https://www.rfc-editor.org/info/rfc8310" quoteTitle="true" derivedAnchor="RFC8310">
          <front>
            <title>Usage Profiles for DNS over TLS and DNS over DTLS</title>
            <author initials="S." surname="Dickinson" fullname="S. Dickinson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Gillmor" fullname="D. Gillmor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Reddy" fullname="T. Reddy">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="March"/>
            <abstract>
              <t indent="0">This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS).  These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS.  This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server.  Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS.  This document updates RFC 7858.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8310"/>
          <seriesInfo name="DOI" value="10.17487/RFC8310"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="August"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8499" quoteTitle="true" derivedAnchor="RFC8499">
          <front>
            <title>DNS Terminology</title>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Sullivan" fullname="A. Sullivan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Fujiwara" fullname="K. Fujiwara">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="January"/>
            <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="RFC8914" target="https://www.rfc-editor.org/info/rfc8914" quoteTitle="true" derivedAnchor="RFC8914">
          <front>
            <title>Extended DNS Errors</title>
            <author initials="W." surname="Kumari" fullname="W. Kumari">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Hunt" fullname="E. Hunt">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Arends" fullname="R. Arends">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Hardaker" fullname="W. Hardaker">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Lawrence" fullname="D. Lawrence">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="October"/>
            <abstract>
              <t indent="0">This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8914"/>
          <seriesInfo name="DOI" value="10.17487/RFC8914"/>
        </reference>
        <reference anchor="RFC8945" target="https://www.rfc-editor.org/info/rfc8945" quoteTitle="true" derivedAnchor="RFC8945">
          <front>
            <title>Secret Key Transaction Authentication for DNS (TSIG)</title>
            <author initials="F." surname="Dupont" fullname="F. Dupont">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Morris" fullname="S. Morris">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Vixie" fullname="P. Vixie">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="O." surname="Gudmundsson" fullname="O. Gudmundsson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Wellington" fullname="B. Wellington">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="November"/>
            <abstract>
              <t indent="0">This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing.  It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server.</t>
              <t indent="0">No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism.</t>
              <t indent="0">This document obsoletes RFCs 2845 and 4635.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="93"/>
          <seriesInfo name="RFC" value="8945"/>
          <seriesInfo name="DOI" value="10.17487/RFC8945"/>
        </reference>
      </references>
      <references pn="section-16.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="BIND" target="https://www.isc.org/bind/" quoteTitle="true" derivedAnchor="BIND">
          <front>
            <title>BIND 9.16.16</title>
            <author>
              <organization showOnFrontPage="true">ISC</organization>
            </author>
          </front>
        </reference>
        <reference anchor="I-D.ietf-dprive-dnsoquic" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-dprive-dnsoquic-03" derivedAnchor="DPRIVE-DNSOQUIC">
          <front>
            <title>Specification of DNS over Dedicated QUIC Connections</title>
            <author initials="C." surname="Huitema" fullname="Christian Huitema">
              <organization showOnFrontPage="true">Private Octopus Inc.</organization>
            </author>
            <author initials="S." surname="Dickinson" fullname="Sara Dickinson">
              <organization showOnFrontPage="true">Sinodun IT</organization>
            </author>
            <author initials="A." surname="Mankin" fullname="Allison Mankin">
              <organization showOnFrontPage="true">Salesforce</organization>
            </author>
            <date month="July" day="12" year="2021"/>
            <abstract>
              <t indent="0">   This document describes the use of QUIC to provide transport privacy
   for DNS.  The encryption provided by QUIC has similar properties to
   that provided by TLS, while QUIC transport eliminates the head-of-
   line blocking issues inherent with TCP and provides more efficient
   error corrections than UDP.  DNS over QUIC (DoQ) has privacy
   properties similar to DNS over TLS (DoT) specified in RFC7858, and
   latency characteristics similar to classic DNS over UDP.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-dprive-dnsoquic-03"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-dprive-dnsoquic-03.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="NIST-GUIDE" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf" quoteTitle="true" derivedAnchor="NIST-GUIDE">
          <front>
            <title>Secure Domain Name System (DNS) Deployment Guide</title>
            <author fullname="Ramaswamy Chandramouli" initials="R." surname="Chandramouli">
              <organization showOnFrontPage="true">NIST</organization>
            </author>
            <author fullname="Scott Rose" initials="S." surname="Rose">
              <organization showOnFrontPage="true">NIST</organization>
            </author>
            <date month="September" year="2013"/>
          </front>
        </reference>
        <reference anchor="NSD" target="https://www.nlnetlabs.nl/projects/nsd/about/" quoteTitle="true" derivedAnchor="NSD">
          <front>
            <title>NSD 4.3.6</title>
            <author>
              <organization showOnFrontPage="true">NLnet Labs</organization>
            </author>
          </front>
        </reference>
        <reference anchor="NSEC3-attacks" target="https://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf" quoteTitle="true" derivedAnchor="NSEC3-attacks">
          <front>
            <title>Stretching NSEC3 to the Limit: Efficient Zone Enumeration Attacks on NSEC3 Variants</title>
            <author fullname="Sharon Goldberg" initials="S." surname="Goldberg">
              <organization showOnFrontPage="true">Boston University, Department of Computer Science</organization>
            </author>
            <author fullname="Moni Naor" initials="N." surname="Naor">
              <organization showOnFrontPage="true">Weizmann Institute of Science, Department of Computer Science and Applied Mathematics</organization>
            </author>
            <author fullname="Dimitrios Papadopoulos" initials="D." surname="Papadopoulos">
              <organization showOnFrontPage="true">Boston University, Department of Computer Science</organization>
            </author>
            <author fullname="Leonid Reyzin" initials="L." surname="Reyzin">
              <organization showOnFrontPage="true">Boston University, Department of Computer Science</organization>
            </author>
            <author fullname="Sachin Vasant" initials="S." surname="Vasant">
              <organization showOnFrontPage="true">Boston University, Department of Computer Science</organization>
            </author>
            <author fullname="Asaf Ziv" initials="A." surname="Ziv">
              <organization showOnFrontPage="true">Weizmann Institute of Science, Department of Computer Science and Applied Mathematics</organization>
            </author>
            <date month="February" year="2015"/>
          </front>
        </reference>
        <reference anchor="I-D.vcelak-nsec5" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-vcelak-nsec5-08" derivedAnchor="NSEC5">
          <front>
            <title>NSEC5, DNSSEC Authenticated Denial of Existence</title>
            <author initials="J." surname="Vcelak" fullname="Jan Vcelak">
              <organization showOnFrontPage="true">CZ.NIC</organization>
            </author>
            <author initials="S." surname="Goldberg" fullname="Sharon Goldberg">
              <organization showOnFrontPage="true">Boston University</organization>
            </author>
            <author initials="D." surname="Papadopoulos" fullname="Dimitrios Papadopoulos">
              <organization showOnFrontPage="true">HKUST</organization>
            </author>
            <author initials="S." surname="Huque" fullname="Shumon Huque">
              <organization showOnFrontPage="true">Salesforce</organization>
            </author>
            <author initials="D." surname="Lawrence" fullname="David C Lawrence">
              <organization showOnFrontPage="true">Dyn</organization>
            </author>
            <date month="December" day="29" year="2018"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-vcelak-nsec5-08"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC1982" target="https://www.rfc-editor.org/info/rfc1982" quoteTitle="true" derivedAnchor="RFC1982">
          <front>
            <title>Serial Number Arithmetic</title>
            <author initials="R." surname="Elz" fullname="R. Elz">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Bush" fullname="R. Bush">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1996" month="August"/>
            <abstract>
              <t indent="0">The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood.  This memo supplies the threat model</li>
<li>Convert all SVG diagrams missing definition.  It is intended to ASCII art</li>
<li>Add discussions on concurrency limits</li>
<li>Add discussions on Extended DNS error codes</li>
<li>Re-work authentication requirements and discussion</li>
<li>Add appendix discussion TLS connection management</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-02</t>

<ul>
<li>Significantly update descriptions for both AXoT RFC1034 and IXoT RFC1035.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1982"/>
          <seriesInfo name="DOI" value="10.17487/RFC1982"/>
        </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 initials="B." surname="Laurie" fullname="B. Laurie">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Sisson" fullname="G. Sisson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Arends" fullname="R. Arends">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Blacka" fullname="D. Blacka">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="March"/>
            <abstract>
              <t indent="0">The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for message and
connection handling taking into account previous specifications in more detail</li>
<li>Add use authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of APLN existence.  However, it also provides measures against zone enumeration and limitations on traffic on XoT connections.</li>
<li>Add new discussions permits gradual expansion of padding delegation-centric zones.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5155"/>
          <seriesInfo name="DOI" value="10.17487/RFC5155"/>
        </reference>
        <reference anchor="RFC6891" target="https://www.rfc-editor.org/info/rfc6891" quoteTitle="true" derivedAnchor="RFC6891">
          <front>
            <title>Extension Mechanisms for both AXoT DNS (EDNS(0))</title>
            <author initials="J." surname="Damas" fullname="J. Damas">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Graff" fullname="M. Graff">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Vixie" fullname="P. Vixie">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="April"/>
            <abstract>
              <t indent="0">The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and IXoT</li>
<li>Add text on SIG(0)</li>
<li>Update security considerations</li>
<li>Move multi-primary considerations does not allow requestors to earlier as they are related advertise their capabilities to connection
handling</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-01</t>

<ul>
<li>Minor editorial updates</li>
<li>Add requirement responders.  This document describes backward-compatible mechanisms for TLS 1.3. or later</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-00</t>

<ul>
<li>Rename after adoption allowing the protocol to grow.</t>
              <t indent="0">This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations.  It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and reference update.</li>
<li>Add placeholder for SIG(0) discussion</li>
<li>Update section adds considerations on ZONEMD</li>
</ul>
<t>draft-hzpa-dprive-xfr-over-tls-02</t>

<ul>
<li>Substantial re-work the use of extended labels in the document.</li>
</ul>
<t>draft-hzpa-dprive-xfr-over-tls-01</t>

<ul>
<li>Editorial changes, updates to references.</li>
</ul>
<t>draft-hzpa-dprive-xfr-over-tls-00</t>

<ul>
<li>Initial commit</li>
</ul>
<t>[-@?I-D.ietf-tls-esni]</t>
</section>

</middle>

<back>
<references><name>Normative References</name>
<reference anchor="DoT-ALPN" target="https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids">
  <front>
    <title>TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs</title>
    <author>
      <organization>IANA</organization>
    </author>
    <date year="2021"></date> DNS.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="75"/>
          <seriesInfo name="RFC" value="6891"/>
          <seriesInfo name="DOI" value="10.17487/RFC6891"/>
        </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1995.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1996.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2931.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5936.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7766.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7828.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8310.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8914.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8945.xml"/>
</references>
<references><name>Informative References</name>
        <reference anchor="BIND" target="https://www.isc.org/bind/"> anchor="RFC8484" target="https://www.rfc-editor.org/info/rfc8484" quoteTitle="true" derivedAnchor="RFC8484">
          <front>
    <title>BIND 9.16.16</title>
    <author>
      <organization>ISC</organization>
            <title>DNS Queries over HTTPS (DoH)</title>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization showOnFrontPage="true"/>
            </author>
    <date year="2021"></date>
  </front>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-dprive-dnsoquic.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-dprive-phase2-requirements.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-dprive-rfc7626-bis.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-tls-esni.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.vcelak-nsec5.xml"/>
<reference anchor="NSD" target="https://www.nlnetlabs.nl/projects/nsd/about/">
  <front>
    <title>NSD 4.3.6</title>
    <author>
      <organization>NLnet Labs</organization>
            <author initials="P." surname="McManus" fullname="P. McManus">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021"></date> year="2018" month="October"/>
            <abstract>
              <t indent="0">This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS.  Each DNS query-response pair is mapped into an HTTP exchange.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8484"/>
          <seriesInfo name="DOI" value="10.17487/RFC8484"/>
        </reference>
        <reference anchor="NSEC3-attacks" target="https://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf"> anchor="RFC8976" target="https://www.rfc-editor.org/info/rfc8976" quoteTitle="true" derivedAnchor="RFC8976">
          <front>
    <title>Stretching NSEC3 to the Limit:&#xA;Efficient Zone Enumeration Attacks on NSEC3 Variants</title>
            <title>Message Digest for DNS Zones</title>
            <author fullname="Sharon Goldberg" initials="S." surname="Goldberg">
      <organization> Boston University, Department of Computer Science</organization> initials="D." surname="Wessels" fullname="D. Wessels">
              <organization showOnFrontPage="true"/>
            </author>
            <author fullname="Moni Naor" initials="N." surname="Naor">
      <organization>Weizmann Institute of Science, Department of Computer Science and Applied Mathematics</organization> initials="P." surname="Barber" fullname="P. Barber">
              <organization showOnFrontPage="true"/>
            </author>
            <author fullname="Dimitrios Papadopoulos" initials="D." surname="Papadopoulos">
      <organization> Boston University, Department of Computer Science</organization> initials="M." surname="Weinberg" fullname="M. Weinberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author fullname="Leonid Reyzin" initials="L." surname="Reyzin">
      <organization> Boston University, Department of Computer Science</organization> initials="W." surname="Kumari" fullname="W. Kumari">
              <organization showOnFrontPage="true"/>
            </author>
            <author fullname="Sachin Vasant" initials="S." surname="Vasant">
      <organization> Boston University, Department of Computer Science</organization> initials="W." surname="Hardaker" fullname="W. Hardaker">
              <organization showOnFrontPage="true"/>
            </author>
    <author fullname="Asaf Ziv" initials="A." surname="Ziv">
      <organization>Weizmann Institute of Science, Department
            <date year="2021" month="February"/>
            <abstract>
              <t indent="0">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 Computer Science how the zone data has been transmitted and Applied Mathematics</organization> received.  When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes. </t>
              <t indent="0">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 indent="0">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>
          <seriesInfo name="RFC" value="8976"/>
          <seriesInfo name="DOI" value="10.17487/RFC8976"/>
        </reference>
        <reference anchor="RFC9076" target="https://www.rfc-editor.org/info/rfc9076" quoteTitle="true" derivedAnchor="RFC9076">
          <front>
            <title>DNS Privacy Considerations</title>
            <author initials="T." surname="Wicinski" fullname="T. Wicinski" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015"></date> year="2021" month="July"/>
            <abstract>
              <t indent="0">This document describes the privacy issues associated with the use of the DNS by Internet users. It provides general observations about typical current privacy practices. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9076"/>
          <seriesInfo name="DOI" value="10.17487/RFC9076"/>
        </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1982.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8976.xml"/>
        <reference anchor="nist-guide" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf"> anchor="I-D.ietf-tls-esni" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-13" derivedAnchor="TLS-ESNI">
          <front>
    <title>Secure Domain Name System (DNS) Deployment Guide</title>
            <title>TLS Encrypted Client Hello</title>
            <author fullname="Ramaswamy Chandramouli" initials="R." surname="Chandramouli">
      <organization>NIST</organization> initials="E." surname="Rescorla" fullname="Eric Rescorla">
              <organization showOnFrontPage="true">RTFM, Inc.</organization>
            </author>
            <author fullname="Scott Rose" initials="S." surname="Rose">
      <organization>NIST</organization> initials="K." surname="Oku" fullname="Kazuho Oku">
              <organization showOnFrontPage="true">Fastly</organization>
            </author>
            <author initials="N." surname="Sullivan" fullname="Nick Sullivan">
              <organization showOnFrontPage="true">Cloudflare</organization>
            </author>
            <author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
              <organization showOnFrontPage="true">Cloudflare</organization>
            </author>
            <date year="2013"></date> month="August" day="12" year="2021"/>
            <abstract>
              <t indent="0">   This document describes a mechanism in Transport Layer Security (TLS)
   for encrypting a ClientHello message under a server public key.

Discussion Venues

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

   Source for this draft and an issue tracker can be found at
   https://github.com/tlswg/draft-ietf-tls-esni
   (https://github.com/tlswg/draft-ietf-tls-esni).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-13"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-tls-esni-13.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="xot-server-connection-handling"><name>XoT server connection handling</name>
<t>This anchor="xot-server-connection-handling" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-xot-server-connection-handl">XoT Server Connection Handling</name>
      <t indent="0" pn="section-appendix.a-1">This appendix provides a non-normative outline of the pros and cons of XoT server connection
handling
  connection-handling options.</t>
<t>For
      <t indent="0" pn="section-appendix.a-2">For completeness, it is noted that an earlier draft version of the specification this document
  suggested using a XoT specific XoT-specific ALPN to negotiate TLS connections that supported
  only a limited set of queries (SOA, XRFs), XFRs); however, this did not gain support.
  Reasons given included additional code complexity and the fact that XoT and ADoT are both
  DNS wire format and so should share the <tt>dot</tt> ALPN.</t>
      <section anchor="only-listen-on-tls-on-a-specific-ip-address"><name>Only listen on TLS anchor="only-listen-on-tls-on-a-specific-ip-address" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.1">
        <name slugifiedName="name-listening-only-on-a-specifi">Listening Only on a specific Specific IP address</name>
<t>Obviously Address for TLS</name>
        <t indent="0" pn="section-appendix.a.1-1">Obviously, a nameserver which name server that hosts a zone and services queries for the zone on
  an IP address published in an NS record may wish to use a separate IP address
  for listening on TLS XoT to listen for XoT, TLS, only publishing that address to its secondaries.</t>
<t>Pros: Probing
        <dl newline="false" spacing="normal" indent="3" pn="section-appendix.a.1-2">
          <dt pn="section-appendix.a.1-2.1">Pros:</dt>
          <dd pn="section-appendix.a.1-2.2">Probing of the public IP address will show no support for TLS. ACLs will
    prevent zone transfer on all transports on a per query basis.</t>
<t>Cons: Attackers per-query basis.</dd>
          <dt pn="section-appendix.a.1-2.3">Cons:</dt>
          <dd pn="section-appendix.a.1-2.4">Attackers passively observing traffic will still be able to observe TLS
    connections to the separate address.</t> address.</dd>
        </dl>
      </section>
      <section anchor="client-specific-tls-acceptance"><name>Client specific TLS acceptance</name>
<t>Primaries anchor="client-specific-tls-acceptance" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.2">
        <name slugifiedName="name-client-specific-tls-accepta">Client-Specific TLS Acceptance</name>
        <t indent="0" pn="section-appendix.a.2-1">Primaries that include IP based IP-based ACLs and/or mutual TLS in their authentication models
  have the option of only accepting TLS connections from authorized clients. This
  could be implemented either using a proxy or directly in the DNS implementation.</t>
<t>Pros: Connection
        <dl newline="false" spacing="normal" indent="3" pn="section-appendix.a.2-2">
          <dt pn="section-appendix.a.2-2.1">Pros:</dt>
          <dd pn="section-appendix.a.2-2.2">Connection management happens at setup time. The maximum number of TLS
    connections a server will have to support can be easily assessed. Once the
    connection is accepted accepted, the server might well be willing to answer any query on
    that connection since it is coming from a configured secondary secondary, and a specific
    response policy on the connection may not be needed (see below).</t>
<t>Cons: Currently, below).</dd>
          <dt pn="section-appendix.a.2-2.3">Cons:</dt>
          <dd pn="section-appendix.a.2-2.4">Currently, none of the major open source open-source
    implementations of a DNS authoritative
implementations server support such an option.</t> option.</dd>
        </dl>
      </section>
      <section anchor="sni-based-tls-acceptance"><name>SNI based TLS acceptance</name>
<t>Primaries anchor="sni-based-tls-acceptance" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.3">
        <name slugifiedName="name-sni-based-tls-acceptance">SNI-Based TLS Acceptance</name>
        <t indent="0" pn="section-appendix.a.3-1">Primaries could also choose to only accept TLS connections based on an SNI a Server Name
  Indication (SNI) that was published only to their secondaries.</t>
<t>Pros: Reduces
        <dl newline="false" spacing="normal" indent="3" pn="section-appendix.a.3-2">
          <dt pn="section-appendix.a.3-2.1">Pros:</dt>
          <dd pn="section-appendix.a.3-2.2">Reduces the number of accepted connections.</t>
<t>Cons: As connections.</dd>
          <dt pn="section-appendix.a.3-2.3">Cons:</dt>
          <dd pn="section-appendix.a.3-2.4">As above. Also, this is not a recommended use of SNI. For SNIs sent in the
    clear, this would still allow attackers passively observing traffic to
    potentially abuse this mechanism. The use of Encrypted Client Hello
    <xref target="I-D.ietf-tls-esni"></xref> target="I-D.ietf-tls-esni" format="default" sectionFormat="of" derivedContent="TLS-ESNI"/> may be of use here.</t> here.</dd>
        </dl>
      </section>
      <section anchor="transport-specific-response-policies"><name>Transport specific response policies</name>
<t>Some anchor="transport-specific-response-policies" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.4">
        <name slugifiedName="name-transport-specific-response">Transport-Specific Response Policies</name>
        <t indent="0" pn="section-appendix.a.4-1">Some primaries might rely on TSIG/SIG(0) combined with per-query IP based per-query, IP-based
  ACLs to authenticate secondaries. In this case case, the primary must accept all
  incoming TLS/TCP connections and then apply a transport-specific response policy on a per
query
  per-query basis.</t>
<t>As
        <t indent="0" pn="section-appendix.a.4-2">As an aside, whilst <xref target="RFC7766"></xref> target="RFC7766" format="default" sectionFormat="of" derivedContent="RFC7766"/> makes a general purpose distinction in
  the advice to clients
  about their usage of connections (between regular queries and zone transfers) transfers), this is
  not strict strict, and nothing in the DNS protocol prevents using the same connection
  for both types of traffic. Hence Hence, a server cannot know the intention of any
  client that connects to it, it; it can only inspect the messages it receives on
  such a connection and make per-query decisions about whether or not to answer
  those queries.</t>
<t>Example
        <t indent="0" pn="section-appendix.a.4-3">Example policies a XoT server might implement are:</t>

<ul>
<li>strict: REFUSE
        <dl newline="false" spacing="normal" indent="12" pn="section-appendix.a.4-4">
          <dt pn="section-appendix.a.4-4.1">strict:</dt>
          <dd pn="section-appendix.a.4-4.2">REFUSE all queries on TLS connections connections, except SOA and authorized XFR requests</li>
<li>moderate: REFUSE requests</dd>
          <dt pn="section-appendix.a.4-4.3">moderate:</dt>
          <dd pn="section-appendix.a.4-4.4">REFUSE all queries on TLS connections until one is received that is
    signed by a recognized TSIG/SIG(0) key, then answer all queries on the
    connection after that</li>
<li>complex: apply that</dd>
          <dt pn="section-appendix.a.4-4.5">complex:</dt>
          <dd pn="section-appendix.a.4-4.6">apply a heuristic to determine which queries on a TLS connections to REFUSE</li>
<li>relaxed: answer REFUSE</dd>
          <dt pn="section-appendix.a.4-4.7">relaxed:</dt>
          <dd pn="section-appendix.a.4-4.8">answer all non-XoT queries on all TLS connections with the same policy applied to TCP queries</li>
</ul>
<t>Pros: Allows
    queries</dd>
        </dl>
        <dl newline="false" spacing="normal" indent="3" pn="section-appendix.a.4-5">
          <dt pn="section-appendix.a.4-5.1">Pros:</dt>
          <dd pn="section-appendix.a.4-5.2">Allows for flexible behavior by the server that could be changed over time.</t>
<t>Cons: The time.</dd>
          <dt pn="section-appendix.a.4-5.3">Cons:</dt>
          <dd pn="section-appendix.a.4-5.4">The server must handle the burden of accepting all TLS connections just
    to perform XFRs with a small number of secondaries. Client behavior to a REFUSED
    response is not clearly defined (see <xref target="response-rcodes"></xref>). target="response-rcodes" format="default" sectionFormat="of" derivedContent="Section 7.8"/>). Currently,
    none of the major open
source open-source implementations of a DNS authoritative implementations server offer an option for different response
    policies in different transports (but such functionality could potentially be implemented
    using a proxy).</t> proxy).</dd>
        </dl>
        <section anchor="sni-based-response-policies"><name>SNI based response policies</name>
<t>In anchor="sni-based-response-policies" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a.4.1">
          <name slugifiedName="name-sni-based-response-policies">SNI-Based Response Policies</name>
          <t indent="0" pn="section-appendix.a.4.1-1">In a similar fashion, XoT servers might use the presence of an SNI in the
client hello
  Client Hello to determine which response policy to initially apply to the TLS
  connections.</t>
<t>Pros: This
          <dl newline="false" spacing="normal" indent="3" pn="section-appendix.a.4.1-2">
            <dt pn="section-appendix.a.4.1-2.1">Pros:</dt>
            <dd pn="section-appendix.a.4.1-2.2">This has to the potential to allow a clean distinction between a XoT service
    and any future DoT based DoT-based service for answering recursive queries.</t>
<t>Cons: As above.</t> queries.</dd>
            <dt pn="section-appendix.a.4.1-2.3">Cons:</dt>
            <dd pn="section-appendix.a.4.1-2.4">As above.</dd>
          </dl>
        </section>
      </section>
    </section>
    <section anchor="acknowledgements" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.b-1">The authors thank <contact fullname="Tony Finch"/>, <contact fullname="Benno   Overeinder"/>, <contact fullname="Shumon Huque"/>,
  <contact fullname="Tim Wicinski"/>, and many other members of DPRIVE for review and
  discussions.</t>
      <t indent="0" pn="section-appendix.b-2">The authors particularly thank <contact fullname="Peter van Dijk"/>,
  <contact fullname="Ondrej Sury"/>, <contact fullname="Brian Dickson"/>, and
  several other open-source DNS implementers for valuable discussion and
  clarification on the issue associated with pipelining XFR queries and handling
  out-of-order/intermingled responses.</t>
    </section>
    <section anchor="contributors" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-contributors">Contributors</name>
      <t indent="0" pn="section-appendix.c-1">Significant contributions to the document were made by:</t>
      <contact fullname="Han Zhang">
        <organization showOnFrontPage="true">Salesforce</organization>
        <address>
          <postal>
            <street/>
            <city>San Francisco</city>
            <region>CA</region>
            <country>United States of America</country>
          </postal>
          <email>hzhang@salesforce.com</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="W." surname="Toorop" fullname="Willem Toorop">
        <organization showOnFrontPage="true">NLnet Labs</organization>
        <address>
          <postal>
            <street>Science Park 400</street>
            <city>Amsterdam</city>
            <code>1098 XH</code>
            <country>Netherlands</country>
          </postal>
          <email>willem@nlnetlabs.nl</email>
        </address>
      </author>
      <author initials="S." surname="Dickinson" fullname="Sara Dickinson">
        <organization showOnFrontPage="true">Sinodun IT</organization>
        <address>
          <postal>
            <extaddr>Magdalen Centre</extaddr>
            <street>Oxford Science Park</street>
            <city>Oxford</city>
            <code>OX4 4GA</code>
            <country>United Kingdom</country>
          </postal>
          <email>sara@sinodun.com</email>
        </address>
      </author>
      <author initials="S." surname="Sahib" fullname="Shivan Sahib">
        <organization showOnFrontPage="true">Brave Software</organization>
        <address>
          <postal>
            <city>Vancouver</city>
            <region>BC</region>
            <country>Canada</country>
          </postal>
          <email>shivankaulsahib@gmail.com</email>
        </address>
      </author>
      <author initials="P." surname="Aras" fullname="Pallavi Aras">
        <organization showOnFrontPage="true">Salesforce</organization>
        <address>
          <postal>
            <city>Herndon</city>
            <region>VA</region>
            <country>United States of America</country>
          </postal>
          <email>paras@salesforce.com</email>
        </address>
      </author>
      <author initials="A." surname="Mankin" fullname="Allison Mankin">
        <organization showOnFrontPage="true">Salesforce</organization>
        <address>
          <postal>
            <city>Herndon</city>
            <region>VA</region>
            <country>United States of America</country>
          </postal>
          <email>allison.mankin@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>