Senior 4 min · June 25, 2026

How DNS Works: From Browser to Server Without Getting Lost

How DNS works explained from first principles.

N
Naren Founder & Principal Engineer

20+ years shipping large-scale distributed systems. Written from production experience, not tutorials.

Follow
✓ Production
production tested
June 25, 2026
last updated
1,663
articles · all by Naren
 ● Production Incident 🔎 Debug Guide ⚙ Triage Commands
⚡Quick Answer

DNS works by querying a hierarchy of servers: your browser first checks its cache, then asks a recursive resolver (usually your ISP or a public DNS like 8.8.8.8), which walks through root, TLD, and authoritative nameservers to find the IP address for a domain.

✦ Definition~90s read
What is How DNS Works?

DNS (Domain Name System) translates human-readable domain names like example.com into machine-readable IP addresses. It's the phonebook of the internet, enabling browsers to find and load websites.

★
Think of DNS like a taxi dispatcher.
Plain-English First

Think of DNS like a taxi dispatcher. You tell the dispatcher "Take me to Joe's Pizza" (the domain name). The dispatcher doesn't know every address, but they have a list of city zones (TLD servers). They call the zone for "Pizza" which knows all pizza places, and that zone gives them Joe's exact street address (IP). The dispatcher then tells the driver, and you get your pizza. Your phone book (cache) might already have Joe's address from last time, skipping the whole call.

You type a URL and hit Enter. Two seconds later, the page loads. Magic, right? Wrong. That two seconds hides a chain of network calls that can — and will — fail in spectacular ways. I've seen a misconfigured DNS record take down a payment service for 45 minutes because the TTL was set to 86400 seconds (24 hours) and nobody could flush the cache.

DNS is the internet's phonebook. Without it, you'd be typing 142.250.190.46 instead of google.com. But it's not just a simple lookup — it's a distributed, hierarchical system designed to handle billions of queries daily. Understanding how it works is the difference between a 5-minute fix and a 3am outage.

