DNS: How Name Resolution Works

The Domain Name System (DNS) maps names such as example.com to the IP addresses that machines use to connect. Every web request, API call and email delivery starts with a DNS lookup. DNS is also a tool you use in designs: it spreads load, moves traffic between regions and points a name at a CDN. When a migration goes wrong, DNS caching is often the reason the fix takes hours to reach everyone.

Why DNS is distributed#

No single server holds every name on the internet. Instead, DNS is a distributed, hierarchical database.

• Delegated ownership: each organization manages its own part of the namespace. The owner of example.com edits its records without asking anyone else.
• Replication: every zone has several authoritative servers, so one failure does not take a name offline.
• Caching: resolvers keep answers for a set time (the TTL). Most lookups never reach the authoritative servers.
• Loose coherency: a change spreads to caches over time, not at once. DNS trades instant consistency for scale and availability.

The namespace#

That distributed database is organized as a tree called the namespace, drawn upside down. The root sits at the top and has an empty label, written as a single dot (.). Below the root are the top-level domains, then the domains under them, and so on.

A few rules apply to names:

• Each part between dots is a label. A label is at most 63 bytes and uses letters, digits and hyphens. Labels are case-insensitive.
• Siblings under the same parent must have unique labels.
• A full name is at most 255 bytes on the wire (about 253 characters as text). The tree can be at most 127 levels deep.

A fully qualified domain name (FQDN) names a host all the way to the root, for example mail.example.com.. The trailing dot is the root. Browsers and most tools add it for you, so you rarely type it.

Zones and name servers#

The tree shows how names are arranged, and zones show who controls each part: a zone is the part of the tree that one administrator controls. The com zone is run by its registry. The example.com zone is run by the domain owner. The owner can also delegate a subdomain, such as eu.example.com, as a separate zone with its own name servers.

Each zone's records live on name servers. These come in two kinds that do different jobs, and most real servers do only one of them.

Primary and secondary servers#

This is where the replication from earlier comes in. A zone usually has one primary server, where you edit records, and several secondary servers that hold copies. Here's how the copies stay in sync:

1. Each zone has a serial number in its SOA record. You increase it on every change.
2. The primary can send a NOTIFY message to tell secondaries that the zone changed.
3. Secondaries also check the primary's serial on a timer (the SOA refresh interval).
4. When the serial is higher, the secondary copies the zone with a zone transfer (full or incremental).

Clients can query any of these servers. All of them give authoritative answers.

Record types#

The data inside a zone is a set of records. Each record has a name, a type, a TTL and a value. These are the types you meet most often.

Here's how those types look together in a small zone, written in the standard zone-file format:

$TTL 3600
example.com.      IN  NS     ns1.examplehost.net.
example.com.      IN  NS     ns2.examplehost.net.
example.com.      IN  A      203.0.113.10
www.example.com.  IN  CNAME  example.com.
example.com.      IN  MX     10 mail1.example.com.
example.com.      IN  MX     20 mail2.example.com.
example.com.      IN  TXT    "v=spf1 include:_spf.example.com -all"
example.com.      IN  CAA    0 issue "letsencrypt.org"

Notes on each type#

Most types have a rule or two that trips people up.

• CNAME: the lookup follows the alias and then asks for the target's A or AAAA record. A name with a CNAME cannot have any other records. So you cannot put a CNAME at the zone apex (example.com), because the apex needs NS and SOA records. Many DNS hosts offer a provider-specific "alias" record for this case.
• MX: mail servers try the lowest priority number first. In the zone above, senders try mail1 (10) and fall back to mail2 (20). An MX value must be a host name, not an IP address.
• NS: list at least two servers, ideally on different networks. If no NS server answers, the name does not resolve.
• TXT: a name can have many TXT records. Common uses are SPF and DKIM for email (records that help receiving mail servers check a sender is genuine), and ownership checks (a service gives you a token to publish, such as "site-verification=abc123").
• SPF type: a separate SPF record type once existed. It is deprecated. Publish SPF policy as a TXT record.
• CAA: with no CAA record, any certificate authority may issue for the name. CAs look for the closest CAA record up the tree, so a CAA on example.com also covers its subdomains unless a subdomain has its own.

The SOA record#

Every zone has exactly one SOA (start of authority) record. It names the primary server and the admin contact, and it sets the timers that secondaries follow.

