Bird
Raised Fist0
Interview Prepcomputer-networksmediumAmazonGoogleMicrosoftFlipkartSwiggyRazorpayZepto

DNS Resolution - Full Journey from Browser to IP

Choose your preparation mode3 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Steps
setup

Browser initiates DNS query

The browser creates a DNS query packet for www.example.com and sends it to the local DNS resolver.

💡 This step starts the DNS resolution journey by generating the initial query packet from the client side.
Line:query_packet = create_dns_query('www.example.com') send_packet(browser, local_resolver, query_packet)
💡 The DNS resolution process begins with the client sending a query to its configured DNS resolver.
📊
DNS Resolution - Full Journey from Browser to IP - Watch the Algorithm Execute, Step by Step
Watching each packet hop and processing step reveals how DNS resolution works in practice, clarifying the roles of different DNS servers and the flow of queries and responses.
Step 1/10
·Active fillAnswer cell
Browser sends DNS query packet to local resolver
Hop: 1
Browser
Local DNS Resolver
Root DNS Server
TLD DNS Server
Authoritative DNS Server
📦Packet
frombrowser
tolocal_resolver
📄 payloadDNS Query: www.example.com
🔌 protocolDNS
🚩 flagsquery
src192.168.1.2:5353
dst192.168.1.1:53
datawww.example.com
flagsquery
Query: browser→local_resolver (www.example.com)
Local resolver forwards query to root DNS server after cache miss
Hop: 2
Browser
Local DNS Resolver
Root DNS Server
TLD DNS Server
Authoritative DNS Server
📦Packet
fromlocal_resolver
toroot_dns
📄 payloadDNS Query: www.example.com
🔌 protocolDNS
🚩 flagsquery
src192.168.1.1:53
dst198.41.0.4:53
datawww.example.com
flagsquery
Query: browser→local_resolver (www.example.com)
Cache miss at local_resolver; forwarding to root_dns
Root DNS server sends referral response to local resolver
Hop: 3
Browser
Local DNS Resolver
Root DNS Server
TLD DNS Server
Authoritative DNS Server
📦Packet
fromroot_dns
tolocal_resolver
📄 payloadReferral: .com TLD DNS Server IP
🔌 protocolDNS
🚩 flagsreferral
src198.41.0.4:53
dst192.168.1.1:53
data.com TLD DNS Server IP
flagsreferral
Query: browser→local_resolver (www.example.com)
Cache miss at local_resolver; forwarding to root_dns
Root DNS server replies with referral to TLD DNS server
Local resolver forwards query to TLD DNS server
Hop: 4
Browser
Local DNS Resolver
Root DNS Server
TLD DNS Server
Authoritative DNS Server
📦Packet
fromlocal_resolver
totld_dns
📄 payloadDNS Query: www.example.com
🔌 protocolDNS
🚩 flagsquery
src192.168.1.1:53
dst192.0.2.53:53
datawww.example.com
flagsquery
Cache miss at local_resolver; forwarding to root_dns
Root DNS server replies with referral to TLD DNS server
Local resolver sends query to TLD DNS server
TLD DNS server sends referral to local resolver
Hop: 5
Browser
Local DNS Resolver
Root DNS Server
TLD DNS Server
Authoritative DNS Server
📦Packet
fromtld_dns
tolocal_resolver
📄 payloadReferral: Authoritative DNS Server IP
🔌 protocolDNS
🚩 flagsreferral
src192.0.2.53:53
dst192.168.1.1:53
dataAuthoritative DNS Server IP
flagsreferral
Root DNS server replies with referral to TLD DNS server
Local resolver sends query to TLD DNS server
TLD DNS server replies with referral to authoritative DNS server
Local resolver forwards query to authoritative DNS server
Hop: 6
Browser
Local DNS Resolver
Root DNS Server
TLD DNS Server
Authoritative DNS Server
📦Packet
fromlocal_resolver
toauth_dns
📄 payloadDNS Query: www.example.com
🔌 protocolDNS
🚩 flagsquery
src192.168.1.1:53
dst203.0.113.53:53
datawww.example.com
flagsquery
Local resolver sends query to TLD DNS server
TLD DNS server replies with referral to authoritative DNS server
Local resolver sends query to authoritative DNS server
Authoritative DNS server sends IP address response to local resolver
Hop: 7
Browser
Local DNS Resolver
Root DNS Server
TLD DNS Server
Authoritative DNS Server
📦Packet
fromauth_dns
tolocal_resolver
📄 payloadDNS Response: IP=93.184.216.34
🔌 protocolDNS
🚩 flagsresponse
src203.0.113.53:53
dst192.168.1.1:53
data93.184.216.34
flagsresponse
TLD DNS server replies with referral to authoritative DNS server
Local resolver sends query to authoritative DNS server
Authoritative DNS server replies with IP address
Local resolver caches the IP address for future queries
Hop: 8
Browser
Local DNS Resolver
Root DNS Server
TLD DNS Server
Authoritative DNS Server
Local resolver sends query to authoritative DNS server
Authoritative DNS server replies with IP address
Local resolver caches IP address for www.example.com
Local resolver sends final IP address response to browser
Hop: 9
Browser
Local DNS Resolver
Root DNS Server
TLD DNS Server
Authoritative DNS Server
📦Packet
fromlocal_resolver
tobrowser
📄 payloadDNS Response: IP=93.184.216.34
🔌 protocolDNS
🚩 flagsresponse
src192.168.1.1:53
dst192.168.1.2:5353
data93.184.216.34
flagsresponse
Authoritative DNS server replies with IP address
Local resolver caches IP address for www.example.com
Local resolver sends IP address response to browser
Browser receives final IP address and DNS resolution completes
Hop: 10
Browser
Local DNS Resolver
Root DNS Server
TLD DNS Server
Authoritative DNS Server
Local resolver caches IP address for www.example.com
Local resolver sends IP address response to browser
Browser receives IP address and completes DNS resolution