By the end of this article, you'll be able to trace a DNS lookup from browser to server, debug common failures using dig and nslookup, and explain why your DNS change isn't propagating (spoiler: it's the TTL).

The Problem DNS Solves: Human Memory vs. Machine Numbers

Computers communicate using IP addresses — strings of numbers like 192.0.2.1 (IPv4) or 2001:db8::1 (IPv6). Humans are terrible at remembering numbers. We remember names. DNS bridges this gap. Before DNS, the internet used a single file called HOSTS.TXT that mapped names to IPs. It was maintained by a central authority and downloaded nightly. As the internet grew, this became impossible — the file was huge, updates were slow, and there was no redundancy. DNS replaced it with a distributed, hierarchical system that scales globally.

HostsFileExample.systemdesignSYSTEMDESIGN
1
2
3
4
5
6
7
8
9
10
// io.thecodeforge — System Design tutorial

// The old way: a static HOSTS file (still exists on your machine!)
// Location: /etc/hosts (Linux/Mac) or C:\Windows\System32\drivers\etc\hosts (Windows)

127.0.0.1   localhost
::1         localhost
192.0.2.1   example.com  # This overrides DNS for example.com

// To test: ping example.com will go to 192.0.2.1, not the real IP
Output
PING example.com (192.0.2.1) 56(84) bytes of data.
Senior Shortcut:
Use /etc/hosts to override DNS for local development. Add 127.0.0.1 myapp.local to test a local server without touching DNS. Just remember to remove it when done — I've seen staging boxes pointing to localhost for weeks.
DNS Lookup: From Browser to IP Address THECODEFORGE.IO DNS Lookup: From Browser to IP Address Step-by-step resolution of a domain name to an IP address Browser Query User types example.com, OS checks cache Recursive Resolver ISP or public resolver (e.g., 8.8.8.8) Root & TLD Servers Root points to .com TLD, TLD to authoritative Authoritative Nameserver Returns A or AAAA record for domain Cached Response Resolver caches result for TTL duration ⚠ Stale cache returns wrong IP after record change Reduce TTL before changes, flush caches, or use short TTL for critical updates THECODEFORGE.IO
thecodeforge.io
DNS Lookup: From Browser to IP Address
Dns How It Works

The DNS Hierarchy: Root, TLD, and Authoritative Nameservers

DNS is a tree. At the top are 13 root nameservers (named A through M), operated by organizations like Verisign, ICANN, and NASA. They don't know every domain — they know where to find the Top-Level Domain (TLD) servers. TLDs are .com, .org, .net, .io, etc. Each TLD has its own set of nameservers that know the authoritative nameservers for every domain under that TLD. The authoritative nameserver is the final source of truth for a domain — it holds the actual DNS records (A, AAAA, CNAME, MX, etc.). When you buy a domain from a registrar, you point it to your authoritative nameserver (often your hosting provider or a DNS service like Route53).

DNSTree.systemdesignSYSTEMDESIGN
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// io.thecodeforge — System Design tutorial

// Visualizing the DNS hierarchy for www.example.com
//
// Root (.) — 13 servers, know where .com is
//   |
//   +-- .com TLD — knows where example.com's nameservers are
//         |
//         +-- example.com (authoritative) — knows www.example.com is 93.184.216.34
//
// Query flow:
// 1. Browser asks local resolver: "What's www.example.com?"
// 2. Resolver asks root: "Who manages .com?"
// 3. Root replies: "Ask a.gtld-servers.net"
// 4. Resolver asks .com TLD: "Who manages example.com?"
// 5. TLD replies: "Ask ns1.example.com"
// 6. Resolver asks ns1.example.com: "What's www.example.com?"
// 7. ns1 replies: "93.184.216.34"
// 8. Resolver gives IP to browser
//
// This is a recursive query (resolver does the work).
// Iterative query: resolver asks each server directly, getting referrals.
Output
www.example.com has address 93.184.216.34
Production Trap:
Root server IPs are anycasted — multiple physical servers share the same IP. This distributes load but means a root server can be in a different continent. Latency varies. Always use a resolver close to your users (e.g., AWS Route53 Resolver in the same region).

Recursive vs. Iterative Queries: Who Does the Work?

When your browser needs an IP, it sends a recursive query to a DNS resolver (usually your ISP or a public resolver like 8.8.8.8). The resolver does all the walking — it queries root, TLD, and authoritative servers on your behalf, then returns the answer. This is called recursion. Alternatively, the resolver can do an iterative query: it asks each server for a referral to the next level, without the server doing any extra work. The resolver itself follows the chain. Most end-user resolvers use recursion. Authoritative servers only answer for domains they own — they don't recurse. This separation of concerns is what makes DNS scalable.

RecursiveVsIterative.systemdesignSYSTEMDESIGN
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// io.thecodeforge — System Design tutorial

// Simulating a recursive query with dig (+trace shows iterative steps)
// Command: dig +trace www.example.com

// Output (simplified):
; <<>> DiG 9.16.1 <<>> +trace www.example.com
;; global options: +cmd
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
;; Received 525 bytes from 192.168.1.1#53(local resolver) in 0 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
;; Received 1113 bytes from 198.41.0.4#53(a.root-servers.net) in 12 ms

example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.
;; Received 557 bytes from 192.5.6.30#53(a.gtld-servers.net) in 4 ms

www.example.com.        86400   IN      A       93.184.216.34
;; Received 244 bytes from 199.43.0.42#53(a.iana-servers.net) in 10 ms
Output
www.example.com. 86400 IN A 93.184.216.34
Interview Gold:
Interviewers love asking: 'What's the difference between recursive and iterative queries?' The key: recursion is done by the resolver on behalf of the client; iteration is done by the client (or resolver) following referrals. Recursion shifts load to the resolver.
Recursive DNS Query WalkTHECODEFORGE.IORecursive DNS Query WalkResolver does all the work on your behalfBrowserSends recursive query to resolverResolverQueries root, TLD, authoritativeRoot ServerReturns TLD nameserver referralTLD ServerReturns authoritative NS for domainAuthoritativeReturns final IP address record⚠ Resolver caches result; subsequent lookups skip the walkTHECODEFORGE.IO
thecodeforge.io
Recursive DNS Query Walk
Dns How It Works

DNS Caching: Speed vs. Freshness

Every DNS response includes a Time-To-Live (TTL) value in seconds. This tells the resolver how long to cache the record. Caching is essential — without it, every page load would trigger a full DNS walk, taking seconds. But caching is also the source of the classic 'DNS propagation delay' myth. There's no central propagation. Each resolver caches independently and respects TTL. If you change a DNS record, old cached entries persist until TTL expires. That's why you lower TTL before changes. Common TTLs: 300s (5 min) for dynamic environments, 86400s (24h) for stable records.

CacheExample.systemdesignSYSTEMDESIGN
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// io.thecodeforge — System Design tutorial

// Check cached DNS entry on your system (Linux/Mac)
// Command: dig example.com +ttlid

// Output:
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            86342   IN      A       93.184.216.34

// The 86342 is the remaining TTL in seconds (about 24 hours from original 86400)
// This means the resolver cached this 58 seconds ago.

// To flush local DNS cache:
// Linux: sudo systemd-resolve --flush-caches
// Mac: sudo killall -HUP mDNSResponder
// Windows: ipconfig /flushdns
Output
example.com. 86342 IN A 93.184.216.34
Never Do This:
Setting TTL to 0 for 'instant updates' is a terrible idea. It kills caching, increasing DNS query load by orders of magnitude. Your resolver will be hammered. Use 300s as a minimum for production.
DNS Caching: Speed vs. FreshnessTHECODEFORGE.IODNS Caching: Speed vs. FreshnessTTL controls how long data stays cachedShort TTL (60s)Fast propagation of changesHigher resolver load per domainGreat for load balancing failoverMore frequent full lookupsLong TTL (86400s)Excellent cache hit ratioStale IPs during outagesLow load on authoritative serversSlow DNS change propagationBalance TTL: short for critical services, long for stable recordsTHECODEFORGE.IO
thecodeforge.io
DNS Caching: Speed vs. Freshness
Dns How It Works

DNS Record Types: A, AAAA, CNAME, MX, and More

DNS records map domain names to various types of data. The most common: A (IPv4 address), AAAA (IPv6 address), CNAME (canonical name — alias to another domain), MX (mail exchange server), TXT (arbitrary text, often for SPF or verification), NS (nameserver), and SOA (start of authority — administrative info). A common mistake is using a CNAME for the root domain (e.g., example.com) — CNAMEs cannot coexist with other records at the same name. Use an ALIAS or A record for the root. For subdomains like www, CNAME is fine.

DNSRecords.systemdesignSYSTEMDESIGN
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// io.thecodeforge — System Design tutorial

// Example DNS zone file for example.com
$TTL 86400
@   IN  SOA     ns1.example.com. admin.example.com. (
                2025031401  ; Serial
                3600        ; Refresh
                1800        ; Retry
                604800      ; Expire
                86400       ; Minimum TTL
                )

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.
@       IN  A       93.184.216.34
www     IN  A       93.184.216.34
mail    IN  A       93.184.216.35
@       IN  MX 10   mail.example.com.
@       IN  TXT     "v=spf1 include:_spf.google.com ~all"

// CNAME example: alias www2 to www
www2    IN  CNAME   www.example.com.

// Note: CNAME cannot be used at the root (@) because it would conflict with other records like SOA and NS.
Output
// No direct output; zone file is loaded by nameserver.
The Classic Bug:
Using a CNAME at the root domain (example.com) will break your MX records and email delivery. The DNS spec forbids other records at the same name as a CNAME. Always use an A/AAAA record for the root.

The Full DNS Lookup: Step by Step

Let's trace what happens when you type www.example.com in a browser. 1. Browser checks its own cache (Chrome: chrome://net-internals/#dns). 2. If not found, it asks the OS (which may have cached from other apps). 3. OS asks the configured resolver (usually your router or ISP). 4. Resolver checks its cache. 5. If not cached, resolver queries a root server (e.g., a.root-servers.net) for the .com TLD servers. 6. Root responds with a list of TLD servers for .com. 7. Resolver queries a .com TLD server (e.g., a.gtld-servers.net) for example.com's nameservers. 8. TLD responds with ns1.example.com and ns2.example.com. 9. Resolver queries ns1.example.com for www.example.com. 10. Authoritative server responds with the A record: 93.184.216.34. 11. Resolver caches the result for the TTL duration and returns it to the OS. 12. OS caches it and returns to browser. 13. Browser opens a TCP connection to that IP.

FullLookup.systemdesignSYSTEMDESIGN
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// io.thecodeforge — System Design tutorial

// Use dig to see the full lookup with timing
// Command: dig www.example.com +stats

; <<>> DiG 9.16.1 <<>> www.example.com +stats
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com.               IN      A

;; ANSWER SECTION:
www.example.com.        86400   IN      A       93.184.216.34

;; AUTHORITY SECTION:
example.com.            86400   IN      NS      a.iana-servers.net.
example.com.            86400   IN      NS      b.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net.     86400   IN      A       199.43.0.42
b.iana-servers.net.     86400   IN      A       199.43.1.42

;; Query time: 23 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Mar 14 12:00:00 UTC 2025
;; MSG SIZE  rcvd: 123
Output
www.example.com. 86400 IN A 93.184.216.34
;; Query time: 23 msec
Production Trap:
The 'Query time' in dig output is the time to get a response from the resolver, not the full walk. If the resolver has it cached, it's fast. To see the full iterative walk, use dig +trace. I've seen resolvers take 5+ seconds on cold cache — that's your page load time.

DNS Security: DNSSEC and Spoofing

Standard DNS has no authentication. A malicious actor can spoof a DNS response and redirect users to a fake site (DNS cache poisoning). DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, allowing resolvers to verify authenticity. It uses a chain of trust from the root zone down to the domain. When DNSSEC is enabled, the resolver checks signatures. If a record is tampered with, the resolver returns SERVFAIL. However, DNSSEC adds complexity and latency. Many domains still don't use it. For critical services, always enable DNSSEC. The classic attack: Kaminsky attack (2008) allowed poisoning of recursive resolvers by flooding with fake responses. DNSSEC prevents this.

DNSSECCheck.systemdesignSYSTEMDESIGN
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// io.thecodeforge — System Design tutorial

// Check if a domain has DNSSEC enabled using dig
// Command: dig example.com +dnssec

; <<>> DiG 9.16.1 <<>> example.com +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54321
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            86400   IN      A       93.184.216.34
example.com.            86400   IN      RRSIG   A 8 2 86400 20250314120000 20250307120000 12345 example.com. ...

// The 'ad' flag in the header means the response was authenticated (DNSSEC validated).
// The RRSIG record is the signature.
// If DNSSEC validation fails, you'll see status: SERVFAIL.
Output
example.com. 86400 IN A 93.184.216.34
example.com. 86400 IN RRSIG A 8 2 86400 ...
Never Do This:
Disabling DNSSEC validation on your resolver to 'fix' SERVFAIL errors is dangerous. You're disabling security. Instead, fix the DNSSEC configuration on your domain. Use tools like dnsviz.net to debug.

Common DNS Failures and How to Debug Them

DNS failures are insidious because they often look like network issues. The most common: NXDOMAIN (domain doesn't exist), SERVFAIL (server failure, often DNSSEC related), timeout (no response), and wrong IP (stale cache or misconfigured record). Debug with dig. For NXDOMAIN, check if the domain is registered and nameservers are correct. For SERVFAIL, check DNSSEC. For timeouts, check firewall rules (UDP port 53) and resolver availability. For wrong IP, check TTL and wait or flush cache. I once spent an hour debugging a 'connection refused' error only to find the A record pointed to an old server that had been decommissioned.

DebugDNS.systemdesignSYSTEMDESIGN
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// io.thecodeforge — System Design tutorial

// Debugging commands for common DNS issues

// 1. Check basic resolution
// Command: dig example.com
// Look for status: NOERROR, and ANSWER section with IP.

// 2. Check specific record type
// Command: dig example.com MX

// 3. Trace the full path
// Command: dig +trace example.com

// 4. Query a specific nameserver directly
// Command: dig @ns1.example.com example.com

// 5. Check DNSSEC
// Command: dig example.com +dnssec

// 6. Reverse DNS lookup (PTR)
// Command: dig -x 93.184.216.34

// 7. Check if resolver is working
// Command: dig google.com
// If this fails, your resolver is down. Try switching to 8.8.8.8 temporarily.

// Example output for a failed query:
; <<>> DiG 9.16.1 <<>> nonexistent.example.com
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11111
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;nonexistent.example.com.       IN      A

;; AUTHORITY SECTION:
example.com.            86400   IN      SOA     ns1.example.com. admin.example.com. ...
Output
status: NXDOMAIN
Senior Shortcut:
When debugging DNS, always check the SOA record first. It tells you the authoritative nameserver and the admin email. If the SOA is missing or wrong, the domain is misconfigured. Use dig example.com SOA.
● Production incidentPOST-MORTEMseverity: high

The 24-Hour DNS Blackout

Symptom
Users in Asia couldn't access our SaaS dashboard. US users were fine. Support tickets flooded in.
Assumption
We assumed a regional CDN outage or a routing issue.
Root cause
A junior engineer had changed the A record for our domain but left the TTL at 86400 seconds (24 hours). The old IP was cached by Asian ISPs. The new IP was only seen by users who had never visited before.
Fix
We reduced TTL to 300 seconds (5 minutes) 24 hours before the change, then updated the record. For the current mess, we had to contact major ISP support to manually clear their caches.
Key lesson
  • Always lower TTL to 300 seconds at least 24 hours before any DNS change.
  • Then wait for propagation before making the switch.
Production debug guideSystematic recovery paths for the failure modes engineers actually hit.3 entries
Symptom · 01
Users report 'site not found' or browser shows DNS_PROBE_FINISHED_NXDOMAIN
→
Fix
1. Run dig example.com from a server in the same region. 2. If NXDOMAIN, check domain registration and nameserver delegation. 3. Verify authoritative nameservers respond: dig @ns1.example.com example.com. 4. Check SOA record: dig example.com SOA. 5. If all else fails, contact domain registrar.
Symptom · 02
Intermittent failures, some users can reach site, others get wrong IP
→
Fix
1. Check TTL of the record: dig example.com +ttlid. 2. If TTL is high (e.g., 86400), wait or flush caches. 3. Check if multiple A records exist (round-robin). 4. Verify all IPs are reachable: curl -I http://<ip>. 5. Consider using a traffic manager like Route53 latency-based routing.
Symptom · 03
Slow page load, DNS lookup taking >1s
→
Fix
1. Measure lookup time: dig example.com +stats. 2. If query time > 1s, check resolver latency: dig @8.8.8.8 example.com. 3. If fast with 8.8.8.8, switch to a faster resolver. 4. Check if authoritative server is slow: dig @ns1.example.com example.com +stats. 5. Consider using a DNS caching proxy like dnsmasq locally.
★ DNS Triage Cheat SheetFirst-response commands for when things go wrong — copy-paste ready.
`dig example.com` returns `status: NXDOMAIN`−
Immediate action
Check if domain is registered and nameservers are correct.
Commands
dig example.com SOA
whois example.com
Fix now
Update nameserver records at registrar to point to correct authoritative servers.
`dig example.com` returns `status: SERVFAIL`+
Immediate action
Check DNSSEC configuration.
Commands
dig example.com +dnssec
dnsviz.net/g/example.com
Fix now
Fix DNSSEC chain or disable DNSSEC temporarily (not recommended).
`dig example.com` times out (no response)+
Immediate action
Check firewall and resolver availability.
Commands
dig @8.8.8.8 example.com
telnet 8.8.8.8 53
Fix now
Allow UDP port 53 outbound in firewall, or switch to a working resolver.
`dig example.com` returns old IP after change+
Immediate action
Check TTL and flush caches.
Commands
dig example.com +ttlid
sudo systemd-resolve --flush-caches
Fix now
Wait for TTL to expire or lower TTL before future changes.
FeatureRecursive QueryIterative Query
Who does the workResolver walks the chainClient (or resolver) follows referrals
Typical useEnd-user DNS resolutionServer-to-server (e.g., root servers)
Load on resolverHigh (does all lookups)Low (only returns referrals)
CachingResolver caches final answerEach level may cache referrals

Key takeaways

1
DNS is a hierarchical, distributed system
not a central phonebook. Understanding the tree (root → TLD → authoritative) is key to debugging.
2
TTL controls caching duration. Always lower it before planned DNS changes. Never set TTL to 0 in production.
3
CNAME records cannot be used at the root domain. Use A/AAAA for root, CNAME for subdomains only.
4
DNSSEC prevents cache poisoning but adds complexity. Enable it for critical domains and monitor with tools like dnsviz.net.
INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Q01SENIOR
How does DNS handle a CNAME record at the root domain, and what happens ...
Q02SENIOR
When would you choose a low TTL (e.g., 60s) vs a high TTL (e.g., 86400s)...
Q03SENIOR
What happens when a recursive resolver receives a DNS response with a TT...
Q04JUNIOR
What is the difference between an A record and a CNAME record?
Q05SENIOR
You deploy a new web server and update the A record for www.example.com....
Q06SENIOR
How would you design a DNS infrastructure for a global SaaS platform ser...
Q01 of 06SENIOR

How does DNS handle a CNAME record at the root domain, and what happens to other records like MX?

ANSWER
A CNAME at the root is invalid per RFC 1034 because it conflicts with other mandatory records (SOA, NS). If you try, most DNS software will ignore the CNAME or cause undefined behavior. MX records will fail because the CNAME takes precedence. Always use an A/AAAA record for the root.
FAQ · 4 QUESTIONS

Frequently Asked Questions

01
How does DNS work step by step?
02
What's the difference between A and CNAME records?
03
How do I check my DNS records?
04
Why is my DNS change not propagating?
Related Articles
TCP vs UDPBeginnerThe OSI ModelBeginnerHTTP/1.1 vs HTTP/2 vs HTTP/3 (QUIC)IntermediateWebSockets ExplainedIntermediateLong Polling vs SSE vs WebSocketsIntermediateIP Addressing and AnycastIntermediate
N
Naren Founder & Principal Engineer

20+ years shipping large-scale distributed systems. Written from production experience, not tutorials.

Follow
✓ Verified
production tested
June 25, 2026
last updated
1,663
articles · all by Naren
🔥

That's Networking. Mark it forged?

4 min read · try the examples if you haven't

←
Previous
Bandwidth Estimation Techniques
1 / 7 · Networking
Next
TCP vs UDP
→