DNS Resolution Flow

DNS Resolution Flow

Why This Matters

Think of DNS like a phone book for the internet. When you want to call someone, you look up their name in the phone book to find their number. DNS does the same thing—when you type "example.com" in your browser, DNS looks up the IP address (like 93.184.216.34) so your browser can connect to the server.

This matters because DNS is involved in almost every network request. If DNS is slow, your entire application feels slow. If DNS fails, your application can't connect to servers. Understanding DNS helps you debug network issues, optimize performance, and design resilient systems.

In interviews, when someone asks "How would you optimize a web application?", they're testing whether you understand DNS. Do you know about DNS caching? Do you understand DNS hierarchy? Most engineers don't. They just use domain names and wonder why requests are slow.

What Engineers Usually Get Wrong

Most engineers think "DNS is just a lookup—it's fast." But DNS can be slow. Each DNS query requires multiple round trips (client → resolver → root → TLD → authoritative server). Without caching, this can take hundreds of milliseconds. DNS caching is critical for performance.

Engineers also don't understand DNS failures. If DNS is down or slow, your application can't resolve domain names. This makes your entire application unavailable, even if your servers are running fine. Always have fallback DNS servers and monitor DNS resolution times.

How This Breaks Systems in the Real World

A service was making API calls to external services. Each call required DNS resolution. The service wasn't caching DNS results. Under normal load, this worked, but DNS lookups added 100-200ms to each request. During high traffic, DNS servers became slow, adding 500ms-1s to each request. Response times spiked. The service became unusable.

The fix? Cache DNS results. Most DNS resolvers cache results for the TTL (Time To Live) specified in DNS records. But you can also cache at the application level. This reduced DNS lookup time from 100-200ms to less than 1ms for cached results. But the real lesson is: DNS can be a bottleneck. Cache DNS results.

Another story: A service was using a single DNS server. When that DNS server had issues, the service couldn't resolve any domain names. The entire service became unavailable, even though the servers were running fine. The fix? Use multiple DNS servers (primary and fallback). Most systems use the OS's DNS resolver, which already has fallback servers configured.

DNS Hierarchy

DNS uses a hierarchical tree structure:

                    . (root)
                   / | \
              com  org  net  (TLD - Top Level Domain)
              /     |     \
         example  wikipedia  google  (Second-level domains)
          /         |          \
      www  mail  www  mail  www  mail  (Subdomains)

DNS Server Types

1. Root DNS Servers: 13 root servers (a.root-servers.net through m.root-servers.net)
2. TLD (Top-Level Domain) Servers: Manage .com, .org, .net, etc.
3. Authoritative DNS Servers: Own the DNS records for specific domains
4. Recursive DNS Servers (Resolvers): Query on behalf of clients (e.g., 8.8.8.8, 1.1.1.1)

Recursive vs Iterative Queries

Recursive Query

The DNS resolver handles all queries and returns the final answer to the client.

Client → Resolver: "What's the IP of example.com?"
Resolver → Root: "Where is .com?"
Resolver → TLD: "Where is example.com?"
Resolver → Authoritative: "What's the IP of example.com?"
Resolver → Client: "93.184.216.34"

Client perspective: Single request, single response

Iterative Query

Each server responds with a referral to the next server in the hierarchy.

Client → Root: "What's the IP of example.com?"
Root → Client: "Ask .com TLD server (IP: 192.5.6.30)"
Client → TLD: "What's the IP of example.com?"
TLD → Client: "Ask example.com authoritative (IP: 199.43.135.53)"
Client → Authoritative: "What's the IP of example.com?"
Authoritative → Client: "93.184.216.34"

Client perspective: Multiple requests, multiple responses

In practice: Clients use recursive queries (to resolvers), resolvers use iterative queries (to DNS hierarchy)

DNS Resolution Process

Step-by-Step Flow

1. Client checks local cache
   ↓ (cache miss)
2. Client queries recursive resolver (e.g., 8.8.8.8)
   ↓
3. Resolver checks its cache
   ↓ (cache miss)
4. Resolver queries root server (iterative)
   Root → "Ask .com TLD server at 192.5.6.30"
   ↓
5. Resolver queries .com TLD server (iterative)
   TLD → "Ask example.com NS at 199.43.135.53"
   ↓
6. Resolver queries authoritative server (iterative)
   Authoritative → "A record: 93.184.216.34"
   ↓
7. Resolver caches result and returns to client
   ↓
8. Client caches result

Detailed Example: Resolving www.example.com

Step 1: Client → Recursive Resolver (8.8.8.8)
  Query: "What's the IP of www.example.com?"

Step 2: Resolver → Root Server (a.root-servers.net)
  Query: "Where is .com?"
  Response: "Ask .com TLD server at 192.5.6.30"

