GUIDE 01.03 INFRASTRUCTURE CORE 8 min read

DNS: How Domain Names Find Servers

Hierarchical tree resolution, recursive resolvers, root nameservers, Anycast routing, and TTL caching failure modes.

Author: Complexity Architecture Staff

•

Verified against: RFC 1034 & RFC 1035

1. Why Do Systems Need DNS?

Computers communicate across the internet using numeric IP addresses (e.g. IPv4 `198.51.100.24` or IPv6 `2001:db8::1`).

Humans, however, remember names like complexity.dev or api.github.com.

The Domain Name System (DNS) is the globally distributed, hierarchical database responsible for translating human-readable domain names into machine-routable IP addresses and service records.

2. The Hierarchical Resolution Tree

DNS is organized as an inverted tree read from right to left:

                      [ Root Level (.) ]
                              │
            ┌─────────────────┼─────────────────┐
            ▼                 ▼                 ▼
        [ .com ]           [ .org ]          [ .io ] (TLD Authority)
            │
            ▼
    [ complexity.io ]                          (Authoritative Zone)
            │
            ▼
     A Record: 198.51.100.24

Root Nameservers (`.`): 13 named root authority systems (A through M), operated by 12 independent organizations and replicated via Anycast BGP routing across over 1,500 physical server clusters worldwide.
Top-Level Domain (TLD) Nameservers: Managed registries responsible for domains ending in specific extensions (`.com`, `.net`, `.org`, ccTLDs like `.uk`, `.de`).
Authoritative Nameservers: The final authority that holds the actual DNS records for a domain (A, AAAA, CNAME, MX, TXT).

3. Recursive vs Iterative Resolution Flow

When a client application makes a DNS query, two types of resolution occur:

Recursive Query (Client to Resolver): The client (stub resolver) asks its configured recursive resolver (such as `1.1.1.1` or corporate DNS) to do all the work and return the final answer.
Iterative Queries (Resolver to Hierarchy): If the answer is not cached, the recursive resolver queries:
- Root server → returns TLD server IP.
- TLD server → returns Authoritative server IP.
- Authoritative server → returns final record IP.

4. TTL Caching & Failure Modes

Every DNS response carries a Time-To-Live (TTL) specifying how many seconds downstream resolvers and clients may cache the record.

WARNING Production Failure: Misconfigured TTL

Setting TTL too high (e.g. 86400s / 24 hours) prevents rapid disaster recovery failover if an IP address goes down. Conversely, setting TTL too low (e.g. 5s) subjects authoritative nameservers to massive query amplification and increases cold-start request latency for every end user.

5. Inside the OS: getaddrinfo() & NSSwitch

Under Linux, applications invoke the POSIX standard function getaddrinfo() provided by glibc.

The lookup order is controlled by /etc/nsswitch.conf:

hosts: files mdns4_minimal [NOTFOUND=return] dns

The OS first checks /etc/hosts before transmitting UDP/TCP port 53 packets to the nameservers specified in /etc/resolv.conf.

6. Engineering Knowledge Verification

KNOWLEDGE CHECK

Why are root nameserver IP addresses replicated via Anycast BGP routing rather than relying on a single physical host per letter?

7. Key Takeaways & References

Hierarchical Authority: Queries traverse Root (.) → TLD (.com) → Authoritative Zone.
Caching Trade-off: TTL controls caching duration versus failover agility.
Anycast Resilience: Shared IPs ensure high availability across globally replicated server footprints.