Why DNS Flag Day 2020 Targets Packet Fragmentation
The DNS Flag Day initiative, backed by a coalition of DNS vendors and operators, returns on October 1, 2020. Its aim is to push implementations closer to DNS standards, reducing the need for workarounds and establishing a dependable baseline of protocol behavior. This year's focus is on eliminating IP fragmentation of DNS messages sent over UDP, a recurring source of reliability problems.
Last year's Flag Day, February 1, centered on EDNS0 compliance. By requiring proper handling of the EDNS0 protocol, originally specified in RFC 2671 from 1999, servers could rely on clients supporting the extension and always send messages as EDNS0, a prerequisite for DNSSEC. The 2020 effort shifts attention to transport-level issues: how DNS messages are carried over UDP and what happens when they grow too large.
The Fragmentation Problem
DNS was designed from the outset—per RFC 1035—to operate over both UDP and TCP. However, TCP support was left to the implementer's discretion, and firewalls often blocked DNS over TCP in practice. Later updates to RFC 1035, particularly RFC 7766, mandate that DNS servers be reachable over TCP. But fragmentation over UDP remains a known hazard.
Network packets are constrained by the Maximum Transmission Unit (MTU) of each link. With a typical MTU of 1500 bytes for IPv4 and a minimum of 1280 bytes for IPv6, the IP header (20 bytes for IPv4, 40 for IPv6) and UDP header (8 bytes) reduce the maximum DNS message that fits a single packet: 1472 bytes over IPv4, 1232 over IPv6. Anything larger gets split into multiple fragments.
TCP handles this gracefully because every packet is acknowledged by the recipient, and unacknowledged packets are resent. UDP offers no such feedback. In practice, UDP fragments are frequently dropped by routers and firewalls—a systemic issue given that UDP is often treated as a lower-priority transport. When fragments carrying part of a DNS message disappear, the whole message fails.
To avoid fragmentation, a DNS server should truncate an oversized response and set the DNS Truncation Flag, signaling the client to retry the query over TCP. Layer 3 unreliability is one reason QUIC, the transport for HTTP/3, implements its own reliability mechanism on top of UDP.
New Requirements for 2020
DNS Flag Day 2020 sets two practical expectations. First, DNS servers must support message transport over TCP. Second, cleartext DNS messages sent over UDP must never exceed the size limit that risks fragmentation. The intent is to make fragmentation a non-event in DNS operations while preserving TCP for reliable delivery of large messages.
Cloudflare's Position and Readiness
Cloudflare supports the Flag Day initiative, noting that in the DNS ecosystem it operates as both client and provider. When Cloudflare performs lookups on behalf of customers, it depends on other providers' compliance with standards; noncompliant implementations can break name resolution. Both the 1.1.1.1 public resolver and Cloudflare's authoritative DNS service enforce reasonable UDP message size limits and are available over TCP. No action is required from Cloudflare users. Domain operators can check compliance via the DNS Flag Day website at https://dnsflagday.net/2020/.
