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 logical root server IP addresses (A-M).
• 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).
• Controlled by Domain Registrars (GoDaddy) or Cloud Providers (AWS Route 53).

DNS Resolution Flow

What happens when you type google.com?

Interactive: Recursive Lookup Flow

1. Browser Cache: Checks chrome://net-internals/. "Have I been here recently?"
2. OS Cache: Checks /etc/hosts or Windows Registry.
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 the Recursive Query.

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: "I don't know IP, but GoDaddy NS1 runs google.com."
3. Resolver -> Authoritative (NS1): "What is IP of google.com?"
   • NS1: "It is 142.250.190.46."
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. Updates take 24h to propagate. (Good for stable APIs).
• Low TTL (60s): High traffic. Fast failover. (Good for Load Balancing).

Anycast Routing

How do 13 Root IPs serve billions of users? Anycast. Multiple servers around the world announce the same IP address via BGP. The network routes your request to the geographically closest server.

Code Example: Querying DNS

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")

TTLs: The Distributed Cache You Don't Control

Every DNS record carries a TTL, and every resolver on Earth honors it independently — which makes DNS the world's largest cache-invalidation problem. The operational consequences:

• Failover speed is bounded by TTL: if your record has a 24-hour TTL and your datacenter dies, some users will keep resolving to the corpse for up to a day. This is why records used for failover run 30–300 second TTLs, accepting more resolver traffic as the price of agility.
• The pre-migration ritual: planning to move a service? Drop the TTL from hours to 60 seconds at least one full old-TTL period before the change, migrate, verify, then raise it back. Teams that skip the waiting period discover that lowering a TTL only takes effect after the old TTL expires everywhere.
• TTLs are advisory: some ISP resolvers clamp very low TTLs upward, and some applications (older JVMs famously cached DNS forever by default) ignore them entirely. Never build a system where correctness depends on a DNS change propagating instantly — treat DNS traffic-shifting as convergent over minutes, not atomic.

DNS as a Load Balancer — and Its Limits

Because DNS is the first touchpoint, it's tempting to use it for traffic management, and services like Route 53 and NS1 offer weighted, latency-based, and health-checked routing. It works — with caveats a load balancer doesn't have:

1. Resolver granularity: one answer serves everyone behind a resolver. A big ISP resolver caching your answer sends all its users to the same target regardless of weights.
2. No connection awareness: DNS can't see that a target is overloaded right now — health checks poll on the order of seconds; a real LB reacts per-request.
3. Client disobedience: browsers and OSes cache resolutions themselves, and happy-eyeballs clients may pin to an address longer than you'd like.

The mature pattern is layered: GeoDNS for coarse regional steering (get the user to the nearest region), anycast for the edge (one IP, BGP routes to the closest POP — how CDNs and public resolvers like 8.8.8.8 work), and real load balancers within the region for fine-grained, health-aware distribution.

Interview Tips 💡

• "What happens when you type URL in browser?" — DNS is step 1. Mention Caching hierarchy!
• "How fast can you fail over?" — Bounded by record TTL and resolver behavior; describe the lower-TTL-in-advance ritual.
• "DNS vs Anycast vs LB?" — DNS steers regions, anycast steers to the nearest POP, LBs steer per-request. All three layers coexist in real architectures.
• "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 CNAME requires a second lookup (first to get CNAME target, second to get A record). Slight performance penalty.
• "Geo-DNS" — Route 53 can return different IPs based on user location (Latency-based routing).

Related Concepts

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