How DNS works

Computers reach each other by IP address, but people remember names. The Domain Name System (DNS) connects the two: give it a name such as www.example.com, and it answers with the addresses where that name can be reached. Almost every web page, email and app connection starts with a DNS lookup, usually unnoticed and finished within a few milliseconds.

DNS is one of the internet’s oldest and most successful designs. It is a database spread over servers all around the world that no single organization runs, yet it answers questions from nearly every connected device, all day long. This article explains how that works: how names are organized, who stores them, how a lookup travels, what DNS messages look like, and how DNS is protected.

Before DNS

In the early ARPANET, the predecessor of the internet, the names and addresses of all hosts were kept in a single file, HOSTS.TXT, maintained by the Network Information Center (NIC) and copied by every host. As the network grew, the scheme stopped scaling: the traffic needed to distribute each new version grew with the square of the number of hosts, and organizations that ran their own networks had to wait for the NIC to update the file before their changes became visible (RFC 1034).

Paul Mockapetris designed the Domain Name System to replace it. His first specifications appeared in 1983; the versions still in force today, RFC 1034 and RFC 1035, were published in 1987. Most of what they describe works unchanged. The design rests on three ideas:

1. A hierarchy of names, so that names can be unique worldwide without a central list.
2. Delegation, so that each part of the hierarchy is managed by whoever owns it.
3. Caching, so that answers are reused and the system scales.

The name space

DNS names form a tree. Each node has a short label, and a node’s full name is the list of labels from that node up to the root, separated by dots. The name www.example.com reads from the most specific label on the left to the most general on the right: the node www, inside example, inside com, inside the root.

The root has an empty label. When a name is written with a final dot, as in www.example.com., the dot stands for the root, and the name is fully qualified: it cannot be read relative to anything else. Most software adds the final dot silently.

A few rules apply to every name:

• A label is at most 63 bytes long, and a complete name at most 255 bytes.
• Names are compared without regard to case: WWW.Example.COM and www.example.com are the same name.
• DNS itself can store any byte in a label, but host names keep to letters, digits and hyphens. Names in other scripts, such as bücher.example, are converted to an ASCII form that begins with xn-- before they are looked up.

The labels directly below the root are the top-level domains (TLDs). There are generic ones such as com, org and net; country-code ones such as uk, de and jp, with two letters; and a few special ones such as arpa, which is used for the internet’s own infrastructure. The names example.com, example.net and example.org, and the top-level domains example, test, invalid and localhost, are reserved for examples and testing (RFC 2606).

Zones and delegation

No server holds the whole tree. It is cut into zones, and each zone is managed by one organization and published by its authoritative name servers. The organization that runs a zone can delegate any part below it to someone else, who then runs a zone of their own.

Delegation is recorded in the parent zone with NS (name server) records. The com zone, for example, contains NS records saying which servers are authoritative for example.com. If those servers have names inside the zone they serve, such as ns1.example.com, the parent also stores their addresses, called glue records. Without glue, a resolver could not find the server for example.com without first asking the server for example.com.

At the top is the root zone. It contains little more than the delegations for all top-level domains, and it is served by 13 named root server identities, a.root-servers.net to m.root-servers.net, operated by 12 independent organizations (Verisign runs two of them). Each identity is not a single machine: with anycast, the same address is announced from many places at once, so that queries reach a nearby copy (RFC 7094).

Looking up a name

Two kinds of DNS servers work together in every lookup:

• Recursive resolvers do the searching on behalf of their users. They are run by internet providers, companies and public services, and often by the home router. A resolver accepts a question and returns a complete answer, finding it however it has to.
• Authoritative name servers know the contents of their zones and answer only for them. When asked about a name in a zone below theirs, they reply with a referral: the NS records of the zone that knows more.

The program on your device that asks the questions is called a stub resolver. It is part of the operating system, it does no searching of its own, and it sends every question to a configured recursive resolver.

