]>

tojens.ietf@gmail.com

Classic DNS DNS over TCP DNS over UDP Protocols that rely on Classic DNS have to account for considerations that only apply to UDP, such as message fragmentation. However, DNS implementations are already required to support both TCP and UDP, and using TCP would alleviate these considerations. This document specifies that new protocols with a dependency on Classic DNS do not need to account for the limitations of Classic DNS over UDP and can instead expect implementations to use Classic DNS over TCP.

Introduction Many uses of the DNS require message sizes larger than common path MTUs. This poses problems for Classic DNS over UDP by requiring peers to handle message fragmentation. This is usually addressed by requiring peers to set the trucation bit and repeat the query using Classic DNS over TCP, which wastes a round trip, introducing delay in the network traffic that depends on the DNS data retrieval. However, there are also worse implications, such as requiring IoT devices to do polling , additional recommendations for avoiding IP fragmentation placing transport-like burdens on DNS implementors, and normative requirements that exist only to deter the attack described in the DNS threat analysis , such as having to consciously control source port selection when initializing a DNS resolver with priming queries . These complications can be avoided by assuming Classic DNS over TCP is the only form of Classic DNS that new protocols need to accommodate. The Implementation Requirements for Classic DNS over TCP already require DNS implementations to support Classic DNS over TCP wherever they support Classic DNS over UDP and to treat TCP as a first-class transport rather than only a fallback option from UDP. Therefore, it is safe to require protocols to assume Classic DNS is always available over TCP without some specific scenario limitations being defined.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document reuses terms defined in DNS Terminology , including "Classic DNS".

Requirements for new protocols This document does not directly define new normative requirements for DNS implementations. Instead, it defines requirements that apply to new documents produced by the IETF. Authors of new IETF documents SHOULD NOT add normative requirements that are only necessary to accommodate Classic DNS over UDP that are not necessary to accommodate Classic DNS over TCP without sufficient explaination for why UDP is a preferable transport to TCP (which would deviate from the Implementation Requirements for Classic DNS over TCP ). Authors of new IETF documents SHOULD direct implementations to use Classic DNS over TCP first by default instead of Classic DNS over UDP if the document defines any usage of Classic DNS that is expected to need message truncation. This will avoid a wasted round trip to switch from UDP to TCP. This requirement does not in any way affect preference between Classic DNS and encrypted DNS.

Security Considerations Discouraging protocols from accommodating Classic DNS over UDP provides a non-zero security benefit by defending against the attack described in the DNS threat analysis . Increasing usage of Classic DNS using TCP will increase maintained state, but this is not concerning because encrypted DNS protocols already require connection maintenance and usage of Classic DNS over TCP is already common due to increasing message sizes.

IANA Considerations This document has no IANA actions.

References Normative References Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. This memo provides information for the Internet community. This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. Informative References This document details considerations about how Internet of Things (IoT) devices use IP addresses and DNS names. These concerns become acute as network operators begin deploying Manufacturer Usage Descriptions (MUD), as specified in RFC 8520, to control device access. Also, this document makes recommendations on when and how to use DNS names in MUD files. The widely deployed Extension Mechanisms for DNS (EDNS(0)) feature in the DNS enables a DNS receiver to indicate its received UDP message size capacity, which supports the sending of large UDP responses by a DNS server. Large DNS/UDP messages are more likely to be fragmented, and IP fragmentation has exposed weaknesses in application protocols. It is possible to avoid IP fragmentation in DNS by limiting the response size where possible and signaling the need to upgrade from UDP to TCP transport where necessary. This document describes techniques to avoid IP fragmentation in DNS. This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS resource record set (RRset) for the root zone and the necessary address information for reaching the root servers. This document obsoletes RFC 8109.

Acknowledgments Many thanks for constructive feedback on this document to TBD.