DNS Architecture

What is DNS?

Computers talk in IP addresses (192.168.1.1). Humans talk in domain names (google.com). DNS (Domain Name System) maps human-readable names to IP addresses.

It is a distributed, hierarchical database. There is no single server that knows every domain name.

The Hierarchy

A query for www.example.com. (note the trailing dot) traverses a tree structure.

1. Root Servers (.)

• There are 13 named root server identities (A–M), each reachable through IPv4 and IPv6 addresses and many distributed instances. IANA root server list.
• Managed by organizations like NASA, Verisign, ICANN.
• They know where the TLD Servers live.

2. TLD Servers (.com, .org, .io)

• Top-Level Domain servers.
• The .com TLD servers know which Name Servers are responsible for google.com or amazon.com.

3. Authoritative Name Servers

• The final destination. These hold the actual DNS records (A, CNAME, MX).
• Operated by the domain owner or a DNS hosting provider; the registrar maintains the delegation selected by the owner.

DNS Resolution Flow

What happens when you type google.com?

Interactive: Recursive Lookup Flow

1. Browser Cache: The browser may reuse a cached answer, depending on its resolver configuration.
2. OS Resolver: Uses its configured name services, which can include a hosts file, a local cache and DNS.
3. Recursive Resolver (ISP): Your computer asks your ISP (or 8.8.8.8).
   • If Resolver has it cached -> Returns IP.
   • If NOT cached -> resolver performs iterative queries to find the answer.

The Recursive Dance

If the Resolver (8.8.8.8) knows nothing:

1. Resolver -> Root: "Where is .com?"
   • Root: "I don't know IP, but here are the .com TLD servers."
2. Resolver -> TLD: "Where is google.com?"
   • TLD: "Here is the delegation to the domain’s authoritative name servers."
3. Resolver -> Authoritative (NS1): "What is IP of google.com?"
   • NS1: "Here is an address record and its TTL." (The diagram’s address is illustrative.)
4. Resolver -> You: "Here is the IP." (And Caches it for TTL seconds).

Key Concepts

Record Types

• A: Maps name to IPv4 (1.2.3.4).
• AAAA: Maps name to IPv6 (2001:db8::1).
• CNAME: Alias. Maps name to another name (www.google.com -> google.com).
• MX: Mail Exchange. Where to route emails.
• TXT: Text. Used for verification (SPF, DKIM, Google Search Console).

Time To Live (TTL)

How long (in seconds) a Resolver should cache the record.

• High TTL (24h): Less traffic to authoritative servers. A cached old answer may remain until its remaining TTL expires. (Good for stable APIs).
• Low TTL (60s): More lookups. Potentially faster DNS changes, subject to caches and health-check delays. (Good for Load Balancing).

Anycast Routing

How do root server identities serve users worldwide? Anycast. Multiple servers around the world announce the same IP address via BGP. The network routes your request to the instance selected by routing policy, which is not necessarily geographically closest.

Code Example: Querying DNS

This example requires the dnspython package and network access.

import dns.resolver

# 1. Simple lookup
def lookup_ip(domain):
    try:
        answers = dns.resolver.resolve(domain, 'A')
        for rdata in answers:
            print(f"IP: {rdata.address}")
    except Exception as e:
        print(f"Lookup failed: {e}")

# 2. Get Name Servers (NS)
def get_nameservers(domain):
    answers = dns.resolver.resolve(domain, 'NS')
    for r in answers:
        print(f"NS: {r.target}")

# Usage
# lookup_ip("google.com")
# get_nameservers("google.com")

Interview Tips 💡

• "What happens when you type URL in browser?" — DNS is step 1. Mention Caching hierarchy!
• "Recursive vs Iterative?" — Your computer makes a Recursive request (Get me the answer). The ISP makes Iterative requests (I'll ask Root, then TLD...).
• "CNAME chasing" — A resolver follows the alias chain; cached or bundled records may avoid an extra network round trip.
• "Geo-DNS" — Geolocation routing and latency-based routing are different policies; neither guarantees the nearest physical server.

Worked decision: a planned address change

Suppose an API record currently has a one-hour TTL and a move is planned for 18:00. Lowering the TTL at 17:55 does not erase answers already cached for an hour. Lower it far enough in advance for those answers to expire, keep the old endpoint serving during the overlap, then compare answers from the authoritative servers and several recursive resolvers. A stale result from one resolver is not evidence that the new authoritative record failed to publish.

DNS resolution and caching are specified in RFC 1034 and RFC 1035.

Related Concepts

• Load Balancing (DNS Round Robin)
• CDN Architecture (Uses CNAME/Anycast)
• HTTP Interaction