draft-ietf-dnsop-dns-tcp-requirements-04.txt   draft-ietf-dnsop-dns-tcp-requirements-05.txt 
Domain Name System Operations J. Kristoff Domain Name System Operations J. Kristoff
Internet-Draft DePaul University Internet-Draft DePaul University
Updates: 1123 (if approved) D. Wessels Updates: 1123 (if approved) D. Wessels
Intended status: Best Current Practice Verisign Intended status: Best Current Practice Verisign
Expires: December 26, 2019 June 24, 2019 Expires: May 4, 2020 November 1, 2019
DNS Transport over TCP - Operational Requirements DNS Transport over TCP - Operational Requirements
draft-ietf-dnsop-dns-tcp-requirements-04 draft-ietf-dnsop-dns-tcp-requirements-05
Abstract Abstract
This document encourages the practice of permitting DNS messages to This document encourages the practice of permitting DNS messages to
be carried over TCP on the Internet. It also considers the be carried over TCP on the Internet. This includes both DNS over
consequences with this form of DNS communication and the potential unencrypted TCP, as well as over an encrypted TLS session. The
operational issues that can arise when this best common practice is document also considers the consequences with this form of DNS
not upheld. communication and the potential operational issues that can arise
when this best common practice is not upheld.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 26, 2019. This Internet-Draft will expire on May 4, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 22 skipping to change at page 2, line 22
2.1. Uneven Transport Usage and Preference . . . . . . . . . . 4 2.1. Uneven Transport Usage and Preference . . . . . . . . . . 4
2.2. Waiting for Large Messages and Reliability . . . . . . . 5 2.2. Waiting for Large Messages and Reliability . . . . . . . 5
2.3. EDNS0 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. EDNS0 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Fragmentation and Truncation . . . . . . . . . . . . . . 6 2.4. Fragmentation and Truncation . . . . . . . . . . . . . . 6
2.5. "Only Zone Transfers Use TCP" . . . . . . . . . . . . . . 7 2.5. "Only Zone Transfers Use TCP" . . . . . . . . . . . . . . 7
3. DNS over TCP Requirements . . . . . . . . . . . . . . . . . . 7 3. DNS over TCP Requirements . . . . . . . . . . . . . . . . . . 7
4. Network and System Considerations . . . . . . . . . . . . . . 8 4. Network and System Considerations . . . . . . . . . . . . . . 8
4.1. Connection Admission . . . . . . . . . . . . . . . . . . 8 4.1. Connection Admission . . . . . . . . . . . . . . . . . . 8
4.2. Connection Management . . . . . . . . . . . . . . . . . . 9 4.2. Connection Management . . . . . . . . . . . . . . . . . . 9
4.3. Connection Termination . . . . . . . . . . . . . . . . . 10 4.3. Connection Termination . . . . . . . . . . . . . . . . . 10
5. DNS over TCP Filtering Risks . . . . . . . . . . . . . . . . 10 5. DNS over TCP Filtering Risks . . . . . . . . . . . . . . . . 11
5.1. DNS Wedgie . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. DNS Wedgie . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. DNS Root Zone KSK Rollover . . . . . . . . . . . . . . . 11 5.2. DNS Root Zone KSK Rollover . . . . . . . . . . . . . . . 11
5.3. DNS-over-TLS . . . . . . . . . . . . . . . . . . . . . . 11 5.3. DNS-over-TLS . . . . . . . . . . . . . . . . . . . . . . 12
6. Logging and Monitoring . . . . . . . . . . . . . . . . . . . 12 6. Logging and Monitoring . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Standards Related to DNS Transport over TCP . . . . 20
Appendix A. Standards Related to DNS Transport over TCP . . . . 19
A.1. IETF RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND A.1. IETF RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION . . . . . . . . . . . . . . . . . . . . . . 19 SPECIFICATION . . . . . . . . . . . . . . . . . . . . . . 20
A.2. IETF RFC 1536 - Common DNS Implementation Errors and A.2. IETF RFC 1536 - Common DNS Implementation Errors and
Suggested Fixes . . . . . . . . . . . . . . . . . . . . . 19 Suggested Fixes . . . . . . . . . . . . . . . . . . . . . 20
A.3. IETF RFC 1995 - Incremental Zone Transfer in DNS . . . . 19 A.3. IETF RFC 1995 - Incremental Zone Transfer in DNS . . . . 20
A.4. IETF RFC 1996 - A Mechanism for Prompt Notification of A.4. IETF RFC 1996 - A Mechanism for Prompt Notification of
Zone Changes (DNS NOTIFY) . . . . . . . . . . . . . . . . 20 Zone Changes (DNS NOTIFY) . . . . . . . . . . . . . . . . 20
A.5. IETF RFC 2181 - Clarifications to the DNS Specification . 20 A.5. IETF RFC 2181 - Clarifications to the DNS Specification . 21
A.6. IETF RFC 2694 - DNS extensions to Network Address A.6. IETF RFC 2694 - DNS extensions to Network Address
Translators (DNS_ALG) . . . . . . . . . . . . . . . . . . 20 Translators (DNS_ALG) . . . . . . . . . . . . . . . . . . 21
A.7. IETF RFC 3225 - Indicating Resolver Support of DNSSEC . . 20 A.7. IETF RFC 3225 - Indicating Resolver Support of DNSSEC . . 21
A.8. IETF RFC 3326 - DNSSEC and IPv6 A6 aware server/resolver A.8. IETF RFC 3326 - DNSSEC and IPv6 A6 aware server/resolver
message size requirements . . . . . . . . . . . . . . . . 20 message size requirements . . . . . . . . . . . . . . . . 21
A.9. IETF RFC 4472 - Operational Considerations and Issues A.9. IETF RFC 4472 - Operational Considerations and Issues
with IPv6 DNS . . . . . . . . . . . . . . . . . . . . . . 21 with IPv6 DNS . . . . . . . . . . . . . . . . . . . . . . 21
A.10. IETF RFC 5452 - Measures for Making DNS More Resilient A.10. IETF RFC 5452 - Measures for Making DNS More Resilient
against Forged Answers . . . . . . . . . . . . . . . . . 21 against Forged Answers . . . . . . . . . . . . . . . . . 22
A.11. IETF RFC 5507 - Design Choices When Expanding the DNS . . 21
A.12. IETF RFC 5625 - DNS Proxy Implementation Guidelines . . . 21 A.11. IETF RFC 5507 - Design Choices When Expanding the DNS . . 22
A.13. IETF RFC 5936 - DNS Zone Transfer Protocol (AXFR) . . . . 21 A.12. IETF RFC 5625 - DNS Proxy Implementation Guidelines . . . 22
A.13. IETF RFC 5936 - DNS Zone Transfer Protocol (AXFR) . . . . 22
A.14. IETF RFC 5966 - DNS Transport over TCP - Implementation A.14. IETF RFC 5966 - DNS Transport over TCP - Implementation
Requirements . . . . . . . . . . . . . . . . . . . . . . 22 Requirements . . . . . . . . . . . . . . . . . . . . . . 22
A.15. IETF RFC 6304 - AS112 Nameserver Operations . . . . . . . 22 A.15. IETF RFC 6304 - AS112 Nameserver Operations . . . . . . . 22
A.16. IETF RFC 6762 - Multicast DNS . . . . . . . . . . . . . . 22 A.16. IETF RFC 6762 - Multicast DNS . . . . . . . . . . . . . . 23
A.17. IETF RFC 6891 - Extension Mechanisms for DNS (EDNS(0)) . 22 A.17. IETF RFC 6891 - Extension Mechanisms for DNS (EDNS(0)) . 23
A.18. IETF RFC 6950 - Architectural Considerations on A.18. IETF RFC 6950 - Architectural Considerations on
Application Features in the DNS . . . . . . . . . . . . . 22 Application Features in the DNS . . . . . . . . . . . . . 23
A.19. IETF RFC 7477 - Child-to-Parent Synchronization in DNS . 22 A.19. IETF RFC 7477 - Child-to-Parent Synchronization in DNS . 23
A.20. IETF RFC 7720 - DNS Root Name Service Protocol and A.20. IETF RFC 7720 - DNS Root Name Service Protocol and
Deployment Requirements . . . . . . . . . . . . . . . . . 23 Deployment Requirements . . . . . . . . . . . . . . . . . 23
A.21. IETF RFC 7766 - DNS Transport over TCP - Implementation A.21. IETF RFC 7766 - DNS Transport over TCP - Implementation
Requirements . . . . . . . . . . . . . . . . . . . . . . 23 Requirements . . . . . . . . . . . . . . . . . . . . . . 23
A.22. IETF RFC 7828 - The edns-tcp-keepalive EDNS0 Option . . . 23 A.22. IETF RFC 7828 - The edns-tcp-keepalive EDNS0 Option . . . 24
A.23. IETF RFC 7858 - Specification for DNS over Transport A.23. IETF RFC 7858 - Specification for DNS over Transport
Layer Security (TLS) . . . . . . . . . . . . . . . . . . 23 Layer Security (TLS) . . . . . . . . . . . . . . . . . . 24
A.24. IETF RFC 7873 - Domain Name System (DNS) Cookies . . . . 23 A.24. IETF RFC 7873 - Domain Name System (DNS) Cookies . . . . 24
A.25. IETF RFC 7901 - CHAIN Query Requests in DNS . . . . . . . 24 A.25. IETF RFC 7901 - CHAIN Query Requests in DNS . . . . . . . 24
A.26. IETF RFC 8027 - DNSSEC Roadblock Avoidance . . . . . . . 24 A.26. IETF RFC 8027 - DNSSEC Roadblock Avoidance . . . . . . . 24
A.27. IETF RFC 8094 - DNS over Datagram Transport Layer A.27. IETF RFC 8094 - DNS over Datagram Transport Layer
Security (DTLS) . . . . . . . . . . . . . . . . . . . . . 24 Security (DTLS) . . . . . . . . . . . . . . . . . . . . . 25
A.28. IETF RFC 8162 - Using Secure DNS to Associate A.28. IETF RFC 8162 - Using Secure DNS to Associate
Certificates with Domain Names for S/MIME . . . . . . . . 24 Certificates with Domain Names for S/MIME . . . . . . . . 25
A.29. IETF RFC 8324 - DNS Privacy, Authorization, Special Uses, A.29. IETF RFC 8324 - DNS Privacy, Authorization, Special Uses,
Encoding, Characters, Matching, and Root Structure: Time Encoding, Characters, Matching, and Root Structure: Time
for Another Look? . . . . . . . . . . . . . . . . . . . . 24 for Another Look? . . . . . . . . . . . . . . . . . . . . 25
A.30. IETF RFC 8467 - Padding Policies for Extension Mechanisms A.30. IETF RFC 8467 - Padding Policies for Extension Mechanisms
for DNS (EDNS(0)) . . . . . . . . . . . . . . . . . . . . 25 for DNS (EDNS(0)) . . . . . . . . . . . . . . . . . . . . 25
A.31. IETF RFC 8483 - Yeti DNS Testbed . . . . . . . . . . . . 25 A.31. IETF RFC 8483 - Yeti DNS Testbed . . . . . . . . . . . . 25
A.32. IETF RFC 8484 - DNS Queries over HTTPS (DoH) . . . . . . 25 A.32. IETF RFC 8484 - DNS Queries over HTTPS (DoH) . . . . . . 25
A.33. IETF RFC 8490 - DNS Stateful Operations . . . . . . . . . 25 A.33. IETF RFC 8490 - DNS Stateful Operations . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 A.34. IETF RFC 8501 - Reverse DNS in IPv6 for Internet Service
Providers . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
DNS messages may be delivered using UDP or TCP communications. While DNS messages may be delivered using UDP or TCP communications. While
most DNS transactions are carried over UDP, some operators have been most DNS transactions are carried over UDP, some operators have been
led to believe that any DNS over TCP traffic is unwanted or led to believe that any DNS over TCP traffic is unwanted or
unnecessary for general DNS operation. When DNS over TCP has been unnecessary for general DNS operation. When DNS over TCP has been
restricted, a variety of communication failures and debugging restricted, a variety of communication failures and debugging
challenges often arise. As DNS and new naming system features have challenges often arise. As DNS and new naming system features have
evolved, TCP as a transport has become increasingly important for the evolved, TCP as a transport has become increasingly important for the
skipping to change at page 7, line 9 skipping to change at page 7, line 13
certain implementation and policy decisions in the DNS. Notably, certain implementation and policy decisions in the DNS. Notably,
Cloudflare implemented what it calls "DNSSEC black lies" [CLOUDFLARE] Cloudflare implemented what it calls "DNSSEC black lies" [CLOUDFLARE]
and uses ECDSA algorithms, such that their signed responses fit and uses ECDSA algorithms, such that their signed responses fit
easily in 512 bytes. The KSK Rollover design team [DESIGNTEAM] spent easily in 512 bytes. The KSK Rollover design team [DESIGNTEAM] spent
a lot of time thinking and worrying about response sizes. There is a lot of time thinking and worrying about response sizes. There is
growing sentiment in the DNSSEC community that RSA key sizes beyond growing sentiment in the DNSSEC community that RSA key sizes beyond
2048-bits are impractical and that critical infrastructure zones 2048-bits are impractical and that critical infrastructure zones
should transition to elliptic curve algorithms to keep response sizes should transition to elliptic curve algorithms to keep response sizes
manageable. manageable.
More recently, renewed security concerns about fragmented DNS
messages [AVOID_FRAGS], [FRAG_POISON] are leading implementors to
consider lower default EDNS0 UDP payload size values, for both
queriers and responders.
2.5. "Only Zone Transfers Use TCP" 2.5. "Only Zone Transfers Use TCP"
Today, the majority of the DNS community expects, or at least has a Today, the majority of the DNS community expects, or at least has a
desire, to see DNS over TCP transactions occur without interference. desire, to see DNS over TCP transactions occur without interference.
However there has also been a long held belief by some operators, However there has also been a long held belief by some operators,
particularly for security-related reasons, that DNS over TCP services particularly for security-related reasons, that DNS over TCP services
should be purposely limited or not provided at all [CHES94], should be purposely limited or not provided at all [CHES94],
[DJBDNS]. A popular meme has also held the imagination of some that [DJBDNS]. A popular meme has also held the imagination of some that
DNS over TCP is only ever used for zone transfers and is generally DNS over TCP is only ever used for zone transfers and is generally
unnecessary otherwise, with filtering all DNS over TCP traffic even unnecessary otherwise, with filtering all DNS over TCP traffic even
skipping to change at page 7, line 31 skipping to change at page 7, line 40
The position on restricting DNS over TCP had some justification given The position on restricting DNS over TCP had some justification given
that historic implementations of DNS nameservers provided very little that historic implementations of DNS nameservers provided very little
in the way of TCP connection management (for example see in the way of TCP connection management (for example see
Section 6.1.2 of [RFC7766] for more details). However modern Section 6.1.2 of [RFC7766] for more details). However modern
standards and implementations are nearing parity with the more standards and implementations are nearing parity with the more
sophisticated TCP management techniques employed by, for example, sophisticated TCP management techniques employed by, for example,
HTTP(S) servers and load balancers. HTTP(S) servers and load balancers.
3. DNS over TCP Requirements 3. DNS over TCP Requirements
An average increase in DNS message size, the continued development of An average increase in DNS message size (e.g., due to DNSSEC), the
new DNS features [Appendix A], and a denial of service mitigation continued development of new DNS features [Appendix A], and a denial
technique [Section 9] have suggested that DNS over TCP transactions of service mitigation technique [Section 9] have suggested that DNS
are as important to the correct and safe operation of the Internet over TCP transactions are as important to the correct and safe
DNS as ever, if not more so. Furthermore, there has been serious operation of the Internet DNS as ever, if not more so. Furthermore,
research that argues connection-oriented DNS transactions may provide there has been serious research that argues connection-oriented DNS
security and privacy advantages over UDP transport. [TDNS] In fact transactions may provide security and privacy advantages over UDP
[RFC7858], a Standards Track document, is just this sort of transport. [TDNS] In fact [RFC7858], a Standards Track document, is
specification. Therefore, this document makes explicit that it is just this sort of specification. Therefore, this document makes
undesirable for network operators to artificially inhibit DNS over explicit that it is undesirable for network operators to artificially
TCP transport. inhibit DNS over TCP transport.
Section 6.1.3.2 in [RFC1123] is updated: All DNS resolvers and Section 6.1.3.2 in [RFC1123] is updated: All DNS resolvers and
servers MUST support and service both UDP and TCP queries. servers MUST support and service both UDP and TCP queries.
o Authoritative servers MUST support and service all TCP queries so o Authoritative servers MUST support and service all TCP queries so
that they do not limit the size of responses to what fits in a that they do not limit the size of responses to what fits in a
single UDP packet. single UDP packet.
o Recursive servers (or forwarders) MUST support and service all TCP o Recursive servers (or forwarders) MUST support and service all TCP
queries so that they do not prevent large responses from a TCP- queries so that they do not prevent large responses from a TCP-
skipping to change at page 9, line 26 skipping to change at page 9, line 33
Networks and applications MUST NOT be configured to refuse TCP Networks and applications MUST NOT be configured to refuse TCP
queries that were not preceded by a UDP query. queries that were not preceded by a UDP query.
TCP Fast Open [RFC7413] (TFO) allows TCP clients to shorten the TCP Fast Open [RFC7413] (TFO) allows TCP clients to shorten the
handshake for subsequent connections to the same server. TFO saves handshake for subsequent connections to the same server. TFO saves
one round-trip time in the connection setup. DNS servers SHOULD one round-trip time in the connection setup. DNS servers SHOULD
enable TFO when possible. Furthermore, DNS servers clustered behind enable TFO when possible. Furthermore, DNS servers clustered behind
a single service address (e.g., anycast or load-balancing), SHOULD a single service address (e.g., anycast or load-balancing), SHOULD
use the same TFO server key on all instances. use the same TFO server key on all instances.
DNS clients SHOULD also enable TFO when possible. Currently, on some DNS clients MAY also enable TFO when possible. Currently, on some
operating systems it is not implemented or disabled by default. operating systems it is not implemented or disabled by default.
[WIKIPEDIA_TFO] describes applications and operating systems that [WIKIPEDIA_TFO] describes applications and operating systems that
support TFO. support TFO.
4.2. Connection Management 4.2. Connection Management
Since host memory for TCP state is a finite resource, DNS servers Since host memory for TCP state is a finite resource, DNS servers
MUST actively manage their connections. Applications that do not MUST actively manage their connections. Applications that do not
actively manage their connections can encounter resource exhaustion actively manage their connections can encounter resource exhaustion
leading to denial of service. For DNS, as in other protocols, there leading to denial of service. For DNS, as in other protocols, there
skipping to change at page 11, line 29 skipping to change at page 11, line 38
Networks that filter DNS over TCP may inadvertently cause problems Networks that filter DNS over TCP may inadvertently cause problems
for third party resolvers as experienced by [TOYAMA]. If for for third party resolvers as experienced by [TOYAMA]. If for
instance a resolver receives a truncated answer from a server, but instance a resolver receives a truncated answer from a server, but
when the resolver resends the query using TCP and the TCP response when the resolver resends the query using TCP and the TCP response
never arrives, not only will a complete answer be unavailable, but never arrives, not only will a complete answer be unavailable, but
the resolver will incur the full extent of TCP retransmissions and the resolver will incur the full extent of TCP retransmissions and
time outs. This situation might place extreme strain on resolver time outs. This situation might place extreme strain on resolver
resources. If the number and frequency of these truncated answers resources. If the number and frequency of these truncated answers
are sufficiently high, the steady-state of lost resources as a result are sufficiently high, the steady-state of lost resources as a result
is a "DNS" wedgie". A DNS wedgie is generally not easily or is a "DNS wedgie". A DNS wedgie is generally not easily or
completely mitigated by the affected DNS resolver operator. completely mitigated by the affected DNS resolver operator.
5.2. DNS Root Zone KSK Rollover 5.2. DNS Root Zone KSK Rollover
Recent plans for a new root zone DNSSEC KSK have highlighted a The plans for deploying a new root zone DNSSEC KSK highlighted a
potential problem in retrieving the keys.[LEWIS] Some packets in the potential problem in retrieving the keys.[LEWIS] During some phases
KSK rollover process will be larger than 1280 bytes, the IPv6 minimum of the KSK rollover process, root zone DNSKEY reponses were larger
MTU for links carrying IPv6 traffic.[RFC2460] While studies have than 1280 bytes, the IPv6 minimum MTU for links carrying IPv6
shown that problems due to fragment filtering or an inability to traffic.[RFC2460] There was some concern that any DNS server unable
generate and receive these larger messages are negligible, any DNS to receive large DNS messages over UDP, or any DNS message over TCP,
server that is unable to receive large DNS over UDP messages or would experience disruption while performing DNSSEC validation.
perform DNS over TCP may experience severe disruption of DNS service
if performing DNSSEC validation.
TODO: Is this "overcome by events" now? We've had 1414 byte DNSKEY However, during the year-long posponment of the KSK rollover there
responses at the three ZSK rollover periods since KSK-2017 became were no reported problems that could be attributed to the 1414 octet
published in the root zone. DNSKEY response when both the old and new keys were publised in the
zone. Additionaly, there were no reported problems during the two
month period when the old key was published as revoked and the DNSKEY
response was 1425 octets in size.[ROLL_YOUR_ROOT]
5.3. DNS-over-TLS 5.3. DNS-over-TLS
DNS messages may be sent over TLS to provide privacy between stubs DNS messages may be sent over TLS to provide privacy between stubs
and recursive resolvers. [RFC7858] is a standards track document and recursive resolvers. [RFC7858] is a standards track document
describing how this works. Although it utilizes TCP port 853 instead describing how this works. Although it utilizes TCP port 853 instead
of port 53, this document applies equally well to DNS-over-TLS. of port 53, this document applies equally well to DNS-over-TLS.
Note, however, DNS-over-TLS is currently only defined between stubs Note, however, DNS-over-TLS is currently only defined between stubs
and recursives. and recursives.
The use of TLS places even strong operational burdens on DNS clients The use of TLS places even stronger operational burdens on DNS
and servers. Cryptographic functions for authentication and clients and servers. Cryptographic functions for authentication and
encryption require additional processing. Unoptimized connection encryption require additional processing. Unoptimized connection
setup takes two additional round-trips compared to TCP, but can be setup takes two additional round-trips compared to TCP, but can be
reduced with Fast TLS connection resumption [RFC5077] and TLS False reduced with Fast TLS connection resumption [RFC5077] and TLS False
Start [RFC7918]. Start [RFC7918].
6. Logging and Monitoring 6. Logging and Monitoring
Developers of applications that log or monitor DNS are advised to not Developers of applications that log or monitor DNS are advised to not
ignore TCP because it is rarely used or because it is hard to ignore TCP because it is rarely used or because it is hard to
process. Operators are advised to ensure that their monitoring and process. Operators are advised to ensure that their monitoring and
logging applications properly capture DNS-over-TCP messages. logging applications properly capture DNS message over TCP.
Otherwise, attacks, exfiltration attempts, and normal traffic may go Otherwise, attacks, exfiltration attempts, and normal traffic may go
undetected. undetected.
DNS messages over TCP are in no way guaranteed to arrive in single DNS messages over TCP are in no way guaranteed to arrive in single
segments. In fact, a clever attacker may attempt to hide certain segments. In fact, a clever attacker may attempt to hide certain
messages by forcing them over very small TCP segments. Applications messages by forcing them over very small TCP segments. Applications
that capture network packets (e.g., with libpcap) should be prepared that capture network packets (e.g., with libpcap) should be prepared
to implement and perform full TCP segment reassembly. dnscap to implement and perform full TCP segment reassembly. dnscap
[dnscap] is an open-source example of a DNS logging program that [dnscap] is an open-source example of a DNS logging program that
implements TCP reassembly. implements TCP reassembly.
skipping to change at page 12, line 47 skipping to change at page 13, line 9
This document was initially motivated by feedback from students who This document was initially motivated by feedback from students who
pointed out that they were hearing contradictory information about pointed out that they were hearing contradictory information about
filtering DNS over TCP messages. Thanks in particular to a teaching filtering DNS over TCP messages. Thanks in particular to a teaching
colleague, JPL, who perhaps unknowingly encouraged the initial colleague, JPL, who perhaps unknowingly encouraged the initial
research into the differences of what the community has historically research into the differences of what the community has historically
said and did. Thanks to all the NANOG 63 attendees who provided said and did. Thanks to all the NANOG 63 attendees who provided
feedback to an early talk on this subject. feedback to an early talk on this subject.
The following individuals provided an array of feedback to help The following individuals provided an array of feedback to help
improve this document: Sara Dickinson, Bob Harold, Tatuya Jinmei, and improve this document: Piet Barber, Sara Dickinson, Bob Harold,
Paul Hoffman. The authors are also indebted to the contributions Tatuya Jinmei, and Paul Hoffman. The authors are also indebted to
stemming from discussion in the tcpm working group meeting at IETF the contributions stemming from discussion in the tcpm working group
104. Any remaining errors or imperfections are the sole meeting at IETF 104. Any remaining errors or imperfections are the
responsibility of the document authors. sole responsibility of the document authors.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 9. Security Considerations
Ironically, returning truncated DNS over UDP answers in order to Ironically, returning truncated DNS over UDP answers in order to
induce a client query to switch to DNS over TCP has become a common induce a client query to switch to DNS over TCP has become a common
response to source address spoofed, DNS denial-of-service attacks response to source address spoofed, DNS denial-of-service attacks
skipping to change at page 13, line 28 skipping to change at page 13, line 38
many operators have provided DNS over TCP service for many years many operators have provided DNS over TCP service for many years
without duress, past experience is no guarantee of future success. without duress, past experience is no guarantee of future success.
DNS over TCP is not unlike many other Internet TCP services. TCP DNS over TCP is not unlike many other Internet TCP services. TCP
threats and many mitigation strategies have been well documented in a threats and many mitigation strategies have been well documented in a
series of documents such as [RFC4953], [RFC4987], [RFC5927], and series of documents such as [RFC4953], [RFC4987], [RFC5927], and
[RFC5961]. [RFC5961].
10. Privacy Considerations 10. Privacy Considerations
TODO: Does this document warrant privacy considerations? Since DNS over both UDP and TCP use the same underlying message
format, the use of one transport instead of the other does change the
11. Examples privacy characteristics of the message content (i.e., the name being
queried). DNS over TLS or DTLS is the recommended way to achieve DNS
privacy.
Suggestion from IETF104 to include example config snippets ala 7706. Because TCP is somewhat more complex than UDP, some characteristics
of a TCP conversation may enable fingerprinting and tracking that is
not possible with UDP. For example, the choice of initial sequence
numbers, window size, and options might be able to identify a
particular TCP implementation, or even individual hosts behind shared
resources such as network address translators (NATs).
12. References 11. References
12.1. Normative References 11.1. Normative References
[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, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
12.2. Informative References 11.2. Informative References
[AVOID_FRAGS]
Fujiwara, K., "It's time to consider avoiding IP
fragmentation in the DNS", Jul 2019,
<https://blog.apnic.net/2019/07/12/its-time-to-consider-
avoiding-ip-fragmentation-in-the-dns/>.
[CASTRO2010] [CASTRO2010]
Castro, S., Zhang, M., John, W., Wessels, D., and k. Castro, S., Zhang, M., John, W., Wessels, D., and k.
claffy, "Understanding and preparing for DNS evolution", claffy, "Understanding and preparing for DNS evolution",
2010. 2010.
[CHES94] Cheswick, W. and S. Bellovin, "Firewalls and Internet [CHES94] Cheswick, W. and S. Bellovin, "Firewalls and Internet
Security: Repelling the Wily Hacker", 1994. Security: Repelling the Wily Hacker", 1994.
[CLOUDFLARE] [CLOUDFLARE]
Grant, D., "Economical With The Truth: Making DNSSEC Grant, D., "Economical With The Truth: Making DNSSEC
Answers Cheap", June 2016, Answers Cheap", June 2016,
<https://blog.cloudflare.com/black-lies/>. <https://blog.cloudflare.com/black-lies/>.
[DESIGNTEAM] [DESIGNTEAM]
Design Team Report, "Root Zone KSK Rollover Plan", Design Team Report, "Root Zone KSK Rollover Plan",
December 2015, <https://www.iana.org/reports/2016/ December 2015, <https://www.iana.org/reports/2016/root-
root-ksk-rollover-design-20160307.pdf>. ksk-rollover-design-20160307.pdf>.
[DJBDNS] D.J. Bernstein, "When are TCP queries sent?", 2002, [DJBDNS] D.J. Bernstein, "When are TCP queries sent?", 2002,
<https://cr.yp.to/djbdns/tcp.html#why>. <https://cr.yp.to/djbdns/tcp.html#why>.
[dnscap] DNS-OARC, "DNSCAP", May 2018, [dnscap] DNS-OARC, "DNSCAP", May 2018,
<https://www.dns-oarc.net/tools/dnscap>. <https://www.dns-oarc.net/tools/dnscap>.
[FRAG_POISON]
Herzberg, A. and H. Shulman, "Fragmentation Considered
Poisonous", May 2012,
<https://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf>.
[HUSTON] Huston, G., "Dealing with IPv6 fragmentation in the DNS", [HUSTON] Huston, G., "Dealing with IPv6 fragmentation in the DNS",
August 2017, <https://blog.apnic.net/2017/08/22/ August 2017, <https://blog.apnic.net/2017/08/22/dealing-
dealing-ipv6-fragmentation-dns/>. ipv6-fragmentation-dns/>.
[LEWIS] Lewis, E., "2017 DNSSEC KSK Rollover", RIPE 74 Budapest, [LEWIS] Lewis, E., "2017 DNSSEC KSK Rollover", RIPE 74 Budapest,
Hungary, May 2017, <https://ripe74.ripe.net/ Hungary, May 2017, <https://ripe74.ripe.net/
presentations/25-RIPE74-lewis-submission.pdf>. presentations/25-RIPE74-lewis-submission.pdf>.
[NETALYZR] [NETALYZR]
Kreibich, C., Weaver, N., Nechaev, B., and V. Paxson, Kreibich, C., Weaver, N., Nechaev, B., and V. Paxson,
"Netalyzr: Illuminating The Edge Network", 2010. "Netalyzr: Illuminating The Edge Network", 2010.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
skipping to change at page 18, line 51 skipping to change at page 19, line 32
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations", Lemon, T., and T. Pusateri, "DNS Stateful Operations",
RFC 8490, DOI 10.17487/RFC8490, March 2019, RFC 8490, DOI 10.17487/RFC8490, March 2019,
<https://www.rfc-editor.org/info/rfc8490>. <https://www.rfc-editor.org/info/rfc8490>.
[RFC8501] Howard, L., "Reverse DNS in IPv6 for Internet Service
Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018,
<https://www.rfc-editor.org/info/rfc8501>.
[ROLL_YOUR_ROOT]
Mueller, M., Thomas, M., Wessels, D., Hardaker, W., Chung,
T., Toorop, W., and R. Rijswijk-Deij, "Roll, Roll, Roll
Your Root: A Comprehensive Analysis of the First Ever
DNSSEC Root KSK Rollover", Oct 2019, <TBD>.
[RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting [RRL] Vixie, P. and V. Schryver, "DNS Response Rate Limiting
(DNS RRL)", ISC-TN 2012-1 Draft1, April 2012. (DNS RRL)", ISC-TN 2012-1 Draft1, April 2012.
[Stevens] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network [Stevens] Stevens, W., Fenner, B., and A. Rudoff, "UNIX Network
Programming Volume 1, Third Edition: The Sockets Programming Volume 1, Third Edition: The Sockets
Networking API", November 2003. Networking API", November 2003.
[TDNS] Zhu, L., Heidemann, J., Wessels, D., Mankin, A., and N. [TDNS] Zhu, L., Heidemann, J., Wessels, D., Mankin, A., and N.
Somaiya, "Connection-oriented DNS to Improve Privacy and Somaiya, "Connection-oriented DNS to Improve Privacy and
Security", 2015. Security", 2015.
skipping to change at page 19, line 52 skipping to change at page 20, line 44
The informational document [RFC1536] states UDP is the "chosen The informational document [RFC1536] states UDP is the "chosen
protocol for communication though TCP is used for zone transfers." protocol for communication though TCP is used for zone transfers."
That statement should now be considered in its historical context and That statement should now be considered in its historical context and
is no longer a proper reflection of modern expectations. is no longer a proper reflection of modern expectations.
A.3. IETF RFC 1995 - Incremental Zone Transfer in DNS A.3. IETF RFC 1995 - Incremental Zone Transfer in DNS
The [RFC1995] standards track document documents the use of TCP as The [RFC1995] standards track document documents the use of TCP as
the fallback transport when IXFR responses do not fit into a single the fallback transport when IXFR responses do not fit into a single
UDP response. As with AXFR, IXFR messages are typically delivered UDP response. As with AXFR, IXFR messages are typically delivered
over TCP by default in practice. XXX: is this an accurate statement? over TCP by default in practice.
A.4. IETF RFC 1996 - A Mechanism for Prompt Notification of Zone A.4. IETF RFC 1996 - A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY) Changes (DNS NOTIFY)
The [RFC1996] standards track document suggests a zone master may The [RFC1996] standards track document suggests a zone master may
decide to issue NOTIFY messages over TCP. In practice NOTIFY decide to issue NOTIFY messages over TCP. In practice NOTIFY
messages are generally sent over UDP, but this specification leaves messages are generally sent over UDP, but this specification leaves
open the possibility that the choice of transport protocol is up to open the possibility that the choice of transport protocol is up to
the master, and therefore a slave ought to be able to operate over the master, and therefore a slave ought to be able to operate over
both UDP and TCP. both UDP and TCP.
skipping to change at page 25, line 35 skipping to change at page 26, line 13
respectively. Self-described as a a technique that more closely respectively. Self-described as a a technique that more closely
resembles a tunneling mechanism, DoH nevertheless likely implies DNS resembles a tunneling mechanism, DoH nevertheless likely implies DNS
over TCP in some sense if not directly. over TCP in some sense if not directly.
A.33. IETF RFC 8490 - DNS Stateful Operations A.33. IETF RFC 8490 - DNS Stateful Operations
This standards track document [RFC8490] updates the base protocol This standards track document [RFC8490] updates the base protocol
specification with a new OPCODE to help manage stateful operations in specification with a new OPCODE to help manage stateful operations in
persistent sessions such as those that might be used by DNS over TCP. persistent sessions such as those that might be used by DNS over TCP.
A.34. IETF RFC 8501 - Reverse DNS in IPv6 for Internet Service
Providers
This informational document [RFC8501] identifies potential
operational challenges with Dynamic DNS including denial-of-service
threats. The document suggests TCP may provide some advantages, but
that updating hosts would need to be explicitly configured to use TCP
instead of UDP.
Authors' Addresses Authors' Addresses
John Kristoff John Kristoff
DePaul University DePaul University
Chicago, IL 60604 Chicago, IL 60604
US US
Phone: +1 312 493 0305 Phone: +1 312 493 0305
Email: jtk@depaul.edu Email: jtk@depaul.edu
URI: https://aharp.iorc.depaul.edu URI: https://aharp.iorc.depaul.edu
 End of changes. 41 change blocks. 
82 lines changed or deleted 128 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/