Every machine on the internet is reached by number. A server answering for
your-website.com might live at 203.0.113.10; your laptop has an
address too. Routing, firewalls, TLS certificates, logs - the plumbing all works in numbers.
People do not. We remember names. The Domain Name System is the service that turns
one into the other, for the whole internet, with no central list anyone has to hold.
This is the first note in a series that builds DNS up from the ground. Start here even if you
have used dig for years; the framing pays off later.
What there was before: one big file
In the early ARPANET, name-to-address mapping was a single text file,
HOSTS.TXT, kept by the Network Information Center at SRI in California. Every
machine downloaded the whole thing periodically and searched it locally. It looked roughly
like the /etc/hosts file still on your computer today:
203.0.113.10 your-website.com www.your-website.com
198.51.100.7 mail.your-website.comThat worked for a few hundred hosts. By the early 1980s it was breaking in every direction:
- Contention. One organisation approved every name. Two sites wanting the same name had to negotiate through a third party.
- Consistency. Your copy was only as fresh as your last download. A new host was invisible to everyone who had not refreshed.
- Load. Every machine on the network pulling one growing file from one server does not scale, and that server was a single point of failure for the entire namespace.
DNS, specified in 1983 and revised into its lasting form in 1987 (RFC 1034 and RFC 1035), replaced the file with a system.
The three ideas that make it work
1. A hierarchical namespace. Names form a tree. At the top is the
root, written as a single dot. Below it are top-level domains -
com, org, uk, dev. Below those are the
names people register, and below those, whatever subdomains the owner wants. Read a name
right to left and you are walking down the tree:
. ← root
|
com ← top-level domain
|
your-website ← the name you register
|
www ← a host within it2. Delegation. Each branch of the tree is handed to whoever runs it. The
root operators delegate com to its registry; that registry delegates
your-website.com to the nameservers you choose; you control everything at or
below your-website.com. Nobody needs a global list, because each operator is
only responsible for pointing at the level directly beneath them. A unit of this delegated
control is called a zone.
3. Caching. Every answer DNS gives carries a number, the TTL
(time to live), that says how many seconds it may be reused. A resolver that looks up
www.your-website.com and gets a TTL of 300 will answer from memory
for the next five minutes instead of asking again. This is what makes DNS fast and keeps
load off the authoritative servers.
What a lookup looks like, briefly
Your device does not walk the tree itself. It asks a recursive resolver - the one
handed to you by your network, or a public one like 1.1.1.1 or
8.8.8.8 - and that resolver does the walking: root, then the TLD, then your
authoritative nameserver, caching each step. The full sequence gets its own note,
Learn DNS 03.
Why "propagation" exists at all
Caching is the feature that makes DNS work, and it is also the reason a change is never instant. When you edit a record, the authoritative server has the new value straight away. But every resolver that already looked the old value up is still holding it, and will keep serving it until its TTL runs out. There is no signal that pushes the update; there is only expiry, cache by cache, on millions of independent machines.
So "DNS propagation" is not data spreading outward. It is old answers timing out at different moments in different places. That is the whole reason a tool like the monitor on this site exists: it asks many resolvers, from many regions, over and over, and shows you the old value giving way to the new one until every vantage point agrees. Watching that from the command line is a companion piece.
DNS is more than web addresses
The tree stores far more than "name to IP". Each name can hold several types of record, and different parts of the internet ask for different ones:
A/AAAA- IPv4 and IPv6 addresses, the classic case.MX- where to deliver mail for the domain.TXT- free-form text, used for email authentication (SPF, DKIM, DMARC) and for proving domain ownership to services.NS- which servers are authoritative for a zone; the mechanism delegation is built on.CNAME- "this name is really an alias for that one".CAA- which certificate authorities are allowed to issue certificates for the domain.SRV- where to find a particular service (chat, VoIP, and others).
Under the hood it is one distributed database keyed on (name, type), and web browsing is just its most visible query.
A first look with dig
dig (part of the bind / bind-utils package, and
built into macOS) is the standard way to ask DNS a question directly. Try these against any
domain:
# the address, with the full answer section
dig your-website.com
# just the answer
dig +short your-website.com
# a different record type
dig +short your-website.com MX
dig +short your-website.com NS
In the full output, the ANSWER SECTION shows the record and a number in front
of it - that is the TTL, counting down. Run the same command twice a few seconds apart
against a cached name and you will see it drop.
The shape of it
- DNS maps names to numbers (and to mail routes, text records, and more) for the entire internet.
- It replaced a single shared file with a tree that is delegated branch by branch, so no one holds a global list.
- Answers are cached for their TTL. That is why DNS is fast - and why a change takes time to be seen everywhere.
- "Propagation" is old cached answers expiring, not new data being pushed.
Next: Learn DNS 02 - Anatomy of a domain name, which takes a single name apart label by label and explains why each piece behaves the way it does.