Bird
Raised Fist0

How DNS Works - Resolution Chain from Browser to IP Address

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/9
Browser DNS Cache

Check cache for example.com IP

Browser checks local DNS cache for example.com

Protocol:Local Cache Lookup
BeforeBrowser has no cached IP for example.com
AfterBrowser confirms cache miss for example.com
OS DNS Cache

Query OS DNS cache for example.com

Browser sends DNS query to OS DNS cache

Protocol:DNS Query (UDP)
BeforeOS DNS cache has no entry for example.com
AfterOS DNS cache confirms cache miss and forwards query
Recursive Resolver (e.g., Google Public DNS, Cloudflare 1.1.1.1)

Receive DNS query and check own cache

Resolver checks cache for example.com IP

Protocol:DNS Query (UDP)
BeforeResolver cache has no entry for example.com
AfterResolver initiates query to Root DNS server
Root DNS Server

Respond with TLD DNS server address

Root server directs resolver to .com TLD server

Protocol:DNS Query/Response (UDP)
BeforeRoot server receives query for example.com
AfterRoot server replies with .com TLD server IP
TLD DNS Server

Respond with Authoritative DNS server address

TLD server directs resolver to authoritative server for example.com

Protocol:DNS Query/Response (UDP)
BeforeTLD server receives query for example.com
AfterTLD server replies with authoritative server IP
Authoritative DNS Server

Respond with example.com IP address

Authoritative server returns IP for example.com

Protocol:DNS Query/Response (UDP)
BeforeAuthoritative server receives query for example.com
AfterAuthoritative server replies with IP address
Recursive Resolver (e.g., Google Public DNS, Cloudflare 1.1.1.1)

Cache and forward IP response

Resolver caches IP and sends response back to OS

Protocol:DNS Response (UDP)
BeforeResolver has IP from authoritative server
AfterResolver caches IP and sends response to OS DNS cache
OS DNS Cache

Cache and forward IP response

OS caches IP and sends response to browser

Protocol:DNS Response (UDP)
BeforeOS DNS cache receives IP from resolver
AfterOS DNS cache caches IP and sends response to browser
Browser DNS Cache

Cache IP and complete resolution

Browser caches IP and uses it for connection

Protocol:Local Cache Store
BeforeBrowser receives IP from OS DNS cache
AfterBrowser caches IP and proceeds to connect to example.com
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│   Browser DNS Cache   │
└─────────────┬─────────┘
              │ DNS Query (UDP)
              ▼
┌───────────────────────┐
│      OS DNS Cache     │
└─────────────┬─────────┘
              │ DNS Query (UDP)
              ▼
┌────────────────────────────────────────────┐
│ Recursive Resolver (e.g., Google DNS, 1.1.1.1)│
└─────────────┬──────────────────────────────┘
              │ DNS Query (UDP)
              ▼
┌───────────────┐
│ Root DNS Server│
└───────┬───────┘
        │ DNS Query (UDP)
        ▼
┌───────────────┐
│  TLD DNS Server│
└───────┬───────┘
        │ DNS Query (UDP)
        ▼
┌───────────────────────┐
│ Authoritative DNS Server│
└─────────────┬─────────┘
              │ DNS Response (UDP)
              ▼
┌───────────────────────┐
│ Recursive Resolver    │
│ caches and returns IP │
└─────────────┬─────────┘
              │ DNS Response (UDP)
              ▼
┌───────────────┐
│ OS DNS Cache  │
└─────────────┬─┘
              │ DNS Response (UDP)
              ▼
┌───────────────┐
│Browser DNS Cache│
└───────────────┘
Design Rationale

DNS resolution starts at the Browser DNS Cache, which checks for a cached IP. On a miss, the query flows down to the OS DNS Cache, then to the Recursive Resolver. The resolver queries the Root DNS Server, which directs it to the TLD DNS Server. The TLD server then points to the Authoritative DNS Server for the domain. The authoritative server responds with the IP address, which is cached and propagated back up the chain. Each cache layer stores the IP to speed future lookups. This vertical flow ensures efficient resolution with caching at multiple layers, reducing latency and load on authoritative servers.

Primary Focus

✓

Practice

(1/5)
1. In a code repository system, which component is best suited to efficiently store and retrieve file diffs to minimize storage space while allowing fast access for merges?
easy
A. Use a relational database with BLOB columns to store entire file versions
B. Use a distributed cache like Redis to store diffs temporarily for quick access
C. Use a content-addressable storage system that stores objects by hash and reuses identical content
D. Use a simple file system directory structure with full copies of each file version

