DNS Design Trade-offs: Recursive vs Iterative Lookup, UDP vs TCP

01 · Design rationale

Why DNS is Hierarchical

A hierarchy lets responsibility — and load — be distributed instead of centralized, which is the only way a naming system scales to hundreds of millions of domains.

If one organization had to know the IP address of every domain on the internet, that single database would need to handle every lookup globally and would need to be updated by every domain owner through one bottlenecked process. A hierarchy solves both problems: each level only needs to know about the level directly below it ("who is authoritative for .com?"), and each domain owner controls their own zone independently, with no coordination required with anyone else.

02 · Query modes

Recursive vs Iterative Lookup

These describe two different relationships in the same overall lookup — not two different protocols.

Recursive query (client ↔ resolver)

The client asks once and expects a complete final answer — the resolver does all the remaining work and the client never talks to root/TLD/authoritative servers directly.

Iterative query (resolver ↔ hierarchy)

The resolver asks the root, gets a referral (not a final answer), asks the TLD, gets another referral, and so on — each server responds with "I don't know, but here's who might" rather than resolving on the resolver's behalf.

03 · Transport

Why DNS Primarily Uses UDP

Most DNS queries and responses are small enough to be answered in a single request/response exchange — UDP avoids handshake and connection-state overhead, which keeps the common path fast.

TCP requires a three-way handshake before application data is exchanged — meaningful overhead when the payload of many ordinary DNS lookups is small (historically under 512 bytes, and still often comfortably small even with EDNS0). UDP has no handshake and no connection state: the client sends one datagram, and the server replies with one. For the majority of simple A/AAAA lookups, that lower overhead matters more than building every query on a full TCP connection.

04 · Transport, part 2

When DNS Uses TCP

DNS also uses TCP when UDP is no longer a good fit — especially for zone transfers and for queries whose replies are truncated or too large for the path to handle comfortably over UDP.

Large responses

Responses larger than the classic 512-byte UDP limit can often still fit over UDP with EDNS0, but not always. If the server sets the TC (truncated) flag because the UDP answer would be incomplete, the client retries the same query over TCP to fetch the full response.

Zone transfers (AXFR/IXFR)

When a secondary nameserver syncs an entire zone from a primary, that's a bulk, reliability-sensitive transfer — AXFR runs over TCP (RFC 5936), while IXFR (RFC 1995) may be answered over UDP when the response fits in a single packet and retried over TCP when it does not. TCP support is required of full DNS implementations (RFC 7766).

DNSSEC responses

DNSSEC-signed responses include extra signature data, increasing response size. Many still succeed over EDNS0-enabled UDP, but truncation and TCP retry become more common on DNSSEC-enabled zones, especially when answers contain many records.

bashIllustrative truncation demo — hypothetical signed zone example.net; sizes and counts are examples, not captured output

# Small UDP buffer, no automatic TCP retry (+ignore): the server truncates
$ dig +ignore +dnssec +bufsize=512 DNSKEY example.net @ns1.example.net
;; flags: qr aa tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1   <- tc = truncated, retry over TCP

# Same question over TCP: the full signed answer fits
$ dig +tcp +dnssec DNSKEY example.net @ns1.example.net
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1   <- DNSKEY + RRSIG, well over 512 bytes

Without +ignore, dig performs this retry itself, which is exactly what a stub or recursive resolver does when it sees the TC flag.

05 · Pitfalls

Common Mistakes

The same handful of misunderstandings show up repeatedly in design discussions and production incidents.

06 · Reference

FAQs & Real-World Architectures

Practical questions, and how large-scale production systems actually combine these DNS mechanisms.

FAQs

Why do some lookups feel instant and others slow?

Instant lookups are cache hits (browser, OS, or resolver cache already has the answer); slow ones are cold lookups walking the full hierarchy, or hitting a resolver that's itself under load.

Can two domains share the same IP?

Yes — this is normal for shared hosting and reverse proxies. The Host header (an HTTP-layer detail, not DNS) is what lets a single IP serve many different domains correctly.

Why does changing my DNS records sometimes seem to have no effect?

Almost always a caching issue — your machine, browser, or recursive resolver is still reusing an older answer. The TTL sets the intended refresh window, but the visible switchover is not perfectly synchronized across every cache on the internet.

Real-world architectures

Global CDN (Cloudflare/Fastly/Akamai style)

DNS often returns an anycast or region-specific entry point, then the CDN network takes over to deliver the user to a nearby edge and serve cached content efficiently. See CDN fundamentals for the deeper edge-caching model.

Multi-region active-active service

Latency-based or geo-based DNS routing can send resolvers toward a nearby healthy region, combined with short TTLs and continuous health checks. That improves regional steering, but recovery is still measured in cache windows rather than the near-immediate reaction of an in-path load balancer.

Key takeaways

The DNS hierarchy exists to distribute both load and administrative control — no single party needs global knowledge.
Recursive describes the client↔resolver relationship; iterative describes the resolver↔hierarchy relationship — don't mix them up.
UDP is the default for the fast common case; TCP is used for zone transfers and for replies that must be retried after UDP truncation, which becomes more common with large or DNSSEC-heavy answers.
Most real-world DNS incidents trace back to caching/TTL misunderstandings, dangling records, or over-reliance on DNS as the only layer of load balancing/failover.