Module 1 · 1.4
The journey of a DNS query
Module 1: What is DNS? · Reading time: 8 minutes
Learning objective: After this lesson, you'll be able to explain step by step how a resolver finds an answer, and where answers are remembered along the way.
Key concepts: resolver (recursive), root server, TLD server, authoritative nameserver, referral (delegation), cache
Two types of DNS servers
In lesson 1.1 you saw that DNS is distributed: no one knows everything. So how does your browser get the address of www.example.com? Two types of servers work together to make this happen:
- Authoritative nameservers (they have the authority over a zone) know the answer for their own little piece. The nameservers of
example.comknow the records ofexample.com. They don't look anything up for anyone else. - Resolvers (also called recursive resolvers) look up the answer for you. They keep asking until they get it. Your internet provider has a resolver, and there are public resolvers too, such as those from Quad9, Cloudflare or Google.
Your computer itself barely looks anything up. It has a small stub resolver that passes the question to your network's resolver and gets the answer back.
The journey, step by step
Let's say the resolver hasn't remembered anything yet, and you ask for the A record of www.example.com.
- Your computer asks the resolver: "What's the A record of www.example.com?"
- The resolver asks a root server. Every resolver has a built-in list of the root servers' addresses. The root server knows nothing about
example.com, but it does know who manages.com. It replies with a referral: "You need to ask the nameservers of com: a.gtld-servers.net, b.gtld-servers.net, and so on." - The resolver asks a nameserver of .com. That one doesn't know the IP address of
www.example.comeither, but it does know which nameserversexample.comhas. Another referral: "Ask ns1.hosting.example or ns2.hosting.example." - The resolver asks a nameserver of example.com. That one is authoritative for this domain and gives the answer: "www.example.com has A record 192.0.2.10."
- The resolver gives the answer to your computer. Your browser connects to 192.0.2.10.
A referral from a higher level to the nameservers of a lower level is called a delegation. The root delegates .com to Verisign, and .com delegates example.com to the nameservers the registrant has specified. For a .nl domain it works exactly the same way, except the root refers to the nameservers of .nl (SIDN, the registry of .nl in the Netherlands, for example ns1.dns.nl). You'll see this yourself in the exercise at the bottom of this lesson. That's why it's so important that the nameservers at the registry are correct (lesson 2.1).
The cache: not the whole journey every time
If every resolver started at the root for every single query, the root would receive an unimaginable number of requests. That doesn't happen, because the resolver remembers answers for a while. That memory is called the cache.
How long an answer may be remembered is stated in the answer itself: the TTL (time to live), in seconds. A TTL of 3600 means: this answer may be remembered for an hour. Referrals are remembered too. A resolver that has just learned which nameservers .com has doesn't need to ask the root again next time.
If someone else at the same provider asks for www.example.com a minute later, the resolver answers straight from its cache. No journey, no waiting.
Caches exist in several places:
- in your provider's resolver or the public resolver you use;
- in your operating system (Windows, macOS, your phone);
- in your browser;
- sometimes in your router.
That's fast and efficient, but it has a consequence you'll often run into later: if you change a record, caches keep giving the old answer until their TTL has passed. That's why one person already sees a change while another doesn't. Module 6 covers this in detail.
The root servers
There are 13 root server names: a.root-servers.net through m.root-servers.net. They're managed by twelve different organisations. Behind each name there are many servers worldwide, in hundreds of locations, sharing the same address (this is called anycast). Your resolver automatically ends up at a nearby one. The TLD nameservers, such as those for .com and .nl, work the same way. This makes DNS fast and keeps it working even if a server fails somewhere.
Where things can go wrong
Knowing the journey helps you place problems correctly:
- The delegation is incorrect. The registry lists nameservers that no longer know the domain. The resolver gets stuck at step 4. The result is either an error or no answer at all.
- The authoritative server has a different answer than you expected. You've changed the record somewhere other than where the nameservers actually are (lesson 2.1).
- The cache still has the old answer. In that case, nothing's broken. You just need to wait until the TTL has passed, or clear your own cache.
- DNSSEC doesn't check out. A validating resolver checks signatures along the way. If the chain doesn't check out, it refuses the answer (lesson 8.1).
With the tool dig +trace you can retrace the journey yourself, from the root to the authoritative server. You'll learn this in lesson 8.2. Online tools can do this too.
Summary
- Authoritative nameservers know the answer for their own domain; resolvers look up the answer for you.
- A resolver starts at the root, gets a referral to the TLD, then to the domain's nameservers, and gets the answer there.
- Such a referral is called a delegation.
- Answers are remembered in caches, for as long as the TTL says; this means changes aren't visible everywhere immediately.
- There are 13 root server names, but thanks to anycast there are many servers worldwide behind them.
Quiz
Exercise
Exercise Z1.4: Following the journey. Follow the journey for www.sidn.nl, using dig +trace www.sidn.nl or an online tool that shows a trace. Fill in: (1) one nameserver of nl. that you encounter along the way, (2) one authoritative nameserver of sidn.nl.
Further reading
These articles describe the situation at WebOké. With other providers it works in a similar way.