📡Module 04 — The Wire Protocol: UDP, TCP & EDNS(0)

$ dig example.com +noall +comments | grep flags
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

$ dig example.com +norecurse +noall +comments | grep flags
;; flags: qr ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

$ dig org SOA +dnssec +noall +comments | grep -E 'flags|EDNS'
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 1232

$ dig org SOA +dnssec +cd +noall +comments | grep flags
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Query 2 — rd disappeared, ra stayed. You stopped asking; the server still advertises that it would. Exactly the distinction from Module 01 C4.1, now with the bit names attached.

Query 3 — two new things appeared, and they are in different places. ad is in the header flags: the resolver validated this answer cryptographically and is vouching for it. do is in the EDNS line, not the header at all — DNSSEC OK, meaning "send me the signatures". Asker sets do; answerer sets ad.

Query 4 — ad vanished and cd appeared. You told the resolver not to validate, so it did not, and therefore has nothing to vouch for. This is the most useful diagnostic pair in DNSSEC: if a name SERVFAILs normally but succeeds with +cd, the data is reachable and validation is what is failing. That is a completely different investigation from a network fault, and one option separates them.

Note udp: 1232 in query 3. That is the EDNS buffer size, and it is the subject of B3 and B4. If your output says 512, something between you and the resolver is rewriting your queries.

A 12-byte header and four sections: question, answer, authority, additional. Queries and responses share the same format — a query just has the last three sections empty.

The header holds a 16-bit transaction ID, the flags, the 4-bit opcode and RCODE, and four 16-bit counters, one per section.

The two details worth volunteering: the RCODE is only 4 bits, which is why EDNS had to extend it rather than the header being changed — DNS is always extended by adding a pseudo-record, never by altering the header, so old implementations can ignore what they do not understand. And the transaction ID is only 16 bits, which is the whole reason source-port randomisation had to be added later.

ad — Authentic Data — is set by a validating resolver to say it checked the DNSSEC signatures and they were good. cd — Checking Disabled — is set by the client to tell the resolver not to validate and to return the data regardless.

Why they matter operationally rather than academically: +cd is the fastest way to diagnose a DNSSEC failure. A name that returns SERVFAIL normally but resolves with +cd tells you the data is reachable and validation is what is failing — a completely different problem from a network fault, isolated by one flag.

Worth adding that ad is only meaningful from a resolver you trust, since anything can set a bit in a packet; the guarantee comes from the channel to the resolver, not from the bit.

$ dig org NS +dnssec +bufsize=512 +ignore +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41022
;; flags: qr rd ra ad tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

$ dig org NS +dnssec +bufsize=512 +noall +comments +stats
;; Truncated, retrying in TCP mode.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41023
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 68 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (TCP)
;; MSG SIZE  rcvd: 1442

First command — tc is set and ANSWER: 0. This is the crucial thing to understand about truncation: the truncated response contains essentially nothing. It is not a partial answer you could use. It is a one-bit message meaning "come back over TCP".

Second command — read the three lines in order and the whole mechanism is there.

• ;; Truncated, retrying in TCP mode. — dig saw tc, gave up on UDP and opened a connection
• ANSWER: 13 — the full response, which never could have fitted
• SERVER: 1.1.1.1#53(1.1.1.1) (TCP) — the transport, printed explicitly. This line is the one to look for whenever you suspect a size problem
• MSG SIZE rcvd: 1442 — nearly three times the 512-byte limit

Now the failure this sets up, and it is a genuinely common outage. If TCP/53 is blocked between the client and the server, the first query still succeeds — the truncated response arrives over UDP just fine. The retry is what fails, silently, as a timeout.

The symptom is diabolical: small answers work, large answers hang. dig example.com is fine. dig org NS +dnssec times out. A domain resolves until it adds DNSSEC or a fifth mail server, and then it half-breaks. Nobody suspects the firewall, because DNS "is working".

Now imagine this at 500 hosts behind a security group that allows UDP/53 and not TCP/53. Every DNSSEC-signed domain becomes unreliable, and the failures look random because they depend on response size, which depends on which records happen to be returned.

$ dig org SOA +dnssec +noall +comments | grep -E 'EDNS|flags'
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 1232

