The internet is just millions of computers agreeing to speak the same set of rules (protocols) so they can find each other and exchange data — even though they're built by different companies, running different software, on different continents.
1. The journey of a single request
When you type google.com into your browser and hit enter, a surprising number of steps happen in milliseconds:
Step-by-step:
Step 1 — DNS Lookup:
Browser ─────> DNS Resolver
"What's the IP address of google.com?"
Your browser doesn't know Google's actual server address — it only knows the name google.com. So it asks the DNS resolver to look it up.
Step 2 — DNS Response:
Browser <──── DNS Resolver
142.250.66.14
The resolver (after possibly doing its own iterative lookups through root → TLD → authoritative servers) returns the actual IP address. Now your browser knows where to send the actual request.
DNS's job is now finished. It only translates names to IP addresses.
Step 3 — TCP Handshake
Browser ─────> Server
Before any real data is exchanged, your browser and Google's server agree to open a reliable connection. This is a 3-step exchange:
- SYN(Synchronize) — I'd like to establish a TCP(Transmission Control Protocol) connection.
- SYN-ACK(Synchronize Acknowledgment) — I received your request, and I'm ready to connect.
- ACK(Acknowledgment) — Great, let's start communicating
Now the TCP connection is established.
At this point:
- The connection is reliable.
- Packets can be retransmitted if lost.
- Data arrives in order.
However, the connection is not encrypted yet.
Step 4 — TLS handshake:
Browser ─────────────> Google
Now the browser wants a secure connection because the URL starts with:https://
TLS (Transport Layer Security) negotiates encryption.
During this handshake:
1. Google sends its certificate
The server provides a digital certificate containing:
- Its public key
- Its domain name (google.com)
- The issuing Certificate Authority (CA)
- Its validity period
The browser verifies that the certificate is valid and trusted.
2. They agree on cryptographic algorithms
The browser and server negotiate:
- Which encryption algorithm to use (cipher suite)
- Which key exchange method to use
- Which protocol version (e.g., TLS 1.3)
3. They derive a shared session key
Using the negotiated key exchange (such as ECDHE), both sides independently compute the same symmetric session key.
This key is never transmitted directly over the network.
Now all communication becomes encrypted:
Browser 🔒=====================🔒 Google
- ECDHE(Elliptic Curve Diffie-Hellman Ephemeral): A key exchange algorithm used in TLS to securely generate a shared session key.
Step 5 — HTTP Request:
Now your browser finally asks for the actual page: "GET me the homepage." This is the actual HTTP request — everything before this was just setup to make this exchange possible and secure.
The request is encrypted because it travels inside the TLS connection.
Step 6 — Server Response:
Google's server processes the request and sends back an HTTP response.
The response often references additional resources, such as:
- CSS files
- JavaScript files
- Images
- Fonts
The browser then downloads those as separate HTTP requests.
Step 7 — Rendering:
The browser parses the HTML, CSS, and JavaScript files, and renders the page.
Summary:
- DNS(Domain Name System) lookup — translate the human-readable domain (
google.com) into a machine-usable IP address - TCP (Transmission Control Protocol) handshake — establish a reliable connection (SYN → SYN-ACK → ACK)
- TLS (Transport Layer Security) handshake — negotiate encryption so the connection is secure (HTTPS)
- HTTP request/response — the browser asks for the page, the server sends it back
- Rendering — the browser parses HTML/CSS/JS and paints the page
This whole flow usually takes under 200ms for a well-optimized site — DNS alone should ideally take single-digit to low double-digit milliseconds.
2. Interview Questions - I
3. The DNS hierarchy
DNS isn't one giant database — it's a distributed, hierarchical tree of servers, each responsible for a piece of the namespace.
| Level | Role | Example |
|---|---|---|
| Root servers | Know where to find TLD servers | 13 logical root server clusters worldwide |
| TLD(Top Level Domain) servers | Know where to find authoritative servers for a domain | .com, .org, .net, .io servers |
| Authoritative servers | Hold the actual DNS records for a specific domain | Google's own nameservers for google.com |
Recursive vs Iterative resolution
This is one of the most commonly misunderstood parts of DNS, and a favorite interview topic.
- Iterative queries: each server gives the resolver a referral ("I don't know, ask this other server") — the resolver does all the legwork, one hop at a time
- Recursive query: what you send to your resolver — you ask once, and expect a final answer, not a referral
The client (your browser/OS) always makes a recursive query. The resolver then does iterative queries on your behalf.
Common DNS record types
| Record | Purpose | Example |
|---|---|---|
| A | Maps a domain to an IPv4 address | example.com → 93.184.216.34 |
| AAAA | Maps a domain to an IPv6 address | example.com → 2606:2800:220:1:: |
| CNAME | Aliases one domain to another domain name | www.example.com → example.com |
| MX | Specifies mail servers for the domain | example.com → mail.example.com (priority 10) |
| TXT | Arbitrary text — often used for verification (SPF, DKIM, domain ownership) | "v=spf1 include:_spf.google.com ~all" |
| NS | Specifies which servers are authoritative for the domain | example.com → ns1.example.com |
| SOA | Start of Authority — admin info, refresh timers, zone version | Primary NS, admin email, serial number |
Caching and TTL
DNS lookups would be painfully slow if every request went all the way to the root. Caching happens at multiple layers:
Browser cache ──► OS cache ──► Router cache ──► ISP resolver cache ──► Authoritative server
(fastest) (slowest, source of truth)Each DNS record has a TTL (Time To Live) — how long it's allowed to be cached before it must be re-fetched.
| TTL choice | Trade-off |
|---|---|
| Low TTL (e.g. 60s) | Faster failover/changes propagate quickly, but more DNS query load and slightly higher average latency |
| High TTL (e.g. 24h) | Fewer lookups, faster cached responses, but changes take much longer to propagate everywhere |
Interview gold: before a planned server migration, engineers often lower the TTL on a record days in advance — so when the actual IP change happens, caches expire quickly and traffic shifts fast, instead of some users being stuck on the old server for hours.
DNS at system-design scale
This is where DNS moves from "trivia" to genuinely powerful infrastructure.
1. DNS-based Load Balancing
Instead of one IP, a domain can resolve to multiple IPs. The resolver (or client) picks one, often round-robin:
-- Not literal SQL — illustrating the mental model
api.example.com → [1.2.3.4, 1.2.3.5, 1.2.3.6]
-- Each new lookup may return a different order/IP, spreading load2. Geo-DNS / GSLB (Global Server Load Balancing)
DNS can return different IPs depending on where the request is coming from — routing users to the nearest data center.
User in Tokyo ──► asia-dns-server ──► 13.x.x.x (Tokyo data center)
User in Berlin ──► eu-dns-server ──► 34.x.x.x (Frankfurt data center)3. Anycast
Multiple physical servers in different locations all announce the same IP address. Internet routing (BGP) automatically sends each user's request to the topologically nearest server announcing that IP. This is how large CDNs and services like 8.8.8.8 (Google's DNS) achieve low latency worldwide — you're not really talking to one server, you're talking to whichever one is closest.
4. DNS Failover / Health Checks
Some DNS providers actively health-check backend servers and stop returning IPs for unhealthy ones — turning DNS into a crude but effective failover mechanism, especially combined with low TTLs.
5. Split-horizon DNS
The same domain name resolves differently depending on who's asking — internal company traffic gets routed to an internal IP, external traffic gets routed to the public-facing IP. Common in corporate networks and internal microservice setups.
DNS security concerns
| Threat | What it is | Mitigation |
|---|---|---|
| DNS Spoofing / Cache Poisoning | An attacker tricks a resolver into caching a fake IP for a domain | DNSSEC (cryptographically signs DNS records) |
| DNS Hijacking | An attacker gains control of DNS settings and redirects traffic | Registrar account security, registry locks |
| DDoS on DNS infrastructure | Flooding DNS servers to make a domain unreachable | Anycast (spreads load across locations), rate limiting |
| DNS Tunneling | Smuggling data through DNS queries to bypass firewalls | Monitoring unusual query patterns/volumes |
DNS vs Service Discovery (microservices context)
A subtlety senior engineers are expected to know: internal service-to-service communication in microservices often doesn't rely purely on public DNS.
| Approach | How it works | Used for |
|---|---|---|
| Public DNS | Standard hierarchical resolution, cached with TTLs | External-facing traffic |
| Service Mesh (e.g. Consul, Istio) | A control plane tracks live service instances directly, often bypassing DNS caching delays entirely | Internal microservice-to-microservice calls |
| Kubernetes DNS (CoreDNS) | Internal DNS resolves service names to pod/cluster IPs, updated near-instantly | In-cluster service discovery |
Why it matters: public DNS's caching-by-design nature (built for a mostly-static internet) works against the highly dynamic nature of containers scaling up/down constantly — hence specialized service discovery layers.
Interview Questions - II
1. Walk me through what happens when you type a URL into a browser and press Enter.
DNS resolution → TCP handshake → TLS handshake (if HTTPS) → HTTP request sent → server processes and responds → browser parses and renders the response. Strong answers also mention caching at each layer and connection reuse (keep-alive).
2. What's the difference between a recursive and an iterative DNS query?
A recursive query expects a final answer from the server it's asked (used by clients talking to their resolver). An iterative query returns a referral to another server if the one asked doesn't have the answer (used between resolvers and the DNS hierarchy).
3. Why does DNS use UDP instead of TCP?
DNS queries and responses are typically small and need to be fast — UDP avoids the overhead of a TCP handshake for every lookup. DNS falls back to TCP for larger responses (like DNSSEC) or zone transfers, where reliability matters more than raw speed.
4. What is TTL in DNS, and what trade-off does it involve?
TTL is how long a DNS record can be cached before it must be re-queried. Lower TTL means faster propagation of changes but more query load; higher TTL means fewer lookups but slower propagation.
5. How does a CDN use DNS to route users to the nearest server?
Through Geo-DNS or Anycast — Geo-DNS returns different IPs based on the resolver's location; Anycast lets multiple physical servers announce the same IP, with internet routing (BGP) sending each user to the topologically closest one.
6. What is DNS cache poisoning, and how is it prevented?
An attacker injects a fake DNS response into a resolver's cache, redirecting users to a malicious server. DNSSEC prevents this by cryptographically signing DNS records so resolvers can verify authenticity.
7. What's the difference between an A record and a CNAME record?
An A record points a domain directly to an IPv4 address. A CNAME points a domain to another domain name, which then gets resolved separately — useful for pointing subdomains to services without hardcoding IPs (which may change).
8. Why might a company lower their DNS TTL before a major infrastructure migration?
To ensure that when the IP address changes, caches around the world expire quickly and traffic shifts to the new servers fast, minimizing the window where users might hit the old (soon-to-be-decommissioned) infrastructure.
9. What is Anycast, and why is it useful for DNS infrastructure?
Anycast lets multiple servers in different physical locations share the same IP address; network routing automatically delivers each request to the nearest one. This reduces latency globally and provides natural DDoS resilience, since an attack against one location doesn't affect servers elsewhere announcing the same IP.
10. In a microservices architecture, why might teams avoid relying purely on public DNS for service-to-service communication?
Public DNS is designed around caching and relatively static records (via TTLs), which conflicts with the highly dynamic nature of containers scaling up and down. Service meshes or platform-native discovery (like Kubernetes' CoreDNS) update much closer to real-time, avoiding stale-cache issues that would cause requests to fail or hit terminated instances.
11. What is split-horizon DNS, and when would you use it?
A setup where the same domain resolves to different IPs depending on who's asking — internal requests get an internal/private IP, external requests get the public IP. Common in corporate networks so internal traffic doesn't need to leave the network to reach an internal service.
12. What's the difference between DNS-based load balancing and a traditional load balancer?
DNS-based load balancing distributes traffic by returning different IPs to different clients/queries — it's coarse-grained and affected by caching (a client might stick to one IP for the TTL duration). A traditional load balancer sits inline, inspecting and routing every single request in real time, enabling much finer-grained, immediate rebalancing and health-check-based failover.