How DNS Works

Every request on the internet starts with a question: what address does this name point to? DNS is the system that answers it, and because it runs first, it is the system that can make a perfectly healthy website unreachable.

What follows is how it works, in enough depth to debug it.

Names and addresses

Computers talk to each other by IP address, something like 203.0.113.7 or 2001:db8::7. People remember names. DNS, the Domain Name System, is the distributed database that maps one to the other.

It is distributed in a specific way. Nobody holds the whole thing. Responsibility is delegated down a tree, from the root, to the top-level domains like .com and .dev, to the domains registered under them, to whatever subdomains their owners create. Each level knows only who is responsible for the level beneath it.

What happens when you type a name

Say you open app.example.com. Your browser asks the operating system, which asks a resolver. The resolver is usually run by your ISP, your company, or a public service like Cloudflare (1.1.1.1), Google (8.8.8.8) or Quad9 (9.9.9.9). Its job is to find the answer on your behalf.

If the resolver has answered this question recently, it replies from cache and the whole thing takes under a millisecond. If it has not, it walks the tree:

1. It asks a root server who is responsible for .com. There are thirteen root server addresses, operated by a dozen organisations and mirrored hundreds of times around the world.
2. The root server points it at the .com TLD servers.
3. It asks a .com server who is responsible for example.com, and gets back the names of the domain's authoritative nameservers. These are the ones you configure at your registrar.
4. It asks one of those authoritative servers for app.example.com, and finally gets an address.

The resolver caches every step, so the next question about anything under example.com skips straight to step four, and the next question about app.example.com specifically skips everything.

Four round trips sounds slow. In practice the root and TLD answers are almost always cached already, so a cold lookup is usually one or two trips and a few tens of milliseconds.

Records

An authoritative nameserver holds a zone, and the zone is a list of records. Each record has a name, a type, a value and a TTL. The types you will actually meet:

Two of these have rules that catch people out. A CNAME says "this name is an alias for that name, go look there," and a name with a CNAME cannot have any other records. That is why you cannot put a CNAME at the apex of a domain, which also needs SOA and NS records, and why providers invented ALIAS and ANAME records to fake it. And an MX record must point at a name, never directly at an address, and that name needs an A or AAAA record of its own.

TXT records are where verification tokens live. When Barkme asks you to add barkme-verify= followed by a token, it is asking you to prove you control the zone, because only someone with access to the authoritative nameservers can add a record to it. That single record on the apex is why verifying example.com covers every subdomain beneath it. The subdomains are in the same zone, under the same control.

TTL, and the myth of propagation

Every record carries a time to live, in seconds. It tells resolvers how long they may keep the answer in cache before asking again.

This is the entire explanation for "DNS propagation." There is no propagation. When you change a record, the authoritative servers have the new value immediately. Every resolver in the world that cached the old value keeps serving it until its copy of the TTL runs out. A TTL of 86400 means some visitors see the old address for up to a day. A TTL of 300 means five minutes.

The practical rule follows directly. Before a migration, lower the TTL on the records you are about to change, wait for the old TTL to expire so every cache has picked up the short one, then make the change. Afterwards, put the TTL back up so resolvers stop hammering your nameservers for something that never changes.

Different resolvers also have different caches, which is why a change looks live to you and stale to a colleague. You are asking different servers, each with its own memory.

Why different resolvers give different answers

The tree has one right answer for any name, but the resolver in the middle does not have to give it to you.

Filtering resolvers, like Cloudflare's 1.1.1.2, Quad9, AdGuard, and most corporate networks, check a name against threat lists before answering. If your domain is on one, they answer with nothing, or with 0.0.0.0, and your site is unreachable for everyone using them while it remains up for everyone else. That failure gets its own post, because it is one of the few outages a normal uptime monitor cannot see.

Some resolvers also answer differently by geography, and some large sites return different addresses depending on where the question came from, to route you to a nearby data centre. Neither is a fault. Both mean that "what does this name resolve to" has no single answer, and debugging DNS means asking the question from the place where it is failing.

DNSSEC, DoH and DoT, briefly

Plain DNS is unencrypted and unauthenticated. Anyone between you and the resolver can read your queries, and a resolver can be fed forged answers.

DNSSEC signs records so a resolver can verify they came from the zone's real owner. It protects against forged answers and nothing else. Queries are still readable in transit. A misconfigured DNSSEC key also takes a domain offline more thoroughly than almost anything else, because validating resolvers will refuse to answer at all.

DNS over HTTPS and DNS over TLS encrypt the conversation between you and your resolver, so the network in between cannot read or tamper with it. Most modern browsers and phones use one of these by default now, often without telling you, which is one more reason your laptop and your customer's laptop may be asking different resolvers.

The mistakes that take sites down

DNS is rarely the thing that fails, and when it is, it is almost always one of these.

A long TTL before a migration. The site moves, half the internet keeps going to the old server for a day, and the old server has already been switched off.

Dangling records. A CNAME pointing at a cloud service you cancelled last year. Someone else signs up for that service, claims the hostname, and now serves whatever they like from old-campaign.example.com. This is called subdomain takeover, and it also gets domains put on blacklists.

Nameserver changes at the registrar. Moving DNS hosting means changing the NS records at the registrar, and the new host must have the complete zone loaded before you switch, or every record vanishes at once.

Missing the verification record. You added the TXT record to the wrong zone, or at www when it needed to be at the apex, or with the token's quotes included in the value.

Expiry. The registration lapses, the registrar pulls the nameservers, and the domain stops resolving everywhere at once. That one has its own post too.

Barkme treats a DNS failure as down, the same as a 500, because from the visitor's point of view it is exactly that. A check that cannot resolve the name never reaches the server, and an outage the server cannot see is still an outage.

The next layer up, the one that decides whether the browser trusts the server it just reached, is how SSL and TLS work.