Key Takeaways

DNS resolution is an iterative, hierarchical process involving multiple DNS servers.

This insight is hard to see from code alone because the flow between servers and referrals is implicit without visualization.

Local DNS resolvers cache responses to optimize future queries and reduce network traffic.

Visualizing caching shows why some queries never leave the local network, which is not obvious from code.

Each DNS server only knows part of the domain namespace and refers queries to the next level.

Seeing referrals as packets flowing back and forth clarifies the delegation model of DNS.

Practice

(1/5)
1. Which component in a CDN architecture is primarily responsible for serving cached content closest to the user to reduce latency?
easy
A. Edge server located near the user's geographic region
B. Origin server that stores the master copy of content
C. DNS server that resolves domain names to IP addresses
D. Load balancer distributing requests among origin servers

Solution

  1. Step 1: Identify the role of the origin server

    The origin server holds the original content but is usually far from the user, causing higher latency.
  2. Step 2: Understand the edge server's function

    Edge servers cache content closer to users geographically, reducing latency by serving requests locally.
  3. Step 3: Clarify DNS server's role

    DNS servers resolve domain names but do not serve content directly.
  4. Step 4: Load balancer's responsibility

    Load balancers distribute traffic among origin servers but do not cache content at the edge.
  5. Final Answer:

    Option A -> Option A
  6. Quick Check:

    Edge servers reduce latency by caching content near users, which is the core CDN principle.
Hint: Edge servers = cached content near users -> low latency
Common Mistakes:
  • Confusing origin server with edge server
  • Assuming DNS servers serve cached content
  • Thinking load balancers cache content
2. You want to prevent unauthorized access to your internal network by filtering incoming and outgoing traffic based on IP addresses and ports. Which network component is best suited for this task?
easy
A. Proxy server acting as an intermediary for client requests
B. Firewall filtering traffic based on rules
C. Reverse proxy optimizing server load
D. Content Delivery Network (CDN) caching static content

Solution

  1. Step 1: Identify the role of each component

    Firewalls are designed to filter network traffic based on IP addresses, ports, and protocols, enforcing security policies.
  2. Step 2: Understand Proxy and Reverse Proxy roles

    Proxies forward client requests but do not primarily filter traffic at the network level; reverse proxies handle server-side requests and optimize load.
  3. Step 3: CDN role

    CDNs cache content to improve performance but do not filter traffic for security.
  4. Final Answer:

    Option B -> Option B
  5. Quick Check:

    Firewall is the component that filters traffic based on rules [OK]
