How DNS works

The Domain Name System (DNS) is the distributed database that maps names such as www.example.com to the data needed to reach them, most often an IP address. Computers connect to IP addresses; people and configuration files use names. Every time a browser opens a site, a phone checks for mail or a service calls another service by name, a DNS lookup happens first.

No single server holds all the names. The data is split into zones, each run by whoever owns that part of the name, and the servers for each zone only know their own records plus where to find the zones below them. A lookup with nothing cached starts at the top of the tree and is referred downwards, one level at a time, until it reaches the server that holds the answer.

That would be slow if it happened on every request, so DNS relies on caching. Every answer carries a time to live (TTL) saying how long it may be reused, and most lookups are answered from a cache without touching the servers further down the chain.

DNS was designed by Paul Mockapetris in 1983 to replace a single HOSTS.TXT file that every computer on the ARPANET downloaded from one central host. The current core standards, RFC 1034 and RFC 1035, date from 1987, and most of what follows still works the way they describe.

DNS names form a tree, read from right to left. Each part between the dots is a label. In www.example.com, the top of the tree is the root, written as an empty label after a final dot that is usually left out (www.example.com.). Below the root are the top-level domains (TLDs) such as com, org and in; there are more than 1,400 of them. Below com is example, and below that www.

A zone is a part of the tree managed as one unit. The root zone lists every TLD and the servers for each. The com zone, run by Verisign, lists every .com domain and its nameservers, but none of the records inside those domains. The example.com zone, run by whoever owns the domain or their DNS provider, holds the actual records such as the address of www.example.com. Handing a part of the tree to another set of servers is called delegation, and it is done with NS records in the parent zone.

When you buy a domain, the company you buy it from is a registrar. It passes your chosen nameservers to the registry that runs the TLD, and the registry publishes them in the TLD's zone. That is the only part of your DNS that lives outside your own provider: if the nameservers listed at the registry are wrong, nothing you change at your provider will be seen.

Four kinds of software take part in a typical lookup. Only the last three are what people usually mean by "DNS servers", and only the last one holds the record being asked for.

The browser needs an address for www.example.com. Before anything goes over the network, three local places are checked.

1. The browser's own cache of recent lookups. Chrome and Firefox keep one, separate from the operating system's.
2. The hosts file (/etc/hosts on Linux and macOS), a leftover of the pre-DNS days that still overrides DNS for any name listed in it.
3. The operating system's resolver cache, if it has one: systemd-resolved on many Linux systems, mDNSResponder on macOS, the DNS Client service on Windows.

All three miss, so the stub resolver sends a query to the recursive resolver it has been configured with, usually handed out by the router over DHCP or set by hand (on Linux it is the nameserver line in /etc/resolv.conf). The query is a single UDP packet to port 53. It carries a random 16-bit ID, comes from a random source port, and has the RD (recursion desired) flag set, which asks the resolver to do the whole lookup and return only the final answer.

Browsers usually ask for two record types at once: an A record for the IPv4 address and an AAAA record for the IPv6 address, so they can try both. Some also ask for an HTTPS record, which can tell them the site supports HTTP/3 before they connect. The rest of this guide follows the A query.

The resolver checks its own cache. It has nothing for www.example.com, nothing for example.com and nothing for com, so it has to start at the top. It knows the root servers' addresses from a root hints file shipped with the software, and when it starts it asks one of them for the current list (this is called priming).

It picks a root server, say a.root-servers.net at 198.41.0.4, and asks for the A record of www.example.com, this time without the RD flag. The root server does not know the answer and does not go looking for it. It replies with a referral: the names of the servers for com, plus their addresses.

The resolver now asks one of the .com servers, say a.gtld-servers.net at 192.5.6.30. That server holds the delegation for every .com domain but none of the records inside them, so it too answers with a referral, this time to the nameservers for example.com.

The resolver asks ns1.example.com at 192.0.2.53. This server holds the example.com zone, so it has the record and answers with it. The aa flag is set this time.

The first lookup took four round trips from the resolver, one to each server and one back to the client. Very few lookups look like that, because the resolver's cache is shared by everyone who uses it.

• Someone else asks for www.example.com within the hour. The resolver answers from its cache straight away, without contacting any other server. The TTL in the answer counts down: a client asking 20 minutes later is told 2400, not 3600, so no cache downstream keeps the record longer than the owner allowed.
• Someone asks for mail.example.com. The resolver still has the NS records for example.com, so it goes straight to ns1.example.com. One round trip.
• Someone asks for a different .com domain. The resolver has the .com servers cached for two days, so it skips the root and starts at step 3.

Root servers are rarely asked about popular TLDs for this reason; a resolver needs to ask them about com only about once every two days. A large share of the queries root servers do receive are for TLDs that do not exist, often from software that tries a misconfigured name or a local name such as printer.local against public DNS.

Every record has a name, a type, a class (almost always IN, for internet), a TTL and the data itself. A lookup asks for one name and one type. These are the types most engineers deal with.

Every record's TTL is chosen by the zone's owner. It is the longest time any cache may keep the record. Common values run from 60 seconds, for records that may need to change quickly, to 86,400 seconds (a day) for records that rarely change. The .com delegations above have a TTL of two days.

There is no "propagation" in DNS. When a record changes, nothing is sent to resolvers. Each resolver that cached the old record keeps serving it until the TTL runs out, then asks again and gets the new one. A change to a record with a one-day TTL can therefore take up to a day to reach everyone, and different users see the change at different times. The usual approach before a planned move is to lower the TTL to a few minutes at least one old TTL in advance, make the change, and raise the TTL again afterwards.

