DNS Resolution

1. What Is It?

DNS (Domain Name System) is the internet's phone book — it translates human-readable hostnames like api.example.com into IP addresses like 93.184.216.34 that machines can route to. Without it, every application would need to hardcode IP addresses, making deployments brittle (IPs change), configs unmaintainable, and load balancing nearly impossible to implement transparently.

The problem DNS solves: network routing operates on IP addresses, but developers and users think in names. DNS decouples the two. When your service moves to a new host, you update a DNS record — every caller gets the new IP automatically on their next lookup, with no code changes.

2. How It Works

A DNS resolution goes through up to four participants before returning an IP:

1. Recursive Resolver — your ISP's or cloud provider's DNS server. It does the work on your behalf and caches results.
2. Root Nameserver — knows which nameserver is authoritative for top-level domains (.com, .io, etc.).
3. TLD Nameserver — knows which nameserver is authoritative for example.com.
4. Authoritative Nameserver — has the actual A/AAAA record mapping api.example.com → IP.

-+ResetFullscreen

Concrete example: When your Node.js service calls fetch("https://api.stripe.com/v1/charges"), the OS calls getaddrinfo("api.stripe.com") before a single byte of HTTP is sent. That call may hit the local cache (fast, ~0ms), the recursive resolver (moderate, ~5–20ms), or do a full traversal (slow, ~50–200ms).

3. What SDEs Actually Need to Know

TTL controls staleness. Every DNS record has a TTL (time-to-live) in seconds. After a TTL expires, resolvers re-query. Setting TTL too high means traffic hits an old IP after you migrate. Setting it too low creates resolver load and increased latency on cold paths. Common practice: lower TTL to 60s a day before a migration, then raise it after.

Record types that matter to SDEs:

• A — hostname → IPv4
• AAAA — hostname → IPv6
• CNAME — hostname → another hostname (used for www → apex, or aliases in cloud services)
• TXT — arbitrary text (used for SPF, DKIM, domain verification)
• SRV — service + port (used by gRPC service discovery, Kubernetes, Consul)

DNS caching layers can fool you. Your app's DNS lookup goes through: JVM/runtime cache → OS /etc/hosts → OS stub resolver → recursive resolver. A change you made may not be visible for minutes even after TTL expires, because each layer has its own cache. In containers, the OS cache is per-container — /etc/nsswitch.conf and /etc/resolv.conf control behavior.

Common errors:

• UnknownHostException / NXDOMAIN — the hostname doesn't exist or isn't reachable from this resolver. Check your search domain in /etc/resolv.conf for Kubernetes pods.
• SERVFAIL — the upstream resolver failed. Indicates DNS infrastructure issues.
• Slow first requests — DNS cache cold start. Mitigate with connection pooling (resolves once, reuses the connection).

4. Tradeoffs & Decisions

TTL too high vs. too low:

• High TTL (3600s+): fewer lookups, faster resolution, but slow failover. Use for stable infrastructure.
• Low TTL (30–60s): fast failover and migration capability, but more resolver load and occasional extra latency. Use when you need quick DNS-based traffic shifting.

CNAME vs. A record:

• CNAME adds one extra lookup hop (CNAME → A). At the zone apex (bare example.com) you cannot use CNAME — use ALIAS or ANAME records if your DNS provider supports them, or an A record.
• Cloud load balancers (AWS ALB, GCP HTTPS LB) are typically pointed to via CNAME because their IPs change.

Split-horizon DNS:

• Internal services often have different DNS answers for internal vs. external clients. If db.internal.example.com resolves to a private IP from inside your VPC but fails externally, that's intentional. Understanding this prevents confusion when debugging from a laptop vs. in-cluster.

5. Interview Cheat Sheet

Key sentences:

• "DNS translates hostnames to IPs; without it, every service call would require hardcoded IPs that break on migration."
• "A TTL governs how long resolvers cache a record; lowering it before a migration is a standard operational practice."
• "DNS resolution goes through the OS stub resolver, a recursive resolver, and eventually the authoritative nameserver — each layer caches independently."
• "In Kubernetes, each pod has its own /etc/resolv.conf with a search domain; unqualified names are resolved against the cluster's internal DNS."

Common follow-ups:

Q: What happens if DNS is slow? A: Your app's first connection to any host incurs the lookup latency — typically 1–50ms from cache, up to 200ms on a cold full traversal. Mitigate with connection pooling (reuses established connections) and DNS pre-fetching at startup.

Q: How does a CDN use DNS? A: CDNs use DNS-based anycast or geo-routing. Your CNAME points to the CDN's hostname; the CDN's authoritative nameserver returns the IP of the nearest PoP based on the resolver's IP. This is why different users get different IPs for the same hostname.

Q: What is a DNS negative cache? A: When a hostname lookup returns NXDOMAIN ("not found"), resolvers cache that failure for a duration defined by the SOA record's minimum TTL. This means a misconfigured or missing record continues to fail even after you fix it, until the negative cache expires.