draft-ietf-dprive-xfr-over-tls-04.txt   draft-ietf-dprive-xfr-over-tls-05.txt 
dprive W. Toorop dprive W. Toorop
Internet-Draft NLnet Labs Internet-Draft NLnet Labs
Updates: 1995, 5936, 7766 (if approved) S. Dickinson Updates: 1995, 5936, 7766 (if approved) S. Dickinson
Intended status: Standards Track Sinodun IT Intended status: Standards Track Sinodun IT
Expires: May 27, 2021 S. Sahib Expires: July 24, 2021 S. Sahib
P. Aras P. Aras
A. Mankin A. Mankin
Salesforce Salesforce
November 23, 2020 January 20, 2021
DNS Zone Transfer-over-TLS DNS Zone Transfer-over-TLS
draft-ietf-dprive-xfr-over-tls-04 draft-ietf-dprive-xfr-over-tls-05
Abstract Abstract
DNS zone transfers are transmitted in clear text, which gives DNS zone transfers are transmitted in clear text, which gives
attackers the opportunity to collect the content of a zone by attackers the opportunity to collect the content of a zone by
eavesdropping on network connections. The DNS Transaction Signature eavesdropping on network connections. The DNS Transaction Signature
(TSIG) mechanism is specified to restrict direct zone transfer to (TSIG) mechanism is specified to restrict direct zone transfer to
authorized clients only, but it does not add confidentiality. This authorized clients only, but it does not add confidentiality. This
document specifies use of TLS, rather then clear text, to prevent document specifies use of TLS, rather then clear text, to prevent
zone content collection via passive monitoring of zone transfers: zone content collection via passive monitoring of zone transfers:
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 27, 2021. This Internet-Draft will expire on July 24, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
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
skipping to change at page 3, line 19 skipping to change at page 3, line 19
9.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.3.1. Opportunistic TLS . . . . . . . . . . . . . . . . . . 24 9.3.1. Opportunistic TLS . . . . . . . . . . . . . . . . . . 24
9.3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . 25 9.3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . 25
9.3.3. Mutual TLS . . . . . . . . . . . . . . . . . . . . . 25 9.3.3. Mutual TLS . . . . . . . . . . . . . . . . . . . . . 25
9.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 25 9.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 25
9.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. XoT authentication . . . . . . . . . . . . . . . . . . . . . 26 10. XoT authentication . . . . . . . . . . . . . . . . . . . . . 26
11. Policies for Both AXoT and IXoT . . . . . . . . . . . . . . . 27 11. Policies for Both AXoT and IXoT . . . . . . . . . . . . . . . 27
12. Implementation Considerations . . . . . . . . . . . . . . . . 28 12. Implementation Considerations . . . . . . . . . . . . . . . . 28
13. Implementation Status . . . . . . . . . . . . . . . . . . . . 28 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 28
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
15. Security Considerations . . . . . . . . . . . . . . . . . . . 28 15. Security Considerations . . . . . . . . . . . . . . . . . . . 29
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
18. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 29 18. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 29
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
19.1. Normative References . . . . . . . . . . . . . . . . . . 31 19.1. Normative References . . . . . . . . . . . . . . . . . . 31
19.2. Informative References . . . . . . . . . . . . . . . . . 32 19.2. Informative References . . . . . . . . . . . . . . . . . 33
19.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 19.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. XoT server connection handling . . . . . . . . . . . 34 Appendix A. XoT server connection handling . . . . . . . . . . . 34
A.1. Only listen on TLS on a specific IP address . . . . . . . 34 A.1. Only listen on TLS on a specific IP address . . . . . . . 35
A.2. Client specific TLS acceptance . . . . . . . . . . . . . 34 A.2. Client specific TLS acceptance . . . . . . . . . . . . . 35
A.3. SNI based TLS acceptance . . . . . . . . . . . . . . . . 35 A.3. SNI based TLS acceptance . . . . . . . . . . . . . . . . 35
A.4. TLS specific response policies . . . . . . . . . . . . . 35 A.4. TLS specific response policies . . . . . . . . . . . . . 35
A.4.1. SNI based response policies . . . . . . . . . . . . . 36 A.4.1. SNI based response policies . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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
skipping to change at page 8, line 8 skipping to change at page 8, line 8
single XFR request/response exchange. single XFR request/response exchange.
5.1. AXFR Mechanism 5.1. AXFR Mechanism
The figure below provides an outline of an AXFR mechanism including The figure below provides an outline of an AXFR mechanism including
NOTIFYs. NOTIFYs.
Secondary Primary Secondary Primary
| NOTIFY | | NOTIFY |
| <-------------------------------- | UPD | <-------------------------------- | UDP
| --------------------------------> | | --------------------------------> |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------> | UDP (or part of | --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP session) | <-------------------------------- | a TCP session)
| SOA Response | | SOA Response |
| | | |
| | | |
skipping to change at page 10, line 8 skipping to change at page 10, line 8
per connection. per connection.
5.2. IXFR Mechanism 5.2. IXFR Mechanism
The figure below provides an outline of the IXFR mechanism including The figure below provides an outline of the IXFR mechanism including
NOTIFYs. NOTIFYs.
Secondary Primary Secondary Primary
| NOTIFY | | NOTIFY |
| <-------------------------------- | UPD | <-------------------------------- | UDP
| --------------------------------> | | --------------------------------> |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------> | UDP or TCP | --------------------------------> | UDP or TCP
| <-------------------------------- | | <-------------------------------- |
| SOA Response | | SOA Response |
| | | |
| | | |
skipping to change at page 14, line 20 skipping to change at page 14, line 20
o pipeline such request and MAY intermingle them o pipeline such request and MAY intermingle them
o send the response(s) for each request as soon as they are o send the response(s) for each request as soon as they are
available i.e. responses MAY be sent intermingled available i.e. responses MAY be sent intermingled
6.3.3. XFR limits 6.3.3. XFR limits
The server MAY limit the number of concurrent IXFRs, AXFRs or total The server MAY limit the number of concurrent IXFRs, AXFRs or total
XFR transfers in progress, or from a given secondary, to protect XFR transfers in progress, or from a given secondary, to protect
server resources. server resources. Servers SHOULD return SERVFAIL if this limit is
hit, since it is a transient error and a retry at a later time might
[OPEN QUESTION] Testing has shown that BIND returns SERVFAIL if the succeed.
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.
6.3.4. The edns-tcp-keepalive EDNS0 Option 6.3.4. The edns-tcp-keepalive EDNS0 Option
XFR clients that send the edns-tcp-keepalive EDNS0 option on every XFR clients that send the edns-tcp-keepalive EDNS0 option on every
XFR request provide the server with maximum opportunity to update the XFR request provide the server with maximum opportunity to update the
edns-tcp-keepalive timeout. The XFR server may use the frequency of edns-tcp-keepalive timeout. The XFR server may use the frequency of
recent XFRs to calculate an average update rate as input to the recent XFRs to calculate an average update rate as input to the
decision of what edns-tcp-keepalive timeout to use. If the server decision of what edns-tcp-keepalive timeout to use. If the server
does not support edns-tcp-keepalive the client MAY keep the does not support edns-tcp-keepalive the client MAY keep the
connection open for a few seconds ([RFC7766] recommends that servers connection open for a few seconds ([RFC7766] recommends that servers
skipping to change at page 15, line 17 skipping to change at page 15, line 7
the subsequent AXFR responses. Note that this requirement, combined the subsequent AXFR responses. Note that this requirement, combined
with the use of edns-tcp-keepalive, enables AXFR servers to signal with the use of edns-tcp-keepalive, enables AXFR servers to signal
the desire to close a connection (when existing transactions have the desire to close a connection (when existing transactions have
competed) due to low resources by sending an edns-tcp-keepalive EDNS0 competed) due to low resources by sending an edns-tcp-keepalive EDNS0
option with a timeout of 0 on any AXFR response. This does not option with a timeout of 0 on any AXFR response. This does not
signal that the AXFR is aborted, just that the server wishes to close signal that the AXFR is aborted, just that the server wishes to close
the connection as soon as possible. the connection as soon as possible.
6.3.5. Backwards compatibility 6.3.5. Backwards compatibility
Certain legacy behaviors were noted in [RFC5936], with provisos that Certain legacy behaviors were noted in [RFC5936], with provisions
implementations may want to offer options to fallback to legacy that implementations may want to offer options to fallback to legacy
behavior when interoperating with servers known not to support behavior when interoperating with servers known not to support
[RFC5936]. For purposes of interoperability, IXFR and AXFR [RFC5936]. For purposes of interoperability, IXFR and AXFR
implementations may want to continue offering such configuration implementations may want to continue offering such configuration
options, as well as supporting some behaviors that were options, as well as supporting some behaviors that were
underspecified prior to this work (e.g. performing IXFR and AXFRs on underspecified prior to this work (e.g. performing IXFR and AXFRs on
separate connections). However, XoT implementations should have no separate connections). However, XoT implementations should have no
need to do so. need to do so.
6.4. Update to RFC7766 6.4. Update to RFC7766
skipping to change at page 17, line 11 skipping to change at page 17, line 8
the TLS connection to the primary for a XFR request, so that in terms the TLS connection to the primary for a XFR request, so that in terms
of connectivity the secondary is the TLS client and the primary the of connectivity the secondary is the TLS client and the primary the
TLS server. TLS server.
The figure below provides an outline of the AXoT mechanism including The figure below provides an outline of the AXoT mechanism including
NOTIFYs. NOTIFYs.
Secondary Primary Secondary Primary
| NOTIFY | | NOTIFY |
| <-------------------------------- | UPD | <-------------------------------- | UDP
| --------------------------------> | | --------------------------------> |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------> | UDP (or part of | --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP/TLS session) | <-------------------------------- | a TCP/TLS session)
| SOA Response | | SOA Response |
| | | |
| | | |
skipping to change at page 18, line 8 skipping to change at page 18, line 8
| | | |
Figure 3. AXoT Mechanism Figure 3. AXoT Mechanism
The figure below provides an outline of the IXoT mechanism including The figure below provides an outline of the IXoT mechanism including
NOTIFYs. NOTIFYs.
Secondary Primary Secondary Primary
| NOTIFY | | NOTIFY |
| <-------------------------------- | UPD | <-------------------------------- | UDP
| --------------------------------> | | --------------------------------> |
| NOTIFY Response | | NOTIFY Response |
| | | |
| | | |
| SOA Request | | SOA Request |
| --------------------------------> | UDP (or part of | --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP/TLS session) | <-------------------------------- | a TCP/TLS session)
| SOA Response | | SOA Response |
| | | |
| | | |
skipping to change at page 20, line 19 skipping to change at page 20, line 19
7.7. Response RCODES 7.7. Response RCODES
XoT clients and servers MUST implement EDE codes. If a XoT server XoT clients and servers MUST implement EDE codes. If a XoT server
receives non-XoT traffic it is not willing to answer on a TLS receives non-XoT traffic it is not willing to answer on a TLS
connection it SHOULD respond with the extended DNS error code 21 - connection it SHOULD respond with the extended DNS error code 21 -
Not Supported [RFC8914]. XoT clients should not send any further Not Supported [RFC8914]. XoT clients should not send any further
queries of this type to the server for a reasonable period of time queries of this type to the server for a reasonable period of time
(for example, one hour) i.e., long enough that the server (for example, one hour) i.e., long enough that the server
configuration or policy might be updated. configuration or policy might be updated.
[OPEN QUESTION] Should this instead be Prohibited (by policy), or
should a new EDE be created for this case?
Historically servers have used the REFUSED RCODE for many situations, Historically servers have used the REFUSED RCODE for many situations,
and so clients often had no detailed information on which to base an and so clients often had no detailed information on which to base an
error or fallback path when queries were refused. As a result the error or fallback path when queries were refused. As a result the
client behavior could vary significantly. XoT servers that refuse client behavior could vary significantly. XoT servers that refuse
queries must cater for the fact that client behavior might vary from queries must cater for the fact that client behavior might vary from
continually retrying queries regardless of receiving REFUSED to every continually retrying queries regardless of receiving REFUSED to every
query, or at the other extreme clients may decide to stop using the query, or at the other extreme clients may decide to stop using the
server over any transport. This might be because those clients are server over any transport. This might be because those clients are
either non-XoT clients or do not implement EDE codes. either non-XoT clients or do not implement EDE codes.
skipping to change at page 28, line 27 skipping to change at page 28, line 27
Server implementations may want to also offer options that allow ACLs Server implementations may want to also offer options that allow ACLs
on a zone to specify that a specific client can use either XoT or on a zone to specify that a specific client can use either XoT or
TCP. This would allow for flexibility while clients are migrating to TCP. This would allow for flexibility while clients are migrating to
XoT. XoT.
Client implementations may similarly want to offer options to cater Client implementations may similarly want to offer options to cater
for the multi-primary case where the primaries are migrating to XoT. for the multi-primary case where the primaries are migrating to XoT.
Such configuration options MUST only be used in a 'migration mode' Such configuration options MUST only be used in a 'migration mode'
though and therefore should be used with care. though, and therefore should be used with care.
13. Implementation Status 13. Implementation Status
The 1.9.2 version of Unbound [3] includes an option to perform AXoT 1. The 1.9.2 version of Unbound [3] includes an option to perform
(instead of AXFR-over-TCP). This requires the client (secondary) to AXoT (instead of AXFR-over-TCP).
2. There are currently open pull requests against NSD to implement
1. Connection re-use by default during XFR-over-TCP [4]
2. Client side XFR-over-TLS [5]
3. Version 9.17.7 of BIND contained an initial implementation of
DoT, implementation of XoT is planned for early 2021 [6]
Both items 1. and 2.2. listed above require the client (secondary) to
authenticate the server (primary) using a configured authentication authenticate the server (primary) using a configured authentication
domain name. domain name if XoT is used.
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.
14. IANA Considerations 14. IANA Considerations
None.
15. Security Considerations 15. Security Considerations
This document specifies a security measure against a DNS risk: the This document specifies a security measure against a DNS risk: the
risk that an attacker collects entire DNS zones through eavesdropping risk that an attacker collects entire DNS zones through eavesdropping
on clear text DNS zone transfers. on clear text DNS zone transfers.
This does not mitigate: This does not mitigate:
o the risk that some level of zone activity might be inferred by o the risk that some level of zone activity might be inferred by
observing zone transfer sizes and timing on encrypted connections observing zone transfer sizes and timing on encrypted connections
skipping to change at page 29, line 31 skipping to change at page 29, line 48
Han Zhang Han Zhang
Salesforce Salesforce
San Francisco, CA San Francisco, CA
United States United States
Email: hzhang@salesforce.com Email: hzhang@salesforce.com
18. Changelog 18. Changelog
draft-ietf-dprive-xfr-over-tls-04 draft-ietf-dprive-xfr-over-tls-05
o Remove the open questions that received no comments.
o Add more detail to the implementation section
o Add Github repository o Add Github repository
o Fix typos 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
o Add a section on the threat model o Add a section on the threat model
skipping to change at page 30, line 28 skipping to change at page 31, line 4
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 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.
skipping to change at page 33, line 18 skipping to change at page 33, line 38
dprive-dnsoquic-01 (work in progress), October 2020. dprive-dnsoquic-01 (work in progress), October 2020.
[I-D.ietf-dprive-phase2-requirements] [I-D.ietf-dprive-phase2-requirements]
Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS
Privacy Requirements for Exchanges between Recursive Privacy Requirements for Exchanges between Recursive
Resolvers and Authoritative Servers", draft-ietf-dprive- Resolvers and Authoritative Servers", draft-ietf-dprive-
phase2-requirements-02 (work in progress), November 2020. phase2-requirements-02 (work in progress), November 2020.
[I-D.ietf-tls-esni] [I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS
Encrypted Client Hello", draft-ietf-tls-esni-08 (work in Encrypted Client Hello", draft-ietf-tls-esni-09 (work in
progress), October 2020. progress), December 2020.
[I-D.vandijk-dprive-ds-dot-signal-and-pin] [I-D.vandijk-dprive-ds-dot-signal-and-pin]
Dijk, P., Geuze, R., and E. Bretelle, "Signalling Dijk, P., Geuze, R., and E. Bretelle, "Signalling
Authoritative DoT support in DS records, with key Authoritative DoT support in DS records, with key
pinning", draft-vandijk-dprive-ds-dot-signal-and-pin-01 pinning", draft-vandijk-dprive-ds-dot-signal-and-pin-01
(work in progress), July 2020. (work in progress), July 2020.
[nist-guide] [nist-guide]
Chandramouli, R. and S. Rose, "Secure Domain Name System Chandramouli, R. and S. Rose, "Secure Domain Name System
(DNS) Deployment Guide", 2013, (DNS) Deployment Guide", 2013,
skipping to change at page 34, line 18 skipping to change at page 34, line 36
19.3. URIs 19.3. URIs
[1] https://www.isc.org/bind/ [1] https://www.isc.org/bind/
[2] https://www.nlnetlabs.nl/projects/nsd/about/ [2] https://www.nlnetlabs.nl/projects/nsd/about/
[3] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/ [3] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/
Changelog Changelog
[4] https://github.com/NLnetLabs/nsd/pull/145
[5] https://github.com/NLnetLabs/nsd/pull/149
[6] https://gitlab.isc.org/isc-projects/bind9/-/issues/1784
Appendix A. XoT server connection handling Appendix A. XoT server connection handling
For completeness, it is noted that an earlier version of the For completeness, it is noted that an earlier version of the
specification suggested using a XoT specific ALPN to negotiate TLS specification suggested using a XoT specific ALPN to negotiate TLS
connections that supported only a limited set of queries (SOA, XRFs) connections that supported only a limited set of queries (SOA, XRFs)
however this did not gain support. Reasons given included additional however this did not gain support. Reasons given included additional
code complexity and proxies having no natural way to forward the ALPN code complexity and proxies having no natural way to forward the ALPN
signal to DNS nameservers over TCP connections. signal to DNS nameservers over TCP connections.
A.1. Only listen on TLS on a specific IP address A.1. Only listen on TLS on a specific IP address
 End of changes. 26 change blocks. 
46 lines changed or deleted 50 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/