Solution

  1. Step 1: Identify storage needs for diffs

    Storing diffs efficiently requires deduplication and immutability; content-addressable storage (CAS) stores objects by their hash, enabling reuse of identical content and saving space.

  2. Step 2: Evaluate other options

    Relational DB with BLOBs stores full versions, wasting space; Redis is volatile and not durable for persistent storage; file system copies waste space and slow for merges.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    CAS stores objects by hash -> deduplication and fast retrieval [check]
Hint: Content-addressable storage deduplicates by hash [check]
Common Mistakes:
2. In the digital wallet system's transaction processing flow, at Step 4 the Ledger Service applies the debit and credit entries. What happens if the Ledger Service detects a mismatch in the double-entry records at this step?
easy
A. The Ledger Service retries the transaction indefinitely until the entries match
B. The Ledger Service marks the transaction as failed and triggers an alert for manual reconciliation
C. The Ledger Service ignores the mismatch and commits the debit entry only
D. The Ledger Service rolls back the entire transaction and deletes all related entries

Solution

  1. Step 1: Understand Ledger Service's double-entry validation

    The Ledger Service enforces double-entry consistency; mismatches indicate data corruption or bugs.

  2. Step 2: Evaluate failure handling

    Retrying indefinitely (A) risks blocking; ignoring mismatch (C) breaks accounting; deleting entries (D) risks data loss. Marking failed and alerting (B) enables safe manual reconciliation.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Mismatch triggers failure mark and alert -> safe reconciliation [check]
Hint: Mismatch triggers failure mark and alert, not silent retry [OK]
Common Mistakes:
3. For ensuring exactly-once payment event processing in a distributed payment gateway, which architecture is more appropriate given the constraint that external payment processors may send duplicate callbacks?
medium
A. Use an event sourcing pattern with idempotent event handlers and a unique event ID store
B. Use a relational database with unique constraints on callback IDs and synchronous processing
C. Use a stateless microservice that processes each callback independently without deduplication
D. Use a batch job that aggregates callbacks and processes them periodically

Solution

  1. Step 1: Identify the need for deduplication and exactly-once semantics

    Duplicate callbacks require idempotent processing and event tracking to avoid double charges.

  2. Step 2: Evaluate event sourcing with idempotent handlers

    Event sourcing stores all events immutably with unique IDs, enabling replay and deduplication.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Event sourcing with idempotent handlers ensures exactly-once processing [check]
Hint: Event sourcing + idempotent handlers handle duplicates best [check]
Common Mistakes:
4. If the Kafka broker cluster goes down unexpectedly, what exactly breaks in the message delivery pipeline?
medium
A. Producers receive errors and messages are lost if not retried; consumers stop receiving new messages causing delivery stalls
B. Consumers continue reading cached messages but new messages from producers are lost until broker recovers
C. Producers block indefinitely waiting to write messages, causing backpressure
D. Messages are duplicated because brokers resend uncommitted messages after restart

Solution

  1. Step 1: Trace producer behavior on broker failure

    Producers get errors on send; without retries, messages are lost. They do not block indefinitely (A).

  2. Step 2: Trace consumer behavior

    Consumers cannot fetch new messages; cached messages may be consumed but no new delivery occurs, causing stalls. Duplication (D) is prevented by offset commits.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Broker failure causes producer errors and consumer stalls, risking message loss [check]
Hint: Broker down -> producer errors, consumer stalls, possible message loss [check]
Common Mistakes:
5. If the REST API server does not implement proper HTTP status codes and always returns HTTP 200 OK, what exact failure occurs for clients trying to detect errors?
medium
A. Clients receive HTTP 500 Internal Server Error instead of 200 OK
B. Clients receive HTTP 404 Not Found for all endpoints
C. Clients automatically retry requests due to 429 Too Many Requests responses
D. Clients cannot distinguish success from failure, leading to silent data corruption or retries

Solution

  1. Step 1: Understand role of HTTP status codes

    Status codes signal success or failure; 200 OK means success.

  2. Step 2: Trace client behavior without proper error codes

    Clients see 200 always, so they assume success even on errors, causing silent failures or incorrect retries.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Always 200 OK hides errors, causing silent client failures [check]
Hint: No error codes -> clients can't detect failures [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard