How DNS works: resolvers, root, TLD and authoritative servers

The short version

If you want the plain English introduction first, read what is DNS. This guide goes one level deeper and follows a single lookup from start to finish, because knowing the chain makes it much easier to understand why changes take time and where things go wrong.

Four kinds of server take part: the recursive resolver, the root servers, the TLD servers and the authoritative nameservers. Only the last one holds your actual records. The others exist to find it.

Following one lookup

Say a customer types www.example.co.uk into a browser.

1. The device asks its resolver. This is usually run by the broadband provider, the office network or a public DNS service. If the resolver already has a fresh answer in its cache, it replies straight away and the lookup ends here.
2. The resolver asks a root server. The root servers do not know about example.co.uk. They only know who runs .uk, so they reply with a referral to the .uk servers.
3. The resolver asks the .uk TLD servers. Nominet runs these. They do not hold the website address either, but they know which nameservers the domain uses, because that is what was set at the registrar. They reply with those nameservers (plus glue addresses if needed).
4. The resolver asks the authoritative nameserver. This server holds the zone for example.co.uk and returns the actual record, for example an A record with the web server's IPv4 address.
5. The resolver caches and replies. It passes the answer to the device and keeps a copy for the record's TTL.

A .com lookup follows the same path, with the .com registry's servers in step 3.

Caching and TTL

Every answer carries a TTL (time to live) in seconds. A resolver that has cached a record will keep using it until the TTL runs out, without asking your nameserver again. Referrals are cached too, so a busy resolver rarely needs to ask the root or TLD servers. A "this name does not exist" answer can also be cached for a while, which is why a record added after someone looked it up may not appear for them straight away.

This is the reason DNS changes are not instant. If your A record has a TTL of 3600, some visitors may see the old address for up to an hour after you change it. The fix is planning: lower the TTL to around 300 a day or two before a move, make the change, then raise it again once things are settled.

Where changes actually happen

Knowing the chain tells you where to make each change:

• Changing a record (website address, MX, TXT) happens at the authoritative DNS provider. Only that zone changes, and caches catch up as TTLs expire.
• Changing nameservers happens at the registrar, which updates the TLD servers. This moves the whole zone to a new provider, and the referral itself is cached, so it can take up to 24 to 48 hours to be seen everywhere. See how to change nameservers.
• DNSSEC adds signatures to answers, and a DS record at the registry ties them to the domain. If the DS record does not match the provider's keys, validating resolvers refuse the answer. See DNSSEC.

Most "DNS is broken" problems come down to editing the wrong provider's records, because the nameservers point somewhere else.

How dijitul helps

We set up, change and fix DNS for small businesses, usually in Cloudflare. DNS management is included with dijihost Complete Hosting at £1 a day + VAT. On its own, set-up and changes are £45 an hour + VAT, or a fixed quote for bigger moves. See DNS management and DNS troubleshooting, or ask for a quote.

Related