EDNS, Large Responses and TCP Fallback

What EDNS adds to a DNS message

EDNS does not change the DNS header. Instead it adds a pseudo-record of type OPT to the additional section of the query and the response. It is called a pseudo-record because it is never stored in a zone or cached; it only describes the message it travels in. The OPT record carries:

• UDP payload size: the largest UDP response the sender can reassemble.
• Extended RCODE and version: extra response-code bits and an EDNS version number, which is still 0.
• Flags: most importantly the DO (DNSSEC OK) bit, which asks the server to include DNSSEC signatures.
• Options: extensions such as Client Subnet (RFC 7871), DNS Cookies (RFC 7873) and Extended DNS Errors (RFC 8914), which explain why a resolver returned SERVFAIL.

If a server does not understand EDNS, it should reply without an OPT record, and the client then knows to stay within 512 bytes. Years ago many resolvers worked around broken servers that simply dropped EDNS queries by retrying without EDNS. DNS Flag Day 2019 ended those workarounds in major resolvers, so a server that silently ignores EDNS queries now just looks unreachable.

Why answers get large

Most simple A record answers are well under 200 bytes. The ones that grow past the limits usually involve:

• DNSSEC: signatures roughly double or triple an answer, and DNSKEY responses during a key rollover, when old and new keys are published together, are often the largest a zone ever serves.
• Many TXT records: SPF policies plus a stack of domain verification tokens at the apex add up quickly.
• Long record sets: dozens of A or AAAA records for one name, or a referral with many name servers and glue addresses.

Truncation and TCP fallback

When an answer is bigger than the size the client advertised, the server sends what it can, sets the TC flag, and the client repeats the query over TCP. TCP has no practical size problem because the stream handles segmentation, at the cost of an extra round trip for the handshake. RFC 7766 made TCP support a requirement for DNS implementations, and RFC 9210 sets it as an operational requirement for servers on the Internet.

The reason to avoid big UDP answers is IP fragmentation. A 4,000-byte UDP response has to be split into several IP fragments, and only the first fragment carries the UDP header. Firewalls and NAT devices often drop the rest, so the client waits, times out and may never think to try TCP because it never saw the TC flag. Fragments have also been used in cache poisoning attacks, because a later fragment can be spoofed without guessing the query ID. MTU, Fragmentation and Big DNS Answers covers the network side in detail, and TCP vs UDP and Why DNS Uses Both explains the two transports.

Testing with dig

dig shows the EDNS details in the OPT pseudosection. These examples ask for a signed DNSKEY set, first with a 1232-byte buffer and then with an artificially small one.

$ dig @ns1.example.com example.com DNSKEY +dnssec +bufsize=1232

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41022
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
...
;; MSG SIZE  rcvd: 1018

$ dig @ns1.example.com example.com DNSKEY +dnssec +bufsize=512 +ignore
;; flags: qr aa tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

$ dig @ns1.example.com example.com SOA +tcp +short
ns1.example.com. hostmaster.example.com. 2026101501 7200 3600 1209600 3600

The +ignore option shows the truncated reply instead of retrying. The final command checks that the server answers over TCP at all. If it times out while the UDP query works, a firewall is almost certainly blocking TCP on port 53. Run the same tests from more than one network, because the device dropping packets is often close to the client; see Why does DNS work on one network but not another?

Operator checklist

For authoritative servers

• Set the maximum UDP response size to 1232 bytes, or let your server software use that default if it already does.
• Allow TCP and UDP on port 53, inbound to your servers, in every firewall and security group.
• Keep apex TXT sets tidy, and prefer smaller DNSSEC algorithms such as ECDSA P-256 over large RSA keys to keep signed answers small.
• Respond to EDNS queries correctly, including unknown EDNS versions and options, rather than dropping them.

For resolvers and networks

• Advertise 1232 bytes from recursive resolvers and allow outbound TCP on port 53 to the Internet.
• Turn off DNS inspection features on firewalls that cap DNS messages at 512 bytes or strip the OPT record.
• Watch for SERVFAIL on signed domains only, or timeouts on DNSKEY queries; both are classic signs of a size problem.

How DNS Panopticon helps

Domain Visualizer resolves records through public DNS-over-HTTPS resolvers, so it does not test the UDP and TCP path between your users and your servers. It does query the records most likely to be large, including TXT, DNSKEY and DS at the apex, and reports DNSSEC and delegation findings. If those lookups succeed there but fail from your own network, the difference points at a size or transport problem on that path, and the dig tests above will usually find it.