💡 The client uses the resolved IP to proceed with HTTP or other protocols.
def dns_resolution(domain):
# STEP 1: Browser creates and sends query
query_packet = create_dns_query(domain) # STEP 1
send_packet('browser', 'local_resolver', query_packet) # STEP 1
# STEP 2: Local resolver receives and checks cache
packet = receive_packet('local_resolver') # STEP 2
if not cache_hit(domain): # STEP 2
send_packet('local_resolver', 'root_dns', packet) # STEP 2
# STEP 3: Root DNS server processes and replies with referral
packet = receive_packet('root_dns') # STEP 3
referral = get_tld_referral(domain) # STEP 3
send_packet('root_dns', 'local_resolver', referral) # STEP 3
# STEP 4: Local resolver sends query to TLD DNS server
referral = receive_packet('local_resolver') # STEP 4
send_packet('local_resolver', 'tld_dns', create_dns_query(domain)) # STEP 4
# STEP 5: TLD DNS server replies with authoritative referral
packet = receive_packet('tld_dns') # STEP 5
referral = get_authoritative_referral(domain) # STEP 5
send_packet('tld_dns', 'local_resolver', referral) # STEP 5
# STEP 6: Local resolver queries authoritative DNS server
referral = receive_packet('local_resolver') # STEP 6
send_packet('local_resolver', 'auth_dns', create_dns_query(domain)) # STEP 6
# STEP 7: Authoritative DNS server replies with IP
packet = receive_packet('auth_dns') # STEP 7
answer = get_ip_address(domain) # STEP 7
send_packet('auth_dns', 'local_resolver', answer) # STEP 7
# STEP 8: Local resolver caches the IP
response = receive_packet('local_resolver') # STEP 8
cache_store(domain, response.data) # STEP 8
# STEP 9: Local resolver sends IP to browser
send_packet('local_resolver', 'browser', create_dns_response(response.data)) # STEP 9
# STEP 10: Browser receives IP
response = receive_packet('browser') # STEP 10
ip_address = extract_ip(response) # STEP 10
return ip_address
📊
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 fill★Answer 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
src→192.168.1.2:5353
dst→192.168.1.1:53
data→www.example.com
flags→query
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
src→192.168.1.1:53
dst→198.41.0.4:53
data→www.example.com
flags→query
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
src→198.41.0.4:53
dst→192.168.1.1:53
data→.com TLD DNS Server IP
flags→referral
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
src→192.168.1.1:53
dst→192.0.2.53:53
data→www.example.com
flags→query
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
src→192.0.2.53:53
dst→192.168.1.1:53
data→Authoritative DNS Server IP
flags→referral
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
src→192.168.1.1:53
dst→203.0.113.53:53
data→www.example.com
flags→query
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
src→203.0.113.53:53
dst→192.168.1.1:53
data→93.184.216.34
flags→response
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
src→192.168.1.1:53
dst→192.168.1.2:5353
data→93.184.216.34
flags→response
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
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.
Step 2: Understand the edge server's function
Edge servers cache content closer to users geographically, reducing latency by serving requests locally.
Step 3: Clarify DNS server's role
DNS servers resolve domain names but do not serve content directly.
Step 4: Load balancer's responsibility
Load balancers distribute traffic among origin servers but do not cache content at the edge.
Final Answer:
Option A -> Option A
Quick Check:
Edge servers reduce latency by caching content near users, which is the core CDN principle.
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
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.
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.
Step 3: CDN role
CDNs cache content to improve performance but do not filter traffic for security.
Final Answer:
Option B -> Option B
Quick Check:
Firewall is the component that filters traffic based on rules [OK]
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
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.
Step 2: Analyze other methods
POST, PUT, and DELETE modify server state and are not safe methods.
Final Answer:
Option A -> Option A
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
Step 1: Define stale-while-revalidate
This strategy serves stale content immediately after TTL expiry while asynchronously fetching fresh content.
Step 2: User experience
User gets content without delay, improving perceived performance.
Step 3: Background refresh
Edge server updates cache with fresh content once fetched.
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.
Final Answer:
Option A -> Option A
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
Step 1: Understand RTO adaptation to RTT variance
TCP's RTO algorithm uses both RTT estimate and variance to adapt timeout dynamically.
Step 2: Analyze handling of large RTT variations
Increasing variance estimate prevents premature retransmissions caused by transient delays, trading off some delay for stability.
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.
Final Answer:
Option A -> Option A
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