DNS: how names become addresses

Computers find each other by number, like 203.0.113.10. People remember names, like club.example.org. DNS (the Domain Name System) is how one becomes the other, billions of times a second, all over the world. When it goes wrong, nothing works, and it's often the last thing people check. There's a saying among admins: "It's always DNS."

The journey of a question

When you open club.example.org, nobody has a list of every name on the internet. Instead, the question is passed along until it reaches someone who knows:

1. Your app asks the computer's resolver, a small part of the operating system. It checks the /etc/hosts file and its own cache first.
2. The resolver asks a recursive resolver, usually your home router, your company's DNS server, or a public one like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google). Its job is to find the answer for you.
3. The recursive resolver asks a root server: "where's club.example.org?" The root doesn't know, but it knows who runs .org.
4. It asks the .org servers. They don't know either, but they know which servers are in charge of example.org.
5. It asks those authoritative servers, and they give the real answer: 203.0.113.10.
6. Everyone on the way back remembers the answer for a while (its TTL, "time to live"), so the next person gets it instantly.

Step 6 is why DNS is fast, and also why DNS changes are slow. Hold that thought.

Record types

A DNS name can hold different kinds of records. These are the ones you'll use:

Reading dig

dig is the DNS tool admins reach for. It's on almost every Linux server (package bind-utils on Rocky, bind9-dnsutils on Ubuntu, and preinstalled on macOS). The useful parts of its answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41231      # NOERROR, NXDOMAIN (no such name) or SERVFAIL
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
club.example.org.   2391   IN   A   198.51.100.20        # name, TTL left (seconds), type, value

;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)              # who answered

One thing to know: dig only ever asks DNS. It skips /etc/hosts. To see what your apps will actually get, use getent hosts NAME.

TTLs and "DNS propagation"

People say a DNS change "takes time to propagate", as if it were slowly spreading. Really, the change is instant at the authoritative servers. What takes time is caches expiring. Every resolver that already asked keeps its old answer until the TTL runs out. With a TTL of 3600, that can be up to an hour.

Where your server gets its DNS

This part is Linux-specific, and the two families do it differently:

Flushing your own cache only helps with your cache. If the router or your company's DNS server still remembers the old answer, you'll keep getting it until their TTL runs out. (On a Windows laptop, the same flush is ipconfig /flushdns; on a Mac, sudo dscacheutil -flushcache.)

/etc/hosts jumps the queue

Before asking DNS at all, Linux checks /etc/hosts (that order is set by the hosts: line in /etc/nsswitch.conf, normally files dns). A line there wins over anything DNS says. That's handy for testing a new server before the real DNS change, and a classic trap when someone forgets to remove it afterwards.

Try it: the club moved its website 🌐

Twenty minutes ago the coding club moved its website to a new server: club.example.org changed from 198.51.100.20 to 203.0.113.10. Some people see the new site, some the old. You're on the club's other server, and you're going to find out why.

Quick check