The Domain Name System (DNS) is the directory that turns names people can remember, such as www.example.com, into the information computers need, such as the IP address 192.0.2.10 or the mail server for a domain. It is not one big database. It is a distributed hierarchy of servers, each responsible for a small part of the namespace, held together by delegation and made fast by caching. The original design is described in RFC 1034 and RFC 1035, and the basics have held up remarkably well.
Two kinds of DNS server
Most confusion about DNS clears up once you separate its two roles.
Recursive resolvers
A recursive resolver does the work of finding an answer on your behalf. Your device sends it a question, and it either answers from its cache or goes and finds out. Your internet provider usually runs one, many organizations run their own, and there are large public resolvers you can choose to use instead. Your device's own "stub resolver" simply hands questions to whichever recursive resolver it is configured to use.
Authoritative servers
An authoritative server holds the actual records for a zone and answers definitively for it. The nameservers listed for your domain at the registry are authoritative for your domain. They do not look anything up elsewhere. They answer for their own zones or say that a name does not exist.
Following a lookup from the top
Suppose a resolver with an empty cache is asked for the address of www.example.com. It works down the hierarchy:
- The root. The resolver starts with a built-in list of root server addresses and asks one of them. The root does not know about www.example.com, but it knows who runs .com, so it replies with a referral: the nameservers for .com.
- The TLD. The resolver asks a .com server. That server does not hold example.com's records either, but it knows which nameservers the domain has been delegated to, and refers the resolver there.
- The authoritative server. The resolver asks one of example.com's nameservers, which returns the answer, for example an A record with the address 192.0.2.10.
- Back to you. The resolver returns the answer to your device and stores it in its cache.
You can think of it as asking for directions: each server either gives the answer or points you to someone closer to it. More on how delegation between these levels works is in Understanding nameservers.
Caching and TTL
If every lookup went all the way to the root, DNS would be slow and the root servers would be overwhelmed. Caching prevents that. Every DNS record carries a time to live (TTL), measured in seconds, which tells resolvers how long they may keep a copy.
www.example.com. 3600 IN A 192.0.2.10
Here the TTL is 3600, so a resolver that fetches this record may reuse it for up to an hour. During that hour, it answers from memory without contacting the authoritative server. The countdown starts when that resolver fetched the record, so different resolvers hold copies that expire at different times.
Caching happens at several layers:
- the recursive resolver;
- your operating system;
- your browser and some applications.
Resolvers also cache negative answers. If a name does not exist, that "no such name" answer is cached too, for a period derived from the zone's SOA record. This is why a record you just created can seem invisible for a while if someone looked it up moments before it existed.
Some resolvers impose their own minimum or maximum TTLs, and a few applications cache longer than they should, so the TTL is a strong guide rather than an exact promise.
What "propagation" really means
When you change a DNS record, you will often be told to "wait for propagation," sometimes with a figure like 24 to 48 hours. The phrase suggests the change is slowly travelling across the world. That is not what happens.
The change takes effect on your authoritative servers almost immediately, typically within seconds or minutes depending on your DNS provider. What takes time is existing cached copies expiring. Any resolver that fetched the old record keeps using it until its TTL runs out, then fetches the new one on the next request. Resolvers that had not cached the record see the new value straight away.
Some practical consequences:
- Lower the TTL before a planned change. If a record has a TTL of 86400 (one day), reduce it to something like 300 at least a day before you change it. Once the long-TTL copies have expired, your change will be picked up within minutes.
- Nameserver changes are slower. When you move a domain to different nameservers, the delegation records at the TLD registry have their own TTL, often a day or more, which you do not control.
- Different people see different answers for a while. That is expected, not a fault.
Comparing public resolvers
A useful way to watch a change settle is to ask several public resolvers the same question and compare answers. It is important to understand what that comparison shows. Large public resolvers run many servers in many locations, each with its own cache, and you reach whichever instance is nearest to the tool doing the checking. So the comparison shows the cache state of those particular resolvers at that moment, not whether your change has "reached" a given country. If one resolver still returns the old value, it simply fetched the record before the change and its copy has not yet expired.
When DNS goes wrong
Many problems that look like "the website is down" are DNS issues:
- NXDOMAIN: the name does not exist, often a typo or a missing record.
- SERVFAIL: the resolver could not get a valid answer, perhaps because the authoritative servers are unreachable or DNSSEC validation failed. See What is DNSSEC?.
- Stale answers: an old record is still cached somewhere.
- Inconsistent nameservers: your authoritative servers disagree with each other, so answers depend on which one a resolver happens to ask.
Check it yourself
- DNS Lookup queries records for a name so you can see exactly what is published, along with TTLs.
- DNS Resolver Comparison asks several public resolvers the same question, which helps you see whether cached copies of an old record are still in circulation.
- Nameserver Checker queries each of a domain's authoritative servers directly and flags disagreements between them.
For a tour of the record types themselves, see Understanding DNS records.