The Domain Name System is one of the most used technologies on the Internet. In this video, you’ll learn about the DNS hierarchy, recursive and iterative DNS queries, and forward and reverse DNS queries.
DNS is the domain name system. And it’s one of the most popular protocols on the internet because its job is to translate those human readable names that we use for things like web services into an IP address that can be used by our computers. This is a process that occurs every time you type something into your browser, for example, www.professormesser.com has to have some type of IP address associated with it. And it’s the domain name system that provides that translation.
DNS is also configured as a hierarchy, which makes it very easy to organize things on the internet. And it is a very distributed database. There are many, many different DNS servers. For example, there are 13 root server clusters, which are the primary root servers for everything on the internet. And although this standard provides for 13 of these servers, there are actually over 1,000 servers providing redundancy across the entire internet.
This allows us to have top level domains, or TLDs, that may be generic such as the dot com, dot org, or dot net addresses we may be familiar with. But there are also country codes that can be used as top level domains. Things like dot US, dot CA, and dot UK are associated with individual countries. Here’s an example of how this hierarchy works with DNS. We start at the very top and we may have a dot com address, a dot net, a dot edu, or others. In my example, I have professormesser.com. So we start with the dot com the hierarchy just under the dot com has the Professor Messer.
I could also have other servers beyond that. For example, I have a web server, which is www.professormesser.com. I could have mail.professormesser.com. And I could even internally have an east and west. And within the east and west, I can have other servers within those particular areas as well, creating a hierarchy that tells me exactly what servers are associated with a particular area.
Visually, my fully qualified domain names, or FQDNs, might look something like this. We have the entire domain of www.professormesser.com. Within professormesser.com, I have a web server, www.professormesser.com. And I might have a west and an east side of professormesser.com. And within the west, I have a device called ethan.west.professormesser.com And in the east, I have katie.east.professormesser.com
So you can see how this hierarchy allows us to create these fully qualified domain names that not only identify what a device is, but perhaps where it’s located as well. Many times the DNS server that we’re using is one that is internal on our own network. We would have it running on our own internal services. Our local IT team manages and configures the device. It may have information about internal devices, which are very important on the inside of our network. But we might not want to share that with others on the outside.
Very often these are running on their own service. They could be running on Windows Server. It could be on a Linux device. But it would be a service that runs internally on our own equipment. There might also be an external DNS that is provided by a third party. We may contract with or pay for a third party to have someone else manage the DNS for us. For example, you may be running your systems on Google DNS, Quad9, or one of the many other DNS services available.
Behind the scenes, the process of resolving an IP address to the name that we provide can use a number of different forms. One of them is a recursive process. And the other is an iterative process. With the recursive query, we send our single request to what is usually a local DNS server. The local DNS server then sends out requests to try to find what the IP address might be for the request that we’ve sent. Once that name resolution is completed, it then reports back to us on what it may have found. It also is keeping a very large cache of these results. So if the next person makes this request to this recursive query, it can respond back immediately without having to go through the process again.
If we’re performing an iterative DNS query, then we’re making all of these queries ourselves directly to all of these different DNS servers. And there’s no central pool that is cached. Instead the cache is local on our machine. Here’s what a recursive query might look like. We have our local machine, which is identified as a resolver. We have a local name server that we’re going to use to provide this query. And out on the internet there might be root servers, a dot com name server, and perhaps even my own local professormesser.com server.
Let’s say that I wanted to look up www.professormesser.com. This request is sent to my local name server. That local name server then starts making queries on our behalf to other servers. For example, it may request that information from a root server. The root server may not have that information, but it may tell our local name server that you need to talk to the dot com server to find out where that might be. That local name server would then talk to the dot com server, which then says, you need to communicate to the professormesser.com DNS server.
And finally, the local name server will make that request. My local name server sends back what the answer might be. And that answer is sent to the resolver. At that point, that request is cached locally on the local name server. And now if someone else makes the same request, that local name server will provide the answer directly back without having to go through this entire process.
With an iterative query, our local device has to do all of the work itself. So the resolver may start communicating to the local name server to see if it happens to know what www.professormesser.com might be. And it says, no it doesn’t. You need to talk to the root server. We talk to the root server and the root server says, you need to talk to the dot com. We talk to dot com. The dot com server says you need to talk directly to the Professor Messer server.
And then finally, we find the correct DNS server and we bring that information back to our original resolver. At that point, the local cache of this device is updated. And if this local machine needs to make exactly the same query, it doesn’t have to go through this entire process again. It could simply look at the local cache on this device.
Another important consideration when you’re making these DNS queries is the authority of the answer that you’re getting. If you’re making a request of a server and you’re getting a response from the cache of that DNS server, you may notice that your request comes back as a non-authoritative answer. This means the answer we received did not come from the source files of the particular zone that we’re querying and probably came from cached information that was available.
Doesn’t necessarily mean that the information we’ve received is wrong. But if any changes were made to the original server, those changes may not be represented in the answer that we received. That’s why all of these answers that we receive from a DNS server have a timer. That timer is ticking down. We call this the time to live. And when information is received from a DNS server, that time to live is put next to the IP address in our cache. If that time to live gets all the way down to zero, then the next time we need to find that IP address, we’ll have to go through the entire name resolution process again.
This could also cause problems for you if time to live is set to some very large number. That means that your cache will sit locally on your machine for days or even weeks at a time. And if changes are made to the original DNS server and the IP configuration, your device may not know of those changes. If that occurs, you may have to manually clear your cache on your device so that an updated series of queries can occur.
Here are the results of a dig command that I performed for www.professormesser.com. This request went out to a server to try to find the IP address of that particular fully qualified domain name and I got three answers back from my local DNS server, which was 9.9.9.9. That’s the quad nine DNS server. Those three IP addresses I received back for www.professormesser.com can all be used to access my server. And each one of them has a value of 300 associated with them.
This is the time to live. That means once you’ve received this answer for www.professormesser.com, it should stay alive in your cache for 300 seconds, or five minutes. After that five minute time period, you’d have to re-query a DNS server and update the cache for another five minute period.
Most of the time, we’re performing forward lookups to a DNS server. That means that we’re providing the DNS server with a fully qualified domain name and the DNS server’s providing us with the IP address that resolves for that fully qualified domain name. You can also reverse this process. You can provide the DNS server with an IP address and the DNS server will tell you the DNS name, or fully qualified domain name, associated with that IP address. We refer to that query as a reverse DNS query.
Here’s a forward look up I did in dig. I performed a forward look up to www.professormesser.com. And in the answers I received IP addresses associated with that fully qualified domain name. Let’s take one of these IP addresses that I received for that forward lookup and let’s perform a reverse lookup. So I’ll perform a dig-x for the reverse lookup and specify the IP address that we received in that earlier query.
You’ll notice that the answer that comes back is not professormesser.com but is instead a server at cloudflare.com That’s because I use Cloudflare in front of my servers to provide access to my web services. And that means every time you’re connecting to my web server, you’re first connecting to Cloudflare, which then connects to a load balancer, which then connects to the Professor Messer web server to finally give you the information that you’re looking for.