| Internet-Draft | Do Not Accommodate Classic DNS over UDP | July 2025 |
| Jensen | Expires 7 January 2026 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 7 January 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 Section 3.1 of [RFC9726], additional recommendations for avoiding IP fragmentation [RFC9715] placing transport-like burdens on DNS implementors, and normative requirements that exist only to deter the attack described in the DNS threat analysis [RFC3833], such as having to consciously control source port selection when initializing a DNS resolver with priming queries [RFC9609].¶
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 [RFC7766] 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document reuses terms defined in DNS Terminology [RFC9499], including "Classic DNS".¶
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 [RFC7766]).¶
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.¶
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 Section 2.2 of [RFC3833].¶
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.¶
This document has no IANA actions.¶
Many thanks for constructive feedback on this document to TBD.¶