MTU, Fragmentation and Big DNS Answers

What MTU means

Each link type has its own MTU. Standard Ethernet carries 1,500 bytes of IP packet per frame; PPPoE broadband links usually carry 1,492; VPN and tunnel interfaces carry less, because the tunnel's own headers must fit inside the outer packet. The path MTU is the smallest MTU on every link between two hosts, and it is what actually limits a packet's size.

Headers use part of that budget. For a DNS response over UDP, the space left for the DNS message is:

The 1,232-byte figure comes from IPv6's guaranteed minimum. RFC 8200 requires every IPv6 link to carry at least 1,280-byte packets, so a 1,232-byte DNS payload fits on any compliant path without fragmenting.

How fragmentation works

When a packet is too large for the next link, it can be split into pieces that each fit. The receiver reassembles them before handing the data to UDP or TCP. If any one fragment is lost, the whole packet is lost, and there is no fragment-level retransmission.

• IPv4 lets routers fragment packets in transit, unless the sender sets the Don't Fragment (DF) bit. With DF set, the router drops the packet and should send back an ICMP "fragmentation needed" message.
• IPv6 never fragments in routers. Only the sending host can fragment, using a Fragment extension header. A router that cannot forward a packet drops it and sends an ICMPv6 Packet Too Big message.

Fragments create practical problems. Only the first fragment carries the UDP header with port numbers, so firewalls, NAT devices and load balancers that make decisions by port often drop the rest or cannot reassemble them. Some networks drop all fragments as a matter of policy. And because later fragments carry no DNS ID or port, researchers have shown that an off-path attacker can sometimes forge a later fragment and splice false data into a DNS answer.

Path MTU Discovery and black holes

Path MTU Discovery (PMTUD) lets a sender learn the path MTU instead of guessing. The sender transmits packets that must not be fragmented and lowers its packet size when ICMP messages report that a link is too small. It is defined for IPv4 in RFC 1191 and for IPv6 in RFC 8201.

PMTUD only works if those ICMP messages get back to the sender. When a firewall filters all ICMP, large packets vanish without explanation. This is a PMTU black hole: small exchanges work, large ones hang. TCP connections often survive because hosts and routers clamp the TCP maximum segment size (MSS) to fit the link, but UDP has no such negotiation.

You can probe the path MTU with ping by forbidding fragmentation and adjusting the payload size. On Linux, 1,472 bytes of ICMP payload plus 28 bytes of headers makes a 1,500-byte packet:

$ ping -M do -s 1472 -c 1 198.51.100.10
PING 198.51.100.10 (198.51.100.10) 1472(1500) bytes of data.
1480 bytes from 198.51.100.10: icmp_seq=1 ttl=57 time=11.8 ms

$ ping -M do -s 1473 -c 1 198.51.100.10
PING 198.51.100.10 (198.51.100.10) 1473(1501) bytes of data.
ping: local error: message too long, mtu=1500

If the 1,472-byte probe gets no reply at all while smaller probes do, something on the path may have a smaller MTU and not be reporting it. It can also simply mean the target or a firewall drops large ICMP echo packets, so confirm with a size-sensitive test of the real traffic, such as a large DNS answer over UDP, before calling it a PMTU black hole. A traceroute variant such as tracepath can show where the size drops; How to Read a Traceroute explains the output.

Why DNS answers get big

Classic DNS answers were small. Several things have pushed sizes up:

EDNS(0), defined in RFC 6891, lets a client advertise how large a UDP response it can accept. For years many resolvers advertised 4,096 bytes, which invited servers to send answers that had to be fragmented. When an answer exceeds the advertised size, the server sets the TC flag and the client retries over TCP, which handles any size safely. EDNS, Large Responses and TCP Fallback covers that mechanism in depth.

$ dig +dnssec +bufsize=1232 @ns1.example.net example.net DNSKEY
;; Truncated, retrying in TCP mode.
...
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
...
;; SERVER: 198.51.100.53#53(ns1.example.net) (TCP)
;; MSG SIZE  rcvd: 1490

Here the 1,490-byte answer did not fit in a 1,232-byte UDP response, so dig retried over TCP and got it intact. That is the intended behavior. The failure case is when TCP is blocked too; see TCP vs UDP and Why DNS Uses Both.

Current practice: DNS Flag Day 2020

In 2020, DNS software vendors and operators coordinated DNS Flag Day 2020 to address fragmentation. The recommendations were:

• Use a default EDNS buffer size of 1,232 bytes on both resolvers and authoritative servers.
• Make sure authoritative servers and resolvers answer over TCP on port 53, so truncated answers can be retrieved.
• Do not send UDP responses larger than the client's advertised buffer, and avoid fragmentation altogether.

Most current resolver and server software ships with a 1,232-byte default. If you have overridden it in older configuration files, check that the override is still wanted. For zone owners, the practical steps are to keep apex TXT records tidy, prefer smaller DNSSEC algorithms such as ECDSA P-256 where your tooling supports them, and confirm that every name server accepts TCP. When signed zones fail only for some resolvers, size is a common suspect, and Debugging DNSSEC validation errors covers the wider checks.

How DNS Panopticon helps

Domain Visualizer resolves a domain's records through DNS-over-HTTPS resolvers, so it shows you the full content of large record sets such as apex TXT records, but its queries do not travel over your own UDP path. A clean result there does not rule out an MTU or fragmentation problem between a particular network and your name servers; test that with dig and ping from the affected network.

For zones you manage, Zone Analyzer can filter an export to TXT records at the apex, which makes it easy to spot stale verification tokens and other entries that inflate answer sizes.