DNS Architecture

How does a single naming system serve billions of devices, resolve trillions of queries daily, and remain available despite constant attacks and failures? The answer lies in DNS's elegant architecture—a distributed, hierarchical design that has scaled from a few hundred ARPANET hosts to the modern internet.

DNS architecture embodies lessons learned from decades of distributed systems research. Its design decisions—hierarchy, delegation, caching, redundancy—are textbook examples of engineering for scale and reliability.

This page explores the architectural principles that make DNS work, from the conceptual namespace tree to the practical deployment of servers worldwide.

DNS names exist in a hierarchical namespace organized as an inverted tree. Understanding this structure is fundamental to understanding DNS architecture.

The DNS Tree:

The DNS namespace is a rooted tree where:

• The root (represented by an empty label or a lone dot .) is at the top
• Top-Level Domains (TLDs) branch from the root (.com, .org, .uk)
• Second-Level Domains branch from TLDs (example.com, bbc.co.uk)
• Subdomains continue branching indefinitely (mail.example.com, www.eng.example.com)

Domain names are written left-to-right (most specific to least specific), but the tree reads right-to-left (root to leaf).

Example: www.engineering.example.com.

• . — Root
• com — Top-level domain
• example — Second-level domain
• engineering — Subdomain of example.com
• www — Host within engineering.example.com

Fully Qualified Domain Names (FQDNs):

An FQDN specifies a name's complete path from the root:

• www.example.com. (trailing dot indicates root)
• Without trailing dot, the name may be treated as relative

Label Constraints:

Each label (component) in a DNS name has rules:

• Maximum 63 characters per label
• Maximum 253 characters total for complete name
• Allowed characters: letters (a-z), digits (0-9), hyphens (-)
• Cannot start or end with hyphen
• Case-insensitive (but case-preserving)

Internationalized Domain Names (IDN):

Non-ASCII characters (Chinese, Arabic, etc.) are supported via Punycode encoding:

• münchen.de → xn--mnchen-3ya.de
• Users see native script; DNS infrastructure sees ASCII

Two fundamental concepts—domains and zones—are often confused. Understanding the distinction is essential for grasping DNS architecture.

Domain:

A domain is a node in the DNS tree and all nodes beneath it. It's a logical, hierarchical concept.

• example.com is a domain that includes:
  • www.example.com
  • mail.example.com
  • engineering.example.com
  • All subdomains beneath these

Domains can be nested: engineering.example.com is a subdomain within example.com, which is within com, which is within the root domain.

Zone:

A zone is an administrative unit—a contiguous portion of the namespace for which a particular set of servers is authoritative.

• A zone contains the DNS records that its authoritative servers directly manage
• Zones are bounded by delegation points where authority is delegated to other zones

Example Scenario:

Consider example.com with:

• Main site at www.example.com
• Mail at mail.example.com
• UK operations delegated to a separate zone uk.example.com

The example.com domain includes: www.example.com, mail.example.com, uk.example.com, london.uk.example.com, and all other descendants.

The example.com zone includes: www.example.com, mail.example.com, and NS records pointing to the uk.example.com zone—but NOT the actual records for uk.example.com or its descendants (those are in a different zone).

Zone Files:

Zone data is traditionally stored in zone files—text files following RFC 1035 format:

Delegation is the mechanism that makes DNS scalable. It allows the namespace to be subdivided, with different authorities managing different portions.

The Delegation Chain:

Starting from the root, authority is delegated down the tree:

1. Root Zone: ICANN/IANA manages the root zone
2. TLD Delegation: Root delegates .com to Verisign, .org to PIR, etc.
3. Domain Delegation: .com delegates example.com to whoever registered it
4. Subdomain Delegation: example.com can delegate uk.example.com to another authority

How Delegation Works:

Delegation is established via NS (Name Server) records at the parent zone:

; In the .com zone file:
example.com.    IN  NS  ns1.example.com.
example.com.    IN  NS  ns2.example.com.

; Glue records (required because ns1/ns2 are within example.com)
ns1.example.com.  IN  A   93.184.216.1
ns2.example.com.  IN  A   93.184.216.2

When a resolver asks the .com servers about www.example.com, they respond with a referral (not an answer): "Ask these servers about example.com."

Authoritative vs. Non-Authoritative Responses:

Authoritative Response:

• Comes from a server that has the zone file loaded
• Flag AA (Authoritative Answer) is set
• Considered definitive answer

Non-Authoritative Response:

• Comes from a cache or referral
• AA flag is NOT set
• May be stale (though still within TTL)

Lame Delegation:

A "lame delegation" occurs when NS records point to a server that:

• Doesn't respond at all
• Responds but isn't authoritative for the zone
• Responds with REFUSED or SERVFAIL

Lame delegations cause resolution failures and should be monitored and corrected.

DNS infrastructure operates in distinct tiers, each with specific responsibilities:

Tier 1: Root Servers

The 13 root server "identities" (a.root-servers.net through m.root-servers.net) are operated by 12 organizations:

• Verisign (A, J)
• USC-ISI (B)
• Cogent (C)
• University of Maryland (D)
• NASA (E)
• ISC (F)
• US DoD (G)
• US Army (H)
• Netnod (I)
• RIPE NCC (K)
• ICANN (L)
• WIDE Project (M)

Despite "13 root servers," hundreds of physical servers exist worldwide via anycast—multiple servers share the same IP address, with routing delivering queries to the nearest instance.