Here is what happens when a browser needs the address of www.example.com and nothing is cached yet:

1. The browser asks the operating system, whose stub resolver first checks its own cache and the local hosts file. Finding nothing, it sends a query to the recursive resolver, with the recursion desired flag set: “please find the full answer”.
2. The resolver checks its cache. It has nothing for this name, so it starts at the top. Every resolver ships with the addresses of the root servers, and it sends its question to one of them.
3. The root server is not authoritative for the name, but it knows who is responsible for com. It answers with a referral: the NS records of the com zone and the addresses of those servers.
4. The resolver asks a com server.
5. The com server refers it further, to the authoritative servers of example.com.
6. The resolver asks one of the example.com servers.
7. This server is authoritative for the name. It answers with the address record and marks the reply as an authoritative answer.
8. The resolver stores everything it has learned in its cache and returns the address to the stub resolver, which hands it to the browser. Now the browser can open a connection.

The resolver does the heavy work, and the work pays off quickly. After this one lookup, it knows the servers for com and for example.com, so a question about mail.example.com goes straight to the example.com servers, and a question about any other .com name skips the root.

Modern resolvers also practise query name minimisation (RFC 9156): instead of sending the full name www.example.com to the root and to the com servers, they ask each server only for the part it needs to know, such as com or example.com. The answers are the same, but less of the user’s browsing reaches servers that do not need it.

Caching and TTL

Every DNS record carries a time to live (TTL): the number of seconds it may be kept in a cache. A record with a TTL of 3600 may be reused for an hour before a resolver must ask again. Caching is what lets DNS answer billions of questions without overwhelming the authoritative servers, and it is why repeated lookups are almost instant.

It also explains what is often called DNS propagation. When a record changes, nothing is pushed anywhere. Resolvers that cached the old record keep using it until its TTL runs out, so a change can take up to the old TTL to be seen everywhere. Administrators who plan a change therefore lower the TTL well in advance, wait for the old TTL to pass, make the change, and raise the TTL again afterwards.

Failures are cached too. If a name does not exist, the authoritative server answers NXDOMAIN (non-existent domain) and includes the zone’s SOA record. Resolvers keep that negative answer for the smaller of the SOA record’s own TTL and the SOA’s minimum field (RFC 2308), so repeated questions for a missing name do not reach the server every time.

Resource records

The data in DNS is stored as resource records. Each record has an owner name, a type, a class (almost always IN, for internet), a TTL and the data itself. All records with the same name, type and class form a record set and are always returned together.

A zone is traditionally written as a zone file, a text format defined in RFC 1035. A small, illustrative zone, using the reserved documentation addresses:

$ORIGIN example.com.
$TTL 3600
@     IN  SOA    ns1.example.com. hostmaster.example.com. (
                 2026100401  ; serial: incremented on every change
                 7200        ; refresh: how often secondary servers check for changes
                 3600        ; retry: how soon they try again after a failure
                 1209600     ; expire: when they stop answering without contact
                 3600 )      ; minimum: how long to cache negative answers
@     IN  NS     ns1.example.com.
@     IN  NS     ns2.example.net.
ns1   IN  A      192.0.2.53
@     IN  A      192.0.2.10
@     IN  AAAA   2001:db8::10
www   IN  CNAME  example.com.
@     IN  MX     10 mail.example.com.
mail  IN  A      192.0.2.25
@     IN  TXT    "v=spf1 mx -all"

@ stands for the zone’s own name, example.com., and names without a final dot are relative to it, so www means www.example.com.. The zone has two name servers, one inside the zone (which needs glue in the parent) and one outside it.

A few rules prevent common mistakes:

