Introduction and problem statement
In this document we want to discuss an existing IETF draft that caught our attention, it is a document that involves two very interesting worlds: IPv6 and DNS. This draft introduces some best practices for DNS transport over IPv6.
The draft is titled “DNS over IPv6 Best Practices” and can be found here.
What is the document about and what does it seek to solve?
The document describes an approach for how the Domain Name System (DNS) should be transmitted over IPv6 [RFC8200].
Some operational issues have been identified when sending DNS packets over IPv6, the draft aims to address these issues.
Technical context
The IPv6 protocol requires a minimum transmission unit (MTU) size of 1280 octets. According to Section 5 “Packet Size Issues” of RFC8200, every link in the Internet must have an MTU of 1280 octets or larger. If a link cannot transmit a 1280-octet packet in one piece, then link-specific fragmentation and reassembly service must be provided at a layer below IPv6.
Using Path MTU Discovery (PMTUD) and fragmentation in IPv6 (source only), larger packets can be sent. However, operational experience indicates that sending large DNS packets over UDP in IPv6 results in high drop rates. Some studies – many years old, but useful for context – have found that about 10% of IPv6 routers discard all IPv6 fragments, and 40% of them block “Packet Too Big” messages, which make client negotiation impossible. (“M. de Boer, J. Bosma, ”Discovering Path MTU black holes on the Internet using RIPE Atlas”)
Most modern transport protocols, such as TCP [TCP] and QUIC [QUIC], include segmentation techniques that allow larger data streams to be sent over IPv6.
A bit of history
The Domain Name System (DNS) was originally defined in RFC 1034 and RFC 1035. It is designed to operate over several different transport protocols, including UDP and TCP, and has more recently been extended to operate over QUIC. These transport protocols can be used on both IPv4 and IPv6.
When DNS was designed, a limit was placed on the size of DNS packets transmitted over UDP at 512 bytes. If a message was longer, it was truncated and the Truncation (TC) bit was set to indicate that the response was incomplete, allowing the client to try again with TCP.
With this original behavior, UDP over IPv6 did not exceed the MTU (maximum transmission unit) of the IPv6 link, avoiding operational problems due to fragmentation. However, with the introduction of the EDNS0 extensions (RFC6891) the maximum was extended to a theoretical 64KB, which caused some responses to exceed the 512-byte limit for UDP, resulting in sizes that could exceed the Path MTU, causing TCP connections to crash and affecting the scalability of DNS servers.
Let's talk about DNS over IPv6
DNS over IPv6 is designed to work over UDP as well as TCP or QUIC. UDP only provides source and destination ports, a length field, and a simple checksum, and is a connectionless protocol. In contrast, TCP and QUIC offer additional features such as packet segmentation, reliability, error correction, and connection state.
DNS over UDP operation in IPv6 is adequate for small packet sizes, but becomes less reliable with larger sizes, especially when IPv6 datagram fragmentation is required.
On the other hand, DNS over TCP or QUIC in IPv6 works well with all packet sizes. However, using a stateful protocol like TCP or QUIC places higher demands on the DNS server's resources (and other equipment like firewalls, DPIs, IDS, etc.), which can affect scalability. This may be a reasonable trade-off for servers that need to send larger DNS response packets.
The draft suggestion for DNS over UDP recommends limiting the size of DNS over UDP packets in IPv6 to 1280 octets. This avoids the need for IPv6 fragmentation or Path MTU Discovery, ensuring greater reliability.
Most DNS queries and responses will fit within this packet size limit and can therefore be sent over UDP. Larger DNS packets should not be sent over UDP; instead, they should be sent over TCP or QUIC, as mentioned in the next section.
DNS over TCP and QUIC
When larger DNS packets need to be transported, it is recommended to use DNS over TCP or QUIC. These protocols handle segmentation and reliably adjust their segment size for different link and path MTU values, making them much more reliable than using UDP with IPv6 fragmentation.
Section 4.2.2 of [RFC1035] describes the use of TCP to transport DNS messages, while [RFC9250] explains how to implement DNS over QUIC to provide transport confidentiality. Additionally, operational requirements for DNS over TCP are described in [RFC9210].
Security
Switching from UDP to TCP/QUIC for large responses means that the DNS server must maintain additional state for each query received via TCP/QUIC. This will consume additional resources on the servers and affect the scalability of the DNS system. In addition, this situation may leave the servers vulnerable to Denial of Service (DoS) attacks.
Is this the correct way?
While we do believe this solution will bring many benefits to the IPv6 and DNS ecosystem, it is a temporary operational patch, but does not address the root cause of the problem.
We believe the right solution is to have fragmentation at the source working, to have PMTUD not broken along the way, and to have fragmentation headers allowed by security devices. This requires changes at various Internet players that may take a long time, but that doesn't mean we should abandon education and efforts to get it right.
