DNS: how names become addresses

The internet's phone book

Humans remember names, networks deliver to numbers. DNS (Domain Name System) is the worldwide system that translates example.com into 93.184.215.14. No single computer holds the whole phone book. Instead the lookup walks a hierarchy, right to left through the name:

1. Your machine asks a resolver (usually run by your ISP, or a public one like 8.8.8.8): "what is the address of example.com?"
2. The resolver asks a root server: "who handles .com?" There are 13 named root server clusters that every resolver knows by heart.
3. The resolver asks the .com TLD server (top-level domain): "who handles example.com?"
4. The resolver asks that authoritative server, which owns the real answer: "example.com is 93.184.215.14."
5. The resolver hands the answer back and caches it, so the next lookup skips all of this until the answer expires.

Each DNS answer carries a TTL (time to live), the number of seconds a resolver may cache it before asking again.

DNS matters to working engineers because it fails in famous ways: a wrong or stale record after a deploy means "the site is down" for some users and fine for others, depending on whose resolver cached what. That is why the half-joking rule "it's always DNS" exists, and why checking DNS is step 1 of the debugging checklist in unit 9.

A recorded session

This session uses the two classic DNS lookup tools, one command at a time, with the output shown for each.

Each step below shows the command and the output it printed.

Step 1. dig is the standard DNS lookup tool. Ask it for example.com and look at the ANSWER SECTION: the record type A means an IPv4 address, and 3600 is the TTL in seconds.

$ dig example.com
;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.	3600	IN	A	93.184.215.14

;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

Step 2. The +short flag strips everything but the answer. Handy in scripts.

$ dig +short example.com
93.184.215.14

Step 3. nslookup is the older tool you will find on almost any machine, including Windows. Same question, same answer.

$ nslookup example.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	example.com
Address: 93.184.215.14

Step 4. Notice 'Non-authoritative answer': it came from the resolver's cache, not from example.com's own authoritative server. Cached answers are normal and fast. You can also ask for other record types, like MX (mail servers).

$ dig +short example.com MX
10 mail.example.com.

A resolver cache in miniature

This is the heart of a resolver: a cache in front of the authoritative answers.

cache = {}
authoritative = {"example.com": "93.184.215.14", "api.shop.com": "203.0.113.40"}

for name in ["example.com", "api.shop.com", "example.com", "example.com"]:
    if name in cache:
        print("HIT ", name, "->", cache[name])
    else:
        cache[name] = authoritative[name]
        print("MISS", name, "->", cache[name])

Output

MISS example.com -> 93.184.215.14
MISS api.shop.com -> 203.0.113.40
HIT  example.com -> 93.184.215.14
HIT  example.com -> 93.184.215.14

Reading the cache logic

• if name in cache: is the membership test that decides which branch runs, and it is the only question a cache ever asks.
• On a miss the code assigns first, so the same print(..., cache[name]) works in both branches. Populating before reading is what makes the two paths converge.
• Only the first lookup of each name prints MISS, and every repeat is a HIT. That repeat traffic is what makes DNS fast in practice, since the expensive four-server walk happens once per name rather than once per request.
• Real resolvers add a TTL timer to each entry, which this skips. Without expiry a cache would never notice a changed record, which is exactly the failure the next block is about.

What a TTL of 300 means

It means resolvers may cache this answer for 300 seconds before asking again.

TTL is time to live, measured in seconds. For those 5 minutes, any resolver that saw this answer serves it from its own cache without re-asking anyone.

This is why DNS changes take a while to propagate. Old cached answers have to expire first, and nothing you do at the authoritative server can reach into a resolver's memory and clear it early.

It also explains the uneven way a bad record plays out. Resolvers started their timers at different moments, so some users get the new address immediately while others keep the old one for minutes, which is why "the site is down for me but fine for you" is a DNS symptom.

The practical move is to lower the TTL before a planned change. Dropping it to 60 a day ahead means the whole world converges within a minute of the switch, and raising it back afterwards restores the caching benefit.

Which server owns the real answer

It is the authoritative server.

It is run by, or for, the domain's owner and holds the real records. Root and TLD servers only point the way to it, and resolvers only cache what it said.

It is step 4 in the lookup walk at the top of this lesson, and nslookup hinted at it by printing "Non-authoritative answer" for a cached result. That label is a statement about where the answer came from rather than about whether it is correct.

When you update a DNS record, what you are changing is what the authoritative server answers. Everything else in the system is a copy with an expiry date, which is the whole reason the previous block's propagation delay exists.