$ dig org SOA +dnssec +noedns +noall +comments +stats | grep -E 'EDNS|flags|MSG SIZE|SERVER'
;; flags: qr rd ra tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

With EDNS: ADDITIONAL: 1, buffer 1232, do set, and the signed answer arrives.

Without EDNS: ADDITIONAL: 0, no OPT line, and tc is set. Three consequences arrived together, and all three follow from removing one pseudo-record:

• There is nowhere to advertise a buffer size, so the limit is 512 bytes
• There is nowhere to put the do bit, so DNSSEC cannot even be requested — the whole of Module 07 depends on EDNS existing
• The signed response does not fit, so it is truncated

This is the single most useful thing to take from Part B. EDNS is not an optional optimisation bolted onto DNS. Modern DNS does not function without it. DNSSEC needs it, client-subnet needs it, cookies need it, and every response larger than 512 bytes needs it.

Which is exactly why an EDNS-hostile middlebox is so destructive — it does not degrade DNS, it removes everything added since 1999.

bufsize 512   TRUNCATED
bufsize 768   TRUNCATED
bufsize 1024  TRUNCATED
bufsize 1232  TRUNCATED
bufsize 1500  fits
bufsize 4096  fits
;; MSG SIZE  rcvd: 1442

The crossover sits between 1232 and 1500, and MSG SIZE rcvd: 1442 tells you exactly where.

Read what that means for a real deployment. With the modern 1232 default, this perfectly ordinary query — the NS set of a signed TLD — requires TCP. Not an edge case, not a pathological zone: a signed delegation with a normal number of nameservers.

So TCP/53 is not a rare fallback you can afford to leave blocked. For any DNSSEC-signed zone it is part of the normal path. Firewall rules written in 2010 that allow UDP/53 only are actively breaking DNSSEC today.

The other lesson is about response size as a design input. Every record you add to a zone apex — another nameserver, another MX, a longer SPF string, DNSSEC signatures — pushes responses toward the boundary. A zone that answers in 1200 bytes today can cross into mandatory-TCP territory because somebody added a fifth mail server. MSG SIZE rcvd is worth watching on your own apex, and D2 turns that into a check.

Both, and the interviewer is checking whether you stop at "UDP". UDP is the default because a lookup is one small question and one small answer — a single round trip, no connection state on a server handling tens of thousands of queries per second.

TCP is used in three situations: when a response is too large for the advertised UDP buffer and comes back with the tc bit set; always for zone transfers, which are far too big for a datagram; and increasingly for DNSSEC-signed responses, which routinely exceed the modern buffer size.

The point that shows current knowledge: since the buffer default dropped from 4096 to 1232 to avoid IP fragmentation, TCP fallback happens far more often than it used to. RFC 7766 makes TCP support mandatory, so a firewall allowing UDP/53 but not TCP/53 is misconfigured — and the symptom is the nastiest kind: small answers work, large ones hang.

An extension mechanism that adds an OPT pseudo-record to the additional section, carrying options the 12-byte header has no room for: a larger UDP buffer size, extra RCODE bits, and the DNSSEC OK flag.

It is negotiated per query and degrades cleanly — a server that does not understand OPT ignores it and answers without one, so the client falls back to 512 bytes.

What makes it more than trivia: modern DNS does not work without it. DNSSEC cannot even be requested without the do bit, which lives in the OPT record — so no EDNS means no DNSSEC, no responses over 512 bytes, no client-subnet, no cookies. That is why an EDNS-hostile middlebox that drops OPT queries is so destructive, and why the 2019 flag day removed the workarounds and let non-compliant domains fail. The one-line diagnosis is dig +noedns: if that works where a normal query times out, you have found one.

To avoid IP fragmentation. A 4096-byte advertisement invites responses larger than the path MTU, and a fragmented UDP datagram is lost entirely if any one fragment is dropped — which firewalls do routinely, since non-initial fragments carry no port numbers.

1232 is chosen to fit inside the 1280-byte minimum IPv6 MTU with headers to spare, so responses never fragment on a conforming path.

