DNS and how domain resolution works in HLD - System Design Exercise

Design: Domain Name System (DNS)

Design focuses on the DNS resolution process and infrastructure. Does not cover domain registration or web hosting services.

Functional Requirements

FR1: Translate human-friendly domain names (e.g., example.com) into IP addresses (e.g., 192.0.2.1)

FR2: Support fast and reliable domain name resolution for internet users worldwide

FR3: Handle millions of queries per second with low latency

FR4: Provide caching to reduce repeated lookups and improve performance

FR5: Support hierarchical domain structure (root, TLD, authoritative servers)

FR6: Allow updates to domain records with eventual consistency

Non-Functional Requirements

NFR1: Handle at least 10 million queries per second globally

NFR2: Average query latency under 50 milliseconds

NFR3: Availability of 99.99% uptime (less than 52.56 minutes downtime per year)

NFR4: Scalable to support growth in internet users and domains

NFR5: Secure against common attacks like DNS spoofing and cache poisoning

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Recursive DNS resolver

Root DNS servers

Top-Level Domain (TLD) DNS servers

Authoritative DNS servers

DNS cache

DNS client (stub resolver)

Security components (DNSSEC)

Design Patterns

Hierarchical distributed system

Caching with TTL expiration

Load balancing for DNS servers

Failover and redundancy

Security with DNSSEC and query validation

Reference Architecture

Client (Stub Resolver)
    |
    v
Recursive Resolver (with Cache)
    |
    v
+-------------------+
| Root DNS Servers   |
+-------------------+
    |
    v
+-------------------+
| TLD DNS Servers    |
+-------------------+
    |
    v
+-------------------+
| Authoritative DNS  |
| Servers           |
+-------------------+

Components

Client (Stub Resolver)

Operating system DNS client

Sends DNS queries to recursive resolver to resolve domain names

Recursive DNS Resolver

DNS resolver software (e.g., BIND, Unbound)

Receives queries from clients, checks cache, queries other DNS servers if needed, returns IP address

Root DNS Servers

Highly available global servers

Provide referral to TLD servers for domain queries

TLD DNS Servers

Managed by domain registries

Provide referral to authoritative DNS servers for specific domains

Authoritative DNS Servers

Managed by domain owners or DNS providers

Store actual DNS records and respond with IP addresses or other data

DNS Cache

In-memory cache in recursive resolver

Store recent DNS query results to reduce latency and load

Security Components (DNSSEC)

DNS Security Extensions

Validate authenticity and integrity of DNS responses

Request Flow

1. 1. Client sends DNS query to recursive resolver.

2. 2. Recursive resolver checks its cache for the domain record.

3. 3. If cache miss, recursive resolver queries a root DNS server.

4. 4. Root server responds with referral to appropriate TLD DNS server.

5. 5. Recursive resolver queries the TLD DNS server.

6. 6. TLD server responds with referral to authoritative DNS server for the domain.

7. 7. Recursive resolver queries authoritative DNS server.

8. 8. Authoritative server responds with the requested DNS record (e.g., IP address).

9. 9. Recursive resolver caches the response with TTL and returns it to the client.

10. 10. Client receives the IP address and can connect to the target server.

Database Schema

Entities: - DomainRecord: domain_name (PK), record_type, value, TTL, last_updated - DNSCacheEntry: domain_name (PK), record_type, cached_value, expiry_time Relationships: - DomainRecord stores authoritative DNS records for domains. - DNSCacheEntry stores cached records in recursive resolvers with expiry based on TTL.

Scaling Discussion

Bottlenecks

Recursive resolver overload due to high query volume

Root and TLD servers becoming hotspots under heavy load

Cache misses causing increased latency and load on authoritative servers

Propagation delay of DNS record updates

Security vulnerabilities like cache poisoning attacks

Solutions

Deploy multiple recursive resolvers with load balancing and geographic distribution

Use Anycast IP addressing for root and TLD servers to distribute traffic globally

Implement aggressive caching with proper TTL tuning to reduce upstream queries

Use incremental zone transfers and DNS NOTIFY to speed up record propagation

Implement DNSSEC to sign DNS records and validate responses to prevent spoofing

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing the architecture and data flow, 10 minutes discussing scaling and security, and 5 minutes summarizing.

Explain the hierarchical nature of DNS and why it is distributed

Discuss caching benefits and TTL impact on performance

Highlight security concerns and DNSSEC importance

Describe how recursive resolvers interact with root, TLD, and authoritative servers

Address scalability challenges and solutions like Anycast and load balancing

Practice

1. What is the main purpose of DNS in internet communication?

easy

A. To translate domain names into IP addresses

