Skip to main content

DNS — a distributed system that runs on delegation

DNS is described as "the mechanism for turning a domain name into an IP address". That's correct, but if you also understand why no single server holds every domain name in the world, you'll be able to see when a change gets reflected and how to triage trouble.

The key is delegation.

What you'll learn in this chapter​

  • Which servers name resolution walks through, in what order
  • How zones and delegation work, and who can decide subdomains
  • How TTL controls caching
  • What "propagation" actually refers to
Prerequisites

Builds on the IP address discussion from TCP/IP.

What DNS returns​

DNS is a mechanism for looking up information tied to a domain name. The most-used case is getting an IP address, but it returns more than that.

Record typeReturns
AIPv4 address
AAAAIPv6 address
CNAMEAnother domain name (alias)
MXServer that receives mail
NSThe nameservers managing the zone
TXTArbitrary text (ownership proof, SPF, etc.)

CNAME carries a constraint the other types don't. A name with a CNAME can hold no records of any other type. A zone's apex (example.com itself) always holds NS, so the apex cannot hold a CNAME. To point the apex at a CDN or a load balancer, you use a record the DNS vendor provides. Route 53's alias records are one example; they are not a standard record type, so the name and the behavior differ by vendor.

DNS handles only names and the records tied to them. Terminals need other network settings like a subnet mask to start communicating, and distributing those is DHCP's job. RFC 2132 defines subnet mask as option code 1 and DNS server address as option code 6, both as DHCP options. That's why DNS looks adjacent to it — but the jobs are different.

The resolution flow​

Resolving www.example.com involves four kinds of servers.

ServerRole
Full-service resolverWalks queries in order on the user's behalf. Run by ISPs, 8.8.8.8, etc.
Root serverKnows where to ask for each TLD
TLD serverKnows the authoritative servers for names under .com (etc.)
Authoritative serverHolds the actual records for the zone

The point is that the root server doesn't know the IP for www.example.com. What the root knows is ".com's people are over there". What .com knows is "example.com's people are over there". Each level holds only the referral to one level below.

Zones and delegation​

DNS works as a distributed system because of this chain of "one-level-down referrals".

RFC 1034 states that authoritative data is divided into units called zones and distributed to nameservers. It also spells out the reason: the size of the database and the frequency of updates require distributed management, and gathering a consistent copy centrally would be increasingly expensive and difficult.

Not every zone is managed by the root. The root holds only delegations to TLDs; the records for example.com are on that organization's authoritative servers.

Subdomains are yours to create​

An organization delegated a zone can handle everything below it at its discretion. RFC 1034 describes an organization's authority once it has its zone under control: it may unilaterally change data in the zone, extend new branches, delete existing nodes, and delegate new subzones underneath.

So a person managing example.com can set up blog.example.com, api.example.com, and staging.api.example.com themselves — without asking anyone above. No application to a superior is needed. The actual operations are covered in Practical AWS Guide — Route 53 and ACM, which walks through hosted zone creation. The certificates ACM issues are covered by TLS and certificates.

This is the essence of delegation. The parent only declares "this range is yours to manage" and stays out of the contents. That's how the world's domains can run without central management.

You can also re-delegate further below. Delegating everything under dept.example.com to a department's nameservers gives a nested structure.

TTL and caching​

If every query walked from the root every time, the root couldn't cope. That's where caching comes in.

RFC 1034 defines TTL as "the upper limit on the time this resource record may be kept in a cache", and the value is decided by the manager of the zone that is the source of the data. TTL is not "until such-and-such time" but "seconds since receiving", so it isn't affected by clock drift between devices (Datetimes and time zones).

www.example.com.    300    IN    A    203.0.113.5
                    ^^^ TTL (seconds)

In this example, resolvers cache the answer for 300 seconds; queries within that window are answered without going to the authoritative server. After 300 seconds, they discard and fetch again on the next query.

Caches live not only in resolvers but in OSes and browsers too.

Answers returned from cache are flagged as "not an authoritative answer". Even if the value is correct, the source is distinguishable as not being the authoritative server.

What "propagation" actually is​

After changing DNS, people say "it takes time to propagate". That phrase does not correctly describe what's happening.

What actually happens:

  1. Records on the authoritative server are rewritten. This is instant
  2. But resolvers around the world still cache the old value until TTL
  3. Resolvers whose TTL has expired come to fetch the new value, one at a time
  4. Once every resolver's cache has expired, everyone sees the new value

That is, it's not "new information spreading around the world"; it's "old information expiring away". The direction is reversed.

What you wait to expire isn't only old values. When someone looks up a name that doesn't exist yet, the "no such name" answer is cached too. If a record you just added still doesn't resolve, that answer is what's left. The upper bound on how long it is held comes from the zone's SOA record, which carries the zone's administrative information. Shortening the A record's TTL doesn't reach it.