The security half, which is the part people miss: fragmentation is an attack surface. An off-path attacker forging a later fragment does not have to guess the transaction ID or the source port, because those only appear in the first fragment — so the standard anti-spoofing defences simply do not apply. Choosing reliable TCP fallback over fast fragmented UDP was a security decision as much as a reliability one.

13:20:41.101 IP 10.0.0.5.54219 > 8.8.8.8.53: 12043+ A? probe1.example.com. (36)
13:20:41.140 IP 10.0.0.5.38871 > 8.8.8.8.53: 41255+ A? probe2.example.com. (36)
13:20:41.178 IP 10.0.0.5.61004 > 8.8.8.8.53: 8891+  A? probe3.example.com. (36)
13:20:41.215 IP 10.0.0.5.49330 > 8.8.8.8.53: 55710+ A? probe4.example.com. (36)
13:20:41.252 IP 10.0.0.5.17662 > 8.8.8.8.53: 30402+ A? probe5.example.com. (36)

Read the two numbers that change on every line. The source port — 54219, 38871, 61004 … — and the transaction ID before the + — 12043, 41255, 8891 … Both are random per query, and both must be guessed correctly for a forgery to land.

That is the ~2³² combinations from the table, made visible. With only the transaction ID randomised it would be 65,536 — a flood of forged packets gets there in seconds. With both, an off-path attacker needs on the order of four billion attempts per race, and the genuine answer arrives long before that.

What a broken system looks like: the same source port on every line. That is a NAT device or an old resolver de-randomising ports — NAT is the common culprit, because a device that rewrites source ports to a predictable range silently undoes the 2008 fix for every client behind it. Worth checking on any network where you do not control the middleboxes.

If you are inside a container behind a DNS proxy, you will see the proxy's ports rather than the resolver's, which tells you about the proxy and not much else.

An attacker gets a resolver to cache a forged answer by racing the real nameserver with a spoofed UDP response. To be accepted, the forgery must match the source address, destination port, transaction ID and question, and arrive first — and originally the transaction ID was the only genuinely unknown part, just 16 bits.

Kaminsky's refinement made the race repeatable: query random subdomains for an unlimited supply of attempts, and put a poisoned NS record in the authority section so a single win hijacks the entire zone rather than one name.

Defences: source-port randomisation, which roughly doubles the entropy to 2³²; 0x20 case randomisation, which is free because DNS matching is case-insensitive but case is preserved; DNS cookies; and avoiding fragmentation.

The distinction worth drawing explicitly: all of those raise the cost of guessing — none of them makes forgery impossible. DNSSEC is the only one that solves the problem, because it makes forged data cryptographically detectable rather than merely improbable.

A resolver randomises the capitalisation of the name it queries — ExAMpLe.cOM — and requires the response to echo it back exactly. Any reply with different capitalisation is discarded.

It works because DNS matching is case-insensitive while case is preserved on output, so it adds roughly one bit of entropy per letter at zero protocol cost and with no compatibility flag day.

Where it earns credit: it is a genuinely elegant defence that exploits an accident of the 1987 specification, and it is the practical payoff of the case-insensitivity rule from Module 01 A4. It is also worth knowing it can trip up badly written authoritative servers and middleboxes that normalise case, which is one of the rarer causes of intermittent resolution failure.

$ ./response-size.sh seamless.se
TYPE       BYTES    STATUS (limit 1232)
SOA        105      fine
NS         180      fine
A          72       fine
MX         200      fine
TXT        299      fine
$ ./response-size.sh org
NS         1442     OVER - needs TCP

seamless.se is comfortable everywhere — largest response under 300 bytes. It is an unsigned zone with four nameservers and one SPF record.

org needs TCP for its NS set, because it is DNSSEC-signed and every RRset carries RRSIG records alongside it. That single contrast is the whole lesson: signing a zone roughly triples its response sizes.

So use this before you turn DNSSEC on, not after. A zone sitting at 400 bytes today will be near 1200 once signed, and a zone at 900 will require TCP for ordinary queries. Neither is a reason not to sign — it is a reason to confirm TCP/53 works end to end first, which is exactly the check in D1.

The other things that quietly grow responses: adding nameservers, adding mail servers, long SPF or DKIM records, and TXT records accumulating vendor verification tokens that nobody ever removes. The apex is where they all land, which is why the apex is what to measure.