B. To store website content

C. To encrypt internet traffic

D. To manage email delivery

Solution

1. Step 1: Understand DNS role

   DNS stands for Domain Name System and its main job is to convert human-friendly domain names into IP addresses computers use.

2. Step 2: Identify correct function

   Among the options, only translating domain names to IP addresses matches DNS's core function.

3. Final Answer:

   To translate domain names into IP addresses -> Option A

4. Quick Check:

   DNS = domain to IP translation [OK]

Hint: DNS converts names to IPs, not content or encryption [OK]

Common Mistakes:

• Confusing DNS with web hosting
• Thinking DNS encrypts data
• Mixing DNS with email servers

2. Which of the following is the correct order of DNS resolution steps when a user types a domain name?

easy

A. Root server -> TLD server -> Authoritative server

B. Authoritative server -> Root server -> TLD server

C. TLD server -> Root server -> Authoritative server

D. Local cache -> Authoritative server -> Root server

Solution

1. Step 1: Recall DNS resolution hierarchy

   DNS resolution starts at the root server, then goes to the TLD (Top-Level Domain) server, and finally to the authoritative server for the domain.

2. Step 2: Match the correct sequence

   Root server -> TLD server -> Authoritative server correctly lists the order: Root -> TLD -> Authoritative.

3. Final Answer:

   Root server -> TLD server -> Authoritative server -> Option A

4. Quick Check:

   Resolution order = Root, TLD, Authoritative [OK]

Hint: DNS starts at root, then TLD, then authoritative [OK]

Common Mistakes:

• Mixing up the order of servers
• Starting resolution at authoritative server
• Ignoring the root server step

3. Consider this simplified DNS resolution code snippet:

cache = {"example.com": "93.184.216.34"}

query = "example.com"

if query in cache:
    ip = cache[query]
else:
    ip = "198.51.100.1"  # IP from authoritative server

print(ip)

What will be the output when this code runs?

medium

A. 198.51.100.1

B. example.com

C. 93.184.216.34

D. KeyError

Solution

1. Step 1: Check if query is in cache

   The query is "example.com" which exists in the cache dictionary with IP "93.184.216.34".

2. Step 2: Determine printed IP

   Since the query is found in cache, the code assigns ip = cache[query] which is "93.184.216.34" and prints it.

3. Final Answer:

   93.184.216.34 -> Option C

4. Quick Check:

   Cache hit returns cached IP [OK]

Hint: If domain in cache, output cached IP [OK]

Common Mistakes:

• Assuming authoritative IP prints always
• Confusing key and value in dictionary
• Expecting error if key exists

4. A DNS resolver is not returning the correct IP address for a domain. Which of the following is the most likely cause?

medium

A. The domain name is misspelled in the URL

B. The root server is unreachable but TLD server works

C. The authoritative server is down but cache is fresh

D. The local DNS cache has outdated information

Solution

1. Step 1: Analyze DNS caching impact

   If the local DNS cache holds old IP data, the resolver returns outdated IP even if authoritative server changed.

2. Step 2: Evaluate other options

   Misspelled domain would cause failure, not wrong IP. Authoritative down with fresh cache returns correct IP. Root unreachable but TLD working is unlikely scenario causing wrong IP.

3. Final Answer:

   The local DNS cache has outdated information -> Option D

4. Quick Check:

   Outdated cache causes wrong IP [OK]

Hint: Old cache causes wrong IP, refresh fixes it [OK]

Common Mistakes:

• Ignoring cache as source of error
• Assuming authoritative server always reachable
• Confusing root and TLD server roles

5. You want to design a scalable DNS system for a global service. Which approach best improves DNS resolution speed and reduces load on authoritative servers?

hard

A. Use a single global authoritative server for all domains

B. Implement multiple caching layers including local resolver and CDN caches

C. Direct all DNS queries only to the authoritative servers

D. Disable caching to always get fresh IP addresses

Solution

1. Step 1: Understand scalability needs

   To handle many users globally, caching at multiple layers reduces repeated queries to authoritative servers and speeds up responses.

2. Step 2: Evaluate options for load and speed

   Direct queries to authoritative servers increase load and latency. Single global server is a bottleneck and risk. Disabling caching slows resolution and increases load.

3. Final Answer:

   Implement multiple caching layers including local resolver and CDN caches -> Option B

4. Quick Check:

   Multi-layer caching improves speed and scalability [OK]

Hint: Use caching layers to scale DNS efficiently [OK]

Common Mistakes:

• Ignoring caching benefits
• Centralizing authoritative servers causing bottlenecks
• Disabling caching for freshness without tradeoff