Negative answers are cached as well (RFC 2308). An NXDOMAIN is kept for the smaller of the SOA record's TTL and its last field, the negative-caching TTL. If something looks a name up before you create it, resolvers will keep saying it does not exist for that long.

A TTL is only the maximum. Some resolvers set a minimum and keep records longer than very short TTLs ask for, and applications often cache on their own. A Java process, for example, caches successful lookups according to networkaddress.cache.ttl, regardless of the record's TTL, and connection pools that never reconnect never look the name up again at all. This is the main reason DNS makes a slow failover mechanism: moving traffic by changing a record takes at least the TTL, and some clients take much longer.

A DNS message has a fixed 12-byte header followed by four sections: the question, the answer, the authority section (used for referrals) and the additional section (glue and other extras). The header holds the 16-bit ID that matches a response to its query, the flags seen above (QR, AA, TC, RD, RA and others), a response code such as NOERROR, NXDOMAIN or SERVFAIL, and the number of records in each section.

Most queries and answers fit in one UDP packet each, which is why DNS uses UDP: no connection setup, one round trip. RFC 1035 limited UDP messages to 512 bytes. EDNS(0) (RFC 6891) lets a client advertise that it can accept larger UDP responses, which DNSSEC signatures need. Very large UDP packets get fragmented, and fragments are often dropped or can be spoofed, so since DNS Flag Day 2020 the recommended size to advertise is 1,232 bytes.

If an answer does not fit, the server sends what it can with the TC (truncated) flag set, and the client repeats the query over TCP. TCP support is required of every DNS server (RFC 7766), and a firewall that allows only UDP on port 53 will break lookups for names with large answers. TCP is also used for zone transfers (AXFR and IXFR), which copy a zone from a primary server to its secondaries.

There are 13 root server identities, a to m, run by 12 organisations (Verisign runs two). The number comes from the original 512-byte limit: thirteen names and their addresses were what fitted in one UDP response. Each identity is not one machine. It is served from many sites around the world, together well over a thousand, using anycast: every site announces the same IP address in BGP, and the internet's routing sends each packet to the nearest site in routing terms.

Anycast suits DNS well. A query and its answer are a single exchange, so it does not matter if the next query goes to a different site. If a site fails, its route is withdrawn and traffic flows to the next nearest one, and a flood of traffic aimed at one address is spread across every site announcing it. Public resolvers such as 1.1.1.1, 8.8.8.8 and 9.9.9.9 use anycast for the same reasons, and so do most large authoritative DNS providers.

The root zone itself is small, a list of TLDs and their servers, and is published by IANA. Some resolvers keep a full local copy of it (RFC 8806) so they never need to query a root server for a referral at all.

Original DNS has no protection. Queries and answers are plain text, and a resolver accepts the first response that matches its question, ID and port. In 2008 Dan Kaminsky showed that an attacker could race the real server with forged referrals and poison a resolver's cache for a whole domain. The immediate fix was to randomise the source port of every query, so a forger has to guess about 32 bits instead of 16, but that only makes the attack harder. Two separate additions deal with the underlying problems.

DNSSEC: proving the answer is genuine

DNSSEC adds signatures to DNS data. Each signed zone publishes its public keys in DNSKEY records and a signature for each set of records in RRSIG records. The parent zone publishes a DS record, a hash of the child's key, and signs that too. A validating resolver starts from the root's key, which it has built in, and follows the chain: the root signs the DS for com, com signs the DS for example.com, and example.com's key signs the A record. The root zone has been signed since July 2010.

DNSSEC proves that an answer came from the zone owner and was not changed. It does not hide anything: the query and the answer are still readable by anyone on the path. When validation fails, for example because a key was rolled badly or a DS record at the registrar no longer matches, a validating resolver returns SERVFAIL and the domain disappears for its users, which is the most common DNSSEC outage.

Encrypting the query

Encrypted DNS protects the link between a client and its resolver from being read or changed. Three forms are in use:

• DNS over TLS (DoT, RFC 7858) sends DNS messages over a TLS connection on port 853. Android's "Private DNS" setting uses it.
• DNS over HTTPS (DoH, RFC 8484) sends each query as an HTTPS request on port 443. It looks like other web traffic and is hard to block, and browsers can use it directly, bypassing the operating system's resolver, which some network operators object to.
• DNS over QUIC (DoQ, RFC 9250) uses QUIC on UDP port 853, avoiding TCP's head-of-line blocking.

These cover only the hop to the resolver. The resolver itself still sees every name, and its queries to authoritative servers are mostly unencrypted. DNSSEC and encrypted transport solve different problems and are used together.

dig, from the BIND tools, is the standard way to see what DNS is returning. A few forms cover most problems.

• Changing a record without lowering its TTL first. Users keep reaching the old address for up to a full TTL, and a rollback takes just as long.
• Testing a name before creating it. The NXDOMAIN gets cached for the negative-caching TTL, and the new record seems not to work.
• Putting a CNAME at the bare domain, or next to other records. It is not allowed, and servers either reject it or behave unpredictably. Use the provider's ALIAS or flattening feature.
• Relying on DNS for fast failover. Even with a 30-second TTL, some resolvers and long-running clients hold on to the old address for minutes or longer. Put failover behind a stable address, such as a load balancer or anycast IP, where it can happen in seconds.
• Ignoring search domains. Kubernetes pods get options ndots:5 in resolv.conf, so a name with fewer than five dots, such as api.example.com, is first tried with each cluster search domain appended, producing several failed queries before the real one. Writing the name with a final dot, api.example.com., skips the search list.
• Letting a DNSSEC key or DS record get out of step. The domain becomes unreachable for every user of a validating resolver, which today includes the large public resolvers. Automate key rollover and check the DS record whenever the DNS provider changes.