1. +ignore. It tells dig not to retry over TCP, so the truncated response is shown as received — flags: ... tc with ANSWER: 0. Without it, dig transparently retries and you never see the truncation that is the whole problem.

dig @$SERVER example.com NS +dnssec +bufsize=512 +ignore +noall +comments

2. The SERVER: line.

;; SERVER: 1.1.1.1#53(1.1.1.1) (TCP)

dig also prints ;; Truncated, retrying in TCP mode. above it. The (TCP) marker is the durable evidence — the retry message is easy to lose in a pipeline.

3. Two commands, one each.

dig @$SERVER name NS +dnssec +tcp    # blocked TCP -> times out here
dig @$SERVER name SOA +noedns        # EDNS-hostile -> SUCCEEDS here while plain query fails

The patterns are opposite and cannot be confused. TCP blocked: the small query works, the truncated response arrives fine, and only the +tcp attempt times out. EDNS-hostile: even the small query times out, and +noedns is what makes it work — because the server or middlebox is discarding the OPT record, not reacting to size.

4. Because signing roughly triples response size. Every RRset in a signed zone is accompanied by RRSIG records, so an NS set that was 300 bytes becomes 1400. Unsigned domains on the same subnet stay under 1232, never truncate, never fall back to TCP, and therefore never touch the blocked port. The firewall rule has been wrong for years and only became visible when this zone was signed.

5. 1232 fits inside the minimum IPv6 MTU of 1280 with headers to spare, so a DNS response never fragments on any conforming path. At 4096 the server happily emits a 3,000-byte datagram, IP splits it, and three things go wrong: losing any one fragment loses the whole response with no retransmission; firewalls drop non-initial fragments because they carry no port numbers to filter on; and — see 7 — fragments are a spoofing bypass.

6. Four fields: source address, destination port, transaction ID, and the echoed question — plus the requirement to arrive before the real answer. Randomised today: the transaction ID (16 bits, always was) and the source port (~16 bits, added in 2008). Together roughly 2³² combinations. 0x20 case randomisation adds about one bit per letter of the name on top.

7. Because a non-initial fragment contains neither of them. The transaction ID and the UDP port numbers appear only in the first fragment. An attacker forging a later fragment has nothing to guess — source-port randomisation, the transaction ID and 0x20 all provide exactly zero protection against it. Reassembly then produces a response the resolver accepts as genuine. That is why fragmentation avoidance is a security control and not merely a reliability tweak.

The five things most people miss:

1. +ignore in requirement 1. Without it dig hides the exact symptom you are trying to demonstrate, and you conclude everything is fine
2. Reading (TCP) on the SERVER: line. It is the one durable artefact that a fallback occurred
3. Requirement 4 — that the firewall was already broken. The signing did not cause the fault, it revealed it. Saying so changes who owns the fix
4. Requirement 5 — that 1232 comes from the IPv6 minimum MTU, not from Ethernet's 1500. That is why the number looks arbitrary and is not
5. Requirement 7 — that fragmentation bypasses the defences entirely rather than merely weakening them. This is the point that turns "avoid fragmentation" from a performance tip into a security requirement

It was designed for a 512-byte datagram, so every byte counted: 16-bit transaction ID, 16 bits of flags and codes, four 16-bit counters.

It forced two things. The 4-bit RCODE ran out, so EDNS added eight more bits in the OPT record rather than changing the header. And the 16-bit transaction ID proved far too little entropy against spoofing, which is why source-port randomisation had to be bolted on in 2008.

The general principle: DNS is extended by adding a pseudo-record, never by altering the header, because old implementations ignore records they do not recognise.

The response did not fit in the permitted UDP size. It contains essentially nothing — usually zero answer records. It is a one-bit instruction meaning "ask again over TCP", not a partial answer you can use.

The client then opens a TCP connection and repeats the query. If TCP/53 is blocked, that retry times out and the symptom is "small answers work, large ones hang".

The advertised UDP buffer size, the extended RCODE bits, the do (DNSSEC OK) flag, and any EDNS options such as cookies or client-subnet.

It sits in the ADDITIONAL section — which is why almost every response shows ADDITIONAL: 1 even with nothing extra to send.