Step 3: Resolver → .com TLD Server (192.5.6.30)
  Query: "Where is example.com?"
  Response: "Ask example.com NS at ns1.example.com (199.43.135.53)"

Step 4: Resolver → Authoritative Server (199.43.135.53)
  Query: "What's the IP of www.example.com?"
  Response: "A record: 93.184.216.34"

Step 5: Resolver → Client
  Response: "93.184.216.34"
  (Resolver caches this result)

DNS Record Types

Common Record Types

Examples

DNS Query Using dig

# Query A record
dig example.com A

# Response:
# ;; ANSWER SECTION:
# example.com.    3600    IN    A    93.184.216.34

# Query with trace (shows full resolution path)
dig +trace example.com

# Shows:
# 1. Query to root server
# 2. Query to TLD server
# 3. Query to authoritative server
# 4. Final answer

DNS Resolution in Code

1import dns from 'dns';
2import { promisify } from 'util';
3
4const resolve4 = promisify(dns.resolve4);
5const resolve = promisify(dns.resolve);
6
7async function resolveDNS(hostname: string): Promise<string | null> {
8  // Resolve hostname to IP address
9  try {
10    // Uses system's DNS resolver (recursive query)
11    const addresses = await resolve4(hostname);
12    return addresses[0]

DNS Caching Implementation

1class DNSCache {
2  private cache: Map<string, CacheEntry>;
3  private maxSize: number;
4  
5  constructor(maxSize: number = 1000) {
6    this.cache = new Map();
7    this.maxSize = maxSize;
8  }
9  
10  get(hostname: string, recordType: string = 'A'): string | null {
11    const key = `${hostname

Common Pitfalls

• Not understanding TTL: DNS records have TTL (Time To Live). Fix: Understand caching behavior, TTL affects how long records are cached
• DNS propagation delays: Changes take time to propagate. Fix: Set appropriate TTL, wait for propagation, use DNS checkers
• CNAME conflicts: CNAME can't coexist with other records. Fix: Use A records for root domain, CNAME for subdomains
• Circular dependencies: CNAME pointing to itself or loops. Fix: Validate DNS records, check for cycles
• DNS cache poisoning: Malicious DNS responses. Fix: Use DNSSEC, validate responses, use trusted resolvers
• Not handling DNS failures: Applications crash when DNS fails. Fix: Implement retries, fallback resolvers, cache results
• Confusing recursive vs iterative: Not understanding query types. Fix: Clients use recursive (to resolver), resolvers use iterative (to hierarchy)

Interview Questions

Beginner

Q: Explain how DNS resolution works. What happens when you type a URL in your browser?

A:

Process:

1. Browser checks cache: Browser first checks its DNS cache for the domain
2. OS checks cache: If not in browser cache, OS checks system DNS cache
3. Query recursive resolver: If cache miss, query configured DNS resolver (e.g., 8.8.8.8)
4. Resolver queries root: Resolver queries root DNS server for TLD information
5. Resolver queries TLD: Resolver queries TLD server (e.g., .com) for domain information
6. Resolver queries authoritative: Resolver queries authoritative DNS server for the domain
7. Return IP address: Authoritative server returns A record (IP address)
8. Cache result: Resolver and client cache the result (respecting TTL)
9. Browser connects: Browser uses IP address to establish TCP connection

Example: www.example.com

Browser → OS Cache → Resolver (8.8.8.8)
Resolver → Root → TLD (.com) → Authoritative (example.com)
Authoritative → "93.184.216.34"
Resolver → Browser: "93.184.216.34"
Browser → Connects to 93.184.216.34:80

Intermediate

Q: What is the difference between recursive and iterative DNS queries? When is each used?

A:

Recursive Query:

• Client asks resolver: "What's the IP of example.com?"
• Resolver does all the work (queries root, TLD, authoritative)
• Resolver returns final answer to client
• Used by: Clients querying DNS resolvers

Iterative Query:

• Client asks server: "What's the IP of example.com?"
• Server responds: "I don't know, but ask this other server"
• Client must query the next server itself
• Used by: DNS resolvers querying DNS hierarchy (root, TLD, authoritative)

Flow:

Client → Resolver (recursive): "example.com?"
  Resolver → Root (iterative): "example.com?"
    Root → Resolver: "Ask .com TLD at 192.5.6.30"
  Resolver → TLD (iterative): "example.com?"
    TLD → Resolver: "Ask example.com NS at 199.43.135.53"
  Resolver → Authoritative (iterative): "example.com?"
    Authoritative → Resolver: "93.184.216.34"
  Resolver → Client: "93.184.216.34" (final answer)

Why this design?

• Efficiency: Resolvers cache results for multiple clients
• Load distribution: Root/TLD servers don't handle all queries
• Security: Authoritative servers only serve their domains

Senior

Q: Design a high-performance DNS resolver that handles millions of queries per second. How do you implement caching, handle DNS failures, and ensure low latency?

A:

1class HighPerformanceDNSResolver {
2  private cache: DNSCache;
3  private upstreamResolvers: string[];
4  private queryQueue: QueryQueue;
5  private stats: ResolverStats;
6  
7  constructor() {
8    // Multi-level cache
9    this.cache = new MultiLevelCache({
10      l1: new InMemoryCache(100000),      // Hot cache
11      l2: new RedisCache(),                // Distributed cache
12      l3: new PersistentCache()            // Disk cache
13    }

Optimizations:

1. Multi-level caching: In-memory (hot), Redis (warm), disk (cold)
2. Query batching: Batch multiple queries to reduce overhead
3. Failover: Multiple upstream resolvers with automatic failover
4. Negative caching: Cache NXDOMAIN responses (shorter TTL)
5. Prefetching: Preload common domains
6. Connection pooling: Reuse TCP connections for DNS queries
7. Anycast: Deploy resolvers in multiple locations
8. Monitoring: Track cache hit rates, latency, failures

Failure Stories You'll Recognize

The Slow DNS Lookups: A service was making API calls to external services. Each call required DNS resolution. The service wasn't caching DNS results. Under normal load, this worked, but DNS lookups added 100-200ms to each request. During high traffic, DNS servers became slow, adding 500ms-1s to each request. Response times spiked. The service became unusable. The fix? Cache DNS results. Most DNS resolvers cache results for the TTL (Time To Live) specified in DNS records. But you can also cache at the application level. This reduced DNS lookup time from 100-200ms to less than 1ms for cached results.

The Single DNS Server: A service was using a single DNS server. When that DNS server had issues, the service couldn't resolve any domain names. The entire service became unavailable, even though the servers were running fine. The fix? Use multiple DNS servers (primary and fallback). Most systems use the OS's DNS resolver, which already has fallback servers configured.

The DNS Propagation Delay: A team changed their DNS records to point to a new server. They expected the change to be immediate. But DNS changes take time to propagate (based on TTL). Some users were still hitting the old server for hours. This caused inconsistent behavior. The fix? Set low TTL before making changes, then increase TTL after propagation. Or use DNS failover services.

What Interviewers Are Really Testing

They want to hear you talk about DNS caching, hierarchy, and failure scenarios. Junior engineers say "DNS resolves domain names to IP addresses." Senior engineers say "DNS can be a bottleneck. Cache DNS results. Use multiple DNS servers for reliability. Understand TTL and propagation delays. Monitor DNS resolution times."

When they ask "How would you optimize a web application?", they're testing:

• Do you understand DNS caching?

• Do you know about DNS hierarchy and resolution flow?

• Can you handle DNS failures and optimize DNS performance?

• TCP vs UDP - DNS primarily uses UDP for queries due to speed requirements, understanding UDP explains DNS protocol choice

• OSI Model (7 Layers) - DNS operates at Layer 7 (Application), understanding the OSI model provides context for DNS placement

• CDN Routing - CDNs use DNS to route users to optimal edge servers, understanding DNS resolution explains CDN functionality

• Load Balancers (L4 vs L7) - DNS-based load balancing is a Layer 7 approach, understanding DNS helps choose load balancing strategies

• Latency, Throughput & Bandwidth - DNS resolution adds latency to requests, understanding latency helps optimize DNS performance

• DNS hierarchy: Root → TLD → Authoritative servers in a tree structure

• Recursive queries: Clients query resolvers (resolver does all work)

• Iterative queries: Resolvers query DNS hierarchy (each server refers to next)

• DNS caching: Results cached at multiple levels (browser, OS, resolver) with TTL

• Record types: A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), NS (name server)

• TTL (Time To Live): Controls how long DNS records are cached

• DNS propagation: Changes take time to propagate through DNS hierarchy

• Performance: Use caching, batching, failover, and connection pooling for high-performance resolvers

• Security: Use DNSSEC, DoH/DoT for encrypted DNS queries

• Common issues: Cache poisoning, propagation delays, CNAME conflicts, DNS failures

How InterviewCrafted Will Teach This

We'll teach this through production failures, not protocol specifications. Instead of memorizing "DNS uses a hierarchical structure," you'll learn through scenarios like "why did our service become slow when DNS servers were slow?"

You'll see how DNS affects application performance and reliability. When an interviewer asks "how would you optimize a web application?", you'll think about DNS caching, resolution times, and failure handling—not just "DNS resolves names."