DNS Resolution

DNS (Domain Name System) resolution is the process of translating a human-readable domain name like www.example.com into a machine-readable IP address like 93.184.216.34.

What It Really Means

DNS is the phone book of the internet. Every time you visit a website, send an email, or make an API call, your device needs to convert a domain name into an IP address. This happens so quickly and transparently that most developers never think about it — until DNS goes down, and nothing works.

The DNS system is a globally distributed, hierarchical database serving over 1 trillion queries per day. It is one of the most critical pieces of internet infrastructure, and understanding how it works is essential for debugging network issues, designing resilient systems, and optimizing application performance.

DNS is also a common interview topic because it demonstrates understanding of distributed systems concepts: caching, hierarchical delegation, TTL-based invalidation, and fault tolerance.

How It Works in Practice

The Full Resolution Path

Record Types

DNS Caching and TTL

Every DNS record has a Time-To-Live (TTL) value in seconds. After the TTL expires, resolvers must re-query the authoritative server. TTL values create a trade-off:

• High TTL (3600s = 1 hour): Fewer queries to authoritative servers, faster resolution for cached records, but changes take up to 1 hour to propagate.
• Low TTL (60s = 1 minute): Changes propagate quickly, but more load on authoritative servers and slightly higher latency for cache misses.
• Very low TTL (5-30s): Used for failover scenarios (Route 53 health checks). Allows rapid traffic switching on failure.

Implementation

DNS lookup debugging:

Application-level DNS caching (Java):

DNS-based service discovery:

Trade-offs

DNS as a load balancer:

• Pros: Simple, no additional infrastructure, works globally
• Cons: No health checks (without Route 53 or similar), TTL-based delays for failover, client-side caching ignores changes

Internal DNS vs service mesh:

• DNS service discovery: Simple, language-agnostic, well-understood
• Service mesh (Istio, Linkerd): Richer features (retries, circuit breaking, mTLS) but more complex

Authoritative DNS providers:

• Self-hosted (BIND, CoreDNS): Full control, but operational burden
• Managed (Route 53, Cloudflare DNS, Google Cloud DNS): High availability, global anycast, but vendor dependency

Common Misconceptions

• "DNS changes propagate instantly" — DNS changes propagate only after cached entries expire (TTL). A record with TTL=86400 may take up to 24 hours to propagate globally.
• "There are only 13 root DNS servers" — There are 13 root server identities (a.root-servers.net through m.root-servers.net), but each is a cluster of hundreds of servers worldwide using anycast routing.
• "DNS is always fast" — An uncached DNS lookup requiring the full resolution path can take 100-200ms. Multiply by the number of domains on a web page (CDN, analytics, ads) and DNS can add significant latency.
• "HTTPS makes DNS secure" — Standard DNS queries are unencrypted and can be intercepted or spoofed. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS queries but are not universally deployed.
• "TTL=0 means no caching" — Some resolvers and operating systems cache TTL=0 records for a minimum duration (e.g., 30 seconds). Do not rely on TTL=0 for instant propagation.

How This Appears in Interviews

1. "What happens when you type a URL in the browser?" — DNS resolution is the first step. Walk through browser cache, OS cache, recursive resolver, root, TLD, authoritative.
2. "How do you handle DNS failover?" — Low-TTL A records with health checks (Route 53), or GeoDNS for latency-based routing.
3. "Design a URL shortener" — Discuss custom domain DNS configuration, CNAME vs A records, and CDN integration.
4. "Why is your service intermittently failing?" — DNS resolution failures are a common cause. Check for resolver issues, TTL expiry during deployments, and DNS-based service discovery failures.

Related Concepts

• What Happens When You Type a URL — DNS is step one in the full request lifecycle
• CDN and Edge Computing — CDNs use DNS for geographic routing
• TCP Three-Way Handshake — happens after DNS resolves the IP
• TLS/SSL Handshake — establishes encrypted connection after TCP
• System Design Interview Guide
• Algoroq Pricing — access all networking deep-dives