Tier 2: TLD Servers

Each TLD has its own authoritative servers:

• gTLDs: .com and .net operated by Verisign; .org by PIR; new gTLDs by various registries
• ccTLDs: Each country manages its own (.uk by Nominet, .de by DENIC, etc.)
• Infrastructure TLDs: .arpa for reverse DNS and infrastructure

TLD servers handle enormous query volumes—.com alone processes billions of queries daily.

Tier 3: Authoritative Servers

Every domain needs authoritative servers. Options include:

• Self-hosted: Run your own BIND/NSD/PowerDNS servers
• Registrar DNS: Many registrars include basic DNS hosting
• Managed DNS: Specialized providers (Cloudflare, AWS Route 53, NS1, Dyn)
• Enterprise: Internal DNS servers for private zones

Tier 4: Recursive Resolvers

Recursive resolvers do the actual resolution work:

• ISP Resolvers: Your ISP provides default resolvers
• Enterprise Resolvers: Companies run internal resolvers
• Public Resolvers: Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9)

DNS is designed for extreme availability. Multiple redundancy mechanisms ensure the system survives component failures.

Multiple Authoritative Servers:

Every zone should have at least two authoritative servers:

• Different physical locations
• Different networks/ASNs
• Ideally different providers

The DNS protocol queries multiple servers automatically—if one fails, others respond.

Anycast Routing:

Major DNS infrastructure uses anycast—the same IP address announced from multiple geographic locations:

• Client queries go to the nearest (by routing metric) instance
• If one instance fails, routing converges to the next nearest
• No client configuration change needed
• Provides both redundancy and latency reduction

Zone Transfers:

To keep multiple authoritative servers synchronized:

AXFR (Full Zone Transfer):

• Transfer entire zone from primary (master) to secondary (slave)
• Used for initial synchronization or after extended outage
• Can be bandwidth-intensive for large zones

IXFR (Incremental Zone Transfer):

• Transfer only changes since a specific serial number
• Much more efficient for frequently updated zones
• Requires primary to maintain change history

NOTIFY:

• Primary notifies secondaries when zone changes
• Secondaries immediately request transfer (rather than waiting for refresh interval)
• Reduces propagation delay for updates

Caching is not merely an optimization—it's fundamental to DNS's ability to scale. Understanding caching architecture is essential for DNS operations.

Cache Hierarchy:

1. Application Cache: Some applications maintain their own DNS cache
2. Browser Cache: Web browsers cache DNS resolutions (typically minutes)
3. OS Stub Resolver Cache: Operating system caches for all applications
4. Local Resolver Cache: If running a local resolver (dnsmasq, systemd-resolved)
5. Recursive Resolver Cache: ISP or public resolver (largest, most impactful)
6. Authoritative Response Caching: Some authoritative servers cache computed responses

TTL (Time-To-Live):

Every DNS record includes a TTL specifying how long it may be cached:

www.example.com.  3600  IN  A  93.184.216.34
                  ^^^^^---- TTL: 3600 seconds (1 hour)

TTL Design Considerations:

Typical TTL Strategies:

• Static content: 24 hours or more
• Standard websites: 1-4 hours
• Dynamic/load-balanced: 5-15 minutes
• Failover scenarios: 1-5 minutes
• Pre-change preparation: Reduce TTL before planned changes

Negative Caching:

DNS caches negative results (NXDOMAIN—domain doesn't exist) to prevent repeated queries for non-existent names:

• Controlled by SOA record's minimum TTL field
• Typically 5 minutes to 1 hour
• Prevents amplification of typo-related queries
• Can delay correction after fixing NXDOMAIN issues

Cache Poisoning Prevention:

Caches are potential attack targets. Defenses include:

• Source Port Randomization: Makes spoofing harder
• TXID Randomization: Transaction ID verification
• 0x20 Bit Encoding: Case randomization in queries
• DNSSEC Validation: Cryptographic proof of authenticity

Modern DNS deployments employ sophisticated patterns beyond basic client-resolver-authoritative models.

Split-Horizon DNS:

Different responses for different query sources:

• Internal clients: See private IP addresses (mail.company.com → 10.0.0.50)
• External clients: See public IP addresses (mail.company.com → 203.0.113.50)

Implemented via:

• BIND views
• Separate internal/external resolvers
• Smart DNS load balancers

GeoDNS:

Different responses based on client geographic location:

• European users directed to European servers
• Asian users directed to Asian servers
• Implemented in CDNs for latency optimization
• Uses GeoIP databases on resolver or authoritative server

DNS Load Balancing:

Distributing traffic across multiple servers:

• Round-robin: Multiple A records; clients receive in varying order
• Weighted: Some records returned more frequently
• Health-checked: Only healthy servers included in responses
• Latency-based: Geographic/network-aware routing

Encrypted DNS Architectures:

DNS over HTTPS (DoH):

• DNS queries sent via HTTPS to port 443
• Indistinguishable from regular web traffic
• Prevents ISP interception/logging
• Supported by major browsers (Firefox, Chrome)

DNS over TLS (DoT):

• DNS queries sent via TLS to port 853
• Distinct traffic pattern (visible but encrypted)
• Easier to implement at network level
• Supported by Android 9+, systemd-resolved

DNS over QUIC (DoQ):

• Using QUIC transport for DNS
• Lower latency than DoT/DoH
• Emerging standard (RFC 9250)