example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. (
    2026101801 ; serial
    7200       ; refresh: secondaries check every 2 hours
    3600       ; retry: wait 1 hour after a failed check
    1209600    ; expire: stop answering after 14 days without contact
    3600 )     ; negative TTL: cache "no such name" for 1 hour

• The contact hostmaster.example.com. means the email address hostmaster@example.com. The first dot stands for @.
• A date-based serial (YYYYMMDDnn) is a common habit, because it always increases.
• The last field controls negative caching: how long resolvers remember that a name does not exist.

Query classes#

Besides a record type, each query also carries a class. IN (internet) is the one you'll use. CH (Chaos) survives for server diagnostics, such as asking BIND for its version. HS (Hesiod) is historic.

The special query type ANY asks for every record at a name. Many servers now return a minimal answer to ANY, because attackers abused it for amplification attacks (small spoofed queries that trigger large replies aimed at a victim).

TTL: the caching trade-off#

Every record above carries a TTL, and it's the main dial you control. The TTL (time to live) tells resolvers how many seconds they may cache a record.

Some clients and resolvers cache longer than the TTL says. Keep the old servers running for a while after a cutover, so these clients still reach something.

How a lookup works#

With servers, records and TTLs in place, you can follow a full lookup. A lookup for www.example.com with empty caches goes through these steps.

1. Your browser and operating system check their own caches. On a miss, the OS's stub resolver sends the query to the configured recursive resolver.
2. The recursive resolver checks its cache. On a miss, it asks a root server.
3. The root server does not know the answer. It replies with a referral: the NS records for the com TLD servers.
4. The resolver asks a com TLD server.
5. The TLD server replies with another referral: the NS records for example.com.
6. The resolver asks one of the example.com authoritative servers.
7. The authoritative server returns the A record (or a CNAME, which the resolver then follows).
8. The resolver caches every answer for its TTL and returns the address to your OS.

The stub sends a recursive query: "give me the final answer". The resolver then makes iterative queries: each server answers with what it knows or with a referral. The next lookup for any .com name skips steps 2 to 3, because the resolver has cached the TLD servers.

DNS queries normally use UDP on port 53. They switch to TCP for large answers and for zone transfers.

Root servers#

Every cold lookup starts at the root, which runs on 13 root server identities named a.root-servers.net to m.root-servers.net. Many independent organizations operate them, and each runs many copies around the world with anycast: every copy announces the same address, and routing delivers your query to a nearby one. So "13 root servers" means 13 names, not 13 machines. Network Layer Protocols explains how anycast works.

Who runs the namespace#

So far this note has covered how names resolve. A separate set of roles decides who gets a name in the first place, and three of them share the work of registering a domain.

Above them, ICANN coordinates the namespace and the address space through the IANA functions. IANA manages the root zone, which lists every TLD and its name servers. It also hands large IP address blocks to the five regional internet registries (ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC), which allocate them further to ISPs and companies.

DNS in system design#

Back to designs. DNS is the first hop of every request, so it shows up in many design decisions.

• Load spreading: return several A records for one name. Clients pick different addresses. This is a form of client-side balancing; see Load Balancing.
• Geo and latency routing: managed DNS can return a different answer based on where the resolver is. This sends users to the nearest region; see Regionalization and Latency.
• Failover: health-checked records switch to a standby when the primary fails. A short TTL makes the switch faster.
• CDNs: point www or static at the CDN's hostname with a CNAME.

Pitfalls#

• Forgotten TTLs. You change a record, but users keep reaching the old address until their cached copy expires.
• CNAME at the apex. Standard DNS does not allow it. Use your provider's alias record or an A record.
• One provider, one point of failure. If your only DNS provider goes down, your names stop resolving even when your servers are healthy.
• Dangling records. A CNAME that still points at a deleted cloud resource lets someone else claim that resource and serve content on your name. Remove records when you remove the resource.

Key takeaways#

• DNS is a distributed, cached, hierarchical database. The root is ., then TLDs, then domains.
• Authoritative servers hold the truth for their zones. Recursive resolvers find and cache answers.
• A cold lookup goes resolver, root, TLD, authoritative. Caching skips most of these steps.
• Know the core records: A, AAAA, CNAME, MX, NS, TXT, CAA and SOA.
• TTL trades fast lookups against fast changes. Lower it before a planned migration.
• There are 13 root server identities, each served by many anycast instances.