Without it you are limited to 512 bytes and cannot request DNSSEC at all, since the do bit has nowhere else to live.

The minimum IPv6 MTU is 1280 bytes; 1232 leaves room for IPv6 and UDP headers. A response of that size never fragments on any conforming path.

It replaced the old default of 4096, which invited fragmentation — and fragmented UDP is lost entirely if any fragment is dropped, is filtered by many firewalls, and is a spoofing bypass.

The trade-off accepted deliberately: more TCP fallback, in exchange for never fragmenting.

TCP/53 is blocked somewhere on the path. Signed responses are roughly three times larger, so they truncate and require a TCP retry that the firewall drops.

Confirm with dig name NS +dnssec +tcp — if that times out while the plain query works, that is the answer.

Second hypothesis if +tcp is fine: an EDNS-hostile middlebox, tested with +noedns.

A server or middlebox that drops or rejects queries containing an OPT record instead of ignoring it — the RFC 8906 problem.

It is severe because every modern resolver sends EDNS by default, so such a server looks completely dead to the current internet while responding perfectly to an old tool.

This was common enough that resolver operators coordinated a DNS flag day in 2019 and removed the workarounds, after which non-compliant domains simply stopped resolving.

Source address (trivially forged), destination port, transaction ID, and the echoed question — arriving before the genuine response.

Randomised today: transaction ID (16 bits) and source port (~16 bits), for roughly 2³² combinations, plus about a bit per letter from 0x20 case randomisation.

All of that is probabilistic. Only DNSSEC makes forged data cryptographically detectable rather than merely unlikely.

A non-initial fragment carries neither the transaction ID nor the UDP port numbers — they appear only in the first fragment. So an attacker forging a later fragment has nothing to guess, and source-port randomisation, the transaction ID and 0x20 provide zero protection.

Reassembly then yields a response the resolver treats as genuine. Avoiding fragmentation removes the bypass entirely, which is why RFC 9715 is a security document as much as a performance one.

+ignore — do not retry over TCP, so the tc bit is visible as received. Proves the response was too large.

+tcp — force TCP. A timeout here with UDP working proves TCP/53 is blocked.

+noedns — send no OPT record. Success here where a normal query fails proves an EDNS-hostile server or middlebox.

+bufsize=N — set the advertised buffer, to find the size at which a real response starts truncating.

+cd — disable validation; success here proves the fault is DNSSEC rather than transport.

Because truncation is correct, healthy behaviour. It is the protocol working as designed: the response was larger than the advertised buffer, so the server said so and the client retried over TCP.

Alerting on it produces constant noise from every DNSSEC-signed zone. What is worth alerting on is the TCP retry failing, and response sizes trending toward the buffer limit.

A note on this module's transcripts, in the interest of honesty. Modules 01–03 used output captured live. This module could not: the environment it was written in sits behind a DNS proxy that intercepts port 53, normalises every EDNS buffer to 512, strips the tc bit and blocks direct TCP — precisely the interception warned about at the top of the page. The transcripts here are therefore reconstructed from the specifications and from dig 9.18's documented output format, not captured. Run them on a real machine; the shapes will match, and if they do not, you have found a middlebox.

Specifications verified directly: RFC 1035, RFC 5452, RFC 6891, RFC 7766, RFC 8906, RFC 9210, RFC 9499, RFC 9715, and the IANA DNS Parameters registry.

Question selection cross-referenced against publicly published 2026 DNS and networking interview question sets:

• Interview Questions & Answers for DNS — DevOpsSchool — "Is DNS using TCP or UDP?" verbatim
• Top 25 DNS Interview Questions and Answers for 2026 — nitizsharma.com — DNSSEC with cryptographic detail, DNS resolution failure causes
• Top 30 Most Common DNS Interview Questions — Verve AI — DNS spoofing and security risks, DNS and the OSI model
• 75+ Network Engineer Interview Questions for 2026 — Taggd

Answers were rewritten and deepened rather than reproduced. "Is DNS TCP or UDP?" is answered "UDP, and TCP for zone transfers" almost everywhere — which has been an incomplete answer since the buffer default dropped to 1232 and made TCP fallback part of the ordinary path for every signed zone.