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 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
or - mmark.miek.nl" --> nsus="true" docName="draft-ietf-dprive-xfr-over-tls-12" indexInclude="true" ipr=
<rfc version="3" ipr="trust200902" docName="draft-ietf-dprive-xfr-over-tls-12" s "trust200902" number="9103" prepTime="2021-08-23T21:11:13" scripts="Common,Latin
ubmissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/20 " sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="
01/XInclude" updates="1995, 5936, 7766" consensus="true"> true" updates="1995, 5936, 7766" xml:lang="en">
<link href="https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls-12
<front> " rel="prev"/>
<title abbrev="XFR-over-TLS">DNS Zone Transfer-over-TLS</title><seriesInfo value <link href="https://dx.doi.org/10.17487/rfc9103" rel="alternate"/>
="draft-ietf-dprive-xfr-over-tls-12" stream="IETF" status="standard" name="Inter <link href="urn:issn:2070-1721" rel="alternate"/>
net-Draft"></seriesInfo> <front>
<author initials="W." surname="Toorop" fullname="Willem Toorop"><organization>NL <title abbrev="XFR over TLS">DNS Zone Transfer over TLS</title>
net Labs</organization><address><postal><street></street> <seriesInfo name="RFC" value="9103" stream="IETF"/>
<street>Science Park 400</street> <author initials="W." surname="Toorop" fullname="Willem Toorop">
<city>Amsterdam</city> <organization showOnFrontPage="true">NLnet Labs</organization>
<code>1098 XH</code> <address>
<country>The Netherlands</country> <postal>
</postal><email>willem@nlnetlabs.nl</email> <street>Science Park 400</street>
</address></author> <city>Amsterdam</city>
<author initials="S." surname="Dickinson" fullname="Sara Dickinson"><organizatio <code>1098 XH</code>
n>Sinodun IT</organization><address><postal><street></street> <country>Netherlands</country>
<street>Magdalen Centre</street> </postal>
<street>Oxford Science Park</street> <email>willem@nlnetlabs.nl</email>
<city>Oxford</city> </address>
<code>OX4 4GA</code> </author>
<country>United Kingdom</country> <author initials="S." surname="Dickinson" fullname="Sara Dickinson">
</postal><email>sara@sinodun.com</email> <organization showOnFrontPage="true">Sinodun IT</organization>
</address></author> <address>
<author initials="S." surname="Sahib" fullname="Shivan Sahib"><organization>Brav <postal>
e Software</organization><address><postal><street></street> <extaddr>Magdalen Centre</extaddr>
<city>Vancouver, BC</city> <street>Oxford Science Park</street>
<country>Canada</country> <city>Oxford</city>
</postal><email>shivankaulsahib@gmail.com</email> <code>OX4 4GA</code>
</address></author> <country>United Kingdom</country>
<author initials="P." surname="Aras" fullname="Pallavi Aras"><organization>Sales </postal>
force</organization><address><postal><street></street> <email>sara@sinodun.com</email>
<city>Herndon, VA</city> </address>
<country>United States</country> </author>
</postal><email>paras@salesforce.com</email> <author initials="S." surname="Sahib" fullname="Shivan Sahib">
</address></author> <organization showOnFrontPage="true">Brave Software</organization>
<author initials="A." surname="Mankin" fullname="Allison Mankin"><organization>S <address>
alesforce</organization><address><postal><street></street> <postal>
<city>Herndon, VA</city> <city>Vancouver</city>
<country>United States</country> <region>BC</region>
</postal><email>allison.mankin@gmail.com</email> <country>Canada</country>
</address></author> </postal>
<date year="2021" month="May" day="26"></date> <email>shivankaulsahib@gmail.com</email>
<area>Internet</area> </address>
<workgroup>dprive</workgroup> </author>
<keyword>DNS</keyword> <author initials="P." surname="Aras" fullname="Pallavi Aras">
<keyword>operations</keyword> <organization showOnFrontPage="true">Salesforce</organization>
<keyword>privacy</keyword> <address>
<postal>
<abstract> <city>Herndon</city>
<t>DNS zone transfers are transmitted in clear text, which gives attackers the <region>VA</region>
opportunity to collect the content of a zone by eavesdropping on network <country>United States of America</country>
connections. The DNS Transaction Signature (TSIG) mechanism is specified to </postal>
restrict direct zone transfer to authorized clients only, but it does not add <email>paras@salesforce.com</email>
confidentiality. This document specifies the use of TLS, rather than clear </address>
text, to prevent zone content collection via passive monitoring of zone </author>
transfers: XFR-over-TLS (XoT). Additionally, this specification updates RFC1995 <author initials="A." surname="Mankin" fullname="Allison Mankin">
and RFC5936 with respect to efficient use of TCP connections, and RFC7766 with <organization showOnFrontPage="true">Salesforce</organization>
respect to the recommended number of connections between a client and server <address>
for each transport.</t> <postal>
</abstract> <city>Herndon</city>
<region>VA</region>
</front> <country>United States of America</country>
</postal>
<middle> <email>allison.mankin@gmail.com</email>
</address>
<section anchor="introduction"><name>Introduction</name> </author>
<t>DNS has a number of privacy vulnerabilities, as discussed in detail in <date month="08" year="2021"/>
<xref target="I-D.ietf-dprive-rfc7626-bis"></xref>. Stub client to recursive res <area>Internet</area>
olver query privacy has received the <workgroup>dprive</workgroup>
most attention to date, with standards track documents for both DNS-over-TLS <keyword>DNS</keyword>
(DoT) <xref target="RFC7858"></xref> and DNS-over-HTTPS (DoH) <xref target="RFC8 <keyword>operations</keyword>
484"></xref>, and a proposal for <keyword>privacy</keyword>
DNS-over-QUIC <xref target="I-D.ietf-dprive-dnsoquic"></xref>. There is ongoing <abstract pn="section-abstract">
work on DNS privacy <t indent="0" pn="section-abstract-1">DNS zone transfers are transmitted i
requirements for exchanges between recursive resolvers and authoritative n cleartext, which gives attackers the
servers <xref target="I-D.ietf-dprive-phase2-requirements"></xref> and some sugg opportunity to collect the content of a zone by eavesdropping on network
estions for how connections. The DNS Transaction Signature (TSIG) mechanism is specified to
signaling of DoT support by authoritative nameservers might work. However, there restrict direct zone transfer to authorized clients only, but it does not add
is currently no RFC confidentiality. This document specifies the use of TLS, rather than cleartext
that specifically defines recursive to authoritative DNS-over-TLS (ADoT).</t> ,
<t><xref target="I-D.ietf-dprive-rfc7626-bis"></xref> established that stub clie to prevent zone content collection via passive monitoring of zone
nt DNS query transfers: XFR over TLS (XoT). Additionally, this specification updates RFC 19
transactions are not public and needed protection, but on zone transfer 95
<xref target="RFC1995"></xref> <xref target="RFC5936"></xref> it says only:</t> and RFC 5936 with respect to efficient use of TCP connections and RFC 7766 wit
h
<artwork>&quot;Privacy risks for the holder of a zone (the risk that someone respect to the recommended number of connections between a client and server
gets the data) are discussed in [RFC5936] and [RFC5155].&quot; for each transport.</t>
</artwork> </abstract>
<t>In what way is exposing the full contents of a zone a privacy risk? The <boilerplate>
contents of the zone could include information such as names of persons used in <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
names of hosts. Best practice is not to use personal information for domain "exclude" pn="section-boilerplate.1">
names, but many such domain names exist. The contents of the zone could also <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
include references to locations that allow inference about location information >
of the individuals associated with the zone's organization. It could also <t indent="0" pn="section-boilerplate.1-1">
include references to other organizations. Examples of this could be:</t> This is an Internet Standards Track document.
</t>
<ul> <t indent="0" pn="section-boilerplate.1-2">
<li>Person-laptop.example.org</li> This document is a product of the Internet Engineering Task Force
<li>MX-for-Location.example.org</li> (IETF). It represents the consensus of the IETF community. It has
<li>Service-tenant-from-another-org.example.org</li> received public review and has been approved for publication by
</ul> the Internet Engineering Steering Group (IESG). Further
<t>Additionally, the full zone contents expose all the IP addresses of endpoints information on Internet Standards is available in Section 2 of
held in the DNS records which can make reconnaissance and attack targeting easie RFC 7841.
r, particularly for </t>
IPv6 addresses or private networks. There may also be regulatory, policy or othe <t indent="0" pn="section-boilerplate.1-3">
r reasons why the Information about the current status of this document, any
zone contents in full must be treated as private.</t> errata, and how to provide feedback on it may be obtained at
<t>Neither of the RFCs mentioned in <xref target="I-D.ietf-dprive-rfc7626-bis">< <eref target="https://www.rfc-editor.org/info/rfc9103" brackets="non
/xref> e"/>.
contemplates the risk that someone gets the data through eavesdropping on </t>
network connections, only via enumeration or unauthorized transfer as described </section>
in the following paragraphs.</t> <section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
<t>Zone enumeration is trivially possible for DNSSEC zones which use NSEC; i.e. ude" pn="section-boilerplate.2">
queries for the authenticated denial of existence records allow a client to <name slugifiedName="name-copyright-notice">Copyright Notice</name>
walk through the entire zone contents. <xref target="RFC5155"></xref> specifies <t indent="0" pn="section-boilerplate.2-1">
NSEC3, a mechanism Copyright (c) 2021 IETF Trust and the persons identified as the
to provide measures against zone enumeration for DNSSEC signed zones (a goal document authors. All rights reserved.
was to make it as hard to enumerate a DNSSEC signed zone as an unsigned zone). </t>
Whilst this is widely used, it has been demonstrated that zone walking is <t indent="0" pn="section-boilerplate.2-2">
possible for precomputed NSEC3 using attacks such as those described in This document is subject to BCP 78 and the IETF Trust's Legal
<xref target="NSEC3-attacks"></xref>. This prompted further work on an alternati Provisions Relating to IETF Documents
ve (<eref target="https://trustee.ietf.org/license-info" brackets="none
mechanism for DNSSEC authenticated denial of existence - NSEC5 "/>) in effect on the date of
<xref target="I-D.vcelak-nsec5"></xref> - however questions remain over the prac publication of this document. Please review these documents
ticality of this carefully, as they describe your rights and restrictions with
mechanism.</t> respect to this document. Code Components extracted from this
<t><xref target="RFC5155"></xref> does not address data obtained outside zone en document must include Simplified BSD License text as described in
umeration (nor does Section 4.e of the Trust Legal Provisions and are provided without
<xref target="I-D.vcelak-nsec5"></xref>). Preventing eavesdropping of zone trans warranty as described in the Simplified BSD License.
fers (this document) </t>
is orthogonal to preventing zone enumeration, though they aim to protect the </section>
same information.</t> </boilerplate>
<t><xref target="RFC5936"></xref> specifies using TSIG <xref target="RFC8945"></ <toc>
xref> for authorization of the clients <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
of a zone transfer and for data integrity, but does not express any need for n="section-toc.1">
confidentiality, and TSIG does not offer encryption.</t> <name slugifiedName="name-table-of-contents">Table of Contents</name>
<t>Section 8 of the NIST guide on 'Secure Domain Name System (DNS) Deployment' <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
<xref target="nist-guide"></xref> discusses restricting access for zone transfer c.1-1">
s using ACLs and <li pn="section-toc.1-1.1">
TSIG in more detail. It also discusses the possibility that specific deployments <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
might choose to use a lower level network layer to protect zone transfers, e.g., ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
IPSec.</t> derivedContent="" format="title" sectionFormat="of" target="name-introduction">
<t>It is noted that in all the common open source implementations Introduction</xref></t>
such ACLs are applied on a per query basis (at the time of writing). Since reque </li>
sts typically occur on <li pn="section-toc.1-1.2">
TCP connections authoritatives must therefore accept any TCP connection and <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
then handling the authentication of each zone transfer (XFR) request individuall ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
y.</t> derivedContent="" format="title" sectionFormat="of" target="name-terminology">T
<t>Because both AXFR (authoritative transfer) and IXFR (incremental transfer) ar erminology</xref></t>
e typically carried out over TCP </li>
from authoritative DNS protocol implementations, encrypting zone transfers <li pn="section-toc.1-1.3">
using TLS <xref target="RFC8499"></xref>, based closely on DoT <xref target="RFC <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
7858"></xref>, seems like a simple step forward. ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref
This document specifies how to use TLS (1.3 or later) as a transport to prevent derivedContent="" format="title" sectionFormat="of" target="name-threat-model">
zone Threat Model</xref></t>
collection from zone transfers.</t> </li>
<t>This document also updates the previous specifications for zone transfers to <li pn="section-toc.1-1.4">
clarify and extend them, mainly with respect to TCP usage:</t> <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
<ul> ormat="title" sectionFormat="of" target="name-design-considerations-for-x">Desig
<li><eref target="IXFR">RFC1995</eref> and <eref target="AXFR">RFC5936</eref> ar n Considerations for XoT</xref></t>
e both updated to add further </li>
specification on efficient use of TCP connections</li> <li pn="section-toc.1-1.5">
<li>Section 6.2.2 of <eref target="DNS Transport over TCP - Implementation <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
Requirements">RFC7766</eref> is updated with a new recommendation about the numb at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
er of ormat="title" sectionFormat="of" target="name-connection-and-data-flows-i">Conne
connections between a client and server for each transport.</li> ction and Data Flows in Existing XFR Mechanisms</xref></t>
</ul> <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
</section> n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<section anchor="document-work-via-github"><name>Document work via GitHub</name> <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
<t>[THIS SECTION TO BE REMOVED BEFORE PUBLICATION] The Github repository for thi "5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
s Content="" format="title" sectionFormat="of" target="name-axfr-mechanism">AXFR M
document is at <eref target="https://github.com/hanzhang0116/hzpa-dprive-xfr-ove echanism</xref></t>
r-tls">https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls</eref>. </li>
Proposed text and editorial changes are very much welcomed there, but any <li pn="section-toc.1-1.5.2.2">
functional changes should always first be discussed on the IETF DPRIVE WG (dns-p <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
rivacy) mailing list.</t> "5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
</section> Content="" format="title" sectionFormat="of" target="name-ixfr-mechanism">IXFR M
echanism</xref></t>
<section anchor="terminology"><name>Terminology</name> </li>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, & <li pn="section-toc.1-1.5.2.3">
quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent=
&quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, &q "5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derived
uot;MAY&quot;, and &quot;OPTIONAL&quot; in this Content="" format="title" sectionFormat="of" target="name-data-leakage-of-notify
document are to be interpreted as described in BCP 14 <xref target="RFC2119"></x -and-">Data Leakage of NOTIFY and SOA Message Exchanges</xref></t>
ref> <ul bare="true" empty="true" indent="2" spacing="compact" pn="se
<xref target="RFC8174"></xref> when, and only when, they appear in all capitals, ction-toc.1-1.5.2.3.2">
as shown here.</t> <li pn="section-toc.1-1.5.2.3.2.1">
<t>Privacy terminology is as described in Section 3 of <xref target="RFC6973"></ <t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref derived
xref>.</t> Content="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>.  <
<t>DNS terminology is as described in <xref target="RFC8499"></xref>. Note that xref derivedContent="" format="title" sectionFormat="of" target="name-notify">NO
as in <xref target="RFC8499"></xref>, the TIFY</xref></t>
terms 'primary' and 'secondary' are used for two servers engaged in zone transfe </li>
rs.</t> <li pn="section-toc.1-1.5.2.3.2.2">
<t>DoT: DNS-over-TLS as specified in <xref target="RFC7858"></xref></t> <t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref derived
<t>XFR-over-TCP: Used to mean both IXFR-over-TCP <xref target="RFC1995"></xref> Content="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>.  <
and AXFR-over-TCP <xref target="RFC5936"></xref>.</t> xref derivedContent="" format="title" sectionFormat="of" target="name-soa">SOA</
<t>XoT: XFR-over-TLS mechanisms as specified in this document which apply to bot xref></t>
h AXFR-over-TLS and IXFR-over-TLS</t> </li>
<t>AXoT: AXFR-over-TLS</t> </ul>
<t>IXoT: IXFR over-TLS</t> </li>
</section> </ul>
</li>
<section anchor="threat-model"><name>Threat Model</name> <li pn="section-toc.1-1.6">
<t>The threat model considered here is one where the current contents and size o <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
f the zone are considered at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
sensitive and should be protected during transfer.</t> ormat="title" sectionFormat="of" target="name-updates-to-existing-specifi">Updat
<t>The threat model does not, however, consider the existence of a zone, the act es to Existing Specifications</xref></t>
of <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
zone transfer between two entities, nor the identities of the nameservers n-toc.1-1.6.2">
hosting a zone (including both those acting as hidden primaries/secondaries <li pn="section-toc.1-1.6.2.1">
or directly serving the zone) as sensitive information. The proposed mechanism <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
does not attempt to obscure such information. The reasons for this include:</t> "6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-update-to-rfc-1995-for
<ul> -ixfr">Update to RFC 1995 for IXFR over TCP</xref></t>
<li>much of this information can be obtained by various methods, including activ </li>
e scanning of the DNS</li> <li pn="section-toc.1-1.6.2.2">
<li>an attacker who can monitor network traffic can relatively easily infer rela <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
tions between "6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
nameservers simply from traffic patterns, even when some or all of the traffic i Content="" format="title" sectionFormat="of" target="name-update-to-rfc-5936-for
s encrypted -axfr">Update to RFC 5936 for AXFR over TCP</xref></t>
(in terms of current deployments)</li> </li>
</ul> <li pn="section-toc.1-1.6.2.3">
<t>The model does not consider attacks on the mechanisms that trigger a zone tra <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent=
nsfer, e.g., NOTIFY messages.</t> "6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derived
<t>It is noted that simply using XoT will indicate a desire by the zone owner th Content="" format="title" sectionFormat="of" target="name-updates-to-rfcs-1995-a
at the contents of the zone nd-59">Updates to RFCs 1995 and 5936 for XFR over TCP</xref></t>
remain confidential and so could be subject to blocking (e.g., via blocking of p <ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ort 853) if an attacker had ction-toc.1-1.6.2.3.2">
such capabilities. However this threat is likely true of any such mechanism that <li pn="section-toc.1-1.6.2.3.2.1">
attempts to encrypt data <t indent="0" pn="section-toc.1-1.6.2.3.2.1.1"><xref derived
passed between nameservers, e.g., IPsec.</t> Content="6.3.1" format="counter" sectionFormat="of" target="section-6.3.1"/>.  <
</section> xref derivedContent="" format="title" sectionFormat="of" target="name-connection
-reuse">Connection Reuse</xref></t>
<section anchor="design-considerations-for-xot"><name>Design Considerations for </li>
XoT</name> <li pn="section-toc.1-1.6.2.3.2.2">
<t>The following principles were considered in the design for XoT:</t> <t indent="0" pn="section-toc.1-1.6.2.3.2.2.1"><xref derived
Content="6.3.2" format="counter" sectionFormat="of" target="section-6.3.2"/>.  <
<ul> xref derivedContent="" format="title" sectionFormat="of" target="name-axfrs-and-
<li><t>Confidentiality. Clearly using an encrypted transport for zone transfers ixfrs-on-the-same">AXFRs and IXFRs on the Same Connection</xref></t>
will </li>
defeat zone content leakage that can occur via passive surveillance.</t> <li pn="section-toc.1-1.6.2.3.2.3">
</li> <t indent="0" pn="section-toc.1-1.6.2.3.2.3.1"><xref derived
<li><t>Authentication. Use of single or mutual TLS (mTLS) authentication (in com Content="6.3.3" format="counter" sectionFormat="of" target="section-6.3.3"/>.  <
bination xref derivedContent="" format="title" sectionFormat="of" target="name-xfr-limits
with access control lists (ACLs)) can complement and potentially be an alternati ">XFR Limits</xref></t>
ve to TSIG.</t> </li>
</li> <li pn="section-toc.1-1.6.2.3.2.4">
<li><t>Performance.</t> <t indent="0" pn="section-toc.1-1.6.2.3.2.4.1"><xref derived
Content="6.3.4" format="counter" sectionFormat="of" target="section-6.3.4"/>.  <
<ul> xref derivedContent="" format="title" sectionFormat="of" target="name-the-edns-t
<li>Existing AXFR and IXFR mechanisms have the burden of backwards cp-keepalive-edns">The edns-tcp-keepalive EDNS(0) Option</xref></t>
compatibility with older implementations based on the original specifications </li>
in <xref target="RFC1034"></xref> and <xref target="RFC1035"></xref>. For exampl <li pn="section-toc.1-1.6.2.3.2.5">
e, some older AXFR servers don’t <t indent="0" pn="section-toc.1-1.6.2.3.2.5.1"><xref derived
support using a TCP connection for multiple AXFR sessions or XFRs of different Content="6.3.5" format="counter" sectionFormat="of" target="section-6.3.5"/>.  <
zones because they have not been updated to follow the guidance in <xref target= xref derivedContent="" format="title" sectionFormat="of" target="name-backwards-
"RFC5936"></xref>. compatibility">Backwards Compatibility</xref></t>
Any implementation of XoT would obviously be required to </li>
implement optimized and interoperable transfers as described in <xref target="RF </ul>
C5936"></xref>, </li>
e.g., transfer of multiple zones over one connection.</li> <li pn="section-toc.1-1.6.2.4">
<li>Current usage of TCP for IXFR is sub-optimal in some cases i.e. <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent=
connections are frequently closed after a single IXFR.</li> "6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derived
</ul></li> Content="" format="title" sectionFormat="of" target="name-update-to-rfc-7766">Up
</ul> date to RFC 7766</xref></t>
</section> </li>
</ul>
<section anchor="connection-and-data-flows-in-existing-xfr-mechanisms"><name>Con </li>
nection and Data Flows in Existing XFR Mechanisms</name> <li pn="section-toc.1-1.7">
<t>The original specification for zone transfers in <xref target="RFC1034"></xre <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
f> and <xref target="RFC1035"></xref> was at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
based on a polling mechanism: a secondary performed a periodic query for the SOA ormat="title" sectionFormat="of" target="name-xot-specification">XoT Specificati
(start of zone authority) record (based on</xref></t>
on the refresh timer) to determine if an AXFR was required.</t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
<t><xref target="RFC1995"></xref> and <xref target="RFC1996"></xref> introduced n-toc.1-1.7.2">
the concepts of IXFR and NOTIFY <li pn="section-toc.1-1.7.2.1">
respectively, to provide for prompt propagation of zone updates. This has <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
largely replaced AXFR where possible, particularly for dynamically updated "7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
zones.</t> Content="" format="title" sectionFormat="of" target="name-connection-establishme
<t><xref target="RFC5936"></xref> subsequently redefined the specification of AX nt">Connection Establishment</xref></t>
FR to improve </li>
performance and interoperability.</t> <li pn="section-toc.1-1.7.2.2">
<t>In this document we use the term &quot;XFR mechanism&quot; to describe the en <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
tire set of "7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
message exchanges between a secondary and a primary that concludes in a Content="" format="title" sectionFormat="of" target="name-tls-versions">TLS Vers
successful AXFR or IXFR request/response. This set may or may not include</t> ions</xref></t>
</li>
<ul> <li pn="section-toc.1-1.7.2.3">
<li>NOTIFY messages</li> <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent=
<li>SOA queries</li> "7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derived
<li>Fallback from IXFR to AXFR</li> Content="" format="title" sectionFormat="of" target="name-port-selection">Port S
<li>Fallback from IXFR-over-UDP to IXFR-over-TCP</li> election</xref></t>
</ul> </li>
<t>The term is used to encompass the range of permutations that are possible and <li pn="section-toc.1-1.7.2.4">
is useful to distinguish the 'XFR mechanism' from a single XFR <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent=
request/response exchange.</t> "7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-high-level-xot-descrip
<section anchor="axfr-mechanism"><name>AXFR Mechanism</name> tions">High-Level XoT Descriptions</xref></t>
<t>The figure below provides an outline of an AXFR mechanism including NOTIFYs.< </li>
/t> <li pn="section-toc.1-1.7.2.5">
<t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent=
<artwork> Secondary Primary "7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-xot-transfers">XoT Tra
nsfers</xref></t>
</li>
<li pn="section-toc.1-1.7.2.6">
<t indent="0" pn="section-toc.1-1.7.2.6.1"><xref derivedContent=
"7.6" format="counter" sectionFormat="of" target="section-7.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-xot-connections">XoT C
onnections</xref></t>
</li>
<li pn="section-toc.1-1.7.2.7">
<t indent="0" pn="section-toc.1-1.7.2.7.1"><xref derivedContent=
"7.7" format="counter" sectionFormat="of" target="section-7.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-xot-vs-adot">XoT vs. A
DoT</xref></t>
</li>
<li pn="section-toc.1-1.7.2.8">
<t indent="0" pn="section-toc.1-1.7.2.8.1"><xref derivedContent=
"7.8" format="counter" sectionFormat="of" target="section-7.8"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-response-rcodes">Respo
nse RCODES</xref></t>
</li>
<li pn="section-toc.1-1.7.2.9">
<t indent="0" pn="section-toc.1-1.7.2.9.1"><xref derivedContent=
"7.9" format="counter" sectionFormat="of" target="section-7.9"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-axot-specifics">AXoT S
pecifics</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.7.2.9.2">
<li pn="section-toc.1-1.7.2.9.2.1">
<t indent="0" pn="section-toc.1-1.7.2.9.2.1.1"><xref derived
Content="7.9.1" format="counter" sectionFormat="of" target="section-7.9.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-padding-ax
ot-responses">Padding AXoT Responses</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7.2.10">
<t indent="0" pn="section-toc.1-1.7.2.10.1"><xref derivedContent
="7.10" format="counter" sectionFormat="of" target="section-7.10"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-ixot-specifics">IXoT
Specifics</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.7.2.10.2">
<li pn="section-toc.1-1.7.2.10.2.1">
<t indent="0" pn="section-toc.1-1.7.2.10.2.1.1"><xref derive
dContent="7.10.1" format="counter" sectionFormat="of" target="section-7.10.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-condens
ation-of-responses">Condensation of Responses</xref></t>
</li>
<li pn="section-toc.1-1.7.2.10.2.2">
<t indent="0" pn="section-toc.1-1.7.2.10.2.2.1"><xref derive
dContent="7.10.2" format="counter" sectionFormat="of" target="section-7.10.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-fallbac
k-to-axfr">Fallback to AXFR</xref></t>
</li>
<li pn="section-toc.1-1.7.2.10.2.3">
<t indent="0" pn="section-toc.1-1.7.2.10.2.3.1"><xref derive
dContent="7.10.3" format="counter" sectionFormat="of" target="section-7.10.3"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-padding
-of-ixot-responses">Padding of IXoT Responses</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7.2.11">
<t indent="0" pn="section-toc.1-1.7.2.11.1"><xref derivedContent
="7.11" format="counter" sectionFormat="of" target="section-7.11"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-name-compression-and
-maximu">Name Compression and Maximum Payload Sizes</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-multi-primary-configuration">Multi
-primary Configurations</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-authentication-mechanisms">Authent
ication Mechanisms</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
"9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-tsig">TSIG</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2">
<t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent=
"9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-sig0">SIG(0)</xref></t
>
</li>
<li pn="section-toc.1-1.9.2.3">
<t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent=
"9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-tls">TLS</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.9.2.3.2">
<li pn="section-toc.1-1.9.2.3.2.1">
<t indent="0" pn="section-toc.1-1.9.2.3.2.1.1"><xref derived
Content="9.3.1" format="counter" sectionFormat="of" target="section-9.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-opportunis
tic-tls">Opportunistic TLS</xref></t>
</li>
<li pn="section-toc.1-1.9.2.3.2.2">
<t indent="0" pn="section-toc.1-1.9.2.3.2.2.1"><xref derived
Content="9.3.2" format="counter" sectionFormat="of" target="section-9.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-strict-tls
">Strict TLS</xref></t>
</li>
<li pn="section-toc.1-1.9.2.3.2.3">
<t indent="0" pn="section-toc.1-1.9.2.3.2.3.1"><xref derived
Content="9.3.3" format="counter" sectionFormat="of" target="section-9.3.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-mutual-tls
">Mutual TLS</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9.2.4">
<t indent="0" pn="section-toc.1-1.9.2.4.1"><xref derivedContent=
"9.4" format="counter" sectionFormat="of" target="section-9.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-ip-based-acl-on-the-pr
imary">IP-Based ACL on the Primary</xref></t>
</li>
<li pn="section-toc.1-1.9.2.5">
<t indent="0" pn="section-toc.1-1.9.2.5.1"><xref derivedContent=
"9.5" format="counter" sectionFormat="of" target="section-9.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-zonemd">ZONEMD</xref><
/t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-xot-authentication">XoT Authenti
cation</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-policies-for-both-axot-and-">Pol
icies for Both AXoT and IXoT</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-implementation-consideratio">Imp
lementation Considerations</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" fo
rmat="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-operational-considerations">Oper
ational Considerations</xref></t>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" fo
rmat="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
erations</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="15" fo
rmat="counter" sectionFormat="of" target="section-15"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-security-considerations">Securit
y Considerations</xref></t>
</li>
<li pn="section-toc.1-1.16">
<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="16" fo
rmat="counter" sectionFormat="of" target="section-16"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references"> References</xref></
t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.16.2">
<li pn="section-toc.1-1.16.2.1">
<t indent="0" pn="section-toc.1-1.16.2.1.1"><xref derivedContent
="16.1" format="counter" sectionFormat="of" target="section-16.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.16.2.2">
<t indent="0" pn="section-toc.1-1.16.2.2.1"><xref derivedContent
="16.2" format="counter" sectionFormat="of" target="section-16.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.17">
<t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-xot-server-conn
ection-handl">XoT Server Connection Handling</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.17.2">
<li pn="section-toc.1-1.17.2.1">
<t indent="0" pn="section-toc.1-1.17.2.1.1"><xref derivedContent
="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-listening-on
ly-on-a-specifi">Listening Only on a Specific IP Address for TLS</xref></t>
</li>
<li pn="section-toc.1-1.17.2.2">
<t indent="0" pn="section-toc.1-1.17.2.2.1"><xref derivedContent
="A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-client-speci
fic-tls-accepta">Client-Specific TLS Acceptance</xref></t>
</li>
<li pn="section-toc.1-1.17.2.3">
<t indent="0" pn="section-toc.1-1.17.2.3.1"><xref derivedContent
="A.3" format="counter" sectionFormat="of" target="section-appendix.a.3"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-sni-based-tl
s-acceptance">SNI-Based TLS Acceptance</xref></t>
</li>
<li pn="section-toc.1-1.17.2.4">
<t indent="0" pn="section-toc.1-1.17.2.4.1"><xref derivedContent
="A.4" format="counter" sectionFormat="of" target="section-appendix.a.4"/>.  <xr
ef derivedContent="" format="title" sectionFormat="of" target="name-transport-sp
ecific-response">Transport-Specific Response Policies</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.17.2.4.2">
<li pn="section-toc.1-1.17.2.4.2.1">
<t indent="0" pn="section-toc.1-1.17.2.4.2.1.1"><xref derive
dContent="A.4.1" format="counter" sectionFormat="of" target="section-appendix.a.
4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-
sni-based-response-policies">SNI-Based Response Policies</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.18">
<t indent="0" pn="section-toc.1-1.18.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
nts</xref></t>
</li>
<li pn="section-toc.1-1.19">
<t indent="0" pn="section-toc.1-1.19.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-contributors">Contributors</xre
f></t>
</li>
<li pn="section-toc.1-1.20">
<t indent="0" pn="section-toc.1-1.20.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section anchor="introduction" numbered="true" removeInRFC="false" toc="incl
ude" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">DNS has a number of privacy vulnerabilities
, as discussed in detail in
<xref target="RFC9076" format="default" sectionFormat="of" derivedContent="RFC
9076"/>. Query privacy between stub resolvers and recursive resolvers has receiv
ed
the most attention to date, with Standards Track documents for both DNS over T
LS
(DoT) <xref target="RFC7858" format="default" sectionFormat="of" derivedConten
t="RFC7858"/> and DNS over HTTPS (DoH) <xref target="RFC8484" format="default" s
ectionFormat="of" derivedContent="RFC8484"/>
and a proposal for
DNS over QUIC <xref target="I-D.ietf-dprive-dnsoquic" format="default" section
Format="of" derivedContent="DPRIVE-DNSOQUIC"/>. There is ongoing work on DNS
privacy
requirements for exchanges between recursive resolvers and authoritative
servers and some suggestions for
how signaling of DoT support by authoritative name servers might work. However
, there is
currently no RFC that specifically defines recursive-to-authoritative DNS over
TLS
(ADoT).</t>
<t indent="0" pn="section-1-2"><xref target="RFC9076" format="default" sec
tionFormat="of" derivedContent="RFC9076"/> establishes that a stub resolver's DN
S query
transactions are not public and that they need protection, but, on zone transf
er
<xref target="RFC1995" format="default" sectionFormat="of" derivedContent="RFC
1995"/> <xref target="RFC5936" format="default" sectionFormat="of" derivedConten
t="RFC5936"/>, it says only:</t>
<blockquote pn="section-1-3">Privacy risks for the holder of a zone (the r
isk that someone
gets the data) are discussed in <xref target="RFC5155" format="default" sectio
nFormat="of" derivedContent="RFC5155"/> and <xref target="RFC5936" format="defau
lt" sectionFormat="of" derivedContent="RFC5936"/>.</blockquote>
<t indent="0" pn="section-1-4">In what way is exposing the full contents o
f a zone a privacy risk? The
contents of the zone could include information such as names of persons used i
n
names of hosts. Best practice is not to use personal information for domain
names, but many such domain names exist. The contents of the zone could also
include references to locations that allow inference about location informatio
n
of the individuals associated with the zone's organization. It could also
include references to other organizations. Examples of this could be:</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1-5
">
<li pn="section-1-5.1">Person-laptop.example.org</li>
<li pn="section-1-5.2">MX-for-Location.example.org</li>
<li pn="section-1-5.3">Service-tenant-from-another-org.example.org</li>
</ul>
<t indent="0" pn="section-1-6">Additionally, the full zone contents expose
all the IP addresses of endpoints
held in the DNS records, which can make reconnaissance and attack targeting ea
sier,
particularly
for IPv6 addresses or private networks. There may also be regulatory, policy,
or other
reasons why the zone contents in full must be treated as private.</t>
<t indent="0" pn="section-1-7">Neither of the RFCs mentioned in <xref targ
et="RFC9076" format="default" sectionFormat="of" derivedContent="RFC9076"/>
contemplate the risk that someone gets the data through eavesdropping on
network connections, only via enumeration or unauthorized transfer, as describ
ed
in the following paragraphs.</t>
<t indent="0" pn="section-1-8">Zone enumeration is trivially possible for
DNSSEC zones that use NSEC, i.e.,
queries for the authenticated denial-of-existence records allow a client to
walk through the entire zone contents. <xref target="RFC5155" format="default"
sectionFormat="of" derivedContent="RFC5155"/> specifies NSEC3, a
mechanism to provide measures against zone enumeration for DNSSEC-signed zones
(a goal
was to make it as hard to enumerate a DNSSEC-signed zone as an unsigned zone).
Whilst this is widely used, it has been demonstrated that zone walking is
possible for precomputed NSEC3 using attacks, such as those described in
<xref target="NSEC3-attacks" format="default" sectionFormat="of" derivedConten
t="NSEC3-attacks"/>. This prompted further work on an alternative
mechanism for DNSSEC-authenticated denial of existence (NSEC5
<xref target="I-D.vcelak-nsec5" format="default" sectionFormat="of" derivedCon
tent="NSEC5"/>); however, questions remain over the practicality of
this mechanism.</t>
<t indent="0" pn="section-1-9"><xref target="RFC5155" format="default" sec
tionFormat="of" derivedContent="RFC5155"/> does not address data obtained outsid
e zone enumeration (nor
does <xref target="I-D.vcelak-nsec5" format="default" sectionFormat="of" deriv
edContent="NSEC5"/>). Preventing eavesdropping of zone transfers (as
described in this document) is orthogonal to preventing zone enumeration, thou
gh they aim to
protect the same information.</t>
<t indent="0" pn="section-1-10"><xref target="RFC5936" format="default" se
ctionFormat="of" derivedContent="RFC5936"/> specifies using TSIG <xref target="R
FC8945" format="default" sectionFormat="of" derivedContent="RFC8945"/> for
authorization of the clients
of a zone transfer and for data integrity but does not express any need for
confidentiality, and TSIG does not offer encryption.</t>
<t indent="0" pn="section-1-11">Section 8 of the NIST document "Secure Dom
ain Name System (DNS) Deployment Guide"
<xref target="NIST-GUIDE" format="default" sectionFormat="of" derivedContent="
NIST-GUIDE"/> discusses restricting access for zone transfers using
Access Control Lists (ACLs) and
TSIG in more detail. It also discusses the possibility that specific deploymen
ts
might choose to use a lower-level network layer to protect zone transfers, e.g
., IPsec.</t>
<t indent="0" pn="section-1-12">It is noted that in all the common open-so
urce implementations
such ACLs are applied on a per-query basis (at the time of writing). Since req
uests
typically occur on TCP connections, authoritative servers must therefore accep
t any TCP connection
and then handle the authentication of each zone transfer (XFR) request individ
ually.</t>
<t indent="0" pn="section-1-13">Because both AXFR (authoritative transfer)
and IXFR (incremental zone transfer) are
typically carried out over TCP
from authoritative DNS protocol implementations, encrypting zone transfers
using TLS <xref target="RFC8499" format="default" sectionFormat="of" derivedCo
ntent="RFC8499"/> -- based closely on DoT <xref target="RFC7858" format="default
" sectionFormat="of" derivedContent="RFC7858"/> -- seems like a simple step forw
ard.
This document specifies how to use TLS (1.3 or later) as a transport to preven
t zone
collection from zone transfers.</t>
<t indent="0" pn="section-1-14">This document also updates the previous sp
ecifications for zone transfers to
clarify and extend them, mainly with respect to TCP usage:</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1-1
5">
<li pn="section-1-15.1">
<xref target="RFC1995" format="default" sectionFormat="of" derivedCont
ent="RFC1995"/> (IXFR) and <xref target="RFC5936" format="default" sectionFormat
="of" derivedContent="RFC5936"/> (AXFR) are both updated to add further
specification on efficient use of TCP connections.</li>
<li pn="section-1-15.2">
<xref target="RFC7766" sectionFormat="of" section="6.2.2" format="defa
ult" derivedLink="https://rfc-editor.org/rfc/rfc7766#section-6.2.2" derivedConte
nt="RFC7766"/> ("DNS Transport 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 anchor="terminology" numbered="true" removeInRFC="false" toc="inclu
de" pn="section-2">
<name slugifiedName="name-terminology">Terminology</name>
<t indent="0" pn="section-2-1">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
OT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t indent="0" pn="section-2-2">Privacy terminology is as described in <xre
f target="RFC6973" sectionFormat="of" section="3" format="default" derivedLink="
https://rfc-editor.org/rfc/rfc6973#section-3" derivedContent="RFC6973"/>.</t>
<t indent="0" pn="section-2-3">DNS terminology is as described in <xref ta
rget="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>. N
ote that, as in
<xref target="RFC8499" format="default" sectionFormat="of" derivedContent
="RFC8499"/>, the
terms 'primary' and 'secondary' are used for two servers engaged in zone
transfers.</t>
<dl newline="false" spacing="normal" indent="7" pn="section-2-4">
<dt pn="section-2-4.1">DoT:</dt>
<dd pn="section-2-4.2">DNS over TLS, as specified in <xref target="RFC78
58" format="default" sectionFormat="of" derivedContent="RFC7858"/></dd>
<dt pn="section-2-4.3">XFR over TCP:</dt>
<dd pn="section-2-4.4">Used to mean both IXFR over TCP <xref target="RFC
1995" format="default" sectionFormat="of" derivedContent="RFC1995"/>
and AXFR over TCP <xref target="RFC5936" format="default" sectionFormat
="of" derivedContent="RFC5936"/></dd>
<dt pn="section-2-4.5">XoT:</dt>
<dd pn="section-2-4.6">XFR-over-TLS mechanisms, as specified in this doc
ument, which apply
to both AXFR over TLS and IXFR over TLS (XoT is pronounced 'zot' since
X here
stands for 'zone transfer')</dd>
<dt pn="section-2-4.7">AXoT:</dt>
<dd pn="section-2-4.8">AXFR over TLS</dd>
<dt pn="section-2-4.9">IXoT:</dt>
<dd pn="section-2-4.10">IXFR over TLS</dd>
</dl>
</section>
<section anchor="threat-model" numbered="true" removeInRFC="false" toc="incl
ude" pn="section-3">
<name slugifiedName="name-threat-model">Threat Model</name>
<t indent="0" pn="section-3-1">The threat model considered here is one whe
re the current contents and size of the zone are
considered sensitive and should be protected during transfer.</t>
<t indent="0" pn="section-3-2">The threat model does not, however, conside
r the existence of a zone, the act of
zone transfer between two entities, nor the identities of the name servers
hosting a zone (including both those acting as hidden primaries/secondaries
or directly serving the zone) as sensitive information. The proposed mechanism
does not attempt to obscure such information. The reasons for this include:</t
>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3-3
">
<li pn="section-3-3.1">much of this information can be obtained by vario
us methods,
including active scanning of the DNS, and</li>
<li pn="section-3-3.2">an attacker who can monitor network traffic can r
ather
easily infer relations between name servers simply from traffic
patterns, even when some or all of the traffic is encrypted
(in terms of current deployments).</li>
</ul>
<t indent="0" pn="section-3-4">The model does not consider attacks on the
mechanisms that trigger a zone transfer, e.g.,
NOTIFY messages.</t>
<t indent="0" pn="section-3-5">It is noted that simply using XoT will indi
cate a desire by the zone owner that the
contents of the zone remain confidential and so could be subject to blocking (
e.g., via
blocking of port 853) if an attacker had
such capabilities. However, 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 anchor="design-considerations-for-xot" numbered="true" removeInRFC=
"false" toc="include" pn="section-4">
<name slugifiedName="name-design-considerations-for-x">Design Consideratio
ns for XoT</name>
<t indent="0" pn="section-4-1">The following principles were considered in
the design for XoT:</t>
<dl newline="false" spacing="normal" indent="3" pn="section-4-2">
<dt pn="section-4-2.1">Confidentiality:</dt>
<dd pn="section-4-2.2">Clearly using an encrypted transport for zone tra
nsfers will
defeat zone content leakage that can occur via passive surveillance.</dd>
<dt pn="section-4-2.3">Authentication:</dt>
<dd pn="section-4-2.4">Use of single or mutual TLS (mTLS) authentication
(in combination
with ACLs) can complement and potentially be an
alternative to TSIG.</dd>
<dt pn="section-4-2.5">Performance:</dt>
<dd pn="section-4-2.6">
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section
-4-2.6.1">
<li pn="section-4-2.6.1.1">Existing AXFR and IXFR mechanisms have th
e burden of backwards
compatibility with older implementations based on the original specificat
ions
in <xref target="RFC1034" format="default" sectionFormat="of" derivedCont
ent="RFC1034"/> and <xref target="RFC1035" format="default" sectionFormat="of" d
erivedContent="RFC1035"/>. For example,
some older AXFR servers don't
support using a TCP connection for multiple AXFR sessions or XFRs of diff
erent
zones because they have not been updated to follow the guidance in <xref
target="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/>.
Any implementation of XoT would obviously be required to
implement optimized and interoperable transfers, as described in <xref ta
rget="RFC5936" format="default" sectionFormat="of" derivedContent="RFC5936"/>,
e.g., transfer of multiple zones over one connection.</li>
<li pn="section-4-2.6.1.2">Current usage of TCP for IXFR is suboptim
al in some cases, i.e.,
connections are frequently closed after a single IXFR.</li>
</ul>
</dd>
</dl>
</section>
<section anchor="connection-and-data-flows-in-existing-xfr-mechanisms" numbe
red="true" removeInRFC="false" toc="include" pn="section-5">
<name slugifiedName="name-connection-and-data-flows-i">Connection and Data
Flows in Existing XFR Mechanisms</name>
<t indent="0" pn="section-5-1">The original specification for zone transfe
rs in <xref target="RFC1034" format="default" sectionFormat="of" derivedContent=
"RFC1034"/> and <xref target="RFC1035" format="default" sectionFormat="of" deriv
edContent="RFC1035"/> was
based on a polling mechanism: a secondary performed a periodic query for the S
OA (start of
zone authority) record (based
on the refresh timer) to determine if an AXFR was required.</t>
<t indent="0" pn="section-5-2"><xref target="RFC1995" format="default" sec
tionFormat="of" derivedContent="RFC1995"/> and <xref target="RFC1996" format="de
fault" sectionFormat="of" derivedContent="RFC1996"/> introduced the concepts
of IXFR and NOTIFY,
respectively, to provide for prompt propagation of zone updates. This has
largely replaced AXFR where possible, particularly for dynamically updated
zones.</t>
<t indent="0" pn="section-5-3"><xref target="RFC5936" format="default" sec
tionFormat="of" derivedContent="RFC5936"/> subsequently redefined the specificat
ion of AXFR to improve
performance and interoperability.</t>
<t indent="0" pn="section-5-4">In this document, the term 'XFR mechanism'
is used to describe the entire set of
message exchanges between a secondary and a primary that concludes with a
successful AXFR or IXFR request/response. This set may or may not include:</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-5-5
">
<li pn="section-5-5.1">NOTIFY messages</li>
<li pn="section-5-5.2">SOA queries</li>
<li pn="section-5-5.3">Fallback from IXFR to AXFR</li>
<li pn="section-5-5.4">Fallback from IXFR over UDP to IXFR over TCP</li>
</ul>
<t indent="0" pn="section-5-6">The term is used to encompass the range of
permutations that are possible and
is useful to distinguish the 'XFR mechanism' from a single XFR
request/response exchange.</t>
<section anchor="axfr-mechanism" numbered="true" removeInRFC="false" toc="
include" pn="section-5.1">
<name slugifiedName="name-axfr-mechanism">AXFR Mechanism</name>
<t indent="0" pn="section-5.1-1">The figure below provides an outline of
an AXFR mechanism including NOTIFYs.</t>
<figure anchor="fig1" align="left" suppress-title="false" pn="figure-1">
<name slugifiedName="name-axfr-mechanism-2">AXFR Mechanism</name>
<artwork name="" type="" alt="" align="left" pn="section-5.1-2.1">
Secondary Primary
| NOTIFY | | NOTIFY |
| &lt;-------------------------------- | UDP | &lt;-------------------------------- | UDP
| --------------------------------&gt; | | --------------------------------&gt; |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------&gt; | UDP (or part of | --------------------------------&gt; | UDP (or part of
| &lt;-------------------------------- | a TCP session) | &lt;-------------------------------- | a TCP session)
skipping to change at line 269 skipping to change at line 577
| (Zone data) | | | (Zone data) | |
| | | | | |
| &lt;-------------------------------- | | TCP | &lt;-------------------------------- | | TCP
| AXFR Response 2 | | Session | AXFR Response 2 | | Session
| (Zone data) | | | (Zone data) | |
| | | | | |
| &lt;-------------------------------- | | | &lt;-------------------------------- | |
| AXFR Response 3 | | | AXFR Response 3 | |
| (Zone data) | --- | (Zone data) | ---
| | | |
Figure 1. AXFR Mechanism
</artwork> </artwork>
</figure>
<ol> <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-5.
<li><t>An AXFR is often (but not always) preceded by a NOTIFY (over UDP) from th 1-3">
e <li pn="section-5.1-3.1" derivedCounter="1.">An AXFR is often (but not always)
primary to the secondary. A secondary may also initiate an AXFR based on a preceded by a NOTIFY (over UDP) from the
refresh timer or scheduled/triggered zone maintenance.</t> primary to the secondary. A secondary may also initiate an AXFR based on a
</li> refresh timer or scheduled/triggered zone maintenance.</li>
<li><t>The secondary will normally (but not always) make a SOA query to the prim <li pn="section-5.1-3.2" derivedCounter="2.">The secondary will normal
ary ly (but not always) make an SOA query to the primary
to obtain the serial number of the zone held by the primary.</t> to obtain the serial number of the zone held by the primary.</li>
</li> <li pn="section-5.1-3.3" derivedCounter="3.">If the primary serial is
<li><t>If the primary serial is higher than the secondary's serial (using Serial higher than the secondary's serial (using Serial
Number Arithmetic <xref target="RFC1982"></xref>), the secondary makes an AXFR r Number Arithmetic <xref target="RFC1982" format="default" sectionFormat="of" d
equest (over TCP) erivedContent="RFC1982"/>), the secondary makes an AXFR request
to the primary after which the AXFR data flows in one or more AXFR responses on (over TCP)
the TCP connection. <xref target="RFC5936"></xref> defines this specific step as to the primary, after which the AXFR data flows in one or more AXFR responses
an 'AXFR session' on
i.e. as an AXFR query message and the sequence of AXFR response messages the TCP connection. <xref target="RFC5936" format="default" sectionFormat="of"
returned for it.</t> derivedContent="RFC5936"/> defines this specific step as an 'AXFR
</li> session',
</ol> i.e., as an AXFR query message and the sequence of AXFR response messages
<t><xref target="RFC5936"></xref> re-specified AXFR providing additional guidanc returned for it.</li>
e beyond that provided </ol>
in <xref target="RFC1034"></xref> and <xref target="RFC1035"></xref> and importa <t indent="0" pn="section-5.1-4"><xref target="RFC5936" format="default"
ntly specified that AXFR must use TCP sectionFormat="of" derivedContent="RFC5936"/> re-specified AXFR, providing addi
as the transport protocol.</t> tional guidance beyond that
<t>Additionally, sections 4.1, 4.1.1 and 4.1.2 of <xref target="RFC5936"></xref> provided in <xref target="RFC1034" format="default" sectionFormat="of" derivedCo
provide improved ntent="RFC1034"/> and <xref target="RFC1035" format="default" sectionFormat="of"
guidance for AXFR clients and servers with regard to re-use of TCP connections derivedContent="RFC1035"/> and importantly
for multiple AXFRs and AXFRs of different zones. However <xref target="RFC5936"> specified that AXFR must use TCP as the transport protocol.</t>
</xref> was <t indent="0" pn="section-5.1-5">Additionally, Sections <xref target="RF
C5936" section="4.1" sectionFormat="bare" format="default" derivedLink="https://
rfc-editor.org/rfc/rfc5936#section-4.1" derivedContent="RFC5936"/>, <xref target
="RFC5936" section="4.1.1" sectionFormat="bare" format="default" derivedLink="ht
tps://rfc-editor.org/rfc/rfc5936#section-4.1.1" derivedContent="RFC5936"/>, and
<xref target="RFC5936" section="4.1.2" sectionFormat="bare" format="default" der
ivedLink="https://rfc-editor.org/rfc/rfc5936#section-4.1.2" derivedContent="RFC5
936"/> of <xref target="RFC5936" format="default" sectionFormat="of" derivedCont
ent="RFC5936"/> provide improved
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"
format="default" sectionFormat="of" derivedContent="RFC5936"/> 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" numbered="true" removeInRFC="false" toc="
<section anchor="ixfr-mechanism"><name>IXFR Mechanism</name> include" pn="section-5.2">
<t>The figure below provides an outline of the IXFR mechanism including NOTIFYs. <name slugifiedName="name-ixfr-mechanism">IXFR Mechanism</name>
</t> <t indent="0" pn="section-5.2-1">The figure below provides an outline of
the IXFR mechanism including NOTIFYs.</t>
<artwork> Secondary Primary <figure anchor="fig2" align="left" suppress-title="false" pn="figure-2">
<name slugifiedName="name-ixfr-mechanism-2">IXFR Mechanism</name>
<artwork name="" type="" alt="" align="left" pn="section-5.2-2.1">
Secondary Primary
| NOTIFY | | NOTIFY |
| &lt;-------------------------------- | UDP | &lt;-------------------------------- | UDP
| --------------------------------&gt; | | --------------------------------&gt; |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------&gt; | UDP or TCP | --------------------------------&gt; | UDP or TCP
| &lt;-------------------------------- | | &lt;-------------------------------- |
skipping to change at line 333 skipping to change at line 639
| &lt;-------------------------------- | | &lt;-------------------------------- |
| IXFR Response | | IXFR Response |
| (Zone data) | | (Zone data) |
| | | |
| | --- | | ---
| IXFR Request | | | IXFR Request | |
| --------------------------------&gt; | | Retry over | --------------------------------&gt; | | Retry over
| &lt;-------------------------------- | | TCP if | &lt;-------------------------------- | | TCP if
| IXFR Response | | required | IXFR Response | | required
| (Zone data) | --- | (Zone data) | ---
Figure 2. IXFR Mechanism
</artwork> </artwork>
</figure>
<ol> <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-5.
<li><t>An IXFR is normally (but not always) preceded by a NOTIFY (over UDP) from 2-3">
the <li pn="section-5.2-3.1" derivedCounter="1.">An IXFR is normally (but not alwa
primary to the secondary. A secondary may also initiate an IXFR based on a ys) preceded by a NOTIFY (over UDP) from the
refresh timer or scheduled/triggered zone maintenance.</t> primary to the secondary. A secondary may also initiate an IXFR based on a
</li> refresh timer or scheduled/triggered zone maintenance.</li>
<li><t>The secondary will normally (but not always) make a SOA query to the prim <li pn="section-5.2-3.2" derivedCounter="2.">The secondary will normal
ary ly (but not always) make an SOA query to the primary
to obtain the serial number of the zone held by the primary.</t> to obtain the serial number of the zone held by the primary.</li>
</li> <li pn="section-5.2-3.3" derivedCounter="3.">If the primary serial is
<li><t>If the primary serial is higher than the secondaries serial (using Serial higher than the secondary's serial (using Serial
Number Arithmetic <xref target="RFC1982"></xref>), the secondary makes an IXFR r Number Arithmetic <xref target="RFC1982" format="default" sectionFormat="of" d
equest to the erivedContent="RFC1982"/>), the secondary makes an IXFR request to
primary after which the primary sends an IXFR response.</t> the primary, after which the primary sends an IXFR response.</li>
</li> </ol>
</ol> <t indent="0" pn="section-5.2-4"><xref target="RFC1995" format="default"
<t><xref target="RFC1995"></xref> specifies that Incremental Transfer may use UD sectionFormat="of" derivedContent="RFC1995"/> specifies that IXFR may use UDP i
P if the entire IXFR f 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 pn="section-5.2-5">Thus, a client should first make an IXFR
<artwork>&quot;Thus, a client should first make an IXFR query using UDP.&quot; query using UDP.</blockquote>
</artwork> <t indent="0" pn="section-5.2-6">So there may be a fourth step above whe
<t>So there may be a fourth step above where the client falls back to IXFR-over- re 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 indent="0" pn="section-5.2-7">However, it is noted that most of the w
r idely used open-source implementations of authoritative name servers
implementations (including both <xref target="BIND"></xref> and <xref target="NS (including both <xref target="BIND" format="default" sectionFormat="of" derivedC
D"></xref>) do IXFR using TCP by default ontent="BIND"/> and <xref target="NSD" format="default" sectionFormat="of" deriv
edContent="NSD"/>) do IXFR 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" numbere
<section anchor="data-leakage-of-notify-and-soa-message-exchanges"><name>Data Le d="true" removeInRFC="false" toc="include" pn="section-5.3">
akage of NOTIFY and SOA Message Exchanges</name> <name slugifiedName="name-data-leakage-of-notify-and-">Data Leakage of N
<t>This section presents a rationale for considering encrypting the other OTIFY and SOA Message Exchanges</name>
messages in the XFR mechanism.</t> <t indent="0" pn="section-5.3-1">This section presents a rationale for c
<t>Since the SOA of the published zone can be trivially discovered by simply onsidering the encryption of the other
querying the publicly available authoritative servers, leakage of this resource messages in the XFR mechanism.</t>
record (RR) via such a <t indent="0" pn="section-5.3-2">Since the SOA of the published zone can
direct query is not discussed in the following sections.</t> be trivially discovered by simply
querying the publicly available authoritative servers, leakage of this resourc
<section anchor="notify"><name>NOTIFY</name> e record (RR)
<t>Unencrypted NOTIFY messages identify configured secondaries on the primary.</ via such a
t> direct query is not discussed in the following sections.</t>
<t><xref target="RFC1996"></xref> also states:</t> <section anchor="notify" numbered="true" removeInRFC="false" toc="includ
e" pn="section-5.3.1">
<artwork>&quot;If ANCOUNT&gt;0, then the answer section represents an <name slugifiedName="name-notify">NOTIFY</name>
unsecure hint at the new RRset for this (QNAME,QCLASS,QTYPE). <t indent="0" pn="section-5.3.1-1">Unencrypted NOTIFY messages identif
</artwork> y configured secondaries on the primary.</t>
<t>But since the only QTYPE for NOTIFY defined at the time of this writing <t indent="0" pn="section-5.3.1-2"><xref target="RFC1996" format="defa
is SOA, this does not pose a ult" sectionFormat="of" derivedContent="RFC1996"/> also states:</t>
potential leak.</t> <blockquote pn="section-5.3.1-3">If ANCOUNT&gt;0, then the answer sect
</section> ion represents an
unsecure hint at the new RRset for this &lt;QNAME,QCLASS,QTYPE&gt;.</blockquot
<section anchor="soa"><name>SOA</name> e>
<t>For hidden XFR servers (either primaries or secondaries), an SOA response <t indent="0" pn="section-5.3.1-4">But since the only query type (QTYP
directly from that server only additionally leaks the degree of SOA serial E) for NOTIFY defined at the time of this writing
number lag of any downstream secondary of that server.</t> is SOA, this does not pose a
</section> potential leak.</t>
</section> </section>
</section> <section anchor="soa" numbered="true" removeInRFC="false" toc="include"
pn="section-5.3.2">
<section anchor="updates-to-existing-specifications"><name>Updates to existing s <name slugifiedName="name-soa">SOA</name>
pecifications</name> <t indent="0" pn="section-5.3.2-1">For hidden XFR servers (either prim
<t>For convenience, the term 'XFR-over-TCP' is used in this document to mean bot aries or secondaries), an SOA response
h directly from that server only additionally leaks the degree of SOA serial
IXFR-over-TCP and AXFR-over-TCP and therefore statements that use that term upda number lag of any downstream secondary of that server.</t>
te </section>
both <xref target="RFC1995"></xref> and <xref target="RFC5936"></xref>, and impl </section>
icitly also apply to XoT. </section>
Differences in behavior specific to XoT are discussed in <section anchor="updates-to-existing-specifications" numbered="true" removeI
<xref target="xot-specification"></xref>.</t> nRFC="false" toc="include" pn="section-6">
<t>Both <xref target="RFC1995"></xref> and <xref target="RFC5936"></xref> were p <name slugifiedName="name-updates-to-existing-specifi">Updates to Existing
ublished sometime before TCP was Specifications</name>
considered a first class transport for DNS. <xref target="RFC1995"></xref>, in f <t indent="0" pn="section-6-1">For convenience, the term 'XFR over TCP' is
act, says nothing used in this document to mean both
with respect to optimizing IXFRs over TCP or re-using already open TCP IXFR over TCP and AXFR over TCP; therefore, statements that use that term upda
connections to perform IXFRs or other queries. Therefore, there arguably is an te
implicit assumption that a TCP connection is used for both <xref target="RFC1995" format="default" sectionFormat="of" derivedContent
one and only one IXFR request. Indeed, many major open source implementations ="RFC1995"/> and <xref target="RFC5936" format="default" sectionFormat="of" deri
take this approach (at the time of this writing). And whilst <xref target="RFC59 vedContent="RFC5936"/> and implicitly also
36"></xref> gives guidance on apply to XoT. Differences in behavior specific to XoT are discussed in
connection re-use for AXFR, it pre-dates more recent specifications describing <xref target="xot-specification" format="default" sectionFormat="of" derivedCo
persistent TCP connections (e.g., <xref target="RFC7766"></xref>, <xref target=" ntent="Section 7"/>.</t>
RFC7828"></xref>), and AXFR implementations again <t indent="0" pn="section-6-2">Both <xref target="RFC1995" format="default
often make less than optimal use of open connections.</t> " sectionFormat="of" derivedContent="RFC1995"/> and <xref target="RFC5936" forma
<t>Given this, new implementations of XoT will clearly benefit from specific gui t="default" sectionFormat="of" derivedContent="RFC5936"/> were published
dance on sometime before TCP became a widely supported transport for DNS. <xref target=
TCP/TLS connection usage for XFR, because this will:</t> "RFC1995" format="default" sectionFormat="of" derivedContent="RFC1995"/>, in fac
t, says nothing
<ul> with respect to optimizing IXFRs over TCP or reusing already open TCP
<li>result in more consistent XoT implementations with better interoperability</ connections to perform IXFRs or other queries. Therefore, there arguably is an
li> implicit assumption that a TCP connection is used for
<li>remove any need for XoT implementations to support legacy behavior for XoT c one and only one IXFR request. Indeed, many major open-source implementations
onnections that take this approach (at the time of this writing). And whilst <xref target="RFC
XFR-over-TCP implementations have historically often supported</li> 5936" format="default" sectionFormat="of" derivedContent="RFC5936"/>
</ul> gives guidance on
<t>Therefore this document updates both the previous specifications for connection reuse for AXFR, it predates more recent specifications describing
XFR-over-TCP ([RFC1995] and [RFC5936]) to clarify that</t> persistent TCP connections (e.g., <xref target="RFC7766" format="default" sect
ionFormat="of" derivedContent="RFC7766"/>, <xref target="RFC7828" format="defaul
<ul> t" sectionFormat="of" derivedContent="RFC7828"/>), and AXFR implementations agai
<li><t>Implementations MUST use <xref target="RFC7766"></xref> (DNS Transport ov n
er TCP - Implementation often make less-than-optimal use of open connections.</t>
Requirements) to optimize the use of TCP connections.</t> <t indent="0" pn="section-6-3">Given this, new implementations of XoT will
</li> clearly benefit from specific guidance on
<li><t>Whilst RFC7766 states that 'DNS clients SHOULD pipeline their queries’ on TCP/TLS connection usage for XFR, because this will:</t>
TCP <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6-4
connections, it did not distinguish between XFRs and other queries for this ">
behavior. It is now recognized that XFRs are not as latency sensitive as <li pn="section-6-4.1">result in more consistent XoT implementations wit
other queries, and can be significantly more complex for clients to handle, h better interoperability and</li>
both because of the large amount of state that must be kept and because there <li pn="section-6-4.2">remove any need for XoT implementations to suppor
may be multiple messages in the responses. For these reasons, it is clarified t legacy behavior for XoT connections
here that a valid reason for not pipelining queries is when they are all XFR that XFR-over-TCP implementations have historically often supported.</li>
queries i.e. clients sending multiple XFRs MAY choose not to pipeline those </ul>
queries. Clients that do not pipeline XFR queries, therefore, have no <t indent="0" pn="section-6-5">Therefore, this document updates both the p
additional requirements to handle out-of-order or intermingled responses (as revious specifications for
described later), since they will never receive them.</t> XFR over TCP (<xref target="RFC1995" format="default" sectionFormat="of" derived
</li> Content="RFC1995"/> and <xref target="RFC5936" format="default" sectionFormat="o
<li><t>Implementations SHOULD use <xref target="RFC7828"></xref> (The edns-tcp-k f" derivedContent="RFC5936"/>) to clarify that:</t>
eepalive EDNS0 Option) <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6-6
to manage persistent connections (which is more flexible than using just fixed t ">
imeouts).</t> <li pn="section-6-6.1">Implementations <bcp14>MUST</bcp14> use <xref tar
</li> get="RFC7766" format="default" sectionFormat="of" derivedContent="RFC7766"/> ("D
</ul> NS Transport
<t>The following sections include detailed clarifications on the updates to XFR over TCP - Implementation Requirements") to optimize the use of TCP connection
behavior implied in <xref target="RFC7766"></xref> and how the use of <xref targ s.</li>
et="RFC7828"></xref> applies <li pn="section-6-6.2">Whilst <xref target="RFC7766" format="default" se
ctionFormat="of" derivedContent="RFC7766"/> states that "DNS clients
<bcp14>SHOULD</bcp14> pipeline their queries"
on TCP connections, it did not distinguish between XFRs and other queries for
this
behavior. It is now recognized that XFRs are not as latency sensitive as
other queries and can be significantly more complex for clients to handle,
both because of the large amount of state that must be kept and because there
may be multiple messages in the responses. For these reasons, it is clarified
here that a valid reason for not pipelining queries is when they are all XFR
queries, i.e., clients sending multiple XFRs <bcp14>MAY</bcp14> choose not to
pipeline those
queries. Clients that do not pipeline XFR queries therefore have no
additional requirements to handle out-of-order or intermingled responses (as
described later), since they will never receive them.</li>
<li pn="section-6-6.3">Implementations <bcp14>SHOULD</bcp14> use the
edns-tcp-keepalive EDNS(0) option <xref target="RFC7828" format="default" sect
ionFormat="of" derivedContent="RFC7828"/> to manage
persistent connections. This is
more flexible than the alternative of simply using fixed timeouts.</li>
</ul>
<t indent="0" pn="section-6-7">The following sections include detailed cla
rifications on the updates to XFR
behavior implied in <xref target="RFC7766" format="default" sectionFormat="of" d
erivedContent="RFC7766"/> and how the use of <xref target="RFC7828" format="defa
ult" sectionFormat="of" derivedContent="RFC7828"/> 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 indent="0" pn="section-6-8">For completeness, the recent specification
NS of extended
error (EDE) codes <xref target="RFC8914"></xref>. For zone transfers, when retur DNS error (EDE) codes <xref target="RFC8914" format="default" sectionFormat="of"
ning REFUSED to a derivedContent="RFC8914"/> is also mentioned here. For zone transfers, when ret
urning 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" numbered="true" remo
<section anchor="update-to-rfc1995-for-ixfr-over-tcp"><name>Update to RFC1995 fo veInRFC="false" toc="include" pn="section-6.1">
r IXFR-over-TCP</name> <name slugifiedName="name-update-to-rfc-1995-for-ixfr">Update to RFC 199
<t>For clarity - an IXFR-over-TCP server compliant with this specification MUST 5 for IXFR over TCP</name>
be <t indent="0" pn="section-6.1-1">For clarity, an IXFR-over-TCP server co
able to handle multiple concurrent IXoT requests on a single TCP connection mpliant with this specification
(for the same and different zones) and SHOULD send the responses as soon as <bcp14>MUST</bcp14> be
they are available, which might be out-of-order compared to the requests.</t> able to handle multiple concurrent IXoT requests on a single TCP connection
</section> (for the same and different zones) and <bcp14>SHOULD</bcp14> send the response
s as soon as
<section anchor="update-to-rfc5936-for-axfr-over-tcp"><name>Update to RFC5936 fo they are available, which might be out of order compared to the requests.</t>
r AXFR-over-TCP</name> </section>
<t>For clarity - an AXFR-over-TCP server compliant with this specification MUST <section anchor="update-to-rfc5936-for-axfr-over-tcp" numbered="true" remo
be veInRFC="false" toc="include" pn="section-6.2">
able to handle multiple concurrent AXoT sessions on a single TCP connection <name slugifiedName="name-update-to-rfc-5936-for-axfr">Update to RFC 593
(for the same and different zones). The response streams for concurrent AXFRs 6 for AXFR over TCP</name>
MAY be intermingled and AXFR-over-TCP clients compliant with this specification <t indent="0" pn="section-6.2-1">For clarity, an AXFR-over-TCP server co
which pipeline AXFR requests MUST be able to handle this.</t> mpliant with this specification
</section> <bcp14>MUST</bcp14> be
able to handle multiple concurrent AXoT sessions on a single TCP connection
<section anchor="updates-to-rfc1995-and-rfc5936-for-xfr-over-tcp"><name>Updates (for the same and different zones). The response streams for concurrent AXFRs
to RFC1995 and RFC5936 for XFR-over-TCP</name> <bcp14>MAY</bcp14> be intermingled, and AXFR-over-TCP clients compliant with t
his
<section anchor="connection-reuse"><name>Connection reuse</name> specification, which pipeline AXFR requests, <bcp14>MUST</bcp14> be able to ha
<t>As specified, XFR-over-TCP clients SHOULD re-use any existing open TCP connec ndle this.</t>
tion when </section>
starting any new XFR request to the same primary, and for issuing SOA queries, <section anchor="updates-to-rfc1995-and-rfc5936-for-xfr-over-tcp" numbered
instead of opening a new connection. The number of TCP connections between a ="true" removeInRFC="false" toc="include" pn="section-6.3">
secondary and primary SHOULD be minimized (also see <xref target="update-to-rfc7 <name slugifiedName="name-updates-to-rfcs-1995-and-59">Updates to RFCs 1
766"></xref>).</t> 995 and 5936 for XFR over TCP</name>
<t>Valid reasons for not re-using existing connections might include:</t> <section anchor="connection-reuse" numbered="true" removeInRFC="false" t
oc="include" pn="section-6.3.1">
<ul> <name slugifiedName="name-connection-reuse">Connection Reuse</name>
<li>as already noted in <xref target="RFC7766"></xref>, separate connections for <t indent="0" pn="section-6.3.1-1">As specified, XFR-over-TCP clients
different zones might be preferred for operational reasons. In this case, the n <bcp14>SHOULD</bcp14> reuse any existing open TCP
umber of concurrent connections for zone transfers SHOULD be limited to the tota connection when
l number of zones transferred between the client and server.</li> starting any new XFR request to the same primary, and for issuing SOA querie
<li>reaching a configured limit for the number of outstanding queries or XFR req s,
uests allowed on a single TCP connection</li> instead of opening a new connection. The number of TCP connections between a
<li>the message ID pool has already been exhausted on an open connection</li> secondary and primary <bcp14>SHOULD</bcp14> be minimized (also see <xref tar
<li>a large number of timeouts or slow responses have occurred on an open get="update-to-rfc7766" format="default" sectionFormat="of" derivedContent="Sect
connection</li> ion 6.4"/>).</t>
<li>an edns-tcp-keepalive EDNS0 option with a timeout of 0 has been received fro <t indent="0" pn="section-6.3.1-2">Valid reasons for not reusing exist
m the ing connections might include:</t>
server and the client is in the process of closing the connection (see <xref tar <ul bare="false" empty="false" indent="3" spacing="normal" pn="section
get="the-edns-tcp-keepalive-edns0-option"></xref>)</li> -6.3.1-3">
</ul> <li pn="section-6.3.1-3.1">As already noted in <xref target="RFC7766
<t>If no TCP connections are currently open, XFR clients MAY send SOA queries ov " format="default" sectionFormat="of" derivedContent="RFC7766"/>, separate conne
er ctions for
UDP or a new TCP connection.</t> different zones might be preferred for operational reasons. In this case,
</section> the number of
concurrent connections for zone transfers <bcp14>SHOULD</bcp14> be limited
<section anchor="axfrs-and-ixfrs-on-the-same-connection"><name>AXFRs and IXFRs o to the total
n the same connection</name> number of zones transferred between the client and server.</li>
<t>Neither <xref target="RFC1995"></xref> nor <xref target="RFC5936"></xref> exp <li pn="section-6.3.1-3.2">A configured limit for the number of outs
licitly discuss the use of a single TCP tanding queries or XFR requests
connection for both IXFR and AXFR requests. <xref target="RFC5936"></xref> does allowed on a single TCP connection has been reached.</li>
make the general statement:</t> <li pn="section-6.3.1-3.3">The message ID pool has already been exha
usted on an open connection.</li>
<artwork>&quot;Non-AXFR session traffic can also use an open TCP connection.&quo <li pn="section-6.3.1-3.4">A large number of timeouts or slow respon
t; ses have occurred on an open
</artwork> connection.</li>
<t>We clarify here that implementations capable of both AXFR and IXFR and compli <li pn="section-6.3.1-3.5">An edns-tcp-keepalive EDNS(0) option with
ant with this specification SHOULD</t> a timeout of 0 has been received from the
server, and the client is in the process of closing the connection (see <x
<ul> ref target="the-edns-tcp-keepalive-edns0-option" format="default" sectionFormat=
<li>use the same TCP connection for both AXFR and IXFR requests to the same prim "of" derivedContent="Section 6.3.4"/>).</li>
ary</li> </ul>
<li>pipeline such requests (if they pipeline XFR requests in general) and MAY in <t indent="0" pn="section-6.3.1-4">If no TCP connections are currently
termingle them</li> open, XFR clients <bcp14>MAY</bcp14> send SOA
<li>send the response(s) for each request as soon as they are available i.e. res queries over UDP or a new TCP connection.</t>
ponses MAY be sent intermingled</li> </section>
</ul> <section anchor="axfrs-and-ixfrs-on-the-same-connection" numbered="true"
<t>For some current implementations adding all the above functionality would int removeInRFC="false" toc="include" pn="section-6.3.2">
roduce significant <name slugifiedName="name-axfrs-and-ixfrs-on-the-same">AXFRs and IXFRs
code complexity. In such a case, there will need to be an assessment of the trad on the Same Connection</name>
e-off between that <t indent="0" pn="section-6.3.2-1">Neither <xref target="RFC1995" form
and the performance benefits of the above for XFR.</t> at="default" sectionFormat="of" derivedContent="RFC1995"/> nor <xref target="RFC
</section> 5936" format="default" sectionFormat="of" derivedContent="RFC5936"/> explicitly
discuss the use of a single TCP
<section anchor="xfr-limits"><name>XFR limits</name> connection for both IXFR and AXFR requests. <xref target="RFC5936" format="d
<t>The server MAY limit the number of concurrent IXFRs, AXFRs or total XFR efault" sectionFormat="of" derivedContent="RFC5936"/> does make the
transfers in progress, or from a given secondary, to protect server resources. general statement:</t>
Servers SHOULD return SERVFAIL if this limit is hit, since it is a <blockquote pn="section-6.3.2-2">Non-AXFR session traffic can also use
transient error and a retry at a later time might succeed (there is no previous an open connection.</blockquote>
specification for this behavior).</t> <t indent="0" pn="section-6.3.2-3">In this document, the above is clar
</section> ified to indicate that implementations capable of both AXFR and IXFR and
compliant with this specification <bcp14>SHOULD</bcp14>:</t>
<section anchor="the-edns-tcp-keepalive-edns0-option"><name>The edns-tcp-keepali <ul bare="false" empty="false" indent="3" spacing="normal" pn="section
ve EDNS0 Option</name> -6.3.2-4">
<t>XFR clients that send the edns-tcp-keepalive EDNS0 option on every XFR reques <li pn="section-6.3.2-4.1">use the same TCP connection for both AXFR
t provide the and IXFR requests to the same
server with maximum opportunity to update the edns-tcp-keepalive timeout. The XF primary,</li>
R server <li pn="section-6.3.2-4.2">pipeline such requests (if they pipeline
may use the frequency of recent XFRs to calculate an average update rate as XFR requests in general) and
input to the decision of what edns-tcp-keepalive timeout to use. If the server <bcp14>MAY</bcp14> intermingle them, and</li>
does not support edns-tcp-keepalive, the client MAY keep the connection open for <li pn="section-6.3.2-4.3">send the response(s) for each request as
a soon as they are available, i.e.,
few seconds (<xref target="RFC7766"></xref> recommends that servers use timeouts responses <bcp14>MAY</bcp14> be sent intermingled.</li>
of at least a few </ul>
seconds).</t> <t indent="0" pn="section-6.3.2-5">For some current implementations, a
<t>Whilst the specification for EDNS0 <xref target="RFC6891"></xref> does not dding all the above functionality would introduce
specifically mention AXFRs, it does say</t> significant code complexity. In such a case, there will need to be an assess
ment of the
<artwork>&quot;If an OPT record is present in a received request, compliant trade-off between that and the performance benefits of the above for XFR.</t
responders MUST include an OPT record in their respective >
responses.&quot; </section>
</artwork> <section anchor="xfr-limits" numbered="true" removeInRFC="false" toc="in
<t>We clarify here that if an OPT record is present in a received AXFR request, clude" pn="section-6.3.3">
compliant responders MUST include an OPT record in each of the subsequent AXFR <name slugifiedName="name-xfr-limits">XFR Limits</name>
responses. Note that this requirement, combined with the use of <t indent="0" pn="section-6.3.3-1">The server <bcp14>MAY</bcp14> limit
edns-tcp-keepalive, enables AXFR servers to signal the desire to close a the number of concurrent IXFRs, AXFRs, or total XFR
connection (when existing transactions have competed) due to low resources by transfers in progress (or from a given secondary) to protect server resource
sending an edns-tcp-keepalive EDNS0 option with a timeout of 0 on any AXFR s.
response. This does not signal that the AXFR is aborted, just that the server Servers <bcp14>SHOULD</bcp14> return SERVFAIL if this limit is hit, since it
wishes to close the connection as soon as possible.</t> is a
</section> transient error and a retry at a later time might succeed (there is no previ
ous
<section anchor="backwards-compatibility"><name>Backwards compatibility</name> specification for this behavior).</t>
<t>Certain legacy behaviors were noted in <xref target="RFC5936"></xref>, with p </section>
rovisions that <section anchor="the-edns-tcp-keepalive-edns0-option" numbered="true" re
implementations may want to offer options to fallback to legacy behavior when moveInRFC="false" toc="include" pn="section-6.3.4">
interoperating with servers known to not support <xref target="RFC5936"></xref>. <name slugifiedName="name-the-edns-tcp-keepalive-edns">The edns-tcp-ke
For purposes of epalive EDNS(0) Option</name>
interoperability, IXFR and AXFR implementations may want to continue offering <t indent="0" pn="section-6.3.4-1">XFR clients that send the edns-tcp-
such configuration options, as well as supporting some behaviors that were keepalive EDNS(0) option on every XFR request provide
underspecified prior to this work (e.g., performing IXFR and AXFRs on separate the server with maximum opportunity to update the edns-tcp-keepalive timeout
connections). However, XoT connections should have no need to do so.</t> . The XFR
</section> server may use the frequency of recent XFRs to calculate an average update r
</section> ate as
input to the decision of what edns-tcp-keepalive timeout to use. If the serv
<section anchor="update-to-rfc7766"><name>Update to RFC7766</name> er
<t><xref target="RFC7766"></xref> made general implementation does not support edns-tcp-keepalive, the client <bcp14>MAY</bcp14> keep the
recommendations with regard to TCP/TLS connection handling:</t> connection
open for a few seconds (<xref target="RFC7766" format="default" sectionForma
<artwork>&quot;To mitigate the risk of unintentional server overload, DNS t="of" derivedContent="RFC7766"/> recommends that servers use
clients MUST take care to minimize the number of concurrent TCP timeouts of at least a few seconds).</t>
connections made to any individual server. It is RECOMMENDED <t indent="0" pn="section-6.3.4-2">Whilst the specification for EDNS(0
that for any given client/server interaction there SHOULD be no ) <xref target="RFC6891" format="default" sectionFormat="of" derivedContent="RF
more than one connection for regular queries, one for zone C6891"/> does not
transfers, and one for each protocol that is being used on top specifically mention AXFRs, it does say:</t>
of TCP (for example, if the resolver was using TLS). However, <blockquote pn="section-6.3.4-3">If an OPT record is present in a rece
it is noted that certain primary/ secondary configurations with ived request, compliant
many busy zones might need to use more than one TCP connection responders <bcp14>MUST</bcp14> include an OPT record in their respective
for zone transfers for operational reasons (for example, to responses.</blockquote>
support concurrent transfers of multiple zones).&quot; <t indent="0" pn="section-6.3.4-4">In this document, the above is clar
</artwork> ified to indicate that if an OPT record is present in a received AXFR request,
<t>Whilst this recommends a particular behavior for the clients using TCP, it compliant responders <bcp14>MUST</bcp14> include an OPT record in each of th
does not relax the requirement for servers to handle 'mixed' traffic (regular e subsequent
queries and zone transfers) on any open TCP/TLS connection. It also overlooks th AXFR responses. Note that this requirement, combined with the use of
e edns-tcp-keepalive, enables AXFR servers to signal the desire to close a
potential that other transports might want to take the same approach with regard connection (when existing transactions have competed) due to low resources b
to y
using separate connections for different purposes.</t> sending an edns-tcp-keepalive EDNS(0) option with a timeout of 0 on any AXFR
<t>This specification updates the above general guidance in <xref target="RFC776 response. This does not signal that the AXFR is aborted, just that the serve
6"></xref> to provide the r
same separation of connection purpose (regular queries and zone transfers) for wishes to close the connection as soon as possible.</t>
all transports being used on top of TCP.</t> </section>
<t>Therefore, it is RECOMMENDED that for <section anchor="backwards-compatibility" numbered="true" removeInRFC="f
each protocol used on top of TCP in any given client/server interaction, there alse" toc="include" pn="section-6.3.5">
SHOULD be no more than one connection for regular queries and one for zone <name slugifiedName="name-backwards-compatibility">Backwards Compatibi
transfers.</t> lity</name>
<t>As an illustration, it could be imagined that in future such an <t indent="0" pn="section-6.3.5-1">Certain legacy behaviors were noted
interaction could hypothetically include one or all of the following:</t> in <xref target="RFC5936" format="default" sectionFormat="of" derivedContent="R
FC5936"/>, with provisions
<ul> that implementations may want to offer options to fallback to legacy behavio
<li>one TCP connection for regular queries</li> r when
<li>one TCP connection for zone transfers</li> interoperating with servers known to not support <xref target="RFC5936" form
<li>one TLS connection for regular queries</li> at="default" sectionFormat="of" derivedContent="RFC5936"/>. For
<li>one TLS connection for zone transfers</li> purposes of interoperability, IXFR and AXFR implementations may want to cont
<li>one DoH connection for regular queries</li> inue offering
<li>one DoH connection for zone transfers</li> such configuration options, as well as supporting some behaviors that were
</ul> underspecified prior to this work (e.g., performing IXFR and AXFRs on separa
<t><xref target="connection-reuse"></xref> has provided specific details of reas te
ons where more than connections). However, XoT connections should have no need to do so.</t>
one connection for a given transport might be required for zone transfers from </section>
a particular client.</t> </section>
</section> <section anchor="update-to-rfc7766" numbered="true" removeInRFC="false" to
</section> c="include" pn="section-6.4">
<name slugifiedName="name-update-to-rfc-7766">Update to RFC 7766</name>
<section anchor="xot-specification"><name>XoT specification</name> <t indent="0" pn="section-6.4-1"><xref target="RFC7766" format="default"
sectionFormat="of" derivedContent="RFC7766"/> made general implementation
<section anchor="connection-establishment"><name>Connection establishment</name> recommendations with regard to TCP/TLS connection handling:</t>
<t>During connection establishment the Application-Layer Protocol Negotiation (A <blockquote pn="section-6.4-2">To mitigate the risk of unintentional ser
LPN) token “dot” <xref target="DoT-ALPN"></xref> MUST be selected in the TLS han ver overload, DNS
dshake.</t> clients <bcp14>MUST</bcp14> take care to minimize the number of concurrent TCP
</section> connections made to any individual server. It is <bcp14>RECOMMENDED</bcp14>
that for any given client/server interaction there <bcp14>SHOULD</bcp14> be no
<section anchor="tls-versions"><name>TLS versions</name> more than one connection for regular queries, one for zone
<t>All implementations of this specification MUST use only TLS 1.3 <xref target= transfers, and one for each protocol that is being used on top
"RFC8446"></xref> or later.</t> 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
<section anchor="port-selection"><name>Port selection</name> for zone transfers for operational reasons (for example, to
<t>The connection for XoT SHOULD be established using port 853, as specified in support concurrent transfers of multiple zones).</blockquote>
<xref target="RFC7858"></xref>, unless there is mutual agreement between the sec <t indent="0" pn="section-6.4-3">Whilst this recommends a particular beh
ondary and primary avior for the clients using TCP, it
to use a port other than port 853 for XoT. There MAY be agreement to use does not relax the requirement for servers to handle 'mixed' traffic (regular
different ports for AXoT and IXoT, or for different zones.</t> queries and zone transfers) on any open TCP/TLS connection. It also overlooks
</section> the
potential that other transports might want to take the same approach with rega
<section anchor="high-level-xot-descriptions"><name>High level XoT descriptions< rd to
/name> using separate connections for different purposes.</t>
<t>It is useful to note that in XoT, it is the secondary that initiates <t indent="0" pn="section-6.4-4">This specification updates the above ge
the TLS connection to the primary for a XFR request, so that in terms of neral guidance in <xref target="RFC7766" format="default" sectionFormat="of" der
connectivity, the secondary is the TLS client and the primary the TLS server.</t ivedContent="RFC7766"/>
> to provide the same separation of connection purpose (regular queries and zone
<t>The figure below provides an outline of the AXoT mechanism including NOTIFYs. transfers) for
</t> all transports being used on top of TCP.</t>
<t indent="0" pn="section-6.4-5">Therefore, it is <bcp14>RECOMMENDED</bc
<artwork> Secondary Primary p14> 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 indent="0" pn="section-6.4-6">As an illustration, it could be imagine
d that in the future such an
interaction could hypothetically include one or all of the following:</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6
.4-7">
<li pn="section-6.4-7.1">one TCP connection for regular queries</li>
<li pn="section-6.4-7.2">one TCP connection for zone transfers</li>
<li pn="section-6.4-7.3">one TLS connection for regular queries</li>
<li pn="section-6.4-7.4">one TLS connection for zone transfers</li>
<li pn="section-6.4-7.5">one DoH connection for regular queries</li>
<li pn="section-6.4-7.6">one DoH connection for zone transfers</li>
</ul>
<t indent="0" pn="section-6.4-8"><xref target="connection-reuse" format=
"default" sectionFormat="of" derivedContent="Section 6.3.1"/> provides specific
details of the reasons why
more than one connection for a given transport might be required for zone tran
sfers from
a particular client.</t>
</section>
</section>
<section anchor="xot-specification" numbered="true" removeInRFC="false" toc=
"include" pn="section-7">
<name slugifiedName="name-xot-specification">XoT Specification</name>
<section anchor="connection-establishment" numbered="true" removeInRFC="fa
lse" toc="include" pn="section-7.1">
<name slugifiedName="name-connection-establishment">Connection Establish
ment</name>
<t indent="0" pn="section-7.1-1">During connection establishment, the Ap
plication-Layer Protocol Negotiation (ALPN) token
"dot" <xref target="DoT-ALPN" format="default" sectionFormat="of" derivedCon
tent="DoT-ALPN"/> <bcp14>MUST</bcp14> be selected in the TLS
handshake.</t>
</section>
<section anchor="tls-versions" numbered="true" removeInRFC="false" toc="in
clude" pn="section-7.2">
<name slugifiedName="name-tls-versions">TLS Versions</name>
<t indent="0" pn="section-7.2-1">All implementations of this specificati
on <bcp14>MUST</bcp14> use only TLS 1.3 <xref target="RFC8446" format="default"
sectionFormat="of" derivedContent="RFC8446"/> or later.</t>
</section>
<section anchor="port-selection" numbered="true" removeInRFC="false" toc="
include" pn="section-7.3">
<name slugifiedName="name-port-selection">Port Selection</name>
<t indent="0" pn="section-7.3-1">The connection for XoT <bcp14>SHOULD</b
cp14> be established using port 853, as
specified in <xref target="RFC7858" format="default" sectionFormat="of" deri
vedContent="RFC7858"/>, unless there is mutual agreement between the
primary and secondary to use a port other than port 853 for XoT. There <bcp1
4>MAY</bcp14>
be agreement to use different ports for AXoT and IXoT or for different zones
.</t>
</section>
<section anchor="high-level-xot-descriptions" numbered="true" removeInRFC=
"false" toc="include" pn="section-7.4">
<name slugifiedName="name-high-level-xot-descriptions">High-Level XoT De
scriptions</name>
<t indent="0" pn="section-7.4-1">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 indent="0" pn="section-7.4-2">The figure below provides an outline of
the AXoT mechanism including NOTIFYs.</t>
<figure anchor="fig3" align="left" suppress-title="false" pn="figure-3">
<name slugifiedName="name-axot-mechanism">AXoT Mechanism</name>
<artwork name="" type="" alt="" align="left" pn="section-7.4-3.1">
Secondary Primary
| NOTIFY | | NOTIFY |
| &lt;-------------------------------- | UDP | &lt;-------------------------------- | UDP
| --------------------------------&gt; | | --------------------------------&gt; |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------&gt; | UDP (or part of | --------------------------------&gt; | UDP (or part of
| &lt;-------------------------------- | a TCP/TLS session) | &lt;-------------------------------- | a TCP/TLS session)
skipping to change at line 645 skipping to change at line 951
| (Zone data) | | | (Zone data) | |
| | | | | |
| &lt;-------------------------------- | | TLS | &lt;-------------------------------- | | TLS
| AXFR Response 2 | | Session | AXFR Response 2 | | Session
| (Zone data) | | | (Zone data) | |
| | | | | |
| &lt;-------------------------------- | | | &lt;-------------------------------- | |
| AXFR Response 3 | | | AXFR Response 3 | |
| (Zone data) | --- | (Zone data) | ---
| | | |
Figure 3. AXoT Mechanism
</artwork> </artwork>
<t>The figure below provides an outline of the IXoT mechanism including NOTIFYs. </figure>
</t> <t indent="0" pn="section-7.4-4">The figure below provides an outline of
the IXoT mechanism including NOTIFYs.</t>
<artwork> Secondary Primary <figure anchor="fig4" align="left" suppress-title="false" pn="figure-4">
<name slugifiedName="name-ixot-mechanism">IXoT Mechanism</name>
<artwork name="" type="" alt="" align="left" pn="section-7.4-5.1">
Secondary Primary
| NOTIFY | | NOTIFY |
| &lt;-------------------------------- | UDP | &lt;-------------------------------- | UDP
| --------------------------------&gt; | | --------------------------------&gt; |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------&gt; | UDP (or part of | --------------------------------&gt; | UDP (or part of
| &lt;-------------------------------- | a TCP/TLS session) | &lt;-------------------------------- | a TCP/TLS session)
skipping to change at line 678 skipping to change at line 984
| &lt;-------------------------------- | | | &lt;-------------------------------- | |
| IXFR Response | | | IXFR Response | |
| (Zone data) | | | (Zone data) | |
| | | TLS | | | TLS
| | | session | | | session
| IXFR Request | | | IXFR Request | |
| --------------------------------&gt; | | | --------------------------------&gt; | |
| &lt;-------------------------------- | | | &lt;-------------------------------- | |
| IXFR Response | | | IXFR Response | |
| (Zone data) | --- | (Zone data) | ---
Figure 4. IXoT Mechanism
</artwork> </artwork>
</section> </figure>
</section>
<section anchor="xot-transfers"><name>XoT transfers</name> <section anchor="xot-transfers" numbered="true" removeInRFC="false" toc="i
<t>For a zone transfer between two end points to be considered protected with Xo nclude" pn="section-7.5">
T <name slugifiedName="name-xot-transfers">XoT Transfers</name>
all XFR requests and response for that zone MUST be sent over TLS connections <t indent="0" pn="section-7.5-1">For a zone transfer between two endpoin
where at a minimum:</t> ts to be considered protected with XoT,
all XFR requests and responses for that zone <bcp14>MUST</bcp14> be sent over
<ul> TLS connections,
<li>the client MUST authenticate the server by use of an authentication domain where at a minimum:</t>
name using a Strict Privacy Profile, as described in <xref target="RFC8310"></xr <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7
ef></li> .5-2">
<li><t>the server MUST validate the client is authorized to request or proxy a z <li pn="section-7.5-2.1">The client <bcp14>MUST</bcp14> authenticate t
one transfer by he server by use of an authentication
using one or both of the following methods:</t> domain name using a Strict Privacy profile, as described in <xref target="RF
C8310" format="default" sectionFormat="of" derivedContent="RFC8310"/>.</li>
<ul> <li pn="section-7.5-2.2">
<li>Mutual TLS (mTLS)</li> <t indent="0" pn="section-7.5-2.2.1">The server <bcp14>MUST</bcp14>
<li>an IP based ACL (which can be either per-message or per-connection) validate the client is authorized to request or proxy
combined with a valid TSIG/SIG(0) signature on the XFR request</li> a zone transfer by using one or both of the following methods:</t>
</ul></li> <ul bare="false" empty="false" indent="3" spacing="normal" pn="secti
</ul> on-7.5-2.2.2">
<t>If only one method is selected then mTLS is preferred because it provides str <li pn="section-7.5-2.2.2.1">mutual TLS (mTLS)</li>
ong cryptographic <li pn="section-7.5-2.2.2.2">an IP-based ACL (which can be either
protection at both endpoints.</t> per message or per connection)
<t>Authentication mechanisms are discussed in full in <xref target="authenticati combined with a valid TSIG/SIG(0) signature on the XFR request</li>
on-mechanisms"></xref> </ul>
and the rationale for the above requirement in <xref target="xot-authentication" </li>
></xref>. Transfer </ul>
group policies are discussed in <xref target="policies-for-both-axot-and-ixot">< <t indent="0" pn="section-7.5-3">If only one method is selected, then mT
/xref>.</t> LS is preferred because it provides strong
</section> cryptographic protection at both endpoints.</t>
<t indent="0" pn="section-7.5-4">Authentication mechanisms are discussed
<section anchor="xot-connections"><name>XoT connections</name> in full in <xref target="authentication-mechanisms" format="default" sectionFor
<t>The details in <xref target="updates-to-existing-specifications"></xref> abou mat="of" derivedContent="Section 9"/>,
t, e.g., persistent and the rationale for the above requirement is discussed in <xref target="xot-
connections and XFR message handling are fully applicable to XoT connections as authentication" format="default" sectionFormat="of" derivedContent="Section 10"/
well. However, any behavior specified here takes precedence for XoT.</t> >.
<t>If no TLS connections are currently open, XoT clients MAY send SOA queries ov Transfer group policies are discussed in <xref target="policies-for-both-axot-
er and-ixot" format="default" sectionFormat="of" derivedContent="Section 11"/>.</t>
UDP or TCP, or TLS.</t> </section>
</section> <section anchor="xot-connections" numbered="true" removeInRFC="false" toc=
"include" pn="section-7.6">
<section anchor="xot-vs-adot"><name>XoT vs ADoT</name> <name slugifiedName="name-xot-connections">XoT Connections</name>
<t>As noted earlier, there is currently no specification for encryption of <t indent="0" pn="section-7.6-1">The details in <xref target="updates-to
connections from recursive resolvers to authoritative servers. Some -existing-specifications" format="default" sectionFormat="of" derivedContent="Se
authoritatives are experimenting with ADoT and opportunistic encryption has ction 6"/> about, e.g.,
also been raised as a possibility; it is therefore highly likely that use of persistent connections and XFR message handling, are fully applicable to XoT c
encryption by authoritative servers will evolve in the coming years.</t> onnections as
<t>This raises questions in the short term with regard to TLS connection and well. However, any behavior specified here takes precedence for XoT.</t>
message handling for authoritative servers. In particular, there is likely to be <t indent="0" pn="section-7.6-2">If no TLS connections are currently ope
a class of authoritatives that wish to use XoT in the near future with a small n, XoT clients <bcp14>MAY</bcp14> send SOA queries
number of configured secondaries, but that do not wish to support DoT for regula over UDP, TCP, or TLS.</t>
r </section>
queries from recursives in that same time frame. These servers have to <section anchor="xot-vs-adot" numbered="true" removeInRFC="false" toc="inc
potentially cope with probing and direct queries from recursives and from test lude" pn="section-7.7">
servers, and also potential attacks that might wish to make use of TLS to <name slugifiedName="name-xot-vs-adot">XoT vs. ADoT</name>
overload the server.</t> <t indent="0" pn="section-7.7-1">As noted earlier, there is currently no
<t><xref target="RFC5936"></xref> clearly states that non-AXFR session traffic c specification for encryption of
an use an open TCP connections from recursive resolvers to authoritative servers. Some
connection, however, this requirement needs to be re-evaluated when considering authoritative servers are experimenting with ADoT, and opportunistic encryptio
applying the same model to XoT. Proposing that a server should also start n
responding to all queries received over TLS just because it has enabled XoT has also been raised as a possibility; therefore, it is highly likely that use
would be equivalent to defining a form of authoritative DoT. This specification of encryption by authoritative servers will evolve in the coming years.</t>
does not propose that, but it also does not prohibit servers from answering <t indent="0" pn="section-7.7-2">This raises questions in the short term
queries unrelated to XFR exchanges over TLS. Rather, this specification with regard to TLS connection and
simply outlines in later sections:</t> message handling for authoritative servers. In particular, there is likely to
be
<ul> a class of authoritative servers that wish to use XoT in the near future with
<li>how XoT implementations should utilize EDE codes in response to queries on T a
LS small number of configured secondaries but that do not wish to support DoT for
connections they are not willing to answer (see <xref target="response-rcodes">< regular queries from recursives in that same time frame. These servers have to
/xref>)</li> potentially cope with probing and direct queries from recursives and from test
<li>the operational and policy options that a XoT server operator has servers and also potential attacks that might wish to make use of TLS to
with regard to managing TLS connections and messages (see <xref target="xot-serv overload the server.</t>
er-connection-handling"></xref>)</li> <t indent="0" pn="section-7.7-3"><xref target="RFC5936" format="default"
</ul> sectionFormat="of" derivedContent="RFC5936"/> clearly states that non-AXFR sess
</section> ion traffic can use an
open connection; however, this requirement needs to be reevaluated when consid
<section anchor="response-rcodes"><name>Response RCODES</name> ering
<t>XoT clients and servers MUST implement EDE codes. If a XoT server receives the application of the same model to XoT. Proposing that a server should also
non-XoT traffic it is not willing to answer on a TLS connection, it SHOULD start
respond with REFUSED and the extended DNS error code 21 - Not Supported responding to all queries received over TLS just because it has enabled XoT
<xref target="RFC8914"></xref>. XoT clients should not send any further would be equivalent to defining a form of authoritative DoT. This specificatio
queries of this type to the server for a reasonable period of time (for n
example, one hour) i.e., long enough that the server configuration or policy does not propose that, but it also does not prohibit servers from answering
might be updated.</t> queries unrelated to XFR exchanges over TLS. Rather, this specification
<t>Historically, servers have used the REFUSED RCODE for many situations, and so simply outlines in later sections:</t>
clients often had no detailed information on which to base an error or fallback <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7
path when queries were refused. As a result, the client behavior could vary .7-4">
significantly. XoT servers that refuse queries must cater for the fact that <li pn="section-7.7-4.1">the utilization of EDE codes by XoT servers i
client behavior might vary from continually retrying queries regardless of n response to queries on TLS
receiving REFUSED to every query, or at the other extreme clients may decide to connections that they are not willing to answer (see <xref target="response-
stop using the server over any transport. This might be because those clients ar rcodes" format="default" sectionFormat="of" derivedContent="Section 7.8"/>)</li>
e <li pn="section-7.7-4.2">the operational and policy options that an op
either non-XoT clients or do not implement EDE codes.</t> erator of a XoT server has
</section> with regard to managing TLS connections and messages (see <xref target="xot-
server-connection-handling" format="default" sectionFormat="of" derivedContent="
<section anchor="axot-specifics"><name>AXoT specifics</name> Appendix A"/>)</li>
</ul>
<section anchor="padding-axot-responses"><name>Padding AXoT responses</name> </section>
<t>The goal of padding AXoT responses is two fold:</t> <section anchor="response-rcodes" numbered="true" removeInRFC="false" toc=
"include" pn="section-7.8">
<ul> <name slugifiedName="name-response-rcodes">Response RCODES</name>
<li>to obfuscate the actual size of the transferred zone to minimize information <t indent="0" pn="section-7.8-1">XoT clients and servers <bcp14>MUST</bc
leakage about the entire contents of the zone.</li> p14> implement EDE codes. If a XoT server receives
<li>to obfuscate the incremental changes to the zone between SOA updates to non-XoT traffic it is not willing to answer on a TLS connection, it <bcp14>SHO
minimize information leakage about zone update activity and growth.</li> ULD</bcp14>
</ul> respond with REFUSED and the extended DNS error code 21 - Not Supported
<t>Note that the re-use of XoT connections for transfers of multiple different <xref target="RFC8914" format="default" sectionFormat="of" derivedContent="RFC
zones slightly complicates any attempt to analyze the traffic size and timing to 8914"/>. XoT clients should not send any further
extract information. Also, effective padding may require state to be kept queries of this type to the server for a reasonable period of time (for
as zones may grow and/or shrink over time.</t> example, one hour), i.e., long enough that the server configuration or policy
<t>It is noted here that, depending on the padding policies eventually developed might be updated.</t>
for XoT, <t indent="0" pn="section-7.8-2">Historically, servers have used the REF
the requirement to obfuscate the total zone size might USED RCODE for many situations; therefore,
require a server to create 'empty' AXoT responses. That is, AXoT responses that clients often had no detailed information on which to base an error or fallbac
contain no RR's apart from an OPT RR containing the EDNS(0) option for padding. k
For example, without this capability the maximum size that a tiny zone could be path when queries were refused. As a result, the client behavior could vary
padded to would significantly. XoT servers that refuse queries must cater to the fact that
theoretically be limited if there had to be a minimum of 1 RR per packet.</t> client behavior might vary from continually retrying queries regardless of
<t>However, as with existing AXFR, the last AXoT response message sent MUST receiving REFUSED to every query or, at the other extreme, clients may decide
contain the same SOA that was in the first message of the AXoT response series to
in order to signal the conclusion of the zone transfer.</t> stop using the server over any transport. This might be because those clients
<t><xref target="RFC5936"></xref> says:</t> are
either non-XoT clients or do not implement EDE codes.</t>
<artwork>&quot;Each AXFR response message SHOULD contain a sufficient number </section>
of RRs to reasonably amortize the per-message overhead, up to <section anchor="axot-specifics" numbered="true" removeInRFC="false" toc="
the largest number that will fit within a DNS message (taking include" pn="section-7.9">
the required content of the other sections into account, as <name slugifiedName="name-axot-specifics">AXoT Specifics</name>
described below).&quot; <section anchor="padding-axot-responses" numbered="true" removeInRFC="fa
</artwork> lse" toc="include" pn="section-7.9.1">
<t>'Empty' AXoT responses generated in order to meet a padding requirement will <name slugifiedName="name-padding-axot-responses">Padding AXoT Respons
be es</name>
exceptions to the above statement. For flexibility, future proofing and in <t indent="0" pn="section-7.9.1-1">The goal of padding AXoT responses
order to guarantee support for future padding policies, we state here that is two fold:</t>
secondary implementations MUST be resilient to receiving padded AXoT responses, <ul bare="false" empty="false" indent="3" spacing="normal" pn="section
including 'empty' AXoT responses that contain only an OPT RR containing the -7.9.1-2">
EDNS(0) option for padding.</t> <li pn="section-7.9.1-2.1">to obfuscate the actual size of the trans
<t>Recommendation of specific policies for padding AXoT responses are out of sco ferred zone to minimize information
pe leakage about the entire contents of the zone</li>
for this specification. Detailed considerations of such policies and the <li pn="section-7.9.1-2.2">to obfuscate the incremental changes to t
trade-offs involved are expected to be the subject of future work.</t> he zone between SOA updates to
</section> minimize information leakage about zone update activity and growth</li>
</section> </ul>
<t indent="0" pn="section-7.9.1-3">Note that the reuse of XoT connecti
<section anchor="ixot-specifics"><name>IXoT specifics</name> ons for transfers of multiple different
zones slightly complicates any attempt to analyze the traffic size and timin
<section anchor="condensation-of-responses"><name>Condensation of responses</nam g to
e> extract information. Also, effective padding may require the state to be ke
<t><xref target="RFC1995"></xref> says condensation of responses is optional and pt
MAY be done. Whilst because zones may grow and/or shrink over time.</t>
it does add complexity to generating responses, it can significantly reduce the <t indent="0" pn="section-7.9.1-4">It is noted here that, depending on
size of responses. However any such reduction might be offset by increased the padding policies eventually developed for XoT,
message size due to padding. This specification does not update the optionality the requirement to obfuscate the total zone size might
of condensation for XoT responses.</t> require a server to create 'empty' AXoT responses, that is, AXoT responses t
</section> hat
contain no RRs apart from an OPT RR containing the EDNS(0) option for paddin
<section anchor="fallback-to-axfr"><name>Fallback to AXFR</name> g.
<t>Fallback to AXFR can happen, for example, if the server is not able to provid For example, without this capability, the maximum size that a tiny zone coul
e d be padded to
an IXFR for the requested SOA. Implementations differ in how long they store would theoretically be limited if there had to be a minimum of 1 RR per pack
zone deltas and how many may be stored at any one time.</t> et.</t>
<t>Just as with IXFR-over-TCP, after a failed IXFR a IXoT client SHOULD request <t indent="0" pn="section-7.9.1-5">However, as with existing AXFR, the
the AXFR on the already open XoT connection.</t> last AXoT response message sent <bcp14>MUST</bcp14>
</section> contain the same SOA that was in the first message of the AXoT response seri
es
<section anchor="padding-of-ixot-responses"><name>Padding of IXoT responses</nam in order to signal the conclusion of the zone transfer.</t>
e> <t indent="0" pn="section-7.9.1-6"><xref target="RFC5936" format="defa
<t>The goal of padding IXoT responses is to obfuscate the incremental ult" sectionFormat="of" derivedContent="RFC5936"/> says:</t>
changes to the zone between SOA updates to minimize information leakage about <blockquote pn="section-7.9.1-7">Each AXFR response message <bcp14>SHO
zone update activity and growth. Both the size and timing of the IXoT responses ULD</bcp14> contain a sufficient number
could of RRs to reasonably amortize the per-message overhead, up to
reveal information.</t> the largest number that will fit within a DNS message (taking
<t>IXFR responses can vary greatly in size from the order of 100 bytes for one o the required content of the other sections into account, as
r described below).</blockquote>
two record updates, to tens of thousands of bytes for large dynamic DNSSEC <t indent="0" pn="section-7.9.1-8">'Empty' AXoT responses generated in
signed zones. The frequency of IXFR responses can also depend greatly on if and order to meet a padding requirement will be
how the zone is DNSSEC signed.</t> exceptions to the above statement. For flexibility, for future proofing, and
<t>In order to guarantee support for future padding policies, we state here that in
secondary implementations MUST be resilient to receiving padded IXoT responses.< order to guarantee support for future padding policies, it is stated here th
/t> at
<t>Recommendation of specific policies for padding IXoT responses are out of sco secondary implementations <bcp14>MUST</bcp14> be resilient to receiving padd
pe ed AXoT
for this specification. Detailed considerations of such padding policies, the responses, including 'empty' AXoT responses that contain only an OPT RR cont
use of traffic obfuscation techniques (such as ‘dummy' traffic), and the aining the
trade-offs involved are expected to be the subject of future work.</t> EDNS(0) option for padding.</t>
</section> <t indent="0" pn="section-7.9.1-9">Recommendations of specific policie
</section> s for padding AXoT responses are out of scope
for this specification. Detailed considerations of such policies and the
<section anchor="name-compression-and-maximum-payload-sizes"><name>Name compress trade-offs involved are expected to be the subject of future work.</t>
ion and maximum payload sizes</name> </section>
<t>It is noted here that name compression <xref target="RFC1035"></xref> can be </section>
used in XFR responses <section anchor="ixot-specifics" numbered="true" removeInRFC="false" toc="
to reduce the size of the payload, however, the maximum value of the offset that include" pn="section-7.10">
can be used in the name compression pointer structure is 16384. For some DNS <name slugifiedName="name-ixot-specifics">IXoT Specifics</name>
implementations this limits the size of an individual XFR response used in <section anchor="condensation-of-responses" numbered="true" removeInRFC=
practice to something around the order of 16kB. In principle, larger "false" toc="include" pn="section-7.10.1">
payload sizes can be supported for some responses with more sophisticated <name slugifiedName="name-condensation-of-responses">Condensation of R
approaches (e.g., by pre-calculating the maximum offset required).</t> esponses</name>
<t>Implementations may wish to offer options to disable name compression for XoT <t indent="0" pn="section-7.10.1-1"><xref target="RFC1995" format="def
responses to enable larger payloads. This might be particularly helpful when ault" sectionFormat="of" derivedContent="RFC1995"/> says that condensation of re
padding is used since minimizing the payload size is not necessarily a useful sponses is optional and
optimization in this case and disabling name compression will reduce the <bcp14>MAY</bcp14> be done. Whilst
resources required to construct the payload.</t> it does add complexity to generating responses, it can significantly reduce
</section> the
</section> size of responses. However, any such reduction might be offset by increased
message size due to padding. This specification does not update the optional
<section anchor="multi-primary-configurations"><name>Multi-primary Configuration ity
s</name> of condensation for XoT responses.</t>
<t>This model can provide flexibility </section>
and redundancy particularly for IXFR. A secondary will receive one or more <section anchor="fallback-to-axfr" numbered="true" removeInRFC="false" t
NOTIFY messages and can send an SOA to all of the configured primaries. It can oc="include" pn="section-7.10.2">
then choose to send an XFR request to the primary with the highest SOA (or <name slugifiedName="name-fallback-to-axfr">Fallback to AXFR</name>
based on other criteria, e.g., RTT).</t> <t indent="0" pn="section-7.10.2-1">Fallback to AXFR can happen, for e
<t>When using persistent connections, the secondary may have a XoT connection xample, if the server is not able to provide
already open to one or more primaries. Should a secondary preferentially an IXFR for the requested SOA. Implementations differ in how long they store
request an XFR from a primary to which it already has an open XoT connection zone deltas and how many may be stored at any one time.</t>
or the one with the highest SOA (assuming it doesn't have a connection open to <t indent="0" pn="section-7.10.2-2">Just as with IXFR over TCP, after
it already)?</t> a failed IXFR, an IXoT client <bcp14>SHOULD</bcp14>
<t>Two extremes can be envisaged here. The first one can be considered a 'prefer request the AXFR on the already open XoT connection.</t>
red </section>
primary connection' model. In this case, the secondary continues to use one <section anchor="padding-of-ixot-responses" numbered="true" removeInRFC=
persistent connection to a single primary until it has reason not to. Reasons "false" toc="include" pn="section-7.10.3">
not to might include the primary repeatedly closing the connection, long query/r <name slugifiedName="name-padding-of-ixot-responses">Padding of IXoT R
esponse RTTs on esponses</name>
transfers or the SOA of the primary being an unacceptable lag behind the SOA of <t indent="0" pn="section-7.10.3-1">The goal of padding IXoT responses
an alternative primary.</t> is to obfuscate the incremental
<t>The other extreme can be considered a 'parallel primary connection' model. He changes to the zone between SOA updates to minimize information leakage abou
re, t
a secondary could keep multiple persistent connections open to all available zone update activity and growth. Both the size and timing of the IXoT respon
primaries and only request XFRs from the primary with the highest serial number. ses could
Since normally the number of secondaries and primaries in direct contact in a reveal information.</t>
transfer group is reasonably low this might be feasible if latency is the most <t indent="0" pn="section-7.10.3-2">IXFR responses can vary greatly in
significant concern.</t> size from the order of 100 bytes for one or
<t>Recommendation of a particular scheme is out of scope of this document, but two record updates to tens of thousands of bytes for large, dynamic DNSSEC-s
igned zones.
The frequency of IXFR responses can also depend greatly on if and how the zo
ne is DNSSEC
signed.</t>
<t indent="0" pn="section-7.10.3-3">In order to guarantee support for
future padding policies, it is stated here
that
secondary implementations <bcp14>MUST</bcp14> be resilient to receiving padd
ed IXoT
responses.</t>
<t indent="0" pn="section-7.10.3-4">Recommendation of specific policie
s 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 anchor="name-compression-and-maximum-payload-sizes" numbered="tru
e" removeInRFC="false" toc="include" pn="section-7.11">
<name slugifiedName="name-name-compression-and-maximu">Name Compression
and Maximum Payload Sizes</name>
<t indent="0" pn="section-7.11-1">It is noted here that name compression
<xref target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1
035"/> can be used in XFR
responses to reduce the size of the payload; however, the maximum value of the
offset that
can be used in the name compression pointer structure is 16384. For some DNS
implementations, this limits the size of an individual XFR response used in
practice to something around the order of 16 KB. In principle, larger
payload sizes can be supported for some responses with more sophisticated
approaches (e.g., by precalculating the maximum offset required).</t>
<t indent="0" pn="section-7.11-2">Implementations may wish to offer opti
ons to disable name compression for XoT
responses to enable larger payloads. This might be particularly helpful when
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 anchor="multi-primary-configurations" numbered="true" removeInRFC="
false" toc="include" pn="section-8">
<name slugifiedName="name-multi-primary-configuration">Multi-primary Confi
gurations</name>
<t indent="0" pn="section-8-1">This model can provide flexibility
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
then choose to send an XFR request to the primary with the highest SOA (or
based on other criteria, e.g., RTT).</t>
<t indent="0" pn="section-8-2">When using persistent connections, the seco
ndary may have a XoT connection
already open to one or more primaries. Should a secondary preferentially
request an XFR from a primary to which it already has an open XoT connection
or the one with the highest SOA (assuming it doesn't have a connection open to
it already)?</t>
<t indent="0" pn="section-8-3">Two extremes can be envisaged here. The fir
st one can be considered a 'preferred
primary connection' model. In this case, the secondary continues to use one
persistent connection to a single primary until it has reason not to. Reasons
not to might include the primary repeatedly closing the connection, long query
/response RTTs
on transfers, or the SOA of the primary being an unacceptable lag behind the S
OA of
an alternative primary.</t>
<t indent="0" pn="section-8-4">The other extreme can be considered a 'para
llel primary connection' model. Here,
a secondary could keep multiple persistent connections open to all available
primaries and only request XFRs from the primary with the highest serial numbe
r.
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 indent="0" pn="section-8-5">Recommendation of a particular scheme is ou
t 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" numbered="true" removeInRFC="fal
<section anchor="authentication-mechanisms"><name>Authentication mechanisms</nam se" toc="include" pn="section-9">
e> <name slugifiedName="name-authentication-mechanisms">Authentication Mechan
<t>To provide context to the requirements in <xref target="xot-transfers"></xref isms</name>
>, this <t indent="0" pn="section-9-1">To provide context to the requirements in <
section provides a brief summary of some of the existing authentication and xref target="xot-transfers" format="default" sectionFormat="of" derivedContent="
validation mechanisms (both transport independent and TLS specific) that are Section 7.5"/>, this
available when performing zone transfers. section provides a brief summary of some of the existing authentication and
<xref target="xot-authentication"></xref> then discusses in more details specifi validation mechanisms (both transport independent and TLS specific) that are
cally how a available when performing zone transfers.
combination of TLS authentication, TSIG and IP based ACLs interact for XoT.</t> <xref target="xot-authentication" format="default" sectionFormat="of" derivedC
<t>We classify the mechanisms based on the following properties:</t> ontent="Section 10"/> then discusses in more detail specifically how a
combination of TLS authentication, TSIG, and IP-based ACLs interact for XoT.</
<ul> t>
<li><t>'Data Origin Authentication' (DO): Authentication that the DNS message or <t indent="0" pn="section-9-2">In this document, the mechanisms are classi
iginated fied based on the following properties:</t>
from the party with whom credentials were shared, and of the data integrity <dl newline="true" spacing="normal" indent="3" pn="section-9-3">
of the message contents (the originating party may or may not be party <dt pn="section-9-3.1">Data Origin Authentication (DO):</dt>
operating the far end of a TCP/TLS connection in a 'proxy' scenario).</t> <dd pn="section-9-3.2">Authentication 1) of the fact that the DNS messag
</li> e originated
<li><t>'Channel Confidentiality' (CC): Confidentiality of the communication chan from the party with whom credentials were shared and 2) of the data integrit
nel between the y
client and server (i.e. the two end points of a TCP/TLS connection) from passive of the message contents (the originating party may or may not be the party
surveillance.</t> operating the far end of a TCP/TLS connection in a 'proxy' scenario).</dd>
</li> <dt pn="section-9-3.3">Channel Confidentiality (CC):</dt>
<li><t>'Channel Authentication' (CA): Authentication of the identity of party to <dd pn="section-9-3.4">Confidentiality of the communication channel betw
whom a TCP/TLS een the
connection is made (this might not be a direct connection between the primary client and server (i.e., the two endpoints of a TCP/TLS connection) from pas
and secondary in a proxy scenario).</t> sive
</li> surveillance.</dd>
</ul> <dt pn="section-9-3.5">Channel Authentication (CA):</dt>
<dd pn="section-9-3.6">Authentication of the identity of the party to wh
<section anchor="tsig"><name>TSIG</name> om a TCP/TLS
<t>TSIG <xref target="RFC8945"></xref> provides a mechanism for two or more part connection is made (this might not be a direct connection between the primar
ies to use shared y
secret keys which can then be used to create a message digest to protect and secondary in a proxy scenario).</dd>
individual DNS messages. This allows each party to authenticate that a request </dl>
or response (and the data in it) came from the other party, even if it was <section anchor="tsig" numbered="true" removeInRFC="false" toc="include" p
transmitted over an unsecured channel or via a proxy.</t> n="section-9.1">
<t>Properties: Data origin authentication</t> <name slugifiedName="name-tsig">TSIG</name>
</section> <t indent="0" pn="section-9.1-1">TSIG <xref target="RFC8945" format="def
ault" sectionFormat="of" derivedContent="RFC8945"/> provides a mechanism for two
<section anchor="sig-0"><name>SIG(0)</name> or more parties to use
<t>SIG(0) <xref target="RFC2931"></xref> similarly provides a mechanism to digit shared secret keys that can then be used to create a message digest to protect
ally sign a DNS individual DNS messages. This allows each party to authenticate that a request
message but uses public key authentication, where the public keys are stored in or response (and the data in it) came from the other party, even if it was
DNS as KEY RRs and a private key is stored at the signer.</t> transmitted over an unsecured channel or via a proxy.</t>
<t>Properties: Data origin authentication</t> <dl newline="false" spacing="normal" indent="3" pn="section-9.1-2">
</section> <dt pn="section-9.1-2.1">Properties:</dt>
<dd pn="section-9.1-2.2">Data origin authentication.</dd>
<section anchor="tls"><name>TLS</name> </dl>
</section>
<section anchor="opportunistic-tls"><name>Opportunistic TLS</name> <section anchor="sig-0" numbered="true" removeInRFC="false" toc="include"
<t>Opportunistic TLS for DoT is defined in <xref target="RFC8310"></xref> and ca pn="section-9.2">
n provide a defense against passive <name slugifiedName="name-sig0">SIG(0)</name>
surveillance, providing on-the-wire confidentiality. Essentially</t> <t indent="0" pn="section-9.2-1">SIG(0) <xref target="RFC2931" format="d
efault" sectionFormat="of" derivedContent="RFC2931"/> similarly provides a mecha
<ul> nism to digitally sign a
<li>clients that know authentication information for a server SHOULD try to auth DNS message but uses public key authentication, where the public keys are stor
enticate the server</li> ed in
<li>however they MAY fallback to using TLS without authentication and</li> DNS as KEY RRs and a private key is stored at the signer.</t>
<li>they MAY fallback to using cleartext if TLS is not available.</li> <dl newline="false" spacing="normal" indent="3" pn="section-9.2-2">
</ul> <dt pn="section-9.2-2.1">Properties:</dt>
<t>As such, it does not offer a defense against active attacks (e.g., an on path <dd pn="section-9.2-2.2">Data origin authentication.</dd>
active attacker </dl>
on the connection from client to server), and is not considered as useful for Xo </section>
T.</t> <section anchor="tls" numbered="true" removeInRFC="false" toc="include" pn
<t>Properties: None guaranteed.</t> ="section-9.3">
</section> <name slugifiedName="name-tls">TLS</name>
<section anchor="opportunistic-tls" numbered="true" removeInRFC="false"
<section anchor="strict-tls"><name>Strict TLS</name> toc="include" pn="section-9.3.1">
<t>Strict TLS for DoT <xref target="RFC8310"></xref> requires that a client is c <name slugifiedName="name-opportunistic-tls">Opportunistic TLS</name>
onfigured with an <t indent="0" pn="section-9.3.1-1">Opportunistic TLS for DoT is define
authentication domain name (and/or SPKI pinset) that MUST be used to d in <xref target="RFC8310" format="default" sectionFormat="of" derivedContent="
authenticate the TLS handshake with the server. If authentication of the server RFC8310"/> and can provide a
fails, the client will not proceed with the connection. This provides a defense defense against passive
for the client against active surveillance, providing client-to-server surveillance, providing on-the-wire confidentiality. Essentially:</t>
authentication and end-to-end channel confidentiality.</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<t>Properties: Channel confidentiality and channel authentication (of the server -9.3.1-2">
).</t> <li pn="section-9.3.1-2.1">if clients know authentication informatio
</section> n for a server, they
<bcp14>SHOULD</bcp14> try to authenticate the server,</li>
<section anchor="mutual-tls"><name>Mutual TLS</name> <li pn="section-9.3.1-2.2">if this fails or clients do not know the
<t>This is an extension to Strict TLS <xref target="RFC8310"></xref> which requi information, they <bcp14>MAY</bcp14>
res that a client is fallback to using TLS without authentication, or</li>
configured with an authentication domain name (and/or SPKI pinset) and a client <li pn="section-9.3.1-2.3">clients <bcp14>MAY</bcp14> fallback to us
certificate. The client offers the certificate for authentication by the server ing cleartext if TLS is not
and the client can authenticate the server the same way as in Strict TLS. This available.</li>
provides a defense for both parties against active surveillance, providing </ul>
bi-directional authentication and end-to-end channel confidentiality.</t> <t indent="0" pn="section-9.3.1-3">As such, it does not offer a defens
<t>Properties: Channel confidentiality and mutual channel authentication.</t> e against active attacks (e.g., an on-path active
</section> attacker on the connection from client to server) and is not considered as u
</section> seful for
XoT.</t>
<section anchor="ip-based-acl-on-the-primary"><name>IP Based ACL on the Primary< <dl newline="false" spacing="normal" indent="3" pn="section-9.3.1-4">
/name> <dt pn="section-9.3.1-4.1">Properties:</dt>
<t>Most DNS server implementations offer an option to configure an IP based Acce <dd pn="section-9.3.1-4.2">None guaranteed.</dd>
ss </dl>
Control List (ACL), which is often used in combination with TSIG based ACLs to </section>
restrict access to zone transfers on primary servers on a per query basis.</t> <section anchor="strict-tls" numbered="true" removeInRFC="false" toc="in
<t>This is also possible with XoT, but it must be noted that, as with TCP, the clude" pn="section-9.3.2">
implementation of such an ACL cannot be enforced on the primary until an XFR <name slugifiedName="name-strict-tls">Strict TLS</name>
request is received on an established connection.</t> <t indent="0" pn="section-9.3.2-1">Strict TLS for DoT <xref target="RF
<t>As discussed in <xref target="xot-server-connection-handling"></xref>, an IP C8310" format="default" sectionFormat="of" derivedContent="RFC8310"/> requires t
based per connection ACL hat a client is configured
could also be implemented where only TLS connections from recognized with an authentication domain name (and/or Subject Public Key Info (SPKI) pin
secondaries are accepted.</t> set) that
<t>Properties: Channel authentication of the client.</t> <bcp14>MUST</bcp14> be used to
</section> authenticate the TLS handshake with the server. If authentication of the serve
r
<section anchor="zonemd"><name>ZONEMD</name> fails, the client will not proceed with the connection. This provides a defens
<t>For completeness, we also describe Message Digest for DNS Zones (ZONEMD) e
<xref target="RFC8976"></xref> here. The message digest for the client against active surveillance, providing client-to-server
is a mechanism that can be used to verify the content of a standalone zone. It authentication and end-to-end channel confidentiality.</t>
is designed to be independent of the transmission channel or mechanism, allowing <dl newline="false" spacing="compact" indent="3" pn="section-9.3.2-2">
a general consumer of a zone to do origin authentication of the entire zone <dt pn="section-9.3.2-2.1">Properties:</dt>
contents. Note that the current version of <xref target="RFC8976"></xref> <dd pn="section-9.3.2-2.2">Channel confidentiality and channel authe
states:</t> ntication (of the server).</dd>
<t><tt>As specified herein, ZONEMD is impractical for large, dynamic zones due t </dl>
o the </section>
time and resources required for digest calculation. However, The ZONEMD record <section anchor="mutual-tls" numbered="true" removeInRFC="false" toc="in
is extensible so that new digest schemes may be added in the future to support clude" pn="section-9.3.3">
large, dynamic zones.</tt></t> <name slugifiedName="name-mutual-tls">Mutual TLS</name>
<t>It is complementary but orthogonal the above mechanisms; and can be used in <t indent="0" pn="section-9.3.3-1">This is an extension to Strict TLS
conjunction with XoT, but is not considered further here.</t> <xref target="RFC8310" format="default" sectionFormat="of" derivedContent="RFC83
</section> 10"/> that requires that a
</section> client is configured with an authentication domain name (and/or SPKI pin set)
and a client
<section anchor="xot-authentication"><name>XoT authentication</name> certificate. The client offers the certificate for authentication by the serve
<t>It is noted that zone transfer scenarios can vary from a simple single r,
primary/secondary relationship where both servers are under the control of a and the client can authenticate the server the same way as in Strict TLS. This
single operator to a complex hierarchical structure which includes proxies and provides a defense for both parties against active surveillance, providing
multiple operators. Each deployment scenario will require specific analysis to bidirectional authentication and end-to-end channel confidentiality.</t>
determine which combination of authentication methods are best suited to the <dl newline="false" spacing="compact" indent="3" pn="section-9.3.3-2">
deployment model in question.</t> <dt pn="section-9.3.3-2.1">Properties:</dt>
<t>The XoT authentication requirement specified in <xref target="xot-transfers"> <dd pn="section-9.3.3-2.2">Channel confidentiality and mutual channe
</xref> addresses the l authentication.</dd>
issue of ensuring that the transfers are encrypted between the two endpoints </dl>
directly involved in the current transfers. The following table summarizes the </section>
properties of a selection of the mechanisms discussed in </section>
<xref target="authentication-mechanisms"></xref>. The two letter acronyms for th <section anchor="ip-based-acl-on-the-primary" numbered="true" removeInRFC=
e properties are "false" toc="include" pn="section-9.4">
used below and (S) indicates the secondary and (P) indicates <name slugifiedName="name-ip-based-acl-on-the-primary">IP-Based ACL on t
the primary.</t> he Primary</name>
<table> <t indent="0" pn="section-9.4-1">Most DNS server implementations offer a
<thead> n option to configure an IP-based
<tr> ACL, which is often used in combination with TSIG-based ACLs to
<th align="left">Method</th> restrict access to zone transfers on primary servers on a per-query basis.</t>
<th align="center">DO(S)</th> <t indent="0" pn="section-9.4-2">This is also possible with XoT, but it
<th align="center">CC(S)</th> must be noted that, as with TCP, the
<th align="center">CA(S)</th> implementation of such an ACL cannot be enforced on the primary until an XFR
<th align="center">DO(P)</th> request is received on an established connection.</t>
<th align="center">CC(P)</th> <t indent="0" pn="section-9.4-3">As discussed in <xref target="xot-serve
<th align="center">CA(P)</th> r-connection-handling" format="default" sectionFormat="of" derivedContent="Appen
</tr> dix A"/>, an
</thead> IP-based per-connection ACL could also be implemented where only TLS connectio
ns from
<tbody> recognized secondaries are accepted.</t>
<tr> <dl newline="false" spacing="normal" indent="3" pn="section-9.4-4">
<td align="left">Strict TLS</td> <dt pn="section-9.4-4.1">Properties:</dt>
<td align="center"></td> <dd pn="section-9.4-4.2">Channel authentication of the client.</dd>
<td align="center">Y</td> </dl>
<td align="center">Y</td> </section>
<td align="center"></td> <section anchor="zonemd" numbered="true" removeInRFC="false" toc="include"
<td align="center">Y</td> pn="section-9.5">
<td align="center"></td> <name slugifiedName="name-zonemd">ZONEMD</name>
</tr> <t indent="0" pn="section-9.5-1">For completeness, ZONEMD
<xref target="RFC8976" format="default" sectionFormat="of" derivedContent="RFC
<tr> 8976"/> ("Message Digest for DNS Zones") is described here.
<td align="left">Mutual TLS</td> The ZONEMD message digest
<td align="center"></td> is a mechanism that can be used to verify the content of a standalone zone. It
<td align="center">Y</td> is designed to be independent of the transmission channel or mechanism, allowi
<td align="center">Y</td> ng
<td align="center"></td> a general consumer of a zone to do origin authentication of the entire zone
<td align="center">Y</td> contents. Note that the current version of <xref target="RFC8976" format="defa
<td align="center">Y</td> ult" sectionFormat="of" derivedContent="RFC8976"/>
</tr> states:</t>
<blockquote pn="section-9.5-2">As specified herein, ZONEMD is impractica
<tr> l for large, dynamic zones due to the
<td align="left">ACL on primary</td> time and resources required for digest calculation. However, the ZONEMD record
<td align="center"></td> is extensible so that new digest schemes may be added in the future to support
<td align="center"></td> large, dynamic zones.</blockquote>
<td align="center"></td> <t indent="0" pn="section-9.5-3">It is complementary but orthogonal to t
<td align="center"></td> he above mechanisms and can be used in
<td align="center"></td> conjunction with XoT but is not considered further here.</t>
<td align="center">Y</td> </section>
</tr> </section>
<section anchor="xot-authentication" numbered="true" removeInRFC="false" toc
<tr> ="include" pn="section-10">
<td align="left">TSIG</td> <name slugifiedName="name-xot-authentication">XoT Authentication</name>
<td align="center">Y</td> <t indent="0" pn="section-10-1">It is noted that zone transfer scenarios c
<td align="center"></td> an vary from a simple single
<td align="center"></td> primary/secondary relationship where both servers are under the control of a
<td align="center">Y</td> single operator to a complex hierarchical structure that includes proxies and
<td align="center"></td> multiple operators. Each deployment scenario will require specific analysis to
<td align="center"></td> determine which combination of authentication methods are best suited to the
</tr> deployment model in question.</t>
</tbody> <t indent="0" pn="section-10-2">The XoT authentication requirement specifi
</table><t>Table 1: Properties of Authentication methods for XoT</t> ed in <xref target="xot-transfers" format="default" sectionFormat="of" derivedCo
<t>Based on this analysis it can be seen that:</t> ntent="Section 7.5"/>
addresses the
<ul> issue of ensuring that the transfers are encrypted between the two endpoints
<li><t>Using just mutual TLS can be considered a standalone solution since both directly involved in the current transfers. The following table summarizes the
end points are properties of a selection of the mechanisms discussed in
cryptographically authenticated</t> <xref target="authentication-mechanisms" format="default" sectionFormat="of" d
</li> erivedContent="Section 9"/>. The two-letter abbreviations for the properties
<li><t>Using secondary side Strict TLS with a primary side IP ACL and TSIG/SIG(0 are used below: (S) indicates the secondary and (P) indicates
) combination provides the primary.</t>
sufficient protection to be acceptable.</t> <table anchor="table1" align="center" pn="table-1">
</li> <name slugifiedName="name-properties-of-authenticatio">Properties of Aut
</ul> hentication Methods for XoT</name>
<t>Using just an IP ACL could be susceptible to attacks that can spoof TCP IP <thead>
addresses, using TSIG/SIG(0) alone could be susceptible to attacks that were <tr>
able to capture such messages should they be accidentally sent in clear text by <th align="left" colspan="1" rowspan="1">Method</th>
any server with the key.</t> <th align="center" colspan="1" rowspan="1">DO(S)</th>
</section> <th align="center" colspan="1" rowspan="1">CC(S)</th>
<th align="center" colspan="1" rowspan="1">CA(S)</th>
<section anchor="policies-for-both-axot-and-ixot"><name>Policies for Both AXoT a <th align="center" colspan="1" rowspan="1">DO(P)</th>
nd IXoT</name> <th align="center" colspan="1" rowspan="1">CC(P)</th>
<t>Whilst the protection of the zone contents in a transfer between two end poin <th align="center" colspan="1" rowspan="1">CA(P)</th>
ts </tr>
can be provided by the XoT protocol, the protection of all the transfers of a </thead>
given zone requires operational administration and policy management.</t> <tbody>
<t>We call the entire group of servers involved in XFR for a particular set of <tr>
zones (all the primaries and all the secondaries) the 'transfer group'.</t> <td align="left" colspan="1" rowspan="1">Strict TLS</td>
<t>In order to assure the confidentiality of the zone information, the entire <td align="center" colspan="1" rowspan="1"/>
transfer group MUST have a consistent policy of using XoT. If any do not, this <td align="center" colspan="1" rowspan="1">Y</td>
is a weak link for attackers to exploit. For clarification, this means that <td align="center" colspan="1" rowspan="1">Y</td>
within any transfer group both AXFRs and IXFRs for a zone MUST all use XoT.</t> <td align="center" colspan="1" rowspan="1"/>
<t>An individual zone transfer is not considered protected by XoT unless <td align="center" colspan="1" rowspan="1">Y</td>
both the client and server are configured to use only XoT and the overall zone <td align="center" colspan="1" rowspan="1"/>
transfer is not considered protected until all members of the transfer group </tr>
are configured to use only XoT with all other transfers servers (see <xref targe <tr>
t="implementation-considerations"></xref>).</t> <td align="left" colspan="1" rowspan="1">Mutual TLS</td>
<t>A XoT policy MUST specify if</t> <td align="center" colspan="1" rowspan="1"/>
<td align="center" colspan="1" rowspan="1">Y</td>
<ul> <td align="center" colspan="1" rowspan="1">Y</td>
<li>mutual TLS is used and/or</li> <td align="center" colspan="1" rowspan="1"/>
<li>a IP ACL and TSIG/SIG(0) combination is used</li> <td align="center" colspan="1" rowspan="1">Y</td>
</ul> <td align="center" colspan="1" rowspan="1">Y</td>
<t>Since this may require configuration of a number of servers who may be under </tr>
the control of different operators the desired consistency could be hard to <tr>
enforce and audit in practice.</t> <td align="left" colspan="1" rowspan="1">ACL on primary</td>
<t>Certain aspects of the Policies can be relatively easily tested independently <td align="center" colspan="1" rowspan="1"/>
, <td align="center" colspan="1" rowspan="1"/>
e.g., by requesting zone transfers without TSIG, from unauthorized IP addresses <td align="center" colspan="1" rowspan="1"/>
or over cleartext DNS. Other aspects such as if a secondary will accept data <td align="center" colspan="1" rowspan="1"/>
without a TSIG digest or if secondaries are using Strict as opposed to <td align="center" colspan="1" rowspan="1"/>
Opportunistic TLS are more challenging.</t> <td align="center" colspan="1" rowspan="1">Y</td>
<t>The mechanics of co-ordinating or enforcing such policies are out of the scop </tr>
e <tr>
of this document but may be the subject of future operational guidance.</t> <td align="left" colspan="1" rowspan="1">TSIG</td>
</section> <td align="center" colspan="1" rowspan="1">Y</td>
<td align="center" colspan="1" rowspan="1"/>
<section anchor="implementation-considerations"><name>Implementation Considerati <td align="center" colspan="1" rowspan="1"/>
ons</name> <td align="center" colspan="1" rowspan="1">Y</td>
<t>Server implementations may want to also offer options that allow ACLs on a zo <td align="center" colspan="1" rowspan="1"/>
ne <td align="center" colspan="1" rowspan="1"/>
to specify that a specific client can use either XoT or TCP. This would allow </tr>
for flexibility while clients are migrating to XoT.</t> </tbody>
<t>Client implementations may similarly want to offer options to cater for the </table>
multi-primary case where the primaries are migrating to XoT.</t> <t indent="0" pn="section-10-4">Based on this analysis, it can be seen tha
</section> t:</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-10-
<section anchor="operational-considerations"><name>Operational Considerations</n 5">
ame> <li pn="section-10-5.1">Using just mutual TLS can be considered a standa
<t>If the options described in <xref target="implementation-considerations"></xr lone solution since both endpoints are
ef> are available, cryptographically authenticated.</li>
such configuration options MUST only be used in a 'migration mode', and <li pn="section-10-5.2">Using secondary-side Strict TLS with a primary-s
therefore should be used with great care.</t> ide IP-based ACL and TSIG/SIG(0) combination
<t>It is noted that use of a TLS proxy in front of the primary server is a simpl provides sufficient protection to be acceptable.</li>
e </ul>
deployment solution that can enable server side XoT.</t> <t indent="0" pn="section-10-6">Using just an IP-based ACL could be suscep
</section> tible to attacks that can spoof TCP IP
addresses; using TSIG/SIG(0) alone could be susceptible to attacks that were
<section anchor="iana-considerations"><name>IANA Considerations</name> able to capture such messages should they be accidentally sent in cleartext by
<t>None.</t> any server
</section> with the key.</t>
</section>
<section anchor="implementation-status"><name>Implementation Status</name> <section anchor="policies-for-both-axot-and-ixot" numbered="true" removeInRF
<t>[THIS SECTION TO BE REMOVED BEFORE PUBLICATION] This section records the stat C="false" toc="include" pn="section-11">
us <name slugifiedName="name-policies-for-both-axot-and-">Policies for Both A
of known implementations of the protocol defined by this specification at the XoT and IXoT</name>
time of posting of this Internet-Draft, and is based on a proposal described in <t indent="0" pn="section-11-1">Whilst the protection of the zone contents
<xref target="RFC7942"></xref>.</t> in a transfer between two endpoints
<t>A summary of current behavior and implementation status can be found here: <e can be provided by the XoT protocol, the protection of all the transfers of a
ref target="https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+St given zone requires operational administration and policy management.</t>
atus#DNSPrivacyImplementationStatus-XFR/XoTImplementationstatus">XoT implementat <t indent="0" pn="section-11-2">The entire group of servers involved in XF
ion status</eref></t> R for a particular set of
<t>Specific recent activity includes:</t> zones (all the primaries and all the secondaries) is called the 'transfer grou
p'.</t>
<ol> <t indent="0" pn="section-11-3">In order to assure the confidentiality of
<li><t>The 1.9.2 version of the zone information, the entire
<eref target="https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/Change transfer group <bcp14>MUST</bcp14> have a consistent policy of using XoT. If a
log">Unbound</eref> ny do not, this
includes an option to perform AXoT (instead of AXFR-over-TCP).</t> is a weak link for attackers to exploit. For clarification, this means that
</li> within any transfer group both AXFRs and IXFRs for a zone <bcp14>MUST</bcp14>
<li><t>There are currently open pull requests against NSD to implement</t> all use
XoT.</t>
<ol> <t indent="0" pn="section-11-4">An individual zone transfer is not conside
<li>Connection re-use by default during <eref target="https://github.com/NLnetLa red protected by XoT unless
bs/nsd/pull/145">XFR-over-TCP</eref></li> both the client and server are configured to use only XoT, and the overall zon
<li>Client side <eref target="https://github.com/NLnetLabs/nsd/pull/149">XoT</er e
ef></li> transfer is not considered protected until all members of the transfer group
</ol></li> are configured to use only XoT with all other transfers servers (see <xref tar
<li><t>Version 9.17.7 of BIND contained an initial implementation of DoT, implem get="implementation-considerations" format="default" sectionFormat="of" derivedC
entation of XoT is planned for early <eref target="https://gitlab.isc.org/isc-pr ontent="Section 12"/>).</t>
ojects/bind9/-/issues/1784">2021</eref></t> <t indent="0" pn="section-11-5">A XoT policy <bcp14>MUST</bcp14> specify i
</li> f:</t>
</ol> <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-11-
<t>Both items 1. and 2.2. listed above require the client (secondary) to 6">
authenticate the server (primary) using a configured authentication domain name <li pn="section-11-6.1">mutual TLS is used and/or</li>
if XoT is used.</t> <li pn="section-11-6.2">an IP-based ACL and TSIG/SIG(0) combination is u
</section> sed.</li>
</ul>
<section anchor="security-considerations"><name>Security Considerations</name> <t indent="0" pn="section-11-7">Since this may require configuration of a
<t>This document specifies a security measure against a DNS risk: the risk that number of servers who may be under
an the control of different operators, the desired consistency could be hard to
attacker collects entire DNS zones through eavesdropping on clear text DNS zone enforce and audit in practice.</t>
<t indent="0" pn="section-11-8">Certain aspects of the policies can be rel
atively easy to test independently,
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 indent="0" pn="section-11-9">The mechanics of coordinating or enforcing
such policies are out of the scope
of this document but may be the subject of future operational guidance.</t>
</section>
<section anchor="implementation-considerations" numbered="true" removeInRFC=
"false" toc="include" pn="section-12">
<name slugifiedName="name-implementation-consideratio">Implementation Cons
iderations</name>
<t indent="0" pn="section-12-1">Server implementations may want to also of
fer options that allow ACLs on a zone
to specify that a specific client can use either XoT or TCP. This would allow
for flexibility while clients are migrating to XoT.</t>
<t indent="0" pn="section-12-2">Client implementations may similarly want
to offer options to cater to the
multi-primary case where the primaries are migrating to XoT.</t>
</section>
<section anchor="operational-considerations" numbered="true" removeInRFC="fa
lse" toc="include" pn="section-13">
<name slugifiedName="name-operational-considerations">Operational Consider
ations</name>
<t indent="0" pn="section-13-1">If the options described in <xref target="
implementation-considerations" format="default" sectionFormat="of" derivedConten
t="Section 12"/> 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 indent="0" pn="section-13-2">It is noted that use of a TLS proxy in fro
nt of the primary server is a simple
deployment solution that can enable server-side XoT.</t>
</section>
<section anchor="iana-considerations" numbered="true" removeInRFC="false" to
c="include" pn="section-14">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t indent="0" pn="section-14-1">This document has no IANA actions.</t>
</section>
<section anchor="security-considerations" numbered="true" removeInRFC="false
" toc="include" pn="section-15">
<name slugifiedName="name-security-considerations">Security Considerations
</name>
<t indent="0" pn="section-15-1">This document specifies a security measure
against a DNS risk: the risk that an
attacker collects entire DNS zones through eavesdropping on cleartext DNS zone
transfers.</t> transfers.</t>
<t>This does not mitigate:</t> <t indent="0" pn="section-15-2">This does not mitigate:</t>
<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-15-
<ul> 3">
<li>the risk that some level of zone activity might be inferred by observing zon <li pn="section-15-3.1">the risk that some level of zone activity might
e be inferred by observing zone
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 pn="section-15-3.2">the risk that hidden primaries might be inferred
observation of encrypted connections.</li> or identified via
<li>the risk of zone contents being obtained via zone enumeration techniques.</l observation of encrypted connections, or</li>
i> <li pn="section-15-3.3">the risk of zone contents being obtained via zon
</ul> e enumeration techniques.</li>
<t>Security concerns of DoT are outlined in <xref target="RFC7858"></xref> and < </ul>
xref target="RFC8310"></xref>.</t> <t indent="0" pn="section-15-4">Security concerns of DoT are outlined in <
</section> xref target="RFC7858" format="default" sectionFormat="of" derivedContent="RFC785
8"/> and <xref target="RFC8310" format="default" sectionFormat="of" derivedConte
<section anchor="acknowledgements"><name>Acknowledgements</name> nt="RFC8310"/>.</t>
<t>The authors thank Tony Finch, Benno Overeinder, Shumon Huque </section>
and Tim Wicinski and many other members of DPRIVE for review and discussions.</t </middle>
> <back>
<t>The authors particularly thank Peter van Dijk, Ondrej Sury, Brian Dickson and <displayreference target="I-D.ietf-dprive-dnsoquic" to="DPRIVE-DNSOQUIC"/>
several other open source DNS implementers for valuable discussion and <displayreference target="I-D.ietf-tls-esni" to="TLS-ESNI"/>
clarification on the issue associated with pipelining XFR queries and handling <displayreference target="I-D.vcelak-nsec5" to="NSEC5"/>
out-of-order/intermingled responses.</t> <references pn="section-16">
</section> <name slugifiedName="name-references"> References</name>
<references pn="section-16.1">
<section anchor="contributors"><name>Contributors</name> <name slugifiedName="name-normative-references">Normative References</na
<t>Significant contributions to the document were made by:</t> me>
<t>Han Zhang <br /> <reference anchor="DoT-ALPN" target="https://www.iana.org/assignments/tl
Salesforce<br /> s-extensiontype-values/" quoteTitle="true" derivedAnchor="DoT-ALPN">
San Francisco, CA<br /> <front>
United States</t> <title>TLS Application-Layer Protocol Negotiation (ALPN) Protocol ID
<t>Email: hzhang@salesforce.com</t> s</title>
</section> <author>
<organization showOnFrontPage="true">IANA</organization>
<section anchor="changelog"><name>Changelog</name> </author>
<t>[THIS SECTION TO BE REMOVED BEFORE PUBLICATION]</t> </front>
<t>draft-ietf-dprive-xfr-over-tls-12</t> </reference>
<reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1
<ul> 034" quoteTitle="true" derivedAnchor="RFC1034">
<li>Changes from IESG review</li> <front>
<li>Add section 8.1 on the requirement to use the DoT ALPN</li> <title>Domain names - concepts and facilities</title>
<li><t>Modify the one of the options for validation of a client from just an IP <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockape
ACL to a combination of tris">
IP ACL and TSIG/SIG(0)</t> <organization showOnFrontPage="true"/>
</author>
<ul> <date year="1987" month="November"/>
<li>Update Abstract and Introduction with clear descriptions of how earlier spec <abstract>
ifications are updated</li> <t indent="0">This RFC is the revised basic definition of The Doma
<li>Add reference on NSEC3 attacks</li> in Name System. It obsoletes RFC-882. This memo describes the domain style nam
<li>Justify use of SHOULD in sections 7.3.2 and 7.3.3.</li> es and their used for host address look up and electronic mail forwarding. It d
<li>Clarify the Appendix is non-normative</li> iscusses the clients and servers in the domain name system and the protocol used
<li>Numerous typos and editorial improvements.</li> between them.</t>
<li>Use xml2rfc v3 (some format changes occur as a result)</li> </abstract>
</ul></li> </front>
</ul> <seriesInfo name="STD" value="13"/>
<t>draft-ietf-dprive-xfr-over-tls-11</t> <seriesInfo name="RFC" value="1034"/>
<seriesInfo name="DOI" value="10.17487/RFC1034"/>
<ul> </reference>
<li>Fix definition update missed in -10</li> <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1
</ul> 035" quoteTitle="true" derivedAnchor="RFC1035">
<t>draft-ietf-dprive-xfr-over-tls-10</t> <front>
<title>Domain names - implementation and specification</title>
<ul> <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockape
<li>Address issued raised from IETF Last Call</li> tris">
</ul> <organization showOnFrontPage="true"/>
<t>draft-ietf-dprive-xfr-over-tls-09</t> </author>
<date year="1987" month="November"/>
<ul> <abstract>
<li>Address issued raised in the AD review</li> <t indent="0">This RFC is the revised specification of the protoco
</ul> l and format used in the implementation of the Domain Name System. It obsoletes
<t>draft-ietf-dprive-xfr-over-tls-08</t> RFC-883. This memo documents the details of the domain name client - server com
munication.</t>
<ul> </abstract>
<li>RFC2845 -&gt; (obsoleted by) RFC8945</li> </front>
<li>I-D.ietf-dnsop-dns-zone-digest -&gt; RFC8976</li> <seriesInfo name="STD" value="13"/>
<li>Minor editorial changes + email update</li> <seriesInfo name="RFC" value="1035"/>
</ul> <seriesInfo name="DOI" value="10.17487/RFC1035"/>
<t>draft-ietf-dprive-xfr-over-tls-07</t> </reference>
<reference anchor="RFC1995" target="https://www.rfc-editor.org/info/rfc1
<ul> 995" quoteTitle="true" derivedAnchor="RFC1995">
<li>Reference RFC7942 in the implementation status section</li> <front>
<li>Convert the URIs that will remain on publication to references</li> <title>Incremental Zone Transfer in DNS</title>
<li>Correct typos in acknowledgments</li> <author initials="M." surname="Ohta" fullname="M. Ohta">
</ul> <organization showOnFrontPage="true"/>
<t>draft-ietf-dprive-xfr-over-tls-06</t> </author>
<date year="1996" month="August"/>
<ul> <abstract>
<li>Update text relating to pipelining and connection reuse after WGLC comments. <t indent="0">This document proposes extensions to the DNS protoco
</li> ls to provide an incremental zone transfer (IXFR) mechanism. [STANDARDS-TRACK]<
<li>Add link to implementation status matrix</li> /t>
<li>Various typos</li> </abstract>
</ul> </front>
<t>draft-ietf-dprive-xfr-over-tls-05</t> <seriesInfo name="RFC" value="1995"/>
<seriesInfo name="DOI" value="10.17487/RFC1995"/>
<ul> </reference>
<li>Remove the open questions that received no comments.</li> <reference anchor="RFC1996" target="https://www.rfc-editor.org/info/rfc1
<li>Add more detail to the implementation section</li> 996" quoteTitle="true" derivedAnchor="RFC1996">
</ul> <front>
<t>draft-ietf-dprive-xfr-over-tls-04</t> <title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTI
FY)</title>
<ul> <author initials="P." surname="Vixie" fullname="P. Vixie">
<li>Add Github repository</li> <organization showOnFrontPage="true"/>
<li>Fix typos and references and improve layout.</li> </author>
</ul> <date year="1996" month="August"/>
<t>draft-ietf-dprive-xfr-over-tls-03</t> <abstract>
<t indent="0">This memo describes the NOTIFY opcode for DNS, by wh
<ul> ich a master server advises a set of slave servers that the master's data has be
<li>Remove propose to use ALPN</li> en changed and that a query should be initiated to discover the new data. [STAND
<li>Clarify updates to both RFC1995 and RFC5936 by adding specific sections on t ARDS-TRACK]</t>
his</li> </abstract>
<li>Add a section on the threat model</li> </front>
<li>Convert all SVG diagrams to ASCII art</li> <seriesInfo name="RFC" value="1996"/>
<li>Add discussions on concurrency limits</li> <seriesInfo name="DOI" value="10.17487/RFC1996"/>
<li>Add discussions on Extended DNS error codes</li> </reference>
<li>Re-work authentication requirements and discussion</li> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
<li>Add appendix discussion TLS connection management</li> 119" quoteTitle="true" derivedAnchor="RFC2119">
</ul> <front>
<t>draft-ietf-dprive-xfr-over-tls-02</t> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<ul> <author initials="S." surname="Bradner" fullname="S. Bradner">
<li>Significantly update descriptions for both AXoT and IXoT for message and <organization showOnFrontPage="true"/>
connection handling taking into account previous specifications in more detail</ </author>
li> <date year="1997" month="March"/>
<li>Add use of APLN and limitations on traffic on XoT connections.</li> <abstract>
<li>Add new discussions of padding for both AXoT and IXoT</li> <t indent="0">In many standards track documents several words are
<li>Add text on SIG(0)</li> used to signify the requirements in the specification. These words are often ca
<li>Update security considerations</li> pitalized. This document defines these words as they should be interpreted in IE
<li>Move multi-primary considerations to earlier as they are related to connecti TF documents. This document specifies an Internet Best Current Practices for th
on e Internet Community, and requests discussion and suggestions for improvements.<
handling</li> /t>
</ul> </abstract>
<t>draft-ietf-dprive-xfr-over-tls-01</t> </front>
<seriesInfo name="BCP" value="14"/>
<ul> <seriesInfo name="RFC" value="2119"/>
<li>Minor editorial updates</li> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
<li>Add requirement for TLS 1.3. or later</li> </reference>
</ul> <reference anchor="RFC2931" target="https://www.rfc-editor.org/info/rfc2
<t>draft-ietf-dprive-xfr-over-tls-00</t> 931" quoteTitle="true" derivedAnchor="RFC2931">
<front>
<ul> <title>DNS Request and Transaction Signatures ( SIG(0)s )</title>
<li>Rename after adoption and reference update.</li> <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3
<li>Add placeholder for SIG(0) discussion</li> rd">
<li>Update section on ZONEMD</li> <organization showOnFrontPage="true"/>
</ul> </author>
<t>draft-hzpa-dprive-xfr-over-tls-02</t> <date year="2000" month="September"/>
<abstract>
<ul> <t indent="0">This document describes the minor but non-interopera
<li>Substantial re-work of the document.</li> ble changes in Request and Transaction signature resource records ( SIG(0)s ) th
</ul> at implementation experience has deemed necessary. [STANDARDS-TRACK]</t>
<t>draft-hzpa-dprive-xfr-over-tls-01</t> </abstract>
</front>
<ul> <seriesInfo name="RFC" value="2931"/>
<li>Editorial changes, updates to references.</li> <seriesInfo name="DOI" value="10.17487/RFC2931"/>
</ul> </reference>
<t>draft-hzpa-dprive-xfr-over-tls-00</t> <reference anchor="RFC5936" target="https://www.rfc-editor.org/info/rfc5
936" quoteTitle="true" derivedAnchor="RFC5936">
<ul> <front>
<li>Initial commit</li> <title>DNS Zone Transfer Protocol (AXFR)</title>
</ul> <author initials="E." surname="Lewis" fullname="E. Lewis">
<t>[-@?I-D.ietf-tls-esni]</t> <organization showOnFrontPage="true"/>
</section> </author>
<author initials="A." surname="Hoenes" fullname="A. Hoenes" role="ed
</middle> itor">
<organization showOnFrontPage="true"/>
<back> </author>
<references><name>Normative References</name> <date year="2010" month="June"/>
<reference anchor="DoT-ALPN" target="https://www.iana.org/assignments/tls-extens <abstract>
iontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids"> <t indent="0">The standard means within the Domain Name System pro
<front> tocol for maintaining coherence among a zone's authoritative name servers consis
<title>TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs</title ts of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms
> and is defined in RFC 1034 and RFC 1035.</t>
<author> <t indent="0">The definition of AXFR has proven insufficient in de
<organization>IANA</organization> tail, thereby forcing implementations intended to be compliant to make assumptio
</author> ns, impeding interoperability. Yet today we have a satisfactory set of implemen
<date year="2021"></date> tations that do interoperate. This document is a new definition of AXFR -- new
</front> in the sense that it records an accurate definition of an interoperable AXFR mec
</reference> hanism. [STANDARDS-TRACK]</t>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034. </abstract>
xml"/> </front>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035. <seriesInfo name="RFC" value="5936"/>
xml"/> <seriesInfo name="DOI" value="10.17487/RFC5936"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1995. </reference>
xml"/> <reference anchor="RFC6973" target="https://www.rfc-editor.org/info/rfc6
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1996. 973" quoteTitle="true" derivedAnchor="RFC6973">
xml"/> <front>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119. <title>Privacy Considerations for Internet Protocols</title>
xml"/> <author initials="A." surname="Cooper" fullname="A. Cooper">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2931. <organization showOnFrontPage="true"/>
xml"/> </author>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5936. <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
xml"/> <organization showOnFrontPage="true"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6973. </author>
xml"/> <author initials="B." surname="Aboba" fullname="B. Aboba">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7766. <organization showOnFrontPage="true"/>
xml"/> </author>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7828. <author initials="J." surname="Peterson" fullname="J. Peterson">
xml"/> <organization showOnFrontPage="true"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7858. </author>
xml"/> <author initials="J." surname="Morris" fullname="J. Morris">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174. <organization showOnFrontPage="true"/>
xml"/> </author>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8310. <author initials="M." surname="Hansen" fullname="M. Hansen">
xml"/> <organization showOnFrontPage="true"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446. </author>
xml"/> <author initials="R." surname="Smith" fullname="R. Smith">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499. <organization showOnFrontPage="true"/>
xml"/> </author>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8914. <date year="2013" month="July"/>
xml"/> <abstract>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8945. <t indent="0">This document offers guidance for developing privacy
xml"/> considerations for inclusion in protocol specifications. It aims to make desig
</references> ners, implementers, and users of Internet protocols aware of privacy-related des
<references><name>Informative References</name> ign choices. It suggests that whether any individual RFC warrants a specific pr
<reference anchor="BIND" target="https://www.isc.org/bind/"> ivacy considerations section will depend on the document's content.</t>
<front> </abstract>
<title>BIND 9.16.16</title> </front>
<author> <seriesInfo name="RFC" value="6973"/>
<organization>ISC</organization> <seriesInfo name="DOI" value="10.17487/RFC6973"/>
</author> </reference>
<date year="2021"></date> <reference anchor="RFC7766" target="https://www.rfc-editor.org/info/rfc7
</front> 766" quoteTitle="true" derivedAnchor="RFC7766">
</reference> <front>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i <title>DNS Transport over TCP - Implementation Requirements</title>
etf-dprive-dnsoquic.xml"/> <author initials="J." surname="Dickinson" fullname="J. Dickinson">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i <organization showOnFrontPage="true"/>
etf-dprive-phase2-requirements.xml"/> </author>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i <author initials="S." surname="Dickinson" fullname="S. Dickinson">
etf-dprive-rfc7626-bis.xml"/> <organization showOnFrontPage="true"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i </author>
etf-tls-esni.xml"/> <author initials="R." surname="Bellis" fullname="R. Bellis">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.v <organization showOnFrontPage="true"/>
celak-nsec5.xml"/> </author>
<reference anchor="NSD" target="https://www.nlnetlabs.nl/projects/nsd/about/"> <author initials="A." surname="Mankin" fullname="A. Mankin">
<front> <organization showOnFrontPage="true"/>
<title>NSD 4.3.6</title> </author>
<author> <author initials="D." surname="Wessels" fullname="D. Wessels">
<organization>NLnet Labs</organization> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2021"></date> <date year="2016" month="March"/>
</front> <abstract>
</reference> <t indent="0">This document specifies the requirement for support
<reference anchor="NSEC3-attacks" target="https://www.cs.bu.edu/~goldbe/papers/n of TCP as a transport protocol for DNS implementations and provides guidelines t
sec3attacks.pdf"> owards DNS-over-TCP performance on par with that of DNS-over-UDP. This document
<front> obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.</t>
<title>Stretching NSEC3 to the Limit:&#xA;Efficient Zone Enumeration Attacks </abstract>
on NSEC3 Variants</title> </front>
<author fullname="Sharon Goldberg" initials="S." surname="Goldberg"> <seriesInfo name="RFC" value="7766"/>
<organization> Boston University, Department of Computer Science</organiza <seriesInfo name="DOI" value="10.17487/RFC7766"/>
tion> </reference>
</author> <reference anchor="RFC7828" target="https://www.rfc-editor.org/info/rfc7
<author fullname="Moni Naor" initials="N." surname="Naor"> 828" quoteTitle="true" derivedAnchor="RFC7828">
<organization>Weizmann Institute of Science, Department of Computer Scienc <front>
e and Applied Mathematics</organization> <title>The edns-tcp-keepalive EDNS0 Option</title>
</author> <author initials="P." surname="Wouters" fullname="P. Wouters">
<author fullname="Dimitrios Papadopoulos" initials="D." surname="Papadopoulo <organization showOnFrontPage="true"/>
s"> </author>
<organization> Boston University, Department of Computer Science</organiza <author initials="J." surname="Abley" fullname="J. Abley">
tion> <organization showOnFrontPage="true"/>
</author> </author>
<author fullname="Leonid Reyzin" initials="L." surname="Reyzin"> <author initials="S." surname="Dickinson" fullname="S. Dickinson">
<organization> Boston University, Department of Computer Science</organiza <organization showOnFrontPage="true"/>
tion> </author>
</author> <author initials="R." surname="Bellis" fullname="R. Bellis">
<author fullname="Sachin Vasant" initials="S." surname="Vasant"> <organization showOnFrontPage="true"/>
<organization> Boston University, Department of Computer Science</organiza </author>
tion> <date year="2016" month="April"/>
</author> <abstract>
<author fullname="Asaf Ziv" initials="A." surname="Ziv"> <t indent="0">DNS messages between clients and servers may be rece
<organization>Weizmann Institute of Science, Department of Computer Scienc ived over either UDP or TCP. UDP transport involves keeping less state on a bus
e and Applied Mathematics</organization> y server, but can cause truncation and retries over TCP. Additionally, UDP can
</author> be exploited for reflection attacks. Using TCP would reduce retransmits and amp
<date year="2015"></date> lification. However, clients commonly use TCP only for retries and servers typi
</front> cally use idle timeouts on the order of seconds.</t>
</reference> <t indent="0">This document defines an EDNS0 option ("edns-tcp-kee
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1982. palive") that allows DNS servers to signal a variable idle timeout. This signal
xml"/> ling encourages the use of long-lived TCP connections by allowing the state asso
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5155. ciated with TCP transport to be managed effectively with minimal impact on the D
xml"/> NS transaction time.</t>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6891. </abstract>
xml"/> </front>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7942. <seriesInfo name="RFC" value="7828"/>
xml"/> <seriesInfo name="DOI" value="10.17487/RFC7828"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8484. </reference>
xml"/> <reference anchor="RFC7858" target="https://www.rfc-editor.org/info/rfc7
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8976. 858" quoteTitle="true" derivedAnchor="RFC7858">
xml"/> <front>
<reference anchor="nist-guide" target="https://nvlpubs.nist.gov/nistpubs/Special <title>Specification for DNS over Transport Layer Security (TLS)</ti
Publications/NIST.SP.800-81-2.pdf"> tle>
<front> <author initials="Z." surname="Hu" fullname="Z. Hu">
<title>Secure Domain Name System (DNS) Deployment Guide</title> <organization showOnFrontPage="true"/>
<author fullname="Ramaswamy Chandramouli" initials="R." surname="Chandramoul </author>
i"> <author initials="L." surname="Zhu" fullname="L. Zhu">
<organization>NIST</organization> <organization showOnFrontPage="true"/>
</author> </author>
<author fullname="Scott Rose" initials="S." surname="Rose"> <author initials="J." surname="Heidemann" fullname="J. Heidemann">
<organization>NIST</organization> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2013"></date> <author initials="A." surname="Mankin" fullname="A. Mankin">
</front> <organization showOnFrontPage="true"/>
</reference> </author>
</references> <author initials="D." surname="Wessels" fullname="D. Wessels">
<organization showOnFrontPage="true"/>
<section anchor="xot-server-connection-handling"><name>XoT server connection han </author>
dling</name> <author initials="P." surname="Hoffman" fullname="P. Hoffman">
<t>This appendix provides a non-normative outline of the pros and cons of XoT se <organization showOnFrontPage="true"/>
rver connection </author>
handling options.</t> <date year="2016" month="May"/>
<t>For completeness, it is noted that an earlier version of the specification <abstract>
suggested using a XoT specific ALPN to negotiate TLS connections that supported <t indent="0">This document describes the use of Transport Layer S
only a limited set of queries (SOA, XRFs), however, this did not gain support. ecurity (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates
Reasons given included additional code complexity and the fact that XoT and ADoT opportunities for eavesdropping and on-path tampering with DNS queries in the n
are both etwork, such as discussed in RFC 7626. In addition, this document specifies two
DNS wire format and so should share the <tt>dot</tt> ALPN.</t> usage profiles for DNS over TLS and provides advice on performance consideratio
ns to minimize overhead from using TCP and TLS with DNS.</t>
<section anchor="only-listen-on-tls-on-a-specific-ip-address"><name>Only listen <t indent="0">This document focuses on securing stub-to-recursive
on TLS on a specific IP address</name> traffic, as per the charter of the DPRIVE Working Group. It does not prevent fu
<t>Obviously a nameserver which hosts a zone and services queries for the zone o ture applications of the protocol to recursive-to-authoritative traffic.</t>
n </abstract>
an IP address published in an NS record may wish to use a separate IP address </front>
for listening on TLS for XoT, only publishing that address to its secondaries.</ <seriesInfo name="RFC" value="7858"/>
t> <seriesInfo name="DOI" value="10.17487/RFC7858"/>
<t>Pros: Probing of the public IP address will show no support for TLS. ACLs wil </reference>
l <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
prevent zone transfer on all transports on a per query basis.</t> 174" quoteTitle="true" derivedAnchor="RFC8174">
<t>Cons: Attackers passively observing traffic will still be able to observe TLS <front>
connections to the separate address.</t> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
</section> tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<section anchor="client-specific-tls-acceptance"><name>Client specific TLS accep <organization showOnFrontPage="true"/>
tance</name> </author>
<t>Primaries that include IP based ACLs and/or mutual TLS in their authenticatio <date year="2017" month="May"/>
n models <abstract>
have the option of only accepting TLS connections from authorized clients. This <t indent="0">RFC 2119 specifies common key words that may be used
could be implemented using a proxy or directly in DNS implementation.</t> in protocol specifications. This document aims to reduce the ambiguity by cla
<t>Pros: Connection management happens at setup time. The maximum number of TLS rifying that only UPPERCASE usage of the key words have the defined special mea
connections a server will have to support can be easily assessed. Once the nings.</t>
connection is accepted the server might well be willing to answer any query on </abstract>
that connection since it is coming from a configured secondary and a specific </front>
response policy on the connection may not be needed (see below).</t> <seriesInfo name="BCP" value="14"/>
<t>Cons: Currently, none of the major open source DNS authoritative <seriesInfo name="RFC" value="8174"/>
implementations support such an option.</t> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</section> </reference>
<reference anchor="RFC8310" target="https://www.rfc-editor.org/info/rfc8
<section anchor="sni-based-tls-acceptance"><name>SNI based TLS acceptance</name> 310" quoteTitle="true" derivedAnchor="RFC8310">
<t>Primaries could also choose to only accept TLS connections based on an SNI th <front>
at <title>Usage Profiles for DNS over TLS and DNS over DTLS</title>
was published only to their secondaries.</t> <author initials="S." surname="Dickinson" fullname="S. Dickinson">
<t>Pros: Reduces the number of accepted connections.</t> <organization showOnFrontPage="true"/>
<t>Cons: As above. Also, this is not a recommended use of SNI. For SNIs sent in </author>
the <author initials="D." surname="Gillmor" fullname="D. Gillmor">
clear, this would still allow attackers passively observing traffic to <organization showOnFrontPage="true"/>
potentially abuse this mechanism. The use of Encrypted Client Hello </author>
<xref target="I-D.ietf-tls-esni"></xref> may be of use here.</t> <author initials="T." surname="Reddy" fullname="T. Reddy">
</section> <organization showOnFrontPage="true"/>
</author>
<date year="2018" month="March"/>
<abstract>
<t indent="0">This document discusses usage profiles, based on one
or more authentication mechanisms, which can be used for DNS over Transport Lay
er Security (TLS) or Datagram TLS (DTLS). These profiles can increase the priva
cy of DNS transactions compared to using only cleartext DNS. This document also
specifies new authentication mechanisms -- it describes several ways that a DNS
client can use an authentication domain name to authenticate a (D)TLS connectio
n to a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS cl
ients and servers implementing DNS over (D)TLS. This document updates RFC 7858.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8310"/>
<seriesInfo name="DOI" value="10.17487/RFC8310"/>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446" quoteTitle="true" derivedAnchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t indent="0">This document specifies version 1.3 of the Transport
Layer Security (TLS) protocol. TLS allows client/server applications to commun
icate over the Internet in a way that is designed to prevent eavesdropping, tamp
ering, and message forgery.</t>
<t indent="0">This document updates RFCs 5705 and 6066, and obsole
tes RFCs 5077, 5246, and 6961. This document also specifies new requirements fo
r TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8
499" quoteTitle="true" derivedAnchor="RFC8499">
<front>
<title>DNS Terminology</title>
<author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Sullivan" fullname="A. Sullivan">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Fujiwara" fullname="K. Fujiwara">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="January"/>
<abstract>
<t indent="0">The Domain Name System (DNS) is defined in literally
dozens of different RFCs. The terminology used by implementers and developers
of DNS protocols, and by operators of DNS systems, has sometimes changed in the
decades since the DNS was first defined. This document gives current definition
s for many of the terms used in the DNS in a single document.</t>
<t indent="0">This document obsoletes RFC 7719 and updates RFC 230
8.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="219"/>
<seriesInfo name="RFC" value="8499"/>
<seriesInfo name="DOI" value="10.17487/RFC8499"/>
</reference>
<reference anchor="RFC8914" target="https://www.rfc-editor.org/info/rfc8
914" quoteTitle="true" derivedAnchor="RFC8914">
<front>
<title>Extended DNS Errors</title>
<author initials="W." surname="Kumari" fullname="W. Kumari">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Hunt" fullname="E. Hunt">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Arends" fullname="R. Arends">
<organization showOnFrontPage="true"/>
</author>
<author initials="W." surname="Hardaker" fullname="W. Hardaker">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Lawrence" fullname="D. Lawrence">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="October"/>
<abstract>
<t indent="0">This document defines an extensible method to return
additional information about the cause of DNS errors. Though created primarily
to extend SERVFAIL to provide additional information about the cause of DNS and
DNSSEC failures, the Extended DNS Errors option defined in this document allows
all response types to contain extended error information. Extended DNS Error inf
ormation does not change the processing of RCODEs.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8914"/>
<seriesInfo name="DOI" value="10.17487/RFC8914"/>
</reference>
<reference anchor="RFC8945" target="https://www.rfc-editor.org/info/rfc8
945" quoteTitle="true" derivedAnchor="RFC8945">
<front>
<title>Secret Key Transaction Authentication for DNS (TSIG)</title>
<author initials="F." surname="Dupont" fullname="F. Dupont">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Morris" fullname="S. Morris">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Vixie" fullname="P. Vixie">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3
rd">
<organization showOnFrontPage="true"/>
</author>
<author initials="O." surname="Gudmundsson" fullname="O. Gudmundsson
">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Wellington" fullname="B. Wellington">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="November"/>
<abstract>
<t indent="0">This document describes a protocol for transaction-l
evel authentication using shared secrets and one-way hashing. It can be used to
authenticate dynamic updates to a DNS zone as coming from an approved client or
to authenticate responses as coming from an approved name server.</t>
<t indent="0">No recommendation is made here for distributing the
shared secrets; it is expected that a network administrator will statically conf
igure name servers and clients using some out-of-band mechanism.</t>
<t indent="0">This document obsoletes RFCs 2845 and 4635.</t>
</abstract>
</front>
<seriesInfo name="STD" value="93"/>
<seriesInfo name="RFC" value="8945"/>
<seriesInfo name="DOI" value="10.17487/RFC8945"/>
</reference>
</references>
<references pn="section-16.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="BIND" target="https://www.isc.org/bind/" quoteTitle="
true" derivedAnchor="BIND">
<front>
<title>BIND 9.16.16</title>
<author>
<organization showOnFrontPage="true">ISC</organization>
</author>
</front>
</reference>
<reference anchor="I-D.ietf-dprive-dnsoquic" quoteTitle="true" target="h
ttps://datatracker.ietf.org/doc/html/draft-ietf-dprive-dnsoquic-03" derivedAncho
r="DPRIVE-DNSOQUIC">
<front>
<title>Specification of DNS over Dedicated QUIC Connections</title>
<author initials="C." surname="Huitema" fullname="Christian Huitema"
>
<organization showOnFrontPage="true">Private Octopus Inc.</organiz
ation>
</author>
<author initials="S." surname="Dickinson" fullname="Sara Dickinson">
<organization showOnFrontPage="true">Sinodun IT</organization>
</author>
<author initials="A." surname="Mankin" fullname="Allison Mankin">
<organization showOnFrontPage="true">Salesforce</organization>
</author>
<date month="July" day="12" year="2021"/>
<abstract>
<t indent="0"> This document describes the use of QUIC to provid
e transport privacy
for DNS. The encryption provided by QUIC has similar properties to
that provided by TLS, while QUIC transport eliminates the head-of-
line blocking issues inherent with TCP and provides more efficient
error corrections than UDP. DNS over QUIC (DoQ) has privacy
properties similar to DNS over TLS (DoT) specified in RFC7858, and
latency characteristics similar to classic DNS over UDP.
<section anchor="transport-specific-response-policies"><name>Transport specific </t>
response policies</name> </abstract>
<t>Some primaries might rely on TSIG/SIG(0) combined with per-query IP based </front>
ACLs to authenticate secondaries. In this case the primary must accept all <seriesInfo name="Internet-Draft" value="draft-ietf-dprive-dnsoquic-03
incoming TLS/TCP connections and then apply a transport-specific response policy "/>
on a per <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
query basis.</t> dprive-dnsoquic-03.txt"/>
<t>As an aside, whilst <xref target="RFC7766"></xref> makes a general purpose di <refcontent>Work in Progress</refcontent>
stinction in the advice to clients </reference>
about their usage of connections (between regular queries and zone transfers) th <reference anchor="NIST-GUIDE" target="https://nvlpubs.nist.gov/nistpubs
is is /SpecialPublications/NIST.SP.800-81-2.pdf" quoteTitle="true" derivedAnchor="NIST
not strict and nothing in the DNS protocol prevents using the same connection -GUIDE">
for both types of traffic. Hence a server cannot know the intention of any <front>
client that connects to it, it can only inspect the messages it receives on <title>Secure Domain Name System (DNS) Deployment Guide</title>
such a connection and make per-query decisions about whether or not to answer <author fullname="Ramaswamy Chandramouli" initials="R." surname="Cha
those queries.</t> ndramouli">
<t>Example policies a XoT server might implement are:</t> <organization showOnFrontPage="true">NIST</organization>
</author>
<author fullname="Scott Rose" initials="S." surname="Rose">
<organization showOnFrontPage="true">NIST</organization>
</author>
<date month="September" year="2013"/>
</front>
</reference>
<reference anchor="NSD" target="https://www.nlnetlabs.nl/projects/nsd/ab
out/" quoteTitle="true" derivedAnchor="NSD">
<front>
<title>NSD 4.3.6</title>
<author>
<organization showOnFrontPage="true">NLnet Labs</organization>
</author>
</front>
</reference>
<reference anchor="NSEC3-attacks" target="https://www.cs.bu.edu/~goldbe/
papers/nsec3attacks.pdf" quoteTitle="true" derivedAnchor="NSEC3-attacks">
<front>
<title>Stretching NSEC3 to the Limit: Efficient Zone Enumeration Att
acks on NSEC3 Variants</title>
<author fullname="Sharon Goldberg" initials="S." surname="Goldberg">
<organization showOnFrontPage="true">Boston University, Department
of Computer Science</organization>
</author>
<author fullname="Moni Naor" initials="N." surname="Naor">
<organization showOnFrontPage="true">Weizmann Institute of Science
, Department of Computer Science and Applied Mathematics</organization>
</author>
<author fullname="Dimitrios Papadopoulos" initials="D." surname="Pap
adopoulos">
<organization showOnFrontPage="true">Boston University, Department
of Computer Science</organization>
</author>
<author fullname="Leonid Reyzin" initials="L." surname="Reyzin">
<organization showOnFrontPage="true">Boston University, Department
of Computer Science</organization>
</author>
<author fullname="Sachin Vasant" initials="S." surname="Vasant">
<organization showOnFrontPage="true">Boston University, Department
of Computer Science</organization>
</author>
<author fullname="Asaf Ziv" initials="A." surname="Ziv">
<organization showOnFrontPage="true">Weizmann Institute of Science
, Department of Computer Science and Applied Mathematics</organization>
</author>
<date month="February" year="2015"/>
</front>
</reference>
<reference anchor="I-D.vcelak-nsec5" quoteTitle="true" target="https://d
atatracker.ietf.org/doc/html/draft-vcelak-nsec5-08" derivedAnchor="NSEC5">
<front>
<title>NSEC5, DNSSEC Authenticated Denial of Existence</title>
<author initials="J." surname="Vcelak" fullname="Jan Vcelak">
<organization showOnFrontPage="true">CZ.NIC</organization>
</author>
<author initials="S." surname="Goldberg" fullname="Sharon Goldberg">
<organization showOnFrontPage="true">Boston University</organizati
on>
</author>
<author initials="D." surname="Papadopoulos" fullname="Dimitrios Pap
adopoulos">
<organization showOnFrontPage="true">HKUST</organization>
</author>
<author initials="S." surname="Huque" fullname="Shumon Huque">
<organization showOnFrontPage="true">Salesforce</organization>
</author>
<author initials="D." surname="Lawrence" fullname="David C Lawrence"
>
<organization showOnFrontPage="true">Dyn</organization>
</author>
<date month="December" day="29" year="2018"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-vcelak-nsec5-08"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="RFC1982" target="https://www.rfc-editor.org/info/rfc1
982" quoteTitle="true" derivedAnchor="RFC1982">
<front>
<title>Serial Number Arithmetic</title>
<author initials="R." surname="Elz" fullname="R. Elz">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Bush" fullname="R. Bush">
<organization showOnFrontPage="true"/>
</author>
<date year="1996" month="August"/>
<abstract>
<t indent="0">The DNS has long relied upon serial number arithmeti
c, a concept which has never really been defined, certainly not in an IETF docum
ent, though which has been widely understood. This memo supplies the missing de
finition. It is intended to update RFC1034 and RFC1035. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1982"/>
<seriesInfo name="DOI" value="10.17487/RFC1982"/>
</reference>
<reference anchor="RFC5155" target="https://www.rfc-editor.org/info/rfc5
155" quoteTitle="true" derivedAnchor="RFC5155">
<front>
<title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existenc
e</title>
<author initials="B." surname="Laurie" fullname="B. Laurie">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Sisson" fullname="G. Sisson">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Arends" fullname="R. Arends">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Blacka" fullname="D. Blacka">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="March"/>
<abstract>
<t indent="0">The Domain Name System Security (DNSSEC) Extensions
introduced the NSEC resource record (RR) for authenticated denial of existence.
This document introduces an alternative resource record, NSEC3, which similarly
provides authenticated denial of existence. However, it also provides measures
against zone enumeration and permits gradual expansion of delegation-centric zon
es. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5155"/>
<seriesInfo name="DOI" value="10.17487/RFC5155"/>
</reference>
<reference anchor="RFC6891" target="https://www.rfc-editor.org/info/rfc6
891" quoteTitle="true" derivedAnchor="RFC6891">
<front>
<title>Extension Mechanisms for DNS (EDNS(0))</title>
<author initials="J." surname="Damas" fullname="J. Damas">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Graff" fullname="M. Graff">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Vixie" fullname="P. Vixie">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="April"/>
<abstract>
<t indent="0">The Domain Name System's wire protocol includes a nu
mber of fixed fields whose range has been or soon will be exhausted and does not
allow requestors to advertise their capabilities to responders. This document
describes backward-compatible mechanisms for allowing the protocol to grow.</t>
<t indent="0">This document updates the Extension Mechanisms for D
NS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deplo
yment experience in several implementations. It also obsoletes RFC 2673 ("Binar
y Labels in the Domain Name System") and adds considerations on the use of exten
ded labels in the DNS.</t>
</abstract>
</front>
<seriesInfo name="STD" value="75"/>
<seriesInfo name="RFC" value="6891"/>
<seriesInfo name="DOI" value="10.17487/RFC6891"/>
</reference>
<reference anchor="RFC8484" target="https://www.rfc-editor.org/info/rfc8
484" quoteTitle="true" derivedAnchor="RFC8484">
<front>
<title>DNS Queries over HTTPS (DoH)</title>
<author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="McManus" fullname="P. McManus">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="October"/>
<abstract>
<t indent="0">This document defines a protocol for sending DNS que
ries and getting DNS responses over HTTPS. Each DNS query-response pair is mapp
ed into an HTTP exchange.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8484"/>
<seriesInfo name="DOI" value="10.17487/RFC8484"/>
</reference>
<reference anchor="RFC8976" target="https://www.rfc-editor.org/info/rfc8
976" quoteTitle="true" derivedAnchor="RFC8976">
<front>
<title>Message Digest for DNS Zones</title>
<author initials="D." surname="Wessels" fullname="D. Wessels">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Barber" fullname="P. Barber">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Weinberg" fullname="M. Weinberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="W." surname="Kumari" fullname="W. Kumari">
<organization showOnFrontPage="true"/>
</author>
<author initials="W." surname="Hardaker" fullname="W. Hardaker">
<organization showOnFrontPage="true"/>
</author>
<date year="2021" month="February"/>
<abstract>
<t indent="0">This document describes a protocol and new DNS Resou
rce Record that provides a cryptographic message digest over DNS zone data at re
st. The ZONEMD Resource Record conveys the digest data in the zone itself. When
used in combination with DNSSEC, ZONEMD allows recipients to verify the zone con
tents for data integrity and origin authenticity. This provides assurance that r
eceived zone data matches published data, regardless of how the zone data has be
en transmitted and received. When used without DNSSEC, ZONEMD functions as a ch
ecksum, guarding only against unintentional changes. </t>
<t indent="0">ZONEMD does not replace DNSSEC: DNSSEC protects indi
vidual RRsets (DNS data with fine granularity), whereas ZONEMD protects a zone's
data as a whole, whether consumed by authoritative name servers, recursive name
servers, or any other applications. </t>
<t indent="0">As specified herein, ZONEMD is impractical for large
, dynamic zones due to the time and resources required for digest calculation. H
owever, the ZONEMD record is extensible so that new digest schemes may be added
in the future to support large, dynamic zones.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8976"/>
<seriesInfo name="DOI" value="10.17487/RFC8976"/>
</reference>
<reference anchor="RFC9076" target="https://www.rfc-editor.org/info/rfc9
076" quoteTitle="true" derivedAnchor="RFC9076">
<front>
<title>DNS Privacy Considerations</title>
<author initials="T." surname="Wicinski" fullname="T. Wicinski" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2021" month="July"/>
<abstract>
<t indent="0">This document describes the privacy issues associate
d with the use of the DNS by Internet users. It provides general observations ab
out typical current privacy practices. It is intended to be an analysis of the p
resent situation and does not prescribe solutions. This document obsoletes RFC 7
626.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9076"/>
<seriesInfo name="DOI" value="10.17487/RFC9076"/>
</reference>
<reference anchor="I-D.ietf-tls-esni" quoteTitle="true" target="https://
datatracker.ietf.org/doc/html/draft-ietf-tls-esni-13" derivedAnchor="TLS-ESNI">
<front>
<title>TLS Encrypted Client Hello</title>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization showOnFrontPage="true">RTFM, Inc.</organization>
</author>
<author initials="K." surname="Oku" fullname="Kazuho Oku">
<organization showOnFrontPage="true">Fastly</organization>
</author>
<author initials="N." surname="Sullivan" fullname="Nick Sullivan">
<organization showOnFrontPage="true">Cloudflare</organization>
</author>
<author initials="C. A." surname="Wood" fullname="Christopher A. Woo
d">
<organization showOnFrontPage="true">Cloudflare</organization>
</author>
<date month="August" day="12" year="2021"/>
<abstract>
<t indent="0"> This document describes a mechanism in Transport
Layer Security (TLS)
for encrypting a ClientHello message under a server public key.
<ul> Discussion Venues
<li>strict: REFUSE all queries on TLS connections except SOA and authorized XFR
requests</li>
<li>moderate: REFUSE all queries on TLS connections until one is received that i
s
signed by a recognized TSIG/SIG(0) key, then answer all queries on the
connection after that</li>
<li>complex: apply a heuristic to determine which queries on a TLS connections t
o REFUSE</li>
<li>relaxed: answer all non-XoT queries on all TLS connections with the same pol
icy applied to TCP queries</li>
</ul>
<t>Pros: Allows for flexible behavior by the server that could be changed over t
ime.</t>
<t>Cons: The server must handle the burden of accepting all TLS connections just
to perform XFRs with a small number of secondaries. Client behavior to REFUSED
response is not clearly defined (see <xref target="response-rcodes"></xref>). Cu
rrently, none of the major open
source DNS authoritative implementations offer an option for different response
policies in different transports (but such functionality could potentially be im
plemented using a proxy).</t>
<section anchor="sni-based-response-policies"><name>SNI based response policies< This note is to be removed before publishing as an RFC.
/name>
<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
connections.</t>
<t>Pros: This has to potential to allow a clean distinction between a XoT servic
e
and any future DoT based service for answering recursive queries.</t>
<t>Cons: As above.</t>
</section>
</section>
</section>
</back> Source for this draft and an issue tracker can be found at
https://github.com/tlswg/draft-ietf-tls-esni
(https://github.com/tlswg/draft-ietf-tls-esni).
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-13"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
tls-esni-13.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
</references>
</references>
<section anchor="xot-server-connection-handling" numbered="true" removeInRFC
="false" toc="include" pn="section-appendix.a">
<name slugifiedName="name-xot-server-connection-handl">XoT Server Connecti
on Handling</name>
<t indent="0" pn="section-appendix.a-1">This appendix provides a non-norma
tive outline of the pros and cons of XoT server
connection-handling options.</t>
<t indent="0" pn="section-appendix.a-2">For completeness, it is noted that
an earlier draft version of this document
suggested using a XoT-specific ALPN to negotiate TLS connections that supporte
d
only a limited set of queries (SOA, XFRs); however, this did not gain support.
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" numbered="tr
ue" removeInRFC="false" toc="include" pn="section-appendix.a.1">
<name slugifiedName="name-listening-only-on-a-specifi">Listening Only on
a Specific IP Address for TLS</name>
<t indent="0" pn="section-appendix.a.1-1">Obviously, a name server that
hosts a zone and services queries for the zone on
an IP address published in an NS record may wish to use a separate IP address
for XoT to listen for TLS, only publishing that address to its secondaries.</t
>
<dl newline="false" spacing="normal" indent="3" pn="section-appendix.a.1
-2">
<dt pn="section-appendix.a.1-2.1">Pros:</dt>
<dd pn="section-appendix.a.1-2.2">Probing of the public IP address wil
l show no support for TLS. ACLs will
prevent zone transfer on all transports on a per-query basis.</dd>
<dt pn="section-appendix.a.1-2.3">Cons:</dt>
<dd pn="section-appendix.a.1-2.4">Attackers passively observing traffi
c will still be able to observe TLS
connections to the separate address.</dd>
</dl>
</section>
<section anchor="client-specific-tls-acceptance" numbered="true" removeInR
FC="false" toc="include" pn="section-appendix.a.2">
<name slugifiedName="name-client-specific-tls-accepta">Client-Specific T
LS Acceptance</name>
<t indent="0" pn="section-appendix.a.2-1">Primaries that include IP-base
d ACLs and/or mutual TLS in their authentication models
have the option of only accepting TLS connections from authorized clients. Thi
s
could be implemented either using a proxy or directly in the DNS implementatio
n.</t>
<dl newline="false" spacing="normal" indent="3" pn="section-appendix.a.2
-2">
<dt pn="section-appendix.a.2-2.1">Pros:</dt>
<dd pn="section-appendix.a.2-2.2">Connection management happens at set
up time. The maximum number of TLS
connections a server will have to support can be easily assessed. Once the
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 pn="section-appendix.a.2-2.3">Cons:</dt>
<dd pn="section-appendix.a.2-2.4">Currently, none of the major open-so
urce
implementations of a DNS authoritative server support such an option.</dd>
</dl>
</section>
<section anchor="sni-based-tls-acceptance" numbered="true" removeInRFC="fa
lse" toc="include" pn="section-appendix.a.3">
<name slugifiedName="name-sni-based-tls-acceptance">SNI-Based TLS Accept
ance</name>
<t indent="0" pn="section-appendix.a.3-1">Primaries could also choose to
only accept TLS connections based on a Server Name
Indication (SNI) that was published only to their secondaries.</t>
<dl newline="false" spacing="normal" indent="3" pn="section-appendix.a.3
-2">
<dt pn="section-appendix.a.3-2.1">Pros:</dt>
<dd pn="section-appendix.a.3-2.2">Reduces the number of accepted conne
ctions.</dd>
<dt pn="section-appendix.a.3-2.3">Cons:</dt>
<dd pn="section-appendix.a.3-2.4">As above. Also, this is not a recomm
ended use of SNI. For SNIs sent in the
clear, this would still allow attackers passively observing traffic to
potentially abuse this mechanism. The use of Encrypted Client Hello
<xref target="I-D.ietf-tls-esni" format="default" sectionFormat="of" derived
Content="TLS-ESNI"/> may be of use here.</dd>
</dl>
</section>
<section anchor="transport-specific-response-policies" numbered="true" rem
oveInRFC="false" toc="include" pn="section-appendix.a.4">
<name slugifiedName="name-transport-specific-response">Transport-Specifi
c Response Policies</name>
<t indent="0" pn="section-appendix.a.4-1">Some primaries might rely on T
SIG/SIG(0) combined with per-query, IP-based
ACLs to authenticate secondaries. In this case, the primary must accept all
incoming TLS/TCP connections and then apply a transport-specific response poli
cy on a
per-query basis.</t>
<t indent="0" pn="section-appendix.a.4-2">As an aside, whilst <xref targ
et="RFC7766" format="default" sectionFormat="of" derivedContent="RFC7766"/> make
s a general purpose distinction in
the advice to clients
about their usage of connections (between regular queries and zone transfers),
this is
not strict, and nothing in the DNS protocol prevents using the same connection
for both types of traffic. Hence, a server cannot know the intention of any
client that connects to it; it can only inspect the messages it receives on
such a connection and make per-query decisions about whether or not to answer
those queries.</t>
<t indent="0" pn="section-appendix.a.4-3">Example policies a XoT server
might implement are:</t>
<dl newline="false" spacing="normal" indent="12" pn="section-appendix.a.
4-4">
<dt pn="section-appendix.a.4-4.1">strict:</dt>
<dd pn="section-appendix.a.4-4.2">REFUSE all queries on TLS connection
s, except SOA and authorized XFR requests</dd>
<dt pn="section-appendix.a.4-4.3">moderate:</dt>
<dd pn="section-appendix.a.4-4.4">REFUSE all queries on TLS connection
s until one is received that is
signed by a recognized TSIG/SIG(0) key, then answer all queries on the
connection after that</dd>
<dt pn="section-appendix.a.4-4.5">complex:</dt>
<dd pn="section-appendix.a.4-4.6">apply a heuristic to determine which
queries on a TLS connections to REFUSE</dd>
<dt pn="section-appendix.a.4-4.7">relaxed:</dt>
<dd pn="section-appendix.a.4-4.8">answer all non-XoT queries on all TL
S connections with the same policy applied to TCP
queries</dd>
</dl>
<dl newline="false" spacing="normal" indent="3" pn="section-appendix.a.4
-5">
<dt pn="section-appendix.a.4-5.1">Pros:</dt>
<dd pn="section-appendix.a.4-5.2">Allows for flexible behavior by the
server that could be changed over time.</dd>
<dt pn="section-appendix.a.4-5.3">Cons:</dt>
<dd pn="section-appendix.a.4-5.4">The server must handle the burden of
accepting all TLS connections just
to perform XFRs with a small number of secondaries. Client behavior to a REF
USED
response is not clearly defined (see <xref target="response-rcodes" format="
default" sectionFormat="of" derivedContent="Section 7.8"/>). 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" numbered="true" removeInRF
C="false" toc="include" pn="section-appendix.a.4.1">
<name slugifiedName="name-sni-based-response-policies">SNI-Based Respo
nse Policies</name>
<t indent="0" pn="section-appendix.a.4.1-1">In a similar fashion, XoT
servers might use the presence of an SNI in the
Client Hello to determine which response policy to initially apply to the TLS
connections.</t>
<dl newline="false" spacing="normal" indent="3" pn="section-appendix.a
.4.1-2">
<dt pn="section-appendix.a.4.1-2.1">Pros:</dt>
<dd pn="section-appendix.a.4.1-2.2">This has the potential to allow
a clean distinction between a XoT service
and any future DoT-based service for answering recursive queries.</dd>
<dt pn="section-appendix.a.4.1-2.3">Cons:</dt>
<dd pn="section-appendix.a.4.1-2.4">As above.</dd>
</dl>
</section>
</section>
</section>
<section anchor="acknowledgements" numbered="false" removeInRFC="false" toc=
"include" pn="section-appendix.b">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t indent="0" pn="section-appendix.b-1">The authors thank <contact fullnam
e="Tony Finch"/>, <contact fullname="Benno Overeinder"/>, <contact fullname="S
humon Huque"/>,
<contact fullname="Tim Wicinski"/>, and many other members of DPRIVE for revie
w and
discussions.</t>
<t indent="0" pn="section-appendix.b-2">The authors particularly thank <co
ntact fullname="Peter van Dijk"/>,
<contact fullname="Ondrej Sury"/>, <contact fullname="Brian Dickson"/>, and
several other open-source DNS implementers for valuable discussion and
clarification on the issue associated with pipelining XFR queries and handling
out-of-order/intermingled responses.</t>
</section>
<section anchor="contributors" numbered="false" removeInRFC="false" toc="inc
lude" pn="section-appendix.c">
<name slugifiedName="name-contributors">Contributors</name>
<t indent="0" pn="section-appendix.c-1">Significant contributions to the d
ocument were made by:</t>
<contact fullname="Han Zhang">
<organization showOnFrontPage="true">Salesforce</organization>
<address>
<postal>
<street/>
<city>San Francisco</city>
<region>CA</region>
<country>United States of America</country>
</postal>
<email>hzhang@salesforce.com</email>
</address>
</contact>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.d">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author initials="W." surname="Toorop" fullname="Willem Toorop">
<organization showOnFrontPage="true">NLnet Labs</organization>
<address>
<postal>
<street>Science Park 400</street>
<city>Amsterdam</city>
<code>1098 XH</code>
<country>Netherlands</country>
</postal>
<email>willem@nlnetlabs.nl</email>
</address>
</author>
<author initials="S." surname="Dickinson" fullname="Sara Dickinson">
<organization showOnFrontPage="true">Sinodun IT</organization>
<address>
<postal>
<extaddr>Magdalen Centre</extaddr>
<street>Oxford Science Park</street>
<city>Oxford</city>
<code>OX4 4GA</code>
<country>United Kingdom</country>
</postal>
<email>sara@sinodun.com</email>
</address>
</author>
<author initials="S." surname="Sahib" fullname="Shivan Sahib">
<organization showOnFrontPage="true">Brave Software</organization>
<address>
<postal>
<city>Vancouver</city>
<region>BC</region>
<country>Canada</country>
</postal>
<email>shivankaulsahib@gmail.com</email>
</address>
</author>
<author initials="P." surname="Aras" fullname="Pallavi Aras">
<organization showOnFrontPage="true">Salesforce</organization>
<address>
<postal>
<city>Herndon</city>
<region>VA</region>
<country>United States of America</country>
</postal>
<email>paras@salesforce.com</email>
</address>
</author>
<author initials="A." surname="Mankin" fullname="Allison Mankin">
<organization showOnFrontPage="true">Salesforce</organization>
<address>
<postal>
<city>Herndon</city>
<region>VA</region>
<country>United States of America</country>
</postal>
<email>allison.mankin@gmail.com</email>
</address>
</author>
</section>
</back>
</rfc> </rfc>
 End of changes. 23 change blocks. 
1671 lines changed or deleted 3152 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/