draft-ietf-dprive-xfr-over-tls-09.txt   draft-ietf-dprive-xfr-over-tls-10.txt 
dprive W. Toorop dprive W. Toorop
Internet-Draft NLnet Labs Internet-Draft NLnet Labs
Updates: 1995, 5936, 7766 (if approved) S. Dickinson Updates: 1995, 5936, 7766 (if approved) S. Dickinson
Intended status: Standards Track Sinodun IT Intended status: Standards Track Sinodun IT
Expires: October 8, 2021 S. Sahib Expires: October 22, 2021 S. Sahib
P. Aras P. Aras
A. Mankin A. Mankin
Salesforce Salesforce
April 6, 2021 April 20, 2021
DNS Zone Transfer-over-TLS DNS Zone Transfer-over-TLS
draft-ietf-dprive-xfr-over-tls-09 draft-ietf-dprive-xfr-over-tls-10
Abstract Abstract
DNS zone transfers are transmitted in clear text, which gives DNS zone transfers are transmitted in clear text, which gives
attackers the opportunity to collect the content of a zone by attackers the opportunity to collect the content of a zone by
eavesdropping on network connections. The DNS Transaction Signature eavesdropping on network connections. The DNS Transaction Signature
(TSIG) mechanism is specified to restrict direct zone transfer to (TSIG) mechanism is specified to restrict direct zone transfer to
authorized clients only, but it does not add confidentiality. This authorized clients only, but it does not add confidentiality. This
document specifies the use of TLS, rather than clear text, to prevent document specifies the use of TLS, rather than clear text, to prevent
zone content collection via passive monitoring of zone transfers: zone content collection via passive monitoring of zone transfers:
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 8, 2021. This Internet-Draft will expire on October 22, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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
skipping to change at page 3, line 29 skipping to change at page 3, line 29
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
16. Implementation Status . . . . . . . . . . . . . . . . . . . . 29 16. Implementation Status . . . . . . . . . . . . . . . . . . . . 29
17. Security Considerations . . . . . . . . . . . . . . . . . . . 30 17. Security Considerations . . . . . . . . . . . . . . . . . . . 30
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
20. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 31 20. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 31
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
21.1. Normative References . . . . . . . . . . . . . . . . . . 33 21.1. Normative References . . . . . . . . . . . . . . . . . . 33
21.2. Informative References . . . . . . . . . . . . . . . . . 35 21.2. Informative References . . . . . . . . . . . . . . . . . 35
21.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 21.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A. XoT server connection handling . . . . . . . . . . . 36 Appendix A. XoT server connection handling . . . . . . . . . . . 37
A.1. Only listen on TLS on a specific IP address . . . . . . . 37 A.1. Only listen on TLS on a specific IP address . . . . . . . 37
A.2. Client specific TLS acceptance . . . . . . . . . . . . . 37 A.2. Client specific TLS acceptance . . . . . . . . . . . . . 37
A.3. SNI based TLS acceptance . . . . . . . . . . . . . . . . 37 A.3. SNI based TLS acceptance . . . . . . . . . . . . . . . . 37
A.4. TLS specific response policies . . . . . . . . . . . . . 37 A.4. TLS specific response policies . . . . . . . . . . . . . 38
A.4.1. SNI based response policies . . . . . . . . . . . . . 38 A.4.1. SNI based response policies . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
DNS has a number of privacy vulnerabilities, as discussed in detail DNS has a number of privacy vulnerabilities, as discussed in detail
in [I-D.ietf-dprive-rfc7626-bis]. Stub client to recursive resolver in [I-D.ietf-dprive-rfc7626-bis]. Stub client to recursive resolver
query privacy has received the most attention to date, with standards query privacy has received the most attention to date, with standards
track documents for both DNS-over-TLS (DoT) [RFC7858] and DNS-over- track documents for both DNS-over-TLS (DoT) [RFC7858] and DNS-over-
HTTPS (DoH) [RFC8484], and a proposal for DNS-over-QUIC HTTPS (DoH) [RFC8484], and a proposal for DNS-over-QUIC
[I-D.ietf-dprive-dnsoquic]. There is ongoing work on DNS privacy [I-D.ietf-dprive-dnsoquic]. There is ongoing work on DNS privacy
skipping to change at page 5, line 27 skipping to change at page 5, line 27
It is noted that in all the common open source implementations such It is noted that in all the common open source implementations such
ACLs are applied on a per query basis. Since requests typically ACLs are applied on a per query basis. Since requests typically
occur on TCP connections authoritatives must cater for accepting any occur on TCP connections authoritatives must cater for accepting any
TCP connection and then handling the authentication of each XFR TCP connection and then handling the authentication of each XFR
request individually. 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 (1.3
transport to prevent zone collection from zone transfers. or later) as a transport to prevent zone collection from zone
transfers.
2. Document work via GitHub 2. Document work via GitHub
[THIS SECTION TO BE REMOVED BEFORE PUBLICATION] The Github repository [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] The Github repository
for this document is at <https://github.com/hanzhang0116/hzpa-dprive- for this document is at <https://github.com/hanzhang0116/hzpa-dprive-
xfr-over-tls>. Proposed text and editorial changes are very much xfr-over-tls>. Proposed text and editorial changes are very much
welcomed there, but any functional changes should always first be welcomed there, but any functional changes should always first be
discussed on the IETF DPRIVE WG (dns-privacy) mailing list. discussed on the IETF DPRIVE WG (dns-privacy) mailing list.
3. Terminology 3. Terminology
skipping to change at page 7, line 5 skipping to change at page 7, line 5
5. Design Considerations for XoT 5. Design Considerations for XoT
o Confidentiality. Clearly using an encrypted transport for zone o Confidentiality. Clearly using an encrypted transport for zone
transfers will defeat zone content leakage that can occur via transfers will defeat zone content leakage that can occur via
passive surveillance. passive surveillance.
o Authentication. Use of single or mutual TLS (mTLS) authentication o Authentication. Use of single or mutual TLS (mTLS) authentication
(in combination with ACLs) can complement and potentially be an (in combination with ACLs) can complement and potentially be an
alternative to TSIG. alternative to TSIG.
o Performance. Existing AXFR and IXFR mechanisms have the burden of o Performance.
backwards compatibility with older implementations based on the
original specifications in [RFC1034] and [RFC1035]. For example,
some older AXFR servers don't support using a TCP connection for
multiple AXFR sessions or XFRs of different zones because they
have not been updated to follow the guidance in [RFC5936]. Any
implementation of XoT would obviously be required to implement
optimized and interoperable transfers as described in [RFC5936],
e.g., transfer of multiple zones over one connection.
o Performance. Current usage of TCP for IXFR is sub-optimal in some * Existing AXFR and IXFR mechanisms have the burden of backwards
cases i.e. connections are frequently closed after a single IXFR. compatibility with older implementations based on the original
specifications in [RFC1034] and [RFC1035]. For example, some
older AXFR servers don't support using a TCP connection for
multiple AXFR sessions or XFRs of different zones because they
have not been updated to follow the guidance in [RFC5936]. Any
implementation of XoT would obviously be required to implement
optimized and interoperable transfers as described in
[RFC5936], e.g., transfer of multiple zones over one
connection.
* Current usage of TCP for IXFR is sub-optimal in some cases i.e.
connections are frequently closed after a single IXFR.
6. Connection and Data Flows in Existing XFR Mechanisms 6. Connection and Data Flows in Existing XFR Mechanisms
The original specification for zone transfers in [RFC1034] and The original specification for zone transfers in [RFC1034] and
[RFC1035] was based on a polling mechanism: a secondary performed a [RFC1035] was based on a polling mechanism: a secondary performed a
periodic SOA query (based on the refresh timer) to determine if an periodic 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.
skipping to change at page 23, line 49 skipping to change at page 23, line 49
Implementations may wish to offer options to disable name compression Implementations may wish to offer options to disable name compression
for XoT responses to enable larger payloads. This might be for XoT responses to enable larger payloads. This might be
particularly helpful when padding is used since minimizing the particularly helpful when padding is used since minimizing the
payload size is not necessarily a useful optimization in this case payload size is not necessarily a useful optimization in this case
and disabling name compression will reduce the resources required to and disabling name compression will reduce the resources required to
construct the payload. construct the payload.
9. Multi-primary Configurations 9. Multi-primary Configurations
Also known as multi-master configurations this model can provide This model can provide flexibility and redundancy particularly for
flexibility and redundancy particularly for IXFR. A secondary will IXFR. A secondary will receive one or more NOTIFY messages and can
receive one or more NOTIFY messages and can send an SOA to all of the send an SOA to all of the configured primaries. It can then choose
configured primaries. It can then choose to send an XFR request to to send an XFR request to the primary with the highest SOA (or other
the primary with the highest SOA (or other criteria, e.g., RTT). criteria, e.g., RTT).
When using persistent connections the secondary may have a XoT When using persistent connections the secondary may have a XoT
connection already open to one or more primaries. Should a secondary connection already open to one or more primaries. Should a secondary
preferentially request an XFR from a primary to which it already has preferentially request an XFR from a primary to which it already has
an open XoT connection or the one with the highest SOA (assuming it an open XoT connection or the one with the highest SOA (assuming it
doesn't have a connection open to it already)? doesn't have a connection open to it already)?
Two extremes can be envisaged here. The first one can be considered Two extremes can be envisaged here. The first one can be considered
a 'preferred primary connection' model. In this case the secondary a 'preferred primary connection' model. In this case the secondary
continues to use one persistent connection to a single primary until continues to use one persistent connection to a single primary until
skipping to change at page 31, line 18 skipping to change at page 31, line 18
Han Zhang Han Zhang
Salesforce Salesforce
San Francisco, CA San Francisco, CA
United States United States
Email: hzhang@salesforce.com Email: hzhang@salesforce.com
20. Changelog 20. Changelog
[THIS SECTION TO BE REMOVED BEFORE PUBLICATION]
draft-ietf-dprive-xfr-over-tls-10
o Address issued raised from IETF Last Call
draft-ietf-dprive-xfr-over-tls-09 draft-ietf-dprive-xfr-over-tls-09
o Address issued raised in the AD review o Address issued raised in the AD review
draft-ietf-dprive-xfr-over-tls-08 draft-ietf-dprive-xfr-over-tls-08
o RFC2845 -> (obsoleted by) RFC8945 o RFC2845 -> (obsoleted by) RFC8945
o I-D.ietf-dnsop-dns-zone-digest -> RFC8976 o I-D.ietf-dnsop-dns-zone-digest -> RFC8976
skipping to change at page 31, line 46 skipping to change at page 32, line 4
o Correct typos in acknowledgments o Correct typos in acknowledgments
draft-ietf-dprive-xfr-over-tls-06 draft-ietf-dprive-xfr-over-tls-06
o Update text relating to pipelining and connection reuse after WGLC o Update text relating to pipelining and connection reuse after WGLC
comments. comments.
o Add link to implementation status matrix o Add link to implementation status matrix
o Various typos o Various typos
draft-ietf-dprive-xfr-over-tls-05
o Remove the open questions that received no comments. o Remove the open questions that received no comments.
o Add more detail to the implementation section o Add more detail to the implementation section
draft-ietf-dprive-xfr-over-tls-04
o Add Github repository o Add Github repository
o Fix typos and references and improve layout. o Fix typos and references and improve layout.
draft-ietf-dprive-xfr-over-tls-03 draft-ietf-dprive-xfr-over-tls-03
o Remove propose to use ALPN o Remove propose to use ALPN
o Clarify updates to both RFC1995 and RFC5936 by adding specific o Clarify updates to both RFC1995 and RFC5936 by adding specific
sections on this sections on this
skipping to change at page 32, line 44 skipping to change at page 33, line 5
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)
o Update security considerations o Update security considerations
o Move multi-primary considerations to earlier as they are related o Move multi-primary considerations to earlier as they are related
to connection handling to connection handling
draft-ietf-dprive-xfr-over-tls-01
o Minor editorial updates o Minor editorial updates
o Add requirement for TLS 1.3. or later o Add requirement for TLS 1.3. or later
draft-ietf-dprive-xfr-over-tls-00
o Rename after adoption and reference update. o Rename after adoption and reference update.
o Add placeholder for SIG(0) discussion o Add placeholder for SIG(0) discussion
o Update section on ZONEMD o Update section on ZONEMD
draft-hzpa-dprive-xfr-over-tls-02 draft-hzpa-dprive-xfr-over-tls-02
o Substantial re-work of the document. o Substantial re-work of the document.
 End of changes. 15 change blocks. 
30 lines changed or deleted 41 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/