| < draft-ietf-dnsop-dns-tcp-requirements-12.txt | draft-ietf-dnsop-dns-tcp-requirements-15.txt > | |||
|---|---|---|---|---|
| Domain Name System Operations J.T. Kristoff | Domain Name System Operations J.T. Kristoff | |||
| Internet-Draft DataPlane.org | Internet-Draft DataPlane.org | |||
| Updates: 1123 (if approved) D. Wessels | Updates: 1123, 1536 (if approved) D. Wessels | |||
| Intended status: Best Current Practice Verisign | Intended status: Best Current Practice Verisign | |||
| Expires: 19 February 2022 18 August 2021 | Expires: 10 July 2022 6 January 2022 | |||
| DNS Transport over TCP - Operational Requirements | DNS Transport over TCP - Operational Requirements | |||
| draft-ietf-dnsop-dns-tcp-requirements-12 | draft-ietf-dnsop-dns-tcp-requirements-15 | |||
| Abstract | Abstract | |||
| This document updates RFC 1123. This document strongly encourages | This document updates RFC 1123 and RFC 1536. This document requires | |||
| the operational practice of permitting DNS messages to be carried | the operational practice of permitting DNS messages to be carried | |||
| over TCP on the Internet as a best current practice. Such | over TCP on the Internet as a Best Current Practice. This | |||
| encouragement is aligned with the implementation requirements in RFC | operational requirement is aligned with the implementation | |||
| 7766. The use of TCP includes both DNS over unencrypted TCP, as well | requirements in RFC 7766. The use of TCP includes both DNS over | |||
| as over an encrypted TLS session. The document also considers the | unencrypted TCP, as well as over an encrypted TLS session. The | |||
| consequences with this form of DNS communication and the potential | document also considers the consequences of this form of DNS | |||
| operational issues that can arise when this best current practice is | communication and the potential operational issues that can arise | |||
| not upheld. | when this Best Current 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 19 February 2022. | This Internet-Draft will expire on 10 July 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Simplified BSD License text | extracted from this document must include Revised BSD License text as | |||
| as described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Simplified BSD License. | provided without warranty as described in the Revised BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 | |||
| 2. History of DNS over TCP . . . . . . . . . . . . . . . . . . . 4 | 2. History of DNS over TCP . . . . . . . . . . . . . . . . . . . 4 | |||
| 2.1. Uneven Transport Usage and Preference . . . . . . . . . . 4 | 2.1. Uneven Transport Usage and Preference . . . . . . . . . . 5 | |||
| 2.2. Waiting for Large Messages and Reliability . . . . . . . 5 | 2.2. Waiting for Large Messages and Reliability . . . . . . . 5 | |||
| 2.3. EDNS(0) . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.3. EDNS(0) . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 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" . . . . . . . . . . . . . . 8 | |||
| 3. DNS over TCP Requirements . . . . . . . . . . . . . . . . . . 8 | 2.6. Reuse, Pipelining, and Out-of-Order Processing . . . . . 8 | |||
| 4. Network and System Considerations . . . . . . . . . . . . . . 9 | 3. DNS over TCP Requirements . . . . . . . . . . . . . . . . . . 9 | |||
| 4.1. Connection Establishment and Admission . . . . . . . . . 9 | 4. Network and System Considerations . . . . . . . . . . . . . . 10 | |||
| 4.2. Connection Management . . . . . . . . . . . . . . . . . . 10 | 4.1. Connection Establishment and Admission . . . . . . . . . 10 | |||
| 4.3. Connection Termination . . . . . . . . . . . . . . . . . 11 | 4.2. Connection Management . . . . . . . . . . . . . . . . . . 12 | |||
| 4.4. DNS-over-TLS . . . . . . . . . . . . . . . . . . . . . . 11 | 4.3. Connection Termination . . . . . . . . . . . . . . . . . 13 | |||
| 5. DNS over TCP Filtering Risks . . . . . . . . . . . . . . . . 12 | 4.4. DNS-over-TLS . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 5.1. DNS Wedgie . . . . . . . . . . . . . . . . . . . . . . . 12 | 4.5. Defaults and Recommended Limits . . . . . . . . . . . . . 14 | |||
| 5.2. DNS Root Zone KSK Rollover . . . . . . . . . . . . . . . 13 | 5. DNS over TCP Filtering Risks . . . . . . . . . . . . . . . . 15 | |||
| 6. Logging and Monitoring . . . . . . . . . . . . . . . . . . . 13 | 5.1. Truncation, Retries, and Timeouts . . . . . . . . . . . . 15 | |||
| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 | 5.2. DNS Root Zone KSK Rollover . . . . . . . . . . . . . . . 16 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 6. Logging and Monitoring . . . . . . . . . . . . . . . . . . . 16 | |||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 11.2. Informative References . . . . . . . . . . . . . . . . . 16 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| Appendix A. Standards Related to DNS Transport over TCP . . . . 23 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 | |||
| 11.2. Informative References . . . . . . . . . . . . . . . . . 19 | ||||
| Appendix A. Standards Related to DNS Transport over TCP . . . . 27 | ||||
| A.1. IETF RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND | A.1. IETF RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND | |||
| SPECIFICATION . . . . . . . . . . . . . . . . . . . . . 23 | SPECIFICATION . . . . . . . . . . . . . . . . . . . . . 27 | |||
| A.2. IETF RFC 1536 - Common DNS Implementation Errors and | A.2. IETF RFC 1536 - Common DNS Implementation Errors and | |||
| Suggested Fixes . . . . . . . . . . . . . . . . . . . . 23 | Suggested Fixes . . . . . . . . . . . . . . . . . . . . 27 | |||
| A.3. IETF RFC 1995 - Incremental Zone Transfer in DNS . . . . 23 | A.3. IETF RFC 1995 - Incremental Zone Transfer in DNS . . . . 27 | |||
| 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) . . . . . . . . . . . . . . . . . . 23 | Changes (DNS NOTIFY) . . . . . . . . . . . . . . . . . . 27 | |||
| A.5. IETF RFC 2181 - Clarifications to the DNS | A.5. IETF RFC 2181 - Clarifications to the DNS | |||
| Specification . . . . . . . . . . . . . . . . . . . . . 23 | Specification . . . . . . . . . . . . . . . . . . . . . 27 | |||
| A.6. IETF RFC 2694 - DNS extensions to Network Address | A.6. IETF RFC 2694 - DNS extensions to Network Address | |||
| Translators (DNS_ALG) . . . . . . . . . . . . . . . . . 24 | Translators (DNS_ALG) . . . . . . . . . . . . . . . . . 28 | |||
| A.7. IETF RFC 3225 - Indicating Resolver Support of DNSSEC . . 24 | A.7. IETF RFC 3225 - Indicating Resolver Support of DNSSEC . . 28 | |||
| A.8. IETF RFC 3326 - DNSSEC and IPv6 A6 aware server/resolver | A.8. IETF RFC 3226 - DNSSEC and IPv6 A6 aware server/resolver | |||
| message size requirements . . . . . . . . . . . . . . . 24 | message size requirements . . . . . . . . . . . . . . . 28 | |||
| A.9. IETF RFC 4472 - Operational Considerations and Issues with | A.9. IETF RFC 4472 - Operational Considerations and Issues with | |||
| IPv6 DNS . . . . . . . . . . . . . . . . . . . . . . . . 24 | IPv6 DNS . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
| 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 . . . . . . . . . . . . . . . . . 24 | against Forged Answers . . . . . . . . . . . . . . . . . 28 | |||
| A.11. IETF RFC 5507 - Design Choices When Expanding the DNS . . 25 | A.11. IETF RFC 5507 - Design Choices When Expanding the DNS . . 29 | |||
| A.12. IETF RFC 5625 - DNS Proxy Implementation Guidelines . . . 25 | A.12. IETF RFC 5625 - DNS Proxy Implementation Guidelines . . . 29 | |||
| A.13. IETF RFC 5936 - DNS Zone Transfer Protocol (AXFR) . . . . 25 | A.13. IETF RFC 5936 - DNS Zone Transfer Protocol (AXFR) . . . . 29 | |||
| A.14. IETF RFC 7534 - AS112 Nameserver Operations . . . . . . . 25 | A.14. IETF RFC 7534 - AS112 Nameserver Operations . . . . . . . 29 | |||
| A.15. IETF RFC 6762 - Multicast DNS . . . . . . . . . . . . . . 25 | A.15. IETF RFC 6762 - Multicast DNS . . . . . . . . . . . . . . 29 | |||
| A.16. IETF RFC 6891 - Extension Mechanisms for DNS (EDNS(0)) . 25 | A.16. IETF RFC 6891 - Extension Mechanisms for DNS (EDNS(0)) . 29 | |||
| A.17. IETF RFC 6950 - Architectural Considerations on Application | A.17. IETF RFC 6950 - Architectural Considerations on Application | |||
| Features in the DNS . . . . . . . . . . . . . . . . . . 26 | Features in the DNS . . . . . . . . . . . . . . . . . . 30 | |||
| A.18. IETF RFC 7477 - Child-to-Parent Synchronization in DNS . 26 | A.18. IETF RFC 7477 - Child-to-Parent Synchronization in DNS . 30 | |||
| A.19. IETF RFC 7720 - DNS Root Name Service Protocol and | A.19. IETF RFC 7720 - DNS Root Name Service Protocol and | |||
| Deployment Requirements . . . . . . . . . . . . . . . . 26 | Deployment Requirements . . . . . . . . . . . . . . . . 30 | |||
| A.20. IETF RFC 7766 - DNS Transport over TCP - Implementation | A.20. IETF RFC 7766 - DNS Transport over TCP - Implementation | |||
| Requirements . . . . . . . . . . . . . . . . . . . . . . 26 | Requirements . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| A.21. IETF RFC 7828 - The edns-tcp-keepalive EDNS(0) Option . . 26 | A.21. IETF RFC 7828 - The edns-tcp-keepalive EDNS(0) Option . . 30 | |||
| A.22. IETF RFC 7858 - Specification for DNS over Transport Layer | A.22. IETF RFC 7858 - Specification for DNS over Transport Layer | |||
| Security (TLS) . . . . . . . . . . . . . . . . . . . . . 27 | Security (TLS) . . . . . . . . . . . . . . . . . . . . . 31 | |||
| A.23. IETF RFC 7873 - Domain Name System (DNS) Cookies . . . . 27 | A.23. IETF RFC 7873 - Domain Name System (DNS) Cookies . . . . 31 | |||
| A.24. IETF RFC 7901 - CHAIN Query Requests in DNS . . . . . . . 27 | A.24. IETF RFC 7901 - CHAIN Query Requests in DNS . . . . . . . 31 | |||
| A.25. IETF RFC 8027 - DNSSEC Roadblock Avoidance . . . . . . . 27 | A.25. IETF RFC 8027 - DNSSEC Roadblock Avoidance . . . . . . . 31 | |||
| A.26. IETF RFC 8094 - DNS over Datagram Transport Layer Security | A.26. IETF RFC 8094 - DNS over Datagram Transport Layer Security | |||
| (DTLS) . . . . . . . . . . . . . . . . . . . . . . . . . 28 | (DTLS) . . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
| A.27. IETF RFC 8162 - Using Secure DNS to Associate Certificates | A.27. IETF RFC 8162 - Using Secure DNS to Associate Certificates | |||
| with Domain Names for S/MIME . . . . . . . . . . . . . . 28 | with Domain Names for S/MIME . . . . . . . . . . . . . . 32 | |||
| A.28. IETF RFC 8324 - DNS Privacy, Authorization, Special Uses, | A.28. IETF RFC 8324 - DNS Privacy, Authorization, Special Uses, | |||
| Encoding, Characters, Matching, and Root Structure: Time for | Encoding, Characters, Matching, and Root Structure: Time for | |||
| Another Look? . . . . . . . . . . . . . . . . . . . . . 28 | Another Look? . . . . . . . . . . . . . . . . . . . . . 32 | |||
| A.29. IETF RFC 8467 - Padding Policies for Extension Mechanisms | A.29. IETF RFC 8467 - Padding Policies for Extension Mechanisms | |||
| for DNS (EDNS(0)) . . . . . . . . . . . . . . . . . . . 28 | for DNS (EDNS(0)) . . . . . . . . . . . . . . . . . . . 32 | |||
| A.30. IETF RFC 8482 - Providing Minimal-Sized Responses to DNS | A.30. IETF RFC 8482 - Providing Minimal-Sized Responses to DNS | |||
| Queries That Have QTYPE=ANY . . . . . . . . . . . . . . 28 | Queries That Have QTYPE=ANY . . . . . . . . . . . . . . 32 | |||
| A.31. IETF RFC 8483 - Yeti DNS Testbed . . . . . . . . . . . . 29 | A.31. IETF RFC 8483 - Yeti DNS Testbed . . . . . . . . . . . . 33 | |||
| A.32. IETF RFC 8484 - DNS Queries over HTTPS (DoH) . . . . . . 29 | A.32. IETF RFC 8484 - DNS Queries over HTTPS (DoH) . . . . . . 33 | |||
| A.33. IETF RFC 8490 - DNS Stateful Operations . . . . . . . . . 29 | A.33. IETF RFC 8490 - DNS Stateful Operations . . . . . . . . . 33 | |||
| A.34. IETF RFC 8501 - Reverse DNS in IPv6 for Internet Service | A.34. IETF RFC 8501 - Reverse DNS in IPv6 for Internet Service | |||
| Providers . . . . . . . . . . . . . . . . . . . . . . . 29 | Providers . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
| A.35. IETF RFC 8806 - Running a Root Server Local to a | A.35. IETF RFC 8806 - Running a Root Server Local to a | |||
| Resolver . . . . . . . . . . . . . . . . . . . . . . . . 29 | Resolver . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
| A.36. IETF RFC 8906 - A Common Operational Problem in DNS | A.36. IETF RFC 8906 - A Common Operational Problem in DNS | |||
| Servers: Failure to Communicate . . . . . . . . . . . . 29 | Servers: Failure to Communicate . . . . . . . . . . . . 33 | |||
| A.37. IETF RFC 8932 - Recommendations for DNS Privacy Service | A.37. IETF RFC 8932 - Recommendations for DNS Privacy Service | |||
| Operators . . . . . . . . . . . . . . . . . . . . . . . 30 | Operators . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
| A.38. IETF RFC 8945 - Secret Key Transaction Authentication for | A.38. IETF RFC 8945 - Secret Key Transaction Authentication for | |||
| DNS (TSIG) . . . . . . . . . . . . . . . . . . . . . . . 30 | DNS (TSIG) . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
| 1. Introduction | 1. Introduction | |||
| DNS messages are delivered using UDP or TCP communications. While | DNS messages are 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 | |||
| correct and safe operation of an Internet DNS. Reflecting modern | correct and safe operation of an Internet DNS. Reflecting modern | |||
| usage, the DNS standards declare that support for TCP is a required | usage, the DNS standards declare that support for TCP is a required | |||
| part of the DNS implementation specifications [RFC7766]. This | part of the DNS implementation specifications [RFC7766]. This | |||
| document is the formal requirements equivalent for the operational | document is the formal requirements equivalent for the operational | |||
| community, encouraging system administrators, network engineers, and | community, encouraging system administrators, network engineers, and | |||
| security staff to ensure DNS over TCP communications support is on | security staff to ensure DNS over TCP communications support is on | |||
| par with DNS over UDP communications. It updates [RFC1123] | par with DNS over UDP communications. It updates [RFC1123] | |||
| Section 6.1.3.2 to clarify that all DNS resolvers and recursive MUST | Section 6.1.3.2 to clarify that all DNS resolvers and recursive | |||
| support and service both TCP and UDP queries. | servers MUST support and service both TCP and UDP queries, and also | |||
| updates [RFC1536] to remove the misconception that TCP is only useful | ||||
| for zone transfers. | ||||
| 1.1. Requirements Language | 1.1. Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 2. History of DNS over TCP | 2. History of DNS over TCP | |||
| The curious state of disagreement between operational best practices | The curious state of disagreement between operational best practices | |||
| and guidance for DNS transport protocols derives from conflicting | and guidance for DNS transport protocols derives from conflicting | |||
| messages operators have gotten from other operators, implementors, | messages operators have received from other operators, implementors, | |||
| and even the IETF. Sometimes these mixed signals have been explicit; | and even the IETF. Sometimes these mixed signals have been explicit; | |||
| on other occasions, conflicting messages have been implicit. This | on other occasions, conflicting messages have been implicit. This | |||
| section presents an interpretation of the storied and conflicting | section presents an interpretation of the storied and conflicting | |||
| history that led to this document. | history that led to this document. This section is included for | |||
| informational purposes only. | ||||
| 2.1. Uneven Transport Usage and Preference | 2.1. Uneven Transport Usage and Preference | |||
| In the original suite of DNS specifications, [RFC1034] and [RFC1035] | In the original suite of DNS specifications, [RFC1034] and [RFC1035] | |||
| clearly specified that DNS messages could be carried in either UDP or | clearly specified that DNS messages could be carried in either UDP or | |||
| TCP, but they also stated a preference for UDP as the best transport | TCP, but they also stated a preference for UDP as the best transport | |||
| for queries in the general case. As stated in [RFC1035]: | for queries in the general case. As stated in [RFC1035]: | |||
| "While virtual circuits can be used for any DNS activity, | "While virtual circuits can be used for any DNS activity, | |||
| datagrams are preferred for queries due to their lower overhead | datagrams are preferred for queries due to their lower overhead | |||
| skipping to change at page 5, line 41 ¶ | skipping to change at page 6, line 4 ¶ | |||
| At least two new, widely anticipated developments were set to elevate | At least two new, widely anticipated developments were set to elevate | |||
| the need for DNS over TCP transactions. The first was dynamic | the need for DNS over TCP transactions. The first was dynamic | |||
| updates defined in [RFC2136] and the second was the set of extensions | updates defined in [RFC2136] and the second was the set of extensions | |||
| collectively known as DNSSEC, whose operational considerations are | collectively known as DNSSEC, whose operational considerations are | |||
| originally given in [RFC2541]. The former suggested "requestors who | originally given in [RFC2541]. The former suggested "requestors who | |||
| require an accurate response code must use TCP," while the latter | require an accurate response code must use TCP," while the latter | |||
| warned "... larger keys increase the size of KEY and SIG RRs. This | warned "... larger keys increase the size of KEY and SIG RRs. This | |||
| increases the chance of DNS UDP packet overflow and the possible | increases the chance of DNS UDP packet overflow and the possible | |||
| necessity for using higher overhead TCP in responses." | necessity for using higher overhead TCP in responses." | |||
| Yet, defying some expectations, DNS over TCP remained little-used in | Yet, defying some expectations, DNS over TCP remained little-used in | |||
| real traffic across the Internet around this time. Dynamic updates | real traffic across the Internet in the late 1990s. Dynamic updates | |||
| saw little deployment between autonomous networks. Around the time | saw little deployment between autonomous networks. Around the time | |||
| DNSSEC was first defined, another new feature helped solidify UDP | DNSSEC was first defined, another new feature helped solidify UDP | |||
| transport dominance for message transactions. | transport dominance for message transactions. | |||
| 2.3. EDNS(0) | 2.3. EDNS(0) | |||
| In 1999 the IETF published the Extension Mechanisms for DNS (EDNS(0)) | In 1999 the IETF published the Extension Mechanisms for DNS (EDNS(0)) | |||
| in [RFC2671] (superseded in 2013 by an update in [RFC6891]). That | in [RFC2671] (superseded in 2013 by an update in [RFC6891]). That | |||
| document standardized a way for communicating DNS nodes to perform | document standardized a way for communicating DNS nodes to perform | |||
| rudimentary capabilities negotiation. One such capability written | rudimentary capabilities negotiation. One such capability written | |||
| into the base specification and present in every EDNS(0)-compatible | into the base specification and present in every EDNS(0)-compatible | |||
| message is the value of the maximum UDP payload size the sender can | message is the value of the maximum UDP payload size the sender can | |||
| support. This unsigned 16-bit field specifies, in bytes, the maximum | support. This unsigned 16-bit field specifies, in bytes, the maximum | |||
| (possibly fragmented) DNS message size a node is capable of receiving | (possibly fragmented) DNS message size a node is capable of receiving | |||
| over UDP. In practice, typical values are a subset of the 512- to | over UDP. In practice, typical values are a subset of the 512- to | |||
| 4096-byte range. EDNS(0) became widely deployed over the next | 4096-byte range. EDNS(0) became widely deployed over the next | |||
| several years, and numerous surveys ([CASTRO2010], [NETALYZR]) have | several years, and numerous surveys ([CASTRO2010], [NETALYZR]) have | |||
| shown many systems currently support larger UDP MTUs with EDNS(0). | shown that many systems support larger UDP MTUs with EDNS(0). | |||
| The natural effect of EDNS(0) deployment meant DNS messages larger | The natural effect of EDNS(0) deployment meant DNS messages larger | |||
| than 512 bytes would be less reliant on TCP than they might otherwise | than 512 bytes would be less reliant on TCP than they might otherwise | |||
| have been. While a non-negligible population of DNS systems lacked | have been. While a non-negligible population of DNS systems lacked | |||
| EDNS(0) or fell back to TCP when necessary, DNS clients still | EDNS(0) or fell back to TCP when necessary, DNS clients still | |||
| strongly prefer UDP to TCP. For example, as of 2014, DNS over TCP | strongly prefer UDP to TCP. For example, as of 2014, DNS over TCP | |||
| transactions remained a very small fraction of overall DNS traffic | transactions remained a very small fraction of overall DNS traffic | |||
| received by root name servers [VERISIGN]. | received by root name servers [VERISIGN]. | |||
| 2.4. Fragmentation and Truncation | 2.4. Fragmentation and Truncation | |||
| skipping to change at page 6, line 47 ¶ | skipping to change at page 7, line 6 ¶ | |||
| fragments do not arrive, the application does not receive the message | fragments do not arrive, the application does not receive the message | |||
| and the request times out. | and the request times out. | |||
| For IPv4-connected hosts, the MTU is often the Ethernet payload size | For IPv4-connected hosts, the MTU is often the Ethernet payload size | |||
| of 1500 bytes. This means that the largest unfragmented UDP DNS | of 1500 bytes. This means that the largest unfragmented UDP DNS | |||
| message that can be sent over IPv4 is likely 1472 bytes, although | message that can be sent over IPv4 is likely 1472 bytes, although | |||
| tunnel encapsulation may reduce that maximum message size in some | tunnel encapsulation may reduce that maximum message size in some | |||
| cases. | cases. | |||
| For IPv6, the situation is a little more complicated. First, IPv6 | For IPv6, the situation is a little more complicated. First, IPv6 | |||
| headers are 40 bytes (versus 20 without options in IPv4). Second, it | headers are 40 bytes (versus 20 without options in IPv4). Second, | |||
| seems as though some people have misinterpreted IPv6's required | approximately one third of DNS recursive resolvers use the minimum | |||
| minimum MTU of 1280 as a required maximum. Third, fragmentation in | MTU of 1280 bytes [APNIC]. Third, fragmentation in IPv6 can only be | |||
| IPv6 can only be done by the host originating the datagram. The need | done by the host originating the datagram. The need to fragment is | |||
| to fragment is conveyed in an ICMPv6 "packet too big" message. The | conveyed in an ICMPv6 "packet too big" message. The originating host | |||
| originating host indicates a fragmented datagram with IPv6 extension | indicates a fragmented datagram with IPv6 extension headers. | |||
| headers. Unfortunately, it is quite common for both ICMPv6 and IPv6 | Unfortunately, it is quite common for both ICMPv6 and IPv6 extension | |||
| extension headers to be blocked by middleboxes. According to | headers to be blocked by middleboxes. According to [HUSTON] some 35% | |||
| [HUSTON] some 35%of IPv6-capable recursive resolvers were unable to | of IPv6-capable recursive resolvers were unable to receive a | |||
| receive a fragmented IPv6 packet. Even if the originating host does | fragmented IPv6 packet. When the originating host receives a signal | |||
| receive a signal that fragmentation is required, the stateless nature | that fragmentation is required, it is expected to populate its Path | |||
| of the DNS protocol is such that the host does not generally retain a | MTU cache for that destination. The application, then, will retry | |||
| copy of the message concerned and hence is unable to fragment and re- | the query after a timeout since the host does not generally retain | |||
| send anyway. | copies of messages sent over UDP for potential retransmission. | |||
| The practical consequence of all this is that DNS requestors must be | The practical consequence of all this is that DNS requestors must be | |||
| prepared to retry queries with different EDNS(0) maximum message size | prepared to retry queries with different EDNS(0) maximum message size | |||
| values. Administrators of [BIND] are likely to be familiar with | values. Administrators of [BIND] are likely to be familiar with | |||
| seeing "success resolving ... after reducing the advertised EDNS(0) | seeing "success resolving ... after reducing the advertised EDNS(0) | |||
| UDP packet size to 512 octets" messages in their system logs. | UDP packet size to 512 octets" messages in their system logs. | |||
| Often, reducing the EDNS(0) UDP packet size leads to a successful | Often, reducing the EDNS(0) UDP packet size leads to a successful | |||
| response. That is, the necessary data fits within the smaller | response. That is, the necessary data fits within the smaller | |||
| message size. However, when the data does not fit, the server sets | message size. However, when the data does not fit, the server sets | |||
| the truncated flag in its response, indicating the client should | the truncated flag in its response, indicating the client should | |||
| retry over TCP to receive the whole response. This is undesirable | retry over TCP to receive the whole response. This is undesirable | |||
| from the client's point of view because it adds more latency and | from the client's point of view because it adds more latency and | |||
| potentially undesirable from the server's point of view due to the | potentially undesirable from the server's point of view due to the | |||
| increased resource requirements of TCP. | increased resource requirements of TCP. | |||
| Note that a receiver is unable to differentiate between packets lost | ||||
| due to congestion and packets (fragments) intentionally dropped by | ||||
| firewalls or middleboxes. Over network paths with non-trivial | ||||
| amounts of packet loss, larger, fragmented DNS responses are more | ||||
| likely to never arrive and time out compared to smaller, unfragmented | ||||
| responses. Clients might be misled into retrying queries with | ||||
| different EDNS(0) UDP packet size values for the wrong reason. | ||||
| The issues around fragmentation, truncation, and TCP are driving | The issues around fragmentation, truncation, and TCP are driving | |||
| 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 Key Signing Key (KSK) Rollover design team | |||
| a lot of time thinking and worrying about response sizes. There is | [DESIGNTEAM] spent a lot of time thinking and worrying about response | |||
| growing sentiment in the DNSSEC community that RSA key sizes beyond | sizes. There is growing sentiment in the DNSSEC community that RSA | |||
| 2048-bits are impractical and that critical infrastructure zones | key sizes beyond 2048-bits are impractical and that critical | |||
| should transition to elliptic curve algorithms to keep response sizes | infrastructure zones should transition to elliptic curve algorithms | |||
| manageable [ECDSA]. | to keep response sizes manageable [ECDSA]. | |||
| More recently, renewed security concerns about fragmented DNS | More recently, renewed security concerns about fragmented DNS | |||
| messages ([AVOID_FRAGS], [FRAG_POISON]) are leading implementors to | messages ([AVOID_FRAGS], [FRAG_POISON]) are leading implementors to | |||
| consider smaller responses and lower default EDNS(0) UDP payload size | consider smaller responses and lower default EDNS(0) UDP payload size | |||
| values for both queriers and responders [FLAGDAY2020]. | values for both queriers and responders [FLAGDAY2020]. | |||
| 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, | [FLAGDAY2020]. However, there has also been a long-held belief by | |||
| particularly for security-related reasons, that DNS over TCP services | some operators, particularly for security-related reasons, that DNS | |||
| should be purposely limited or not provided at all [CHES94], | over TCP services should be purposely limited or not provided at all | |||
| [DJBDNS]. A popular meme is that DNS over TCP is only ever used for | [CHES94], [DJBDNS]. A popular meme is that DNS over TCP is only ever | |||
| zone transfers and is generally unnecessary otherwise, with filtering | used for zone transfers and is generally unnecessary otherwise, with | |||
| all DNS over TCP traffic even described as a best practice. | filtering all DNS over TCP traffic even described as a best practice. | |||
| The position on restricting DNS over TCP had some justification given | The position on restricting DNS over TCP had some justification given | |||
| that historical implementations of DNS nameservers provided very | that historical implementations of DNS nameservers provided very | |||
| little in the way of TCP connection management (for example see | little 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. | |||
| 2.6. Reuse, Pipelining, and Out-of-Order Processing | ||||
| The idea that a TCP connection can support multiple transactions goes | ||||
| back as far as [RFC0883], which states: "Multiple messages may be | ||||
| sent over a virtual circuit." Although [RFC1035], which updates the | ||||
| former, omits this particular detail, it has been generally accepted | ||||
| that a TCP connection can be used for more than one query and | ||||
| response. | ||||
| [RFC5966] clarified that servers are not required to preserve the | ||||
| order of queries and responses over any transport. [RFC7766], which | ||||
| updates the former, further encourages query pipelining over TCP to | ||||
| achieve performance on par with UDP. A server that sends out-of- | ||||
| order responses to pipelined queries avoids head-of-line blocking | ||||
| when the response for a later query is ready before the response to | ||||
| an earlier query. | ||||
| However, TCP can potentially suffer from a different head-of-line | ||||
| blocking problem due to packet loss. Since TCP itself enforces | ||||
| ordering, a single lost segment delays delivery of data in any | ||||
| following segments until the lost segment is retransmitted and | ||||
| successfully received. | ||||
| 3. DNS over TCP Requirements | 3. DNS over TCP Requirements | |||
| An average increase in DNS message size (e.g., due to DNSSEC), the | An average increase in DNS message size (e.g., due to DNSSEC), the | |||
| continued development of new DNS features (Appendix A), and a denial | continued development of new DNS features (Appendix A), and a denial | |||
| of service mitigation technique (Section 9), all show that DNS over | of service mitigation technique (Section 8), all show that DNS over | |||
| TCP transactions are as important to the correct and safe operation | TCP transactions are as important to the correct and safe operation | |||
| of the Internet DNS as ever, if not more so. Furthermore, there has | of the Internet DNS as ever, if not more so. Furthermore, there has | |||
| been serious research that argues connection-oriented DNS | been research that argues connection-oriented DNS transactions may | |||
| transactions may provide security and privacy advantages over UDP | provide security and privacy advantages over UDP transport [TDNS]. | |||
| transport.[TDNS] In fact, the standard for DNS over TLS [RFC7858] is | In fact, the standard for DNS over TLS [RFC7858] is just this sort of | |||
| just this sort of specification. Therefore, this document makes | specification. Therefore, this document makes explicit that it is | |||
| explicit that it is undesirable for network operators to artificially | undesirable for network operators to artificially inhibit DNS over | |||
| inhibit DNS over TCP transport. | 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. | |||
| * Authoritative servers MUST support and service all TCP queries so | * DNS servers (including forwarders) MUST support and service TCP | |||
| that they do not limit the size of responses to what fits in a | for receiving queries, so that clients can reliably receive | |||
| single UDP packet. | responses that are larger than what either side considers too | |||
| large for UDP. | ||||
| * Recursive servers (or forwarders) MUST support and service all TCP | * DNS clients MUST support TCP for sending queries, so that they can | |||
| queries so that they do not prevent large responses from a TCP- | retry truncated UDP responses as necessary. | |||
| capable server from reaching its TCP-capable clients. | ||||
| Regarding the choice of limiting the resources a server devotes to | Furthermore, the requirement in Section 6.1.3.2 of [RFC1123] around | |||
| queries, Section 6.1.3.2 in [RFC1123] also says: | limiting the resources a server devotes to queries is hereby updated: | |||
| "A name server MAY limit the resources it devotes to TCP queries, | OLD: | |||
| A name server MAY limit the resources it devotes to TCP queries, | ||||
| but it SHOULD NOT refuse to service a TCP query just because it | but it SHOULD NOT refuse to service a TCP query just because it | |||
| would have succeeded with UDP." | would have succeeded with UDP. | |||
| This requirement is hereby updated: A name server MAY limit the | NEW: | |||
| resources it devotes to queries, but it MUST NOT refuse to service a | ||||
| query just because it would have succeeded with another transport | A name server MAY limit the resources it devotes to queries, but | |||
| protocol. | it MUST NOT refuse to service a query just because it would have | |||
| succeeded with another transport protocol. | ||||
| Lastly, Section 1 of [RFC1536] is updated to eliminate the | ||||
| misconception that TCP is only useful for zone transfers: | ||||
| OLD: | ||||
| DNS implements the classic request-response scheme of client- | ||||
| server interaction. UDP is, therefore, the chosen protocol for | ||||
| communication though TCP is used for zone transfers. | ||||
| NEW: | ||||
| DNS implements the classic request-response scheme of client- | ||||
| server interaction. | ||||
| Filtering of DNS over TCP is harmful in the general case. DNS | Filtering of DNS over TCP is harmful in the general case. DNS | |||
| resolver and server operators MUST support and provide DNS service | resolver and server operators MUST support and provide DNS service | |||
| over both UDP and TCP transports. Likewise, network operators MUST | over both UDP and TCP transports. Likewise, network operators MUST | |||
| allow DNS service over both UDP and TCP transports. It is | allow DNS service over both UDP and TCP transports. It is | |||
| acknowledged that DNS over TCP service can pose operational | acknowledged that DNS over TCP service can pose operational | |||
| challenges that are not present when running DNS over UDP alone, and | challenges that are not present when running DNS over UDP alone, and | |||
| vice-versa. However, the potential damage incurred by prohibiting | vice-versa. However, the potential damage incurred by prohibiting | |||
| DNS over TCP service is more detrimental to the continued utility and | DNS over TCP service is more detrimental to the continued utility and | |||
| success of the DNS than when its usage is allowed. | success of the DNS than when its usage is allowed. | |||
| 4. Network and System Considerations | 4. Network and System Considerations | |||
| This section describes measures that systems and applications can | This section describes measures that systems and applications can | |||
| take to optimize performance over TCP and to protect themselves from | take to optimize performance over TCP and to protect themselves from | |||
| TCP-based resource exhaustion and attacks. | TCP-based resource exhaustion and attacks. | |||
| 4.1. Connection Establishment and Admission | 4.1. Connection Establishment and Admission | |||
| Resolvers and other DNS clients should be aware that some servers | Resolvers and other DNS clients should be aware that some servers | |||
| might not be reachable over TCP. For this reason, clients MAY want | might not be reachable over TCP. For this reason, clients MAY track | |||
| to track and limit the number of TCP connections and connection | and limit the number of TCP connections and connection attempts to a | |||
| attempts to a single server. Additionally, DNS clients MAY want to | single server. Reachability problems can be caused by network | |||
| enforce a short timeout on unestablished connections, rather than | elements close to the server, close to the client, or anywhere along | |||
| rely on the host operating system's TCP connection timeout, which is | the path between them. Mobile clients that cache connection failures | |||
| often around 60-120 seconds. | MAY do so on a per-network basis, or MAY clear such a cache upon | |||
| change of network. | ||||
| Additionally, DNS clients MAY enforce a short timeout on | ||||
| unestablished connections, rather than rely on the host operating | ||||
| system's TCP connection timeout, which is often around 60-120 seconds | ||||
| (i.e., due to an initial retransmission timeout of 1 second, the | ||||
| exponential back off rules of [RFC6298], and a limit of six retries | ||||
| as is the default in Linux). | ||||
| The SYN flooding attack is a denial-of-service method affecting hosts | The SYN flooding attack is a denial-of-service method affecting hosts | |||
| that run TCP server processes [RFC4987]. This attack can be very | that run TCP server processes [RFC4987]. This attack can be very | |||
| effective if not mitigated. One of the most effective mitigation | effective if not mitigated. One of the most effective mitigation | |||
| techniques is SYN cookies, which allows the server to avoid | techniques is SYN cookies, described in Section 3.6 of [RFC4987], | |||
| allocating any state until the successful completion of the three-way | which allows the server to avoid allocating any state until the | |||
| handshake. | successful completion of the three-way handshake. | |||
| Services not intended for use by the public Internet, such as most | Services not intended for use by the public Internet, such as most | |||
| recursive name servers, SHOULD be protected with access controls. | recursive name servers, SHOULD be protected with access controls. | |||
| Ideally these controls are placed in the network, well before any | Ideally these controls are placed in the network, well before any | |||
| unwanted TCP packets can reach the DNS server host or application. | unwanted TCP packets can reach the DNS server host or application. | |||
| If this is not possible, the controls can be placed in the | If this is not possible, the controls can be placed in the | |||
| application itself. In some situations (e.g. attacks) it may be | application itself. In some situations (e.g. attacks) it may be | |||
| necessary to deploy access controls for DNS services that should | necessary to deploy access controls for DNS services that should | |||
| otherwise be globally reachable. See also [RFC5358]. | otherwise be globally reachable. See also [RFC5358]. | |||
| skipping to change at page 10, line 21 ¶ | skipping to change at page 11, line 47 ¶ | |||
| Per [RFC7766], applications and administrators are advised to | Per [RFC7766], applications and administrators are advised to | |||
| remember that TCP MAY be used before sending any UDP queries. | remember that TCP MAY be used before sending any UDP queries. | |||
| 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. | either use the same TFO server key on all instances, or disable TFO | |||
| for all members of the cluster. | ||||
| DNS clients MAY also enable TFO when possible. Currently, on some | DNS clients MAY also enable TFO. At the time of this writing, on | |||
| operating systems it is not implemented or disabled by default. | some operating systems it is not implemented, or is disabled by | |||
| [WIKIPEDIA_TFO] describes applications and operating systems that | default. [WIKIPEDIA_TFO] describes applications and operating | |||
| support TFO. | systems that support TFO. | |||
| 4.2. Connection Management | 4.2. Connection Management | |||
| Since host memory for TCP state is a finite resource, DNS clients and | Since host memory for TCP state is a finite resource, DNS clients and | |||
| servers MUST actively manage their connections. Applications that do | servers SHOULD actively manage their connections. Applications that | |||
| not actively manage their connections can encounter resource | do not actively manage their connections can encounter resource | |||
| exhaustion leading to denial of service. For DNS, as in other | exhaustion leading to denial of service. For DNS, as in other | |||
| protocols, there is a tradeoff between keeping connections open for | protocols, there is a tradeoff between keeping connections open for | |||
| potential future use and the need to free up resources for new | potential future use and the need to free up resources for new | |||
| connections that will arrive. | connections that will arrive. | |||
| DNS server software SHOULD provide a configurable limit on the total | Operators of DNS server software SHOULD be aware that operating | |||
| number of established TCP connections. If the limit is reached, the | system and application vendors MAY impose a limit on the total number | |||
| application is expected to either close existing (idle) connections | of established connections. These limits may be designed to protect | |||
| or refuse new connections. Operators SHOULD ensure the limit is | against DDoS attacks or performance degradation. Operators SHOULD | |||
| configured appropriately for their particular situation. | understand how to increase these limits if necessary, and the | |||
| consequences of doing so. Limits imposed by the application SHOULD | ||||
| be lower than limits imposed by the operating system, so that the | ||||
| application can apply its own policy to connection management, such | ||||
| as closing the oldest idle connections first. | ||||
| DNS server software MAY provide a configurable limit on the number of | DNS server software MAY provide a configurable limit on the number of | |||
| established connections per source IP address or subnet. This can be | established connections per source IP address or subnet. This can be | |||
| used to ensure that a single or small set of users cannot consume all | used to ensure that a single or small set of users cannot consume all | |||
| TCP resources and deny service to other users. Operators SHOULD | TCP resources and deny service to other users. Note, however, that | |||
| ensure this limit is configured appropriately, based on their number | if this limit is enabled, it possibly limits client performance while | |||
| of diversity of users. | leaving some TCP resources unutilized. Operators SHOULD be aware of | |||
| these tradeoffs and ensure this limit, if configured, is set | ||||
| appropriately based on the number and diversity of their users, and | ||||
| whether users connect from unique IP addresses or through a shared | ||||
| Network Address Translator [RFC3022]. | ||||
| DNS server software SHOULD provide a configurable timeout for idle | DNS server software SHOULD provide a configurable timeout for idle | |||
| TCP connections. For very busy name servers this might be set to a | TCP connections. This can be used to free up resources for new | |||
| low value, such as a few seconds. For less busy servers it might be | connections and to ensure that idle connections are eventually | |||
| set to a higher value, such as tens of seconds. DNS clients and | closed. At the same time, it possibly limits client performance | |||
| servers SHOULD signal their timeout values using the edns-tcp- | while leaving some TCP resources unutilized. For very busy name | |||
| keepalive option [RFC7828]. | servers this might be set to a low value, such as a few seconds. For | |||
| less busy servers it might be set to a higher value, such as tens of | ||||
| seconds. DNS clients and servers SHOULD signal their timeout values | ||||
| using the edns-tcp-keepalive option [RFC7828]. | ||||
| DNS server software MAY provide a configurable limit on the number of | DNS server software MAY provide a configurable limit on the number of | |||
| transactions per TCP connection. This document does not offer advice | transactions per TCP connection. This can help protect against | |||
| on particular values for such a limit. | unfair connection use (e.g., not releasing connection slots to other | |||
| clients) and network evasion attacks. | ||||
| Similarly, DNS server software MAY provide a configurable limit on | Similarly, DNS server software MAY provide a configurable limit on | |||
| the total duration of a TCP connection. This document does not offer | the total duration of a TCP connection. This can help protect | |||
| advice on particular values for such a limit. | against unfair connection use, slow read attacks, and network evasion | |||
| attacks. | ||||
| Since clients may not be aware of server-imposed limits, clients | Since clients may not be aware of server-imposed limits, clients | |||
| utilizing TCP for DNS need to always be prepared to re-establish | utilizing TCP for DNS need to always be prepared to re-establish | |||
| connections or otherwise retry outstanding queries. | connections or otherwise retry outstanding queries. | |||
| 4.3. Connection Termination | 4.3. Connection Termination | |||
| The TCP peer that initiates a connection close retains the socket in | The TCP peer that initiates a connection close retains the socket in | |||
| the TIME_WAIT state for some amount of time, possibly a few minutes. | the TIME_WAIT state for some amount of time, possibly a few minutes. | |||
| It is generally preferable for clients to initiate the close of a TCP | It is generally preferable for clients to initiate the close of a TCP | |||
| connection so that busy servers do not accumulate many sockets in the | connection so that busy servers do not accumulate many sockets in the | |||
| TIME_WAIT state, which can cause performance problems or even denial | TIME_WAIT state, which can cause performance problems or even denial | |||
| of service. The edns-tcp-keepalive EDNS(0) option [RFC7828] can be | of service. The edns-tcp-keepalive EDNS(0) option [RFC7828] can be | |||
| used to encourage clients to close connections. | used to encourage clients to close connections. | |||
| On systems where large numbers of sockets in TIME_WAIT are observed | On systems where large numbers of sockets in TIME_WAIT are observed | |||
| (either as client or server), it may be beneficial to tune the local | (either as client or server), and are affecting an application's | |||
| TCP parameters. For example, the Linux kernel provides a number of | performance, it may be tempting to tune local TCP parameters. For | |||
| "sysctl" parameters related to TIME_WAIT, such as | example, the Linux kernel has a "sysctl" parameter named | |||
| net.ipv4.tcp_fin_timeout and net.ipv4.tcp_tw_reuse. In extreme | net.ipv4.tcp_tw_reuse which allows connections in the TIME_WAIT state | |||
| cases, implementors and operators of very busy servers may find it | to be reused in specific circumstances. Note, however, this affects | |||
| necessary to utilize the SO_LINGER socket option ([Stevens] | only outgoing (client) connections and has no impact on servers. In | |||
| Section 7.5) with a value of zero so that the server doesn't | most cases it is NOT RECOMMENDED to change parameters related to the | |||
| accumulate TIME_WAIT sockets. | TIME_WAIT state. It should only be done by those with detailed | |||
| knowledge of both TCP and the affected application. | ||||
| 4.4. DNS-over-TLS | 4.4. 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 DNS-over-TLS utilizes TCP port | describing how this works. Although DNS-over-TLS utilizes TCP port | |||
| 853 instead of port 53, this document applies equally well to DNS- | 853 instead of port 53, this document applies equally well to DNS- | |||
| over-TLS. Note, however, DNS-over-TLS is currently only defined | over-TLS. Note, however, DNS-over-TLS is only defined between stubs | |||
| between stubs and recursives. | and recursives at the time of this writing. | |||
| The use of TLS places even stronger operational burdens on DNS | The use of TLS places even stronger operational burdens on DNS | |||
| clients and servers. Cryptographic functions for authentication and | clients and servers. Cryptographic functions for authentication and | |||
| encryption requires additional processing. Unoptimized connection | encryption require additional processing. Unoptimized connection | |||
| setup takes two additional round-trips compared to TCP, but can be | setup with TLS 1.3 [RFC8446] takes one additional round-trip compared | |||
| reduced with TLS session resumption [RFC8446] and TLS False Start | to TCP. Connection setup times can be reduced with TCP Fast Open, | |||
| [RFC7918]. | and TLS False Start [RFC7918] for TLS 1.2. TLS 1.3 session | |||
| resumption does not reduce round-trip latency because no application | ||||
| profile for use of TLS 0-RTT data with DNS has been published at the | ||||
| time of this writing. However, TLS session resumption can reduce the | ||||
| number of cryptographic operations, and in TLS 1.2, session | ||||
| resumption does reduce the number of additional round trips from two | ||||
| to one. | ||||
| 4.5. Defaults and Recommended Limits | ||||
| A survey of features and defaults was conducted for popular open | ||||
| source DNS server implementations at the time of writing. This | ||||
| section documents those defaults and makes recommendations for | ||||
| configurable limits that can be used in the absence of any other | ||||
| information. Any recommended values in this document are only | ||||
| intended as a starting point for administrators that are unsure what | ||||
| sorts of limits might be reasonable. Operators SHOULD use | ||||
| application-specific monitoring, system logs, and system monitoring | ||||
| tools to gauge whether their service is operating within or exceeding | ||||
| these limits, and adjust accordingly. | ||||
| Most open source DNS server implementations provide a configurable | ||||
| limit on the total number of established connections. Default values | ||||
| range from 20 to 150. In most cases, where the majority of queries | ||||
| take place over UDP, 150 is a reasonable limit. For services or | ||||
| environments where most queries take place over TCP or TLS, 5000 is a | ||||
| more appropriate limit. | ||||
| Only some open source implementations provide a way to limit the | ||||
| number of connections per source IP address or subnet, but the | ||||
| default is to have no limit. For environments or situations where it | ||||
| may be necessary to enable this limit, 25 connections per source IP | ||||
| address is a reasonable starting point. The limit should be | ||||
| increased when aggregated by subnet, or for services where most | ||||
| queries take place over TCP or TLS. | ||||
| Most open source implementations provide a configurable idle timeout | ||||
| on connections. Default values range from 2 to 30 seconds. In most | ||||
| cases, 10 seconds is a reasonable default for this limit. Longer | ||||
| timeouts improve connection reuse, but busy servers may need to use a | ||||
| lower limit. | ||||
| Only some open source implementations provide a way to limit the | ||||
| number of transactions per connection, but the default is to have no | ||||
| limit. This document does not offer advice on particular values for | ||||
| such a limit. | ||||
| Only some open source implementations provide a way to limit the | ||||
| duration of connection, but the default is to have no limit. This | ||||
| document does not offer advice on particular values for such a limit. | ||||
| 5. DNS over TCP Filtering Risks | 5. DNS over TCP Filtering Risks | |||
| Networks that filter DNS over TCP risk losing access to significant | Networks that filter DNS over TCP risk losing access to significant | |||
| or important pieces of the DNS namespace. For a variety of reasons a | or important pieces of the DNS namespace. For a variety of reasons a | |||
| DNS answer may require a DNS over TCP query. This may include large | DNS answer may require a DNS over TCP query. This may include large | |||
| message sizes, lack of EDNS(0) support, DDoS mitigation techniques | message sizes, lack of EDNS(0) support, DDoS mitigation techniques | |||
| (including [RRL]), or perhaps some future capability that is as yet | (including [RRL]), or perhaps some future capability that is as yet | |||
| unforeseen will also demand TCP transport. | unforeseen will also demand TCP transport. | |||
| skipping to change at page 12, line 34 ¶ | skipping to change at page 15, line 31 ¶ | |||
| The specification mandates the use of TCP or DNS Cookies [RFC7873]. | The specification mandates the use of TCP or DNS Cookies [RFC7873]. | |||
| Even if any or all particular answers have consistently been returned | Even if any or all particular answers have consistently been returned | |||
| successfully with UDP in the past, this continued behavior cannot be | successfully with UDP in the past, this continued behavior cannot be | |||
| guaranteed when DNS messages are exchanged between autonomous | guaranteed when DNS messages are exchanged between autonomous | |||
| systems. Therefore, filtering of DNS over TCP is considered harmful | systems. Therefore, filtering of DNS over TCP is considered harmful | |||
| and contrary to the safe and successful operation of the Internet. | and contrary to the safe and successful operation of the Internet. | |||
| This section enumerates some of the known risks at the time of this | This section enumerates some of the known risks at the time of this | |||
| writing when networks filter DNS over TCP. | writing when networks filter DNS over TCP. | |||
| 5.1. DNS Wedgie | 5.1. Truncation, Retries, and Timeouts | |||
| 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]. For example, a | for third-party resolvers as experienced by [TOYAMA]. For example, a | |||
| resolver receives queries for a moderately popular domain. The | resolver receives queries for a moderately popular domain. The | |||
| resolver forwards the queries to the domain's authoritative name | resolver forwards the queries to the domain's authoritative name | |||
| servers, but those servers respond with the TC bit set. The resolver | servers, but those servers respond with the TC bit set. The resolver | |||
| retries over TCP, but the authoritative server blocks DNS over TCP. | retries over TCP, but the authoritative server blocks DNS over TCP. | |||
| The pending connections consume resources on the resolver until they | The pending connections consume resources on the resolver until they | |||
| time out. If the number and frequency of these truncated-and-then- | time out. If the number and frequency of these truncated-and-then- | |||
| blocked queries is sufficiently high, the steady-state of lost | blocked queries is sufficiently high, the resolver wastes valuable | |||
| resources as a result is a "DNS wedgie." A DNS wedgie is generally | resources on queries that can never be answered. This condition is | |||
| not easily or completely mitigated by the affected DNS resolver | generally not easily or completely mitigated by the affected DNS | |||
| operator. | resolver operator. | |||
| 5.2. DNS Root Zone KSK Rollover | 5.2. DNS Root Zone KSK Rollover | |||
| The plans for deploying a new root zone DNSSEC KSK highlighted a | The plans for deploying a new root zone DNSSEC KSK highlighted a | |||
| potential problem in retrieving the root zone key set [LEWIS]. | potential problem in retrieving the root zone key set [LEWIS]. | |||
| During some phases of the KSK rollover process, root zone DNSKEY | During some phases of the KSK rollover process, root zone DNSKEY | |||
| responses were larger than 1280 bytes, the IPv6 minimum MTU for links | responses were larger than 1280 bytes, the IPv6 minimum MTU for links | |||
| carrying IPv6 traffic [RFC8200]. There was some concern | carrying IPv6 traffic [RFC8200]. There was some concern | |||
| [KSK_ROLLOVER_ARCHIVES] that any DNS server unable to receive large | [KSK_ROLLOVER_ARCHIVES] that any DNS server unable to receive large | |||
| DNS messages over UDP, or any DNS message over TCP, would experience | DNS messages over UDP, or any DNS message over TCP, would experience | |||
| disruption while performing DNSSEC validation. | disruption while performing DNSSEC validation. | |||
| However, during the year-long postponement of the KSK rollover there | However, during the year-long postponement of the KSK rollover there | |||
| were no reported problems that could be attributed to the 1414 octet | were no reported problems that could be attributed to the 1414 octet | |||
| DNSKEY response when both the old and new keys were published in the | DNSKEY response when both the old and new keys were published in the | |||
| zone. Additionally, there were no reported problems during the two | zone. Additionally, there were no reported problems during the two- | |||
| month period when the old key was published as revoked and the DNSKEY | month period when the old key was published as revoked and the DNSKEY | |||
| response was 1425 octets in size [ROLL_YOUR_ROOT]. | response was 1425 octets in size [ROLL_YOUR_ROOT]. | |||
| 6. Logging and Monitoring | 6. Logging and Monitoring | |||
| Developers of applications that log or monitor DNS SHOULD NOT ignore | Developers of applications that log or monitor DNS SHOULD NOT ignore | |||
| TCP due to the perception that it is rarely used or is hard to | TCP due to the perception that it is rarely used or is hard to | |||
| process. Operators SHOULD ensure that their monitoring and logging | process. Operators SHOULD ensure that their monitoring and logging | |||
| applications properly capture DNS messages over TCP. Otherwise, | applications properly capture DNS messages over TCP. Otherwise, | |||
| attacks, exfiltration attempts, and normal traffic may go undetected. | attacks, exfiltration attempts, and normal traffic may go 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 might attempt to hide certain | segments. In fact, a clever attacker might 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 [libpcap]) SHOULD be | that capture network packets (e.g., with libpcap [libpcap]) SHOULD | |||
| prepared to implement and perform full TCP segment reassembly. | implement and perform full TCP stream reassembly and analyze the | |||
| dnscap [dnscap] is an open-source example of a DNS logging program | reassembled stream instead of the individual packets. Otherwise, | |||
| that implements TCP reassembly. | they are vulnerable to network evasion attacks [phrack]. | |||
| Furthermore, such applications need to protect themselves from | ||||
| resource exhaustion attacks by limiting the amount of memory | ||||
| allocated to tracking unacknowledged connection state data. dnscap | ||||
| [dnscap] is an open-source example of a DNS logging program that | ||||
| implements TCP stream reassembly. | ||||
| Developers SHOULD also keep in mind connection reuse, query | Developers SHOULD also keep in mind connection reuse, query | |||
| pipelining, and out-of-order responses when building and testing DNS | pipelining, and out-of-order responses when building and testing DNS | |||
| monitoring applications. | monitoring applications. | |||
| As an alternative to packet capture, some DNS server software | As an alternative to packet capture, some DNS server software | |||
| supports dnstap [dnstap] as an integrated monitoring protocol | supports dnstap [dnstap] as an integrated monitoring protocol | |||
| intended to facilitate wide-scale DNS monitoring. | intended to facilitate wide-scale DNS monitoring. | |||
| 7. Acknowledgments | 7. IANA Considerations | |||
| This document was initially motivated by feedback from students who | ||||
| pointed out that they were hearing contradictory information about | ||||
| filtering DNS over TCP messages. Thanks in particular to a teaching | ||||
| colleague, JPL, who perhaps unknowingly encouraged the initial | ||||
| research into the differences between what the community has | ||||
| historically said and did. Thanks to all the NANOG 63 attendees who | ||||
| provided feedback to an early talk on this subject. | ||||
| The following individuals provided an array of feedback to help | ||||
| improve this document: Piet Barber, Sara Dickinson, Tony Finch, Bob | ||||
| Harold, Tatuya Jinmei, Paul Hoffman, Puneet Sood, and Richard | ||||
| Wilhelm. The authors are also indebted to the contributions stemming | ||||
| from discussion in the tcpm working group meeting at IETF 104. Any | ||||
| remaining errors or imperfections are the sole responsibility of the | ||||
| document authors. | ||||
| 8. IANA Considerations | ||||
| This memo includes no request to IANA. | This memo includes no request to IANA. | |||
| 9. Security Considerations | 8. Security Considerations | |||
| This document, providing operational requirements, is the companion | ||||
| to the implementation requirements of DNS over TCP, provided in | ||||
| [RFC7766]. The security considerations from [RFC7766] still apply. | ||||
| 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 | |||
| [RRL]. Historically, operators have been wary of TCP-based attacks, | [RRL]. Historically, operators have been wary of TCP-based attacks, | |||
| but in recent years, UDP-based flooding attacks have proven to be the | but in recent years, UDP-based flooding attacks have proven to be the | |||
| most common protocol attack on the DNS. Nevertheless, a high rate of | most common protocol attack on the DNS. Nevertheless, a high rate of | |||
| short-lived DNS transactions over TCP may pose challenges. In fact, | short-lived DNS transactions over TCP may pose challenges. In fact, | |||
| [DAI21] details a class of IP fragmenetation attacks on DNS | [DAI21] details a class of IP fragmentation attacks on DNS | |||
| transactions if the IP ID field can be predicted and a system is | transactions if the IP Identifier field (16 bits in IPv4 and 32 bits | |||
| coerced to fragment rather than retransmit messages. While many | in IPv6) can be predicted and a system is coerced to fragment rather | |||
| operators have provided DNS over TCP service for many years without | than retransmit messages. While many operators have provided DNS | |||
| duress, past experience is no guarantee of future success. | over TCP service for many years without duress, past experience is no | |||
| guarantee of future success. | ||||
| DNS over TCP is similar to many other Internet TCP services. TCP | DNS over TCP is similar to 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 | As mentioned in Section 6, applications that implement TCP stream | |||
| reassembly need to limit the amount of memory allocated to connection | ||||
| tracking. A failure to do so could lead to a total failure of the | ||||
| logging or monitoring application. Imposition of resource limits | ||||
| creates a tradeoff between allowing some stream reassembly to | ||||
| continue and allowing some evasion attacks to succeed. | ||||
| Since DNS over both UDP and TCP use the same underlying message | This document recommends that DNS Servers enable TFO when possible. | |||
| [RFC7413] recommends that a pool of servers behind a load balancer | ||||
| with shared server IP address also share the key used to generate | ||||
| Fast Open cookies, to prevent inordinate fallback to the 3WHS. This | ||||
| guidance remains accurate, but comes with a caveat: compromise of one | ||||
| server would reveal this group-shared key, and allow for attacks | ||||
| involving the other servers in the pool by forging invalid Fast Open | ||||
| cookies. | ||||
| 9. Privacy Considerations | ||||
| Since DNS over both UDP and TCP uses the same underlying message | ||||
| format, the use of one transport instead of the other does not change | format, the use of one transport instead of the other does not change | |||
| the privacy characteristics of the message content (i.e., the name | the privacy characteristics of the message content (i.e., the name | |||
| being queried). DNS over TLS or DTLS is the recommended way to | being queried). A number of protocols have recently been developed | |||
| achieve DNS privacy. | to provide DNS privacy, including DNS over TLS [RFC7858], DNS over | |||
| DTLS [RFC8094], DNS over HTTPS [RFC8484], with even more on the way. | ||||
| Because TCP is somewhat more complex than UDP, some characteristics | Because TCP is somewhat more complex than UDP, some characteristics | |||
| of a TCP conversation may enable fingerprinting and tracking that is | of a TCP conversation may enable DNS client fingerprinting and | |||
| not possible with UDP. For example, the choice of initial sequence | tracking that is not possible with UDP. For example, the choice of | |||
| numbers, window size, and options might be able to identify a | initial sequence numbers, window size, and options might be able to | |||
| particular TCP implementation, or even individual hosts behind shared | identify a particular TCP implementation, or even individual hosts | |||
| resources such as network address translators (NATs). | behind shared resources such as network address translators (NATs). | |||
| 10. Acknowledgments | ||||
| This document was initially motivated by feedback from students who | ||||
| pointed out that they were hearing contradictory information about | ||||
| filtering DNS over TCP messages. Thanks in particular to a teaching | ||||
| colleague, JPL, who perhaps unknowingly encouraged the initial | ||||
| research into the differences between what the community has | ||||
| historically said and did. Thanks to all the NANOG 63 attendees who | ||||
| provided feedback to an early talk on this subject. | ||||
| The following individuals provided an array of feedback to help | ||||
| improve this document: Joe Abley, Piet Barber, Sara Dickinson, Tony | ||||
| Finch, Bob Harold, Paul Hoffman, Geoff Huston, Tatuya Jinmei, Puneet | ||||
| Sood, and Richard Wilhelm. The authors are also indebted to the | ||||
| contributions stemming from discussion in the tcpm working group | ||||
| meeting at IETF 104. Any remaining errors or imperfections are the | ||||
| sole responsibility of the document authors. | ||||
| 11. References | 11. References | |||
| 11.1. Normative References | 11.1. Normative References | |||
| [RFC1035] Mockapetris, P., "Domain names - implementation and | [RFC1035] Mockapetris, P., "Domain names - implementation and | |||
| specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | |||
| November 1987, <https://www.rfc-editor.org/info/rfc1035>. | November 1987, <https://www.rfc-editor.org/info/rfc1035>. | |||
| [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, | ||||
| DOI 10.17487/RFC1995, August 1996, | ||||
| <https://www.rfc-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, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS | [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS | |||
| Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, | Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, | |||
| <https://www.rfc-editor.org/info/rfc2181>. | <https://www.rfc-editor.org/info/rfc2181>. | |||
| [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", | ||||
| BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, | ||||
| <https://www.rfc-editor.org/info/rfc5625>. | ||||
| [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol | ||||
| (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, | ||||
| <https://www.rfc-editor.org/info/rfc5936>. | ||||
| [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, | ||||
| DOI 10.17487/RFC6762, February 2013, | ||||
| <https://www.rfc-editor.org/info/rfc6762>. | ||||
| [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, | DOI 10.17487/RFC6891, April 2013, | |||
| <https://www.rfc-editor.org/info/rfc6891>. | <https://www.rfc-editor.org/info/rfc6891>. | |||
| [RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS", | ||||
| RFC 7477, DOI 10.17487/RFC7477, March 2015, | ||||
| <https://www.rfc-editor.org/info/rfc7477>. | ||||
| [RFC7720] Blanchet, M. and L-J. Liman, "DNS Root Name Service | ||||
| Protocol and Deployment Requirements", BCP 40, RFC 7720, | ||||
| DOI 10.17487/RFC7720, December 2015, | ||||
| <https://www.rfc-editor.org/info/rfc7720>. | ||||
| [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and | [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and | |||
| D. Wessels, "DNS Transport over TCP - Implementation | D. Wessels, "DNS Transport over TCP - Implementation | |||
| Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, | Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, | |||
| <https://www.rfc-editor.org/info/rfc7766>. | <https://www.rfc-editor.org/info/rfc7766>. | |||
| [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The | [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The | |||
| edns-tcp-keepalive EDNS0 Option", RFC 7828, | edns-tcp-keepalive EDNS0 Option", RFC 7828, | |||
| DOI 10.17487/RFC7828, April 2016, | DOI 10.17487/RFC7828, April 2016, | |||
| <https://www.rfc-editor.org/info/rfc7828>. | <https://www.rfc-editor.org/info/rfc7828>. | |||
| [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) | [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) | |||
| Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, | Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, | |||
| <https://www.rfc-editor.org/info/rfc7873>. | <https://www.rfc-editor.org/info/rfc7873>. | |||
| [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>. | |||
| [RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, | ||||
| "Providing Minimal-Sized Responses to DNS Queries That | ||||
| Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January | ||||
| 2019, <https://www.rfc-editor.org/info/rfc8482>. | ||||
| [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., | ||||
| Lemon, T., and T. Pusateri, "DNS Stateful Operations", | ||||
| RFC 8490, DOI 10.17487/RFC8490, March 2019, | ||||
| <https://www.rfc-editor.org/info/rfc8490>. | ||||
| 11.2. Informative References | 11.2. Informative References | |||
| [accept_filter] | [accept_filter] | |||
| FreeBSD, "FreeBSD accept_filter(9)", 7 May 2018, | FreeBSD, "FreeBSD accept_filter(9)", 7 May 2018, | |||
| <https://www.freebsd.org/cgi/man.cgi?query=accept_filter>. | <https://www.freebsd.org/cgi/man.cgi?query=accept_filter>. | |||
| [APNIC] Huston, G., "DNS XL", October 2020, | ||||
| <https://labs.apnic.net/?p=1380>. | ||||
| [AVOID_FRAGS] | [AVOID_FRAGS] | |||
| Fujiwara, K. and P. Vixie, "Fragmentation Avoidance in | Fujiwara, K. and P. Vixie, "Fragmentation Avoidance in | |||
| DNS", Work in Progress, draft-ietf-dnsop-avoid- | DNS", Work in Progress, draft-ietf-dnsop-avoid- | |||
| fragmentation-04, February 2021. | fragmentation-05, February 2021. | |||
| [BIND] Internet Systems Consortium, "BIND 9 - ISC", April 2021, | [BIND] Internet Systems Consortium, "BIND 9 - ISC", April 2021, | |||
| <https://www.isc.org/bind/>. | <https://www.isc.org/bind/>. | |||
| [CASTRO2010] | [CASTRO2010] | |||
| Castro, S., Zhang, M., John, W., Wessels, D., and k.c. | Castro, S., Zhang, M., John, W., Wessels, D., and k.c. | |||
| claffy, "Understanding and preparing for DNS evolution", | claffy, "Understanding and preparing for DNS evolution", | |||
| 2010. | 2010. | |||
| [CHES94] Cheswick, W.R. and S.M. Bellovin, "Firewalls and Internet | [CHES94] Cheswick, W.R. and S.M. Bellovin, "Firewalls and Internet | |||
| skipping to change at page 18, line 34 ¶ | skipping to change at page 21, line 15 ¶ | |||
| [LEWIS] Lewis, E., "2017 DNSSEC KSK Rollover", RIPE 74 Budapest, | [LEWIS] Lewis, E., "2017 DNSSEC KSK Rollover", RIPE 74 Budapest, | |||
| Hungary, 8 May 2017, <https://ripe74.ripe.net/ | Hungary, 8 May 2017, <https://ripe74.ripe.net/ | |||
| presentations/25-RIPE74-lewis-submission.pdf>. | presentations/25-RIPE74-lewis-submission.pdf>. | |||
| [libpcap] Tcpdump/Libpcap, "Tcpdump and Libpcap", 7 May 2018, | [libpcap] Tcpdump/Libpcap, "Tcpdump and Libpcap", 7 May 2018, | |||
| <https://www.tcpdump.org>. | <https://www.tcpdump.org>. | |||
| [NETALYZR] Kreibich, C., Weaver, N., Nechaev, B., and V. Paxson, | [NETALYZR] Kreibich, C., Weaver, N., Nechaev, B., and V. Paxson, | |||
| "Netalyzr: Illuminating The Edge Network", 2010. | "Netalyzr: Illuminating The Edge Network", 2010. | |||
| [phrack] horizon, "Defeating Sniffers and Intrusion Detection | ||||
| Systems", December 1998, | ||||
| <http://phrack.org/issues/54/10.html>. | ||||
| [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | |||
| DOI 10.17487/RFC0768, August 1980, | DOI 10.17487/RFC0768, August 1980, | |||
| <https://www.rfc-editor.org/info/rfc768>. | <https://www.rfc-editor.org/info/rfc768>. | |||
| [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | |||
| RFC 793, DOI 10.17487/RFC0793, September 1981, | RFC 793, DOI 10.17487/RFC0793, September 1981, | |||
| <https://www.rfc-editor.org/info/rfc793>. | <https://www.rfc-editor.org/info/rfc793>. | |||
| [RFC0883] Mockapetris, P., "Domain names: Implementation | ||||
| specification", RFC 883, DOI 10.17487/RFC0883, November | ||||
| 1983, <https://www.rfc-editor.org/info/rfc883>. | ||||
| [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | |||
| STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | |||
| <https://www.rfc-editor.org/info/rfc1034>. | <https://www.rfc-editor.org/info/rfc1034>. | |||
| [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - | [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - | |||
| Application and Support", STD 3, RFC 1123, | Application and Support", STD 3, RFC 1123, | |||
| DOI 10.17487/RFC1123, October 1989, | DOI 10.17487/RFC1123, October 1989, | |||
| <https://www.rfc-editor.org/info/rfc1123>. | <https://www.rfc-editor.org/info/rfc1123>. | |||
| [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. | [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. | |||
| Miller, "Common DNS Implementation Errors and Suggested | Miller, "Common DNS Implementation Errors and Suggested | |||
| Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993, | Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993, | |||
| <https://www.rfc-editor.org/info/rfc1536>. | <https://www.rfc-editor.org/info/rfc1536>. | |||
| [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, | ||||
| DOI 10.17487/RFC1995, August 1996, | ||||
| <https://www.rfc-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>. | ||||
| [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, | [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, | |||
| "Dynamic Updates in the Domain Name System (DNS UPDATE)", | "Dynamic Updates in the Domain Name System (DNS UPDATE)", | |||
| RFC 2136, DOI 10.17487/RFC2136, April 1997, | RFC 2136, DOI 10.17487/RFC2136, April 1997, | |||
| <https://www.rfc-editor.org/info/rfc2136>. | <https://www.rfc-editor.org/info/rfc2136>. | |||
| [RFC2541] Eastlake 3rd, D., "DNS Security Operational | [RFC2541] Eastlake 3rd, D., "DNS Security Operational | |||
| Considerations", RFC 2541, DOI 10.17487/RFC2541, March | Considerations", RFC 2541, DOI 10.17487/RFC2541, March | |||
| 1999, <https://www.rfc-editor.org/info/rfc2541>. | 1999, <https://www.rfc-editor.org/info/rfc2541>. | |||
| [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", | [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", | |||
| RFC 2671, DOI 10.17487/RFC2671, August 1999, | RFC 2671, DOI 10.17487/RFC2671, August 1999, | |||
| <https://www.rfc-editor.org/info/rfc2671>. | <https://www.rfc-editor.org/info/rfc2671>. | |||
| [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. | [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. | |||
| Heffernan, "DNS extensions to Network Address Translators | Heffernan, "DNS extensions to Network Address Translators | |||
| (DNS_ALG)", RFC 2694, DOI 10.17487/RFC2694, September | (DNS_ALG)", RFC 2694, DOI 10.17487/RFC2694, September | |||
| 1999, <https://www.rfc-editor.org/info/rfc2694>. | 1999, <https://www.rfc-editor.org/info/rfc2694>. | |||
| [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network | ||||
| Address Translator (Traditional NAT)", RFC 3022, | ||||
| DOI 10.17487/RFC3022, January 2001, | ||||
| <https://www.rfc-editor.org/info/rfc3022>. | ||||
| [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", | [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", | |||
| RFC 3225, DOI 10.17487/RFC3225, December 2001, | RFC 3225, DOI 10.17487/RFC3225, December 2001, | |||
| <https://www.rfc-editor.org/info/rfc3225>. | <https://www.rfc-editor.org/info/rfc3225>. | |||
| [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver | [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver | |||
| message size requirements", RFC 3226, | message size requirements", RFC 3226, | |||
| DOI 10.17487/RFC3226, December 2001, | DOI 10.17487/RFC3226, December 2001, | |||
| <https://www.rfc-editor.org/info/rfc3226>. | <https://www.rfc-editor.org/info/rfc3226>. | |||
| [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational | [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational | |||
| skipping to change at page 20, line 20 ¶ | skipping to change at page 23, line 20 ¶ | |||
| [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More | [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More | |||
| Resilient against Forged Answers", RFC 5452, | Resilient against Forged Answers", RFC 5452, | |||
| DOI 10.17487/RFC5452, January 2009, | DOI 10.17487/RFC5452, January 2009, | |||
| <https://www.rfc-editor.org/info/rfc5452>. | <https://www.rfc-editor.org/info/rfc5452>. | |||
| [RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, | [RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, | |||
| Ed., "Design Choices When Expanding the DNS", RFC 5507, | Ed., "Design Choices When Expanding the DNS", RFC 5507, | |||
| DOI 10.17487/RFC5507, April 2009, | DOI 10.17487/RFC5507, April 2009, | |||
| <https://www.rfc-editor.org/info/rfc5507>. | <https://www.rfc-editor.org/info/rfc5507>. | |||
| [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", | ||||
| BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, | ||||
| <https://www.rfc-editor.org/info/rfc5625>. | ||||
| [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, | [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, | |||
| DOI 10.17487/RFC5927, July 2010, | DOI 10.17487/RFC5927, July 2010, | |||
| <https://www.rfc-editor.org/info/rfc5927>. | <https://www.rfc-editor.org/info/rfc5927>. | |||
| [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol | ||||
| (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, | ||||
| <https://www.rfc-editor.org/info/rfc5936>. | ||||
| [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's | [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's | |||
| Robustness to Blind In-Window Attacks", RFC 5961, | Robustness to Blind In-Window Attacks", RFC 5961, | |||
| DOI 10.17487/RFC5961, August 2010, | DOI 10.17487/RFC5961, August 2010, | |||
| <https://www.rfc-editor.org/info/rfc5961>. | <https://www.rfc-editor.org/info/rfc5961>. | |||
| [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation | ||||
| Requirements", RFC 5966, DOI 10.17487/RFC5966, August | ||||
| 2010, <https://www.rfc-editor.org/info/rfc5966>. | ||||
| [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, | ||||
| "Computing TCP's Retransmission Timer", RFC 6298, | ||||
| DOI 10.17487/RFC6298, June 2011, | ||||
| <https://www.rfc-editor.org/info/rfc6298>. | ||||
| [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, | ||||
| DOI 10.17487/RFC6762, February 2013, | ||||
| <https://www.rfc-editor.org/info/rfc6762>. | ||||
| [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, | [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, | |||
| "Architectural Considerations on Application Features in | "Architectural Considerations on Application Features in | |||
| the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, | the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, | |||
| <https://www.rfc-editor.org/info/rfc6950>. | <https://www.rfc-editor.org/info/rfc6950>. | |||
| [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP | [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP | |||
| Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, | Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, | |||
| <https://www.rfc-editor.org/info/rfc7413>. | <https://www.rfc-editor.org/info/rfc7413>. | |||
| [RFC7477] Hardaker, W., "Child-to-Parent Synchronization in DNS", | ||||
| RFC 7477, DOI 10.17487/RFC7477, March 2015, | ||||
| <https://www.rfc-editor.org/info/rfc7477>. | ||||
| [RFC7534] Abley, J. and W. Sotomayor, "AS112 Nameserver Operations", | [RFC7534] Abley, J. and W. Sotomayor, "AS112 Nameserver Operations", | |||
| RFC 7534, DOI 10.17487/RFC7534, May 2015, | RFC 7534, DOI 10.17487/RFC7534, May 2015, | |||
| <https://www.rfc-editor.org/info/rfc7534>. | <https://www.rfc-editor.org/info/rfc7534>. | |||
| [RFC7720] Blanchet, M. and L-J. Liman, "DNS Root Name Service | ||||
| Protocol and Deployment Requirements", BCP 40, RFC 7720, | ||||
| DOI 10.17487/RFC7720, December 2015, | ||||
| <https://www.rfc-editor.org/info/rfc7720>. | ||||
| [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>. | |||
| [RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, | [RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, | |||
| DOI 10.17487/RFC7901, June 2016, | DOI 10.17487/RFC7901, June 2016, | |||
| <https://www.rfc-editor.org/info/rfc7901>. | <https://www.rfc-editor.org/info/rfc7901>. | |||
| [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport | [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport | |||
| skipping to change at page 21, line 43 ¶ | skipping to change at page 25, line 28 ¶ | |||
| February 2018, <https://www.rfc-editor.org/info/rfc8324>. | February 2018, <https://www.rfc-editor.org/info/rfc8324>. | |||
| [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
| Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
| <https://www.rfc-editor.org/info/rfc8446>. | <https://www.rfc-editor.org/info/rfc8446>. | |||
| [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms | [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms | |||
| for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, | for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, | |||
| October 2018, <https://www.rfc-editor.org/info/rfc8467>. | October 2018, <https://www.rfc-editor.org/info/rfc8467>. | |||
| [RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, | ||||
| "Providing Minimal-Sized Responses to DNS Queries That | ||||
| Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January | ||||
| 2019, <https://www.rfc-editor.org/info/rfc8482>. | ||||
| [RFC8483] Song, L., Ed., Liu, D., Vixie, P., Kato, A., and S. Kerr, | [RFC8483] Song, L., Ed., Liu, D., Vixie, P., Kato, A., and S. Kerr, | |||
| "Yeti DNS Testbed", RFC 8483, DOI 10.17487/RFC8483, | "Yeti DNS Testbed", RFC 8483, DOI 10.17487/RFC8483, | |||
| October 2018, <https://www.rfc-editor.org/info/rfc8483>. | October 2018, <https://www.rfc-editor.org/info/rfc8483>. | |||
| [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., | ||||
| Lemon, T., and T. Pusateri, "DNS Stateful Operations", | ||||
| RFC 8490, DOI 10.17487/RFC8490, March 2019, | ||||
| <https://www.rfc-editor.org/info/rfc8490>. | ||||
| [RFC8501] Howard, L., "Reverse DNS in IPv6 for Internet Service | [RFC8501] Howard, L., "Reverse DNS in IPv6 for Internet Service | |||
| Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018, | Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018, | |||
| <https://www.rfc-editor.org/info/rfc8501>. | <https://www.rfc-editor.org/info/rfc8501>. | |||
| [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to | [RFC8806] Kumari, W. and P. Hoffman, "Running a Root Server Local to | |||
| a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, | a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020, | |||
| <https://www.rfc-editor.org/info/rfc8806>. | <https://www.rfc-editor.org/info/rfc8806>. | |||
| [RFC8906] Andrews, M. and R. Bellis, "A Common Operational Problem | [RFC8906] Andrews, M. and R. Bellis, "A Common Operational Problem | |||
| in DNS Servers: Failure to Communicate", BCP 231, | in DNS Servers: Failure to Communicate", BCP 231, | |||
| skipping to change at page 22, line 33 ¶ | skipping to change at page 26, line 25 ¶ | |||
| [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., | [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., | |||
| Gudmundsson, O., and B. Wellington, "Secret Key | Gudmundsson, O., and B. Wellington, "Secret Key | |||
| Transaction Authentication for DNS (TSIG)", STD 93, | Transaction Authentication for DNS (TSIG)", STD 93, | |||
| RFC 8945, DOI 10.17487/RFC8945, November 2020, | RFC 8945, DOI 10.17487/RFC8945, November 2020, | |||
| <https://www.rfc-editor.org/info/rfc8945>. | <https://www.rfc-editor.org/info/rfc8945>. | |||
| [ROLL_YOUR_ROOT] | [ROLL_YOUR_ROOT] | |||
| Müller, M., Thomas, M., Wessels, D., Hardaker, W., Chung, | Müller, M., Thomas, M., Wessels, D., Hardaker, W., Chung, | |||
| T., Toorop, W., and R.v. Rijswijk-Deij, "Roll, Roll, Roll | T., Toorop, W., and R.v. Rijswijk-Deij, "Roll, Roll, Roll | |||
| Your Root: A Comprehensive Analysis of the First Ever | Your Root: A Comprehensive Analysis of the First Ever | |||
| DNSSEC Root KSK Rollover", October 2019, <TBD>. | DNSSEC Root KSK Rollover", October 2019, | |||
| <https://dl.acm.org/doi/10.1145/3355369.3355570>. | ||||
| [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.R., Fenner, B., and A.M. Rudoff, "UNIX Network | ||||
| Programming Volume 1, Third Edition: The Sockets | ||||
| Networking API", 21 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. | |||
| [TOYAMA] Toyama, K., Ishibashi, K., Ishino, M., Yoshimura, C., and | [TOYAMA] Toyama, K., Ishibashi, K., Ishino, M., Yoshimura, C., and | |||
| K. Fujiwara, "DNS Anomalies and Their Impacts on DNS Cache | K. Fujiwara, "DNS Anomalies and Their Impacts on DNS Cache | |||
| Servers", NANOG 32 Reston, VA USA, 2004. | Servers", NANOG 32 Reston, VA USA, 2004. | |||
| [VERISIGN] Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in | [VERISIGN] Thomas, M. and D. Wessels, "An Analysis of TCP Traffic in | |||
| Root Server DITL Data", DNS-OARC 2014 Fall Workshop Los | Root Server DITL Data", DNS-OARC 2014 Fall Workshop Los | |||
| Angeles, 2014. | Angeles, 2014. | |||
| [WIKIPEDIA_TFO] | [WIKIPEDIA_TFO] | |||
| Wikipedia, "TCP Fast Open", 4 May 2018, | Wikipedia, "TCP Fast Open", 4 May 2018, | |||
| <https://en.wikipedia.org/wiki/TCP_Fast_Open>. | <https://en.wikipedia.org/wiki/TCP_Fast_Open>. | |||
| Appendix A. Standards Related to DNS Transport over TCP | Appendix A. Standards Related to DNS Transport over TCP | |||
| This section enumerates all known IETF RFC documents that are | This section enumerates all known IETF RFC documents that are | |||
| currently of status standard, informational, best current practice, | currently of status Internet Standard, Draft Standard, Proposed | |||
| or experimental and either implicitly or explicitly make assumptions | Standard, Informational, Best Current Practice, or Experimental and | |||
| or statements about the use of TCP as a transport for the DNS germane | either implicitly or explicitly make assumptions or statements about | |||
| to this document. | the use of TCP as a transport for the DNS germane to this document. | |||
| A.1. IETF RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION | A.1. IETF RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION | |||
| The internet standard [RFC1035] is the base DNS specification that | The Internet Standard [RFC1035] is the base DNS specification that | |||
| explicitly defines support for DNS over TCP. | explicitly defines support for DNS over TCP. | |||
| A.2. IETF RFC 1536 - Common DNS Implementation Errors and Suggested | A.2. IETF RFC 1536 - Common DNS Implementation Errors and Suggested | |||
| Fixes | Fixes | |||
| The informational document [RFC1536] states UDP is the "chosen | This 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 | This Proposed Standard [RFC1995] documents the use of TCP as the | |||
| the fallback transport when IXFR responses do not fit into a single | fallback transport when IXFR responses do not fit into a single UDP | |||
| UDP response. As with AXFR, IXFR messages are typically delivered | response. As with AXFR, IXFR messages are typically delivered over | |||
| over TCP by default in practice. | 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 master server may | This Proposed Standard [RFC1996] suggests a primary server may decide | |||
| decide to issue NOTIFY messages over TCP. In practice, NOTIFY | to issue NOTIFY messages over TCP. In practice, NOTIFY messages are | |||
| messages are generally sent over UDP, but this specification leaves | generally sent over UDP, but this specification leaves open the | |||
| open the possibility that the choice of transport protocol is up to | possibility that the choice of transport protocol is up to the | |||
| the master server, and therefore a slave server ought to be able to | primary server, and therefore a secondary server ought to be able to | |||
| operate over both UDP and TCP. | operate over both UDP and TCP. | |||
| A.5. IETF RFC 2181 - Clarifications to the DNS Specification | A.5. IETF RFC 2181 - Clarifications to the DNS Specification | |||
| The [RFC2181] standards track document includes clarifying text on | This Proposed Standard [RFC2181] includes clarifying text on how a | |||
| how a client should react to the TC bit set on responses. It is | client should react to the TC bit set on responses. It is advised | |||
| advised that the response should be discarded and the query resent | that the response should be discarded and the query resent using TCP. | |||
| using TCP. | ||||
| A.6. IETF RFC 2694 - DNS extensions to Network Address Translators | A.6. IETF RFC 2694 - DNS extensions to Network Address Translators | |||
| (DNS_ALG) | (DNS_ALG) | |||
| The informational document [RFC2694] enumerates considerations for | This Informational document [RFC2694] enumerates considerations for | |||
| network address translation (NAT) devices to properly handle DNS | network address translation (NAT) devices to properly handle DNS | |||
| traffic. This document is noteworthy in its suggestion that | traffic. This document is noteworthy in its suggestion that | |||
| "[t]ypically, TCP is used for AXFR requests," as further evidence | "[t]ypically, TCP is used for AXFR requests," as further evidence | |||
| that helps explain why DNS over TCP may often have been treated very | that helps explain why DNS over TCP may have often been treated very | |||
| differently than DNS over UDP in operational networks. | differently than DNS over UDP in operational networks. | |||
| A.7. IETF RFC 3225 - Indicating Resolver Support of DNSSEC | A.7. IETF RFC 3225 - Indicating Resolver Support of DNSSEC | |||
| The [RFC3225] standards track document makes statements indicating | This Proposed Standard [RFC3225] makes statements indicating DNS over | |||
| DNS over TCP is "detrimental" as a result of increased traffic, | TCP is "detrimental" as a result of increased traffic, latency, and | |||
| latency, and server load. This document is a companion to the next | server load. This document is a companion to the next document in | |||
| document in the RFC series expressing the requirement for EDNS(0) | the RFC series expressing the requirement for EDNS(0) support for | |||
| support for DNSSEC. | DNSSEC. | |||
| A.8. IETF RFC 3326 - DNSSEC and IPv6 A6 aware server/resolver message | A.8. IETF RFC 3226 - DNSSEC and IPv6 A6 aware server/resolver message | |||
| size requirements | size requirements | |||
| Although updated by later DNSSEC RFCs, the standards track document | Although updated by later DNSSEC RFCs, the Proposed Standard | |||
| [RFC3226] strongly argued in favor of UDP messages instead of TCP, | [RFC3226] strongly argues in favor of UDP messages instead of TCP, | |||
| largely for performance reasons. The document declares EDNS(0) a | largely for performance reasons. The document declares EDNS(0) a | |||
| requirement for DNSSEC servers and advocated packet fragmentation may | requirement for DNSSEC servers and advocates that packet | |||
| be preferable to TCP in certain situations. | fragmentation may be preferable to TCP in certain situations. | |||
| A.9. IETF RFC 4472 - Operational Considerations and Issues with IPv6 | A.9. IETF RFC 4472 - Operational Considerations and Issues with IPv6 | |||
| DNS | DNS | |||
| This informational document [RFC4472] notes that IPv6 data may | This Informational document [RFC4472] notes that IPv6 data may | |||
| increase DNS responses beyond what would fit in a UDP message. | increase DNS responses beyond what would fit in a UDP message. | |||
| Particularly noteworthy, perhaps less common today then when this | Particularly noteworthy, perhaps less common today than when this | |||
| document was written, it refers to implementations that truncate data | document was written, it refers to implementations that truncate data | |||
| without setting the TC bit to encourage the client to resend the | without setting the TC bit to encourage the client to resend the | |||
| query using TCP. | query using TCP. | |||
| A.10. IETF RFC 5452 - Measures for Making DNS More Resilient against | A.10. IETF RFC 5452 - Measures for Making DNS More Resilient against | |||
| Forged Answers | Forged Answers | |||
| This informational document [RFC5452] arose as public DNS systems | This Informational document [RFC5452] arose as public DNS systems | |||
| began to experience widespread abuse from spoofed queries, resulting | began to experience widespread abuse from spoofed queries, resulting | |||
| in amplification and reflection attacks against unwitting victims. | in amplification and reflection attacks against unwitting victims. | |||
| One of the leading justifications for supporting DNS over TCP to | One of the leading justifications for supporting DNS over TCP to | |||
| thwart these attacks is briefly described in this document's 9.3 | thwart these attacks is briefly described in this document's 9.3 | |||
| Spoof Detection and Countermeasure section. | Spoof Detection and Countermeasure section. | |||
| A.11. IETF RFC 5507 - Design Choices When Expanding the DNS | A.11. IETF RFC 5507 - Design Choices When Expanding the DNS | |||
| This informational document [RFC5507] was largely an attempt to | This Informational document [RFC5507] was largely an attempt to | |||
| dissuade new DNS data types from overloading the TXT resource record | dissuade new DNS data types from overloading the TXT resource record | |||
| type. In so doing it summarizes the conventional wisdom of DNS | type. In so doing it summarizes the conventional wisdom of DNS | |||
| design and implementation practices. The authors suggest TCP | design and implementation practices. The authors suggest TCP | |||
| overhead and stateful properties pose challenges compared to UDP, and | overhead and stateful properties pose challenges compared to UDP, and | |||
| imply that UDP is generally preferred for performance and robustness. | imply that UDP is generally preferred for performance and robustness. | |||
| A.12. IETF RFC 5625 - DNS Proxy Implementation Guidelines | A.12. IETF RFC 5625 - DNS Proxy Implementation Guidelines | |||
| This best current practice document [RFC5625] provides DNS proxy | This Best Current Practice document [RFC5625] provides DNS proxy | |||
| implementation guidance including the mandate that a proxy "MUST | implementation guidance including the mandate that a proxy "MUST | |||
| [...] be prepared to receive and forward queries over TCP" even | [...] be prepared to receive and forward queries over TCP" even | |||
| though it suggests historically TCP transport has not been strictly | though it suggests historically TCP transport has not been strictly | |||
| mandatory in stub resolvers or recursive servers. | mandatory in stub resolvers or recursive servers. | |||
| A.13. IETF RFC 5936 - DNS Zone Transfer Protocol (AXFR) | A.13. IETF RFC 5936 - DNS Zone Transfer Protocol (AXFR) | |||
| The [RFC5936] standards track document provides a detailed | This Proposed Standard [RFC5936] provides a detailed specification | |||
| specification for the zone transfer protocol, as originally outlined | for the zone transfer protocol, as originally outlined in the early | |||
| in the early DNS standards. AXFR operation is limited to TCP and not | DNS standards. AXFR operation is limited to TCP and not specified | |||
| specified for UDP. This document discusses TCP usage at length. | for UDP. This document discusses TCP usage at length. | |||
| A.14. IETF RFC 7534 - AS112 Nameserver Operations | A.14. IETF RFC 7534 - AS112 Nameserver Operations | |||
| [RFC7534] is an informational document enumerating the requirements | [RFC7534] is an Informational document enumerating the requirements | |||
| for operation of AS112 project DNS servers. New AS112 nodes are | for operation of AS112 project DNS servers. New AS112 nodes are | |||
| tested for their ability to provide service on both UDP and TCP | tested for their ability to provide service on both UDP and TCP | |||
| transports, with the implication that TCP service is an expected part | transports, with the implication that TCP service is an expected part | |||
| of normal operations. | of normal operations. | |||
| A.15. IETF RFC 6762 - Multicast DNS | A.15. IETF RFC 6762 - Multicast DNS | |||
| In this standards track document [RFC6762], the TC bit is deemed to | In this Proposed Standard [RFC6762], the TC bit is deemed to have | |||
| have essentially the same meaning as described in the original DNS | essentially the same meaning as described in the original DNS | |||
| specifications. That is, if a response with the TC bit set is | specifications. That is, if a response with the TC bit set is | |||
| received, "[...] the querier SHOULD reissue its query using TCP in | received, "[...] the querier SHOULD reissue its query using TCP in | |||
| order to receive the larger response." | order to receive the larger response." | |||
| A.16. IETF RFC 6891 - Extension Mechanisms for DNS (EDNS(0)) | A.16. IETF RFC 6891 - Extension Mechanisms for DNS (EDNS(0)) | |||
| This standards track document [RFC6891] helped slow the use of and | This Internet Standard [RFC6891] helped slow the use of and need for | |||
| need for DNS over TCP messages. This document highlights concerns | DNS over TCP messages. This document highlights concerns over server | |||
| over server load and scalability in widespread use of DNS over TCP. | load and scalability in widespread use of DNS over TCP. | |||
| A.17. IETF RFC 6950 - Architectural Considerations on Application | A.17. IETF RFC 6950 - Architectural Considerations on Application | |||
| Features in the DNS | Features in the DNS | |||
| An informational document [RFC6950] that draws attention to large | An Informational document [RFC6950] that draws attention to large | |||
| data in the DNS. TCP is referenced in the context as a common | data in the DNS. TCP is referenced in the context as a common | |||
| fallback mechanism and counter to some spoofing attacks. | fallback mechanism and counter to some spoofing attacks. | |||
| A.18. IETF RFC 7477 - Child-to-Parent Synchronization in DNS | A.18. IETF RFC 7477 - Child-to-Parent Synchronization in DNS | |||
| This standards track document [RFC7477] specifies a RRType and | This Proposed Standard [RFC7477] specifies a RRType and protocol to | |||
| protocol to signal and synchronize NS, A, and AAAA resource record | signal and synchronize NS, A, and AAAA resource record changes from a | |||
| changes from a child to parent zone. Since this protocol may require | child to parent zone. Since this protocol may require multiple | |||
| multiple requests and responses, it recommends utilizing DNS over TCP | requests and responses, it recommends utilizing DNS over TCP to | |||
| to ensure the conversation takes place between a consistent pair of | ensure the conversation takes place between a consistent pair of end | |||
| end nodes. | nodes. | |||
| A.19. IETF RFC 7720 - DNS Root Name Service Protocol and Deployment | A.19. IETF RFC 7720 - DNS Root Name Service Protocol and Deployment | |||
| Requirements | Requirements | |||
| This best current practice [RFC7720] declares root name service "MUST | This Best Current Practice [RFC7720] declares root name service "MUST | |||
| support UDP [RFC0768] and TCP [RFC0793] transport of DNS queries and | support UDP [RFC0768] and TCP [RFC0793] transport of DNS queries and | |||
| responses." | responses." | |||
| A.20. IETF RFC 7766 - DNS Transport over TCP - Implementation | A.20. IETF RFC 7766 - DNS Transport over TCP - Implementation | |||
| Requirements | Requirements | |||
| This standards track document [RFC7766] instructs DNS implementers to | This Proposed Standard [RFC7766] instructs DNS implementers to | |||
| provide support for carrying DNS over TCP messages in their software, | provide support for carrying DNS over TCP messages in their software, | |||
| and might be considered the direct ancestor of this operational | and might be considered the direct ancestor of this operational | |||
| requirements document. The implementation requirements document | requirements document. The implementation requirements document | |||
| codifies mandatory support for DNS over TCP in compliant DNS | codifies mandatory support for DNS over TCP in compliant DNS | |||
| software, but makes no recommendations to operators, which we seek to | software, but makes no recommendations to operators, which we seek to | |||
| address here. | address here. | |||
| A.21. IETF RFC 7828 - The edns-tcp-keepalive EDNS(0) Option | A.21. IETF RFC 7828 - The edns-tcp-keepalive EDNS(0) Option | |||
| This standards track document [RFC7828] defines an EDNS(0) option to | This Proposed Standard [RFC7828] defines an EDNS(0) option to | |||
| negotiate an idle timeout value for long-lived DNS over TCP | negotiate an idle timeout value for long-lived DNS over TCP | |||
| connections. Consequently, this document is only applicable and | connections. Consequently, this document is only applicable and | |||
| relevant to DNS over TCP sessions and between implementations that | relevant to DNS over TCP sessions and between implementations that | |||
| support this option. | support this option. | |||
| A.22. IETF RFC 7858 - Specification for DNS over Transport Layer | A.22. IETF RFC 7858 - Specification for DNS over Transport Layer | |||
| Security (TLS) | Security (TLS) | |||
| This standards track document [RFC7858] defines a method for putting | This Proposed Standard [RFC7858] defines a method for putting DNS | |||
| DNS messages into a TCP-based encrypted channel using TLS. This | messages into a TCP-based encrypted channel using TLS. This | |||
| specification is noteworthy for explicitly targeting the stub-to- | specification is noteworthy for explicitly targeting the stub-to- | |||
| recursive traffic, but does not preclude its application from | recursive traffic, but does not preclude its application from | |||
| recursive-to-authoritative traffic. | recursive-to-authoritative traffic. | |||
| A.23. IETF RFC 7873 - Domain Name System (DNS) Cookies | A.23. IETF RFC 7873 - Domain Name System (DNS) Cookies | |||
| This standards track document [RFC7873] describes an EDNS(0) option | This Proposed Standard [RFC7873] describes an EDNS(0) option to | |||
| to provide additional protection against query and answer forgery. | provide additional protection against query and answer forgery. This | |||
| This specification mentions DNS over TCP as an alternative mechanism | specification mentions DNS over TCP as an alternative mechanism when | |||
| when DNS Cookies are not available. The specification does make | DNS Cookies are not available. The specification does make mention | |||
| mention of DNS over TCP processing in two specific situations. In | of DNS over TCP processing in two specific situations. In one, when | |||
| one, when a server receives only a client cookie in a request, the | a server receives only a client cookie in a request, the server | |||
| server should consider whether the request arrived over TCP and if | should consider whether the request arrived over TCP and if so, it | |||
| so, it should consider accepting TCP as sufficient to authenticate | should consider accepting TCP as sufficient to authenticate the | |||
| the request and respond accordingly. In another, when a client | request and respond accordingly. In another, when a client receives | |||
| receives a BADCOOKIE reply using a fresh server cookie, the client | a BADCOOKIE reply using a fresh server cookie, the client should | |||
| should retry using TCP as the transport. | retry using TCP as the transport. | |||
| A.24. IETF RFC 7901 - CHAIN Query Requests in DNS | A.24. IETF RFC 7901 - CHAIN Query Requests in DNS | |||
| This experimental specification [RFC7901] describes an EDNS(0) option | This Experimental specification [RFC7901] describes an EDNS(0) option | |||
| that can be used by a security-aware validating resolver to request | that can be used by a security-aware validating resolver to request | |||
| and obtain a complete DNSSEC validation path for any single query. | and obtain a complete DNSSEC validation path for any single query. | |||
| This document requires the use of DNS over TCP or a source IP address | This document requires the use of DNS over TCP or a source IP address | |||
| verified transport mechanism such as EDNS-COOKIE [RFC7873]. | verified transport mechanism such as EDNS-COOKIE [RFC7873]. | |||
| A.25. IETF RFC 8027 - DNSSEC Roadblock Avoidance | A.25. IETF RFC 8027 - DNSSEC Roadblock Avoidance | |||
| This document [RFC8027] details observed problems with DNSSEC | This Best Current Practice [RFC8027] details observed problems with | |||
| deployment and mitigation techniques. Network traffic blocking and | DNSSEC deployment and mitigation techniques. Network traffic | |||
| restrictions, including DNS over TCP messages, are highlighted as one | blocking and restrictions, including DNS over TCP messages, are | |||
| reason for DNSSEC deployment issues. While this document suggests | highlighted as one reason for DNSSEC deployment issues. While this | |||
| these sorts of problems are due to "non-compliant infrastructure" and | document suggests these sorts of problems are due to "non-compliant | |||
| is of type BCP, the scope of the document is limited to detection and | infrastructure", the scope of the document is limited to detection | |||
| mitigation techniques to avoid so-called DNSSEC roadblocks. | and mitigation techniques to avoid so-called DNSSEC roadblocks. | |||
| A.26. IETF RFC 8094 - DNS over Datagram Transport Layer Security (DTLS) | A.26. IETF RFC 8094 - DNS over Datagram Transport Layer Security (DTLS) | |||
| This experimental specification [RFC8094] details a protocol that | This Experimental specification [RFC8094] details a protocol that | |||
| uses a datagram transport (UDP), but stipulates that "DNS clients and | uses a datagram transport (UDP), but stipulates that "DNS clients and | |||
| servers that implement DNS over DTLS MUST also implement DNS over TLS | servers that implement DNS over DTLS MUST also implement DNS over TLS | |||
| in order to provide privacy for clients that desire Strict Privacy | in order to provide privacy for clients that desire Strict Privacy | |||
| [...]." This requirement implies DNS over TCP must be supported in | [...]." This requirement implies DNS over TCP must be supported in | |||
| case the message size is larger than the path MTU. | case the message size is larger than the path MTU. | |||
| A.27. IETF RFC 8162 - Using Secure DNS to Associate Certificates with | A.27. IETF RFC 8162 - Using Secure DNS to Associate Certificates with | |||
| Domain Names for S/MIME | Domain Names for S/MIME | |||
| This experimental specification [RFC8162] describes a technique to | This Experimental specification [RFC8162] describes a technique to | |||
| authenticate user X.509 certificates in an S/MIME system via the DNS. | authenticate user X.509 certificates in an S/MIME system via the DNS. | |||
| The document points out that the new experimental resource record | The document points out that the new experimental resource record | |||
| types are expected to carry large payloads, resulting in the | types are expected to carry large payloads, resulting in the | |||
| suggestion that "applications SHOULD use TCP -- not UDP -- to perform | suggestion that "applications SHOULD use TCP -- not UDP -- to perform | |||
| queries for the SMIMEA resource record." | queries for the SMIMEA resource record." | |||
| A.28. IETF RFC 8324 - DNS Privacy, Authorization, Special Uses, | A.28. IETF RFC 8324 - DNS Privacy, Authorization, Special Uses, | |||
| Encoding, Characters, Matching, and Root Structure: Time for | Encoding, Characters, Matching, and Root Structure: Time for | |||
| Another Look? | Another Look? | |||
| An informational document [RFC8324] that briefly discusses the common | An Informational document [RFC8324] that briefly discusses the common | |||
| role and challenges of DNS over TCP throughout the history of DNS. | role and challenges of DNS over TCP throughout the history of DNS. | |||
| A.29. IETF RFC 8467 - Padding Policies for Extension Mechanisms for DNS | A.29. IETF RFC 8467 - Padding Policies for Extension Mechanisms for DNS | |||
| (EDNS(0)) | (EDNS(0)) | |||
| An experimental document [RFC8467] reminds implementers to consider | An Experimental document [RFC8467] reminds implementers to consider | |||
| the underlying transport protocol (e.g. TCP) when calculating the | the underlying transport protocol (e.g. TCP) when calculating the | |||
| padding length when artificially increasing the DNS message size with | padding length when artificially increasing the DNS message size with | |||
| an EDNS(0) padding option. | an EDNS(0) padding option. | |||
| A.30. IETF RFC 8482 - Providing Minimal-Sized Responses to DNS Queries | A.30. IETF RFC 8482 - Providing Minimal-Sized Responses to DNS Queries | |||
| That Have QTYPE=ANY | That Have QTYPE=ANY | |||
| [RFC8482] is a standards-track document that describes alternative | [RFC8482] is a Proposed Standard that describes alternative ways that | |||
| ways that DNS servers can respond to queries of type ANY, which are | DNS servers can respond to queries of type ANY, which are sometimes | |||
| sometimes used to provide amplification in DDoS attacks. The | used to provide amplification in DDoS attacks. The specification | |||
| specification notes that responders may behave differently, depending | notes that responders may behave differently, depending on the | |||
| on the transport. For example, minimal-sized responses may be used | transport. For example, minimal-sized responses may be used over UDP | |||
| over UDP transport, while full responses may be given over TCP. | transport, while full responses may be given over TCP. | |||
| A.31. IETF RFC 8483 - Yeti DNS Testbed | A.31. IETF RFC 8483 - Yeti DNS Testbed | |||
| This informational document [RFC8483] describes a testbed environment | This Informational document [RFC8483] describes a testbed environment | |||
| that highlights some DNS over TCP behaviors, including issues | that highlights some DNS over TCP behaviors, including issues | |||
| involving packet fragmentation and operational requirements for TCP | involving packet fragmentation and operational requirements for TCP | |||
| stream assembly in order to conduct DNS measurement and analysis. | stream assembly in order to conduct DNS measurement and analysis. | |||
| A.32. IETF RFC 8484 - DNS Queries over HTTPS (DoH) | A.32. IETF RFC 8484 - DNS Queries over HTTPS (DoH) | |||
| This standards track document [RFC8484] defines a protocol for | This Proposed Standard [RFC8484] defines a protocol for sending DNS | |||
| sending DNS queries and responses over HTTPS. This specification | queries and responses over HTTPS. This specification assumes TLS and | |||
| assumes TLS and TCP for the underlying security and transport layers, | TCP for the underlying security and transport layers, respectively. | |||
| respectively. Self-described as a a technique that more closely | Self-described as a technique that more closely resembles a tunneling | |||
| resembles a tunneling mechanism, DoH nevertheless likely implies DNS | mechanism, DoH nevertheless likely implies DNS over TCP in some | |||
| over TCP in some sense, if not directly. | 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 Proposed Standard [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 | persistent sessions, such as those that might be used by DNS over | |||
| TCP. | TCP. | |||
| A.34. IETF RFC 8501 - Reverse DNS in IPv6 for Internet Service | A.34. IETF RFC 8501 - Reverse DNS in IPv6 for Internet Service | |||
| Providers | Providers | |||
| This informational document [RFC8501] identifies potential | This Informational document [RFC8501] identifies potential | |||
| operational challenges with Dynamic DNS including denial-of-service | operational challenges with Dynamic DNS including denial-of-service | |||
| threats. The document suggests TCP may provide some advantages, but | threats. The document suggests TCP may provide some advantages, but | |||
| that updating hosts would need to be explicitly configured to use TCP | that updating hosts would need to be explicitly configured to use TCP | |||
| instead of UDP. | instead of UDP. | |||
| A.35. IETF RFC 8806 - Running a Root Server Local to a Resolver | A.35. IETF RFC 8806 - Running a Root Server Local to a Resolver | |||
| This informational document [RFC8806] describes how to obtain and | This Informational document [RFC8806] describes how to obtain and | |||
| operate a local copy of the root zone with examples showing how to | operate a local copy of the root zone with examples showing how to | |||
| pull from authoritative sources using a DNS over TCP zone transfer. | pull from authoritative sources using a DNS over TCP zone transfer. | |||
| A.36. IETF RFC 8906 - A Common Operational Problem in DNS Servers: | A.36. IETF RFC 8906 - A Common Operational Problem in DNS Servers: | |||
| Failure to Communicate | Failure to Communicate | |||
| This best current practice document [RFC8906] discusses a number of | This Best Current Practice document [RFC8906] discusses a number of | |||
| DNS operational failure scenarios and how to avoid them. This | DNS operational failure scenarios and how to avoid them. This | |||
| includes discussions involving DNS over TCP queries, EDNS over TCP, | includes discussions involving DNS over TCP queries, EDNS over TCP, | |||
| and a testing methodology that includes a section on verifying DNS | and a testing methodology that includes a section on verifying DNS | |||
| over TCP functionality. | over TCP functionality. | |||
| A.37. IETF RFC 8932 - Recommendations for DNS Privacy Service Operators | A.37. IETF RFC 8932 - Recommendations for DNS Privacy Service Operators | |||
| This best current practice document [RFC8932] presents privacy | This Best Current Practice document [RFC8932] presents privacy | |||
| considerations to DNS privacy service operators. These mechanisms | considerations to DNS privacy service operators. These mechanisms | |||
| sometimes include the use of TCP and are therefore susceptible to | sometimes include the use of TCP and are therefore susceptible to | |||
| information leakage such as TCP-based fingerprinting. This document | information leakage such as TCP-based fingerprinting. This document | |||
| also references a draft version of this document. | also references a draft version of this document. | |||
| A.38. IETF RFC 8945 - Secret Key Transaction Authentication for DNS | A.38. IETF RFC 8945 - Secret Key Transaction Authentication for DNS | |||
| (TSIG) | (TSIG) | |||
| This standards track document [RFC8945] recommends a client use TCP | This Internet Standard [RFC8945] recommends a client use TCP if | |||
| if truncated TSIG messages are received. | truncated TSIG messages are received. | |||
| Authors' Addresses | Authors' Addresses | |||
| John Kristoff | John Kristoff | |||
| DataPlane.org | DataPlane.org | |||
| Chicago, IL 60605 | Chicago, IL 60605 | |||
| United States of America | United States of America | |||
| Phone: +1 312 493 0305 | Phone: +1 312 493 0305 | |||
| Email: jtk@dataplane.org | Email: jtk@dataplane.org | |||
| URI: https://dataplane.org/jtk/ | URI: https://dataplane.org/jtk/ | |||
| Duane Wessels | Duane Wessels | |||
| Verisign | Verisign | |||
| 12061 Bluemont Way | 12061 Bluemont Way | |||
| Reston, VA 20190 | Reston, VA 20190 | |||
| United States of America | United States of America | |||
| Phone: +1 703 948 3200 | Phone: +1 703 948 3200 | |||
| Email: dwessels@verisign.com | Email: dwessels@verisign.com | |||
| URI: http://verisign.com | URI: https://verisign.com | |||
| End of changes. 138 change blocks. | ||||
| 370 lines changed or deleted | 542 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/ | ||||