rfc9103.original.xml   rfc9103.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process or - mmark.miek.nl" --> <!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process or - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-ietf-dprive-xfr-over-tls-12" s
ubmissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/20 <rfc version="3" ipr="trust200902" docName="draft-ietf-dprive-xfr-over-tls-12" n
01/XInclude" updates="1995, 5936, 7766" consensus="true"> umber="9103" submissionType="IETF" category="std" consensus="true" xml:lang="en"
xmlns:xi="http://www.w3.org/2001/XInclude" symRefs="true" sortRefs="true" tocIn
clude="true" updates="1995, 5936, 7766">
<front> <front>
<title abbrev="XFR-over-TLS">DNS Zone Transfer-over-TLS</title><seriesInfo value <title abbrev="XFR over TLS">DNS Zone Transfer over TLS</title>
="draft-ietf-dprive-xfr-over-tls-12" stream="IETF" status="standard" name="Inter <seriesInfo name="RFC" value="9103"/>
net-Draft"></seriesInfo> <author initials="W." surname="Toorop" fullname="Willem Toorop">
<author initials="W." surname="Toorop" fullname="Willem Toorop"><organization>NL <organization>NLnet Labs</organization>
net Labs</organization><address><postal><street></street> <address>
<street>Science Park 400</street> <postal>
<city>Amsterdam</city> <street>Science Park 400</street>
<code>1098 XH</code> <city>Amsterdam</city>
<country>The Netherlands</country> <code>1098 XH</code>
</postal><email>willem@nlnetlabs.nl</email> <country>Netherlands</country>
</address></author> </postal>
<author initials="S." surname="Dickinson" fullname="Sara Dickinson"><organizatio <email>willem@nlnetlabs.nl</email>
n>Sinodun IT</organization><address><postal><street></street> </address>
<street>Magdalen Centre</street> </author>
<street>Oxford Science Park</street> <author initials="S." surname="Dickinson" fullname="Sara Dickinson">
<city>Oxford</city> <organization>Sinodun IT</organization>
<code>OX4 4GA</code> <address>
<country>United Kingdom</country> <postal>
</postal><email>sara@sinodun.com</email> <extaddr>Magdalen Centre</extaddr>
</address></author> <street>Oxford Science Park</street>
<author initials="S." surname="Sahib" fullname="Shivan Sahib"><organization>Brav <city>Oxford</city>
e Software</organization><address><postal><street></street> <code>OX4 4GA</code>
<city>Vancouver, BC</city> <country>United Kingdom</country>
<country>Canada</country> </postal>
</postal><email>shivankaulsahib@gmail.com</email> <email>sara@sinodun.com</email>
</address></author> </address>
<author initials="P." surname="Aras" fullname="Pallavi Aras"><organization>Sales </author>
force</organization><address><postal><street></street> <author initials="S." surname="Sahib" fullname="Shivan Sahib">
<city>Herndon, VA</city> <organization>Brave Software</organization>
<country>United States</country> <address>
</postal><email>paras@salesforce.com</email> <postal>
</address></author> <city>Vancouver</city>
<author initials="A." surname="Mankin" fullname="Allison Mankin"><organization>S <region>BC</region>
alesforce</organization><address><postal><street></street> <country>Canada</country>
<city>Herndon, VA</city> </postal>
<country>United States</country> <email>shivankaulsahib@gmail.com</email>
</postal><email>allison.mankin@gmail.com</email> </address>
</address></author> </author>
<date year="2021" month="May" day="26"></date> <author initials="P." surname="Aras" fullname="Pallavi Aras">
<organization>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>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>
<date year="2021" month="August"></date>
<area>Internet</area> <area>Internet</area>
<workgroup>dprive</workgroup> <workgroup>dprive</workgroup>
<keyword>DNS</keyword> <keyword>DNS</keyword>
<keyword>operations</keyword> <keyword>operations</keyword>
<keyword>privacy</keyword> <keyword>privacy</keyword>
<abstract> <abstract>
<t>DNS zone transfers are transmitted in clear text, which gives attackers the <t>DNS zone transfers are transmitted in cleartext, which gives attackers the
opportunity to collect the content of a zone by eavesdropping on network opportunity to collect the content of a zone by eavesdropping on network
connections. The DNS Transaction Signature (TSIG) mechanism is specified to connections. The DNS Transaction Signature (TSIG) mechanism is specified to
restrict direct zone transfer to authorized clients only, but it does not add restrict direct zone transfer to authorized clients only, but it does not add
confidentiality. This document specifies the use of TLS, rather than clear confidentiality. This document specifies the use of TLS, rather than cleartext
text, to prevent zone content collection via passive monitoring of zone ,
transfers: XFR-over-TLS (XoT). Additionally, this specification updates RFC1995 to prevent zone content collection via passive monitoring of zone
and RFC5936 with respect to efficient use of TCP connections, and RFC7766 with transfers: XFR over TLS (XoT). Additionally, this specification updates RFC 19
respect to the recommended number of connections between a client and server 95
for each transport.</t> and RFC 5936 with respect to efficient use of TCP connections and RFC 7766 wit
h
respect to the recommended number of connections between a client and server
for each transport.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction">
<section anchor="introduction"><name>Introduction</name> <name>Introduction</name>
<t>DNS has a number of privacy vulnerabilities, as discussed in detail in <t>DNS has a number of privacy vulnerabilities, as discussed in detail in
<xref target="I-D.ietf-dprive-rfc7626-bis"></xref>. Stub client to recursive res <xref target="RFC9076"></xref>. Query privacy between stub resolvers and recur
olver query privacy has received the sive resolvers has received
most attention to date, with standards track documents for both DNS-over-TLS the most attention to date, with Standards Track documents for both DNS over T
(DoT) <xref target="RFC7858"></xref> and DNS-over-HTTPS (DoH) <xref target="RFC8 LS
484"></xref>, and a proposal for (DoT) <xref target="RFC7858"></xref> and DNS over HTTPS (DoH) <xref target="RF
DNS-over-QUIC <xref target="I-D.ietf-dprive-dnsoquic"></xref>. There is ongoing C8484"></xref>
work on DNS privacy and a proposal for
requirements for exchanges between recursive resolvers and authoritative DNS over QUIC <xref target="I-D.ietf-dprive-dnsoquic"></xref>. There is ongoin
servers <xref target="I-D.ietf-dprive-phase2-requirements"></xref> and some sugg g work on DNS
estions for how privacy
signaling of DoT support by authoritative nameservers might work. However, there requirements for exchanges between recursive resolvers and authoritative
is currently no RFC servers and some suggestions for
that specifically defines recursive to authoritative DNS-over-TLS (ADoT).</t> how signaling of DoT support by authoritative name servers might work. However
<t><xref target="I-D.ietf-dprive-rfc7626-bis"></xref> established that stub clie , there is
nt DNS query currently no RFC that specifically defines recursive-to-authoritative DNS over
transactions are not public and needed protection, but on zone transfer TLS
<xref target="RFC1995"></xref> <xref target="RFC5936"></xref> it says only:</t> (ADoT).</t>
<t><xref target="RFC9076"></xref> establishes that a stub resolver's DNS query
<artwork>&quot;Privacy risks for the holder of a zone (the risk that someone transactions are not public and that they need protection, but, on zone transf
gets the data) are discussed in [RFC5936] and [RFC5155].&quot; er
</artwork> <xref target="RFC1995"></xref> <xref target="RFC5936"></xref>, it says only:</
<t>In what way is exposing the full contents of a zone a privacy risk? The t>
contents of the zone could include information such as names of persons used in <blockquote>Privacy risks for the holder of a zone (the risk that someone
names of hosts. Best practice is not to use personal information for domain gets the data) are discussed in <xref target="RFC5155" format="default"/> and
names, but many such domain names exist. The contents of the zone could also <xref
include references to locations that allow inference about location information target="RFC5936" format="default"/>.</blockquote>
of the individuals associated with the zone's organization. It could also <t>In what way is exposing the full contents of a zone a privacy risk? The
include references to other organizations. Examples of this could be:</t> contents of the zone could include information such as names of persons used i
n
<ul> names of hosts. Best practice is not to use personal information for domain
<li>Person-laptop.example.org</li> names, but many such domain names exist. The contents of the zone could also
<li>MX-for-Location.example.org</li> include references to locations that allow inference about location informatio
<li>Service-tenant-from-another-org.example.org</li> n
</ul> of the individuals associated with the zone's organization. It could also
<t>Additionally, the full zone contents expose all the IP addresses of endpoints include references to other organizations. Examples of this could be:</t>
held in the DNS records which can make reconnaissance and attack targeting easie <ul>
r, particularly for <li>Person-laptop.example.org</li>
IPv6 addresses or private networks. There may also be regulatory, policy or othe <li>MX-for-Location.example.org</li>
r reasons why the <li>Service-tenant-from-another-org.example.org</li>
zone contents in full must be treated as private.</t> </ul>
<t>Neither of the RFCs mentioned in <xref target="I-D.ietf-dprive-rfc7626-bis">< <t>Additionally, the full zone contents expose all the IP addresses of endpoin
/xref> ts
contemplates the risk that someone gets the data through eavesdropping on held in the DNS records, which can make reconnaissance and attack targeting ea
network connections, only via enumeration or unauthorized transfer as described sier,
in the following paragraphs.</t> particularly
<t>Zone enumeration is trivially possible for DNSSEC zones which use NSEC; i.e. for IPv6 addresses or private networks. There may also be regulatory, policy,
queries for the authenticated denial of existence records allow a client to or other
walk through the entire zone contents. <xref target="RFC5155"></xref> specifies reasons why the zone contents in full must be treated as private.</t>
NSEC3, a mechanism <t>Neither of the RFCs mentioned in <xref target="RFC9076"></xref>
to provide measures against zone enumeration for DNSSEC signed zones (a goal contemplate the risk that someone gets the data through eavesdropping on
was to make it as hard to enumerate a DNSSEC signed zone as an unsigned zone). network connections, only via enumeration or unauthorized transfer, as describ
Whilst this is widely used, it has been demonstrated that zone walking is ed
possible for precomputed NSEC3 using attacks such as those described in in the following paragraphs.</t>
<xref target="NSEC3-attacks"></xref>. This prompted further work on an alternati <t>Zone enumeration is trivially possible for DNSSEC zones that use NSEC, i.e.
ve ,
mechanism for DNSSEC authenticated denial of existence - NSEC5 queries for the authenticated denial-of-existence records allow a client to
<xref target="I-D.vcelak-nsec5"></xref> - however questions remain over the prac walk through the entire zone contents. <xref target="RFC5155"></xref> specifie
ticality of this s NSEC3, a
mechanism.</t> mechanism to provide measures against zone enumeration for DNSSEC-signed zones
<t><xref target="RFC5155"></xref> does not address data obtained outside zone en (a goal
umeration (nor does was to make it as hard to enumerate a DNSSEC-signed zone as an unsigned zone).
<xref target="I-D.vcelak-nsec5"></xref>). Preventing eavesdropping of zone trans Whilst this is widely used, it has been demonstrated that zone walking is
fers (this document) possible for precomputed NSEC3 using attacks, such as those described in
is orthogonal to preventing zone enumeration, though they aim to protect the <xref target="NSEC3-attacks"></xref>. This prompted further work on an alterna
same information.</t> tive
<t><xref target="RFC5936"></xref> specifies using TSIG <xref target="RFC8945"></ mechanism for DNSSEC-authenticated denial of existence (NSEC5
xref> for authorization of the clients <xref target="I-D.vcelak-nsec5"></xref>); however, questions remain over the p
of a zone transfer and for data integrity, but does not express any need for racticality of
confidentiality, and TSIG does not offer encryption.</t> this mechanism.</t>
<t>Section 8 of the NIST guide on 'Secure Domain Name System (DNS) Deployment' <t><xref target="RFC5155"></xref> does not address data obtained outside zone
<xref target="nist-guide"></xref> discusses restricting access for zone transfer enumeration (nor
s using ACLs and does <xref target="I-D.vcelak-nsec5"></xref>). Preventing eavesdropping of zon
TSIG in more detail. It also discusses the possibility that specific deployments e transfers (as
might choose to use a lower level network layer to protect zone transfers, e.g., described in this document) is orthogonal to preventing zone enumeration, thou
IPSec.</t> gh they aim to
<t>It is noted that in all the common open source implementations protect the same information.</t>
such ACLs are applied on a per query basis (at the time of writing). Since reque <t><xref target="RFC5936"></xref> specifies using TSIG <xref target="RFC8945">
sts typically occur on </xref> for
TCP connections authoritatives must therefore accept any TCP connection and authorization of the clients
then handling the authentication of each zone transfer (XFR) request individuall of a zone transfer and for data integrity but does not express any need for
y.</t> confidentiality, and TSIG does not offer encryption.</t>
<t>Because both AXFR (authoritative transfer) and IXFR (incremental transfer) ar <t>Section 8 of the NIST document "Secure Domain Name System (DNS) Deployment
e typically carried out over TCP Guide"
from authoritative DNS protocol implementations, encrypting zone transfers <xref target="NIST-GUIDE"></xref> discusses restricting access for zone transf
using TLS <xref target="RFC8499"></xref>, based closely on DoT <xref target="RFC ers using
7858"></xref>, seems like a simple step forward. Access Control Lists (ACLs) and
This document specifies how to use TLS (1.3 or later) as a transport to prevent TSIG in more detail. It also discusses the possibility that specific deploymen
zone ts
collection from zone transfers.</t> might choose to use a lower-level network layer to protect zone transfers, e.g
<t>This document also updates the previous specifications for zone transfers to ., IPsec.</t>
clarify and extend them, mainly with respect to TCP usage:</t> <t>It is noted that in all the common open-source implementations
such ACLs are applied on a per-query basis (at the time of writing). Since req
<ul> uests
<li><eref target="IXFR">RFC1995</eref> and <eref target="AXFR">RFC5936</eref> ar typically occur on TCP connections, authoritative servers must therefore accep
e both updated to add further t any TCP connection
specification on efficient use of TCP connections</li> and then handle the authentication of each zone transfer (XFR) request individ
<li>Section 6.2.2 of <eref target="DNS Transport over TCP - Implementation ually.</t>
Requirements">RFC7766</eref> is updated with a new recommendation about the numb <t>Because both AXFR (authoritative transfer) and IXFR (incremental zone trans
er of fer) are
connections between a client and server for each transport.</li> typically carried out over TCP
</ul> from authoritative DNS protocol implementations, encrypting zone transfers
</section> using TLS <xref target="RFC8499"></xref> -- based closely on DoT <xref
target="RFC7858"></xref> -- seems like a simple step forward.
<section anchor="document-work-via-github"><name>Document work via GitHub</name> This document specifies how to use TLS (1.3 or later) as a transport to preven
<t>[THIS SECTION TO BE REMOVED BEFORE PUBLICATION] The Github repository for thi t zone
s collection from zone transfers.</t>
document is at <eref target="https://github.com/hanzhang0116/hzpa-dprive-xfr-ove <t>This document also updates the previous specifications for zone transfers t
r-tls">https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls</eref>. o
Proposed text and editorial changes are very much welcomed there, but any clarify and extend them, mainly with respect to TCP usage:</t>
functional changes should always first be discussed on the IETF DPRIVE WG (dns-p <ul>
rivacy) mailing list.</t> <li><xref target="RFC1995" format="default"/> (IXFR) and <xref target="RFC59
36"
format="default"/> (AXFR) are both updated to add further
specification on efficient use of TCP connections.</li>
<li><xref target="RFC7766" sectionFormat="of" section="6.2.2"/> ("DNS Transp
ort over TCP -
Implementation Requirements") is updated with a new recommendation about
the number of connections between a client and server for each transport.</l
i>
</ul>
</section> </section>
<section anchor="terminology">
<section anchor="terminology"><name>Terminology</name> <name>Terminology</name>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, & <t>
quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
&quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, &q IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
uot;MAY&quot;, and &quot;OPTIONAL&quot; in this NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
document are to be interpreted as described in BCP 14 <xref target="RFC2119"></x RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
ref> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<xref target="RFC8174"></xref> when, and only when, they appear in all capitals, be interpreted as
as shown here.</t> described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
<t>Privacy terminology is as described in Section 3 of <xref target="RFC6973"></ when, and only when, they appear in all capitals, as shown here.
xref>.</t> </t>
<t>DNS terminology is as described in <xref target="RFC8499"></xref>. Note that <t>Privacy terminology is as described in <xref target="RFC6973" sectionF
as in <xref target="RFC8499"></xref>, the ormat="of"
terms 'primary' and 'secondary' are used for two servers engaged in zone transfe section="3"/>.</t>
rs.</t> <t>DNS terminology is as described in <xref target="RFC8499"></xref>. Not
<t>DoT: DNS-over-TLS as specified in <xref target="RFC7858"></xref></t> e that, as in
<t>XFR-over-TCP: Used to mean both IXFR-over-TCP <xref target="RFC1995"></xref> <xref target="RFC8499"></xref>, the
and AXFR-over-TCP <xref target="RFC5936"></xref>.</t> terms 'primary' and 'secondary' are used for two servers engaged in zone
<t>XoT: XFR-over-TLS mechanisms as specified in this document which apply to bot transfers.</t>
h AXFR-over-TLS and IXFR-over-TLS</t> <dl newline="false" spacing="normal" indent="7">
<t>AXoT: AXFR-over-TLS</t> <dt>DoT:</dt>
<t>IXoT: IXFR over-TLS</t> <dd>DNS over TLS, as specified in <xref target="RFC7858"></xref></dd>
<dt>XFR over TCP:</dt>
<dd>Used to mean both IXFR over TCP <xref target="RFC1995"></xref>
and AXFR over TCP <xref target="RFC5936"></xref></dd>
<dt>XoT:</dt>
<dd>XFR-over-TLS mechanisms, as specified in this document, which apply
to both AXFR over TLS and IXFR over TLS (XoT is pronounced 'zot' since
X here
stands for 'zone transfer')</dd>
<dt>AXoT:</dt>
<dd>AXFR over TLS</dd>
<dt>IXoT:</dt>
<dd>IXFR over TLS</dd>
</dl>
</section> </section>
<section anchor="threat-model"><name>Threat Model</name> <section anchor="threat-model">
<t>The threat model considered here is one where the current contents and size o <name>Threat Model</name>
f the zone are considered <t>The threat model considered here is one where the current contents and size
sensitive and should be protected during transfer.</t> of the zone are
<t>The threat model does not, however, consider the existence of a zone, the act considered sensitive and should be protected during transfer.</t>
of <t>The threat model does not, however, consider the existence of a zone, the a
zone transfer between two entities, nor the identities of the nameservers ct of
hosting a zone (including both those acting as hidden primaries/secondaries zone transfer between two entities, nor the identities of the name servers
or directly serving the zone) as sensitive information. The proposed mechanism hosting a zone (including both those acting as hidden primaries/secondaries
does not attempt to obscure such information. The reasons for this include:</t> 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 of this information can be obtained by various methods, including activ <ul>
e scanning of the DNS</li> <li>much of this information can be obtained by various methods,
<li>an attacker who can monitor network traffic can relatively easily infer rela including active scanning of the DNS, and</li>
tions between <li>an attacker who can monitor network traffic can rather
nameservers simply from traffic patterns, even when some or all of the traffic i easily infer relations between name servers simply from traffic
s encrypted patterns, even when some or all of the traffic is encrypted
(in terms of current deployments)</li> (in terms of current deployments).</li>
</ul> </ul>
<t>The model does not consider attacks on the mechanisms that trigger a zone tra <t>The model does not consider attacks on the mechanisms that trigger a zone t
nsfer, e.g., NOTIFY messages.</t> ransfer, e.g.,
<t>It is noted that simply using XoT will indicate a desire by the zone owner th NOTIFY messages.</t>
at the contents of the zone <t>It is noted that simply using XoT will indicate a desire by the zone owner
remain confidential and so could be subject to blocking (e.g., via blocking of p that the
ort 853) if an attacker had contents of the zone remain confidential and so could be subject to blocking (
such capabilities. However this threat is likely true of any such mechanism that e.g., via
attempts to encrypt data blocking of port 853) if an attacker had
passed between nameservers, e.g., IPsec.</t> such capabilities. However, this threat is likely true of any such mechanism t
hat attempts to
encrypt data passed between name servers, e.g., IPsec.</t>
</section> </section>
<section anchor="design-considerations-for-xot"><name>Design Considerations for <section anchor="design-considerations-for-xot">
XoT</name> <name>Design Considerations for XoT</name>
<t>The following principles were considered in the design for XoT:</t> <t>The following principles were considered in the design for XoT:</t>
<dl newline="false" spacing="normal">
<ul> <dt>Confidentiality:</dt>
<li><t>Confidentiality. Clearly using an encrypted transport for zone transfers <dd>Clearly using an encrypted transport for zone transfers will
will defeat zone content leakage that can occur via passive surveillance.</dd>
defeat zone content leakage that can occur via passive surveillance.</t> <dt>Authentication:</dt>
</li> <dd>Use of single or mutual TLS (mTLS) authentication (in combination
<li><t>Authentication. Use of single or mutual TLS (mTLS) authentication (in com with ACLs) can complement and potentially be an
bination alternative to TSIG.</dd>
with access control lists (ACLs)) can complement and potentially be an alternati <dt>Performance:</dt>
ve to TSIG.</t> <dd>
</li> <ul>
<li><t>Performance.</t> <li>Existing AXFR and IXFR mechanisms have the burden of backwards
compatibility with older implementations based on the original specificat
<ul> ions
<li>Existing AXFR and IXFR mechanisms have the burden of backwards in <xref target="RFC1034"></xref> and <xref target="RFC1035"></xref>. For
compatibility with older implementations based on the original specifications example,
in <xref target="RFC1034"></xref> and <xref target="RFC1035"></xref>. For exampl some older AXFR servers don't
e, some older AXFR servers don’t support using a TCP connection for multiple AXFR sessions or XFRs of diff
support using a TCP connection for multiple AXFR sessions or XFRs of different erent
zones because they have not been updated to follow the guidance in <xref target= zones because they have not been updated to follow the guidance in <xref
"RFC5936"></xref>. target="RFC5936"></xref>.
Any implementation of XoT would obviously be required to Any implementation of XoT would obviously be required to
implement optimized and interoperable transfers as described in <xref target="RF implement optimized and interoperable transfers, as described in <xref
C5936"></xref>, target="RFC5936"></xref>,
e.g., transfer of multiple zones over one connection.</li> e.g., transfer of multiple zones over one connection.</li>
<li>Current usage of TCP for IXFR is sub-optimal in some cases i.e. <li>Current usage of TCP for IXFR is suboptimal in some cases, i.e.,
connections are frequently closed after a single IXFR.</li> connections are frequently closed after a single IXFR.</li>
</ul></li> </ul>
</ul> </dd>
</dl>
</section> </section>
<section anchor="connection-and-data-flows-in-existing-xfr-mechanisms"><name>Con <section anchor="connection-and-data-flows-in-existing-xfr-mechanisms">
nection and Data Flows in Existing XFR Mechanisms</name> <name>Connection and Data Flows in Existing XFR Mechanisms</name>
<t>The original specification for zone transfers in <xref target="RFC1034"></xre <t>The original specification for zone transfers in <xref target="RFC1034"></x
f> and <xref target="RFC1035"></xref> was ref> and <xref
based on a polling mechanism: a secondary performed a periodic query for the SOA target="RFC1035"></xref> was
(start of zone authority) record (based based on a polling mechanism: a secondary performed a periodic query for the S
on the refresh timer) to determine if an AXFR was required.</t> OA (start of
<t><xref target="RFC1995"></xref> and <xref target="RFC1996"></xref> introduced zone authority) record (based
the concepts of IXFR and NOTIFY on the refresh timer) to determine if an AXFR was required.</t>
respectively, to provide for prompt propagation of zone updates. This has <t><xref target="RFC1995"></xref> and <xref target="RFC1996"></xref> introduce
largely replaced AXFR where possible, particularly for dynamically updated d the concepts
zones.</t> of IXFR and NOTIFY,
<t><xref target="RFC5936"></xref> subsequently redefined the specification of AX respectively, to provide for prompt propagation of zone updates. This has
FR to improve largely replaced AXFR where possible, particularly for dynamically updated
performance and interoperability.</t> zones.</t>
<t>In this document we use the term &quot;XFR mechanism&quot; to describe the en <t><xref target="RFC5936"></xref> subsequently redefined the specification of
tire set of AXFR to improve
message exchanges between a secondary and a primary that concludes in a performance and interoperability.</t>
successful AXFR or IXFR request/response. This set may or may not include</t> <t>In this document, the term 'XFR mechanism' is used to describe the entire s
et of
<ul> message exchanges between a secondary and a primary that concludes with a
<li>NOTIFY messages</li> successful AXFR or IXFR request/response. This set may or may not include:</t>
<li>SOA queries</li> <ul>
<li>Fallback from IXFR to AXFR</li> <li>NOTIFY messages</li>
<li>Fallback from IXFR-over-UDP to IXFR-over-TCP</li> <li>SOA queries</li>
</ul> <li>Fallback from IXFR to AXFR</li>
<t>The term is used to encompass the range of permutations that are possible and <li>Fallback from IXFR over UDP to IXFR over TCP</li>
is useful to distinguish the 'XFR mechanism' from a single XFR </ul>
request/response exchange.</t> <t>The term is used to encompass the range of permutations that are possible a
nd
<section anchor="axfr-mechanism"><name>AXFR Mechanism</name> is useful to distinguish the 'XFR mechanism' from a single XFR
<t>The figure below provides an outline of an AXFR mechanism including NOTIFYs.< request/response exchange.</t>
/t>
<artwork> Secondary Primary <section anchor="axfr-mechanism">
<name>AXFR Mechanism</name>
<t>The figure below provides an outline of an AXFR mechanism including NOTIFYs
.</t>
<figure anchor="fig1">
<name>AXFR Mechanism</name>
<artwork name="" type="" alt=""><![CDATA[
Secondary Primary
| NOTIFY | | NOTIFY |
| &lt;-------------------------------- | UDP | <-------------------------------- | UDP
| --------------------------------&gt; | | --------------------------------> |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------&gt; | UDP (or part of | --------------------------------> | UDP (or part of
| &lt;-------------------------------- | a TCP session) | <-------------------------------- | a TCP session)
| SOA Response | | SOA Response |
| | | |
| | | |
| | | |
| AXFR Request | --- | AXFR Request | ---
| --------------------------------&gt; | | | --------------------------------> | |
| &lt;-------------------------------- | | | <-------------------------------- | |
| AXFR Response 1 | | | AXFR Response 1 | |
| (Zone data) | | | (Zone data) | |
| | | | | |
| &lt;-------------------------------- | | TCP | <-------------------------------- | | TCP
| AXFR Response 2 | | Session | AXFR Response 2 | | Session
| (Zone data) | | | (Zone data) | |
| | | | | |
| &lt;-------------------------------- | | | <-------------------------------- | |
| AXFR Response 3 | | | AXFR Response 3 | |
| (Zone data) | --- | (Zone data) | ---
| | | |
]]></artwork>
Figure 1. AXFR Mechanism </figure>
</artwork>
<ol> <ol>
<li><t>An AXFR is often (but not always) preceded by a NOTIFY (over UDP) from th <li>An AXFR is often (but not always) preceded by a NOTIFY (over UDP) from the
e primary to the secondary. A secondary may also initiate an AXFR based on a
primary to the secondary. A secondary may also initiate an AXFR based on a refresh timer or scheduled/triggered zone maintenance.</li>
refresh timer or scheduled/triggered zone maintenance.</t> <li>The secondary will normally (but not always) make an SOA query to the prim
</li> ary
<li><t>The secondary will normally (but not always) make a SOA query to the prim to obtain the serial number of the zone held by the primary.</li>
ary <li>If the primary serial is higher than the secondary's serial (using Serial
to obtain the serial number of the zone held by the primary.</t> Number Arithmetic <xref target="RFC1982"></xref>), the secondary makes an AXFR
</li> request
<li><t>If the primary serial is higher than the secondary's serial (using Serial (over TCP)
Number Arithmetic <xref target="RFC1982"></xref>), the secondary makes an AXFR r to the primary, after which the AXFR data flows in one or more AXFR responses
equest (over TCP) on
to the primary after which the AXFR data flows in one or more AXFR responses on the TCP connection. <xref target="RFC5936"></xref> defines this specific step
the TCP connection. <xref target="RFC5936"></xref> defines this specific step as as an 'AXFR
an 'AXFR session' session',
i.e. as an AXFR query message and the sequence of AXFR response messages i.e., as an AXFR query message and the sequence of AXFR response messages
returned for it.</t> returned for it.</li>
</li>
</ol> </ol>
<t><xref target="RFC5936"></xref> re-specified AXFR providing additional guidanc <t><xref target="RFC5936"></xref> re-specified AXFR, providing additional guidan
e beyond that provided ce beyond that
in <xref target="RFC1034"></xref> and <xref target="RFC1035"></xref> and importa provided in <xref target="RFC1034"></xref> and <xref target="RFC1035"></xref> an
ntly specified that AXFR must use TCP d importantly
as the transport protocol.</t> 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>Additionally, Sections <xref target="RFC5936" section="4.1" sectionFormat="ba
provide improved re"/>, <xref target="RFC5936" section="4.1.1" sectionFormat="bare"/>, and <xref
guidance for AXFR clients and servers with regard to re-use of TCP connections target="RFC5936" section="4.1.2" sectionFormat="bare"/> of <xref target="RFC5936
for multiple AXFRs and AXFRs of different zones. However <xref target="RFC5936"> "></xref> provide improved
</xref> was guidance for AXFR clients and servers with regard to reuse of TCP connections
for multiple AXFRs and AXFRs of different zones. However, <xref target="RFC5936"
></xref> was
constrained by having to be backwards compatible with some very early basic 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 implementations of AXFR. For example, it outlines that the SOA query can also
happen on this connection. However, this can cause interoperability problems happen on this connection. However, this can cause interoperability problems
with older implementations that support only the trivial case of one AXFR per with older implementations that support only the trivial case of one AXFR per
connection.</t> connection.</t>
</section> </section>
<section anchor="ixfr-mechanism"><name>IXFR Mechanism</name> <section anchor="ixfr-mechanism">
<t>The figure below provides an outline of the IXFR mechanism including NOTIFYs. <name>IXFR Mechanism</name>
</t> <t>The figure below provides an outline of the IXFR mechanism including NOTIFY
s.</t>
<artwork> Secondary Primary <figure anchor="fig2">
<name>IXFR Mechanism</name>
<artwork name="" type="" alt=""><![CDATA[
Secondary Primary
| NOTIFY | | NOTIFY |
| &lt;-------------------------------- | UDP | <-------------------------------- | UDP
| --------------------------------&gt; | | --------------------------------> |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------&gt; | UDP or TCP | --------------------------------> | UDP or TCP
| &lt;-------------------------------- | | <-------------------------------- |
| SOA Response | | SOA Response |
| | | |
| | | |
| | | |
| IXFR Request | | IXFR Request |
| --------------------------------&gt; | UDP or TCP | --------------------------------> | UDP or TCP
| &lt;-------------------------------- | | <-------------------------------- |
| IXFR Response | | IXFR Response |
| (Zone data) | | (Zone data) |
| | | |
| | --- | | ---
| IXFR Request | | | IXFR Request | |
| --------------------------------&gt; | | Retry over | --------------------------------> | | Retry over
| &lt;-------------------------------- | | TCP if | <-------------------------------- | | TCP if
| IXFR Response | | required | IXFR Response | | required
| (Zone data) | --- | (Zone data) | ---
]]></artwork>
Figure 2. IXFR Mechanism </figure>
</artwork>
<ol> <ol>
<li><t>An IXFR is normally (but not always) preceded by a NOTIFY (over UDP) from <li>An IXFR is normally (but not always) preceded by a NOTIFY (over UDP) from
the the
primary to the secondary. A secondary may also initiate an IXFR based on a primary to the secondary. A secondary may also initiate an IXFR based on a
refresh timer or scheduled/triggered zone maintenance.</t> refresh timer or scheduled/triggered zone maintenance.</li>
</li> <li>The secondary will normally (but not always) make an SOA query to the prim
<li><t>The secondary will normally (but not always) make a SOA query to the prim ary
ary to obtain the serial number of the zone held by the primary.</li>
to obtain the serial number of the zone held by the primary.</t> <li>If the primary serial is higher than the secondary's serial (using Serial
</li> Number Arithmetic <xref target="RFC1982"></xref>), the secondary makes an IXFR
<li><t>If the primary serial is higher than the secondaries serial (using Serial request to
Number Arithmetic <xref target="RFC1982"></xref>), the secondary makes an IXFR r the primary, after which the primary sends an IXFR response.</li>
equest to the
primary after which the primary sends an IXFR response.</t>
</li>
</ol> </ol>
<t><xref target="RFC1995"></xref> specifies that Incremental Transfer may use UD P if the entire IXFR <t><xref target="RFC1995"></xref> specifies that IXFR may use UDP if the entire IXFR
response can be contained in a single DNS packet, otherwise, TCP is used. In response can be contained in a single DNS packet, otherwise, TCP is used. In
fact it says:</t> fact, it says:</t>
<blockquote>Thus, a client should first make an IXFR query using UDP.</blockquot
<artwork>&quot;Thus, a client should first make an IXFR query using UDP.&quot; e>
</artwork> <t>So there may be a fourth step above where the client falls back to IXFR over
<t>So there may be a fourth step above where the client falls back to IXFR-over- TCP.
TCP. There may also be an additional step where the secondary must fall back to AXFR
There may also be a additional step where the secondary must fall back to AXFR
because, e.g., the primary does not support IXFR.</t> because, e.g., the primary does not support IXFR.</t>
<t>However it is noted that most widely used open source authoritative nameserve <t>However, it is noted that most of the widely used open-source implementations
r of authoritative name servers
implementations (including both <xref target="BIND"></xref> and <xref target="NS (including both <xref target="BIND"></xref> and <xref target="NSD"></xref>) do I
D"></xref>) do IXFR using TCP by default XFR using TCP by default
in their latest releases. For BIND, TCP connections are sometimes used for SOA in their latest releases. For BIND, TCP connections are sometimes used for SOA
queries but in general they are not used persistently and close after an IXFR queries, but, in general, they are not used persistently and are closed after an IXFR
is completed.</t> is completed.</t>
</section> </section>
<section anchor="data-leakage-of-notify-and-soa-message-exchanges"><name>Data Le <section anchor="data-leakage-of-notify-and-soa-message-exchanges">
akage of NOTIFY and SOA Message Exchanges</name> <name>Data Leakage of NOTIFY and SOA Message Exchanges</name>
<t>This section presents a rationale for considering encrypting the other <t>This section presents a rationale for considering the encryption of the oth
messages in the XFR mechanism.</t> er
<t>Since the SOA of the published zone can be trivially discovered by simply messages in the XFR mechanism.</t>
querying the publicly available authoritative servers, leakage of this resource <t>Since the SOA of the published zone can be trivially discovered by simply
record (RR) via such a querying the publicly available authoritative servers, leakage of this resourc
direct query is not discussed in the following sections.</t> e record (RR)
via such a
direct query is not discussed in the following sections.</t>
<section anchor="notify"><name>NOTIFY</name> <section anchor="notify">
<t>Unencrypted NOTIFY messages identify configured secondaries on the primary.</ <name>NOTIFY</name>
t> <t>Unencrypted NOTIFY messages identify configured secondaries on the primary.
<t><xref target="RFC1996"></xref> also states:</t> </t>
<t><xref target="RFC1996"></xref> also states:</t>
<blockquote>If ANCOUNT&gt;0, then the answer section represents an
unsecure hint at the new RRset for this &lt;QNAME,QCLASS,QTYPE&gt;.</blockquot
e>
<artwork>&quot;If ANCOUNT&gt;0, then the answer section represents an <t>But since the only query type (QTYPE) for NOTIFY defined at the time of thi
unsecure hint at the new RRset for this (QNAME,QCLASS,QTYPE). s writing
</artwork> is SOA, this does not pose a
<t>But since the only QTYPE for NOTIFY defined at the time of this writing potential leak.</t>
is SOA, this does not pose a
potential leak.</t>
</section> </section>
<section anchor="soa"><name>SOA</name> <section anchor="soa">
<t>For hidden XFR servers (either primaries or secondaries), an SOA response <name>SOA</name>
directly from that server only additionally leaks the degree of SOA serial <t>For hidden XFR servers (either primaries or secondaries), an SOA response
number lag of any downstream secondary of that server.</t> 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>
</section> </section>
<section anchor="updates-to-existing-specifications"><name>Updates to existing s <section anchor="updates-to-existing-specifications">
pecifications</name> <name>Updates to Existing Specifications</name>
<t>For convenience, the term 'XFR-over-TCP' is used in this document to mean bot <t>For convenience, the term 'XFR over TCP' is used in this document to mean b
h oth
IXFR-over-TCP and AXFR-over-TCP and therefore statements that use that term upda IXFR over TCP and AXFR over TCP; therefore, statements that use that term upda
te te
both <xref target="RFC1995"></xref> and <xref target="RFC5936"></xref>, and impl both <xref target="RFC1995"></xref> and <xref target="RFC5936"></xref> and imp
icitly also apply to XoT. licitly also
Differences in behavior specific to XoT are discussed in apply to XoT. Differences in behavior specific to XoT are discussed in
<xref target="xot-specification"></xref>.</t> <xref target="xot-specification"></xref>.</t>
<t>Both <xref target="RFC1995"></xref> and <xref target="RFC5936"></xref> were p <t>Both <xref target="RFC1995"></xref> and <xref target="RFC5936"></xref> were
ublished sometime before TCP was published
considered a first class transport for DNS. <xref target="RFC1995"></xref>, in f sometime before TCP became a widely supported transport for DNS. <xref
act, says nothing target="RFC1995"></xref>, in fact, says nothing
with respect to optimizing IXFRs over TCP or re-using already open TCP with respect to optimizing IXFRs over TCP or reusing already open TCP
connections to perform IXFRs or other queries. Therefore, there arguably is an connections to perform IXFRs or other queries. Therefore, there arguably is an
implicit assumption that a TCP connection is used for implicit assumption that a TCP connection is used for
one and only one IXFR request. Indeed, many major open source implementations one and only one IXFR request. Indeed, many major open-source implementations
take this approach (at the time of this writing). And whilst <xref target="RFC59 take this approach (at the time of this writing). And whilst <xref target="RFC
36"></xref> gives guidance on 5936"></xref>
connection re-use for AXFR, it pre-dates more recent specifications describing gives guidance on
persistent TCP connections (e.g., <xref target="RFC7766"></xref>, <xref target=" connection reuse for AXFR, it predates more recent specifications describing
RFC7828"></xref>), and AXFR implementations again persistent TCP connections (e.g., <xref target="RFC7766"></xref>, <xref
often make less than optimal use of open connections.</t> target="RFC7828"></xref>), and AXFR implementations again
<t>Given this, new implementations of XoT will clearly benefit from specific gui often make less-than-optimal use of open connections.</t>
dance on <t>Given this, new implementations of XoT will clearly benefit from specific g
TCP/TLS connection usage for XFR, because this will:</t> uidance on
TCP/TLS connection usage for XFR, because this will:</t>
<ul> <ul>
<li>result in more consistent XoT implementations with better interoperability</ <li>result in more consistent XoT implementations with better interoperability
li> and</li>
<li>remove any need for XoT implementations to support legacy behavior for XoT c <li>remove any need for XoT implementations to support legacy behavior for XoT
onnections that connections
XFR-over-TCP implementations have historically often supported</li> that XFR-over-TCP implementations have historically often supported.</li>
</ul> </ul>
<t>Therefore this document updates both the previous specifications for <t>Therefore, this document updates both the previous specifications for
XFR-over-TCP ([RFC1995] and [RFC5936]) to clarify that</t> XFR over TCP (<xref target="RFC1995" format="default"/> and <xref target="RFC593
6" format="default"/>) to clarify that:</t>
<ul> <ul>
<li><t>Implementations MUST use <xref target="RFC7766"></xref> (DNS Transport ov <li>Implementations <bcp14>MUST</bcp14> use <xref target="RFC7766"></xref> ("D
er TCP - Implementation NS Transport
Requirements) to optimize the use of TCP connections.</t> over TCP - Implementation Requirements") to optimize the use of TCP connection
</li> s.</li>
<li><t>Whilst RFC7766 states that 'DNS clients SHOULD pipeline their queries’ on <li>Whilst <xref target="RFC7766" format="default"/> states that "DNS clients
TCP <bcp14>SHOULD</bcp14> pipeline their queries"
connections, it did not distinguish between XFRs and other queries for this on TCP connections, it did not distinguish between XFRs and other queries for
behavior. It is now recognized that XFRs are not as latency sensitive as this
other queries, and can be significantly more complex for clients to handle, behavior. It is now recognized that XFRs are not as latency sensitive as
both because of the large amount of state that must be kept and because there other queries and can be significantly more complex for clients to handle,
may be multiple messages in the responses. For these reasons, it is clarified both because of the large amount of state that must be kept and because there
here that a valid reason for not pipelining queries is when they are all XFR may be multiple messages in the responses. For these reasons, it is clarified
queries i.e. clients sending multiple XFRs MAY choose not to pipeline those here that a valid reason for not pipelining queries is when they are all XFR
queries. Clients that do not pipeline XFR queries, therefore, have no queries, i.e., clients sending multiple XFRs <bcp14>MAY</bcp14> choose not to
additional requirements to handle out-of-order or intermingled responses (as pipeline those
described later), since they will never receive them.</t> queries. Clients that do not pipeline XFR queries therefore have no
</li> additional requirements to handle out-of-order or intermingled responses (as
<li><t>Implementations SHOULD use <xref target="RFC7828"></xref> (The edns-tcp-k described later), since they will never receive them.</li>
eepalive EDNS0 Option) <li>Implementations <bcp14>SHOULD</bcp14> use the
to manage persistent connections (which is more flexible than using just fixed t edns-tcp-keepalive EDNS(0) option <xref target="RFC7828"></xref> to manage
imeouts).</t> persistent connections. This is
</li> more flexible than the alternative of simply using fixed timeouts.</li>
</ul> </ul>
<t>The following sections include detailed clarifications on the updates to XFR <t>The following sections include detailed clarifications on the updates to XFR
behavior implied in <xref target="RFC7766"></xref> and how the use of <xref targ et="RFC7828"></xref> applies behavior implied in <xref target="RFC7766"></xref> and how the use of <xref targ et="RFC7828"></xref> applies
specifically to XFR exchanges. They also discuss how IXFR and AXFR can reuse specifically to XFR exchanges. They also discuss how IXFR and AXFR can reuse
the same TCP connection.</t> the same TCP connection.</t>
<t>For completeness, we also mention here the recent specification of extended D <t>For completeness, the recent specification of extended
NS DNS error (EDE) codes <xref target="RFC8914"></xref> is also mentioned here. For
error (EDE) codes <xref target="RFC8914"></xref>. For zone transfers, when retur zone transfers, when returning REFUSED to a
ning REFUSED to a
zone transfer request from an 'unauthorized' client (e.g., where the client is n ot zone transfer request from an 'unauthorized' client (e.g., where the client is n ot
listed in an ACL for zone transfers or does not sign the request with a 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) can also be sent.</ valid TSIG key), the extended DNS error code 18 - Prohibited can also be sent.</
t> t>
<section anchor="update-to-rfc1995-for-ixfr-over-tcp"><name>Update to RFC1995 fo
r IXFR-over-TCP</name>
<t>For clarity - an IXFR-over-TCP server compliant with this specification MUST
be
able to handle multiple concurrent IXoT requests on a single TCP connection
(for the same and different zones) and SHOULD send the responses as soon as
they are available, which might be out-of-order compared to the requests.</t>
</section>
<section anchor="update-to-rfc5936-for-axfr-over-tcp"><name>Update to RFC5936 fo
r AXFR-over-TCP</name>
<t>For clarity - an AXFR-over-TCP server compliant with this specification MUST
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 be intermingled and AXFR-over-TCP clients compliant with this specification
which pipeline AXFR requests MUST be able to handle this.</t>
</section>
<section anchor="updates-to-rfc1995-and-rfc5936-for-xfr-over-tcp"><name>Updates
to RFC1995 and RFC5936 for XFR-over-TCP</name>
<section anchor="connection-reuse"><name>Connection reuse</name>
<t>As specified, XFR-over-TCP clients SHOULD re-use any existing open TCP connec
tion 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 be minimized (also see <xref target="update-to-rfc7
766"></xref>).</t>
<t>Valid reasons for not re-using existing connections might include:</t>
<ul>
<li>as already noted in <xref target="RFC7766"></xref>, separate connections for
different zones might be preferred for operational reasons. In this case, the n
umber of concurrent connections for zone transfers SHOULD be limited to the tota
l number of zones transferred between the client and server.</li>
<li>reaching a configured limit for the number of outstanding queries or XFR req
uests allowed on a single TCP connection</li>
<li>the message ID pool has already been exhausted on an open connection</li>
<li>a large number of timeouts or slow responses have occurred on an open
connection</li>
<li>an edns-tcp-keepalive EDNS0 option with a timeout of 0 has been received fro
m the
server and the client is in the process of closing the connection (see <xref tar
get="the-edns-tcp-keepalive-edns0-option"></xref>)</li>
</ul>
<t>If no TCP connections are currently open, XFR clients MAY send SOA queries ov
er
UDP or a new TCP connection.</t>
</section>
<section anchor="axfrs-and-ixfrs-on-the-same-connection"><name>AXFRs and IXFRs o
n the same connection</name>
<t>Neither <xref target="RFC1995"></xref> nor <xref target="RFC5936"></xref> exp
licitly discuss the use of a single TCP
connection for both IXFR and AXFR requests. <xref target="RFC5936"></xref> does
make the general statement:</t>
<artwork>&quot;Non-AXFR session traffic can also use an open TCP connection.&quo
t;
</artwork>
<t>We clarify here that implementations capable of both AXFR and IXFR and compli
ant with this specification SHOULD</t>
<ul> <section anchor="update-to-rfc1995-for-ixfr-over-tcp">
<li>use the same TCP connection for both AXFR and IXFR requests to the same prim <name>Update to RFC 1995 for IXFR over TCP</name>
ary</li> <t>For clarity, an IXFR-over-TCP server compliant with this specification
<li>pipeline such requests (if they pipeline XFR requests in general) and MAY in <bcp14>MUST</bcp14> be
termingle them</li> able to handle multiple concurrent IXoT requests on a single TCP connection
<li>send the response(s) for each request as soon as they are available i.e. res (for the same and different zones) and <bcp14>SHOULD</bcp14> send the response
ponses MAY be sent intermingled</li> s as soon as
</ul> they are available, which might be out of order compared to the requests.</t>
<t>For some current implementations adding all the above functionality would int
roduce significant
code complexity. In such a case, there will need to be an assessment of the trad
e-off between that
and the performance benefits of the above for XFR.</t>
</section> </section>
<section anchor="xfr-limits"><name>XFR limits</name> <section anchor="update-to-rfc5936-for-axfr-over-tcp">
<t>The server MAY limit the number of concurrent IXFRs, AXFRs or total XFR <name>Update to RFC 5936 for AXFR over TCP</name>
transfers in progress, or from a given secondary, to protect server resources. <t>For clarity, an AXFR-over-TCP server compliant with this specification
Servers SHOULD return SERVFAIL if this limit is hit, since it is a <bcp14>MUST</bcp14> be
transient error and a retry at a later time might succeed (there is no previous able to handle multiple concurrent AXoT sessions on a single TCP connection
specification for this behavior).</t> (for the same and different zones). The response streams for concurrent AXFRs
<bcp14>MAY</bcp14> be intermingled, and AXFR-over-TCP clients compliant with t
his
specification, which pipeline AXFR requests, <bcp14>MUST</bcp14> be able to ha
ndle this.</t>
</section> </section>
<section anchor="the-edns-tcp-keepalive-edns0-option"><name>The edns-tcp-keepali <section anchor="updates-to-rfc1995-and-rfc5936-for-xfr-over-tcp">
ve EDNS0 Option</name> <name>Updates to RFCs 1995 and 5936 for XFR over TCP</name>
<t>XFR clients that send the edns-tcp-keepalive EDNS0 option on every XFR reques <section anchor="connection-reuse">
t provide the <name>Connection Reuse</name>
server with maximum opportunity to update the edns-tcp-keepalive timeout. The XF <t>As specified, XFR-over-TCP clients <bcp14>SHOULD</bcp14> reuse any existi
R server ng open TCP
may use the frequency of recent XFRs to calculate an average update rate as connection when
input to the decision of what edns-tcp-keepalive timeout to use. If the server starting any new XFR request to the same primary, and for issuing SOA querie
does not support edns-tcp-keepalive, the client MAY keep the connection open for s,
a instead of opening a new connection. The number of TCP connections between a
few seconds (<xref target="RFC7766"></xref> recommends that servers use timeouts secondary and primary <bcp14>SHOULD</bcp14> be minimized (also see <xref
of at least a few target="update-to-rfc7766"></xref>).</t>
seconds).</t> <t>Valid reasons for not reusing existing connections might include:</t>
<t>Whilst the specification for EDNS0 <xref target="RFC6891"></xref> does not <ul>
specifically mention AXFRs, it does say</t> <li>As already noted in <xref target="RFC7766"></xref>, separate connectio
ns for
different zones might be preferred for operational reasons. In this case,
the number of
concurrent connections for zone transfers <bcp14>SHOULD</bcp14> be limited
to the total
number of zones transferred between the client and server.</li>
<li>A configured limit for the number of outstanding queries or XFR reques
ts
allowed on a single TCP connection has been reached.</li>
<li>The message ID pool has already been exhausted on an open connection.<
/li>
<li>A large number of timeouts or slow responses have occurred on an open
connection.</li>
<li>An edns-tcp-keepalive EDNS(0) option with a timeout of 0 has been rece
ived from the
server, and the client is in the process of closing the connection (see <x
ref
target="the-edns-tcp-keepalive-edns0-option"></xref>).</li>
</ul>
<t>If no TCP connections are currently open, XFR clients <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 and IXFRs on the Same Connection</name>
<t>Neither <xref target="RFC1995"></xref> nor <xref target="RFC5936"></xref>
explicitly
discuss the use of a single TCP
connection for both IXFR and AXFR requests. <xref target="RFC5936"></xref> d
oes make the
general statement:</t>
<blockquote>Non-AXFR session traffic can also use an open connection.</block
quote>
<t>In this document, the above is clarified to indicate that implementations
capable of both AXFR and IXFR and
compliant with this specification <bcp14>SHOULD</bcp14>:</t>
<ul>
<li>use the same TCP connection for both AXFR and IXFR requests to the sam
e
primary,</li>
<li>pipeline such requests (if they pipeline XFR requests in general) and
<bcp14>MAY</bcp14> intermingle them, and</li>
<li>send the response(s) for each request as soon as they are available, i
.e.,
responses <bcp14>MAY</bcp14> be sent intermingled.</li>
</ul>
<t>For some current implementations, adding all the above functionality woul
d introduce
significant code complexity. In such a case, there will need to be an assess
ment 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 server <bcp14>MAY</bcp14> limit the number of concurrent IXFRs, AXFRs
, or total XFR
transfers in progress (or from a given secondary) to protect server resource
s.
Servers <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 previ
ous
specification for this behavior).</t>
</section>
<section anchor="the-edns-tcp-keepalive-edns0-option">
<name>The edns-tcp-keepalive EDNS(0) Option</name>
<t>XFR clients that send the edns-tcp-keepalive 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 r
ate as
input to the decision of what edns-tcp-keepalive timeout to use. If the serv
er
does not support edns-tcp-keepalive, the client <bcp14>MAY</bcp14> keep the
connection
open for a few seconds (<xref target="RFC7766"></xref> recommends that serve
rs use
timeouts of at least a few seconds).</t>
<t>Whilst the specification for EDNS(0) <xref target="RFC6891"></xref> doe
s not
specifically mention AXFRs, it does say:</t>
<blockquote>If an OPT record is present in a received request, compliant
responders <bcp14>MUST</bcp14> include an OPT record in their respective
responses.</blockquote>
<t>In this document, the above is clarified to indicate that if an OPT recor
d is present in a received AXFR request,
compliant responders <bcp14>MUST</bcp14> include an OPT record in each of th
e 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 b
y
sending an edns-tcp-keepalive EDNS(0) option with a timeout of 0 on any AXFR
response. This does not signal that the AXFR is aborted, just that the serve
r
wishes to close the connection as soon as possible.</t>
</section>
<artwork>&quot;If an OPT record is present in a received request, compliant <section anchor="backwards-compatibility">
responders MUST include an OPT record in their respective <name>Backwards Compatibility</name>
responses.&quot; <t>Certain legacy behaviors were noted in <xref target="RFC5936"></xref>, wi
</artwork> th provisions
<t>We clarify here that if an OPT record is present in a received AXFR request, that implementations may want to offer options to fallback to legacy behavio
compliant responders MUST include an OPT record in each of the subsequent AXFR r when
responses. Note that this requirement, combined with the use of interoperating with servers known to not support <xref target="RFC5936"></xr
edns-tcp-keepalive, enables AXFR servers to signal the desire to close a ef>. For
connection (when existing transactions have competed) due to low resources by purposes of interoperability, IXFR and AXFR implementations may want to cont
sending an edns-tcp-keepalive EDNS0 option with a timeout of 0 on any AXFR inue offering
response. This does not signal that the AXFR is aborted, just that the server such configuration options, as well as supporting some behaviors that were
wishes to close the connection as soon as possible.</t> underspecified prior to this work (e.g., performing IXFR and AXFRs on separa
te
connections). However, XoT connections should have no need to do so.</t>
</section>
</section> </section>
<section anchor="backwards-compatibility"><name>Backwards compatibility</name> <section anchor="update-to-rfc7766">
<t>Certain legacy behaviors were noted in <xref target="RFC5936"></xref>, with p <name>Update to RFC 7766</name>
rovisions that <t><xref target="RFC7766"></xref> made general implementation
implementations may want to offer options to fallback to legacy behavior when recommendations with regard to TCP/TLS connection handling:</t>
interoperating with servers known to not support <xref target="RFC5936"></xref>. <blockquote>To mitigate the risk of unintentional server overload, DNS
For purposes of clients <bcp14>MUST</bcp14> take care to minimize the number of concurrent TCP
interoperability, IXFR and AXFR implementations may want to continue offering connections made to any individual server. It is <bcp14>RECOMMENDED</bcp14>
such configuration options, as well as supporting some behaviors that were that for any given client/server interaction there <bcp14>SHOULD</bcp14> be no
underspecified prior to this work (e.g., performing IXFR and AXFRs on separate more than one connection for regular queries, one for zone
connections). However, XoT connections should have no need to do so.</t> transfers, and one for each protocol that is being used on top
</section> of TCP (for example, if the resolver was using TLS). However,
</section> 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).</blockquote>
<section anchor="update-to-rfc7766"><name>Update to RFC7766</name> <t>Whilst this recommends a particular behavior for the clients using TCP, it
<t><xref target="RFC7766"></xref> made general implementation does not relax the requirement for servers to handle 'mixed' traffic (regular
recommendations with regard to TCP/TLS connection handling:</t> 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 rega
rd to
using separate connections for different purposes.</t>
<t>This specification updates the above general guidance in <xref target="RFC7
766"></xref>
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, it is <bcp14>RECOMMENDED</bcp14> that for
each protocol used on top of TCP in any given client/server interaction there
<bcp14>SHOULD</bcp14> be no more than one connection for regular queries and o
ne for zone
transfers.</t>
<t>As an illustration, it could be imagined that in the future such an
interaction could hypothetically include one or all of the following:</t>
<artwork>&quot;To mitigate the risk of unintentional server overload, DNS <ul>
clients MUST take care to minimize the number of concurrent TCP <li>one TCP connection for regular queries</li>
connections made to any individual server. It is RECOMMENDED <li>one TCP connection for zone transfers</li>
that for any given client/server interaction there SHOULD be no <li>one TLS connection for regular queries</li>
more than one connection for regular queries, one for zone <li>one TLS connection for zone transfers</li>
transfers, and one for each protocol that is being used on top <li>one DoH connection for regular queries</li>
of TCP (for example, if the resolver was using TLS). However, <li>one DoH connection for zone transfers</li>
it is noted that certain primary/ secondary configurations with </ul>
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 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 th
e
potential that other transports might want to take the same approach with regard
to
using separate connections for different purposes.</t>
<t>This specification updates the above general guidance in <xref target="RFC776
6"></xref> 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, it is RECOMMENDED that for
each protocol used on top of TCP in any given client/server interaction, there
SHOULD be no more than one connection for regular queries and one for zone
transfers.</t>
<t>As an illustration, it could be imagined that in future such an
interaction could hypothetically include one or all of the following:</t>
<ul> <t><xref target="connection-reuse"></xref> provides specific details of the re
<li>one TCP connection for regular queries</li> asons why
<li>one TCP connection for zone transfers</li> more than one connection for a given transport might be required for zone tran
<li>one TLS connection for regular queries</li> sfers from
<li>one TLS connection for zone transfers</li> a particular client.</t>
<li>one DoH connection for regular queries</li>
<li>one DoH connection for zone transfers</li>
</ul>
<t><xref target="connection-reuse"></xref> has provided specific details of reas
ons where more than
one connection for a given transport might be required for zone transfers from
a particular client.</t>
</section> </section>
</section> </section>
<section anchor="xot-specification"><name>XoT specification</name> <section anchor="xot-specification">
<name>XoT Specification</name>
<section anchor="connection-establishment"><name>Connection establishment</name>
<t>During connection establishment the Application-Layer Protocol Negotiation (A
LPN) token “dot” <xref target="DoT-ALPN"></xref> MUST be selected in the TLS han
dshake.</t>
</section>
<section anchor="tls-versions"><name>TLS versions</name> <section anchor="connection-establishment">
<t>All implementations of this specification MUST use only TLS 1.3 <xref target= <name>Connection Establishment</name>
"RFC8446"></xref> or later.</t> <t>During connection establishment, the Application-Layer Protocol Negotiati
</section> on (ALPN) token
"dot" <xref target="DoT-ALPN"></xref> <bcp14>MUST</bcp14> be selected in the
TLS
handshake.</t>
</section>
<section anchor="port-selection"><name>Port selection</name> <section anchor="tls-versions">
<t>The connection for XoT SHOULD be established using port 853, as specified in <name>TLS Versions</name>
<xref target="RFC7858"></xref>, unless there is mutual agreement between the sec <t>All implementations of this specification <bcp14>MUST</bcp14> use only TL
ondary and primary S 1.3 <xref
to use a port other than port 853 for XoT. There MAY be agreement to use target="RFC8446"></xref> or later.</t>
different ports for AXoT and IXoT, or for different zones.</t> </section>
</section>
<section anchor="high-level-xot-descriptions"><name>High level XoT descriptions< <section anchor="port-selection">
/name> <name>Port Selection</name>
<t>It is useful to note that in XoT, it is the secondary that initiates <t>The connection for XoT <bcp14>SHOULD</bcp14> be established using port 85
the TLS connection to the primary for a XFR request, so that in terms of 3, as
connectivity, the secondary is the TLS client and the primary the TLS server.</t specified in <xref target="RFC7858"></xref>, unless there is mutual agreemen
> t between the
<t>The figure below provides an outline of the AXoT mechanism including NOTIFYs. primary and secondary to use a port other than port 853 for XoT. There <bcp1
</t> 4>MAY</bcp14>
be agreement to use different ports for AXoT and IXoT or for different zones
.</t>
</section>
<artwork> Secondary Primary <section anchor="high-level-xot-descriptions">
<name>High-Level XoT Descriptions</name>
<t>It is useful to note that in XoT it is the secondary that initiates
the TLS connection to the primary for an XFR request so that, in terms of
connectivity, the secondary is the TLS client and the primary is the TLS ser
ver.</t>
<t>The figure below provides an outline of the AXoT mechanism including NOTI
FYs.</t>
<figure anchor="fig3">
<name>AXoT Mechanism</name>
<artwork name="" type="" alt=""><![CDATA[
Secondary Primary
| NOTIFY | | NOTIFY |
| &lt;-------------------------------- | UDP | <-------------------------------- | UDP
| --------------------------------&gt; | | --------------------------------> |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------&gt; | UDP (or part of | --------------------------------> | UDP (or part of
| &lt;-------------------------------- | a TCP/TLS session) | <-------------------------------- | a TCP/TLS session)
| SOA Response | | SOA Response |
| | | |
| | | |
| | | |
| AXFR Request | --- | AXFR Request | ---
| --------------------------------&gt; | | | --------------------------------> | |
| &lt;-------------------------------- | | | <-------------------------------- | |
| AXFR Response 1 | | | AXFR Response 1 | |
| (Zone data) | | | (Zone data) | |
| | | | | |
| &lt;-------------------------------- | | TLS | <-------------------------------- | | TLS
| AXFR Response 2 | | Session | AXFR Response 2 | | Session
| (Zone data) | | | (Zone data) | |
| | | | | |
| &lt;-------------------------------- | | | <-------------------------------- | |
| AXFR Response 3 | | | AXFR Response 3 | |
| (Zone data) | --- | (Zone data) | ---
| | | |
]]></artwork>
Figure 3. AXoT Mechanism </figure>
</artwork>
<t>The figure below provides an outline of the IXoT mechanism including NOTIFYs. </t> <t>The figure below provides an outline of the IXoT mechanism including NOTIFYs. </t>
<figure anchor="fig4">
<artwork> Secondary Primary <name>IXoT Mechanism</name>
<artwork name="" type="" alt=""><![CDATA[
Secondary Primary
| NOTIFY | | NOTIFY |
| &lt;-------------------------------- | UDP | <-------------------------------- | UDP
| --------------------------------&gt; | | --------------------------------> |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------&gt; | UDP (or part of | --------------------------------> | UDP (or part of
| &lt;-------------------------------- | a TCP/TLS session) | <-------------------------------- | a TCP/TLS session)
| SOA Response | | SOA Response |
| | | |
| | | |
| | | |
| IXFR Request | --- | IXFR Request | ---
| --------------------------------&gt; | | | --------------------------------> | |
| &lt;-------------------------------- | | | <-------------------------------- | |
| IXFR Response | | | IXFR Response | |
| (Zone data) | | | (Zone data) | |
| | | TLS | | | TLS
| | | session | | | session
| IXFR Request | | | IXFR Request | |
| --------------------------------&gt; | | | --------------------------------> | |
| &lt;-------------------------------- | | | <-------------------------------- | |
| IXFR Response | | | IXFR Response | |
| (Zone data) | --- | (Zone data) | ---
]]></artwork>
Figure 4. IXoT Mechanism </figure>
</artwork>
</section> </section>
<section anchor="xot-transfers"><name>XoT transfers</name> <section anchor="xot-transfers">
<t>For a zone transfer between two end points to be considered protected with Xo <name>XoT Transfers</name>
T <t>For a zone transfer between two endpoints to be considered protected with X
all XFR requests and response for that zone MUST be sent over TLS connections oT,
where at a minimum:</t> all XFR requests and responses for that zone <bcp14>MUST</bcp14> be sent over
TLS connections,
<ul> where at a minimum:</t>
<li>the client MUST authenticate the server by use of an authentication domain
name using a Strict Privacy Profile, as described in <xref target="RFC8310"></xr
ef></li>
<li><t>the server MUST validate the client is authorized to request or proxy a z
one transfer by
using one or both of the following methods:</t>
<ul> <ul>
<li>Mutual TLS (mTLS)</li> <li>The client <bcp14>MUST</bcp14> authenticate the server by use of an auth
<li>an IP based ACL (which can be either per-message or per-connection) entication
combined with a valid TSIG/SIG(0) signature on the XFR request</li> domain name using a Strict Privacy profile, as described in <xref
</ul></li> target="RFC8310"></xref>.</li>
</ul> <li><t>The server <bcp14>MUST</bcp14> validate the client is authorized to r
<t>If only one method is selected then mTLS is preferred because it provides str equest or proxy
ong cryptographic a zone transfer by using one or both of the following methods:</t>
protection at both endpoints.</t> <ul>
<t>Authentication mechanisms are discussed in full in <xref target="authenticati <li>mutual TLS (mTLS)</li>
on-mechanisms"></xref> <li>an IP-based ACL (which can be either per message or per connection)
and the rationale for the above requirement in <xref target="xot-authentication" combined with a valid TSIG/SIG(0) signature on the XFR request</li>
></xref>. Transfer </ul>
group policies are discussed in <xref target="policies-for-both-axot-and-ixot">< </li>
/xref>.</t> </ul>
<t>If only one method is selected, then mTLS is preferred because it provides
strong
cryptographic protection at both endpoints.</t>
<t>Authentication mechanisms are discussed in full in <xref
target="authentication-mechanisms"></xref>,
and the rationale for the above requirement is discussed in <xref
target="xot-authentication"></xref>.
Transfer group policies are discussed in <xref
target="policies-for-both-axot-and-ixot"></xref>.</t>
</section> </section>
<section anchor="xot-connections"><name>XoT connections</name> <section anchor="xot-connections">
<t>The details in <xref target="updates-to-existing-specifications"></xref> abou <name>XoT Connections</name>
t, e.g., persistent <t>The details in <xref target="updates-to-existing-specifications"></xref> ab
connections and XFR message handling are fully applicable to XoT connections as out, e.g.,
well. However, any behavior specified here takes precedence for XoT.</t> persistent connections and XFR message handling, are fully applicable to XoT c
<t>If no TLS connections are currently open, XoT clients MAY send SOA queries ov onnections as
er well. However, any behavior specified here takes precedence for XoT.</t>
UDP or TCP, or TLS.</t> <t>If no TLS connections are currently open, XoT clients <bcp14>MAY</bcp14> se
nd SOA queries
over UDP, TCP, or TLS.</t>
</section> </section>
<section anchor="xot-vs-adot"><name>XoT vs ADoT</name> <section anchor="xot-vs-adot">
<t>As noted earlier, there is currently no specification for encryption of <name>XoT vs. ADoT</name>
connections from recursive resolvers to authoritative servers. Some <t>As noted earlier, there is currently no specification for encryption of
authoritatives are experimenting with ADoT and opportunistic encryption has connections from recursive resolvers to authoritative servers. Some
also been raised as a possibility; it is therefore highly likely that use of authoritative servers are experimenting with ADoT, and opportunistic encryptio
encryption by authoritative servers will evolve in the coming years.</t> n
<t>This raises questions in the short term with regard to TLS connection and has also been raised as a possibility; therefore, it is highly likely that use
message handling for authoritative servers. In particular, there is likely to be of encryption by authoritative servers will evolve in the coming years.</t>
a class of authoritatives that wish to use XoT in the near future with a small <t>This raises questions in the short term with regard to TLS connection and
number of configured secondaries, but that do not wish to support DoT for regula message handling for authoritative servers. In particular, there is likely to
r be
queries from recursives in that same time frame. These servers have to a class of authoritative servers that wish to use XoT in the near future with
potentially cope with probing and direct queries from recursives and from test a
servers, and also potential attacks that might wish to make use of TLS to small number of configured secondaries but that do not wish to support DoT for
overload the server.</t> regular queries from recursives in that same time frame. These servers have to
<t><xref target="RFC5936"></xref> clearly states that non-AXFR session traffic c potentially cope with probing and direct queries from recursives and from test
an use an open TCP servers and also potential attacks that might wish to make use of TLS to
connection, however, this requirement needs to be re-evaluated when considering overload the server.</t>
applying the same model to XoT. Proposing that a server should also start <t><xref target="RFC5936"></xref> clearly states that non-AXFR session traffic
responding to all queries received over TLS just because it has enabled XoT can use an
would be equivalent to defining a form of authoritative DoT. This specification open connection; however, this requirement needs to be reevaluated when consid
does not propose that, but it also does not prohibit servers from answering ering
queries unrelated to XFR exchanges over TLS. Rather, this specification the application of the same model to XoT. Proposing that a server should also
simply outlines in later sections:</t> 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 specificatio
n
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> <ul>
<li>how XoT implementations should utilize EDE codes in response to queries on T <li>the utilization of EDE codes by XoT servers in response to queries on TL
LS S
connections they are not willing to answer (see <xref target="response-rcodes">< connections that they are not willing to answer (see <xref
/xref>)</li> target="response-rcodes"></xref>)</li>
<li>the operational and policy options that a XoT server operator has <li>the operational and policy options that an operator of a XoT server has
with regard to managing TLS connections and messages (see <xref target="xot-serv with regard to managing TLS connections and messages (see <xref
er-connection-handling"></xref>)</li> target="xot-server-connection-handling"></xref>)</li>
</ul> </ul>
</section> </section>
<section anchor="response-rcodes"><name>Response RCODES</name> <section anchor="response-rcodes">
<t>XoT clients and servers MUST implement EDE codes. If a XoT server receives <name>Response RCODES</name>
non-XoT traffic it is not willing to answer on a TLS connection, it SHOULD <t>XoT clients and servers <bcp14>MUST</bcp14> implement EDE codes. If a XoT s
respond with REFUSED and the extended DNS error code 21 - Not Supported erver receives
<xref target="RFC8914"></xref>. XoT clients should not send any further non-XoT traffic it is not willing to answer on a TLS connection, it <bcp14>SHO
queries of this type to the server for a reasonable period of time (for ULD</bcp14>
example, one hour) i.e., long enough that the server configuration or policy respond with REFUSED and the extended DNS error code 21 - Not Supported
might be updated.</t> <xref target="RFC8914"></xref>. XoT clients should not send any further
<t>Historically, servers have used the REFUSED RCODE for many situations, and so queries of this type to the server for a reasonable period of time (for
clients often had no detailed information on which to base an error or fallback example, one hour), i.e., long enough that the server configuration or policy
path when queries were refused. As a result, the client behavior could vary might be updated.</t>
significantly. XoT servers that refuse queries must cater for the fact that <t>Historically, servers have used the REFUSED RCODE for many situations; ther
client behavior might vary from continually retrying queries regardless of efore,
receiving REFUSED to every query, or at the other extreme clients may decide to clients often had no detailed information on which to base an error or fallbac
stop using the server over any transport. This might be because those clients ar k
e path when queries were refused. As a result, the client behavior could vary
either non-XoT clients or do not implement EDE codes.</t> significantly. XoT servers that refuse queries must cater to the fact that
client behavior might vary from continually retrying queries regardless of
receiving REFUSED to every query or, at the other 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>
<section anchor="axot-specifics"><name>AXoT specifics</name> <section anchor="axot-specifics">
<name>AXoT Specifics</name>
<section anchor="padding-axot-responses"><name>Padding AXoT responses</name> <section anchor="padding-axot-responses">
<t>The goal of padding AXoT responses is two fold:</t> <name>Padding AXoT Responses</name>
<t>The goal of padding AXoT responses is two fold:</t>
<ul> <ul>
<li>to obfuscate the actual size of the transferred zone to minimize information <li>to obfuscate the actual size of the transferred zone to minimize infor
leakage about the entire contents of the zone.</li> mation
<li>to obfuscate the incremental changes to the zone between SOA updates to leakage about the entire contents of the zone</li>
minimize information leakage about zone update activity and growth.</li> <li>to obfuscate the incremental changes to the zone between SOA updates t
</ul> o
<t>Note that the re-use of XoT connections for transfers of multiple different minimize information leakage about zone update activity and growth</li>
zones slightly complicates any attempt to analyze the traffic size and timing to </ul>
extract information. Also, effective padding may require state to be kept <t>Note that the reuse of XoT connections for transfers of multiple differen
as zones may grow and/or shrink over time.</t> t
<t>It is noted here that, depending on the padding policies eventually developed zones slightly complicates any attempt to analyze the traffic size and timin
for XoT, g to
the requirement to obfuscate the total zone size might extract information. Also, effective padding may require the state to be ke
require a server to create 'empty' AXoT responses. That is, AXoT responses that pt
contain no RR's apart from an OPT RR containing the EDNS(0) option for padding. because zones may grow and/or shrink over time.</t>
For example, without this capability the maximum size that a tiny zone could be <t>It is noted here that, depending on the padding policies eventually devel
padded to would oped for XoT,
theoretically be limited if there had to be a minimum of 1 RR per packet.</t> the requirement to obfuscate the total zone size might
<t>However, as with existing AXFR, the last AXoT response message sent MUST require a server to create 'empty' AXoT responses, that is, AXoT responses t
contain the same SOA that was in the first message of the AXoT response series hat
in order to signal the conclusion of the zone transfer.</t> contain no RRs apart from an OPT RR containing the EDNS(0) option for paddin
<t><xref target="RFC5936"></xref> says:</t> g.
For example, without this capability, the maximum size that a tiny zone coul
d be padded to
would theoretically be limited if there had to be a minimum of 1 RR per pack
et.</t>
<t>However, as with existing AXFR, the last AXoT response message sent <bcp1
4>MUST</bcp14>
contain the same SOA that was in the first message of the AXoT response seri
es
in order to signal the conclusion of the zone transfer.</t>
<t><xref target="RFC5936"></xref> says:</t>
<blockquote>Each AXFR response message <bcp14>SHOULD</bcp14> contain a suffi
cient 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).</blockquote>
<artwork>&quot;Each AXFR response message SHOULD contain a sufficient number <t>'Empty' AXoT responses generated in order to meet a padding requirement w
of RRs to reasonably amortize the per-message overhead, up to ill be
the largest number that will fit within a DNS message (taking exceptions to the above statement. For flexibility, for future proofing, and
the required content of the other sections into account, as in
described below).&quot; order to guarantee support for future padding policies, it is stated here th
</artwork> at
<t>'Empty' AXoT responses generated in order to meet a padding requirement will secondary implementations <bcp14>MUST</bcp14> be resilient to receiving padd
be ed AXoT
exceptions to the above statement. For flexibility, future proofing and in responses, including 'empty' AXoT responses that contain only an OPT RR cont
order to guarantee support for future padding policies, we state here that aining the
secondary implementations MUST be resilient to receiving padded AXoT responses, EDNS(0) option for padding.</t>
including 'empty' AXoT responses that contain only an OPT RR containing the <t>Recommendations of specific policies for padding AXoT responses are out o
EDNS(0) option for padding.</t> f scope
<t>Recommendation of specific policies for padding AXoT responses are out of sco for this specification. Detailed considerations of such policies and the
pe trade-offs involved are expected to be the subject of future work.</t>
for this specification. Detailed considerations of such policies and the </section>
trade-offs involved are expected to be the subject of future work.</t>
</section>
</section> </section>
<section anchor="ixot-specifics"><name>IXoT specifics</name> <section anchor="ixot-specifics">
<name>IXoT Specifics</name>
<section anchor="condensation-of-responses"><name>Condensation of responses</nam <section anchor="condensation-of-responses">
e> <name>Condensation of Responses</name>
<t><xref target="RFC1995"></xref> says condensation of responses is optional and <t><xref target="RFC1995"></xref> says that condensation of responses is opt
MAY be done. Whilst ional and
it does add complexity to generating responses, it can significantly reduce the <bcp14>MAY</bcp14> be done. Whilst
size of responses. However any such reduction might be offset by increased it does add complexity to generating responses, it can significantly reduce
message size due to padding. This specification does not update the optionality the
of condensation for XoT responses.</t> size of responses. However, any such reduction might be offset by increased
</section> message size due to padding. This specification does not update the optional
ity
of condensation for XoT responses.</t>
</section>
<section anchor="fallback-to-axfr"><name>Fallback to AXFR</name> <section anchor="fallback-to-axfr">
<t>Fallback to AXFR can happen, for example, if the server is not able to provid <name>Fallback to AXFR</name>
e <t>Fallback to AXFR can happen, for example, if the server is not able to pr
an IXFR for the requested SOA. Implementations differ in how long they store ovide
zone deltas and how many may be stored at any one time.</t> an IXFR for the requested SOA. Implementations differ in how long they store
<t>Just as with IXFR-over-TCP, after a failed IXFR a IXoT client SHOULD request zone deltas and how many may be stored at any one time.</t>
the AXFR on the already open XoT connection.</t> <t>Just as with IXFR over TCP, after a failed IXFR, an IXoT client <bcp14>SH
</section> OULD</bcp14>
request the AXFR on the already open XoT connection.</t>
</section>
<section anchor="padding-of-ixot-responses"><name>Padding of IXoT responses</nam <section anchor="padding-of-ixot-responses">
e> <name>Padding of IXoT Responses</name>
<t>The goal of padding IXoT responses is to obfuscate the incremental <t>The goal of padding IXoT responses is to obfuscate the incremental
changes to the zone between SOA updates to minimize information leakage about changes to the zone between SOA updates to minimize information leakage abou
zone update activity and growth. Both the size and timing of the IXoT responses t
could zone update activity and growth. Both the size and timing of the IXoT respon
reveal information.</t> ses could
<t>IXFR responses can vary greatly in size from the order of 100 bytes for one o reveal information.</t>
r <t>IXFR responses can vary greatly in size from the order of 100 bytes for o
two record updates, to tens of thousands of bytes for large dynamic DNSSEC ne or
signed zones. The frequency of IXFR responses can also depend greatly on if and two record updates to tens of thousands of bytes for large, dynamic DNSSEC-s
how the zone is DNSSEC signed.</t> igned zones.
<t>In order to guarantee support for future padding policies, we state here that The frequency of IXFR responses can also depend greatly on if and how the zo
secondary implementations MUST be resilient to receiving padded IXoT responses.< ne is DNSSEC
/t> signed.</t>
<t>Recommendation of specific policies for padding IXoT responses are out of sco <t>In order to guarantee support for future padding policies, it is stated h
pe ere
for this specification. Detailed considerations of such padding policies, the that
use of traffic obfuscation techniques (such as ‘dummy' traffic), and the secondary implementations <bcp14>MUST</bcp14> be resilient to receiving padd
trade-offs involved are expected to be the subject of future work.</t> ed IXoT
</section> responses.</t>
<t>Recommendation of specific policies for padding IXoT responses are out of
scope
for this specification. Detailed considerations of such padding policies, th
e
use of traffic obfuscation techniques (such as generating fake XFR traffic),
and
the trade-offs involved are expected to be the subject of future work.</t>
</section>
</section> </section>
<section anchor="name-compression-and-maximum-payload-sizes"><name>Name compress <section anchor="name-compression-and-maximum-payload-sizes">
ion and maximum payload sizes</name> <name>Name Compression and Maximum Payload Sizes</name>
<t>It is noted here that name compression <xref target="RFC1035"></xref> can be <t>It is noted here that name compression <xref target="RFC1035"></xref> can b
used in XFR responses e used in XFR
to reduce the size of the payload, however, the maximum value of the offset that responses to reduce the size of the payload; however, the maximum value of the
can be used in the name compression pointer structure is 16384. For some DNS offset that
implementations this limits the size of an individual XFR response used in can be used in the name compression pointer structure is 16384. For some DNS
practice to something around the order of 16kB. In principle, larger implementations, this limits the size of an individual XFR response used in
payload sizes can be supported for some responses with more sophisticated practice to something around the order of 16 KB. In principle, larger
approaches (e.g., by pre-calculating the maximum offset required).</t> payload sizes can be supported for some responses with more sophisticated
<t>Implementations may wish to offer options to disable name compression for XoT approaches (e.g., by precalculating the maximum offset required).</t>
responses to enable larger payloads. This might be particularly helpful when <t>Implementations may wish to offer options to disable name compression for X
padding is used since minimizing the payload size is not necessarily a useful oT
optimization in this case and disabling name compression will reduce the responses to enable larger payloads. This might be particularly helpful when
resources required to construct the payload.</t> padding is 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> </section>
<section anchor="multi-primary-configurations"><name>Multi-primary Configuration <section anchor="multi-primary-configurations">
s</name> <name>Multi-primary Configurations</name>
<t>This model can provide flexibility <t>This model can provide flexibility
and redundancy particularly for IXFR. A secondary will receive one or more and 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 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 then choose to send an XFR request to the primary with the highest SOA (or
based on other criteria, e.g., RTT).</t> based on other criteria, e.g., RTT).</t>
<t>When using persistent connections, the secondary may have a XoT connection <t>When using persistent connections, the secondary may have a XoT connection
already open to one or more primaries. Should a secondary preferentially 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 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 or the one with the highest SOA (assuming it doesn't have a connection open to
it already)?</t> it already)?</t>
<t>Two extremes can be envisaged here. The first one can be considered a 'prefer <t>Two extremes can be envisaged here. The first one can be considered a 'pref
red erred
primary connection' model. In this case, the secondary continues to use one 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 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/r not to might include the primary repeatedly closing the connection, long query
esponse RTTs on /response RTTs
transfers or the SOA of the primary being an unacceptable lag behind the SOA of on transfers, or the SOA of the primary being an unacceptable lag behind the S
an alternative primary.</t> OA of
<t>The other extreme can be considered a 'parallel primary connection' model. He an alternative primary.</t>
re, <t>The other extreme can be considered a 'parallel primary connection' model.
a secondary could keep multiple persistent connections open to all available Here,
primaries and only request XFRs from the primary with the highest serial number. a secondary could keep multiple persistent connections open to all available
Since normally the number of secondaries and primaries in direct contact in a primaries and only request XFRs from the primary with the highest serial numbe
transfer group is reasonably low this might be feasible if latency is the most r.
significant concern.</t> Since normally the number of secondaries and primaries in direct contact in a
transfer group is reasonably low, this might be feasible if latency is the mos
t
significant concern.</t>
<t>Recommendation of a particular scheme is out of scope of this document, but <t>Recommendation of a particular scheme is out of scope of this document, but
implementations are encouraged to provide configuration options that allow implementations are encouraged to provide configuration options that allow
operators to make choices about this behavior.</t> operators to make choices about this behavior.</t>
</section> </section>
<section anchor="authentication-mechanisms"><name>Authentication mechanisms</nam <section anchor="authentication-mechanisms">
e> <name>Authentication Mechanisms</name>
<t>To provide context to the requirements in <xref target="xot-transfers"></xref <t>To provide context to the requirements in <xref target="xot-transfers"></xr
>, this ef>, this
section provides a brief summary of some of the existing authentication and section provides a brief summary of some of the existing authentication and
validation mechanisms (both transport independent and TLS specific) that are validation mechanisms (both transport independent and TLS specific) that are
available when performing zone transfers. available when performing zone transfers.
<xref target="xot-authentication"></xref> then discusses in more details specifi <xref target="xot-authentication"></xref> then discusses in more detail specif
cally how a ically how a
combination of TLS authentication, TSIG and IP based ACLs interact for XoT.</t> combination of TLS authentication, TSIG, and IP-based ACLs interact for XoT.</
<t>We classify the mechanisms based on the following properties:</t> t>
<t>In this document, the mechanisms are classified based on the following prop
erties:</t>
<ul> <dl newline="true" spacing="normal">
<li><t>'Data Origin Authentication' (DO): Authentication that the DNS message or <dt>Data Origin Authentication (DO):</dt>
iginated <dd>Authentication 1) of the fact that the DNS message originated
from the party with whom credentials were shared, and of the data integrity from the party with whom credentials were shared and 2) of the data integrit
of the message contents (the originating party may or may not be party y
operating the far end of a TCP/TLS connection in a 'proxy' scenario).</t> of the message contents (the originating party may or may not be the party
</li> operating the far end of a TCP/TLS connection in a 'proxy' scenario).</dd>
<li><t>'Channel Confidentiality' (CC): Confidentiality of the communication chan <dt>Channel Confidentiality (CC):</dt>
nel between the <dd>Confidentiality of the communication channel between the
client and server (i.e. the two end points of a TCP/TLS connection) from passive client and server (i.e., the two endpoints of a TCP/TLS connection) from pas
surveillance.</t> sive
</li> surveillance.</dd>
<li><t>'Channel Authentication' (CA): Authentication of the identity of party to <dt>Channel Authentication (CA):</dt>
whom a TCP/TLS <dd>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 connection is made (this might not be a direct connection between the primar
and secondary in a proxy scenario).</t> y
</li> and secondary in a proxy scenario).</dd>
</ul> </dl>
<section anchor="tsig"><name>TSIG</name> <section anchor="tsig">
<t>TSIG <xref target="RFC8945"></xref> provides a mechanism for two or more part <name>TSIG</name>
ies to use shared <t>TSIG <xref target="RFC8945"></xref> provides a mechanism for two or more pa
secret keys which can then be used to create a message digest to protect rties to use
individual DNS messages. This allows each party to authenticate that a request shared secret keys that can then be used to create a message digest to protect
or response (and the data in it) came from the other party, even if it was individual DNS messages. This allows each party to authenticate that a request
transmitted over an unsecured channel or via a proxy.</t> or response (and the data in it) came from the other party, even if it was
<t>Properties: Data origin authentication</t> transmitted over an unsecured channel or via a proxy.</t>
<dl newline="false" spacing="normal">
<dt>Properties:</dt>
<dd>Data origin authentication.</dd>
</dl>
</section> </section>
<section anchor="sig-0"><name>SIG(0)</name> <section anchor="sig-0">
<t>SIG(0) <xref target="RFC2931"></xref> similarly provides a mechanism to digit <name>SIG(0)</name>
ally sign a DNS <t>SIG(0) <xref target="RFC2931"></xref> similarly provides a mechanism to dig
message but uses public key authentication, where the public keys are stored in itally sign a
DNS as KEY RRs and a private key is stored at the signer.</t> DNS message but uses public key authentication, where the public keys are stor
<t>Properties: Data origin authentication</t> ed in
DNS as KEY RRs and a private key is stored at the signer.</t>
<dl newline="false" spacing="normal">
<dt>Properties:</dt>
<dd>Data origin authentication.</dd>
</dl>
</section> </section>
<section anchor="tls"><name>TLS</name> <section anchor="tls">
<name>TLS</name>
<section anchor="opportunistic-tls"><name>Opportunistic TLS</name> <section anchor="opportunistic-tls">
<t>Opportunistic TLS for DoT is defined in <xref target="RFC8310"></xref> and ca <name>Opportunistic TLS</name>
n provide a defense against passive <t>Opportunistic TLS for DoT is defined in <xref target="RFC8310"></xref> an
surveillance, providing on-the-wire confidentiality. Essentially</t> d can provide a
defense against passive
<ul> surveillance, providing on-the-wire confidentiality. Essentially:</t>
<li>clients that know authentication information for a server SHOULD try to auth <ul spacing="normal">
enticate the server</li> <li>if clients know authentication information for a server, they
<li>however they MAY fallback to using TLS without authentication and</li> <bcp14>SHOULD</bcp14> try to authenticate the server,</li>
<li>they MAY fallback to using cleartext if TLS is not available.</li> <li>if this fails or clients do not know the information, they <bcp14>MAY<
</ul> /bcp14>
<t>As such, it does not offer a defense against active attacks (e.g., an on path fallback to using TLS without authentication, or</li>
active attacker <li>clients <bcp14>MAY</bcp14> fallback to using cleartext if TLS is not
on the connection from client to server), and is not considered as useful for Xo available.</li>
T.</t> </ul>
<t>Properties: None guaranteed.</t> <t>As such, it does not offer a defense against active attacks (e.g., an on-
path active
attacker on the connection from client to server) and is not considered as u
seful for
XoT.</t>
<dl newline="false" spacing="normal">
<dt>Properties:</dt>
<dd>None guaranteed.</dd>
</dl>
</section> </section>
<section anchor="strict-tls"><name>Strict TLS</name> <section anchor="strict-tls">
<t>Strict TLS for DoT <xref target="RFC8310"></xref> requires that a client is c <name>Strict TLS</name>
onfigured with an <t>Strict TLS for DoT <xref target="RFC8310"></xref> requires that a client is
authentication domain name (and/or SPKI pinset) that MUST be used to configured
authenticate the TLS handshake with the server. If authentication of the server with an authentication domain name (and/or Subject Public Key Info (SPKI) pin
fails, the client will not proceed with the connection. This provides a defense set) that
for the client against active surveillance, providing client-to-server <bcp14>MUST</bcp14> be used to
authentication and end-to-end channel confidentiality.</t> authenticate the TLS handshake with the server. If authentication of the serve
<t>Properties: Channel confidentiality and channel authentication (of the server r
).</t> fails, the client will not proceed with the connection. This provides a defens
e
for the client against active surveillance, providing client-to-server
authentication and end-to-end channel confidentiality.</t>
<dl newline="false" spacing="compact">
<dt>Properties:</dt>
<dd>Channel confidentiality and channel authentication (of the server).</dd>
</dl>
</section> </section>
<section anchor="mutual-tls"><name>Mutual TLS</name> <section anchor="mutual-tls">
<t>This is an extension to Strict TLS <xref target="RFC8310"></xref> which requi <name>Mutual TLS</name>
res that a client is <t>This is an extension to Strict TLS <xref target="RFC8310"></xref> that requ
configured with an authentication domain name (and/or SPKI pinset) and a client ires that a
certificate. The client offers the certificate for authentication by the server client is configured with an authentication domain name (and/or SPKI pin set)
and the client can authenticate the server the same way as in Strict TLS. This and a client
provides a defense for both parties against active surveillance, providing certificate. The client offers the certificate for authentication by the serve
bi-directional authentication and end-to-end channel confidentiality.</t> r,
<t>Properties: Channel confidentiality and mutual channel authentication.</t> 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
bidirectional authentication and end-to-end channel confidentiality.</t>
<dl newline="false" spacing="compact">
<dt>Properties:</dt>
<dd>Channel confidentiality and mutual channel authentication.</dd>
</dl>
</section> </section>
</section> </section>
<section anchor="ip-based-acl-on-the-primary"><name>IP Based ACL on the Primary< <section anchor="ip-based-acl-on-the-primary">
/name> <name>IP-Based ACL on the Primary</name>
<t>Most DNS server implementations offer an option to configure an IP based Acce <t>Most DNS server implementations offer an option to configure an IP-based
ss ACL, which is often used in combination with TSIG-based ACLs to
Control List (ACL), which is often used in combination with TSIG based ACLs to restrict access to zone transfers on primary servers on a per-query basis.</t>
restrict access to zone transfers on primary servers on a per query basis.</t> <t>This is also possible with XoT, but it must be noted that, as with TCP, the
<t>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
implementation of such an ACL cannot be enforced on the primary until an XFR request is received on an established connection.</t>
request is received on an established connection.</t> <t>As discussed in <xref target="xot-server-connection-handling"></xref>, an
<t>As discussed in <xref target="xot-server-connection-handling"></xref>, an IP IP-based per-connection ACL could also be implemented where only TLS connectio
based per connection ACL ns from
could also be implemented where only TLS connections from recognized recognized secondaries are accepted.</t>
secondaries are accepted.</t> <dl newline="false" spacing="normal">
<t>Properties: Channel authentication of the client.</t> <dt>Properties:</dt>
<dd>Channel authentication of the client.</dd>
</dl>
</section> </section>
<section anchor="zonemd"><name>ZONEMD</name> <section anchor="zonemd">
<t>For completeness, we also describe Message Digest for DNS Zones (ZONEMD) <name>ZONEMD</name>
<xref target="RFC8976"></xref> here. The message digest <t>For completeness, ZONEMD
is a mechanism that can be used to verify the content of a standalone zone. It <xref target="RFC8976" format="default"/> ("Message Digest for DNS Zones") is
is designed to be independent of the transmission channel or mechanism, allowing described here.
a general consumer of a zone to do origin authentication of the entire zone The ZONEMD message digest
contents. Note that the current version of <xref target="RFC8976"></xref> is a mechanism that can be used to verify the content of a standalone zone. It
states:</t> is designed to be independent of the transmission channel or mechanism, allowi
<t><tt>As specified herein, ZONEMD is impractical for large, dynamic zones due t ng
o the a general consumer of a zone to do origin authentication of the entire zone
time and resources required for digest calculation. However, The ZONEMD record contents. Note that the current version of <xref target="RFC8976"></xref>
is extensible so that new digest schemes may be added in the future to support states:</t>
large, dynamic zones.</tt></t> <blockquote>As specified herein, ZONEMD is impractical for large, dynamic zone
<t>It is complementary but orthogonal the above mechanisms; and can be used in s due to the
conjunction with XoT, but is not considered further here.</t> 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.</blockquote>
<t>It is complementary but orthogonal to the above mechanisms and can be used
in
conjunction with XoT but is not considered further here.</t>
</section> </section>
</section> </section>
<section anchor="xot-authentication"><name>XoT authentication</name> <section anchor="xot-authentication">
<t>It is noted that zone transfer scenarios can vary from a simple single <name>XoT Authentication</name>
primary/secondary relationship where both servers are under the control of a <t>It is noted that zone transfer scenarios can vary from a simple single
single operator to a complex hierarchical structure which includes proxies and primary/secondary relationship where both servers are under the control of a
multiple operators. Each deployment scenario will require specific analysis to single operator to a complex hierarchical structure that includes proxies and
determine which combination of authentication methods are best suited to the multiple operators. Each deployment scenario will require specific analysis to
deployment model in question.</t> determine which combination of authentication methods are best suited to the
<t>The XoT authentication requirement specified in <xref target="xot-transfers"> deployment model in question.</t>
</xref> addresses the <t>The XoT authentication requirement specified in <xref target="xot-transfers
issue of ensuring that the transfers are encrypted between the two endpoints "></xref>
directly involved in the current transfers. The following table summarizes the addresses the
properties of a selection of the mechanisms discussed in issue of ensuring that the transfers are encrypted between the two endpoints
<xref target="authentication-mechanisms"></xref>. The two letter acronyms for th directly involved in the current transfers. The following table summarizes the
e properties are properties of a selection of the mechanisms discussed in
used below and (S) indicates the secondary and (P) indicates <xref target="authentication-mechanisms"></xref>. The two-letter abbreviations
the primary.</t> for the properties
<table> are used below: (S) indicates the secondary and (P) indicates
<thead> the primary.</t>
<tr> <table anchor="table1">
<th align="left">Method</th> <name>Properties of Authentication Methods for XoT</name>
<th align="center">DO(S)</th> <thead>
<th align="center">CC(S)</th> <tr>
<th align="center">CA(S)</th> <th align="left">Method</th>
<th align="center">DO(P)</th> <th align="center">DO(S)</th>
<th align="center">CC(P)</th> <th align="center">CC(S)</th>
<th align="center">CA(P)</th> <th align="center">CA(S)</th>
</tr> <th align="center">DO(P)</th>
</thead> <th align="center">CC(P)</th>
<th align="center">CA(P)</th>
<tbody> </tr>
<tr> </thead>
<td align="left">Strict TLS</td>
<td align="center"></td>
<td align="center">Y</td>
<td align="center">Y</td>
<td align="center"></td>
<td align="center">Y</td>
<td align="center"></td>
</tr>
<tr>
<td align="left">Mutual TLS</td>
<td align="center"></td>
<td align="center">Y</td>
<td align="center">Y</td>
<td align="center"></td>
<td align="center">Y</td>
<td align="center">Y</td>
</tr>
<tr> <tbody>
<td align="left">ACL on primary</td> <tr>
<td align="center"></td> <td align="left">Strict TLS</td>
<td align="center"></td> <td align="center"></td>
<td align="center"></td> <td align="center">Y</td>
<td align="center"></td> <td align="center">Y</td>
<td align="center"></td> <td align="center"></td>
<td align="center">Y</td> <td align="center">Y</td>
</tr> <td align="center"></td>
</tr>
<tr> <tr>
<td align="left">TSIG</td> <td align="left">Mutual TLS</td>
<td align="center">Y</td> <td align="center"></td>
<td align="center"></td> <td align="center">Y</td>
<td align="center"></td> <td align="center">Y</td>
<td align="center">Y</td> <td align="center"></td>
<td align="center"></td> <td align="center">Y</td>
<td align="center"></td> <td align="center">Y</td>
</tr> </tr>
</tbody>
</table><t>Table 1: Properties of Authentication methods for XoT</t>
<t>Based on this analysis it can be seen that:</t>
<ul> <tr>
<li><t>Using just mutual TLS can be considered a standalone solution since both <td align="left">ACL on primary</td>
end points are <td align="center"></td>
cryptographically authenticated</t> <td align="center"></td>
</li> <td align="center"></td>
<li><t>Using secondary side Strict TLS with a primary side IP ACL and TSIG/SIG(0 <td align="center"></td>
) combination provides <td align="center"></td>
sufficient protection to be acceptable.</t> <td align="center">Y</td>
</li> </tr>
</ul>
<t>Using just an IP ACL could be susceptible to attacks that can spoof TCP IP
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 by
any server with the key.</t>
</section>
<section anchor="policies-for-both-axot-and-ixot"><name>Policies for Both AXoT a <tr>
nd IXoT</name> <td align="left">TSIG</td>
<t>Whilst the protection of the zone contents in a transfer between two end poin <td align="center">Y</td>
ts <td align="center"></td>
can be provided by the XoT protocol, the protection of all the transfers of a <td align="center"></td>
given zone requires operational administration and policy management.</t> <td align="center">Y</td>
<t>We call the entire group of servers involved in XFR for a particular set of <td align="center"></td>
zones (all the primaries and all the secondaries) the 'transfer group'.</t> <td align="center"></td>
<t>In order to assure the confidentiality of the zone information, the entire </tr>
transfer group MUST have a consistent policy of using XoT. If any do not, this </tbody>
is a weak link for attackers to exploit. For clarification, this means that </table>
within any transfer group both AXFRs and IXFRs for a zone MUST all use XoT.</t> <t>Based on this analysis, it can be seen that:</t>
<t>An individual zone transfer is not considered protected by XoT unless <ul>
both the client and server are configured to use only XoT and the overall zone <li>Using just mutual TLS can be considered a standalone solution since both
transfer is not considered protected until all members of the transfer group endpoints are
are configured to use only XoT with all other transfers servers (see <xref targe cryptographically authenticated.</li>
t="implementation-considerations"></xref>).</t> <li>Using secondary-side Strict TLS with a primary-side IP-based ACL and TSI
<t>A XoT policy MUST specify if</t> G/SIG(0) combination
provides sufficient protection to be acceptable.</li>
</ul>
<ul> <t>Using just an IP-based ACL could be susceptible to attacks that can spoof T
<li>mutual TLS is used and/or</li> CP IP
<li>a IP ACL and TSIG/SIG(0) combination is used</li> addresses; using TSIG/SIG(0) alone could be susceptible to attacks that were
</ul> able to capture such messages should they be accidentally sent in cleartext by
<t>Since this may require configuration of a number of servers who may be under any server
the control of different operators the desired consistency could be hard to with the key.</t>
enforce and audit in practice.</t>
<t>Certain aspects of the Policies can be relatively easily tested independently
,
e.g., by requesting zone transfers without TSIG, from unauthorized IP addresses
or over cleartext DNS. Other aspects such as if a secondary will accept data
without a TSIG digest or if secondaries are using Strict as opposed to
Opportunistic TLS are more challenging.</t>
<t>The mechanics of co-ordinating or enforcing such policies are out of the scop
e
of this document but may be the subject of future operational guidance.</t>
</section> </section>
<section anchor="implementation-considerations"><name>Implementation Considerati <section anchor="policies-for-both-axot-and-ixot">
ons</name> <name>Policies for Both AXoT and IXoT</name>
<t>Server implementations may want to also offer options that allow ACLs on a zo <t>Whilst the protection of the zone contents in a transfer between two endpoi
ne nts
to specify that a specific client can use either XoT or TCP. This would allow can be provided by the XoT protocol, the protection of all the transfers of a
for flexibility while clients are migrating to XoT.</t> given zone requires operational administration and policy management.</t>
<t>Client implementations may similarly want to offer options to cater for the <t>The entire group of servers involved in XFR for a particular set of
multi-primary case where the primaries are migrating to XoT.</t> zones (all the primaries and all the secondaries) is called the 'transfer grou
p'.</t>
<t>In order to assure the confidentiality of the zone information, the entire
transfer group <bcp14>MUST</bcp14> have a consistent policy of using XoT. If a
ny 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 <bcp14>MUST</bcp14>
all use
XoT.</t>
<t>An individual zone transfer is not considered protected by XoT unless
both the client and server are configured to use only XoT, and the overall zon
e
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 XoT policy <bcp14>MUST</bcp14> specify if:</t>
<ul>
<li>mutual TLS is used and/or</li>
<li>an IP-based ACL and TSIG/SIG(0) combination is used.</li>
</ul>
<t>Since this may require configuration of a number of servers who may be unde
r
the control of different operators, the desired consistency could be hard to
enforce and audit in practice.</t>
<t>Certain aspects of the policies can be relatively easy to test independentl
y,
e.g., by requesting zone transfers without TSIG, from unauthorized IP addresse
s
or over cleartext DNS. Other aspects, such as if a secondary will accept data
without a TSIG digest or if secondaries are using Strict as opposed to
Opportunistic TLS, are more challenging.</t>
<t>The mechanics of coordinating or enforcing such policies are out of the sco
pe
of this document but may be the subject of future operational guidance.</t>
</section> </section>
<section anchor="operational-considerations"><name>Operational Considerations</n <section anchor="implementation-considerations">
ame> <name>Implementation Considerations</name>
<t>If the options described in <xref target="implementation-considerations"></xr <t>Server implementations may want to also offer options that allow ACLs on a
ef> are available, zone
such configuration options MUST only be used in a 'migration mode', and to specify that a specific client can use either XoT or TCP. This would allow
therefore should be used with great care.</t> for flexibility while clients are migrating to XoT.</t>
<t>It is noted that use of a TLS proxy in front of the primary server is a simpl <t>Client implementations may similarly want to offer options to cater to the
e multi-primary case where the primaries are migrating to XoT.</t>
deployment solution that can enable server side XoT.</t>
</section> </section>
<section anchor="iana-considerations"><name>IANA Considerations</name> <section anchor="operational-considerations">
<t>None.</t> <name>Operational Considerations</name>
<t>If the options described in <xref target="implementation-considerations"></
xref> are
available,
such configuration options <bcp14>MUST</bcp14> only be used in a 'migration mo
de' and
therefore should be used with great care.</t>
<t>It is noted that use of a TLS proxy in front of the primary server is a sim
ple
deployment solution that can enable server-side XoT.</t>
</section> </section>
<section anchor="implementation-status"><name>Implementation Status</name> <section anchor="iana-considerations">
<t>[THIS SECTION TO BE REMOVED BEFORE PUBLICATION] This section records the stat <name>IANA Considerations</name>
us <t>This document has no IANA actions.</t>
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: <e
ref target="https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+St
atus#DNSPrivacyImplementationStatus-XFR/XoTImplementationstatus">XoT implementat
ion 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/Change
log">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/NLnetLa
bs/nsd/pull/145">XFR-over-TCP</eref></li>
<li>Client side <eref target="https://github.com/NLnetLabs/nsd/pull/149">XoT</er
ef></li>
</ol></li>
<li><t>Version 9.17.7 of BIND contained an initial implementation of DoT, implem
entation of XoT is planned for early <eref target="https://gitlab.isc.org/isc-pr
ojects/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>
</section> </section>
<section anchor="security-considerations"><name>Security Considerations</name> <section anchor="security-considerations">
<name>Security Considerations</name>
<t>This document specifies a security measure against a DNS risk: the risk that an <t>This document specifies a security measure against a DNS risk: the risk that an
attacker collects entire DNS zones through eavesdropping on clear text DNS zone attacker collects entire DNS zones through eavesdropping on cleartext DNS zone
transfers.</t> transfers.</t>
<t>This does not mitigate:</t> <t>This does not mitigate:</t>
<ul> <ul>
<li>the risk that some level of zone activity might be inferred by observing zon <li>the risk that some level of zone activity might be inferred by observing z
e one
transfer sizes and timing on encrypted connections (even with padding transfer sizes and timing on encrypted connections (even with padding
applied), in combination with obtaining SOA records by directly querying applied), in combination with obtaining SOA records by directly querying
authoritative servers.</li> authoritative servers,</li>
<li>the risk that hidden primaries might be inferred or identified via <li>the risk that hidden primaries might be inferred or identified via
observation of encrypted connections.</li> observation of encrypted connections, or</li>
<li>the risk of zone contents being obtained via zone enumeration techniques.</l <li>the risk of zone contents being obtained via zone enumeration techniques.<
i> /li>
</ul> </ul>
<t>Security concerns of DoT are outlined in <xref target="RFC7858"></xref> and < xref target="RFC8310"></xref>.</t> <t>Security concerns of DoT are outlined in <xref target="RFC7858"></xref> and < xref target="RFC8310"></xref>.</t>
</section> </section>
<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>The authors thank Tony Finch, Benno Overeinder, Shumon Huque
and Tim Wicinski and many other members of DPRIVE for review and discussions.</t
>
<t>The authors particularly thank Peter van Dijk, Ondrej Sury, 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"><name>Contributors</name>
<t>Significant contributions to 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 the requirement to use the DoT ALPN</li>
<li><t>Modify the one of the options for validation of a client from just an IP
ACL to a combination of
IP ACL and TSIG/SIG(0)</t>
<ul>
<li>Update Abstract and Introduction with clear descriptions of how earlier spec
ifications are updated</li>
<li>Add reference on NSEC3 attacks</li>
<li>Justify use of SHOULD in sections 7.3.2 and 7.3.3.</li>
<li>Clarify 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 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 in the implementation status section</li>
<li>Convert the URIs that will remain on publication to references</li>
<li>Correct typos in acknowledgments</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-06</t>
<ul>
<li>Update text relating to pipelining and connection reuse after WGLC comments.
</li>
<li>Add link to implementation status matrix</li>
<li>Various typos</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-05</t>
<ul>
<li>Remove the open questions that received no comments.</li>
<li>Add more detail to the implementation section</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-04</t>
<ul>
<li>Add Github repository</li>
<li>Fix typos and references and improve layout.</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-03</t>
<ul>
<li>Remove propose to use ALPN</li>
<li>Clarify updates to both RFC1995 and RFC5936 by adding specific sections on t
his</li>
<li>Add a section on the threat model</li>
<li>Convert all SVG diagrams 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 and IXoT for message and
connection handling taking into account previous specifications in more detail</
li>
<li>Add use of APLN and limitations on traffic on XoT connections.</li>
<li>Add new discussions of padding for both AXoT and IXoT</li>
<li>Add text on SIG(0)</li>
<li>Update security considerations</li>
<li>Move multi-primary considerations to earlier as they are related to connecti
on
handling</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-01</t>
<ul>
<li>Minor editorial updates</li>
<li>Add requirement for TLS 1.3. or later</li>
</ul>
<t>draft-ietf-dprive-xfr-over-tls-00</t>
<ul>
<li>Rename after adoption and reference update.</li>
<li>Add placeholder for SIG(0) discussion</li>
<li>Update section on ZONEMD</li>
</ul>
<t>draft-hzpa-dprive-xfr-over-tls-02</t>
<ul>
<li>Substantial re-work of 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> </middle>
<back> <back>
<references><name>Normative References</name>
<reference anchor="DoT-ALPN" target="https://www.iana.org/assignments/tls-extens <displayreference target="I-D.ietf-dprive-dnsoquic" to="DPRIVE-DNSOQUIC"/>
iontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids"> <displayreference target="I-D.ietf-tls-esni" to="TLS-ESNI"/>
<front> <displayreference target="I-D.vcelak-nsec5" to="NSEC5"/>
<title>TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs</title
> <references>
<author> <name> References</name>
<organization>IANA</organization> <references>
</author> <name>Normative References</name>
<date year="2021"></date> <reference anchor="DoT-ALPN" target="https://www.iana.org/assignments/tls-e
</front> xtensiontype-values/">
</reference> <front>
<title>TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs</tit
le>
<author>
<organization>IANA</organization>
</author>
</front>
</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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.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.8914. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8945. xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8945. xml"/>
</references> </references>
<references><name>Informative References</name> <references>
<name>Informative References</name>
<reference anchor="BIND" target="https://www.isc.org/bind/"> <reference anchor="BIND" target="https://www.isc.org/bind/">
<front> <front>
<title>BIND 9.16.16</title> <title>BIND 9.16.16</title>
<author> <author>
<organization>ISC</organization> <organization>ISC</organization>
</author> </author>
<date year="2021"></date>
</front> </front>
</reference> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i etf-dprive-dnsoquic.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i etf-dprive-dnsoquic.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i
etf-dprive-phase2-requirements.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9076.
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i xml"/>
etf-dprive-rfc7626-bis.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i etf-tls-esni.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i etf-tls-esni.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.v celak-nsec5.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.v celak-nsec5.xml"/>
<reference anchor="NSD" target="https://www.nlnetlabs.nl/projects/nsd/about/"> <reference anchor="NSD" target="https://www.nlnetlabs.nl/projects/nsd/about/">
<front> <front>
<title>NSD 4.3.6</title> <title>NSD 4.3.6</title>
<author> <author>
<organization>NLnet Labs</organization> <organization>NLnet Labs</organization>
</author> </author>
<date year="2021"></date>
</front> </front>
</reference> </reference>
<reference anchor="NSEC3-attacks" target="https://www.cs.bu.edu/~goldbe/papers/n sec3attacks.pdf"> <reference anchor="NSEC3-attacks" target="https://www.cs.bu.edu/~goldbe/papers/n sec3attacks.pdf">
<front> <front>
<title>Stretching NSEC3 to the Limit:&#xA;Efficient Zone Enumeration Attacks <title>Stretching NSEC3 to the Limit: Efficient Zone Enumeration Attacks on
on NSEC3 Variants</title> NSEC3
Variants</title>
<author fullname="Sharon Goldberg" initials="S." surname="Goldberg"> <author fullname="Sharon Goldberg" initials="S." surname="Goldberg">
<organization> Boston University, Department of Computer Science</organiza tion> <organization> Boston University, Department of Computer Science</organiza tion>
</author> </author>
<author fullname="Moni Naor" initials="N." surname="Naor"> <author fullname="Moni Naor" initials="N." surname="Naor">
<organization>Weizmann Institute of Science, Department of Computer Scienc <organization>Weizmann Institute of Science, Department of Computer Scienc
e and Applied Mathematics</organization> e and Applied
Mathematics</organization>
</author> </author>
<author fullname="Dimitrios Papadopoulos" initials="D." surname="Papadopoulo s"> <author fullname="Dimitrios Papadopoulos" initials="D." surname="Papadopoulo s">
<organization> Boston University, Department of Computer Science</organiza tion> <organization> Boston University, Department of Computer Science</organiza tion>
</author> </author>
<author fullname="Leonid Reyzin" initials="L." surname="Reyzin"> <author fullname="Leonid Reyzin" initials="L." surname="Reyzin">
<organization> Boston University, Department of Computer Science</organiza tion> <organization> Boston University, Department of Computer Science</organiza tion>
</author> </author>
<author fullname="Sachin Vasant" initials="S." surname="Vasant"> <author fullname="Sachin Vasant" initials="S." surname="Vasant">
<organization> Boston University, Department of Computer Science</organiza tion> <organization> Boston University, Department of Computer Science</organiza tion>
</author> </author>
<author fullname="Asaf Ziv" initials="A." surname="Ziv"> <author fullname="Asaf Ziv" initials="A." surname="Ziv">
<organization>Weizmann Institute of Science, Department of Computer Scienc <organization>Weizmann Institute of Science, Department of Computer Scienc
e and Applied Mathematics</organization> e and Applied
Mathematics</organization>
</author> </author>
<date year="2015"></date> <date month="February" year="2015"></date>
</front> </front>
</reference> </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.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.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.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.8484. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8976. 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/Special
Publications/NIST.SP.800-81-2.pdf"> <reference anchor="NIST-GUIDE" target="https://nvlpubs.nist.gov/nistpubs/Special
Publications/NIST.SP.800-81-2.pdf">
<front> <front>
<title>Secure Domain Name System (DNS) Deployment Guide</title> <title>Secure Domain Name System (DNS) Deployment Guide</title>
<author fullname="Ramaswamy Chandramouli" initials="R." surname="Chandramoul i"> <author fullname="Ramaswamy Chandramouli" initials="R." surname="Chandramoul i">
<organization>NIST</organization> <organization>NIST</organization>
</author> </author>
<author fullname="Scott Rose" initials="S." surname="Rose"> <author fullname="Scott Rose" initials="S." surname="Rose">
<organization>NIST</organization> <organization>NIST</organization>
</author> </author>
<date year="2013"></date> <date month="September" year="2013"></date>
</front> </front>
</reference> </reference>
</references> </references>
</references>
<section anchor="xot-server-connection-handling"><name>XoT server connection han <section anchor="xot-server-connection-handling">
dling</name> <name>XoT Server Connection Handling</name>
<t>This appendix provides a non-normative outline of the pros and cons of XoT se <t>This appendix provides a non-normative outline of the pros and cons of XoT
rver connection server
handling options.</t> connection-handling options.</t>
<t>For completeness, it is noted that an earlier version of the specification <t>For completeness, it is noted that an earlier draft version of this documen
suggested using a XoT specific ALPN to negotiate TLS connections that supported t
only a limited set of queries (SOA, XRFs), however, this did not gain support. suggested using a XoT-specific ALPN to negotiate TLS connections that supporte
Reasons given included additional code complexity and the fact that XoT and ADoT d
are both only a limited set of queries (SOA, XFRs); however, this did not gain support.
DNS wire format and so should share the <tt>dot</tt> ALPN.</t> Reasons given included additional code complexity and the fact that XoT and AD
oT 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 <section anchor="only-listen-on-tls-on-a-specific-ip-address">
on TLS on a specific IP address</name> <name>Listening Only on a Specific IP Address for TLS</name>
<t>Obviously a nameserver which hosts a zone and services queries for the zone o <t>Obviously, a name server that hosts a zone and services queries for the zon
n e on
an IP address published in an NS record may wish to use a separate IP address an IP address published in an NS record may wish to use a separate IP address
for listening on TLS for XoT, only publishing that address to its secondaries.</ for XoT to listen for TLS, only publishing that address to its secondaries.</t
t> >
<t>Pros: Probing of the public IP address will show no support for TLS. ACLs wil <dl newline="false" spacing="normal">
l <dt>Pros:</dt>
prevent zone transfer on all transports on a per query basis.</t> <dd>Probing of the public IP address will show no support for TLS. ACLs will
<t>Cons: Attackers passively observing traffic will still be able to observe TLS prevent zone transfer on all transports on a per-query basis.</dd>
connections to the separate address.</t> <dt>Cons:</dt>
<dd>Attackers passively observing traffic will still be able to observe TLS
connections to the separate address.</dd>
</dl>
</section> </section>
<section anchor="client-specific-tls-acceptance"><name>Client specific TLS accep <section anchor="client-specific-tls-acceptance">
tance</name> <name>Client-Specific TLS Acceptance</name>
<t>Primaries that include IP based ACLs and/or mutual TLS in their authenticatio <t>Primaries that include IP-based ACLs and/or mutual TLS in their authenticat
n models ion models
have the option of only accepting TLS connections from authorized clients. This have the option of only accepting TLS connections from authorized clients. Thi
could be implemented using a proxy or directly in DNS implementation.</t> s
<t>Pros: Connection management happens at setup time. The maximum number of TLS could be implemented either using a proxy or directly in the DNS implementatio
connections a server will have to support can be easily assessed. Once the n.</t>
connection is accepted the server might well be willing to answer any query on <dl newline="false" spacing="normal">
that connection since it is coming from a configured secondary and a specific <dt>Pros:</dt>
response policy on the connection may not be needed (see below).</t> <dd>Connection management happens at setup time. The maximum number of TLS
<t>Cons: Currently, none of the major open source DNS authoritative connections a server will have to support can be easily assessed. Once the
implementations support such an option.</t> connection is accepted, the server might well be willing to answer any query
on
that connection since it is coming from a configured secondary, and a specif
ic
response policy on the connection may not be needed (see below).</dd>
<dt>Cons:</dt>
<dd>Currently, none of the major open-source
implementations of a DNS authoritative server support such an option.</dd>
</dl>
</section> </section>
<section anchor="sni-based-tls-acceptance"><name>SNI based TLS acceptance</name> <section anchor="sni-based-tls-acceptance">
<t>Primaries could also choose to only accept TLS connections based on an SNI th <name>SNI-Based TLS Acceptance</name>
at <t>Primaries could also choose to only accept TLS connections based on a Serve
was published only to their secondaries.</t> r Name
<t>Pros: Reduces the number of accepted connections.</t> Indication (SNI) that was published only to their secondaries.</t>
<t>Cons: As above. Also, this is not a recommended use of SNI. For SNIs sent in <dl newline="false" spacing="normal">
the <dt>Pros:</dt>
clear, this would still allow attackers passively observing traffic to <dd>Reduces the number of accepted connections.</dd>
potentially abuse this mechanism. The use of Encrypted Client Hello <dt>Cons:</dt>
<xref target="I-D.ietf-tls-esni"></xref> may be of use here.</t> <dd>As above. Also, this is not a recommended use of SNI. For SNIs sent in t
he
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> may be of use here.</dd>
</dl>
</section> </section>
<section anchor="transport-specific-response-policies"><name>Transport specific <section anchor="transport-specific-response-policies">
response policies</name> <name>Transport-Specific Response Policies</name>
<t>Some primaries might rely on TSIG/SIG(0) combined with per-query IP based <t>Some primaries might rely on TSIG/SIG(0) combined with per-query, IP-based
ACLs to authenticate secondaries. In this case the primary must accept all ACLs to authenticate secondaries. In this case, the primary must accept all
incoming TLS/TCP connections and then apply a transport-specific response policy incoming TLS/TCP connections and then apply a transport-specific response poli
on a per cy on a
query basis.</t> per-query basis.</t>
<t>As an aside, whilst <xref target="RFC7766"></xref> makes a general purpose di <t>As an aside, whilst <xref target="RFC7766"></xref> makes a general purpose
stinction in the advice to clients distinction in
about their usage of connections (between regular queries and zone transfers) th the advice to clients
is is about their usage of connections (between regular queries and zone transfers),
not strict and nothing in the DNS protocol prevents using the same connection this is
for both types of traffic. Hence a server cannot know the intention of any not strict, and nothing in the DNS protocol prevents using the same connection
client that connects to it, it can only inspect the messages it receives on for both types of traffic. Hence, a server cannot know the intention of any
such a connection and make per-query decisions about whether or not to answer client that connects to it; it can only inspect the messages it receives on
those queries.</t> such a connection and make per-query decisions about whether or not to answer
<t>Example policies a XoT server might implement are:</t> those queries.</t>
<t>Example policies a XoT server might implement are:</t>
<ul> <dl newline="false" spacing="normal" indent="12">
<li>strict: REFUSE all queries on TLS connections except SOA and authorized XFR <dt>strict:</dt>
requests</li> <dd>REFUSE all queries on TLS connections, except SOA and authorized XFR req
<li>moderate: REFUSE all queries on TLS connections until one is received that i uests</dd>
s <dt>moderate:</dt>
signed by a recognized TSIG/SIG(0) key, then answer all queries on the <dd>REFUSE all queries on TLS connections until one is received that is
connection after that</li> signed by a recognized TSIG/SIG(0) key, then answer all queries on the
<li>complex: apply a heuristic to determine which queries on a TLS connections t connection after that</dd>
o REFUSE</li> <dt>complex:</dt>
<li>relaxed: answer all non-XoT queries on all TLS connections with the same pol <dd>apply a heuristic to determine which queries on a TLS connections to REF
icy applied to TCP queries</li> USE</dd>
</ul> <dt>relaxed:</dt>
<t>Pros: Allows for flexible behavior by the server that could be changed over t <dd>answer all non-XoT queries on all TLS connections with the same policy a
ime.</t> pplied to TCP
<t>Cons: The server must handle the burden of accepting all TLS connections just queries</dd>
to perform XFRs with a small number of secondaries. Client behavior to REFUSED </dl>
response is not clearly defined (see <xref target="response-rcodes"></xref>). Cu <dl newline="false" spacing="normal">
rrently, none of the major open <dt>Pros:</dt>
source DNS authoritative implementations offer an option for different response <dd>Allows for flexible behavior by the server that could be changed over ti
policies in different transports (but such functionality could potentially be im me.</dd>
plemented using a proxy).</t> <dt>Cons:</dt>
<dd>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 REF
USED
response is not clearly defined (see <xref target="response-rcodes"></xref>)
. Currently,
none of the major open-source implementations of a DNS authoritative server
offer an option for different response
policies in different transports (but such functionality could potentially b
e implemented
using a proxy).</dd>
</dl>
<section anchor="sni-based-response-policies"><name>SNI based response policies< <section anchor="sni-based-response-policies">
/name> <name>SNI-Based Response Policies</name>
<t>In a similar fashion, XoT servers might use the presence of an SNI in the <t>In a similar fashion, XoT servers might use the presence of an SNI in the
client hello to determine which response policy to initially apply to the TLS Client Hello to determine which response policy to initially apply to the TLS
connections.</t> connections.</t>
<t>Pros: This has to potential to allow a clean distinction between a XoT servic <dl newline="false" spacing="normal">
e <dt>Pros:</dt>
and any future DoT based service for answering recursive queries.</t> <dd>This has the potential to allow a clean distinction between a XoT servic
<t>Cons: As above.</t> e
and any future DoT-based service for answering recursive queries.</dd>
<dt>Cons:</dt>
<dd>As above.</dd>
</dl>
</section> </section>
</section> </section>
</section> </section>
</back> <section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>The authors thank <contact fullname="Tony Finch"/>, <contact fullname="Benn
o
Overeinder"/>, <contact fullname="Shumon Huque"/>,
<contact fullname="Tim Wicinski"/>, and many other members of DPRIVE for revie
w and
discussions.</t>
<t>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">
<name>Contributors</name>
<t>Significant contributions to the document were made by:</t>
<contact fullname="Han Zhang">
<organization>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>
</back>
</rfc> </rfc>
 End of changes. 131 change blocks. 
1451 lines changed or deleted 1546 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/