draft-ietf-dprive-xfr-over-tls-03.txt   draft-ietf-dprive-xfr-over-tls-04.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: May 6, 2021 S. Sahib Expires: May 27, 2021 S. Sahib
P. Aras P. Aras
A. Mankin A. Mankin
Salesforce Salesforce
November 2, 2020 November 23, 2020
DNS Zone Transfer-over-TLS DNS Zone Transfer-over-TLS
draft-ietf-dprive-xfr-over-tls-03 draft-ietf-dprive-xfr-over-tls-04
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 use of TLS, rather then clear text, to prevent document specifies use of TLS, rather then clear text, to prevent
zone content collection via passive monitoring of zone transfers: zone content collection via passive monitoring of zone transfers:
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 http://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 May 6, 2021. This Internet-Draft will expire on May 27, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Document work via GitHub . . . . . . . . . . . . . . . . . . 5
3. Use Cases for XFR-over-TLS . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 6 4. Use Cases for XFR-over-TLS . . . . . . . . . . . . . . . . . 6
4. Connection and Data Flows in Existing XFR Mechanisms . . . . 7 4.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 6
4.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 7 5. Connection and Data Flows in Existing XFR Mechanisms . . . . 7
4.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 9 5.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 7
4.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 11 5.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 11
4.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 11
5. Updates to existing specifications . . . . . . . . . . . . . 11 5.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Update to RFC1995 for IXFR-over-TCP . . . . . . . . . . . 12 6. Updates to existing specifications . . . . . . . . . . . . . 11
5.2. Update to RFC5936 for AXFR-over-TCP . . . . . . . . . . . 13 6.1. Update to RFC1995 for IXFR-over-TCP . . . . . . . . . . . 12
5.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP . . . . . 13 6.2. Update to RFC5936 for AXFR-over-TCP . . . . . . . . . . . 13
5.3.1. Connection reuse . . . . . . . . . . . . . . . . . . 13 6.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP . . . . . 13
5.3.2. AXFRs and IXFRs on the same connection . . . . . . . 13 6.3.1. Connection reuse . . . . . . . . . . . . . . . . . . 13
5.3.3. XFR limits . . . . . . . . . . . . . . . . . . . . . 14 6.3.2. AXFRs and IXFRs on the same connection . . . . . . . 13
5.3.4. The edns-tcp-keepalive EDNS0 Option . . . . . . . . . 14 6.3.3. XFR limits . . . . . . . . . . . . . . . . . . . . . 14
5.3.5. Backwards compatibility . . . . . . . . . . . . . . . 15 6.3.4. The edns-tcp-keepalive EDNS0 Option . . . . . . . . . 14
5.4. Update to RFC7766 . . . . . . . . . . . . . . . . . . . . 15 6.3.5. Backwards compatibility . . . . . . . . . . . . . . . 15
6. XoT specification . . . . . . . . . . . . . . . . . . . . . . 16 6.4. Update to RFC7766 . . . . . . . . . . . . . . . . . . . . 15
6.1. TLS versions . . . . . . . . . . . . . . . . . . . . . . 16 7. XoT specification . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Port selection . . . . . . . . . . . . . . . . . . . . . 16 7.1. TLS versions . . . . . . . . . . . . . . . . . . . . . . 16
6.3. High level XoT descriptions . . . . . . . . . . . . . . . 16 7.2. Port selection . . . . . . . . . . . . . . . . . . . . . 16
6.4. XoT transfers . . . . . . . . . . . . . . . . . . . . . . 18 7.3. High level XoT descriptions . . . . . . . . . . . . . . . 16
6.5. XoT connections . . . . . . . . . . . . . . . . . . . . . 19 7.4. XoT transfers . . . . . . . . . . . . . . . . . . . . . . 18
6.6. XoT vs ADoT . . . . . . . . . . . . . . . . . . . . . . . 19 7.5. XoT connections . . . . . . . . . . . . . . . . . . . . . 19
6.7. Response RCODES . . . . . . . . . . . . . . . . . . . . . 20 7.6. XoT vs ADoT . . . . . . . . . . . . . . . . . . . . . . . 19
6.8. AXoT specifics . . . . . . . . . . . . . . . . . . . . . 20 7.7. Response RCODES . . . . . . . . . . . . . . . . . . . . . 20
6.8.1. Padding AXoT responses . . . . . . . . . . . . . . . 20 7.8. AXoT specifics . . . . . . . . . . . . . . . . . . . . . 20
6.9. IXoT specifics . . . . . . . . . . . . . . . . . . . . . 21 7.8.1. Padding AXoT responses . . . . . . . . . . . . . . . 20
6.9.1. Condensation of responses . . . . . . . . . . . . . . 21 7.9. IXoT specifics . . . . . . . . . . . . . . . . . . . . . 21
6.9.2. Fallback to AXFR . . . . . . . . . . . . . . . . . . 21 7.9.1. Condensation of responses . . . . . . . . . . . . . . 21
6.9.3. Padding of IXoT responses . . . . . . . . . . . . . . 22 7.9.2. Fallback to AXFR . . . . . . . . . . . . . . . . . . 21
6.10. Name compression and maximum payload sizes . . . . . . . 22 7.9.3. Padding of IXoT responses . . . . . . . . . . . . . . 22
7. Multi-primary Configurations . . . . . . . . . . . . . . . . 22 7.10. Name compression and maximum payload sizes . . . . . . . 22
8. Authentication mechanisms . . . . . . . . . . . . . . . . . . 23
8.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Multi-primary Configurations . . . . . . . . . . . . . . . . 22
8.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Authentication mechanisms . . . . . . . . . . . . . . . . . . 23
8.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.3.1. Opportunistic TLS . . . . . . . . . . . . . . . . . . 24 9.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . 25 9.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.3.3. Mutual TLS . . . . . . . . . . . . . . . . . . . . . 25 9.3.1. Opportunistic TLS . . . . . . . . . . . . . . . . . . 24
8.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 25 9.3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . 25
8.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.3.3. Mutual TLS . . . . . . . . . . . . . . . . . . . . . 25
9. XoT authentication . . . . . . . . . . . . . . . . . . . . . 26 9.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 25
10. Policies for Both AXoT and IXoT . . . . . . . . . . . . . . . 27 9.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Implementation Considerations . . . . . . . . . . . . . . . . 28 10. XoT authentication . . . . . . . . . . . . . . . . . . . . . 26
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 28 11. Policies for Both AXoT and IXoT . . . . . . . . . . . . . . . 27
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 12. Implementation Considerations . . . . . . . . . . . . . . . . 28
14. Security Considerations . . . . . . . . . . . . . . . . . . . 28 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 28
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 15. Security Considerations . . . . . . . . . . . . . . . . . . . 28
17. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 29 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
18.1. Normative References . . . . . . . . . . . . . . . . . . 30 18. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 29
18.2. Informative References . . . . . . . . . . . . . . . . . 32 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
18.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 19.1. Normative References . . . . . . . . . . . . . . . . . . 31
19.2. Informative References . . . . . . . . . . . . . . . . . 32
19.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. XoT server connection handling . . . . . . . . . . . 34 Appendix A. XoT server connection handling . . . . . . . . . . . 34
A.1. Only listen on TLS on a specific IP address . . . . . . . 34 A.1. Only listen on TLS on a specific IP address . . . . . . . 34
A.2. Client specific TLS acceptance . . . . . . . . . . . . . 34 A.2. Client specific TLS acceptance . . . . . . . . . . . . . 34
A.3. SNI based TLS acceptance . . . . . . . . . . . . . . . . 35 A.3. SNI based TLS acceptance . . . . . . . . . . . . . . . . 35
A.4. TLS specific response policies . . . . . . . . . . . . . 35 A.4. TLS specific response policies . . . . . . . . . . . . . 35
A.4.1. SNI based response policies . . . . . . . . . . . . . 36 A.4.1. SNI based response policies . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
skipping to change at page 5, line 19 skipping to change at page 5, line 25
per query basis. Since requests typically occur on TCP connections per query basis. Since requests typically occur on TCP connections
authoritatives must cater for accepting any TCP connection and then authoritatives must cater for accepting any TCP connection and then
handling the authentication of each XFR request individually. handling the authentication of each XFR request individually.
Because both AXFR and IXFR zone transfers are typically carried out Because both AXFR and IXFR zone transfers are typically carried out
over TCP from authoritative DNS protocol implementations, encrypting over TCP from authoritative DNS protocol implementations, encrypting
zone transfers using TLS, based closely on DoT [RFC7858], seems like zone transfers using TLS, based closely on DoT [RFC7858], seems like
a simple step forward. This document specifies how to use TLS as a a simple step forward. This document specifies how to use TLS as a
transport to prevent zone collection from zone transfers. transport to prevent zone collection from zone transfers.
2. Terminology 2. Document work via GitHub
[THIS SECTION TO BE REMOVED BEFORE PUBLICATION] The Github repository
for this document is at <https://github.com/hanzhang0116/hzpa-dprive-
xfr-over-tls>. Proposed text and editorial changes are very much
welcomed there, but any functional changes should always first be
discussed on the IETF DPRIVE WG (dns-privacy) mailing list.
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] and [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].
Note that in this document we choose to use the terms 'primary' and Note that in this document we choose to use the terms 'primary' and
skipping to change at page 5, line 45 skipping to change at page 6, line 11
XFR-over-TCP: Used to mean both IXFR-over-TCP [RFC1995] and AXFR- XFR-over-TCP: Used to mean both IXFR-over-TCP [RFC1995] and AXFR-
over-TCP [RFC5936]. over-TCP [RFC5936].
XoT: Generic XFR-over-TLS mechanisms as specified in this document XoT: Generic XFR-over-TLS mechanisms as specified in this document
AXoT: AXFR-over-TLS AXoT: AXFR-over-TLS
IXoT: IXFR over-TLS IXoT: IXFR over-TLS
3. Use Cases for XFR-over-TLS 4. Use Cases for XFR-over-TLS
o Confidentiality. Clearly using an encrypted transport for zone o 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 o Authentication. Use of single or mutual TLS (mTLS) authentication
(in combination with ACLs) can complement and potentially be an (in combination with ACLs) can complement and potentially be an
alternative to TSIG. alternative to TSIG.
o Performance. Existing AXFR and IXFR mechanisms have the burden of o Performance. Existing AXFR and IXFR mechanisms have the burden of
skipping to change at page 6, line 22 skipping to change at page 6, line 34
some older AXFR servers don't support using a TCP connection for some 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 XFR-over-TLS (XoT) would obviously be required implementation of XFR-over-TLS (XoT) would obviously be required
to implement optimized and interoperable transfers as described in to implement optimized and interoperable transfers as described in
[RFC5936], e.g., transfer of multiple zones over one connection. [RFC5936], e.g., transfer of multiple zones over one connection.
o Performance. Current usage of TCP for IXFR is sub-optimal in some o Performance. Current usage of TCP for IXFR is sub-optimal in some
cases i.e. connections are frequently closed after a single IXFR. cases i.e. connections are frequently closed after a single IXFR.
3.1. Threat model 4.1. 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 mechanisms does not attempt to obscure
skipping to change at page 7, line 5 skipping to change at page 7, line 12
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
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 attacker be subject to blocking (e.g. via blocking of port 853) if an attacker
had such capabilities. However this threat is likely true of any had such capabilities. However this threat is likely true of any
such mechanism that attempts to encrypt data passed between such mechanism that attempts to encrypt data passed between
nameservers e.g. IPsec. nameservers e.g. IPsec.
4. Connection and Data Flows in Existing XFR Mechanisms 5. 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 SOA query (based on the refresh timer) to determine if an
AXFR was required. 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.
skipping to change at page 7, line 37 skipping to change at page 7, line 44
o SOA queries o SOA queries
o Fallback from IXFR to AXFR o Fallback from IXFR to AXFR
o Fallback from IXFR-over-UDP to IXFR-over-TCP o 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 encompasses 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.
4.1. AXFR Mechanism 5.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 |
| <-------------------------------- | UPD | <-------------------------------- | UPD
| --------------------------------> | | --------------------------------> |
| NOTIFY Response | | NOTIFY Response |
skipping to change at page 9, line 21 skipping to change at page 9, line 21
Additionally, sections 4.1, 4.1.1 and 4.1.2 of [RFC5936] provide Additionally, sections 4.1, 4.1.1 and 4.1.2 of [RFC5936] provide
improved guidance for AXFR clients and servers with regard to re-use improved guidance for AXFR clients and servers with regard to re-use
of TCP connections for multiple AXFRs and AXFRs of different zones. of TCP connections for multiple AXFRs and AXFRs of different zones.
However [RFC5936] was constrained by having to be backwards However [RFC5936] was constrained by having to be backwards
compatible with some very early basic implementations of AXFR. For compatible with some very early basic implementations of AXFR. For
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.
4.2. IXFR Mechanism 5.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 |
| <-------------------------------- | UPD | <-------------------------------- | UPD
| --------------------------------> | | --------------------------------> |
| NOTIFY Response | | NOTIFY Response |
skipping to change at page 11, line 18 skipping to change at page 11, line 18
IXFR-over-TCP. There may also be a fourth step where the secondary IXFR-over-TCP. There may also be a fourth step where the secondary
must fall back to AXFR because, e.g., the primary does not support must fall back to AXFR because, e.g., the primary does not support
IXFR. 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 [1] and NSD [2]) do nameserver implementations (including both BIND [1] and NSD [2]) do
IXFR using TCP by default in their latest releases. For BIND TCP IXFR 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.
4.3. Data Leakage of NOTIFY and SOA Message Exchanges 5.3. Data Leakage of NOTIFY and SOA Message Exchanges
This section attempts to presents a rationale for considering This section attempts to presents a rationale for considering
encrypting the other messages in the XFR mechanism. encrypting the 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 RR is not discussed in the following sections.
4.3.1. NOTIFY 5.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 supported QTYPE for NOTIFY is SOA, this does not
pose a potential leak. pose a potential leak.
4.3.2. SOA 5.3.2. SOA
For hidden primaries or secondaries the SOA response leaks only the For hidden primaries or secondaries the SOA response leaks only the
degree of lag of any downstream secondary. degree of lag of any downstream secondary.
5. Updates to existing specifications 6. Updates to existing specifications
For convenience, the phrase 'XFR-over-TCP' is used in this document For convenience, the phrase 'XFR-over-TCP' is used in this document
to mean both IXFR-over-TCP and AXFR-over-TCP and therefore statements to mean both IXFR-over-TCP and AXFR-over-TCP and therefore statements
that use it update both [RFC1995] and [RFC5936], and implicitly also that use it update both [RFC1995] and [RFC5936], and implicitly also
apply to XoT. Differences in behavior specific to XoT are discussed apply to XoT. Differences in behavior specific to XoT are discussed
in Section 6. in Section 7.
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 (probably unintentional) there arguably is an implicit assumption (probably unintentional)
that a TCP connection is used for one and only one IXFR request. that a TCP connection is used for one and only one IXFR request.
Indeed, several open source implementations currently take this Indeed, several open source implementations currently take this
approach. And whilst [RFC5936] gives guidance on connection re-use approach. And whilst [RFC5936] gives guidance on connection re-use
for AXFR, it pre-dates more recent specifications describing for AXFR, it pre-dates more recent specifications describing
persistent TCP connections e.g. [RFC7626], [RFC7828] and AXFR persistent TCP connections e.g. [RFC7766], [RFC7828] and AXFR
implementations again often make less than optimal use of open implementations again often make less than optimal use of open
connections. 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 o result in more consistent XoT implementations with better
interoperability interoperability
skipping to change at page 12, line 47 skipping to change at page 12, line 47
applies specifically to XFR exchanges. It also discusses how IXFR applies specifically to XFR exchanges. It also discusses 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 to an 'unauthorized' returning REFUSED to a zone transfer request to 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 the correct TSIG key),
the extended DNS error code 18 (Prohibited) can also be sent. the extended DNS error code 18 (Prohibited) can also be sent.
5.1. Update to RFC1995 for IXFR-over-TCP 6.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.
5.2. Update to RFC5936 for AXFR-over-TCP 6.2. Update to RFC5936 for AXFR-over-TCP
For clarity - an AXFR-over-TCP server compliant with this For clarity - an AXFR-over-TCP server compliant with this
specification MUST be able to handle multiple concurrent AXoT specification MUST be able to handle multiple concurrent AXoT
sessions on a single TCP connection (for the same and different sessions on a single TCP connection (for the same and different
zones). The response streams for concurrent AXFRs MAY be zones). The response streams for concurrent AXFRs MAY be
intermingled and AXFR-over-TCP clients compliant with this intermingled and AXFR-over-TCP clients compliant with this
specification MUST be able to handle this. specification MUST be able to handle this.
5.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP 6.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP
5.3.1. Connection reuse 6.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 5.4). be minimized (also see Section 6.4).
Valid reasons for not re-using existing connections might include: Valid reasons for not re-using existing connections might include:
o reaching a configured limit for the number of outstanding queries o 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 o 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 o 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 o 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 5.3.4) closing the connection (see Section 6.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.
5.3.2. AXFRs and IXFRs on the same connection 6.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 state: does make the general state:
"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 o use the same TCP connection for both AXFR and IXFR requests to the
same primary same primary
o pipeline such request and MAY intermingle them o pipeline such request and MAY intermingle them
o send the response(s) for each request as soon as they are o 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
5.3.3. XFR limits 6.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. server resources.
[OPEN QUESTION] Testing has shown that BIND returns SERVFAIL if the [OPEN QUESTION] Testing has shown that BIND returns SERVFAIL if the
limit on concurrent transfers is reached since this is regarded as a limit on concurrent transfers is reached since this is regarded as a
soft limit and a retry can/should succeed. Should there be a soft limit and a retry can/should succeed. Should there be a
specific recommendation here about what is returned re: SERVFAIL vs specific recommendation here about what is returned re: SERVFAIL vs
REFUSED? REFUSED?
[OPEN QUESTION] Is there a desire to define an additional XFR [OPEN QUESTION] Is there a desire to define an additional XFR
specific EDE code so that a client can determine why a specific XFR specific EDE code so that a client can determine why a specific XFR
request was declined in this case e.g., Max concurrent XFR: too may request was declined in this case e.g., Max concurrent XFR: too may
concurrent transfers in progress. It could potentially contain a concurrent transfers in progress. It could potentially contain a
retry delay, or at least clients can apply a reasonable back-off for retry delay, or at least clients can apply a reasonable back-off for
the retry. This could avoid retry storms which have been observed to the retry. This could avoid retry storms which have been observed to
actually increase the load on primaries in certain scenarios. actually increase the load on primaries in certain scenarios.
5.3.4. The edns-tcp-keepalive EDNS0 Option 6.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).
skipping to change at page 15, line 15 skipping to change at page 15, line 15
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.
5.3.5. Backwards compatibility 6.3.5. Backwards compatibility
Certain legacy behaviors were noted in [RFC5936], with provisos that Certain legacy behaviors were noted in [RFC5936], with provisos that
implementations may want to offer options to fallback to legacy 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 not to 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 implementations should have no
need to do so. need to do so.
5.4. Update to RFC7766 6.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
skipping to change at page 16, line 27 skipping to change at page 16, line 32
o one TLS connection for zone transfers o one TLS connection for zone transfers
o one DoH connection for regular queries o one DoH connection for regular queries
o one DoH connection for zone transfers o one DoH connection for zone transfers
We provide specific details in the later sections of reasons where We provide specific details in the later sections of reasons where
more than one connection for a given transport might be required for more than one connection for a given transport might be required for
zone transfers from a particular client. zone transfers from a particular client.
6. XoT specification 7. XoT specification
6.1. TLS versions 7.1. TLS versions
For improved security all implementations of this specification MUST For improved security all implementations of this specification MUST
use only TLS 1.3 [RFC8446] or later. use only TLS 1.3 [RFC8446] or later.
6.2. Port selection 7.2. 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.
6.3. High level XoT descriptions 7.3. 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
skipping to change at page 18, line 35 skipping to change at page 18, line 35
| | | TLS | | | TLS
| | | session | | | session
| IXFR Request | | | IXFR Request | |
| --------------------------------> | | | --------------------------------> | |
| <-------------------------------- | | | <-------------------------------- | |
| IXFR Response | | | IXFR Response | |
| (Zone data) | --- | (Zone data) | ---
Figure 1. IXoT Mechanism Figure 1. IXoT Mechanism
6.4. XoT transfers 7.4. 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 o 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 o 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:
* an IP based ACL (which can be either per-message or per- * an IP based ACL (which can be either per-message or per-
connection) connection)
* Mutual TLS (mTLS) * Mutual TLS (mTLS)
The server MAY also require a valid TSIG/SIG(0) signature, but this The server MAY also require a valid TSIG/SIG(0) signature, but this
alone is not sufficient to authenticate the client or server. alone is not sufficient to authenticate the client or server.
Authentication mechanisms are discussed in full in Section 8 and the Authentication mechanisms are discussed in full in Section 9 and the
rationale for the above requirement in Section 9. Transfer group rationale for the above requirement in Section 10. Transfer group
policies are discussed in Section 10. policies are discussed in Section 11.
6.5. XoT connections 7.5. XoT connections
The details in Section 5 about e.g., persistent connections and XFR The details in Section 6 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.
6.6. XoT vs ADoT 7.6. 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,S.S. with regard to TLS This raises questions in the short term,S.S. with regard to TLS
connection and message handling for authoritative servers. In connection and message handling for authoritative servers. In
skipping to change at page 19, line 52 skipping to change at page 19, line 52
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 o 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 6.7) Section 7.7)
o the operational and policy options that a XoT server operator has o 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)
6.7. Response RCODES 7.7. 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 the extended DNS error code 21 -
Not Supported [RFC8914]. XoT clients should not send any further Not Supported [RFC8914]. XoT clients should not send any further
queries of this type to the server for a reasonable period of time queries of this type to the server for a reasonable period of time
(for example, one hour) i.e., long enough that the server (for example, one hour) i.e., long enough that the server
configuration or policy might be updated. configuration or policy might be updated.
[OPEN QUESTION] Should this instead be Prohibited (by policy), or [OPEN QUESTION] Should this instead be Prohibited (by policy), or
should a new EDE be created for this case? should a new EDE be created for this case?
Historically servers have used the REFUSED RCODE for many situations, Historically servers have used the REFUSED RCODE for many situations,
and so clients often had no detailed information on which to base an and so clients often had no detailed information on which to base an
error or fallback path when queries were refused. As a result the error or fallback path when queries were refused. As a result the
client behavior could vary significantly. XoT severs that refuse client behavior could vary significantly. XoT servers that refuse
queries must cater for the fact that client behavior might vary from queries must cater for the fact that client behavior might vary from
continually retrying queries regardless of receiving REFUSED to every continually retrying queries regardless of receiving REFUSED to every
query, or at the other extreme clients may decide to stop using the query, or at the other extreme clients may decide to stop using the
server over any transport. This might be because those clients are server over any transport. This might be because those clients are
either non-XoT clients or do not implement EDE codes. either non-XoT clients or do not implement EDE codes.
6.8. AXoT specifics 7.8. AXoT specifics
6.8.1. Padding AXoT responses 7.8.1. Padding AXoT responses
The goal of padding AXoT responses would be two fold: The goal of padding AXoT responses would be two fold:
o to obfuscate the actual size of the transferred zone to minimize o 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 o 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.
skipping to change at page 21, line 35 skipping to change at page 21, line 35
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.
6.9. IXoT specifics 7.9. IXoT specifics
6.9.1. Condensation of responses 7.9.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.
6.9.2. Fallback to AXFR 7.9.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.
6.9.3. Padding of IXoT responses 7.9.3. Padding of IXoT responses
The goal of padding IXoT responses would be to obfuscate the The goal of padding IXoT responses would be to obfuscate the
incremental changes to the zone between SOA updates to minimize incremental changes to the zone between SOA updates to minimize
information leakage about zone update activity and growth. Both the information leakage about zone update activity and growth. Both the
size and timing of the IXoT responses could reveal information. size and 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 in size greatly 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 policies and the trade-offs involved are expected to be the subject
of future work. of future work.
6.10. Name compression and maximum payload sizes 7.10. 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 (e.g. supported for some responses with more sophisticated approaches (e.g.
by pre-calculating the maximum offset required). 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.
7. Multi-primary Configurations 8. Multi-primary Configurations
Also known as multi-master configurations this model can provide Also known as multi-master configurations this model can provide
flexibility and redundancy particularly for IXFR. A secondary will flexibility and redundancy particularly for IXFR. A secondary will
receive one or more NOTIFY messages and can send an SOA to all of the receive one or more NOTIFY messages and can send an SOA to all of the
configured primaries. It can then choose to send an XFR request to configured primaries. It can then choose to send an XFR request to
the primary with the highest SOA (or other criteria, e.g., RTT). the primary with the highest SOA (or 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
skipping to change at page 23, line 33 skipping to change at page 23, line 33
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.
8. Authentication mechanisms 9. Authentication mechanisms
To provide context to the requirements in section Section 6.4, this To provide context to the requirements in section Section 7.4, this
section provides a brief summary of some of the existing section provides a brief summary of some of the existing
authentication and validation mechanisms (both transport independent authentication and validation mechanisms (both transport independent
and TLS specific) that are available when performing zone transfers. and TLS specific) that are available when performing zone transfers.
Section 9 then discusses in more details specifically how a Section 10 then discusses in more details specifically how a
combination of TLS authentication, TSIG and IP based ACLs interact combination of TLS 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 o '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 o '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 o '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).
8.1. TSIG 9.1. TSIG
TSIG [RFC2845] provides a mechanism for two or more parties to use TSIG [RFC2845] 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
8.2. SIG(0) 9.2. SIG(0)
SIG(0) [RFC2535] similarly also provides a mechanism to digitally SIG(0) [RFC2931] similarly also provides a mechanism to digitally
sign a DNS message but uses public key authentication, where the sign a DNS message but uses public key authentication, where the
public keys are stored in DNS as KEY RRs and a private key is stored public keys are stored in DNS as KEY RRs and a private key is stored
at the signer. at the signer.
Properties: Data origin authentication Properties: Data origin authentication
8.3. TLS 9.3. TLS
8.3.1. Opportunistic TLS 9.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 o 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 o however they MAY fallback to using TLS without authentication and
o they MAY fallback to using cleartext is TLS is not available. o they MAY fallback to using cleartext if TLS is not available.
As such it does not offer a defense against active attacks (e.g. a As such it does not offer a defense against active attacks (e.g. a
MitM attack on the connection from client to server), and is not MitM attack on the connection from client to server), and is not
considered as useful for XoT. considered as useful for XoT.
Properties: None guaranteed. Properties: None guaranteed.
8.3.2. Strict TLS 9.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 authentication (of the
server). server).
8.3.3. Mutual TLS 9.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 authentic the for authentication by the server and the client can authentic 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 authentication.
8.4. IP Based ACL on the Primary 9.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.
8.5. ZONEMD 9.5. ZONEMD
For completeness, we also describe Message Digest for DNS Zones For completeness, we also describe Message Digest for DNS Zones
(ZONEMD) [I-D.ietf-dnsop-dns-zone-digest] here. The message digest (ZONEMD) [I-D.ietf-dnsop-dns-zone-digest] here. The message digest
is a mechanism that can be used to verify the content of a standalone is a mechanism that can be used to verify the content of a standalone
zone. It is designed to be independent of the transmission channel zone. It is designed to be independent of the transmission channel
or mechanism, allowing a general consumer of a zone to do origin or mechanism, allowing a general consumer of a zone to do origin
authentication of the entire zone contents. Note that the current authentication of the entire zone contents. Note that the current
version of [I-D.ietf-dnsop-dns-zone-digest] states: version of [I-D.ietf-dnsop-dns-zone-digest] 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.
9. XoT authentication 10. 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 6.4 addresses The XoT authentication requirement specified in Section 7.4 addresses
the issue of ensuring that the transfers is encrypted between the two the issue of ensuring that the transfers is encrypted between the two
endpoints directly involved in the current transfers. The following endpoints directly involved in the current transfers. The following
table summarized the properties of a selection of the mechanisms table summarized the properties of a selection of the mechanisms
discussed in Section 8. The two letter acronyms for the properties discussed in Section 9. The two letter acronyms for the properties
are used below and (S) indicates the secondary and (P) indicates the are used below and (S) indicates the secondary and (P) indicates the
primary. 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 | | |
skipping to change at page 27, line 17 skipping to change at page 27, line 17
o Using Strict TLS and an IP based ACL on the primary also provides o Using Strict TLS and an IP based ACL on the primary also provides
authentication of both end points authentication of both end points
o Additional use of TSIG (or equally SIG(0)) can also provide data o Additional use of TSIG (or equally SIG(0)) can also provide data
origin authentication which might be desirable for deployments origin authentication which might be desirable for deployments
that include a proxy between the secondary and primary, but is not that include a proxy between the secondary and primary, but is not
part of the XoT requirement because it does nothing to guarantee part of the XoT requirement because it does nothing to guarantee
channel confidentiality or authentication. channel confidentiality or authentication.
10. Policies for Both AXoT and IXoT 11. 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'.
skipping to change at page 27, line 40 skipping to change at page 27, line 40
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 requiring
confidentiality. If any do not, this is a weak link for attackers to confidentiality. If any do not, this is a weak link for attackers to
exploit. exploit.
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 11). transfers servers (see Section 12).
A XoT policy should specify A XoT policy should specify
o What kind of TLS is required (Strict or Mutual TLS) o What kind of TLS is required (Strict or Mutual TLS)
o or if an IP based ACL is required. o or if an IP based ACL is required.
o (optionally) if TSIG/SIG(0) is required 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
skipping to change at page 28, line 16 skipping to change at page 28, line 16
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.
The mechanics of co-ordinating or enforcing such policies are out of The mechanics of co-ordinating or enforcing such policies are out of
the scope of this document but may be the subject of future the scope of this document but may be the subject of future
operational guidance. operational guidance.
11. Implementation Considerations 12. Implementation Considerations
Server implementations may want to also offer options that allow ACLs Server implementations may want to also offer options that allow ACLs
on a zone to specify that a specific client can use either XoT or on a zone to specify that a specific client can use either XoT or
TCP. This would allow for flexibility while clients are migrating to TCP. This would allow for flexibility while clients are migrating to
XoT. XoT.
Client implementations may similarly want to offer options to cater Client implementations may similarly want to offer options to cater
for the multi-primary case where the primaries are migrating to XoT. for the multi-primary case where the primaries are migrating to XoT.
Such configuration options MUST only be used in a 'migration mode' Such configuration options MUST only be used in a 'migration mode'
though and therefore should be used with care. though and therefore should be used with care.
12. Implementation Status 13. Implementation Status
The 1.9.2 version of Unbound [3] includes an option to perform AXoT The 1.9.2 version of Unbound [3] includes an option to perform AXoT
(instead of AXFR-over-TCP). This requires the client (secondary) to (instead of AXFR-over-TCP). This requires the client (secondary) to
authenticate the server (primary) using a configured authentication authenticate the server (primary) using a configured authentication
domain name. domain name.
It is noted that use of a TLS proxy in front of the primary server is It is noted that use of a TLS proxy in front of the primary server is
a simple deployment solution that can enable server side XoT. a simple deployment solution that can enable server side XoT.
13. IANA Considerations 14. IANA Considerations
14. Security Considerations 15. 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 o 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 o 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 o 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].
15. Acknowledgements 16. Acknowledgements
The authors thank Tony Finch, Peter van Dijk, Benno Overeinder, The authors thank Tony Finch, Peter van Dijk, Benno Overeinder,
Shumon Huque and Tim Wicinski for review and discussions. Shumon Huque and Tim Wicinski for review and discussions.
16. Contributors 17. Contributors
Significant contributions to the document were made by: Significant contributions to the document were made by:
Han Zhang Han Zhang
Salesforce Salesforce
San Francisco, CA San Francisco, CA
United States United States
Email: hzhang@salesforce.com Email: hzhang@salesforce.com
17. Changelog 18. Changelog
draft-ietf-dprive-xfr-over-tls-04
o Add Github repository
o Fix typos and improve layout.
draft-ietf-dprive-xfr-over-tls-03 draft-ietf-dprive-xfr-over-tls-03
o Remove propose to use ALPN o Remove propose to use ALPN
o Clarify updates to both RFC1995 and RFC5936 by adding specific o Clarify updates to both RFC1995 and RFC5936 by adding specific
sections on this sections on this
o Add a section on the threat model o Add a section on the threat model
skipping to change at page 30, line 45 skipping to change at page 31, line 5
o Substantial re-work of the document. o 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. o Editorial changes, updates to references.
draft-hzpa-dprive-xfr-over-tls-00 draft-hzpa-dprive-xfr-over-tls-00
o Initial commit o Initial commit
18. References 19. References
18.1. Normative References 19.1. Normative References
[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", draft-vcelak-nsec5-08 (work in progress),
December 2018. December 2018.
[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>.
skipping to change at page 32, line 42 skipping to change at page 32, line 46
[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, <https://www.rfc-
editor.org/info/rfc8914>. editor.org/info/rfc8914>.
18.2. Informative References 19.2. Informative References
[I-D.ietf-dnsop-dns-zone-digest] [I-D.ietf-dnsop-dns-zone-digest]
Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W.
Hardaker, "Message Digest for DNS Zones", draft-ietf- Hardaker, "Message Digest for DNS Zones", draft-ietf-
dnsop-dns-zone-digest-14 (work in progress), October 2020. dnsop-dns-zone-digest-14 (work in progress), October 2020.
[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", draft-ietf-
dprive-dnsoquic-01 (work in progress), October 2020. dprive-dnsoquic-01 (work in progress), October 2020.
[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", draft-ietf-dprive-
phase2-requirements-01 (work in progress), June 2020. phase2-requirements-02 (work in progress), November 2020.
[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. Wood, "TLS
Encrypted Client Hello", draft-ietf-tls-esni-08 (work in Encrypted Client Hello", draft-ietf-tls-esni-08 (work in
progress), October 2020. progress), October 2020.
[I-D.vandijk-dprive-ds-dot-signal-and-pin] [I-D.vandijk-dprive-ds-dot-signal-and-pin]
Dijk, P., Geuze, R., and E. Bretelle, "Signalling Dijk, P., Geuze, R., and E. Bretelle, "Signalling
Authoritative DoT support in DS records, with key Authoritative DoT support in DS records, with key
pinning", draft-vandijk-dprive-ds-dot-signal-and-pin-01 pinning", draft-vandijk-dprive-ds-dot-signal-and-pin-01
skipping to change at page 33, line 32 skipping to change at page 33, line 37
[nist-guide] [nist-guide]
Chandramouli, R. and S. Rose, "Secure Domain Name System Chandramouli, R. and S. Rose, "Secure Domain Name System
(DNS) Deployment Guide", 2013, (DNS) Deployment Guide", 2013,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-81-2.pdf>. NIST.SP.800-81-2.pdf>.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
DOI 10.17487/RFC1982, August 1996, <https://www.rfc- DOI 10.17487/RFC1982, August 1996, <https://www.rfc-
editor.org/info/rfc1982>. editor.org/info/rfc1982>.
[RFC2535] Eastlake 3rd, D., "Domain Name System Security [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999, ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
<https://www.rfc-editor.org/info/rfc2535>. 2000, <https://www.rfc-editor.org/info/rfc2931>.
[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, <https://www.rfc-
editor.org/info/rfc6891>. editor.org/info/rfc6891>.
[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>.
18.3. URIs 19.3. URIs
[1] https://www.isc.org/bind/ [1] https://www.isc.org/bind/
[2] https://www.nlnetlabs.nl/projects/nsd/about/ [2] https://www.nlnetlabs.nl/projects/nsd/about/
[3] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/ [3] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/
Changelog Changelog
Appendix A. XoT server connection handling Appendix A. XoT server connection handling
 End of changes. 79 change blocks. 
139 lines changed or deleted 155 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/