Loading...
Loading...
How domain names get translated to IP addresses
Last topic traced an encapsulation diagram aimed at 93.184.216.34, wrapped as HTTP inside TCP inside IP inside Ethernet, with 1460 bytes of room per frame. Nobody typed that number. Servers find each other by number, with an IP address, meaning a numeric host address like 93.184.216.34. Humans cannot remember those, and should not have to. So every time you type a name, something has to translate it into a number first. That something is DNS, meaning the Domain Name System, the internet's distributed phone book, and it runs before literally everything else you will learn in this module.
One sentence version: DNS turns names you can remember into numbers computers can route to.
Your computer does not ask the whole internet every time. The rejected version would query the authoritative server, meaning the domain owner's server holding the true records, on every click. At millions of clicks a second that server melts, and every click pays the full round trip. Instead your machine asks a chain of helpers, cheapest first, and stops at whoever actually knows:
Visited recently? The answer is already sitting there. Zero network involved, valid until its TTL, meaning time-to-live expiry, runs out.
Missed the browser? The OS keeps its own small cache next, shared across apps on the same machine.
Usually your ISP's server, or a public one like 8.8.8.8, which is Google's free public resolver. This is the helper that does the real legwork below, walking the tree on your behalf and caching the result for thousands of users at once.
The resolver climbs down: root, meaning the top-level directory of all names, points to whoever runs .com, called a TLD meaning top-level-domain server, and .com points to the domain's own server.
The domain owner's server. It gives the final IP, and everyone up the chain remembers it for the TTL. Only this layer can change the truth. Everything above just remembers it.
A DNS answer is not always an IP. Different record types answer different questions. Here are the ones that show up in real work. An IPv4 address is the classic 32-bit number, while IPv6 is its longer 128-bit successor:
| Type | Question it answers | Looks like |
|---|---|---|
| A | What is the IPv4 address? | example.com → 93.184.216.34 |
| AAAA | What is the IPv6 address? | example.com → 2606:2800:... |
| CNAME | What is this name really called? | www → example.com |
| MX | Where does this domain's mail go? | mail.example.com (priority 10) |
| NS | Who is authoritative here? | ns1.example.com |
| TXT | Any attached notes? (ownership proofs, mail policy) | “v=spf1 include:...” |
Here is the trick worth knowing: nothing stops one name from having many answers. Ask for a big site's address in Berlin and you get a German server. Ask from Tokyo and you get a Japanese one. Same name, different numbers, routed by where you stand. That is GeoDNS, which is location-aware DNS that answers with the nearby datacenter, a global traffic system built out of a phone book.
Hand out different IPs per region, or rotate through several. Cheap, no extra hardware, works everywhere because every client already speaks DNS.
GeoDNS answers with the closest datacenter, shaving a hundred milliseconds off every first visit by replacing an ocean crossing with a local hop.
Health checks pull dead servers out of answers automatically. Traffic just stops going to the failed address once cached answers expire.
Every answer carries an expiry time, the TTL. Short expiry means fast failover but more lookups. Long expiry means the opposite. There is no correct value, only the trade-off you chose on purpose.
Every DNS answer carries an expiry stamp, and the whole failover story is that number. Set TTL to 300 seconds and a dead server stops receiving traffic within about five minutes, but every client re-asks every five minutes, so a popular name can mean thousands of extra lookups a second against your authoritative servers. Set it to 86400 seconds, a full day, and lookups nearly vanish, but a bad migration poisons clients for a full day. The arithmetic: cutting TTL from 3600 to 60 multiplies lookup load roughly 60-fold, so you buy failover speed with query volume. A second rejected option is pinning a 5-second TTL forever “for agility”: failover stays instant but you pay the 60-fold lookup tax every hour of every day, including the 364 days you never fail over.
| TTL you set | Failover feels like | Use it for |
|---|---|---|
| 30–60 s | Traffic moves in ~a minute; lookup load jumps 10–50× | Active failover names, blue-green cuts (lower it a day before) |
| 300 s (5 min) | The sane default, with minutes to drain and modest load | Most API and app names |
| 3600 s+ (hours) | Changes crawl; some resolvers cap or ignore tiny TTLs anyway | Stable infra names, MX/TXT records that rarely move |
Two gotchas worth memorizing: browsers and OS caches add their own floors on top of your TTL, so the effective wait is your TTL plus their minimums, and negative answers, called NXDOMAIN meaning “this name does not exist,” are cached too, so a typo during setup can linger for the full negative TTL. Lower TTLs 24–48 hours before a planned move, then raise them after so you are not paying the lookup tax forever.
Your app can be perfectly healthy and globally unreachable, because nobody can find it. The pattern repeats: a team migrates to new IPs but leaves a 24-hour TTL, so half the world keeps knocking on the old address for a day. With 24 hours of caching, even a 10-minute fix takes a day to reach everyone. Or a DNS provider has an outage and every name they host vanishes at once, with the servers up, the traffic at zero, and nothing to restart except waiting.
Health checks pulled the dead IP out of the authoritative answer, but clients with cached records keep calling the failed address until TTL expiry. Users see intermittent failures (“works for my friend, not for me”), which is the signature of a caching layer, not a server bug. Short TTLs on failover-critical names plus multiple A records, meaning several IPs returned for one name so one dead IP is not the only answer, blunt it.
Forged answers redirect users to lookalike sites, called cache poisoning, and DNS amplification, meaning tiny queries that trigger giant responses aimed at a victim, turns the system into a weapon. DNSSEC signs answers so forgeries fail validation, while anycast, meaning the same address served from many places so load spreads, plus rate-limiting absorb the floods. Adoption of DNSSEC is still uneven, which is exactly why its gaps keep showing up in outages.
You hold 93.184.216.34 with a 300-second TTL, multiple A records for failover, and GeoDNS pointing Berlin and Tokyo at different doors. But an address alone moves no bytes. The next question is transport: once the SYN leaves for that address, does every parcel get tracked and resent like registered mail, or flung like a postcard?