How DNS actually works

Most websites give you "the IP address" of a domain as if it's a single fixed number. It isn't. The same domain can resolve to different IPs for different people at the same moment, and that's by design. Here's what actually happens between typing a URL and the response showing up.

The chain, end to end

When you hit Enter on x.com in your browser, the request walks through five different pieces of software, each with a tiny, single-purpose job:

┌──────────┐    ┌───────────┐    ┌─────────────┐    ┌──────────────┐    ┌────────────────┐
│ Browser  │ -> │ OS stub   │ -> │ Router /    │ -> │ ISP recursive│ -> │ Internet at    │
│          │    │ resolver  │    │ home device │    │ resolver     │    │ large          │
└──────────┘    └───────────┘    └─────────────┘    └──────────────┘    └────────────────┘

1. Browser. Checks its own in-process cache first. Chrome and Firefox cache DNS answers for ~60 seconds separately from the OS.
2. OS stub resolver. Your laptop's network stack. Has one job: forward the question to whatever DNS server is configured (usually your router or the ISP). It's called a "stub" because it doesn't do the actual walking.
3. Router / home device. Most home routers just forward upstream; some run their own small cache. Same role as the stub.
4. ISP recursive resolver. The smart one. If it doesn't have a cached answer, it goes out and actually finds it — see the next section.
5. Cache and return. Once an answer comes back, it gets cached at every layer for the TTL (often 30-300 seconds). Next lookup skips most of the chain.

What the recursive resolver actually does

"Recursive" means "willing to walk the whole tree on your behalf." Asking 1.1.1.1 for x.com kicks off three more lookups:

1. Asks one of the 13 root nameservers: "who handles .com?" Root replies: "Verisign — go ask a.gtld-servers.net."
2. Asks the TLD nameserver: "who handles x.com?" TLD replies with the domain's authoritative nameservers.
3. Asks the authoritative nameserver: "what's the A record for x.com?" Authoritative replies with an actual IP. Done.

The four kinds of nameservers

TTL and why propagation takes a while

Every DNS record has a TTL (time-to-live) in seconds. When the recursive resolver caches an answer, it remembers it for that long. Same on the OS, the router, the browser. If a TTL is 300, your change won't be visible to half the internet for up to 5 minutes — sometimes longer because some resolvers (looking at you, certain ISPs and Windows DNS Client) cheat and hold answers past TTL.

Short TTLs (10-60 s) give the operator fast failovers and the ability to shift traffic. Long TTLs (hours) reduce DNS query load but make changes painful. Anything load-balanced or geo-routed runs short TTLs.

Traffic Manager and GSLB

"Traffic Manager" is Microsoft's brand name; AWS calls it Route 53 latency / geolocation routing; Cloudflare calls it Load Balancer; Akamai calls it GTM. They all do the same thing: they're smart authoritative nameservers.

A plain authoritative nameserver returns the same answer no matter who's asking. A traffic-manager authoritative nameserver looks at the question itself and picks a different answer per request based on:

• The source IP of the recursive resolver doing the asking — the authoritative server doesn't see your laptop, it sees your ISP's resolver. Geo-locating the resolver gives a rough idea of where you are.
• EDNS Client Subnet (ECS) when the recursive resolver includes it. ECS is an optional extension where the recursive resolver tells the authoritative server "my client is in 203.0.113.0/24," so the authoritative can pick a truly client-appropriate answer. Some recursive resolvers (Cloudflare's 1.1.1.1) deliberately strip ECS as a privacy stance; others (Google's 8.8.8.8) include it.
• Health of each backend. If a Frankfurt POP just went offline, the TM stops handing out its IP.
• Weights and priorities the operator configured (canary 5% of traffic to the new build, 95% to the old, etc.).

TTL is usually short (10-60 s) so the TM can rotate backends quickly. That's why WhatsApp resolves to 185.60.218.53 from Bucharest and to a different IP from Frankfurt at the same moment — Facebook's authoritative DNS is making a per-region decision.

Anycast vs Traffic Manager

Two completely different ways to route a user to a nearby server. Big services usually use both:

Why this matters for CertGrade

CertGrade scans run from our servers in Romania. If we resolve whatsapp.com from there, we get whatever IP Facebook's TM hands out for Romania-routed queries — a Bucharest endpoint. Someone in Portugal scanning the same domain would actually connect to a Lisbon or Madrid endpoint, and would see different IPs / cities / ASNs in the geo report.

To fix that we now do client-side DNS-over-HTTPS: before submitting the scan, the page makes a small HTTPS request from your browser to Google's DoH endpoint, gets back the IP your region would actually resolve, and passes that IP to the scanner. The Hosting & Jurisdiction card then reflects the endpoint someone in your region would connect to — not ours.

The TLS handshake itself still happens from Romania (the scan has to come from somewhere, and we can't fork the certificate chain or cipher list across regions). For unicast services that's perfect — the same IP is one box, same behaviour everywhere. For anycast services, the physical endpoint our scanner lands on might still differ from yours, but the IP and geo we display will match what your browser sees. That's the most honest answer we can give from a single scan origin.

Tools to dig deeper

• dnschecker.org — see how a domain resolves from 70+ vantages worldwide.
• dnsviz.net — visualize the DNSSEC chain for a domain.
• DNS-OARC — DNS operators' research org with great public talks.
• The DNS RFC (1035) if you want the canonical spec from 1987. Still the foundation.