I found this diagram while scrolling through my Linkedin feed the other day and it made me realise why so many people misunderstand how DNS works, this diagram was very popular and was shared around quite a lot, but there’s quite a few things wrong with it.
- There’s no mention of DNS caching.
- Inconsistent naming of the DNS name servers
- The “Local DNS Server” assumes you have your own server, in the real world this would be a DNS server hosted by your ISP or if you use Google(8.8.8.8)/Cloudflare(1.1.1.1) for your queries, then it will go to them. The actual name of this server is called a Recursive DNS nameserver.
- All of the DNS nameservers on the right are the Authoritative nameservers that own their respective zones and can provide answers to questions from recursors.
At the very start, on step 2 it says the recursive nameserver sends the question of “download.beta.example.com.” to the root nameservers, it would only do that if it doesn’t know about the “.com.” nameservers yet, which would mean the nameserver has just been installed/started up for the first time, in the majority of the cases, it would send a query to the “.com” nameservers for this instead.
There’s an important step missing, a recursive nameserver has it’s own DNS cache which would prevent too many queries going to an authoritative nameserver in the first place, as once it knows about the nameservers, it will cache this in it’s DNS cache so it saves time. It will also cache answers to questions, for example if you have queried for google.com before, then it will keep that in it’s cache so it doesn’t have to be looked up again, the way it makes sure that it’s still a correct (up to date) answer is that every DNS record has a TTL record attached to it (Time To Live), which tells recursors how long to keep the answer in it’s cache before resolving it again.
The recursive nameserver will check its own DNS cache of saved answers for “download.beta.example.com.” if it’s not within the DNS cache, then it will start a recursive lookup from right to left, one label at a time, so it will check if it knows about the root “.” nameservers, then the .com. nameservers, then the example.com. nameservers so it can find out where to send the query. Once it has done each one of these, it will save the answers to each of the questions in it’s cache.
A label is each name separated by a dot “.”, for example chrisappleyard.uk has two labels, chrisappleyard is the first label and uk is the second label.
The root zone is symbolised as the “invisible” dot (“.”) at the end of every domain name, for example: “example.com.”
The recursive nameserver will check if it has the answer in it’s DNS cache for the record in question, in this example I think it would be an “A or AAAA” record which is an IP Address record, which is the default lookup a client does if you don’t specify a type of lookup to perform (there’s many types of DNS records, like MX (Mail Exchange record) for example for email delivery), it will check it’s cache for an address record for “download.beta.example.com.”, if it doesn’t have an answer for that then it will need to perform a recursive lookup.
If the recursive nameserver has just been started up for the first time then it will need to “prime” the root, meaning, it will send a query to the root to find out the hostnames (NS records) and IP Addresses (A/AAAA records) of the root nameservers, then cache the answers, so it can send a query to one of them.
If the recursive nameserver has been running for a while then it might have lots of different things cached, it might even have delegation records (NS records) for example.com, in that case it could simply send the query “download.beta.example.com.” straight to the nameservers that are authoritative, or even straight towards the “beta.example.com.” nameservers if it’s been asked about it before and has it still in it’s DNS cache.
It’s also important to note that every DNS client (your laptop, phone etc.) has it’s own DNS cache, it can do it’s own lookups meaning it doesn’t have to keep sending queries to the recursive nameserver. The DNS client will only hold certain types of DNS records in it’s cache, such as A records, it won’t cache NS records (delegation records) because it doesn’t perform recursive lookups.
The next step the recursive nameserver will do is (if it’s just started up for the first time) send the A/AAAA record query for “download.beta.example.com.” to the root nameservers to see if they know about it, the root nameserver will reply with a “Referral” or “Delegation” answer which means it will give you the delegations to “.com.” (the NS records).
The recursirve nameserver will then send the A/AAAA record query to the “.com.” nameservers for “download.beta.example.com.”, the “.com.” nameservers will then reply with a referral for “example.com.”, On step 5 within the diagram, it gets this wrong.
The recursive nameserver will then send the A/AAAA record query for “download.beta.example.com.” to the “example.com.” nameservers, and in this example it answers again with another referral to “beta.example.com.”.
It’s important to note that in a DNS zone if you have a NS record for a record name, then you can’t have any other record called that within that zone, because you need to answer queries for all types of DNS records with the NS records so you can “re-direct” (refer) people to the other nameservers that holds the domain/zone, this means “example.com.” could actually have nothing for “download.beta.example.com.” and just reply saying it doesn’t exist, but in this example it has a referral to “beta.example.com.”.
The recursive nameserver will then, finally do a lookup for “download.beta.example.com.” to the “beta.example.com.” nameservers, and then those nameservers state that the record doesn’t exist, this would be the response code of “NXDomain” or non-existant domain, meaning it doesn’t exist.
Delegations/Referrals is a term used to describe how an Authoritative nameserver will tell you where to go to find another domain name within the DNS. This will consist of NS records (nameserver records), which will then be looked up for Address records (A/AAAA) to then send a query to those nameservers to find an answer to a question.
Using a popular DNS recursive nameserver called Unbound, which is made by NLNetLabs in the Netherlands, we can see how this works:
start of service (unbound 1.17.0).
resolving download.beta.example.com. A IN
priming . IN NS
response for . NS IN
reply from <.> 198.97.190.53#53
query response was ANSWER
priming successful for . NS IN
response for download.beta.example.com. A IN
reply from <.> 199.7.83.42#53
query response was REFERRAL
response for download.beta.example.com. A IN
reply from <com.> 192.43.172.30#53
query response was REFERRAL
resolving a.iana-servers.net. AAAA IN
resolving b.iana-servers.net. A IN
resolving b.iana-servers.net. AAAA IN
resolving a.iana-servers.net. A IN
response for a.iana-servers.net. A IN
reply from <.> 199.7.91.13#53
query response was REFERRAL
response for a.iana-servers.net. AAAA IN
reply from <.> 192.112.36.4#53
query response was REFERRAL
response for b.iana-servers.net. A IN
reply from <.> 202.12.27.33#53
query response was REFERRAL
response for b.iana-servers.net. AAAA IN
reply from <.> 202.12.27.33#53
query response was REFERRAL
response for a.iana-servers.net. AAAA IN
reply from <net.> 192.55.83.30#53
query response was REFERRAL
resolving ns.icann.org. AAAA IN
resolving ns.icann.org. A IN
response for a.iana-servers.net. A IN
reply from <net.> 192.54.112.30#53
query response was REFERRAL
response for a.iana-servers.net. A IN
reply from <iana-servers.net.> 199.43.135.53#53
query response was ANSWER
response for b.iana-servers.net. A IN
reply from <net.> 192.48.79.30#53
query response was REFERRAL
response for ns.icann.org. A IN
reply from <.> 192.33.4.12#53
query response was REFERRAL
response for a.iana-servers.net. AAAA IN
reply from <iana-servers.net.> 199.43.134.53#53
query response was ANSWER
response for a.iana-servers.net. A IN
reply from <iana-servers.net.> 199.43.134.53#53
query response was ANSWER
response for b.iana-servers.net. A IN
reply from <iana-servers.net.> 199.43.134.53#53
query response was ANSWER
response for download.beta.example.com. A IN
reply from <example.com.> 199.43.135.53#53
query response was NXDOMAIN ANSWER
It’s worth pointing out, in that log output from Unbound, it contacts the .net nameservers, this is because the nameservers for .com are “[a-m].gtld-servers.net.” (13 nameservers) this means the .com nameservers are out-of-bailiwick, meaning the nameserver records don’t exist within the .com zone it self.
There’s so much more that happens here, however I don’t want to go into too much detail, I will write more blog posts that explains more areas of the DNS such as how a Recursive DNS nameserver knows how to contact the root zone nameservers in the first place or explain how to secure DNS delegation/referral answers with DNSSEC, but for now I hope this has been useful and I hope you have a great day!
Leave a Reply