DNS Explained: How a Name Becomes an Address

DNS is the internet's phone book, and like a phone book it is only useful if it is fast, cached and mostly out of date — which is a description of both. When someone says "the DNS is down", they almost always mean their recursive resolver cannot be reached, not that the naming system has failed. The actual naming system is remarkably robust; almost all of its failure modes are local or commercial.

The lookup, step by step

1. 1Your stub resolver asks the operating system

   The OS checks its own cache first, using the file that says which resolver to ask.

2. 2The OS asks your configured recursive resolver

   Usually run by your internet provider. This is the party that does the walking, and the one whose outage takes your connection down with it.

3. 3The resolver checks its cache

   If a fresh record exists, it returns immediately. This is the overwhelming majority of lookups, which is why DNS is fast.

4. 4Otherwise it queries a root server

   The root servers do not know the answer. They know which server is authoritative for the top-level domain, and they reply with a pointer to it.

5. 5The resolver queries the nameserver for the domain

   The authoritative server for example.com knows the A record for www.example.com and returns it, along with a TTL.

6. 6The resolver caches and returns the answer

   It returns the address to you and caches it for the length of the TTL, so the next person asking does not repeat the walk.

Only the recursive resolver does the walking. Your device, your provider's resolver and the authoritative servers each do one job. This split is why the root servers can handle billions of lookups a day: they answer almost every request from cache and only do real work for the fraction of queries that need it.

Record types you will actually meet

A CNAME cannot exist at a zone apex. You cannot put a CNAME on example.com itself, only on subdomains like www.example.com. This is an old technical constraint, not a policy, and it is the reason bare domains use A or AAAA records with an MX alongside.

Caching and TTL

The TTL is a promise, in seconds, about how long a resolver may keep a record. It is a compromise: a long TTL makes the system fast and resilient, and makes a change slow to propagate everywhere. A short TTL makes changes appear quickly and makes the system depend on more queries.

This is the single most useful thing to understand when a change "does not work". If you lowered the TTL yesterday, some resolvers are still holding the old value. If you raised it, some resolvers may cache for far longer than you expect. The practical rule is: set the TTL low before a planned change, wait for at least one full TTL to pass, make the change, and only then raise it back.

The four failure modes

1. Wrong record type. A hostname that has a CNAME but no A record, or an A record where a CNAME was needed, resolves to nothing. The error is explicit: "CNAME and other data cannot exist at the same name".

2. Propagation lag. The record exists and is correct, but resolvers are still serving the old answer. Diagnosed by querying a public resolver directly and comparing the answer time.

3. A dangling CNAME. A subdomain points at a target that no longer exists. Lookups fail with a resolution error rather than a connection error, which is a useful signature: the browser says it cannot find the server, and the cause is a host that has been deleted.

4. A nameserver mismatch. Delegation says the zone is served by ns1.example.com, but ns1.example.com has no NS records pointing back, or is a different provider entirely. Some resolvers follow delegation and some do not, which produces a maddening partial failure where it works for one person and not another.

The tools

Common questions

Frequently asked questions

What is DNS in one sentence?

A distributed, cached, hierarchical lookup service that translates a hostname into the addresses a client needs to reach it, and a few other records that say who handles mail, who is authoritative, and what policies apply.

Do I need DNSSEC?

DNSSEC cryptographically signs DNS records so a resolver can verify they were not altered in transit. It is genuinely valuable and widely supported, but adoption is still partial, and a signed zone with a broken configuration fails closed, which means nothing resolves at all. For most sites the honest answer is that HTTPS already prevents the practical attack DNSSEC addresses.

Is a public resolver like 1.1.1.1 better than my provider's?

It is often faster and it has better logging, which makes it useful for debugging. It is a trade-off: the provider's resolver sits inside their network and cannot fail to route to it, whereas a public resolver is one more hop. For routine use the provider's is fine; for diagnosis the public one is invaluable, because comparing the two answers tells you immediately whether the problem is local.

Why does my email get rejected but my website works?

Mail uses a different set of records. A working website proves only that A or AAAA resolution works. Mail additionally needs MX records pointing at hosts that exist, a reverse lookup that matches, and a TXT record declaring which servers are allowed to send on your behalf. A missing or incorrect SPF, DKIM or DMARC policy is the most common cause, and it is invisible in a browser.

Where to go next

These are the services referenced above. Compare them on your own terms before you sign up for anything.

• GitHub →

Related reading

• How the Internet Actually Works 4 min read
• HTTPS and TLS Explained Without the Handshake Diagrams 4 min read
• What Happens When You Press Enter 4 min read
• Git and Version Control for People Who Have Avoided It 4 min read