draft-ietf-dprive-xfr-over-tls-02.txt   draft-ietf-dprive-xfr-over-tls-03.txt 
dprive W. Toorop dprive W. Toorop
Internet-Draft NLnet Labs Internet-Draft NLnet Labs
Updates: 1995, 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: January 14, 2021 S. Sahib Expires: May 6, 2021 S. Sahib
P. Aras P. Aras
A. Mankin A. Mankin
Salesforce Salesforce
July 13, 2020 November 2, 2020
DNS Zone Transfer-over-TLS DNS Zone Transfer-over-TLS
draft-ietf-dprive-xfr-over-tls-02 draft-ietf-dprive-xfr-over-tls-03
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 contents collection via passive monitoring of zone transfers. zone content collection via passive monitoring of zone transfers:
XFR-over-TLS (XoT). Additionally, this specification updates
RFC1995, RFC5936 and RFC7766.
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 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 January 14, 2021. This Internet-Draft will expire on May 6, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Cases for XFR-over-TLS . . . . . . . . . . . . . . . . . 5 3. Use Cases for XFR-over-TLS . . . . . . . . . . . . . . . . . 5
4. Connection and Data Flows in Existing XFR Mechanisms . . . . 5 3.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 6
4.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 6 4. Connection and Data Flows in Existing XFR Mechanisms . . . . 7
4.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 7 4.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 7
4.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 8 4.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 11
4.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 11
5. Connections and Data Flows in XoT . . . . . . . . . . . . . . 8 4.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. TLS versions . . . . . . . . . . . . . . . . . . . . . . 8 5. Updates to existing specifications . . . . . . . . . . . . . 11
5.2. Connection usage . . . . . . . . . . . . . . . . . . . . 8 5.1. Update to RFC1995 for IXFR-over-TCP . . . . . . . . . . . 12
5.2.1. High level XoT descriptions . . . . . . . . . . . . . 9 5.2. Update to RFC5936 for AXFR-over-TCP . . . . . . . . . . . 13
5.2.2. Previous specifications . . . . . . . . . . . . . . . 9 5.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP . . . . . 13
5.3. Update to RFC7766 . . . . . . . . . . . . . . . . . . . . 10 5.3.1. Connection reuse . . . . . . . . . . . . . . . . . . 13
5.4. Connection Establishment . . . . . . . . . . . . . . . . 10 5.3.2. AXFRs and IXFRs on the same connection . . . . . . . 13
5.4.1. Draft Version Identification . . . . . . . . . . . . 11 5.3.3. XFR limits . . . . . . . . . . . . . . . . . . . . . 14
5.5. Port selection . . . . . . . . . . . . . . . . . . . . . 11 5.3.4. The edns-tcp-keepalive EDNS0 Option . . . . . . . . . 14
5.6. AXoT mechanism . . . . . . . . . . . . . . . . . . . . . 11 5.3.5. Backwards compatibility . . . . . . . . . . . . . . . 15
5.6.1. Coverage and relationship to RFC5936 . . . . . . . . 12 5.4. Update to RFC7766 . . . . . . . . . . . . . . . . . . . . 15
5.6.2. AXoT connection and message handling . . . . . . . . 12 6. XoT specification . . . . . . . . . . . . . . . . . . . . . . 16
5.6.3. Padding AXoT responses . . . . . . . . . . . . . . . 14 6.1. TLS versions . . . . . . . . . . . . . . . . . . . . . . 16
5.7. IXoT mechanism . . . . . . . . . . . . . . . . . . . . . 15 6.2. Port selection . . . . . . . . . . . . . . . . . . . . . 16
5.7.1. Coverage and relationship to RFC1995 . . . . . . . . 15 6.3. High level XoT descriptions . . . . . . . . . . . . . . . 16
5.7.2. IXoT connection and message handling . . . . . . . . 15 6.4. XoT transfers . . . . . . . . . . . . . . . . . . . . . . 18
5.7.3. Condensation of responses . . . . . . . . . . . . . . 16 6.5. XoT connections . . . . . . . . . . . . . . . . . . . . . 19
5.7.4. Fallback to AXFR . . . . . . . . . . . . . . . . . . 16 6.6. XoT vs ADoT . . . . . . . . . . . . . . . . . . . . . . . 19
5.7.5. Padding of IXoT responses . . . . . . . . . . . . . . 16 6.7. Response RCODES . . . . . . . . . . . . . . . . . . . . . 20
6. Multi-primary Configurations . . . . . . . . . . . . . . . . 16 6.8. AXoT specifics . . . . . . . . . . . . . . . . . . . . . 20
7. Zone Transfer with DoT - Authentication . . . . . . . . . . . 17 6.8.1. Padding AXoT responses . . . . . . . . . . . . . . . 20
7.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.9. IXoT specifics . . . . . . . . . . . . . . . . . . . . . 21
7.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.9.1. Condensation of responses . . . . . . . . . . . . . . 21
7.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.9.2. Fallback to AXFR . . . . . . . . . . . . . . . . . . 21
7.3.1. Opportunistic . . . . . . . . . . . . . . . . . . . . 18 6.9.3. Padding of IXoT responses . . . . . . . . . . . . . . 22
7.3.2. Strict . . . . . . . . . . . . . . . . . . . . . . . 18 6.10. Name compression and maximum payload sizes . . . . . . . 22
7.3.3. Mutual . . . . . . . . . . . . . . . . . . . . . . . 18 7. Multi-primary Configurations . . . . . . . . . . . . . . . . 22
7.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 18 8. Authentication mechanisms . . . . . . . . . . . . . . . . . . 23
7.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.6. Comparison of Authentication Methods . . . . . . . . . . 19 8.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Policies for Both AXFR and IXFR . . . . . . . . . . . . . . . 20 8.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9. Implementation Considerations . . . . . . . . . . . . . . . . 21 8.3.1. Opportunistic TLS . . . . . . . . . . . . . . . . . . 24
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 8.3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8.3.3. Mutual TLS . . . . . . . . . . . . . . . . . . . . . 25
11.1. Registration of XoT Identification String . . . . . . . 21 8.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 25
12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 26
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 9. XoT authentication . . . . . . . . . . . . . . . . . . . . . 26
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Policies for Both AXoT and IXoT . . . . . . . . . . . . . . . 27
15. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. Implementation Considerations . . . . . . . . . . . . . . . . 28
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 28
16.1. Normative References . . . . . . . . . . . . . . . . . . 23 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
16.2. Informative References . . . . . . . . . . . . . . . . . 24 14. Security Considerations . . . . . . . . . . . . . . . . . . . 28
16.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
17. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 29
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
18.1. Normative References . . . . . . . . . . . . . . . . . . 30
18.2. Informative References . . . . . . . . . . . . . . . . . 32
18.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. XoT server connection handling . . . . . . . . . . . 34
A.1. Only listen on TLS on a specific IP address . . . . . . . 34
A.2. Client specific TLS acceptance . . . . . . . . . . . . . 34
A.3. SNI based TLS acceptance . . . . . . . . . . . . . . . . 35
A.4. TLS specific response policies . . . . . . . . . . . . . 35
A.4.1. SNI based response policies . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
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 [RFC7626]. Stub client to recursive resolver query privacy has in [RFC7626]. Stub client to recursive resolver query privacy has
received the most attention to date, with standards track documents received the most attention to date, with standards track documents
for both DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) for both DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH)
[RFC8484], and a proposal for DNS-over-QUIC [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 authoritatives might
work, e.g., [I-D.vandijk-dprive-ds-dot-signal-and-pin]. However work, e.g., [I-D.vandijk-dprive-ds-dot-signal-and-pin]. However
there is currently no RFC that specifically defines authoritative there is currently no RFC that specifically defines recursive to
support for DNS-over-TLS. authoritative DNS-over-TLS (ADoT).
[RFC7626] established that stub client DNS query transactions are not [RFC7626] established that stub client DNS query transactions are not
public and needed protection, but on zone transfer [RFC1995] public and needed protection, but on zone transfer [RFC1995]
[RFC5936] it says only: [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
skipping to change at page 4, line 16 skipping to change at page 4, line 31
o Service-tenant-from-another-org.example.org o Service-tenant-from-another-org.example.org
There may also be regulatory, policy or other reasons why the zone There may also be regulatory, policy or other reasons why the zone
contents in full must be treated as private. contents in full must be treated as private.
Neither of the RFCs mentioned in [RFC7626] contemplates the risk that Neither of the RFCs mentioned in [RFC7626] contemplates the risk that
someone gets the data through eavesdropping on network connections, someone gets the data through eavesdropping on network connections,
only via enumeration or unauthorized transfer as described in the only via enumeration or unauthorized transfer as described in the
following paragraphs. following paragraphs.
[RFC5155] specifies NSEC3 to prevent zone enumeration, which is when Zone enumeration is trivially possible for DNSSEC zones which use
queries for the authenticated denial of existences records of DNSSEC NSEC; i.e. queries for the authenticated denial of existences
allow a client to walk through the entire zone. Note that the need records allow a client to walk through the entire zone contents.
for this protection also motivates NSEC5 [I-D.vcelak-nsec5]; zone [RFC5155] specifies NSEC3, a mechanism to provide measures against
walking is now possible with NSEC3 due to crypto-breaking advances, zone enumeration for DNSSEC signed zones (a goal was to make it as
and NSEC5 is a response to this problem. hard to enumerate an DNSSEC signed zone as an unsigned zone). Whilst
this is widely used, zone walking is now possible with NSEC3 due to
crypto-breaking advances. This has prompted further work on an
alternative mechanism for DNSSEC authenticated denial of existence -
NSEC5 [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 draft) is orthogonal to preventing zone enumeration,
though they aim to protect the same information. though they aim to protect the same information.
[RFC5936] specifies using TSIG [RFC2845] for authorization of the [RFC5936] specifies using TSIG [RFC2845] 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. Some operators use SSH tunneling or IPSec to encrypt the encryption. Some operators use SSH tunneling or IPSec to encrypt the
transfer data. transfer data.
Section 8 of the NIST guide on 'Secure Domain Name System (DNS)
Deployment' [nist-guide] discusses restricting access for zone
transfers using ACLs and TSIG in more detail. It is noted that in
all the common open source implementations such ACLs are applied on a
per query basis. Since requests typically occur on TCP connections
authoritatives must cater for accepting any TCP connection and then
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. 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
skipping to change at page 5, line 9 skipping to change at page 5, line 36
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
'secondary' for two servers engaged in zone transfers. 'secondary' for two servers engaged in zone transfers.
DNS terminology is as described in [RFC8499]. DNS terminology is as described in [RFC8499].
DoT: DNS-over-TLS as specified in [RFC7858] DoT: DNS-over-TLS as specified in [RFC7858]
XFR-over-TCP: Used to mean both IXFR-over-TCP [RFC1995] and AXFR-
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 3. 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 authentication (in o Authentication. Use of single or mutual TLS (mTLS) authentication
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
backwards compatibility with older implementations based on the backwards compatibility with older implementations based on the
original specifications in [RFC1034] and [RFC1035]. For example, original specifications in [RFC1034] and [RFC1035]. For example,
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
The threat model considered here is one where the current contents
and size of the zone are considered sensitive and should be protected
during transfer.
The threat model does not, however, consider the existence of a zone,
the act of zone transfer between two entities, nor the identities of
the nameservers hosting a zone (including both those acting as hidden
primaries/secondaries or directly serving the zone) as sensitive
information. The proposed mechanisms does not attempt to obscure
such information. The reasons for this include:
o much of this information can be obtained by various methods
including active scanning of the DNS
o an attacker who can monitor network traffic can relatively easily
infer relations between nameservers simply from traffic patterns,
even when some or all of the traffic is encrypted
It is noted that simply using XoT will indicate a desire by the zone
owner that the contents of the zone remain confidential and so could
be subject to blocking (e.g. via blocking of port 853) if an attacker
had such capabilities. However this threat is likely true of any
such mechanism that attempts to encrypt data passed between
nameservers e.g. IPsec.
4. Connection and Data Flows in Existing XFR Mechanisms 4. 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
skipping to change at page 6, line 27 skipping to change at page 8, line 5
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 4.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.
Figure 1. AXFR Mechanism [1] Secondary Primary
| NOTIFY |
| <-------------------------------- | UPD
| --------------------------------> |
| NOTIFY Response |
| |
| |
| SOA Request |
| --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP session)
| SOA Response |
| |
| |
| |
| AXFR Request | ---
| --------------------------------> | |
| <-------------------------------- | |
| AXFR Response 1 | |
| (Zone data) | |
| | |
| <-------------------------------- | | TCP
| AXFR Response 2 | | Session
| (Zone data) | |
| | |
| <-------------------------------- | |
| AXFR Response 3 | |
| (Zone data) | ---
| |
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 secondaries 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
an AXFR query message and the sequence of AXFR response messages
returned for it.
[RFC5936] specifies that AXFR must use TCP as the transport protocol [RFC5936] re-specified AXFR providing additional guidance beyond that
but details that there is no restriction in the protocol that a provided in [RFC1034] and [RFC1035] and importantly specified that
single TCP connection must be used only for a single AXFR exchange, AXFR must use TCP as the transport protocol.
or even solely for XFRs. For example, it outlines that the SOA query
can also happen on this connection. However, this can cause
interoperability problems with older implementations that support
only the trivial case of one AXFR per connection.
Further details of the limitations in existing AXFR implementations Additionally, sections 4.1, 4.1.1 and 4.1.2 of [RFC5936] provide
are outlined in [RFC5936]. improved guidance for AXFR clients and servers with regard to re-use
of TCP connections for multiple AXFRs and AXFRs of different zones.
However [RFC5936] was constrained by having to be backwards
compatible with some very early basic implementations of AXFR. For
example, it outlines that the SOA query can also happen on this
connection. However, this can cause interoperability problems with
older implementations that support only the trivial case of one AXFR
per connection.
4.2. IXFR Mechanism 4.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.
Figure 1. IXFR Mechanism [2] Secondary Primary
| NOTIFY |
| <-------------------------------- | UPD
| --------------------------------> |
| NOTIFY Response |
| |
| |
| SOA Request |
| --------------------------------> | UDP or TCP
| <-------------------------------- |
| SOA Response |
| |
| |
| |
| IXFR Request |
| --------------------------------> | UDP or TCP
| <-------------------------------- |
| IXFR Response |
| (Zone data) |
| |
| | ---
| IXFR Request | |
| --------------------------------> | | Retry over
| <-------------------------------- | | TCP if
| IXFR Response | | required
| (Zone data) | ---
Figure 1. 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 the primary sends an IXFR an IXFR request to the primary after the primary sends an IXFR
response. 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 is says in non-normative language: 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 forth 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 forth 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 at least two widely used open source However it is noted that most widely used open source authoritative
authoritative nameserver implementations (BIND [3] and NSD [4]) 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.
It is noted that the specification for IXFR was published well before
TCP was considered a first class transport for DNS. This document
therefore updates [RFC1995] to state that DNS implementations that
support IXFR-over-TCP MUST use [RFC7766] to optimize the use of TCP
connections and SHOULD use [RFC7858] to manage persistent
connections.
4.3. Data Leakage of NOTIFY and SOA Message Exchanges 4.3. Data Leakage of NOTIFY and SOA Message Exchanges
This section attempts to presents a rationale for also encrypting the This section attempts to presents a rationale for considering
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 4.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 4.3.2. SOA
For hidden primaries or secondaries the SOA response leaks the degree For hidden primaries or secondaries the SOA response leaks only the
of lag of any downstream secondary. degree of lag of any downstream secondary.
5. Connections and Data Flows in XoT 5. Updates to existing specifications
5.1. TLS versions 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
that use it update both [RFC1995] and [RFC5936], and implicitly also
apply to XoT. Differences in behavior specific to XoT are discussed
in Section 6.
For improved security all implementations of this specification MUST Both [RFC1995] and [RFC5936] were published sometime before TCP was
use only TLS 1.3 [RFC8446] or later. considered a first class transport for DNS. [RFC1995], in fact, says
nothing with respect to optimizing IXFRs over TCP or re-using already
open TCP connections to perform IXFRs or other queries. Therefore,
there arguably is an implicit assumption (probably unintentional)
that a TCP connection is used for one and only one IXFR request.
Indeed, several open source implementations currently take this
approach. And whilst [RFC5936] gives guidance on connection re-use
for AXFR, it pre-dates more recent specifications describing
persistent TCP connections e.g. [RFC7626], [RFC7828] and AXFR
implementations again often make less than optimal use of open
connections.
5.2. Connection usage Given this, new implementations of XoT will clearly benefit from
specific guidance on TCP/TLS connection usage for XFR because this
will:
It is useful to note that in these mechanisms it is the secondary o result in more consistent XoT implementations with better
that initiates the TLS connection to the primary for a XFR request, interoperability
so that in terms of connectivity the secondary is the TLS client and
the primary the TLS server.
The details in [RFC7766], [RFC7858] and [RFC8310] about, e.g., o remove any need for XoT implementations to support legacy behavior
persistent connection and message handling are fully applicable to that XFR-over-TCP implementations have historically often
XoT as well. However any behavior specified here takes precedence supported
for XoT.
5.2.1. High level XoT descriptions Therefore this document updates both the previous specifications for
XFR-over-TCP to clarify that implementations MUST use [RFC7766] (DNS
Transport over TCP - Implementation Requirements) to optimize the use
of TCP connections and SHOULD use [RFC7828] (The edns-tcp-keepalive
EDNS0 Option) to manage persistent connections.
The figure below provides an outline of the AXoT mechanism including The following sections include detailed clarifications on the updates
NOTIFYs. to XFR behavior implied in [RFC7766] and how the use of [RFC7828]
applies specifically to XFR exchanges. It also discusses how IXFR
and AXFR can reuse the same TCP connection.
Figure 3: AXoT mechanism [5] For completeness, we also mention here the recent specification of
extended DNS error (EDE) codes [RFC8914]. For zone transfers, when
returning REFUSED to a zone transfer request to an 'unauthorized'
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),
the extended DNS error code 18 (Prohibited) can also be sent.
The figure below provides an outline of the IXoT mechanism including 5.1. Update to RFC1995 for IXFR-over-TCP
NOTIFYs.
Figure 4: IXoT mechanism [6] For clarity - an IXFR-over-TCP server compliant with this
specification MUST be able to handle multiple concurrent IXoT
requests on a single TCP connection (for the same and different
zones) and SHOULD send the responses as soon as they are available,
which might be out-of-order compared to the requests.
5.2.2. Previous specifications 5.2. Update to RFC5936 for AXFR-over-TCP
We note that whilst [RFC5936] already recommends re-using open TCP For clarity - an AXFR-over-TCP server compliant with this
connections, it does state: specification MUST be able to handle multiple concurrent AXoT
sessions on a single TCP connection (for the same and different
zones). The response streams for concurrent AXFRs MAY be
intermingled and AXFR-over-TCP clients compliant with this
specification MUST be able to handle this.
5.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP
5.3.1. Connection reuse
As specified, XFR-over-TCP clients SHOULD re-use any existing open
TCP connection when starting any new XFR request to the same primary,
and for issuing SOA queries, instead of opening a new connection.
The number of TCP connections between a secondary and primary SHOULD
be minimized (also see Section 5.4).
Valid reasons for not re-using existing connections might include:
o reaching a configured limit for the number of outstanding queries
or XFR requests allowed on a single TCP connection
o the message ID pool has already been exhausted on an open
connection
o a large number of timeouts or slow responses have occurred on an
open connection
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
closing the connection (see Section 5.3.4)
If no TCP connections are currently open, XFR clients MAY send SOA
queries over UDP or a new TCP connection.
5.3.2. AXFRs and IXFRs on the same connection
Neither [RFC1995] nor [RFC5936] explicitly discuss the use of a
single TCP connection for both IXFR and AXFR requests. [RFC5936]
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."
when discussing AXFR-over-TCP. It defines an AXFR session as an AXFR We clarify here that implementations capable of both AXFR and IXFR
query message and the sequence of AXFR response messages returned for and compliant with this specification SHOULD
it. Note that this excludes any SOA queries issued as part of the
overall AXFR mechanism. This requirement needs to be re-evaluated
when considering applying the same model to XoT since
o There is no guarantee that a XoT server (which is very likely, but o use the same TCP connection for both AXFR and IXFR requests to the
not necessarily, a purely authoritative server) will also support same primary
DoT for regular queries. Requiring a purely authoritative server
to also respond to any query over a TLS connection would be
equivalent to defining a form of authoritative DoT. We consider
this to be out of scope for this document, which is focussed
purely on zone transfers.
o It would, however, be optimal for XoT to include the capability to o pipeline such request and MAY intermingle them
send SOA queries over an already open TLS connection.
Moreover, it is worth noting that [RFC7766] made general o send the response(s) for each request as soon as they are
implementation recommendations with regard to TCP/TLS connection available i.e. responses MAY be sent intermingled
handling:
5.3.3. XFR limits
The server MAY limit the number of concurrent IXFRs, AXFRs or total
XFR transfers in progress, or from a given secondary, to protect
server resources.
[OPEN QUESTION] Testing has shown that BIND returns SERVFAIL if the
limit on concurrent transfers is reached since this is regarded as a
soft limit and a retry can/should succeed. Should there be a
specific recommendation here about what is returned re: SERVFAIL vs
REFUSED?
[OPEN QUESTION] Is there a desire to define an additional 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
concurrent transfers in progress. It could potentially contain a
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
actually increase the load on primaries in certain scenarios.
5.3.4. The edns-tcp-keepalive EDNS0 Option
XFR clients that send the edns-tcp-keepalive EDNS0 option on every
XFR request provide the server with maximum opportunity to update the
edns-tcp-keepalive timeout. The XFR server may use the frequency of
recent XFRs to calculate an average update rate as input to the
decision of what edns-tcp-keepalive timeout to use. If the server
does not support edns-tcp-keepalive the client MAY keep the
connection open for a few seconds ([RFC7766] recommends that servers
use timeouts of at least a few seconds).
Whilst the specification for EDNS0 [RFC6891] does not specifically
mention AXFRs, it does say
"If an OPT record is present in a received request, compliant
responders MUST include an OPT record in their respective
responses."
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
the subsequent AXFR responses. Note that this requirement, combined
with the use of edns-tcp-keepalive, enables AXFR servers to signal
the desire to close a connection (when existing transactions have
competed) due to low resources by sending an edns-tcp-keepalive EDNS0
option with a timeout of 0 on any AXFR response. This does not
signal that the AXFR is aborted, just that the server wishes to close
the connection as soon as possible.
5.3.5. Backwards compatibility
Certain legacy behaviors were noted in [RFC5936], with provisos that
implementations may want to offer options to fallback to legacy
behavior when interoperating with servers known not to support
[RFC5936]. For purposes of interoperability, IXFR and AXFR
implementations may want to continue offering such configuration
options, as well as supporting some behaviors that were
underspecified prior to this work (e.g. performing IXFR and AXFRs on
separate connections). However, XoT implementations should have no
need to do so.
5.4. Update to RFC7766
[RFC7766] made general implementation recommendations with regard to
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.
5.3. Update to RFC7766
This specification for XoT updates the guidance in [RFC7766] to This specification for XoT updates the 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.
We provide specific details in the following sections of reasons As an illustration, it could be imagined that in future such an
where more than one connection might be required for zone transfers. interaction could hypothetically include one or all of the following:
5.4. Connection Establishment o one TCP connection for regular queries
This specification additionally limits the scope of XoT as defined o one TCP connection for zone transfers
here to be the use of dedicated TLS connections (XoT connections) to
exchange only traffic specific to enabling zone transfers. The set
of transactions supported on such connections is limited to:
o AXFR o one TLS connection for regular queries
o IXFR o one TLS connection for zone transfers
o SOA o one DoH connection for regular queries
and is collectively referred to hereafter as 'XoT traffic'. o one DoH connection for zone transfers
Such connections MUST use an ALPN token of 'xot' during the TLS We provide specific details in the later sections of reasons where
handshake (see Section 11). more than one connection for a given transport might be required for
zone transfers from a particular client.
In the absence of DNS specific capability signaling mechanisms this 6. XoT specification
greatly simplifies the implementation of XoT such that a XoT exchange
can occur between any primary and secondary regardless of the role of
each (e.g. purely authoritative, recursive resolver also
authoritatively hosting zones, stub) or of other DNS transport
capability each may have. It also clearly makes XoT support
orthogonal to any set of zone transfer authentication mechanisms
chosen by the two parties.
XoT clients MUST only send XoT traffic on XoT connections. If a XoT 6.1. TLS versions
server receives traffic other than XoT traffic on a XoT connection it
MUST respond with the extended DNS error code 21 - Not Supported
[I-D.ietf-dnsop-extended-error]. It SHOULD treat this as protocol
error and close the connection.
With the update to [RFC7766] guidance above, clients are free to open For improved security all implementations of this specification MUST
separate connections to the server to make any other queries they may use only TLS 1.3 [RFC8446] or later.
need over either TLS, TCP or UDP. A specification for connections
that support both XoT traffic and non-XoT traffic may be the subject
of a future work.
5.4.1. Draft Version Identification 6.2. Port selection
_RFC Editor's Note:_ Please remove this section prior to publication The connection for XoT SHOULD be established using port 853, as
of a final version of this document. specified in [RFC7858], unless there is mutual agreement between the
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
for different zones.
Only implementations of the final, published RFC can identify 6.3. High level XoT descriptions
themselves as "xot". Until such an RFC exists, implementations MUST
NOT identify themselves using this string.
Implementations of draft versions of the protocol MUST add the string It is useful to note that in XoT it is the secondary that initiates
"-" and the corresponding draft number to the identifier. For the TLS connection to the primary for a XFR request, so that in terms
example, draft-ietf-dprive-xfr-over-tls-02 is identified using the of connectivity the secondary is the TLS client and the primary the
string "xot-02". TLS server.
5.5. Port selection The figure below provides an outline of the AXoT mechanism including
NOTIFYs.
The connection for XoT SHOULD be established using port 853, as Secondary Primary
specified in [RFC7858], unless there is mutual agreement between the
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.
5.6. AXoT mechanism | NOTIFY |
5.6.1. Coverage and relationship to RFC5936 | <-------------------------------- | UPD
| --------------------------------> |
| NOTIFY Response |
| |
| |
| SOA Request |
| --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP/TLS session)
| SOA Response |
| |
| |
| |
| AXFR Request | ---
| --------------------------------> | |
| <-------------------------------- | |
| AXFR Response 1 | |
| (Zone data) | |
| | |
| <-------------------------------- | | TLS
| AXFR Response 2 | | Session
| (Zone data) | |
| | |
| <-------------------------------- | |
| AXFR Response 3 | |
| (Zone data) | ---
| |
[RFC5936] re-specified AXFR providing additional guidance beyond that Figure 3. AXoT Mechanism
provided in [RFC1034] and [RFC1035]. For example, 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 of connections for multiple
AXFRs and AXFRs of different zones. However [RFC5936] was
constrained by having to be backwards compatible with some very early
basic implementations of AXFR.
Here we specify some optimized behaviors for AXoT, based closely on The figure below provides an outline of the IXoT mechanism including
those in [RFC5936], but without the constraint of backwards NOTIFYs.
compatibility since it is expected that all implementations of AXoT
fully implement the behavior described here.
Where any behavior is not explicitly described here, the behavior Secondary Primary
specified in [RFC5936] MUST be followed. Any behavior specified here
takes precedence for AXoT implementations over that in [RFC5936].
5.6.2. AXoT connection and message handling | NOTIFY |
| <-------------------------------- | UPD
| --------------------------------> |
| NOTIFY Response |
| |
| |
| SOA Request |
| --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP/TLS session)
| SOA Response |
| |
| |
| |
| IXFR Request | ---
| --------------------------------> | |
| <-------------------------------- | |
| IXFR Response | |
| (Zone data) | |
| | | TLS
| | | session
| IXFR Request | |
| --------------------------------> | |
| <-------------------------------- | |
| IXFR Response | |
| (Zone data) | ---
The first paragraph of Section 4.1.1 of [RFC5936] says that clients Figure 1. IXoT Mechanism
SHOULD close the connection when there is no 'apparent need' to use
the connection for some time period.
For AXoT this requirement is updated: AXoT clients and servers SHOULD 6.4. XoT transfers
use EDNS0 Keepalive [RFC7828] to establish the connection timeouts to
be used. The client SHOULD send the EDNS0 Keepalive option on every
AXoT request sent so that the server has every opportunity to update
the Keepalive timeout. The AXoT server may use the frequency of
recent AXFRs to calculate an average update rate as input to the
decision of what EDNS0 Keepalive timeout to use. If the server does
not support EDNS0 Keepalive the client MAY keep the connection open
for a few seconds ([RFC7766] recommends that servers use timeouts of
at least a few seconds).
Whilst the specification for EDNS0 [RFC6891] does not specifically For a zone transfer between two end points to be considered protected
mention AXFRs, it does say with XoT all XFR requests and response for that zone MUST be sent
over TLS connections where at a minimum:
"If an OPT record is present in a received request, compliant o the client MUST authenticate the server by use of an
responders MUST include an OPT record in their respective authentication domain name using a Strict Privacy Profile as
responses." described in [RFC8310]
We clarify here that if an OPT record is present in a received AXoT o the server MUST validate the client is authorized to request or
request, compliant responders MUST include an OPT record in each of proxy a zone transfer by using one or both of the following:
the subsequent AXoT responses. Note that this requirement, combined
with the use of EDNS0 Keepalive, enables AXoT servers to signal the
desire to close a connection due to low resources by sending an EDNS0
Keepalive option with a timeout of 0 on any AXoT response (in the
absence of another way to signal the abort of a AXoT transfer).
An AXoT server MUST be able to handle multiple AXFR requests on a * an IP based ACL (which can be either per-message or per-
single XoT connection (for the same and different zones). connection)
[RFC5936] says: * Mutual TLS (mTLS)
"An AXFR client MAY use an already opened TCP connection to The server MAY also require a valid TSIG/SIG(0) signature, but this
start an AXFR session. Using an existing open connection is alone is not sufficient to authenticate the client or server.
RECOMMENDED over opening a new connection. (Non-AXFR session
traffic can also use an open connection.)"
For AXoT this requirement is updated: AXoT clients SHOULD re-use an Authentication mechanisms are discussed in full in Section 8 and the
existing open XoT connection when starting any new AXoT session to rationale for the above requirement in Section 9. Transfer group
the same primary, and for issuing SOA queries, instead of opening a policies are discussed in Section 10.
new connection. The number of XoT connections between a secondary
and primary SHOULD be minimized.
Valid reasons for not re-using existing connections might include: 6.5. XoT connections
o reaching a configured limit for the number of outstanding queries The details in Section 5 about e.g., persistent connections and XFR
allowed on a single XoT connection message handling are fully applicable to XoT connections as well.
However any behavior specified here takes precedence for XoT.
o the message ID pool has already been exhausted on an open If no TLS connections are currently open, XoT clients MAY send SOA
connection queries over UDP or TCP, or TLS.
o a large number of timeouts or slow responses have occurred on an 6.6. XoT vs ADoT
open connection
o an EDNS0 Keepalive option with a timeout of 0 has been received As noted earlier, there is currently no specification for encryption
from the server and the client is in the process of closing the of connections from recursive resolvers to authoritative servers.
connection Some authoritatives are experimenting with ADoT and opportunistic
encryption has also been raised as a possibility; it is therefore
highly likely that use of encryption by authoritative servers will
evolve in the coming years.
If no XoT connections are currently open, AXoT clients MAY send SOA This raises questions in the short term,S.S. with regard to TLS
queries over UDP, TCP or TLS. connection and message handling for authoritative servers. In
particular, there 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 wish to support DoT for regular queries from
recursive in that same time frame. These servers have to potentially
cope with probing and direct queries from recursives and from test
servers, and also potential attacks that might wish to make use of
TLS to overload the server.
[RFC5936] says: [RFC5936] clearly states that non-AXFR session traffic can use an
open TCP connection, however, this requirement needs to be re-
evaluated when considering applying the same model to XoT. Proposing
that a server should also start responding to all queries received
over TLS just because it has enabled XoT would be equivalent to
defining a form of authoritative DoT. This specification does not
propose that, but it also does not prohibit servers from answering
queries unrelated to XFR exchanges over TLS. Rather, this
specification simply outlines in later sections:
"Some old AXFR clients expect each response message to contain o how XoT implementations should utilize EDE codes in response to
only a single RR. To interoperate with such clients, the server queries on TLS connections they are not willing to answer (see
MAY restrict response messages to a single RR." Section 6.7)
This is opposed to the normal behavior of containing a sufficient o the operational and policy options that a XoT server operator has
number of RRs to reasonably amortize the per-message overhead. We with regard to managing TLS connections and messages (see
clarify here that AXoT clients MUST be able to handle responses that Appendix A)
include multiple RRs, up to the largest number that will fit within a
DNS message (taking the required content of the other sections into
account, as described here and in [RFC5936]). This removes any
burden on AXoT servers of having to accommodate a configuration
option or support for restricting responses to containing only a
single RR.
An AXoT client SHOULD pipeline AXFR requests for different zones on a 6.7. Response RCODES
single XoT connection. An AXoT server SHOULD respond to those
requests as soon as the response is available i.e. potentially out of
order.
5.6.3. Padding AXoT responses 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
connection it SHOULD respond with the extended DNS error code 21 -
Not Supported [RFC8914]. XoT clients should not send any further
queries of this type to the server for a reasonable period of time
(for example, one hour) i.e., long enough that the server
configuration or policy might be updated.
[OPEN QUESTION] Should this instead be Prohibited (by policy), or
should a new EDE be created for this case?
Historically servers have used the REFUSED RCODE for many situations,
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
client behavior could vary significantly. XoT severs that refuse
queries must cater for the fact that client behavior might vary from
continually retrying queries regardless of receiving REFUSED to every
query, or at the other extreme clients may decide to stop using the
server over any transport. This might be because those clients are
either non-XoT clients or do not implement EDE codes.
6.8. AXoT specifics
6.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.
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 complicates any attempt to analyze the traffic size
and timing to extract information. and timing to extract information.
We note here that any requirement to obfuscate the total zone size is It is noted here that, depending on the padding policies eventually
likely to require a server to create 'empty' AXoT responses. That developed for XoT, the requirement to obfuscate the total zone size
is, AXoT responses that contain no RR's apart from an OPT RR might require a server to create 'empty' AXoT responses. That is,
containing the EDNS(0) option for padding. However, as with existing AXoT responses that contain no RR's apart from an OPT RR containing
AXFR, the last AXoT response message sent MUST contain the same SOA the EDNS(0) option for padding. For example, without this capability
that was in the first message of the AXoT response series in order to the maximum size that a tiny zone could be padded to would
signal the conclusion of the zone transfer. theoretically be limited if there had to be a minimum of 1 RR per
packet.
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
response series in order to signal the conclusion of the zone
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. In order to requirement will be exceptions to the above statement. For
guarantee support for future padding policies, we state here that flexibility, future proofing and in order to guarantee support for
secondary implementations MUST be resilient to receiving padded AXoT future padding policies, we state here that secondary implementations
responses, including 'empty' AXoT responses that contain only an OPT MUST be resilient to receiving padded AXoT responses, including
RR containing the EDNS(0) option for padding. 'empty' AXoT responses that contain only an OPT RR containing the
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.
5.7. IXoT mechanism 6.9. IXoT specifics
5.7.1. Coverage and relationship to RFC1995
[RFC1995] says nothing with respect to optimizing IXFRs over TCP or
re-using already open TCP connections to perform IXFRs or other
queries. Therefore, there arguably is an implicit assumption
(probably unintentional) that a TCP connection is used for one and
only one IXFR request. Indeed, several open source implementations
currently take this approach.
We provide new guidance here specific to IXoT that aligns with the
guidance in [RFC5936] for AXFR, that in section Section 5.6 for AXoT,
and with that for performant TCP/TLS usage in [RFC7766] and
[RFC7858].
Where any behavior is not explicitly described here, the behavior
specified in [RFC1995] MUST be followed. Any behavior specified here
takes precedence for IXoT implementations over that in [RFC1995].
5.7.2. IXoT connection and message handling
In a manner entirely analogous to that described in paragraph 2 of
Section 5.6.2 IXoT clients and servers SHOULD use EDNS0 Keepalive
[RFC7828] to establish the connection timeouts to be used.
An IXoT server MUST be able to handle multiple IXoT requests on a
single XoT connection (for the same and different zones).
IXoT clients SHOULD re-use an existing open XoT connection when
making any new IXoT request to the same primary, and for issuing SOA
queries, instead of opening a new connection. The number of XoT
connections between a secondary and primary SHOULD be minimized.
Valid reasons for not re-using existing connections are the same as
those described in Section 5.6.2
If no XoT connections are currently open, IXoT clients MAY send SOA
queries over UDP, TCP or TLS.
An IXoT client SHOULD pipeline IXFR requests for different zones on a
single XoT connection. An IXoT server SHOULD respond to those
requests as soon as the response is available i.e. potentially out of
order.
5.7.3. Condensation of responses 6.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.
5.7.4. Fallback to AXFR 6.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.
After a failed IXFR a IXoT client SHOULD request the AXFR on the Just as with IXFR-over-TCP, after a failed IXFR a IXoT client SHOULD
already open XoT connection. request the AXFR on the already open XoT connection.
5.7.5. Padding of IXoT responses 6.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. Multi-primary Configurations 6.10. Name compression and maximum payload sizes
It is noted here that name compression [RFC1035] can be used in XFR
responses to reduce the size of the payload, however the maximum
value of the offset that can be used in the name compression pointer
structure is 16384. For some DNS implementations this limits the
size of an individual XFR response used in practice to something
around the order of 16kB. In principle, larger payload sizes can be
supported for some responses with more sophisticated approaches (e.g.
by pre-calculating the maximum offset required).
Implementations may wish to offer options to disable name compression
for XoT responses to enable larger payloads. This might be
particularly helpful when padding is used since minimizing the
payload size is not necessarily a useful optimization in this case
and disabling name compression will reduce the resources required to
construct the payload.
7. 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 17, 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.
7. Zone Transfer with DoT - Authentication 8. Authentication mechanisms
7.1. TSIG To provide context to the requirements in section Section 6.4, this
section provides a brief summary of some of the existing
authentication and validation mechanisms (both transport independent
and TLS specific) that are available when performing zone transfers.
Section 9 then discusses in more details specifically how a
combination of TLS authentication, TSIG and IP based ACLs interact
for XoT.
We classify the mechanisms based on the following properties:
o 'Data Origin Authentication' (DO): Authentication that the DNS
message originated from the party with whom credentials were
shared, and of the data integrity of the message contents (the
originating party may or may not be party operating the far end of
a TCP/TLS connection in a 'proxy' scenario).
o 'Channel Confidentiality' (CC): Confidentiality of the
communication channel between the client and server (i.e. the two
end points of a TCP/TLS connection) from passive surveillance.
o 'Channel Authentication' (CA): Authentication of the identity of
party to whom a TCP/TLS connection is made (this might not be a
direct connection between the primary and secondary in a proxy
scenario).
8.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. It provides party-to-party data channel or via a proxy.
authentication, but not hop-to-hop channel authentication or
confidentiality.
7.2. SIG(0) Properties: Data origin authentication
8.2. SIG(0)
SIG(0) [RFC2535] similarly also provides a mechanism to digitally SIG(0) [RFC2535] 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. It also provides party-to-party data authentication, at the signer.
but not hop-to-hop channel authentication or confidentiality.
7.3. TLS Properties: Data origin authentication
7.3.1. Opportunistic 8.3. TLS
Opportunistic TLS [RFC8310] provides a defense against passive 8.3.1. Opportunistic TLS
surveillance, providing on-the-wire confidentiality.
7.3.2. Strict Opportunistic TLS for DoT is defined in [RFC8310] and can provide a
defense against passive surveillance, providing on-the-wire
confidentiality. Essentially
Strict TLS [RFC8310] requires that a client is configured with an o clients that know authentication information for a server SHOULD
authentication domain name (and/or SPKI pinset) that should be used try to authenticate the server
to authenticate the TLS handshake with the server. This additionally
provides a defense for the client against active surveillance,
providing client-to-server authentication and end-to-end channel
confidentiality.
7.3.3. Mutual o however they MAY fallback to using TLS without authentication and
o they MAY fallback to using cleartext is TLS is not available.
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
considered as useful for XoT.
Properties: None guaranteed.
8.3.2. Strict TLS
Strict TLS for DoT [RFC8310] requires that a client is configured
with an authentication domain name (and/or SPKI pinset) that MUST be
used to authenticate the TLS handshake with the server. If
authentication of the server fails, the client will not proceed with
the connection. This provides a defense for the client against
active surveillance, providing client-to-server authentication and
end-to-end channel confidentiality.
Properties: Channel confidentiality and authentication (of the
server).
8.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.
7.4. IP Based ACL on the Primary Properties: Channel confidentiality and mutual authentication.
8.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. servers on a per query basis.
This is also possible with XoT but it must be noted that as with TCP
the implementation of such an ACL cannot be enforced on the primary
until a XFR request is received on an established connection.
If control were to be any more fine-grained than this then a
separate, dedicated port would need to be agreed between primary and
secondary for XoT such that implementations would be able to refuse
connections on that port to all clients except those configured as
secondaries.
7.5. ZONEMD
Message Digest for DNS Zones (ZONEMD) This is also possible with XoT but it must be noted that, as with
[I-D.ietf-dnsop-dns-zone-digest] digest is a mechanism that can be TCP, the implementation of such an ACL cannot be enforced on the
used to verify the content of a standalone zone. It is designed to primary until an XFR request is received on an established
be independent of the transmission channel or mechanism, allowing a connection.
general consumer of a zone to do origin authentication of the entire
zone contents. Note that the current version of
[I-D.ietf-dnsop-dns-zone-digest] states:
"As specified at this time, ZONEMD is not designed for use in large, As discussed in Appendix A an IP based per connection ACL could also
dynamic zones due to the time and resources required for digest be implemented where only TLS connections from recognized secondaries
calculation. The ZONEMD record described in this document includes are accepted.
fields reserved for future work to support large, dynamic zones."
It is complementary the above mechanisms and can be used in Properties: Channel authentication of the client.
conjunction with XoT but is not considered further.
7.6. Comparison of Authentication Methods 8.5. ZONEMD
The Table below compares the properties of a selection of the above For completeness, we also describe Message Digest for DNS Zones
methods in terms of what protection they provide to the secondary and (ZONEMD) [I-D.ietf-dnsop-dns-zone-digest] here. The message digest
primary servers during XoT in terms of: is a mechanism that can be used to verify the content of a standalone
zone. It is designed to be independent of the transmission channel
or mechanism, allowing a general consumer of a zone to do origin
authentication of the entire zone contents. Note that the current
version of [I-D.ietf-dnsop-dns-zone-digest] states:
o 'Data Auth': Authentication that the DNS message data is signed by "As specified herein, ZONEMD is impractical for large, dynamic zones
the party with whom credentials were shared (the signing party may due to the time and resources required for digest calculation.
or may not be party operating the far end of a TCP/TLS connection However, The ZONEMD record is extensible so that new digest schemes
in a 'proxy' scenario). For the primary the TSIG on the XFR may be added in the future to support large, dynamic zones."
request confirms that the requesting party is authorized to
request zone data, for the secondary it authenticates the zone
data that is received.
o 'Channel Conf': Confidentiality of the communication channel It is complementary but orthogonal the above mechanisms; and can be
between the client and server (i.e. the two end points of a TCP/ used in conjunction with XoT but is not considered further here.
TLS connection).
o Channel Auth: Authentication of the identity of party to whom a 9. XoT authentication
TCP/TLS connection is made (this might not be a direct connection
between the primary and secondary in a proxy scenario).
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
authentication methods are best suited to the deployment model in combination of authentication methods are best suited to the
question. deployment model in question.
Table 1: Properties of Authentication methods for XoT [7] The XoT authentication requirement specified in Section 6.4 addresses
the issue of ensuring that the transfers is encrypted between the two
endpoints directly involved in the current transfers. The following
table summarized the properties of a selection of the mechanisms
discussed in Section 8. The two letter acronyms for the properties
are used below and (S) indicates the secondary and (P) indicates the
primary.
+----------------+-------+-------+-------+-------+-------+-------+
| Method | DO(S) | CC(S) | CA(S) | DO(P) | CC(P) | CA(P) |
+----------------+-------+-------+-------+-------+-------+-------+
| Strict TLS | | Y | Y | | Y | |
| Mutual TLS | | Y | Y | | Y | Y |
| ACL on primary | | | | | | Y |
| TSIG | Y | | | Y | | |
+----------------+-------+-------+-------+-------+-------+-------+
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 A combination of Opportunistic TLS and TSIG provides both data o Using just mutual TLS can be considered a standalone solution
authentication and channel confidentiality for both parties. since both end points are authenticated
However this does not stop a MitM attack on the channel which
could be used to gather zone data.
o Using just mutual TLS can be considered a standalone solution if o Using Strict TLS and an IP based ACL on the primary also provides
the secondary has reason to place equivalent trust in channel authentication of both end points
authentication as data authentication, e.g., the same operator
runs both the primary and secondary.
o Using TSIG, Strict TLS and an ACL on the primary provides all 3 o Additional use of TSIG (or equally SIG(0)) can also provide data
properties for both parties with probably the lowest operational origin authentication which might be desirable for deployments
overhead. that include a proxy between the secondary and primary, but is not
part of the XoT requirement because it does nothing to guarantee
channel confidentiality or authentication.
8. Policies for Both AXFR and IXFR 10. Policies for Both AXoT and IXoT
We call the entire group of servers involved in XFR (all the Whilst the protection of the zone contents in a transfer between two
primaries and all the secondaries) the 'transfer group'. end points can be provided by the XoT protocol, the protection of all
the transfers of a given zone requires operational administration and
policy management.
Within any transfer group both AXFRs and IXFRs for a zone SHOULD all We call the entire group of servers involved in XFR for a particular
use the same policy, e.g., if AXFRs use AXoT all IXFRs SHOULD use set of zones (all the primaries and all the secondaries) the
IXoT. '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 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 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
both the client and server are configured to use only XoT and the
overall zone transfer is not considered protected until all members
of the transfer group are configured to use only XoT with all other
transfers servers (see Section 11).
A XoT policy should specify A XoT policy should specify
o If TSIG or SIG(0) is required o What kind of TLS is required (Strict or Mutual TLS)
o What kind of TLS is required (Opportunistic, Strict or mTLS) o or if an IP based ACL is required.
o If IP based ACLs should also be 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.
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.
9. Implementation Considerations 11. Implementation Considerations
TBD Server implementations may want to also offer options that allow ACLs
on a zone to specify that a specific client can use either XoT or
TCP. This would allow for flexibility while clients are migrating to
XoT.
10. Implementation Status Client implementations may similarly want to offer options to cater
for the multi-primary case where the primaries are migrating to XoT.
The 1.9.2 version of Unbound [8] includes an option to perform AXoT Such configuration options MUST only be used in a 'migration mode'
though and therefore should be used with care.
12. Implementation Status
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.
11. IANA Considerations 13. IANA Considerations
11.1. Registration of XoT Identification String
This document creates a new registration for the identification of
XoT in the "Application Layer Protocol Negotiation (ALPN) Protocol
IDs" registry [RFC7301].
The "xot" string identifies XoT:
Protocol: XoT
Identification Sequence: 0x64 0x6F 0x72 ("xot")
Specification: This document
12. Security Considerations 14. 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].
13. Acknowledgements 15. Acknowledgements
The authors thank Benno Overeinder, Shumon Huque and Tim Wicinski for The authors thank Tony Finch, Peter van Dijk, Benno Overeinder,
review and discussions. Shumon Huque and Tim Wicinski for review and discussions.
14. Contributors 16. 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
15. Changelog 17. Changelog
draft-ietf-dprive-xfr-over-tls-02 draft-ietf-dprive-xfr-over-tls-03
o Remove propose to use ALPN
o Clarify updates to both RFC1995 and RFC5936 by adding specific
sections on this
o Add a section on the threat model
o Convert all SVG diagrams to ASCII art
o Add discussions on concurrency limits
o Add discussions on Extended DNS error codes
o Re-work authentication requirements and discussion
o Add appendix discussion TLS connection management
draft-ietf-dprive-xfr-over-tls-02
o Significantly update descriptions for both AXoT and IXoT for o 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. o Add use of APLN and limitations on traffic on XoT connections.
o Add new discussions of padding for both AXoT and IXoT o Add new discussions of padding for both AXoT and IXoT
o Add text on SIG(0) o Add text on SIG(0)
skipping to change at page 23, line 28 skipping to change at page 30, line 45
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
16. References 18. References
16.1. Normative References 18.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",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/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, <https://www.rfc-
editor.org/info/rfc1995>. editor.org/info/rfc1995>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/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, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<https://www.rfc-editor.org/info/rfc2845>. <https://www.rfc-editor.org/info/rfc2845>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<https://www.rfc-editor.org/info/rfc5155>.
[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, <https://www.rfc-
editor.org/info/rfc6973>. editor.org/info/rfc6973>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015, <https://www.rfc- DOI 10.17487/RFC7626, August 2015, <https://www.rfc-
editor.org/info/rfc7626>. editor.org/info/rfc7626>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<https://www.rfc-editor.org/info/rfc7766>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", RFC 7828,
DOI 10.17487/RFC7828, April 2016, <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, <https://www.rfc-
editor.org/info/rfc8310>. editor.org/info/rfc8310>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8484>. <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>.
16.2. Informative References [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020, <https://www.rfc-
editor.org/info/rfc8914>.
18.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-08 (work in progress), June 2020. dnsop-dns-zone-digest-14 (work in progress), October 2020.
[I-D.ietf-dnsop-extended-error]
Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", draft-ietf-dnsop-
extended-error-16 (work in progress), May 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-00 (work in progress), April 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-01 (work in progress), June 2020.
[I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS
Encrypted Client Hello", draft-ietf-tls-esni-08 (work in
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-00 pinning", draft-vandijk-dprive-ds-dot-signal-and-pin-01
(work in progress), May 2020. (work in progress), July 2020.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [nist-guide]
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, Chandramouli, R. and S. Rose, "Secure Domain Name System
November 1987, <https://www.rfc-editor.org/info/rfc1035>. (DNS) Deployment Guide", 2013,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
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>.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
August 1996, <https://www.rfc-editor.org/info/rfc1996>.
[RFC2535] Eastlake 3rd, D., "Domain Name System Security [RFC2535] Eastlake 3rd, D., "Domain Name System Security
Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999, Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999,
<https://www.rfc-editor.org/info/rfc2535>. <https://www.rfc-editor.org/info/rfc2535>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
<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>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
D. Wessels, "DNS Transport over TCP - Implementation (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, <https://www.rfc-editor.org/info/rfc8484>.
<https://www.rfc-editor.org/info/rfc7766>.
16.3. URIs 18.3. URIs
[1] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/ [1] https://www.isc.org/bind/
master/02-draft-dprive-svg/AXFR_mechanism.svg
[2] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/ [2] https://www.nlnetlabs.nl/projects/nsd/about/
master/02-draft-dprive-svg/IXFR_mechanism.svg
[3] https://www.isc.org/bind/ [3] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/
Changelog
[4] https://www.nlnetlabs.nl/projects/nsd/about/ Appendix A. XoT server connection handling
[5] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/ For completeness, it is noted that an earlier version of the
master/02-draft-dprive-svg/AXoT_mechanism.svg specification suggested using a XoT specific ALPN to negotiate TLS
connections that supported only a limited set of queries (SOA, XRFs)
however this did not gain support. Reasons given included additional
code complexity and proxies having no natural way to forward the ALPN
signal to DNS nameservers over TCP connections.
[6] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/blob/ A.1. Only listen on TLS on a specific IP address
master/02-draft-dprive-svg/IXoT_mechanism.svg
[7] https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/ Obviously a nameserver which hosts a zone and services queries for
blob/02_updates/02-draft-svg/ the zone on an IP address published in an NS record may wish to use a
Properties_of_Authentication_methods_for_XoT.svg separate IP address for listening on TLS for XoT, only publishing
that address to its secondaries.
[8] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/ Pros: Probing of the public IP address will show no support for TLS.
Changelog ACLs will prevent zone transfer on all transports on a per query
basis.
Cons: Attackers passively observing traffic will still be able to
observe TLS connections to the separate address.
A.2. Client specific TLS acceptance
Primaries that include IP based ACLs and/or mutual TLS in their
authentication models have the option of only accepting TLS
connections from authorized clients. This could be implemented using
a proxy or directly in DNS implementation.
Pros: Connection management happens at setup time. The maximum
number of TLS connections a server will have to support can be easily
assessed. Once the connection is accepted the server might well be
willing to answer any query on that connection since it is coming
from a configured secondary and a specific response policy on the
connection may not be needed (see below).
Cons: Currently, none of the major open source DNS authoritative
implementations support such an option.
A.3. SNI based TLS acceptance
Primaries could also choose to only accept TLS connections based on
an SNI that was published only to their secondaries.
Pros: Reduces the number of accepted connections.
Cons: As above. For SNIs sent in the clear, this would still allow
attackers passively observing traffic to potentially abuse this
mechanism. The use of Encrypted Client Hello [I-D.ietf-tls-esni] may
be of use here.
A.4. TLS specific response policies
Some primaries might rely on TSIG/SIG(0) combined with per-query IP
based ACLs to authenticate secondaries. In this case the primary
must accept all incoming TLS connections and then apply a TLS
specific response policy on a per query basis.
As an aside, whilst [RFC7766] makes a general purpose distinction to
clients in the usage of connections (between regular queries and zone
transfers) this is not strict and nothing in the DNS protocol
prevents using the same connection for both types of traffic. Hence
a server cannot know the intention of any client that connects to it,
it can only inspect the messages it receives on such a connection and
make per query decisions about whether or not to answer those
queries.
Example policies a XoT server might implement are:
o strict: REFUSE all queries on TLS connections except SOA and
authorized XFR requests
o moderate: REFUSE all queries on TLS connections until one is
received that is signed by a recognized TSIG/SIG(0) key, then
answer all queries on the connection after that
o complex: apply a heuristic to determine which queries on a TLS
connections to REFUSE
o relaxed: answer all non-XoT queries on all TLS connections with
the same policy applied to TCP queries
Pros: Allows for flexible behavior by the server that could be
changed over time.
Cons: The server must handle the burden of accepting all TLS
connections just to perform XFRs with a small number of secondaries.
Client behavior to REFUSED response is not clearly defined (see
below). Currently, none of the major open source DNS authoritative
implementations offer an option for different response policies in
different transports (but could potentially be implemented using a
proxy).
A.4.1. SNI based response policies
In a similar fashion, XoT servers might use the presence of an SNI in
the client hello to determine which response policy to initially
apply to the TLS connections.
Pros: This has to potential to allow a clean distinction between a
XoT service and any future DoT based service for answering recursive
queries.
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 1098 XH
The Netherlands The Netherlands
Email: willem@nlnetlabs.nl Email: willem@nlnetlabs.nl
 End of changes. 164 change blocks. 
493 lines changed or deleted 920 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/