• A CNAME cannot share its name with other records. A name that is an alias is only an alias. This is why the top of a zone, which always has SOA and NS records, cannot be a CNAME; DNS providers offer non-standard workarounds for that case under various names.
• MX and NS records must point to names that have address records, not to aliases (RFC 2181).
• Reverse lookups use special zones. The name for the address 192.0.2.10 is 10.2.0.192.in-addr.arpa, with the bytes in reverse order so that the most general part comes last, as in every other DNS name. IPv6 uses ip6.arpa with one label per hexadecimal digit. The PTR record found there gives the name.

Inside a DNS message

Questions and answers use the same message format. Every message starts with a 12-byte header, followed by four sections.

• The ID is a random 16-bit number chosen by the asker and copied into the answer, so that answers can be matched to questions.
• The flags say whether the message is a query or a response (QR), what kind of query it is (the opcode), whether the answer is authoritative (AA), whether it was truncated (TC), and whether recursion is desired (RD) and available (RA). Two bits were added later for DNSSEC: AD (authentic data) and CD (checking disabled). The 4-bit response code says how the query went: 0 for no error, 2 for SERVFAIL (the server failed), 3 for NXDOMAIN (the name does not exist).
• The question section holds the name, type and class asked for.
• The answer section holds records that answer the question.
• The authority section points to authoritative servers, as in a referral.
• The additional section holds records that may help, such as the addresses of the servers in a referral.

DNS normally runs over UDP on port 53: one packet out, one packet back, no connection to set up. The original specification limited UDP messages to 512 bytes. When an answer does not fit, the server sets the TC flag, and the client repeats the query over TCP on port 53. Today, the EDNS(0) extension (RFC 6891) lets a client announce that it can receive larger UDP messages, which DNSSEC signatures in particular need. TCP support is required of every implementation (RFC 7766), and zone transfers between servers use it.

Trying it yourself

The command-line tool dig, available on most systems, shows DNS messages in full:

dig www.example.com AAAA     # ask your resolver for the IPv6 address
dig example.com MX           # find the domain's mail servers
dig -x 192.0.2.10            # reverse lookup: the name for an address
dig +trace www.example.com   # follow the referrals from the root yourself

Its output lists the header flags and the sections described above. On Windows, nslookup and Resolve-DnsName do similar work.

Security and privacy

The original DNS has no way to prove that an answer is genuine. A resolver accepts an answer if it arrives from the right address, on the right port, with the right ID. An attacker who can guess those can send a forged answer first, and the resolver will cache it and hand it to all its users, a so-called cache poisoning attack. Resolvers now choose random source ports in addition to random IDs (RFC 5452), which makes guessing far harder, but only cryptography solves the problem.

DNSSEC: authentic answers

DNS Security Extensions (DNSSEC), defined in RFC 4033 to 4035, add digital signatures to DNS data:

• A zone signs every record set and publishes the signatures as RRSIG records.
• Its public keys are published as DNSKEY records.
• The parent zone vouches for the child’s key with a DS (delegation signer) record, which the parent signs in turn.

This builds a chain of trust from the root zone, signed since July 2010, down to each signed zone; the root’s key is the trust anchor that validating resolvers have built in. A validating resolver checks every link. If a signature does not verify, it refuses the answer rather than passing on forged data. DNSSEC proves where data comes from and that it was not changed; it does not hide the questions or answers.

Encrypted DNS: private questions

Ordinary DNS queries travel unencrypted, so anyone on the path can see which names a device looks up. Three standards encrypt the connection between a device and its resolver:

Encryption protects the questions on their way to the resolver. The resolver itself still sees them, so choosing a resolver remains a question of trust.

Key points

• DNS is a distributed, hierarchical database that maps names to records such as IP addresses.
• The name tree is divided into zones. Each zone is served by authoritative servers, and parents delegate to children with NS records.
• Recursive resolvers answer for their users by following referrals from the root down, and cache every answer for its TTL.
• Messages normally travel over UDP port 53, with TCP for large answers and zone transfers.
• DNSSEC makes answers verifiable. DoT, DoH and DoQ make questions private.