The Domain Name System is, on the surface at least, a simple system. Its most visible functionality is translating names into IP addresses, for example www.google.com to 216.58.211.164. Peering beneath the surface reveals a much more complicated system that is often misunderstood.
The Resolution Process
DNS resolution is the process that a system goes through to look up information about a name in DNS. A DNS client starts by asking one of its configured resolvers a question which includes the DNS name it wishes to make a lookup for and the type of the query (e.g. A for IPv4 addresses, AAAA for IPv6, MX for mail servers or many other types).
If the resolver already knows the answer for the query, for example because it has recently been asked the same question, it can immediately send an answer and the process concludes. The resolver may be configured to simply forward all queries to another resolver—most consumer broadband routers are configured to forward queries to the ISP’s DNS resolvers—in which case the query is simply sent on, and the answer relayed back to the client. Failing that, the resolver must perform the recursive resolution process.
As with most DNS query processes, a DNS server will avoid performing the full query process if it has entries in its cache that can help it avoid repeating parts of the process. The following process assumes a DNS server has nothing in its cache, which simplifies the explanation as we don’t have to keep referring back to the cache.
To begin the process, a recursor will send the query it received from the client to one of the well-known DNS root servers. This is a list of 13 DNS servers distributed across the globe that hold a copy of the DNS root zone, and whose IP addresses are built-in to DNS recursor software. The root zone contains entries for the top-level domains, or TLDs, including the likes of com, net, org, uk, fr, or the newer info, tech, space, etc… The root servers almost certainly don’t have the answer to the query, but they can point the recursor towards other servers that have a better idea. For example, when looking up www.tiger-computing.co.uk, the root servers’ reply will simply state that uk can be found over there.
The process by which a DNS zone can point at another like this is known as delegation: the root zone (also known as just .) delegates the uk. zone to servers operated by Nominet, the authority for the uk TLD. And thus the recursor repeats, sending the same query again to one of the servers it got back from the root servers. The servers for uk again don’t know the answer, but they know that tiger-computing.co.uk can probably be found with yet another set of servers: the tiger-computing.co.uk. zone has again been delegated, this time to ourselves. Finally, the question is repeated again to DNS servers that hold our zone file and which know the answer to the query. The recursor will then send the reply on to the client that asked it the question.
Only at the end of this process can, for example, a web browser start connecting to a web server in order to load a web site. It is vitally important for DNS resolution to be as fast as possible, or people may start to turn away from a slow-loading web site.
The whole recursive resolution process can be followed using the dig command on a Linux system:
$ dig www.tiger-computing.co.uk +trace +nodnssec ; <<>> DiG 9.11.5-P4-5.1-Debian <<>> www.tiger-computing.co.uk +trace +nodnssec ;; global options: +cmd . 497470 IN NS k.root-servers.net. . 497470 IN NS b.root-servers.net. . 497470 IN NS d.root-servers.net. . 497470 IN NS c.root-servers.net. . 497470 IN NS i.root-servers.net. . 497470 IN NS g.root-servers.net. . 497470 IN NS j.root-servers.net. . 497470 IN NS a.root-servers.net. . 497470 IN NS l.root-servers.net. . 497470 IN NS e.root-servers.net. . 497470 IN NS f.root-servers.net. . 497470 IN NS h.root-servers.net. . 497470 IN NS m.root-servers.net. ;; Received 853 bytes from 172.30.96.1#53(172.30.96.1) in 2 ms uk. 172800 IN NS nsa.nic.uk. uk. 172800 IN NS nsb.nic.uk. uk. 172800 IN NS nsc.nic.uk. uk. 172800 IN NS nsd.nic.uk. uk. 172800 IN NS dns1.nic.uk. uk. 172800 IN NS dns2.nic.uk. uk. 172800 IN NS dns3.nic.uk. uk. 172800 IN NS dns4.nic.uk. ;; Received 474 bytes from 192.58.128.30#53(j.root-servers.net) in 24 ms tiger-computing.co.uk. 172800 IN NS ns0.portfast.net. tiger-computing.co.uk. 172800 IN NS ns1.portfast.net. tiger-computing.co.uk. 172800 IN NS ns1.tiger-computing.co.uk. tiger-computing.co.uk. 172800 IN NS ns2.portfast.net.uk. tiger-computing.co.uk. 172800 IN NS ns2.tiger-computing.co.uk. ;; Received 229 bytes from 213.248.220.1#53(dns3.nic.uk) in 12 ms www.tiger-computing.co.uk. 3600 IN CNAME fender.tiger-computing.co.uk. fender.tiger-computing.co.uk. 3600 IN A 188.246.204.235 tiger-computing.co.uk. 3600 IN NS ns2.tiger-computing.co.uk. tiger-computing.co.uk. 3600 IN NS ns2.portfast.net.uk. tiger-computing.co.uk. 3600 IN NS ns1.tiger-computing.co.uk. tiger-computing.co.uk. 3600 IN NS ns0.portfast.net. tiger-computing.co.uk. 3600 IN NS ns1.portfast.net. ;; Received 266 bytes from 193.35.57.58#53(ns1.tiger-computing.co.uk) in 239 ms
In this case www.tiger-computing.co.uk is actually on a server called fender.tiger-computing.co.uk, which is what the CNAME denotes: it’s a “canonical” name or alias for another name in DNS. If the record for fender had not been included in this response the recursor would have to go back and start again, resolving the value of the CNAME record to find the actual A record that the client wanted.
It’s important to understand that when you buy a domain name, all you get from the registry (e.g. Nominet for uk) is a delegation from their zone to a set of DNS servers of your choice for your domain name. It’s up to you to find or operate those DNS servers, though many domain name resellers will include use of their DNS servers for the domain name that you have purchased. They may additionally bundle other services with that too, such as web site or email hosting. It’s crucial to understand that these are separate services, however, and that a domain name may be obtained from one company, the DNS hosted with one or more others, one or more web sites with one or more other companies, and email with yet another.
Authoritative DNS Servers
Servers that hold a full copy of one or more zones are said to be authoritative for those zones. Such servers will generally not attempt to process queries that need recursion: the root servers will not make any attempt to find www.tiger-computing.co.uk’s A record and will just tell you to look elsewhere.
Authoritative DNS servers usually come in two flavours: masters and slaves. Masters hold the primary copy of a particular DNS zone. Any changes to a DNS zone are made on the master server for the zone which then sends notification messages to slave servers that a change has been made. Slaves will then perform a zone transfer query to copy across the updated zone contents. This process relies on a serial number that’s embedded in the zone’s header, its Start of Authority (SOA) record. The serial number must change and be higher than before in order to trigger the process of updating the zone on slave servers.
Caching and the Myth of Propagation
The term “propagation” suggests that changes in DNS have to somehow be spread across the whole Internet, but this doesn’t happen. Instead, DNS recursors are permitted to remember, or cache, the responses they have received from other servers so that they don’t have to keep repeating the same questions. The amount of time they are allowed to remember a set of DNS records for is included in the response to their queries.
If your DNS zone states that a response can be cached for 5 minutes, then that is the maximum amount of time that particular query can be remembered for. Conversely, if you state that responses can be cached for 3 weeks then the server may keep such responses for that entire time. For example, if during those three weeks you make changes to your DNS records or move your DNS hosting to another set of servers, then that particular recursor may keep giving out of date answers for many weeks. This assumes that you have remembered to increase the TTL in your zone so that slaves correctly obtain updated zone contents.
One problem is that every step of the recursion process involves a distinct set of queries, each with their own TTL (Time to Live, or maximum permitted caching time), many of which are imposed by systems outside the control of domain owners. The propagation myth was borne out of the need for a way to provide a simpler overview of this complex caching and TTL hierarchy. It’s a convenient lie we tell to make things simpler for people to understand. In reality, if a DNS change or domain move is planned well enough in advance, TTL values can be changed and plans put into place to make a transition almost seamless.
Photo by Matteo Grando on Unsplash.