Hint: Firewall filters traffic; proxies forward requests.
Common Mistakes:
  • Confusing proxy with firewall as a security filter
  • Assuming reverse proxy filters traffic like a firewall
3. You need to design a RESTful API endpoint that retrieves user profile information without modifying any server data. Which HTTP method should you use to ensure the operation is safe and does not change server state?
easy
A. GET
B. POST
C. PUT
D. DELETE

Solution

  1. Step 1: Understand the safety property of HTTP methods

    GET is defined as a safe method, meaning it does not modify server state and is used to retrieve data.
  2. Step 2: Analyze other methods

    POST, PUT, and DELETE modify server state and are not safe methods.
  3. Final Answer:

    Option A -> Option A
  4. Quick Check:

    GET is the only safe method here, suitable for data retrieval without side effects.
Hint: GET = safe read, POST/PUT/DELETE = state change
Common Mistakes:
  • Confusing POST with GET as both can send data
  • Thinking PUT is safe because it replaces data
  • Assuming DELETE can be used to retrieve data
4. If a CDN edge server uses a stale-while-revalidate caching strategy, what happens when a user requests content whose TTL has expired but the stale content is still served?
hard
A. User receives stale content immediately while edge server fetches fresh content asynchronously
B. User request is blocked until fresh content is fetched from the origin server
C. Edge server returns an error indicating content is expired
D. User is redirected to the origin server to get fresh content

Solution

  1. Step 1: Define stale-while-revalidate

    This strategy serves stale content immediately after TTL expiry while asynchronously fetching fresh content.
  2. Step 2: User experience

    User gets content without delay, improving perceived performance.
  3. Step 3: Background refresh

    Edge server updates cache with fresh content once fetched.
  4. Step 4: Analyze other options

    User request is blocked until fresh content is fetched from the origin server is incorrect because user is not blocked. Edge server returns an error indicating content is expired is false; no error is returned. User is redirected to the origin server to get fresh content is wrong; user is not redirected to origin.
  5. Final Answer:

    Option A -> Option A
  6. Quick Check:

    Stale-while-revalidate balances freshness and latency by serving stale content immediately.
Hint: Stale-while-revalidate = serve stale now, refresh in background
Common Mistakes:
  • Assuming user waits for fresh content
  • Thinking stale content causes errors
  • Believing user is redirected to origin on expiry
5. If a TCP connection experiences sudden, large variations in round-trip time (RTT), how should the retransmission timeout (RTO) algorithm adapt to maintain efficient retransmissions?
hard
A. Increase the RTO variance estimate to avoid premature retransmissions, even if it delays recovery
B. Ignore RTT variations and keep RTO fixed to prevent oscillations
C. Reset the RTO to a minimal value after each retransmission to speed up recovery
D. Disable retransmissions temporarily until RTT stabilizes

Solution

  1. Step 1: Understand RTO adaptation to RTT variance

    TCP's RTO algorithm uses both RTT estimate and variance to adapt timeout dynamically.
  2. Step 2: Analyze handling of large RTT variations

    Increasing variance estimate prevents premature retransmissions caused by transient delays, trading off some delay for stability.
  3. Step 3: Evaluate options

    Increase the RTO variance estimate to avoid premature retransmissions, even if it delays recovery correctly describes the adaptive behavior. Ignore RTT variations and keep RTO fixed to prevent oscillations ignores adaptation, causing inefficiency. Reset the RTO to a minimal value after each retransmission to speed up recovery risks spurious retransmissions. Disable retransmissions temporarily until RTT stabilizes is impractical and breaks reliability.
  4. Final Answer:

    Option A -> Option A
  5. Quick Check:

    Adaptive RTO balances responsiveness and stability under RTT fluctuations.
Hint: High RTT variance -> increase RTO variance to avoid spurious retransmits.
Common Mistakes:
  • Fixing RTO despite RTT changes
  • Resetting RTO too aggressively after retransmissions
  • Disabling retransmissions during network instability