draft-ietf-dprive-xfr-over-tls-11.txt   draft-ietf-dprive-xfr-over-tls-12.txt 
dprive W. Toorop dprive W. Toorop
Internet-Draft NLnet Labs Internet-Draft NLnet Labs
Updates: 1995, 5936, 7766 (if approved) S. Dickinson Updates: 1995, 5936, 7766 (if approved) S. Dickinson
Intended status: Standards Track Sinodun IT Intended status: Standards Track Sinodun IT
Expires: October 22, 2021 S. Sahib Expires: 27 November 2021 S. Sahib
Brave Software
P. Aras P. Aras
A. Mankin A. Mankin
Salesforce Salesforce
April 20, 2021 26 May 2021
DNS Zone Transfer-over-TLS DNS Zone Transfer-over-TLS
draft-ietf-dprive-xfr-over-tls-11 draft-ietf-dprive-xfr-over-tls-12
Abstract Abstract
DNS zone transfers are transmitted in clear text, which gives DNS zone transfers are transmitted in clear text, which gives
attackers the opportunity to collect the content of a zone by attackers the opportunity to collect the content of a zone by
eavesdropping on network connections. The DNS Transaction Signature eavesdropping on network connections. The DNS Transaction Signature
(TSIG) mechanism is specified to restrict direct zone transfer to (TSIG) mechanism is specified to restrict direct zone transfer to
authorized clients only, but it does not add confidentiality. This authorized clients only, but it does not add confidentiality. This
document specifies the use of TLS, rather than clear text, to prevent document specifies the use of TLS, rather than clear text, to prevent
zone content collection via passive monitoring of zone transfers: zone content collection via passive monitoring of zone transfers:
XFR-over-TLS (XoT). Additionally, this specification updates XFR-over-TLS (XoT). Additionally, this specification updates RFC1995
RFC1995, RFC5936 and RFC7766. and RFC5936 with respect to efficient use of TCP connections, and
RFC7766 with respect to the recommended number of connections between
a client and server for each transport.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 22, 2021. This Internet-Draft will expire on 27 November 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document work via GitHub . . . . . . . . . . . . . . . . . . 5 2. Document work via GitHub . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Design Considerations for XoT . . . . . . . . . . . . . . . . 6 5. Design Considerations for XoT . . . . . . . . . . . . . . . . 7
6. Connection and Data Flows in Existing XFR Mechanisms . . . . 7 6. Connection and Data Flows in Existing XFR Mechanisms . . . . 8
6.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 8 6.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 8
6.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 9 6.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 10
6.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 11 6.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 11
6.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 11 6.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 11
6.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Updates to existing specifications . . . . . . . . . . . . . 11 7. Updates to existing specifications . . . . . . . . . . . . . 12
7.1. Update to RFC1995 for IXFR-over-TCP . . . . . . . . . . . 13 7.1. Update to RFC1995 for IXFR-over-TCP . . . . . . . . . . . 13
7.2. Update to RFC5936 for AXFR-over-TCP . . . . . . . . . . . 13 7.2. Update to RFC5936 for AXFR-over-TCP . . . . . . . . . . . 14
7.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP . . . . . 13 7.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP . . . . . 14
7.3.1. Connection reuse . . . . . . . . . . . . . . . . . . 13 7.3.1. Connection reuse . . . . . . . . . . . . . . . . . . 14
7.3.2. AXFRs and IXFRs on the same connection . . . . . . . 14 7.3.2. AXFRs and IXFRs on the same connection . . . . . . . 15
7.3.3. XFR limits . . . . . . . . . . . . . . . . . . . . . 14 7.3.3. XFR limits . . . . . . . . . . . . . . . . . . . . . 15
7.3.4. The edns-tcp-keepalive EDNS0 Option . . . . . . . . . 15 7.3.4. The edns-tcp-keepalive EDNS0 Option . . . . . . . . . 15
7.3.5. Backwards compatibility . . . . . . . . . . . . . . . 15 7.3.5. Backwards compatibility . . . . . . . . . . . . . . . 16
7.4. Update to RFC7766 . . . . . . . . . . . . . . . . . . . . 15 7.4. Update to RFC7766 . . . . . . . . . . . . . . . . . . . . 16
8. XoT specification . . . . . . . . . . . . . . . . . . . . . . 17 8. XoT specification . . . . . . . . . . . . . . . . . . . . . . 17
8.1. TLS versions . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Connection establishment . . . . . . . . . . . . . . . . 17
8.2. Port selection . . . . . . . . . . . . . . . . . . . . . 17 8.2. TLS versions . . . . . . . . . . . . . . . . . . . . . . 17
8.3. High level XoT descriptions . . . . . . . . . . . . . . . 17 8.3. Port selection . . . . . . . . . . . . . . . . . . . . . 18
8.4. XoT transfers . . . . . . . . . . . . . . . . . . . . . . 19 8.4. High level XoT descriptions . . . . . . . . . . . . . . . 18
8.5. XoT connections . . . . . . . . . . . . . . . . . . . . . 20 8.5. XoT transfers . . . . . . . . . . . . . . . . . . . . . . 20
8.6. XoT vs ADoT . . . . . . . . . . . . . . . . . . . . . . . 20 8.6. XoT connections . . . . . . . . . . . . . . . . . . . . . 21
8.7. Response RCODES . . . . . . . . . . . . . . . . . . . . . 21 8.7. XoT vs ADoT . . . . . . . . . . . . . . . . . . . . . . . 21
8.8. AXoT specifics . . . . . . . . . . . . . . . . . . . . . 21 8.8. Response RCODES . . . . . . . . . . . . . . . . . . . . . 22
8.8.1. Padding AXoT responses . . . . . . . . . . . . . . . 21 8.9. AXoT specifics . . . . . . . . . . . . . . . . . . . . . 22
8.9. IXoT specifics . . . . . . . . . . . . . . . . . . . . . 22 8.9.1. Padding AXoT responses . . . . . . . . . . . . . . . 22
8.9.1. Condensation of responses . . . . . . . . . . . . . . 22
8.9.2. Fallback to AXFR . . . . . . . . . . . . . . . . . . 22
8.9.3. Padding of IXoT responses . . . . . . . . . . . . . . 23
8.10. Name compression and maximum payload sizes . . . . . . . 23
9. Multi-primary Configurations . . . . . . . . . . . . . . . . 23 8.10. IXoT specifics . . . . . . . . . . . . . . . . . . . . . 23
10. Authentication mechanisms . . . . . . . . . . . . . . . . . . 24 8.10.1. Condensation of responses . . . . . . . . . . . . . 23
10.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.10.2. Fallback to AXFR . . . . . . . . . . . . . . . . . . 24
10.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.10.3. Padding of IXoT responses . . . . . . . . . . . . . 24
10.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.11. Name compression and maximum payload sizes . . . . . . . 24
10.3.1. Opportunistic TLS . . . . . . . . . . . . . . . . . 25 9. Multi-primary Configurations . . . . . . . . . . . . . . . . 25
10.3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . 26 10. Authentication mechanisms . . . . . . . . . . . . . . . . . . 26
10.3.3. Mutual TLS . . . . . . . . . . . . . . . . . . . . . 26 10.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.4. IP Based ACL on the Primary . . . . . . . . . . . . . . 26 10.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. XoT authentication . . . . . . . . . . . . . . . . . . . . . 27 10.3.1. Opportunistic TLS . . . . . . . . . . . . . . . . . 27
12. Policies for Both AXoT and IXoT . . . . . . . . . . . . . . . 28 10.3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . 27
13. Implementation Considerations . . . . . . . . . . . . . . . . 29 10.3.3. Mutual TLS . . . . . . . . . . . . . . . . . . . . . 27
14. Operational Considerations . . . . . . . . . . . . . . . . . 29 10.4. IP Based ACL on the Primary . . . . . . . . . . . . . . 28
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 28
16. Implementation Status . . . . . . . . . . . . . . . . . . . . 29 11. XoT authentication . . . . . . . . . . . . . . . . . . . . . 28
17. Security Considerations . . . . . . . . . . . . . . . . . . . 30 12. Policies for Both AXoT and IXoT . . . . . . . . . . . . . . . 29
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 13. Implementation Considerations . . . . . . . . . . . . . . . . 30
19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 14. Operational Considerations . . . . . . . . . . . . . . . . . 30
20. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 31 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 16. Implementation Status . . . . . . . . . . . . . . . . . . . . 31
21.1. Normative References . . . . . . . . . . . . . . . . . . 33 17. Security Considerations . . . . . . . . . . . . . . . . . . . 31
21.2. Informative References . . . . . . . . . . . . . . . . . 35 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
21.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix A. XoT server connection handling . . . . . . . . . . . 37 20. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.1. Only listen on TLS on a specific IP address . . . . . . . 37 21. Normative References . . . . . . . . . . . . . . . . . . . . 35
A.2. Client specific TLS acceptance . . . . . . . . . . . . . 37 22. Informative References . . . . . . . . . . . . . . . . . . . 37
A.3. SNI based TLS acceptance . . . . . . . . . . . . . . . . 37 Appendix A. XoT server connection handling . . . . . . . . . . . 39
A.4. TLS specific response policies . . . . . . . . . . . . . 38 A.1. Only listen on TLS on a specific IP address . . . . . . . 39
A.4.1. SNI based response policies . . . . . . . . . . . . . 39 A.2. Client specific TLS acceptance . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 A.3. SNI based TLS acceptance . . . . . . . . . . . . . . . . 40
A.4. Transport specific response policies . . . . . . . . . . 40
A.4.1. SNI based response policies . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
DNS has a number of privacy vulnerabilities, as discussed in detail DNS has a number of privacy vulnerabilities, as discussed in detail
in [I-D.ietf-dprive-rfc7626-bis]. Stub client to recursive resolver in [I-D.ietf-dprive-rfc7626-bis]. Stub client to recursive resolver
query privacy has received the most attention to date, with standards query privacy has received the most attention to date, with standards
track documents for both DNS-over-TLS (DoT) [RFC7858] and DNS-over- track documents for both DNS-over-TLS (DoT) [RFC7858] and DNS-over-
HTTPS (DoH) [RFC8484], and a proposal for DNS-over-QUIC HTTPS (DoH) [RFC8484], and a proposal for DNS-over-QUIC
[I-D.ietf-dprive-dnsoquic]. There is ongoing work on DNS privacy [I-D.ietf-dprive-dnsoquic]. There is ongoing work on DNS privacy
requirements for exchanges between recursive resolvers and requirements for exchanges between recursive resolvers and
authoritative servers [I-D.ietf-dprive-phase2-requirements] and some authoritative servers [I-D.ietf-dprive-phase2-requirements] and some
suggestions for how signaling of DoT support by authoritatives might suggestions for how signaling of DoT support by authoritative
work. However there is currently no RFC that specifically defines nameservers might work. However, there is currently no RFC that
recursive to authoritative DNS-over-TLS (ADoT). specifically defines recursive to authoritative DNS-over-TLS (ADoT).
[I-D.ietf-dprive-rfc7626-bis] established that stub client DNS query [I-D.ietf-dprive-rfc7626-bis] established that stub client DNS query
transactions are not public and needed protection, but on zone transactions are not public and needed protection, but on zone
transfer [RFC1995] [RFC5936] it says only: transfer [RFC1995] [RFC5936] it says only:
"Privacy risks for the holder of a zone (the risk that someone "Privacy risks for the holder of a zone (the risk that someone
gets the data) are discussed in [RFC5936] and [RFC5155]." gets the data) are discussed in [RFC5936] and [RFC5155]."
In what way is exposing the full contents of a zone a privacy risk? In what way is exposing the full contents of a zone a privacy risk?
The contents of the zone could include information such as names of The contents of the zone could include information such as names of
persons used in names of hosts. Best practice is not to use personal persons used in names of hosts. Best practice is not to use personal
information for domain names, but many such domain names exist. The information for domain names, but many such domain names exist. The
contents of the zone could also include references to locations that contents of the zone could also include references to locations that
allow inference about location information of the individuals allow inference about location information of the individuals
associated with the zone's organization. It could also include associated with the zone's organization. It could also include
references to other organizations. Examples of this could be: references to other organizations. Examples of this could be:
o Person-laptop.example.org * Person-laptop.example.org
o MX-for-Location.example.org * MX-for-Location.example.org
o Service-tenant-from-another-org.example.org * Service-tenant-from-another-org.example.org
Additionally, the full zone contents expose all the IP addresses of Additionally, the full zone contents expose all the IP addresses of
endpoints held in the DNS records which can make reconnaissance endpoints held in the DNS records which can make reconnaissance and
trivial, particularly for IPv6 addresses. There may also be attack targeting easier, particularly for IPv6 addresses or private
regulatory, policy or other reasons why the zone contents in full networks. There may also be regulatory, policy or other reasons why
must be treated as private. the zone contents in full must be treated as private.
Neither of the RFCs mentioned in [I-D.ietf-dprive-rfc7626-bis] Neither of the RFCs mentioned in [I-D.ietf-dprive-rfc7626-bis]
contemplates the risk that someone gets the data through contemplates the risk that someone gets the data through
eavesdropping on network connections, only via enumeration or eavesdropping on network connections, only via enumeration or
unauthorized transfer as described in the following paragraphs. unauthorized transfer as described in the following paragraphs.
Zone enumeration is trivially possible for DNSSEC zones which use Zone enumeration is trivially possible for DNSSEC zones which use
NSEC; i.e. queries for the authenticated denial of existences NSEC; i.e. queries for the authenticated denial of existence records
records allow a client to walk through the entire zone contents. allow a client to walk through the entire zone contents. [RFC5155]
[RFC5155] specifies NSEC3, a mechanism to provide measures against specifies NSEC3, a mechanism to provide measures against zone
zone enumeration for DNSSEC signed zones (a goal was to make it as enumeration for DNSSEC signed zones (a goal was to make it as hard to
hard to enumerate an DNSSEC signed zone as an unsigned zone). Whilst enumerate a DNSSEC signed zone as an unsigned zone). Whilst this is
this is widely used, zone walking is now possible with NSEC3 due to widely used, it has been demonstrated that zone walking is possible
crypto-breaking advances. This has prompted further work on an for precomputed NSEC3 using attacks such as those described in
alternative mechanism for DNSSEC authenticated denial of existence - [NSEC3-attacks]. This prompted further work on an alternative
NSEC5 [I-D.vcelak-nsec5] - however questions remain over the mechanism for DNSSEC authenticated denial of existence - NSEC5
practicality of this mechanism. [I-D.vcelak-nsec5] - however questions remain over the practicality
of this mechanism.
[RFC5155] does not address data obtained outside zone enumeration [RFC5155] does not address data obtained outside zone enumeration
(nor does [I-D.vcelak-nsec5]). Preventing eavesdropping of zone (nor does [I-D.vcelak-nsec5]). Preventing eavesdropping of zone
transfers (this draft) is orthogonal to preventing zone enumeration, transfers (this document) is orthogonal to preventing zone
though they aim to protect the same information. enumeration, though they aim to protect the same information.
[RFC5936] specifies using TSIG [RFC8945] for authorization of the [RFC5936] specifies using TSIG [RFC8945] for authorization of the
clients of a zone transfer and for data integrity, but does not clients of a zone transfer and for data integrity, but does not
express any need for confidentiality, and TSIG does not offer express any need for confidentiality, and TSIG does not offer
encryption. encryption.
Section 8 of the NIST guide on 'Secure Domain Name System (DNS) Section 8 of the NIST guide on 'Secure Domain Name System (DNS)
Deployment' [nist-guide] discusses restricting access for zone Deployment' [nist-guide] discusses restricting access for zone
transfers using ACLs and TSIG in more detail. It also discusses the transfers using ACLs and TSIG in more detail. It also discusses the
possibility that specific deployments might choose to use a lower possibility that specific deployments might choose to use a lower
level network layer to protect zone transfers, e.g., IPSec. level network layer to protect zone transfers, e.g., IPSec.
It is noted that in all the common open source implementations such It is noted that in all the common open source implementations such
ACLs are applied on a per query basis. Since requests typically ACLs are applied on a per query basis (at the time of writing).
occur on TCP connections authoritatives must cater for accepting any Since requests typically occur on TCP connections authoritatives must
TCP connection and then handling the authentication of each XFR therefore accept any TCP connection and then handling the
request individually. authentication of each zone transfer (XFR) request individually.
Because both AXFR and IXFR zone transfers are typically carried out Because both AXFR (authoritative transfer) and IXFR (incremental
over TCP from authoritative DNS protocol implementations, encrypting transfer) are typically carried out over TCP from authoritative DNS
zone transfers using TLS, based closely on DoT [RFC7858], seems like protocol implementations, encrypting zone transfers using TLS
a simple step forward. This document specifies how to use TLS (1.3 [RFC8499], based closely on DoT [RFC7858], seems like a simple step
or later) as a transport to prevent zone collection from zone forward. This document specifies how to use TLS (1.3 or later) as a
transfers. transport to prevent zone collection from zone transfers.
This document also updates the previous specifications for zone
transfers to clarify and extend them, mainly with respect to TCP
usage:
* RFC1995 (IXFR) and RFC5936 (AXFR) are both updated to add further
specification on efficient use of TCP connections
* Section 6.2.2 of 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.
2. Document work via GitHub 2. Document work via GitHub
[THIS SECTION TO BE REMOVED BEFORE PUBLICATION] The Github repository [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] The Github repository
for this document is at <https://github.com/hanzhang0116/hzpa-dprive- for this document is at https://github.com/hanzhang0116/hzpa-dprive-
xfr-over-tls>. Proposed text and editorial changes are very much xfr-over-tls (https://github.com/hanzhang0116/hzpa-dprive-xfr-over-
welcomed there, but any functional changes should always first be tls). Proposed text and editorial changes are very much welcomed
discussed on the IETF DPRIVE WG (dns-privacy) mailing list. there, but any functional changes should always first be discussed on
the IETF DPRIVE WG (dns-privacy) mailing list.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] and [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Privacy terminology is as described in Section 3 of [RFC6973]. Privacy terminology is as described in Section 3 of [RFC6973].
DNS terminology is as described in [RFC8499]. Note that as in DNS terminology is as described in [RFC8499]. Note that as in
[RFC8499], the terms 'primary' and 'secondary' are used for two [RFC8499], the terms 'primary' and 'secondary' are used for two
servers engaged in zone transfers. servers engaged in zone transfers.
DoT: DNS-over-TLS as specified in [RFC7858] DoT: DNS-over-TLS as specified in [RFC7858]
skipping to change at page 6, line 27 skipping to change at page 6, line 50
4. Threat Model 4. Threat Model
The threat model considered here is one where the current contents The threat model considered here is one where the current contents
and size of the zone are considered sensitive and should be protected and size of the zone are considered sensitive and should be protected
during transfer. during transfer.
The threat model does not, however, consider the existence of a zone, The threat model does not, however, consider the existence of a zone,
the act of zone transfer between two entities, nor the identities of the act of zone transfer between two entities, nor the identities of
the nameservers hosting a zone (including both those acting as hidden the nameservers hosting a zone (including both those acting as hidden
primaries/secondaries or directly serving the zone) as sensitive primaries/secondaries or directly serving the zone) as sensitive
information. The proposed mechanisms does not attempt to obscure information. The proposed mechanism does not attempt to obscure such
such information. The reasons for this include: information. The reasons for this include:
o much of this information can be obtained by various methods * much of this information can be obtained by various methods,
including active scanning of the DNS including active scanning of the DNS
o an attacker who can monitor network traffic can relatively easily * an attacker who can monitor network traffic can relatively easily
infer relations between nameservers simply from traffic patterns, infer relations between nameservers simply from traffic patterns,
even when some or all of the traffic is encrypted even when some or all of the traffic is encrypted (in terms of
current deployments)
The model does not consider attacks on the mechanisms that trigger a
zone transfer, e.g., NOTIFY messages.
It is noted that simply using XoT will indicate a desire by the zone It is noted that simply using XoT will indicate a desire by the zone
owner that the contents of the zone remain confidential and so could 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 be subject to blocking (e.g., via blocking of port 853) if an
attacker had such capabilities. However this threat is likely true attacker had such capabilities. However this threat is likely true
of any such mechanism that attempts to encrypt data passed between of any such mechanism that attempts to encrypt data passed between
nameservers, e.g., IPsec. nameservers, e.g., IPsec.
5. Design Considerations for XoT 5. Design Considerations for XoT
o Confidentiality. Clearly using an encrypted transport for zone The following principles were considered in the design for XoT:
* Confidentiality. Clearly using an encrypted transport for zone
transfers will defeat zone content leakage that can occur via transfers will defeat zone content leakage that can occur via
passive surveillance. passive surveillance.
o Authentication. Use of single or mutual TLS (mTLS) authentication * Authentication. Use of single or mutual TLS (mTLS) authentication
(in combination with ACLs) can complement and potentially be an (in combination with access control lists (ACLs)) can complement
alternative to TSIG. and potentially be an alternative to TSIG.
o Performance. * Performance.
* Existing AXFR and IXFR mechanisms have the burden of backwards - Existing AXFR and IXFR mechanisms have the burden of backwards
compatibility with older implementations based on the original compatibility with older implementations based on the original
specifications in [RFC1034] and [RFC1035]. For example, some specifications in [RFC1034] and [RFC1035]. For example, some
older AXFR servers don't support using a TCP connection for older AXFR servers don't support using a TCP connection for
multiple AXFR sessions or XFRs of different zones because they multiple AXFR sessions or XFRs of different zones because they
have not been updated to follow the guidance in [RFC5936]. Any have not been updated to follow the guidance in [RFC5936]. Any
implementation of XoT would obviously be required to implement implementation of XoT would obviously be required to implement
optimized and interoperable transfers as described in optimized and interoperable transfers as described in
[RFC5936], e.g., transfer of multiple zones over one [RFC5936], e.g., transfer of multiple zones over one
connection. connection.
* Current usage of TCP for IXFR is sub-optimal in some cases i.e. - Current usage of TCP for IXFR is sub-optimal in some cases i.e.
connections are frequently closed after a single IXFR. connections are frequently closed after a single IXFR.
6. Connection and Data Flows in Existing XFR Mechanisms 6. Connection and Data Flows in Existing XFR Mechanisms
The original specification for zone transfers in [RFC1034] and The original specification for zone transfers in [RFC1034] and
[RFC1035] was based on a polling mechanism: a secondary performed a [RFC1035] was based on a polling mechanism: a secondary performed a
periodic SOA query (based on the refresh timer) to determine if an periodic query for the SOA (start of zone authority) record (based on
AXFR was required. the refresh timer) to determine if an AXFR was required.
[RFC1995] and [RFC1996] introduced the concepts of IXFR and NOTIFY [RFC1995] and [RFC1996] introduced the concepts of IXFR and NOTIFY
respectively, to provide for prompt propagation of zone updates. respectively, to provide for prompt propagation of zone updates.
This has largely replaced AXFR where possible, particularly for This has largely replaced AXFR where possible, particularly for
dynamically updated zones. dynamically updated zones.
[RFC5936] subsequently redefined the specification of AXFR to improve [RFC5936] subsequently redefined the specification of AXFR to improve
performance and interoperability. performance and interoperability.
In this document we use the term "XFR mechanism" to describe the In this document we use the term "XFR mechanism" to describe the
entire set of message exchanges between a secondary and a primary entire set of message exchanges between a secondary and a primary
that concludes in a successful AXFR or IXFR request/response. This that concludes in a successful AXFR or IXFR request/response. This
set may or may not include set may or may not include
o NOTIFY messages * NOTIFY messages
o SOA queries * SOA queries
o Fallback from IXFR to AXFR * Fallback from IXFR to AXFR
o Fallback from IXFR-over-UDP to IXFR-over-TCP * Fallback from IXFR-over-UDP to IXFR-over-TCP
The term is used to encompasses the range of permutations that are The term is used to encompass the range of permutations that are
possible and is useful to distinguish the 'XFR mechanism' from a possible and is useful to distinguish the 'XFR mechanism' from a
single XFR request/response exchange. single XFR request/response exchange.
6.1. AXFR Mechanism 6.1. AXFR Mechanism
The figure below provides an outline of an AXFR mechanism including The figure below provides an outline of an AXFR mechanism including
NOTIFYs. NOTIFYs.
Secondary Primary Secondary Primary
| NOTIFY | | NOTIFY |
| <-------------------------------- | UDP | <-------------------------------- | UDP
| --------------------------------> | | --------------------------------> |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------> | UDP (or part of | --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP session) | <-------------------------------- | a TCP session)
| SOA Response | | SOA Response |
| | | |
| | | |
| | | |
| AXFR Request | --- | AXFR Request | ---
| --------------------------------> | | | --------------------------------> | |
| <-------------------------------- | | | <-------------------------------- | |
| AXFR Response 1 | | | AXFR Response 1 | |
| (Zone data) | | | (Zone data) | |
| | | | | |
| <-------------------------------- | | TCP | <-------------------------------- | | TCP
| AXFR Response 2 | | Session | AXFR Response 2 | | Session
| (Zone data) | | | (Zone data) | |
| | | | | |
| <-------------------------------- | | | <-------------------------------- | |
| AXFR Response 3 | | | AXFR Response 3 | |
| (Zone data) | --- | (Zone data) | ---
| | | |
Figure 1. AXFR Mechanism Figure 1. AXFR Mechanism
1. An AXFR is often (but not always) preceded by a NOTIFY (over UDP) 1. An AXFR is often (but not always) preceded by a NOTIFY (over UDP)
from the primary to the secondary. A secondary may also initiate from the primary to the secondary. A secondary may also initiate
an AXFR based on a refresh timer or scheduled/triggered zone an AXFR based on a refresh timer or scheduled/triggered zone
maintenance. maintenance.
2. The secondary will normally (but not always) make a SOA query to 2. The secondary will normally (but not always) make a SOA query to
the primary to obtain the serial number of the zone held by the the primary to obtain the serial number of the zone held by the
primary. primary.
3. If the primary serial is higher than the secondaries serial 3. If the primary serial is higher than the secondary's serial
(using Serial Number Arithmetic [RFC1982]), the secondary makes (using Serial Number Arithmetic [RFC1982]), the secondary makes
an AXFR request (over TCP) to the primary after which the AXFR an AXFR request (over TCP) to the primary after which the AXFR
data flows in one or more AXFR responses on the TCP connection. data flows in one or more AXFR responses on the TCP connection.
[RFC5936] defines this specific step as an 'AXFR session' i.e. as [RFC5936] defines this specific step as an 'AXFR session' i.e. as
an AXFR query message and the sequence of AXFR response messages an AXFR query message and the sequence of AXFR response messages
returned for it. returned for it.
[RFC5936] re-specified AXFR providing additional guidance beyond that [RFC5936] re-specified AXFR providing additional guidance beyond that
provided in [RFC1034] and [RFC1035] and importantly specified that provided in [RFC1034] and [RFC1035] and importantly specified that
AXFR must use TCP as the transport protocol. AXFR must use TCP as the transport protocol.
skipping to change at page 10, line 5 skipping to change at page 10, line 24
example, it outlines that the SOA query can also happen on this example, it outlines that the SOA query can also happen on this
connection. However, this can cause interoperability problems with connection. However, this can cause interoperability problems with
older implementations that support only the trivial case of one AXFR older implementations that support only the trivial case of one AXFR
per connection. per connection.
6.2. IXFR Mechanism 6.2. IXFR Mechanism
The figure below provides an outline of the IXFR mechanism including The figure below provides an outline of the IXFR mechanism including
NOTIFYs. NOTIFYs.
Secondary Primary Secondary Primary
| NOTIFY | | NOTIFY |
| <-------------------------------- | UDP | <-------------------------------- | UDP
| --------------------------------> | | --------------------------------> |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------> | UDP or TCP | --------------------------------> | UDP or TCP
| <-------------------------------- | | <-------------------------------- |
| SOA Response | | SOA Response |
| | | |
| | | |
| | | |
| IXFR Request | | IXFR Request |
| --------------------------------> | UDP or TCP | --------------------------------> | UDP or TCP
| <-------------------------------- | | <-------------------------------- |
| IXFR Response | | IXFR Response |
| (Zone data) | | (Zone data) |
| | | |
| | --- | | ---
| IXFR Request | | | IXFR Request | |
| --------------------------------> | | Retry over | --------------------------------> | | Retry over
| <-------------------------------- | | TCP if | <-------------------------------- | | TCP if
| IXFR Response | | required | IXFR Response | | required
| (Zone data) | --- | (Zone data) | ---
Figure 2. IXFR Mechanism Figure 2. IXFR Mechanism
1. An IXFR is normally (but not always) preceded by a NOTIFY (over 1. An IXFR is normally (but not always) preceded by a NOTIFY (over
UDP) from the primary to the secondary. A secondary may also UDP) from the primary to the secondary. A secondary may also
initiate an IXFR based on a refresh timer or scheduled/triggered initiate an IXFR based on a refresh timer or scheduled/triggered
zone maintenance. zone maintenance.
2. The secondary will normally (but not always) make a SOA query to 2. The secondary will normally (but not always) make a SOA query to
the primary to obtain the serial number of the zone held by the the primary to obtain the serial number of the zone held by the
primary. primary.
3. If the primary serial is higher than the secondaries serial 3. If the primary serial is higher than the secondaries serial
(using Serial Number Arithmetic [RFC1982]), the secondary makes (using Serial Number Arithmetic [RFC1982]), the secondary makes
an IXFR request to the primary after which the primary sends an an IXFR request to the primary after which the primary sends an
IXFR response. IXFR response.
[RFC1995] specifies that Incremental Transfer may use UDP if the [RFC1995] specifies that Incremental Transfer may use UDP if the
entire IXFR response can be contained in a single DNS packet, entire IXFR response can be contained in a single DNS packet,
otherwise, TCP is used. In fact it says: otherwise, TCP is used. In fact it says:
"Thus, a client should first make an IXFR query using UDP." "Thus, a client should first make an IXFR query using UDP."
So there may be a fourth step above where the client falls back to So there may be a fourth step above where the client falls back to
IXFR-over-TCP. There may also be a fourth step where the secondary IXFR-over-TCP. There may also be a additional step where the
must fall back to AXFR because, e.g., the primary does not support secondary must fall back to AXFR because, e.g., the primary does not
IXFR. support IXFR.
However it is noted that most widely used open source authoritative However it is noted that most widely used open source authoritative
nameserver implementations (including both [BIND] and [NSD]) do IXFR nameserver implementations (including both [BIND] and [NSD]) do IXFR
using TCP by default in their latest releases. For BIND TCP using TCP by default in their latest releases. For BIND, TCP
connections are sometimes used for SOA queries but in general they connections are sometimes used for SOA queries but in general they
are not used persistently and close after an IXFR is completed. are not used persistently and close after an IXFR is completed.
6.3. Data Leakage of NOTIFY and SOA Message Exchanges 6.3. Data Leakage of NOTIFY and SOA Message Exchanges
This section attempts to presents a rationale for considering This section presents a rationale for considering encrypting the
encrypting the other messages in the XFR mechanism. other messages in the XFR mechanism.
Since the SOA of the published zone can be trivially discovered by Since the SOA of the published zone can be trivially discovered by
simply querying the publicly available authoritative servers leakage simply querying the publicly available authoritative servers, leakage
of this RR is not discussed in the following sections. of this resource record (RR) via such a direct query is not discussed
in the following sections.
6.3.1. NOTIFY 6.3.1. NOTIFY
Unencrypted NOTIFY messages identify configured secondaries on the Unencrypted NOTIFY messages identify configured secondaries on the
primary. primary.
[RFC1996] also states: [RFC1996] also states:
"If ANCOUNT>0, then the answer section represents an "If ANCOUNT>0, then the answer section represents an
unsecure hint at the new RRset for this (QNAME,QCLASS,QTYPE). unsecure hint at the new RRset for this (QNAME,QCLASS,QTYPE).
But since the only supported QTYPE for NOTIFY is SOA, this does not But since the only QTYPE for NOTIFY defined at the time of this
pose a potential leak. writing is SOA, this does not pose a potential leak.
6.3.2. SOA 6.3.2. SOA
For hidden primaries or secondaries the SOA response leaks only the For hidden XFR servers (either primaries or secondaries), an SOA
degree of SOA serial number lag of any downstream secondary. response directly from that server only additionally leaks the degree
of SOA serial number lag of any downstream secondary of that server.
7. Updates to existing specifications 7. Updates to existing specifications
For convenience, the term 'XFR-over-TCP' is used in this document to For convenience, the term 'XFR-over-TCP' is used in this document to
mean both IXFR-over-TCP and AXFR-over-TCP and therefore statements mean both IXFR-over-TCP and AXFR-over-TCP and therefore statements
that use that term update both [RFC1995] and [RFC5936], and that use that term update both [RFC1995] and [RFC5936], and
implicitly also apply to XoT. Differences in behavior specific to implicitly also apply to XoT. Differences in behavior specific to
XoT are discussed in Section 8. XoT are discussed in Section 8.
Both [RFC1995] and [RFC5936] were published sometime before TCP was Both [RFC1995] and [RFC5936] were published sometime before TCP was
considered a first class transport for DNS. [RFC1995], in fact, says considered a first class transport for DNS. [RFC1995], in fact, says
nothing with respect to optimizing IXFRs over TCP or re-using already nothing with respect to optimizing IXFRs over TCP or re-using already
open TCP connections to perform IXFRs or other queries. Therefore, open TCP connections to perform IXFRs or other queries. Therefore,
there arguably is an implicit assumption that a TCP connection is there arguably is an implicit assumption that a TCP connection is
used for one and only one IXFR request. Indeed, many major open used for one and only one IXFR request. Indeed, many major open
source implementations currently take this approach. And whilst source implementations take this approach (at the time of this
[RFC5936] gives guidance on connection re-use for AXFR, it pre-dates writing). And whilst [RFC5936] gives guidance on connection re-use
more recent specifications describing persistent TCP connections, for AXFR, it pre-dates more recent specifications describing
e.g., [RFC7766], [RFC7828] and AXFR implementations again often make persistent TCP connections (e.g., [RFC7766], [RFC7828]), and AXFR
less than optimal use of open connections. implementations again often make less than optimal use of open
connections.
Given this, new implementations of XoT will clearly benefit from Given this, new implementations of XoT will clearly benefit from
specific guidance on TCP/TLS connection usage for XFR because this specific guidance on TCP/TLS connection usage for XFR, because this
will: will:
o result in more consistent XoT implementations with better * result in more consistent XoT implementations with better
interoperability interoperability
o remove any need for XoT implementations to support legacy behavior * remove any need for XoT implementations to support legacy behavior
that XFR-over-TCP implementations have historically often for XoT connections that XFR-over-TCP implementations have
supported historically often supported
Therefore this document updates both the previous specifications for Therefore this document updates both the previous specifications for
XFR-over-TCP to clarify that XFR-over-TCP ([RFC1995] and [RFC5936]) to clarify that
* Implementations MUST use [RFC7766] (DNS Transport over TCP -
o Implementations MUST use [RFC7766] (DNS Transport over TCP -
Implementation Requirements) to optimize the use of TCP Implementation Requirements) to optimize the use of TCP
connections. connections.
o Whilst RFC7766 states that 'DNS clients SHOULD pipeline their * Whilst RFC7766 states that 'DNS clients SHOULD pipeline their
queries' on TCP connections, it did not distinguish between XFRs queries' on TCP connections, it did not distinguish between XFRs
and other queries for this behavior. It is now recognized that and other queries for this behavior. It is now recognized that
XFRs are not as latency sensitive as other queries, and can be XFRs are not as latency sensitive as other queries, and can be
significantly more complex for clients to handle both because of significantly more complex for clients to handle, both because of
the large amount of state that must be kept and because there may the large amount of state that must be kept and because there may
be multiple messages in the responses. For these reasons it is be multiple messages in the responses. For these reasons, it is
clarified here that a valid reason for not pipelining queries is clarified here that a valid reason for not pipelining queries is
when they are all XFR queries i.e. clients sending multiple XFRs when they are all XFR queries i.e. clients sending multiple XFRs
MAY choose not to pipeline those queries. Clients that do not MAY choose not to pipeline those queries. Clients that do not
pipeline XFR queries, therefore, have no additional requirements pipeline XFR queries, therefore, have no additional requirements
to handle out-of-order or intermingled responses (as described to handle out-of-order or intermingled responses (as described
later) since they will never receive them. later), since they will never receive them.
o Implementations SHOULD use [RFC7828] (The edns-tcp-keepalive EDNS0 * Implementations SHOULD use [RFC7828] (The edns-tcp-keepalive EDNS0
Option) to manage persistent connections. Option) to manage persistent connections (which is more flexible
than using just fixed timeouts).
The following sections include detailed clarifications on the updates The following sections include detailed clarifications on the updates
to XFR behavior implied in [RFC7766] and how the use of [RFC7828] to XFR behavior implied in [RFC7766] and how the use of [RFC7828]
applies specifically to XFR exchanges. It also discusses how IXFR applies specifically to XFR exchanges. They also discuss how IXFR
and AXFR can reuse the same TCP connection. and AXFR can reuse the same TCP connection.
For completeness, we also mention here the recent specification of For completeness, we also mention here the recent specification of
extended DNS error (EDE) codes [RFC8914]. For zone transfers, when extended DNS error (EDE) codes [RFC8914]. For zone transfers, when
returning REFUSED to a zone transfer request from an 'unauthorized' returning REFUSED to a zone transfer request from an 'unauthorized'
client (e.g., where the client is not listed in an ACL for zone client (e.g., where the client is not listed in an ACL for zone
transfers or does not sign the request with the correct TSIG key), transfers or does not sign the request with a valid TSIG key), the
the extended DNS error code 18 (Prohibited) can also be sent. extended DNS error code 18 (Prohibited) can also be sent.
7.1. Update to RFC1995 for IXFR-over-TCP 7.1. Update to RFC1995 for IXFR-over-TCP
For clarity - an IXFR-over-TCP server compliant with this For clarity - an IXFR-over-TCP server compliant with this
specification MUST be able to handle multiple concurrent IXoT specification MUST be able to handle multiple concurrent IXoT
requests on a single TCP connection (for the same and different requests on a single TCP connection (for the same and different
zones) and SHOULD send the responses as soon as they are available, zones) and SHOULD send the responses as soon as they are available,
which might be out-of-order compared to the requests. which might be out-of-order compared to the requests.
7.2. Update to RFC5936 for AXFR-over-TCP 7.2. Update to RFC5936 for AXFR-over-TCP
skipping to change at page 13, line 47 skipping to change at page 14, line 27
7.3.1. Connection reuse 7.3.1. Connection reuse
As specified, XFR-over-TCP clients SHOULD re-use any existing open As specified, XFR-over-TCP clients SHOULD re-use any existing open
TCP connection when starting any new XFR request to the same primary, TCP connection when starting any new XFR request to the same primary,
and for issuing SOA queries, instead of opening a new connection. and for issuing SOA queries, instead of opening a new connection.
The number of TCP connections between a secondary and primary SHOULD The number of TCP connections between a secondary and primary SHOULD
be minimized (also see Section 7.4). be minimized (also see Section 7.4).
Valid reasons for not re-using existing connections might include: Valid reasons for not re-using existing connections might include:
o as already noted in [RFC7766], separate connections for different * as already noted in [RFC7766], separate connections for different
zones might be preferred for operational reasons. In this case zones might be preferred for operational reasons. In this case,
the number of concurrent connections for zone transfers SHOULD be the number of concurrent connections for zone transfers SHOULD be
limited to the total number of zones transferred between the limited to the total number of zones transferred between the
client and server. client and server.
o reaching a configured limit for the number of outstanding queries * reaching a configured limit for the number of outstanding queries
or XFR requests allowed on a single TCP connection or XFR requests allowed on a single TCP connection
o the message ID pool has already been exhausted on an open * the message ID pool has already been exhausted on an open
connection connection
o a large number of timeouts or slow responses have occurred on an * a large number of timeouts or slow responses have occurred on an
open connection open connection
o an edns-tcp-keepalive EDNS0 option with a timeout of 0 has been * an edns-tcp-keepalive EDNS0 option with a timeout of 0 has been
received from the server and the client is in the process of received from the server and the client is in the process of
closing the connection (see Section 7.3.4) closing the connection (see Section 7.3.4)
If no TCP connections are currently open, XFR clients MAY send SOA If no TCP connections are currently open, XFR clients MAY send SOA
queries over UDP or a new TCP connection. queries over UDP or a new TCP connection.
7.3.2. AXFRs and IXFRs on the same connection 7.3.2. AXFRs and IXFRs on the same connection
Neither [RFC1995] nor [RFC5936] explicitly discuss the use of a Neither [RFC1995] nor [RFC5936] explicitly discuss the use of a
single TCP connection for both IXFR and AXFR requests. [RFC5936] single TCP connection for both IXFR and AXFR requests. [RFC5936]
does make the general statement: does make the general statement:
"Non-AXFR session traffic can also use an open TCP connection." "Non-AXFR session traffic can also use an open TCP connection."
We clarify here that implementations capable of both AXFR and IXFR We clarify here that implementations capable of both AXFR and IXFR
and compliant with this specification SHOULD and compliant with this specification SHOULD
o use the same TCP connection for both AXFR and IXFR requests to the * use the same TCP connection for both AXFR and IXFR requests to the
same primary same primary
o pipeline such requests (if they pipeline XFR requests in general) * pipeline such requests (if they pipeline XFR requests in general)
and MAY intermingle them and MAY intermingle them
o send the response(s) for each request as soon as they are * send the response(s) for each request as soon as they are
available i.e. responses MAY be sent intermingled available i.e. responses MAY be sent intermingled
For some current implementations adding all the above functionality
would introduce significant code complexity. In such a case, there
will need to be an assessment of the trade-off between that and the
performance benefits of the above for XFR.
7.3.3. XFR limits 7.3.3. XFR limits
The server MAY limit the number of concurrent IXFRs, AXFRs or total The server MAY limit the number of concurrent IXFRs, AXFRs or total
XFR transfers in progress, or from a given secondary, to protect XFR transfers in progress, or from a given secondary, to protect
server resources. Servers SHOULD return SERVFAIL if this limit is server resources. Servers SHOULD return SERVFAIL if this limit is
hit, since it is a transient error and a retry at a later time might hit, since it is a transient error and a retry at a later time might
succeed. succeed (there is no previous specification for this behavior).
7.3.4. The edns-tcp-keepalive EDNS0 Option 7.3.4. The edns-tcp-keepalive EDNS0 Option
XFR clients that send the edns-tcp-keepalive EDNS0 option on every XFR clients that send the edns-tcp-keepalive EDNS0 option on every
XFR request provide the server with maximum opportunity to update the XFR request provide the server with maximum opportunity to update the
edns-tcp-keepalive timeout. The XFR server may use the frequency of edns-tcp-keepalive timeout. The XFR server may use the frequency of
recent XFRs to calculate an average update rate as input to the recent XFRs to calculate an average update rate as input to the
decision of what edns-tcp-keepalive timeout to use. If the server decision of what edns-tcp-keepalive timeout to use. If the server
does not support edns-tcp-keepalive the client MAY keep the does not support edns-tcp-keepalive, the client MAY keep the
connection open for a few seconds ([RFC7766] recommends that servers connection open for a few seconds ([RFC7766] recommends that servers
use timeouts of at least a few seconds). use timeouts of at least a few seconds).
Whilst the specification for EDNS0 [RFC6891] does not specifically Whilst the specification for EDNS0 [RFC6891] does not specifically
mention AXFRs, it does say mention AXFRs, it does say
"If an OPT record is present in a received request, compliant
"If an OPT record is present in a received request, compliant responders MUST include an OPT record in their respective
responders MUST include an OPT record in their respective responses."
responses."
We clarify here that if an OPT record is present in a received AXFR We clarify here that if an OPT record is present in a received AXFR
request, compliant responders MUST include an OPT record in each of request, compliant responders MUST include an OPT record in each of
the subsequent AXFR responses. Note that this requirement, combined the subsequent AXFR responses. Note that this requirement, combined
with the use of edns-tcp-keepalive, enables AXFR servers to signal with the use of edns-tcp-keepalive, enables AXFR servers to signal
the desire to close a connection (when existing transactions have the desire to close a connection (when existing transactions have
competed) due to low resources by sending an edns-tcp-keepalive EDNS0 competed) due to low resources by sending an edns-tcp-keepalive EDNS0
option with a timeout of 0 on any AXFR response. This does not option with a timeout of 0 on any AXFR response. This does not
signal that the AXFR is aborted, just that the server wishes to close signal that the AXFR is aborted, just that the server wishes to close
the connection as soon as possible. the connection as soon as possible.
7.3.5. Backwards compatibility 7.3.5. Backwards compatibility
Certain legacy behaviors were noted in [RFC5936], with provisions Certain legacy behaviors were noted in [RFC5936], with provisions
that implementations may want to offer options to fallback to legacy that implementations may want to offer options to fallback to legacy
behavior when interoperating with servers known not to support behavior when interoperating with servers known to not support
[RFC5936]. For purposes of interoperability, IXFR and AXFR [RFC5936]. For purposes of interoperability, IXFR and AXFR
implementations may want to continue offering such configuration implementations may want to continue offering such configuration
options, as well as supporting some behaviors that were options, as well as supporting some behaviors that were
underspecified prior to this work (e.g., performing IXFR and AXFRs on underspecified prior to this work (e.g., performing IXFR and AXFRs on
separate connections). However, XoT implementations should have no separate connections). However, XoT connections should have no need
need to do so. to do so.
7.4. Update to RFC7766 7.4. Update to RFC7766
[RFC7766] made general implementation recommendations with regard to [RFC7766] made general implementation recommendations with regard to
TCP/TLS connection handling: TCP/TLS connection handling:
"To mitigate the risk of unintentional server overload, DNS "To mitigate the risk of unintentional server overload, DNS
clients MUST take care to minimize the number of concurrent TCP clients MUST take care to minimize the number of concurrent TCP
connections made to any individual server. It is RECOMMENDED connections made to any individual server. It is RECOMMENDED
that for any given client/server interaction there SHOULD be no that for any given client/server interaction there SHOULD be no
more than one connection for regular queries, one for zone more than one connection for regular queries, one for zone
transfers, and one for each protocol that is being used on top transfers, and one for each protocol that is being used on top
of TCP (for example, if the resolver was using TLS). However, of TCP (for example, if the resolver was using TLS). However,
it is noted that certain primary/ secondary configurations with it is noted that certain primary/ secondary configurations with
many busy zones might need to use more than one TCP connection many busy zones might need to use more than one TCP connection
for zone transfers for operational reasons (for example, to for zone transfers for operational reasons (for example, to
support concurrent transfers of multiple zones)." support concurrent transfers of multiple zones)."
Whilst this recommends a particular behavior for the clients using Whilst this recommends a particular behavior for the clients using
TCP, it does not relax the requirement for servers to handle 'mixed' TCP, it does not relax the requirement for servers to handle 'mixed'
traffic (regular queries and zone transfers) on any open TCP/TLS traffic (regular queries and zone transfers) on any open TCP/TLS
connection. It also overlooks the potential that other transports connection. It also overlooks the potential that other transports
might want to take the same approach with regard to using separate might want to take the same approach with regard to using separate
connections for different purposes. connections for different purposes.
This specification for XoT updates the guidance in [RFC7766] to This specification updates the above general guidance in [RFC7766] to
provide the same separation of connection purpose (regular queries provide the same separation of connection purpose (regular queries
and zone transfers) for all transports being used on top of TCP. and zone transfers) for all transports being used on top of TCP.
Therefore, it is RECOMMENDED that for each protocol used on top of Therefore, it is RECOMMENDED that for each protocol used on top of
TCP in any given client/server interaction there SHOULD be no more TCP in any given client/server interaction, there SHOULD be no more
than one connection for regular queries and one for zone transfers. than one connection for regular queries and one for zone transfers.
As an illustration, it could be imagined that in future such an As an illustration, it could be imagined that in future such an
interaction could hypothetically include one or all of the following: interaction could hypothetically include one or all of the following:
o one TCP connection for regular queries * one TCP connection for regular queries
o one TCP connection for zone transfers * one TCP connection for zone transfers
o one TLS connection for regular queries * one TLS connection for regular queries
o one TLS connection for zone transfers * one TLS connection for zone transfers
o one DoH connection for regular queries * one DoH connection for regular queries
o one DoH connection for zone transfers * one DoH connection for zone transfers
Section 7.3.1 has provided specific details of reasons where more Section 7.3.1 has provided specific details of reasons where more
than one connection for a given transport might be required for zone than one connection for a given transport might be required for zone
transfers from a particular client. transfers from a particular client.
8. XoT specification 8. XoT specification
8.1. TLS versions 8.1. Connection establishment
For improved security all implementations of this specification MUST During connection establishment the Application-Layer Protocol
use only TLS 1.3 [RFC8446] or later. Negotiation (ALPN) token "dot" [DoT-ALPN] MUST be selected in the TLS
handshake.
8.2. Port selection 8.2. TLS versions
All implementations of this specification MUST use only TLS 1.3
[RFC8446] or later.
8.3. Port selection
The connection for XoT SHOULD be established using port 853, as The connection for XoT SHOULD be established using port 853, as
specified in [RFC7858], unless there is mutual agreement between the specified in [RFC7858], unless there is mutual agreement between the
secondary and primary to use a port other than port 853 for XoT. secondary and primary to use a port other than port 853 for XoT.
There MAY be agreement to use different ports for AXoT and IXoT, or There MAY be agreement to use different ports for AXoT and IXoT, or
for different zones. for different zones.
8.3. High level XoT descriptions 8.4. High level XoT descriptions
It is useful to note that in XoT it is the secondary that initiates It is useful to note that in XoT, it is the secondary that initiates
the TLS connection to the primary for a XFR request, so that in terms the TLS connection to the primary for a XFR request, so that in terms
of connectivity the secondary is the TLS client and the primary the of connectivity, the secondary is the TLS client and the primary the
TLS server. TLS server.
The figure below provides an outline of the AXoT mechanism including The figure below provides an outline of the AXoT mechanism including
NOTIFYs. NOTIFYs.
Secondary Primary Secondary Primary
| NOTIFY | | NOTIFY |
| <-------------------------------- | UDP | <-------------------------------- | UDP
| --------------------------------> | | --------------------------------> |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------> | UDP (or part of | --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP/TLS session) | <-------------------------------- | a TCP/TLS session)
| SOA Response | | SOA Response |
| | | |
| | | |
| | | |
| AXFR Request | --- | AXFR Request | ---
| --------------------------------> | | | --------------------------------> | |
| <-------------------------------- | | | <-------------------------------- | |
| AXFR Response 1 | | | AXFR Response 1 | |
| (Zone data) | | | (Zone data) | |
| | | | | |
| <-------------------------------- | | TLS | <-------------------------------- | | TLS
| AXFR Response 2 | | Session | AXFR Response 2 | | Session
| (Zone data) | | | (Zone data) | |
| | | | | |
| <-------------------------------- | | | <-------------------------------- | |
| AXFR Response 3 | | | AXFR Response 3 | |
| (Zone data) | --- | (Zone data) | ---
| | | |
Figure 3. AXoT Mechanism Figure 3. AXoT Mechanism
The figure below provides an outline of the IXoT mechanism including The figure below provides an outline of the IXoT mechanism including
NOTIFYs. NOTIFYs.
Secondary Primary Secondary Primary
| NOTIFY | | NOTIFY |
| <-------------------------------- | UDP | <-------------------------------- | UDP
| --------------------------------> | | --------------------------------> |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------> | UDP (or part of | --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP/TLS session) | <-------------------------------- | a TCP/TLS session)
| SOA Response | | SOA Response |
| | | |
| | | |
| | | |
| IXFR Request | --- | IXFR Request | ---
| --------------------------------> | | | --------------------------------> | |
| <-------------------------------- | | | <-------------------------------- | |
| IXFR Response | | | IXFR Response | |
| (Zone data) | | | (Zone data) | |
| | | TLS | | | TLS
| | | session | | | session
| IXFR Request | | | IXFR Request | |
| --------------------------------> | | | --------------------------------> | |
| <-------------------------------- | | | <-------------------------------- | |
| IXFR Response | | | IXFR Response | |
| (Zone data) | --- | (Zone data) | ---
Figure 4. IXoT Mechanism Figure 4. IXoT Mechanism
8.4. XoT transfers 8.5. XoT transfers
For a zone transfer between two end points to be considered protected For a zone transfer between two end points to be considered protected
with XoT all XFR requests and response for that zone MUST be sent with XoT all XFR requests and response for that zone MUST be sent
over TLS connections where at a minimum: over TLS connections where at a minimum:
o the client MUST authenticate the server by use of an * the client MUST authenticate the server by use of an
authentication domain name using a Strict Privacy Profile as authentication domain name using a Strict Privacy Profile, as
described in [RFC8310] described in [RFC8310]
o the server MUST validate the client is authorized to request or * the server MUST validate the client is authorized to request or
proxy a zone transfer by using one or both of the following: proxy a zone transfer by using one or both of the following
methods:
* an IP based ACL (which can be either per-message or per-
connection)
* Mutual TLS (mTLS) - Mutual TLS (mTLS)
- an IP based ACL (which can be either per-message or per-
connection) combined with a valid TSIG/SIG(0) signature on the
XFR request
The server MAY also require a valid TSIG/SIG(0) signature, but this If only one method is selected then mTLS is preferred because it
alone is not sufficient to authenticate the client or server. provides strong cryptographic protection at both endpoints.
Authentication mechanisms are discussed in full in Section 10 and the Authentication mechanisms are discussed in full in Section 10 and the
rationale for the above requirement in Section 11. Transfer group rationale for the above requirement in Section 11. Transfer group
policies are discussed in Section 12. policies are discussed in Section 12.
8.5. XoT connections 8.6. XoT connections
The details in Section 7 about, e.g., persistent connections and XFR The details in Section 7 about, e.g., persistent connections and XFR
message handling are fully applicable to XoT connections as well. message handling are fully applicable to XoT connections as well.
However any behavior specified here takes precedence for XoT. However, any behavior specified here takes precedence for XoT.
If no TLS connections are currently open, XoT clients MAY send SOA If no TLS connections are currently open, XoT clients MAY send SOA
queries over UDP or TCP, or TLS. queries over UDP or TCP, or TLS.
8.6. XoT vs ADoT 8.7. XoT vs ADoT
As noted earlier, there is currently no specification for encryption As noted earlier, there is currently no specification for encryption
of connections from recursive resolvers to authoritative servers. of connections from recursive resolvers to authoritative servers.
Some authoritatives are experimenting with ADoT and opportunistic Some authoritatives are experimenting with ADoT and opportunistic
encryption has also been raised as a possibility; it is therefore encryption has also been raised as a possibility; it is therefore
highly likely that use of encryption by authoritative servers will highly likely that use of encryption by authoritative servers will
evolve in the coming years. evolve in the coming years.
This raises questions in the short term with regard to TLS connection This raises questions in the short term with regard to TLS connection
and message handling for authoritative servers. In particular, there and message handling for authoritative servers. In particular, there
is likely to be a class of authoritatives that wish to use XoT in the is likely to be a class of authoritatives that wish to use XoT in the
near future with a small number of configured secondaries but that do near future with a small number of configured secondaries, but that
wish to support DoT for regular queries from recursive in that same do not wish to support DoT for regular queries from recursives in
time frame. These servers have to potentially cope with probing and that same time frame. These servers have to potentially cope with
direct queries from recursives and from test servers, and also probing and direct queries from recursives and from test servers, and
potential attacks that might wish to make use of TLS to overload the also potential attacks that might wish to make use of TLS to overload
server. the server.
[RFC5936] clearly states that non-AXFR session traffic can use an [RFC5936] clearly states that non-AXFR session traffic can use an
open TCP connection, however, this requirement needs to be re- open TCP connection, however, this requirement needs to be re-
evaluated when considering applying the same model to XoT. Proposing evaluated when considering applying the same model to XoT. Proposing
that a server should also start responding to all queries received that a server should also start responding to all queries received
over TLS just because it has enabled XoT would be equivalent to over TLS just because it has enabled XoT would be equivalent to
defining a form of authoritative DoT. This specification does not defining a form of authoritative DoT. This specification does not
propose that, but it also does not prohibit servers from answering propose that, but it also does not prohibit servers from answering
queries unrelated to XFR exchanges over TLS. Rather, this queries unrelated to XFR exchanges over TLS. Rather, this
specification simply outlines in later sections: specification simply outlines in later sections:
o how XoT implementations should utilize EDE codes in response to * how XoT implementations should utilize EDE codes in response to
queries on TLS connections they are not willing to answer (see queries on TLS connections they are not willing to answer (see
Section 8.7) Section 8.8)
o the operational and policy options that a XoT server operator has * the operational and policy options that a XoT server operator has
with regard to managing TLS connections and messages (see with regard to managing TLS connections and messages (see
Appendix A) Appendix A)
8.7. Response RCODES 8.8. Response RCODES
XoT clients and servers MUST implement EDE codes. If a XoT server XoT clients and servers MUST implement EDE codes. If a XoT server
receives non-XoT traffic it is not willing to answer on a TLS receives non-XoT traffic it is not willing to answer on a TLS
connection it SHOULD respond with the extended DNS error code 21 - connection, it SHOULD respond with REFUSED and the extended DNS error
Not Supported [RFC8914]. XoT clients should not send any further code 21 - Not Supported [RFC8914]. XoT clients should not send any
queries of this type to the server for a reasonable period of time further queries of this type to the server for a reasonable period of
(for example, one hour) i.e., long enough that the server time (for example, one hour) i.e., long enough that the server
configuration or policy might be updated. configuration or policy might be updated.
Historically servers have used the REFUSED RCODE for many situations, Historically, servers have used the REFUSED RCODE for many
and so clients often had no detailed information on which to base an situations, and so clients often had no detailed information on which
error or fallback path when queries were refused. As a result the to base an error or fallback path when queries were refused. As a
client behavior could vary significantly. XoT servers that refuse result, the client behavior could vary significantly. XoT servers
queries must cater for the fact that client behavior might vary from that refuse queries must cater for the fact that client behavior
continually retrying queries regardless of receiving REFUSED to every might vary from continually retrying queries regardless of receiving
query, or at the other extreme clients may decide to stop using the REFUSED to every query, or at the other extreme clients may decide to
server over any transport. This might be because those clients are stop using the server over any transport. This might be because
either non-XoT clients or do not implement EDE codes. those clients are either non-XoT clients or do not implement EDE
codes.
8.8. AXoT specifics 8.9. AXoT specifics
8.8.1. Padding AXoT responses 8.9.1. Padding AXoT responses
The goal of padding AXoT responses would be two fold: The goal of padding AXoT responses is two fold:
o to obfuscate the actual size of the transferred zone to minimize * to obfuscate the actual size of the transferred zone to minimize
information leakage about the entire contents of the zone. information leakage about the entire contents of the zone.
o to obfuscate the incremental changes to the zone between SOA * to obfuscate the incremental changes to the zone between SOA
updates to minimize information leakage about zone update activity updates to minimize information leakage about zone update activity
and growth. and growth.
Note that the re-use of XoT connections for transfers of multiple Note that the re-use of XoT connections for transfers of multiple
different zones complicates any attempt to analyze the traffic size different zones slightly complicates any attempt to analyze the
and timing to extract information. traffic size and timing to extract information. Also, effective
padding may require state to be kept as zones may grow and/or shrink
over time.
It is noted here that, depending on the padding policies eventually It is noted here that, depending on the padding policies eventually
developed for XoT, the requirement to obfuscate the total zone size developed for XoT, the requirement to obfuscate the total zone size
might require a server to create 'empty' AXoT responses. That is, might require a server to create 'empty' AXoT responses. That is,
AXoT responses that contain no RR's apart from an OPT RR containing AXoT responses that contain no RR's apart from an OPT RR containing
the EDNS(0) option for padding. For example, without this capability the EDNS(0) option for padding. For example, without this capability
the maximum size that a tiny zone could be padded to would the maximum size that a tiny zone could be padded to would
theoretically be limited if there had to be a minimum of 1 RR per theoretically be limited if there had to be a minimum of 1 RR per
packet. packet.
However, as with existing AXFR, the last AXoT response message sent However, as with existing AXFR, the last AXoT response message sent
MUST contain the same SOA that was in the first message of the AXoT MUST contain the same SOA that was in the first message of the AXoT
response series in order to signal the conclusion of the zone response series in order to signal the conclusion of the zone
transfer. transfer.
[RFC5936] says: [RFC5936] says:
"Each AXFR response message SHOULD contain a sufficient number "Each AXFR response message SHOULD contain a sufficient number
of RRs to reasonably amortize the per-message overhead, up to of RRs to reasonably amortize the per-message overhead, up to
the largest number that will fit within a DNS message (taking the largest number that will fit within a DNS message (taking
the required content of the other sections into account, as the required content of the other sections into account, as
described below)." described below)."
'Empty' AXoT responses generated in order to meet a padding 'Empty' AXoT responses generated in order to meet a padding
requirement will be exceptions to the above statement. For requirement will be exceptions to the above statement. For
flexibility, future proofing and in order to guarantee support for flexibility, future proofing and in order to guarantee support for
future padding policies, we state here that secondary implementations future padding policies, we state here that secondary implementations
MUST be resilient to receiving padded AXoT responses, including MUST be resilient to receiving padded AXoT responses, including
'empty' AXoT responses that contain only an OPT RR containing the 'empty' AXoT responses that contain only an OPT RR containing the
EDNS(0) option for padding. EDNS(0) option for padding.
Recommendation of specific policies for padding AXoT responses are Recommendation of specific policies for padding AXoT responses are
out of scope for this specification. Detailed considerations of such out of scope for this specification. Detailed considerations of such
policies and the trade-offs involved are expected to be the subject policies and the trade-offs involved are expected to be the subject
of future work. of future work.
8.9. IXoT specifics 8.10. IXoT specifics
8.9.1. Condensation of responses 8.10.1. Condensation of responses
[RFC1995] says condensation of responses is optional and MAY be done. [RFC1995] says condensation of responses is optional and MAY be done.
Whilst it does add complexity to generating responses it can Whilst it does add complexity to generating responses, it can
significantly reduce the size of responses. However any such significantly reduce the size of responses. However any such
reduction might be offset by increased message size due to padding. reduction might be offset by increased message size due to padding.
This specification does not update the optionality of condensation This specification does not update the optionality of condensation
for XoT responses. for XoT responses.
8.9.2. Fallback to AXFR 8.10.2. Fallback to AXFR
Fallback to AXFR can happen, for example, if the server is not able Fallback to AXFR can happen, for example, if the server is not able
to provide an IXFR for the requested SOA. Implementations differ in to provide an IXFR for the requested SOA. Implementations differ in
how long they store zone deltas and how many may be stored at any one how long they store zone deltas and how many may be stored at any one
time. time.
Just as with IXFR-over-TCP, after a failed IXFR a IXoT client SHOULD Just as with IXFR-over-TCP, after a failed IXFR a IXoT client SHOULD
request the AXFR on the already open XoT connection. request the AXFR on the already open XoT connection.
8.9.3. Padding of IXoT responses 8.10.3. Padding of IXoT responses
The goal of padding IXoT responses would be to obfuscate the The goal of padding IXoT responses is to obfuscate the incremental
incremental changes to the zone between SOA updates to minimize changes to the zone between SOA updates to minimize information
information leakage about zone update activity and growth. Both the leakage about zone update activity and growth. Both the size and
size and timing of the IXoT responses could reveal information. timing of the IXoT responses could reveal information.
IXFR responses can vary in size greatly from the order of 100 bytes IXFR responses can vary greatly in size from the order of 100 bytes
for one or two record updates, to tens of thousands of bytes for for one or two record updates, to tens of thousands of bytes for
large dynamic DNSSEC signed zones. The frequency of IXFR responses large dynamic DNSSEC signed zones. The frequency of IXFR responses
can also depend greatly on if and how the zone is DNSSEC signed. can also depend greatly on if and how the zone is DNSSEC signed.
In order to guarantee support for future padding policies, we state In order to guarantee support for future padding policies, we state
here that secondary implementations MUST be resilient to receiving here that secondary implementations MUST be resilient to receiving
padded IXoT responses. padded IXoT responses.
Recommendation of specific policies for padding IXoT responses are Recommendation of specific policies for padding IXoT responses are
out of scope for this specification. Detailed considerations of such out of scope for this specification. Detailed considerations of such
policies and the trade-offs involved are expected to be the subject padding policies, the use of traffic obfuscation techniques (such as
of future work. 'dummy' traffic), and the trade-offs involved are expected to be the
subject of future work.
8.10. Name compression and maximum payload sizes 8.11. Name compression and maximum payload sizes
It is noted here that name compression [RFC1035] can be used in XFR It is noted here that name compression [RFC1035] can be used in XFR
responses to reduce the size of the payload, however the maximum responses to reduce the size of the payload, however, the maximum
value of the offset that can be used in the name compression pointer value of the offset that can be used in the name compression pointer
structure is 16384. For some DNS implementations this limits the structure is 16384. For some DNS implementations this limits the
size of an individual XFR response used in practice to something size of an individual XFR response used in practice to something
around the order of 16kB. In principle, larger payload sizes can be around the order of 16kB. In principle, larger payload sizes can be
supported for some responses with more sophisticated approaches supported for some responses with more sophisticated approaches
(e.g., by pre-calculating the maximum offset required). (e.g., by pre-calculating the maximum offset required).
Implementations may wish to offer options to disable name compression Implementations may wish to offer options to disable name compression
for XoT responses to enable larger payloads. This might be for XoT responses to enable larger payloads. This might be
particularly helpful when padding is used since minimizing the particularly helpful when padding is used since minimizing the
payload size is not necessarily a useful optimization in this case payload size is not necessarily a useful optimization in this case
and disabling name compression will reduce the resources required to and disabling name compression will reduce the resources required to
construct the payload. construct the payload.
9. Multi-primary Configurations 9. Multi-primary Configurations
This model can provide flexibility and redundancy particularly for This model can provide flexibility and redundancy particularly for
IXFR. A secondary will receive one or more NOTIFY messages and can 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 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 other to send an XFR request to the primary with the highest SOA (or based
criteria, e.g., RTT). on other criteria, e.g., RTT).
When using persistent connections the secondary may have a XoT When using persistent connections, the secondary may have a XoT
connection already open to one or more primaries. Should a secondary connection already open to one or more primaries. Should a secondary
preferentially request an XFR from a primary to which it already has 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 an open XoT connection or the one with the highest SOA (assuming it
doesn't have a connection open to it already)? doesn't have a connection open to it already)?
Two extremes can be envisaged here. The first one can be considered Two extremes can be envisaged here. The first one can be considered
a 'preferred primary connection' model. In this case the secondary a 'preferred primary connection' model. In this case, the secondary
continues to use one persistent connection to a single primary until continues to use one persistent connection to a single primary until
it has reason not to. Reasons not to might include the primary it has reason not to. Reasons not to might include the primary
repeatedly closing the connection, long query/response RTTs on repeatedly closing the connection, long query/response RTTs on
transfers or the SOA of the primary being an unacceptable lag behind transfers or the SOA of the primary being an unacceptable lag behind
the SOA of an alternative primary. the SOA of an alternative primary.
The other extreme can be considered a 'parallel primary connection' The other extreme can be considered a 'parallel primary connection'
model. Here a secondary could keep multiple persistent connections model. Here, a secondary could keep multiple persistent connections
open to all available primaries and only request XFRs from the open to all available primaries and only request XFRs from the
primary with the highest serial number. Since normally the number of primary with the highest serial number. Since normally the number of
secondaries and primaries in direct contact in a transfer group is secondaries and primaries in direct contact in a transfer group is
reasonably low this might be feasible if latency is the most reasonably low this might be feasible if latency is the most
significant concern. significant concern.
Recommendation of a particular scheme is out of scope of this Recommendation of a particular scheme is out of scope of this
document but implementations are encouraged to provide configuration document, but implementations are encouraged to provide configuration
options that allow operators to make choices about this behavior. options that allow operators to make choices about this behavior.
10. Authentication mechanisms 10. Authentication mechanisms
To provide context to the requirements in section Section 8.4, this To provide context to the requirements in Section 8.5, this section
section provides a brief summary of some of the existing provides a brief summary of some of the existing authentication and
authentication and validation mechanisms (both transport independent validation mechanisms (both transport independent and TLS specific)
and TLS specific) that are available when performing zone transfers. that are available when performing zone transfers. Section 11 then
Section 11 then discusses in more details specifically how a discusses in more details specifically how a combination of TLS
combination of TLS authentication, TSIG and IP based ACLs interact authentication, TSIG and IP based ACLs interact for XoT.
for XoT.
We classify the mechanisms based on the following properties: We classify the mechanisms based on the following properties:
o 'Data Origin Authentication' (DO): Authentication that the DNS * 'Data Origin Authentication' (DO): Authentication that the DNS
message originated from the party with whom credentials were message originated from the party with whom credentials were
shared, and of the data integrity of the message contents (the shared, and of the data integrity of the message contents (the
originating party may or may not be party operating the far end of originating party may or may not be party operating the far end of
a TCP/TLS connection in a 'proxy' scenario). a TCP/TLS connection in a 'proxy' scenario).
o 'Channel Confidentiality' (CC): Confidentiality of the * 'Channel Confidentiality' (CC): Confidentiality of the
communication channel between the client and server (i.e. the two communication channel between the client and server (i.e. the two
end points of a TCP/TLS connection) from passive surveillance. end points of a TCP/TLS connection) from passive surveillance.
o 'Channel Authentication' (CA): Authentication of the identity of * 'Channel Authentication' (CA): Authentication of the identity of
party to whom a TCP/TLS connection is made (this might not be a party to whom a TCP/TLS connection is made (this might not be a
direct connection between the primary and secondary in a proxy direct connection between the primary and secondary in a proxy
scenario). scenario).
10.1. TSIG 10.1. TSIG
TSIG [RFC8945] provides a mechanism for two or more parties to use TSIG [RFC8945] provides a mechanism for two or more parties to use
shared secret keys which can then be used to create a message digest shared secret keys which can then be used to create a message digest
to protect individual DNS messages. This allows each party to to protect individual DNS messages. This allows each party to
authenticate that a request or response (and the data in it) came authenticate that a request or response (and the data in it) came
from the other party, even if it was transmitted over an unsecured from the other party, even if it was transmitted over an unsecured
channel or via a proxy. channel or via a proxy.
Properties: Data origin authentication Properties: Data origin authentication
10.2. SIG(0) 10.2. SIG(0)
SIG(0) [RFC2931] similarly also provides a mechanism to digitally SIG(0) [RFC2931] similarly provides a mechanism to digitally sign a
sign a DNS message but uses public key authentication, where the DNS message but uses public key authentication, where the public keys
public keys are stored in DNS as KEY RRs and a private key is stored are stored in DNS as KEY RRs and a private key is stored at the
at the signer. signer.
Properties: Data origin authentication Properties: Data origin authentication
10.3. TLS 10.3. TLS
10.3.1. Opportunistic TLS 10.3.1. Opportunistic TLS
Opportunistic TLS for DoT is defined in [RFC8310] and can provide a Opportunistic TLS for DoT is defined in [RFC8310] and can provide a
defense against passive surveillance, providing on-the-wire defense against passive surveillance, providing on-the-wire
confidentiality. Essentially confidentiality. Essentially
o clients that know authentication information for a server SHOULD * clients that know authentication information for a server SHOULD
try to authenticate the server try to authenticate the server
o however they MAY fallback to using TLS without authentication and * however they MAY fallback to using TLS without authentication and
o they MAY fallback to using cleartext if TLS is not available. * they MAY fallback to using cleartext if TLS is not available.
As such it does not offer a defense against active attacks (e.g., an As such, it does not offer a defense against active attacks (e.g., an
on path active attacker on the connection from client to server), and on path active attacker on the connection from client to server), and
is not considered as useful for XoT. is not considered as useful for XoT.
Properties: None guaranteed. Properties: None guaranteed.
10.3.2. Strict TLS 10.3.2. Strict TLS
Strict TLS for DoT [RFC8310] requires that a client is configured Strict TLS for DoT [RFC8310] requires that a client is configured
with an authentication domain name (and/or SPKI pinset) that MUST be with an authentication domain name (and/or SPKI pinset) that MUST be
used to authenticate the TLS handshake with the server. If used to authenticate the TLS handshake with the server. If
authentication of the server fails, the client will not proceed with authentication of the server fails, the client will not proceed with
the connection. This provides a defense for the client against the connection. This provides a defense for the client against
active surveillance, providing client-to-server authentication and active surveillance, providing client-to-server authentication and
end-to-end channel confidentiality. end-to-end channel confidentiality.
Properties: Channel confidentiality and authentication (of the Properties: Channel confidentiality and channel authentication (of
server). the server).
10.3.3. Mutual TLS 10.3.3. Mutual TLS
This is an extension to Strict TLS [RFC8310] which requires that a This is an extension to Strict TLS [RFC8310] which requires that a
client is configured with an authentication domain name (and/or SPKI client is configured with an authentication domain name (and/or SPKI
pinset) and a client certificate. The client offers the certificate pinset) and a client certificate. The client offers the certificate
for authentication by the server and the client can authenticate the for authentication by the server and the client can authenticate the
server the same way as in Strict TLS. This provides a defense for server the same way as in Strict TLS. This provides a defense for
both parties against active surveillance, providing bi-directional both parties against active surveillance, providing bi-directional
authentication and end-to-end channel confidentiality. authentication and end-to-end channel confidentiality.
Properties: Channel confidentiality and mutual authentication. Properties: Channel confidentiality and mutual channel
authentication.
10.4. IP Based ACL on the Primary 10.4. IP Based ACL on the Primary
Most DNS server implementations offer an option to configure an IP Most DNS server implementations offer an option to configure an IP
based Access Control List (ACL), which is often used in combination based Access Control List (ACL), which is often used in combination
with TSIG based ACLs to restrict access to zone transfers on primary with TSIG based ACLs to restrict access to zone transfers on primary
servers on a per query basis. servers on a per query basis.
This is also possible with XoT but it must be noted that, as with This is also possible with XoT, but it must be noted that, as with
TCP, the implementation of such an ACL cannot be enforced on the TCP, the implementation of such an ACL cannot be enforced on the
primary until an XFR request is received on an established primary until an XFR request is received on an established
connection. connection.
As discussed in Appendix A an IP based per connection ACL could also As discussed in Appendix A, an IP based per connection ACL could also
be implemented where only TLS connections from recognized secondaries be implemented where only TLS connections from recognized secondaries
are accepted. are accepted.
Properties: Channel authentication of the client. Properties: Channel authentication of the client.
10.5. ZONEMD 10.5. ZONEMD
For completeness, we also describe Message Digest for DNS Zones For completeness, we also describe Message Digest for DNS Zones
(ZONEMD) [RFC8976] here. The message digest is a mechanism that can (ZONEMD) [RFC8976] here. The message digest is a mechanism that can
be used to verify the content of a standalone zone. It is designed be used to verify the content of a standalone zone. It is designed
skipping to change at page 27, line 21 skipping to change at page 28, line 39
a general consumer of a zone to do origin authentication of the a general consumer of a zone to do origin authentication of the
entire zone contents. Note that the current version of [RFC8976] entire zone contents. Note that the current version of [RFC8976]
states: states:
"As specified herein, ZONEMD is impractical for large, dynamic zones "As specified herein, ZONEMD is impractical for large, dynamic zones
due to the time and resources required for digest calculation. due to the time and resources required for digest calculation.
However, The ZONEMD record is extensible so that new digest schemes However, The ZONEMD record is extensible so that new digest schemes
may be added in the future to support large, dynamic zones." may be added in the future to support large, dynamic zones."
It is complementary but orthogonal the above mechanisms; and can be It is complementary but orthogonal the above mechanisms; and can be
used in conjunction with XoT but is not considered further here. used in conjunction with XoT, but is not considered further here.
11. XoT authentication 11. XoT authentication
It is noted that zone transfer scenarios can vary from a simple It is noted that zone transfer scenarios can vary from a simple
single primary/secondary relationship where both servers are under single primary/secondary relationship where both servers are under
the control of a single operator to a complex hierarchical structure the control of a single operator to a complex hierarchical structure
which includes proxies and multiple operators. Each deployment which includes proxies and multiple operators. Each deployment
scenario will require specific analysis to determine which scenario will require specific analysis to determine which
combination of authentication methods are best suited to the combination of authentication methods are best suited to the
deployment model in question. deployment model in question.
The XoT authentication requirement specified in Section 8.4 addresses The XoT authentication requirement specified in Section 8.5 addresses
the issue of ensuring that the transfers is encrypted between the two the issue of ensuring that the transfers are encrypted between the
endpoints directly involved in the current transfers. The following two endpoints directly involved in the current transfers. The
table summarized the properties of a selection of the mechanisms following table summarizes the properties of a selection of the
discussed in Section 10. The two letter acronyms for the properties mechanisms discussed in Section 10. The two letter acronyms for the
are used below and (S) indicates the secondary and (P) indicates the properties are used below and (S) indicates the secondary and (P)
primary. indicates the primary.
+----------------+-------+-------+-------+-------+-------+-------+ +================+=======+=======+=======+=======+=======+=======+
| Method | DO(S) | CC(S) | CA(S) | DO(P) | CC(P) | CA(P) | | Method | DO(S) | CC(S) | CA(S) | DO(P) | CC(P) | CA(P) |
+----------------+-------+-------+-------+-------+-------+-------+ +================+=======+=======+=======+=======+=======+=======+
| Strict TLS | | Y | Y | | Y | | | Strict TLS | | Y | Y | | Y | |
+----------------+-------+-------+-------+-------+-------+-------+
| Mutual TLS | | Y | Y | | Y | Y | | Mutual TLS | | Y | Y | | Y | Y |
+----------------+-------+-------+-------+-------+-------+-------+
| ACL on primary | | | | | | Y | | ACL on primary | | | | | | Y |
+----------------+-------+-------+-------+-------+-------+-------+
| TSIG | Y | | | Y | | | | TSIG | Y | | | Y | | |
+----------------+-------+-------+-------+-------+-------+-------+ +----------------+-------+-------+-------+-------+-------+-------+
Table 1
Table 1: Properties of Authentication methods for XoT Table 1: Properties of Authentication methods for XoT
Based on this analysis it can be seen that: Based on this analysis it can be seen that:
o Using just mutual TLS can be considered a standalone solution * Using just mutual TLS can be considered a standalone solution
since both end points are authenticated since both end points are cryptographically authenticated
o Using Strict TLS and an IP based ACL on the primary also provides * Using secondary side Strict TLS with a primary side IP ACL and
authentication of both end points TSIG/SIG(0) combination provides sufficient protection to be
acceptable.
o Additional use of TSIG (or equally SIG(0)) can also provide data Using just an IP ACL could be susceptible to attacks that can spoof
origin authentication which might be desirable for deployments TCP IP addresses, using TSIG/SIG(0) alone could be susceptible to
that include a proxy between the secondary and primary, but is not attacks that were able to capture such messages should they be
part of the XoT requirement because it does nothing to guarantee accidentally sent in clear text by any server with the key.
channel confidentiality or authentication.
12. Policies for Both AXoT and IXoT 12. Policies for Both AXoT and IXoT
Whilst the protection of the zone contents in a transfer between two Whilst the protection of the zone contents in a transfer between two
end points can be provided by the XoT protocol, the protection of all end points can be provided by the XoT protocol, the protection of all
the transfers of a given zone requires operational administration and the transfers of a given zone requires operational administration and
policy management. policy management.
We call the entire group of servers involved in XFR for a particular We call the entire group of servers involved in XFR for a particular
set of zones (all the primaries and all the secondaries) the set of zones (all the primaries and all the secondaries) the
'transfer group'. 'transfer group'.
Within any transfer group both AXFRs and IXFRs for a zone MUST all
use the same policy, e.g., if AXFRs use AXoT then all IXFRs MUST use
IXoT.
In order to assure the confidentiality of the zone information, the In order to assure the confidentiality of the zone information, the
entire transfer group MUST have a consistent policy of requiring entire transfer group MUST have a consistent policy of using XoT. If
confidentiality. If any do not, this is a weak link for attackers to any do not, this is a weak link for attackers to exploit. For
exploit. clarification, this means that within any transfer group both AXFRs
and IXFRs for a zone MUST all use XoT.
An individual zone transfer is not considered protected by XoT unless An individual zone transfer is not considered protected by XoT unless
both the client and server are configured to use only XoT and the both the client and server are configured to use only XoT and the
overall zone transfer is not considered protected until all members overall zone transfer is not considered protected until all members
of the transfer group are configured to use only XoT with all other of the transfer group are configured to use only XoT with all other
transfers servers (see Section 13). transfers servers (see Section 13).
A XoT policy should specify A XoT policy MUST specify if
o What kind of TLS is required (Strict or Mutual TLS) * mutual TLS is used and/or
o or if an IP based ACL is required. * a IP ACL and TSIG/SIG(0) combination is used
o (optionally) if TSIG/SIG(0) is required
Since this may require configuration of a number of servers who may Since this may require configuration of a number of servers who may
be under the control of different operators the desired consistency be under the control of different operators the desired consistency
could be hard to enforce and audit in practice. could be hard to enforce and audit in practice.
Certain aspects of the Policies can be relatively easily tested Certain aspects of the Policies can be relatively easily tested
independently, e.g., by requesting zone transfers without TSIG, from independently, e.g., by requesting zone transfers without TSIG, from
unauthorized IP addresses or over cleartext DNS. Other aspects such unauthorized IP addresses or over cleartext DNS. Other aspects such
as if a secondary will accept data without a TSIG digest or if as if a secondary will accept data without a TSIG digest or if
secondaries are using Strict as opposed to Opportunistic TLS are more secondaries are using Strict as opposed to Opportunistic TLS are more
challenging. challenging.
skipping to change at page 29, line 50 skipping to change at page 31, line 20
None. None.
16. Implementation Status 16. Implementation Status
[THIS SECTION TO BE REMOVED BEFORE PUBLICATION] This section records [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] This section records
the status of known implementations of the protocol defined by this the status of known implementations of the protocol defined by this
specification at the time of posting of this Internet-Draft, and is specification at the time of posting of this Internet-Draft, and is
based on a proposal described in [RFC7942]. based on a proposal described in [RFC7942].
A summary of current behavior and implementation status can be found A summary of current behavior and implementation status can be found
here: XoT implementation status [1] here: XoT implementation status
(https://dnsprivacy.org/wiki/display/DP/
DNS+Privacy+Implementation+Status#DNSPrivacyImplementationStatus-XFR/
XoTImplementationstatus)
Specific recent activity includes: Specific recent activity includes:
1. The 1.9.2 version of Unbound [2] includes an option to perform 1. The 1.9.2 version of Unbound
AXoT (instead of AXFR-over-TCP). (https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/
Changelog) includes an option to perform AXoT (instead of AXFR-
over-TCP).
2. There are currently open pull requests against NSD to implement 2. There are currently open pull requests against NSD to implement
1. Connection re-use by default during XFR-over-TCP [3] 1. Connection re-use by default during XFR-over-TCP
(https://github.com/NLnetLabs/nsd/pull/145)
2. Client side XoT [4] 2. Client side XoT (https://github.com/NLnetLabs/nsd/pull/149)
3. Version 9.17.7 of BIND contained an initial implementation of 3. Version 9.17.7 of BIND contained an initial implementation of
DoT, implementation of XoT is planned for early 2021 [5] DoT, implementation of XoT is planned for early 2021
(https://gitlab.isc.org/isc-projects/bind9/-/issues/1784)
Both items 1. and 2.2. listed above require the client (secondary) to Both items 1. and 2.2. listed above require the client (secondary) to
authenticate the server (primary) using a configured authentication authenticate the server (primary) using a configured authentication
domain name if XoT is used. domain name if XoT is used.
17. Security Considerations 17. Security Considerations
This document specifies a security measure against a DNS risk: the This document specifies a security measure against a DNS risk: the
risk that an attacker collects entire DNS zones through eavesdropping risk that an attacker collects entire DNS zones through eavesdropping
on clear text DNS zone transfers. on clear text DNS zone transfers.
This does not mitigate: This does not mitigate:
o the risk that some level of zone activity might be inferred by * the risk that some level of zone activity might be inferred by
observing zone transfer sizes and timing on encrypted connections observing zone transfer sizes and timing on encrypted connections
(even with padding applied), in combination with obtaining SOA (even with padding applied), in combination with obtaining SOA
records by directly querying authoritative servers. records by directly querying authoritative servers.
o the risk that hidden primaries might be inferred or identified via * the risk that hidden primaries might be inferred or identified via
observation of encrypted connections. observation of encrypted connections.
o the risk of zone contents being obtained via zone enumeration * the risk of zone contents being obtained via zone enumeration
techniques. techniques.
Security concerns of DoT are outlined in [RFC7858] and [RFC8310]. Security concerns of DoT are outlined in [RFC7858] and [RFC8310].
18. Acknowledgements 18. Acknowledgements
The authors thank Tony Finch, Benno Overeinder, Shumon Huque and Tim The authors thank Tony Finch, Benno Overeinder, Shumon Huque and Tim
Wicinski and many other members of DPRIVE for review and discussions. Wicinski and many other members of DPRIVE for review and discussions.
The authors particularly thank Peter van Dijk, Ondrej Sury, Brian The authors particularly thank Peter van Dijk, Ondrej Sury, Brian
skipping to change at page 31, line 20 skipping to change at page 32, line 45
Salesforce Salesforce
San Francisco, CA San Francisco, CA
United States United States
Email: hzhang@salesforce.com Email: hzhang@salesforce.com
20. Changelog 20. Changelog
[THIS SECTION TO BE REMOVED BEFORE PUBLICATION] [THIS SECTION TO BE REMOVED BEFORE PUBLICATION]
draft-ietf-dprive-xfr-over-tls-12
* Changes from IESG review
* Add section 8.1 on the requirement to use the DoT ALPN
* Modify the one of the options for validation of a client from just
an IP ACL to a combination of IP ACL and TSIG/SIG(0)
- Update Abstract and Introduction with clear descriptions of how
earlier specifications are updated
- Add reference on NSEC3 attacks
- Justify use of SHOULD in sections 7.3.2 and 7.3.3.
- Clarify the Appendix is non-normative
- Numerous typos and editorial improvements.
- Use xml2rfc v3 (some format changes occur as a result)
draft-ietf-dprive-xfr-over-tls-11
* Fix definition update missed in -10
draft-ietf-dprive-xfr-over-tls-10 draft-ietf-dprive-xfr-over-tls-10
o Address issued raised from IETF Last Call * Address issued raised from IETF Last Call
draft-ietf-dprive-xfr-over-tls-09 draft-ietf-dprive-xfr-over-tls-09
o Address issued raised in the AD review * Address issued raised in the AD review
draft-ietf-dprive-xfr-over-tls-08 draft-ietf-dprive-xfr-over-tls-08
o RFC2845 -> (obsoleted by) RFC8945 * RFC2845 -> (obsoleted by) RFC8945
o I-D.ietf-dnsop-dns-zone-digest -> RFC8976 * I-D.ietf-dnsop-dns-zone-digest -> RFC8976
o Minor editorial changes + email update * Minor editorial changes + email update
draft-ietf-dprive-xfr-over-tls-07 draft-ietf-dprive-xfr-over-tls-07
o Reference RFC7942 in the implementation status section * Reference RFC7942 in the implementation status section
o Convert the URIs that will remain on publication to references * Convert the URIs that will remain on publication to references
o Correct typos in acknowledgments * Correct typos in acknowledgments
draft-ietf-dprive-xfr-over-tls-06 draft-ietf-dprive-xfr-over-tls-06
o Update text relating to pipelining and connection reuse after WGLC * Update text relating to pipelining and connection reuse after WGLC
comments. comments.
o Add link to implementation status matrix * Add link to implementation status matrix
* Various typos
o Various typos draft-ietf-dprive-xfr-over-tls-05
o Remove the open questions that received no comments.
o Add more detail to the implementation section * Remove the open questions that received no comments.
* Add more detail to the implementation section
draft-ietf-dprive-xfr-over-tls-04 draft-ietf-dprive-xfr-over-tls-04
o Add Github repository * Add Github repository
o Fix typos and references and improve layout. * Fix typos and references and improve layout.
draft-ietf-dprive-xfr-over-tls-03 draft-ietf-dprive-xfr-over-tls-03
o Remove propose to use ALPN * Remove propose to use ALPN
o Clarify updates to both RFC1995 and RFC5936 by adding specific * Clarify updates to both RFC1995 and RFC5936 by adding specific
sections on this sections on this
o Add a section on the threat model * Add a section on the threat model
o Convert all SVG diagrams to ASCII art * Convert all SVG diagrams to ASCII art
o Add discussions on concurrency limits * Add discussions on concurrency limits
o Add discussions on Extended DNS error codes * Add discussions on Extended DNS error codes
o Re-work authentication requirements and discussion * Re-work authentication requirements and discussion
o Add appendix discussion TLS connection management * Add appendix discussion TLS connection management
draft-ietf-dprive-xfr-over-tls-02 draft-ietf-dprive-xfr-over-tls-02
o Significantly update descriptions for both AXoT and IXoT for * Significantly update descriptions for both AXoT and IXoT for
message and connection handling taking into account previous message and connection handling taking into account previous
specifications in more detail specifications in more detail
o Add use of APLN and limitations on traffic on XoT connections. * Add use of APLN and limitations on traffic on XoT connections.
o Add new discussions of padding for both AXoT and IXoT
o Add text on SIG(0) * Add new discussions of padding for both AXoT and IXoT
o Update security considerations * Add text on SIG(0)
o Move multi-primary considerations to earlier as they are related * Update security considerations
* Move multi-primary considerations to earlier as they are related
to connection handling to connection handling
o Minor editorial updates draft-ietf-dprive-xfr-over-tls-01
o Add requirement for TLS 1.3. or later * Minor editorial updates
* Add requirement for TLS 1.3. or later
draft-ietf-dprive-xfr-over-tls-00 draft-ietf-dprive-xfr-over-tls-00
o Rename after adoption and reference update. * Rename after adoption and reference update.
o Add placeholder for SIG(0) discussion * Add placeholder for SIG(0) discussion
o Update section on ZONEMD * Update section on ZONEMD
draft-hzpa-dprive-xfr-over-tls-02 draft-hzpa-dprive-xfr-over-tls-02
o Substantial re-work of the document. * Substantial re-work of the document.
draft-hzpa-dprive-xfr-over-tls-01 draft-hzpa-dprive-xfr-over-tls-01
o Editorial changes, updates to references. * Editorial changes, updates to references.
draft-hzpa-dprive-xfr-over-tls-00 draft-hzpa-dprive-xfr-over-tls-00
o Initial commit * Initial commit
21. References [-@?I-D.ietf-tls-esni]
21.1. Normative References 21. Normative References
[I-D.ietf-dprive-rfc7626-bis] [DoT-ALPN] IANA, "TLS Application-Layer Protocol Negotiation (ALPN)
Wicinski, T., "DNS Privacy Considerations", draft-ietf- Protocol IDs", 2021, <https://www.iana.org/assignments/
dprive-rfc7626-bis-08 (work in progress), October 2020. tls-extensiontype-values/tls-extensiontype-
values.xhtml#alpn-protocol-ids>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
DOI 10.17487/RFC1995, August 1996, <https://www.rfc- DOI 10.17487/RFC1995, August 1996,
editor.org/info/rfc1995>. <https://www.rfc-editor.org/info/rfc1995>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <https://www.rfc-editor.org/info/rfc1996>. August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
(AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
<https://www.rfc-editor.org/info/rfc5936>. <https://www.rfc-editor.org/info/rfc5936>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, <https://www.rfc- DOI 10.17487/RFC6973, July 2013,
editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<https://www.rfc-editor.org/info/rfc7766>. <https://www.rfc-editor.org/info/rfc7766>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", RFC 7828, edns-tcp-keepalive EDNS0 Option", RFC 7828,
DOI 10.17487/RFC7828, April 2016, <https://www.rfc- DOI 10.17487/RFC7828, April 2016,
editor.org/info/rfc7828>. <https://www.rfc-editor.org/info/rfc7828>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310, for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018, <https://www.rfc- DOI 10.17487/RFC8310, March 2018,
editor.org/info/rfc8310>. <https://www.rfc-editor.org/info/rfc8310>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914, Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020, <https://www.rfc- DOI 10.17487/RFC8914, October 2020,
editor.org/info/rfc8914>. <https://www.rfc-editor.org/info/rfc8914>.
[RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
Gudmundsson, O., and B. Wellington, "Secret Key Gudmundsson, O., and B. Wellington, "Secret Key
Transaction Authentication for DNS (TSIG)", STD 93, Transaction Authentication for DNS (TSIG)", STD 93,
RFC 8945, DOI 10.17487/RFC8945, November 2020, RFC 8945, DOI 10.17487/RFC8945, November 2020,
<https://www.rfc-editor.org/info/rfc8945>. <https://www.rfc-editor.org/info/rfc8945>.
21.2. Informative References 22. Informative References
[BIND] ISC, "BIND 9", 2021, <https://www.isc.org/bind/>. [BIND] ISC, "BIND 9.16.16", 2021, <https://www.isc.org/bind/>.
[I-D.ietf-dprive-dnsoquic] [I-D.ietf-dprive-dnsoquic]
Huitema, C., Mankin, A., and S. Dickinson, "Specification Huitema, C., Mankin, A., and S. Dickinson, "Specification
of DNS over Dedicated QUIC Connections", draft-ietf- of DNS over Dedicated QUIC Connections", Work in Progress,
dprive-dnsoquic-01 (work in progress), October 2020. Internet-Draft, draft-ietf-dprive-dnsoquic-02, 22 February
2021, <https://tools.ietf.org/html/draft-ietf-dprive-
dnsoquic-02>.
[I-D.ietf-dprive-phase2-requirements] [I-D.ietf-dprive-phase2-requirements]
Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS
Privacy Requirements for Exchanges between Recursive Privacy Requirements for Exchanges between Recursive
Resolvers and Authoritative Servers", draft-ietf-dprive- Resolvers and Authoritative Servers", Work in Progress,
phase2-requirements-02 (work in progress), November 2020. Internet-Draft, draft-ietf-dprive-phase2-requirements-02,
2 November 2020, <https://tools.ietf.org/html/draft-ietf-
dprive-phase2-requirements-02>.
[I-D.ietf-dprive-rfc7626-bis]
Wicinski, T., "DNS Privacy Considerations", Work in
Progress, Internet-Draft, draft-ietf-dprive-rfc7626-bis-
09, 9 March 2021, <https://tools.ietf.org/html/draft-ietf-
dprive-rfc7626-bis-09>.
[I-D.ietf-tls-esni] [I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", draft-ietf-tls-esni-09 (work in Encrypted Client Hello", Work in Progress, Internet-Draft,
progress), December 2020. draft-ietf-tls-esni-10, 8 March 2021,
<https://tools.ietf.org/html/draft-ietf-tls-esni-10>.
[I-D.vcelak-nsec5] [I-D.vcelak-nsec5]
Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and
D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of
Existence", draft-vcelak-nsec5-08 (work in progress), Existence", Work in Progress, Internet-Draft, draft-
December 2018. vcelak-nsec5-08, 29 December 2018,
<https://tools.ietf.org/html/draft-vcelak-nsec5-08>.
[nist-guide]
Chandramouli, R. and S. Rose, "Secure Domain Name System
(DNS) Deployment Guide", 2013,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-81-2.pdf>.
[NSD] NLnet Labs, "NSD", 2021, [NSD] NLnet Labs, "NSD 4.3.6", 2021,
<https://www.nlnetlabs.nl/projects/nsd/about/>. <https://www.nlnetlabs.nl/projects/nsd/about/>.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [NSEC3-attacks]
DOI 10.17487/RFC1982, August 1996, <https://www.rfc- Goldberf, S., Naor, N., Papadopoulos, D., Reyzin, L.,
editor.org/info/rfc1982>. Vasant, S., and A. Ziv, "Stretching NSEC3 to the Limit:
Efficient Zone Enumeration Attacks on NSEC3 Variants",
2015,
<https://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September DOI 10.17487/RFC1982, August 1996,
2000, <https://www.rfc-editor.org/info/rfc2931>. <https://www.rfc-editor.org/info/rfc1982>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>. <https://www.rfc-editor.org/info/rfc5155>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013, <https://www.rfc- DOI 10.17487/RFC6891, April 2013,
editor.org/info/rfc6891>. <https://www.rfc-editor.org/info/rfc6891>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. [RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W.
Hardaker, "Message Digest for DNS Zones", RFC 8976, Hardaker, "Message Digest for DNS Zones", RFC 8976,
DOI 10.17487/RFC8976, February 2021, <https://www.rfc- DOI 10.17487/RFC8976, February 2021,
editor.org/info/rfc8976>. <https://www.rfc-editor.org/info/rfc8976>.
21.3. URIs
[1] https://dnsprivacy.org/wiki/display/DP/
DNS+Privacy+Implementation+Status#DNSPrivacyImplementationStatus-
XFR/XoTImplementationstatus
[2] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/
Changelog
[3] https://github.com/NLnetLabs/nsd/pull/145
[4] https://github.com/NLnetLabs/nsd/pull/149
[5] https://gitlab.isc.org/isc-projects/bind9/-/issues/1784 [nist-guide]
Chandramouli, R. and S. Rose, "Secure Domain Name System
(DNS) Deployment Guide", 2013,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-81-2.pdf>.
Appendix A. XoT server connection handling Appendix A. XoT server connection handling
This appendix provides a non-normative outline of the pros and cons
of XoT server connection handling options.
For completeness, it is noted that an earlier version of the For completeness, it is noted that an earlier version of the
specification suggested using a XoT specific ALPN to negotiate TLS specification suggested using a XoT specific ALPN to negotiate TLS
connections that supported only a limited set of queries (SOA, XRFs) connections that supported only a limited set of queries (SOA, XRFs),
however this did not gain support. Reasons given included additional however, this did not gain support. Reasons given included
code complexity and proxies having no natural way to forward the ALPN additional code complexity and the fact that XoT and ADoT are both
signal to DNS nameservers over TCP connections. DNS wire format and so should share the "dot" ALPN.
A.1. Only listen on TLS on a specific IP address A.1. Only listen on TLS on a specific IP address
Obviously a nameserver which hosts a zone and services queries for Obviously a nameserver which hosts a zone and services queries for
the zone on an IP address published in an NS record may wish to use a the zone on an IP address published in an NS record may wish to use a
separate IP address for listening on TLS for XoT, only publishing separate IP address for listening on TLS for XoT, only publishing
that address to its secondaries. that address to its secondaries.
Pros: Probing of the public IP address will show no support for TLS. Pros: Probing of the public IP address will show no support for TLS.
ACLs will prevent zone transfer on all transports on a per query ACLs will prevent zone transfer on all transports on a per query
skipping to change at page 38, line 5 skipping to change at page 40, line 22
Cons: Currently, none of the major open source DNS authoritative Cons: Currently, none of the major open source DNS authoritative
implementations support such an option. implementations support such an option.
A.3. SNI based TLS acceptance A.3. SNI based TLS acceptance
Primaries could also choose to only accept TLS connections based on Primaries could also choose to only accept TLS connections based on
an SNI that was published only to their secondaries. an SNI that was published only to their secondaries.
Pros: Reduces the number of accepted connections. Pros: Reduces the number of accepted connections.
Cons: As above. For SNIs sent in the clear, this would still allow Cons: As above. Also, this is not a recommended use of SNI. For
attackers passively observing traffic to potentially abuse this SNIs sent in the clear, this would still allow attackers passively
mechanism. The use of Encrypted Client Hello [I-D.ietf-tls-esni] may observing traffic to potentially abuse this mechanism. The use of
be of use here. Encrypted Client Hello [I-D.ietf-tls-esni] may be of use here.
A.4. TLS specific response policies A.4. Transport specific response policies
Some primaries might rely on TSIG/SIG(0) combined with per-query IP Some primaries might rely on TSIG/SIG(0) combined with per-query IP
based ACLs to authenticate secondaries. In this case the primary based ACLs to authenticate secondaries. In this case the primary
must accept all incoming TLS connections and then apply a TLS must accept all incoming TLS/TCP connections and then apply a
specific response policy on a per query basis. transport-specific response policy on a per query basis.
As an aside, whilst [RFC7766] makes a general purpose distinction to As an aside, whilst [RFC7766] makes a general purpose distinction in
clients in the usage of connections (between regular queries and zone the advice to clients about their usage of connections (between
transfers) this is not strict and nothing in the DNS protocol regular queries and zone transfers) this is not strict and nothing in
prevents using the same connection for both types of traffic. Hence the DNS protocol prevents using the same connection for both types of
a server cannot know the intention of any client that connects to it, traffic. Hence a server cannot know the intention of any client that
it can only inspect the messages it receives on such a connection and connects to it, it can only inspect the messages it receives on such
make per query decisions about whether or not to answer those a connection and make per-query decisions about whether or not to
queries. answer those queries.
Example policies a XoT server might implement are: Example policies a XoT server might implement are:
o strict: REFUSE all queries on TLS connections except SOA and * strict: REFUSE all queries on TLS connections except SOA and
authorized XFR requests authorized XFR requests
o moderate: REFUSE all queries on TLS connections until one is * moderate: REFUSE all queries on TLS connections until one is
received that is signed by a recognized TSIG/SIG(0) key, then received that is signed by a recognized TSIG/SIG(0) key, then
answer all queries on the connection after that answer all queries on the connection after that
o complex: apply a heuristic to determine which queries on a TLS * complex: apply a heuristic to determine which queries on a TLS
connections to REFUSE connections to REFUSE
o relaxed: answer all non-XoT queries on all TLS connections with * relaxed: answer all non-XoT queries on all TLS connections with
the same policy applied to TCP queries the same policy applied to TCP queries
Pros: Allows for flexible behavior by the server that could be Pros: Allows for flexible behavior by the server that could be
changed over time. changed over time.
Cons: The server must handle the burden of accepting all TLS Cons: The server must handle the burden of accepting all TLS
connections just to perform XFRs with a small number of secondaries. connections just to perform XFRs with a small number of secondaries.
Client behavior to REFUSED response is not clearly defined (see Client behavior to REFUSED response is not clearly defined (see
below). Currently, none of the major open source DNS authoritative Section 8.8). Currently, none of the major open source DNS
implementations offer an option for different response policies in authoritative implementations offer an option for different response
different transports (but could potentially be implemented using a policies in different transports (but such functionality could
proxy). potentially be implemented using a proxy).
A.4.1. SNI based response policies A.4.1. SNI based response policies
In a similar fashion, XoT servers might use the presence of an SNI in In a similar fashion, XoT servers might use the presence of an SNI in
the client hello to determine which response policy to initially the client hello to determine which response policy to initially
apply to the TLS connections. apply to the TLS connections.
Pros: This has to potential to allow a clean distinction between a Pros: This has to potential to allow a clean distinction between a
XoT service and any future DoT based service for answering recursive XoT service and any future DoT based service for answering recursive
queries. queries.
Cons: As above. Cons: As above.
Authors' Addresses Authors' Addresses
Willem Toorop Willem Toorop
NLnet Labs NLnet Labs
Science Park 400 Science Park 400
Amsterdam 1098 XH Amsterdam
The Netherlands
Email: willem@nlnetlabs.nl Email: willem@nlnetlabs.nl
Sara Dickinson Sara Dickinson
Sinodun IT Sinodun IT
Magdalen Centre Magdalen Centre
Oxford Science Park Oxford Science Park
Oxford OX4 4GA Oxford
OX4 4GA
United Kingdom United Kingdom
Email: sara@sinodun.com Email: sara@sinodun.com
Shivan Sahib Shivan Sahib
Salesforce Brave Software
Vancouver, BC Vancouver, BC
Canada Canada
Email: shivankaulsahib@gmail.com Email: shivankaulsahib@gmail.com
Pallavi Aras Pallavi Aras
Salesforce Salesforce
Herndon, VA Herndon, VA,
United States United States
Email: paras@salesforce.com Email: paras@salesforce.com
Allison Mankin Allison Mankin
Salesforce Salesforce
Herndon, VA Herndon, VA,
United States United States
Email: allison.mankin@gmail.com Email: allison.mankin@gmail.com
 End of changes. 257 change blocks. 
592 lines changed or deleted 674 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/