The distinction changes what you do about it.

MisunderstandingWhat follows
"There's nothing to do but wait for it to spread"Actually, lowering TTL in advance controls the wait (for records inside your own zone)
"Ask the root server for the latest"The root doesn't hold example.com's records. Asking doesn't help

If a change is planned, lower the TTL more than one TTL in advance. For example, if you normally run at 86400 seconds (1 day), drop it to 300 seconds more than a day before. Then every cache in circulation expires within 300 seconds, and the switch propagates in 5 minutes. Raise it back after the change.

To check, look at the authoritative server. The root doesn't hold the target record.

# Find the authoritative servers
dig NS example.com

# Ask that authoritative server directly (bypassing caches). Replace ns1.example.com with the name the first command returned
dig @ns1.example.com www.example.com A

Common misconceptions​

"DNS and DHCP are both mechanisms for distributing network settings." — Different things. DNS looks up names; DHCP distributes network settings to devices. They mix up because DHCP's payload includes a DNS server address.

"Every zone is managed on the root servers." — The root holds only delegations to TLDs. Actual records live on each organization's authoritative servers. That's why DNS is a distributed system.

"You need an application to a higher level to create a subdomain." — You don't. An administrator with a delegated zone can freely configure everything under it.

"To check whether the switch happened, ask the root server." — The root doesn't hold the target record. Ask the authoritative server. And what's happening isn't "propagation" — it's "waiting for old caches to expire".

"DNS changes always take 24 to 72 hours to reflect." — For records inside your own zone, the time is set by TTL. With a 300-second TTL, it's 5 minutes. But when you change the delegation itself (switching nameservers to another vendor at your registrar), what applies is the NS TTL held on the parent zone's side (.com). Lowering the TTL in your own zone doesn't reach it. For .com that's up to two days, and that wait alone lines up with the order of magnitude in the folklore.

Exercises​

Q1. In three days you'll migrate a server and switch the A record to a new IP. What preparation minimizes downtime?

Answer and explanation

Answer: Lower the TTL right now.

Suppose the current TTL is 86400 seconds (1 day). At the moment of switching, resolvers worldwide will still hold values up to a day old. Even after switching, traffic to the old server continues for that day.

Procedure:

  1. Lower TTL to 300 seconds now — this change itself has to wait one old-TTL period, so do it more than "old TTL" before the switch. Three days ahead easily clears the "more than one day" bar
  2. On the day, change the A record to the new IP — every cache in circulation expires within 300 seconds, propagating in 5 minutes
  3. Raise TTL back once done — short TTLs increase query volume; keep it long during normal operation

Keeping the old server running through the transition means it can absorb traffic while caches expire.

Q2. You want to create blog.example.com. Do you need to apply to the .com administrator or to ICANN?

Answer and explanation

Answer: No.

Managing the zone example.com puts the namespace under it under your discretion. In RFC 1034's words, an organization with its zone under control may unilaterally change data in the zone and extend new branches.

Adding an A record for blog.example.com on your authoritative server completes the setup. If someone looked the name up before you added it, you wait for the cached "no such name" answer to expire. The upper .com server only knows where example.com's authoritative servers are; it stays out of the contents.

Applications are needed only when acquiring example.com itself (through a registrar).

Q3. You changed the A record. Your PC still connects to the old IP; your colleague's PC connects to the new one. What's happening?

Answer and explanation

Answer: Something on your side is still caching the old value.

Caches live at three levels: browser, OS, resolver. If your colleague sees the new value, the authoritative server is correctly updated, so the cause is on your side.

Investigate in this order:

# 1. Ask the authoritative server directly (replace ns1.example.com with the name dig NS example.com returns). If it's new here, the config is right
dig @ns1.example.com www.example.com A

# 2. Ask the resolver you normally use. If old, that's the resolver's cache
dig www.example.com A

# 3. Clear the OS cache (macOS example)
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Browsers also hold their own cache, so checking in an incognito window or a different browser helps.

Skipping this by shrugging with "propagation" leaves you waiting hours for what's actually just your local cache. Check level by level to see which one is stale.

Summary​

  • DNS looks up records tied to a domain name. DHCP, which hands out device network settings, has a different role
  • Resolution walks resolver → root → TLD → authoritative. Each level holds only the referral to one level below
  • Not every zone lives on the root. That is why DNS is a distributed system
  • An administrator delegated a zone can freely configure the subdomains below it. No application needed
  • TTL is the upper limit on how long a cache may hold a record, set by the zone's administrator
  • So-called "propagation" is old caches expiring, not new information spreading
  • To speed reflection of a change, lower TTL in advance. Ask the authoritative server, not the root
Related references
  • HTTP — Once the destination is resolved, what actually gets exchanged