Domain Name Services are a critical part of any network. In this video, you’ll learn about DNS, local name resolution, forward and reverse lookups, recursive queries, and securing DNS.
One of the most common uses of DNS, or the Domain Name System, is to translate the names that we put into our browsers into IP addresses that can be used to connect with that particular server. For example, if you put into a browser www.professormesser.com, there’s no IP address associated with that name. There needs to be some process to resolve the IP address based on that name, and we rely on DNS to provide us with that name resolution.
This database of names is a hierarchy, and in this video, we will look at the structure of a DNS database. We often describe this resolution process as one device that is receiving information from one DNS server, but, in reality, there are many DNS servers. In fact, the root DNS servers consist of 13 separate server clusters that make up over 1,000 actual DNS servers. These DNS servers manage the Top Level Domains, or TLDs, of a number of different generic top levels such as .com, .org, .net, and others. There are also country-level TLDs. Those are country codes such as .us for the United States, .ca for Canada, .uk, for the United Kingdom, and so on.
Here’s an example of a DNS hierarchy. This starts at the very top of the tree, which is a single period or dot. Underneath that is the top-level domain, such as .com, .net, and others. And then you can have other names underneath those, such as professormesser. For example, you could have www.professormesser.com, all found by following this hierarchy. We refer to this as a Fully Qualified Domain Name, or an FQDN.
You can structure the names used in your organization into this FQDN model. For example, you can start with www.professormesser.com, which incorporates everything within our domain. Underneath that name, you might have www.professormesser.com, which is the fully qualified domain name of our web server. You can continue to add on to this domain name. For example, in our organization, there is an east and a west for the domain names, and within the east, there might be servers and services with names associated with them. And in the west, there might be a separate group of services in that particular area of the domain.
We use DNS to resolve the IP address of many different services. For example, a web server would be a very common resolution, but we also use this for things such as Active Directory and for application access. To be able to maintain uptime and availability of such an important service, we will often use redundant DNS servers. This means we might have two or more DNS servers, and we can configure our systems to use those redundant servers so that if the first server is not available, you still have another server to choose.
You’ll notice if you look at the configuration of your computer, there are usually two DNS configuration settings. This first one is for the primary DNS server. This is a DNS server that has all of the zone information for your particular DNS domain. Any changes you make to the configuration or updates to the config all happen in this primary DNS server.
The secondary DNS server is not used for primary configuration changes. Instead, it receives an update from the primary DNS server. All of this zone information is pushed down to the secondary server in a read-only mode, and anything that we get from a secondary DNS server was first configured on the primary DNS server.
From the end user’s perspective, of course, it doesn’t matter which DNS server is referenced. The same information exists in both of those, and regardless of which server was accessed, the end user has no idea if it came from a primary DNS server or a secondary DNS server.
In some situations, you might not want to query a name server to provide that name resolution. Instead, you might want all of that resolution to occur on your local machine. We refer to that as a local name resolution. For example, if you have a test server, you might want to configure your system to access this test IP address for that server rather than accessing the production server itself. You might also use local name resolution if you feel that the DNS server has incorrect information and you want to have your own resolution that corrects that information on your local machine.
To accomplish this, we need a file with all of this name resolution inside of it, and the file name is commonly called the hosts file because the name of the file itself is called hosts. This is an example of the hosts database. It’s simply a text file that contains information about the IP addresses and the names of the devices that you would like to resolve.
For example, I have a test server for www.ProfessorMesser.com. Its IP address is 10.1.10.170, and I can configure my hosts file to access that IP address every time I reference www.ProfessorMesser.com.
This works for many applications, but there are certain apps that will not reference the hosts file. Instead, they will rely on the DNS server as the primary source of information. So you’ll want to check the documentation for your application or your browser to see how it resolves this information, and that way you’ll know whether the hosts file is something that can be used on your system or whether you’ll need to configure all of those settings on the DNS server itself.
Here’s a bigger view of this hosts file inside of Windows. This file itself is located at windows/system32/drivers/etc/hosts. This is a file that is often stored as a read-only document, so if you want to make changes to this file, you’ll have to first change the file so that you have read-write access. And once you do that, you can modify the text within this file to have the IP addresses and names that you would prefer rather than the ones that are located on a DNS server.
One of the most common uses of a DNS server is to provide a forward lookup. This means that we provide the DNS server with a name, and it returns with an IP address. For example, we can send the name www.ProfessorMesser.com to the DNS server, and the DNS server will respond back to us with the IP address associated with that fully qualified domain name.
But we can also provide this entire process in reverse. We refer to this as a reverse DNS where we provide the DNS server with an IP address, and the DNS server gives us information on what it believes the name is for that IP. This is something that will need to be configured in the DNS server to provide both a forward lookup and a reverse lookup, and you’ll often find the name that you use for the forward lookup might be different than the name you receive for the reverse lookup.
Here are the results of a forward lookup. I provided this lookup through a utility named dig. This dig utility allows me to query DNS servers. I use the dig utility with the parameters www.ProfessorMesser.com. It tells me that it’s going to perform this query against the name server. It shows me information that I have requested here such as www.professormesser.com, and you can see that the results in the answer section show me three separate IP addresses associated with www.ProfessorMesser.com. These three IP addresses are listed here in this order, and at the bottom of this output we can see how long it took to perform the query and the DNS server that was referenced to provide these details.
With this particular example, you can see that there are three separate IP addresses that could be used to access www.professormesser.com, but let’s perform a reverse lookup to one of these IP addresses and see what the name is that we get back. To perform the reverse DNS lookup, I’m going to use the same dig utility, but I’m going to use the option of -x and include the IP address of 104.22.72.108. And if we look down further into the results that we get, we can see that that particular device is cruz.ns.cloudflare.com. This is because the front end to the www.ProfessorMesser.com web server is actually a front end located at cloudflare.com, and by performing the reverse DNS, we can see the actual name of that server appear.
When you receive the results of a DNS query, those are often provided to you through a server that is caching that information, but occasionally you would like to get information from the primary DNS server for that domain. We refer to that primary device as the authoritative server. That means that that DNS server is the one that is the authority for that entire DNS zone.
If you’re accessing a DNS server or receiving a result from a DNS server that is not the authority, then it would be a nonauthoritative server, so it may be a secondary server that’s receiving a copy of the zone files from the authoritative server. But in many cases, it’s usually a server that is caching this information to make that DNS query much faster.
For example, I use the nslookup utility to perform a DNS query of www.professormesser.com, and you can see that the server that was used for that lookup was 9.9.9.9, which happens to be a DNS server that is hosted by Google. You’ll notice that the results that I get back specify that these are nonauthoritative answers. That means all of this information showing the IP addresses associated with www.ProfessorMesser.com are not coming from the primary or authoritative server but instead have been cached on the Google DNS servers.
One of the challenges you have with information that’s cached is that information could be outdated. If I make a change to the IP addresses in my authoritative server, there may be cached IP addresses on a nonauthoritative server that are still providing incorrect information to end users. Fortunately, we can specify how long a nonauthoritative server will keep that information cached. At the end of that time frame, the nonauthoritative server will delete those details, and any subsequent queries for that domain name would need to go all the way to the authoritative server so that information could be cached again.
We refer to the amount of time that a nonauthoritative server will maintain that cache as a Time to Live, or a TTL. That time to live is added to the configuration file of the authoritative DNS, and it’s listed as the number of seconds that that information is allowed to be cached.
We can see this time to live when we perform a DNS query. For example, if you use dig to perform a query of www.professormesser.com, you can see that the results are showing three different IP addresses, but you’ll also see that there are some numbers included on each line of those IP addresses, the number 300. This specifies that this information will only stay in a cache for 300 seconds, so you know that the IP addresses that you’re resolving are going to be five minutes old or less.
DNS commonly uses recursive DNS queries to populate those local DNS servers and cache that information so that we’re able to obtain those resolutions as quickly as possible. This is part of the overall efficiencies associated with DNS, and it allows us to have many different DNS queries taking place but minimize the amount of overall network traffic. The DNS server itself is the one doing all of the hard work behind the scenes. The end user never sees any of these recursive queries.
And then once the original recursive query is done, we have information that’s now cached on our local DNS server, and any subsequent requests for that domain name will come from our local server in the cache.
Let’s look at how this recursive DNS query occurs. Let’s first assume that no previous queries have been made for this domain name, so nothing is hidden or stored within any caches. We start with the device making the request. We refer to this device as the resolver. This resolver is going to make a request to your local DNS server. So in this case, we’re looking for the name www.ProfessorMesser.com.
If your local DNS server is one that is managed by your company or it’s one that may be at a third party such as Google, that name of www.ProfessorMesser.com is not going to exist in that particular DNS database because the DNS server used by our domain is located at a different provider. So how does our local name server know where to find that particular information? Fortunately, the local DNS server is configured with a root server IP address, so the local name server is going to make a request to the root server asking for www.ProfessorMesser.com. The root server doesn’t contain that information, but it does know where the .com name server is, and it provides that information to your local name server.
The local name server is then going to make a request to the .com name server. The .com name server does have a record that shows where the primary DNS is for the domain www.professormesser.com, and it provides the answer of that IP address back to the local name server. Now the local name server knows exactly where the primary DNS server is, and it makes a direct request to the professormesser.com name server. And, of course, that server will know exactly the IP address for www.professormesser.com, and it will provide that information back to your local name server.
Now that that information is back at the local name server, it can provide the answer back to your workstation, and it will cache that information so that any subsequent requests will simply query the local name server, and the local name server will be able to respond back immediately.
DNS is a protocol that has been around for a very long time, and when it was first created, there was not a lot of work put into security of the protocol. Information for DNS is usually sent in the clear, and if someone was monitoring your DNS queries, they could at least have an idea of the services or the names of devices that you’re trying to access.
Another challenge is that the results that we’re getting from DNS are not authenticated, so we’re never quite sure if we’re receiving legitimate responses from a DNS server or if the responses that we’re receiving may be from a third party or spoofed DNS server.
One way to resolve this is to use DNSSEC. This is Domain Name Security Extensions, where the responses that we get from these DNS servers are digitally signed. This means that we can verify that the information that we’re receiving really did come from a trusted source and the information contained within that DNS response has not been modified by a third party somewhere along the transmission. DNSSEC does require additional changes in configurations on your DNS server, but it does provide a much more secure method of name resolution.
Even though this information has now been digitally signed and we can confirm that we are receiving information from a trusted source, the information that’s being sent is still in the clear, which means anybody capturing that traffic can see the host names that you’re trying to access. One way to resolve this is to encrypt all of the traffic to and from the DNS server. One method of encrypting this data is through DNS over TLS, or DoT. This allows you to send the DNS traffic over a different TCP port than usual. By default, it’s tcp/853, and it encrypts all of that information using very similar protocols to what we use when we are encrypting web-server communication.
Another form of encrypting this DNS information is to send DNS over HTTPS, or DoH. This is going to send all of that DNS information over a very standard HTTPS packet. This is the same process of communication that we use to send and receive encrypted data to a web server, and if you were to look at a packet capture, you would see traffic that looked exactly like encrypted web-server traffic that’s being communicated over TCP port 443. Some of the more modern browsers use DoH by default, and you may be already encrypting that DNS traffic whenever you’re accessing web servers from your browser.