We often take the DNS resolution process for granted. In this video, you’ll get an insight into what happens behind the scenes when resolving an IP address and how the DNS server configuration is used during the resolution process.
DNS is the domain name system, and we often refer to this as the service that converts the fully qualified domain names that we might type into our browser to something our networks might use, like an IP address. But what you may not realize about DNS is that this is not simply a standalone server that provides this resource. There are multiple servers across the internet that provide these translations and they work on a hierarchy across all of the different fully qualified domain names.
This is also a very distributed database, because we have many different DNS servers on the internet. There are 13 root server clusters. In actuality, this consists of over 1,000 different servers. There are hundreds of generic top-level domains. These are the domains that are the .com, the .org, the .net, and others. And then there are also country-level top-level domains, like .us, .ca for Canada, or .uk for the United Kingdom.
Here’s a very simple visual representation of this hierarchy from the perspective of professormesser.com. We’ll start at the top with a period. This designates the end of the fully qualified domain name. And working backwards, we would have a .com, a .net, a .edu, and others. Obviously, professormesser.com would be the next layer in this hierarchy. So you can see underneath .com, we have .professormesser.
And of course, there may be multiple servers at professormesser.com. If you go to my website, then you’re visiting www.professormesser.com, but I might have a mail server, which is mail.professormesser.com. And in very large networks, you may have organizational domain names– for example, east.professormesser.com and west.professormesser.com. And in the east, there may be certain servers. In the west, there might be other servers. Having this hierarchy allows us to configure a very specific structure, and this works across every fully qualified domain name on the internet.
If you’d like to see visually how this translation operates and your system supports the dig command, you can run at the command line dig www.professormessor.com. The results of this command show us a summary of what we requested. It shows the information that was sent asking specifically for an address associated with www.professormesser.com.
And then you can see in the ANSWER SECTION, there are actually three different IP addresses associated with my web server, and you can see those IP addresses are listed here. The reason there are three different addresses for my web server is for redundancy. If one of those IP addresses is no longer available, your device can use any of these other IP addresses to communicate back to www.professormesser.com.
If you’re not on a system that supports the dig command, you can use nslookup professormesser.com. This will go out to your locally configured DNS server and provide answers for the professormesser.com IP addresses, and you can see the results of this query show exactly the same three IP addresses.
Behind the scenes, the DNS server has a large database that contains fully qualified domain names, IP addresses, and other details that can help your systems perform this translation between fully qualified domain name and IP address. We refer to these as resource records, and in this video, we’ll look at a number of different types of resource records that are used on a DNS server. There are over 30 different record types. We won’t go through all 30 of those in this video. Those record types might be IP addresses, certificates, host names, and other details.
As you can imagine, a DNS server is a critical resource. If a DNS server isn’t available, you can make the request to visit www.professormesser.com, but there’s nothing behind the scenes to make the translation between the fully qualified domain name and the IP address. This is why we tell people, if you’re making a change to DNS, make sure you have very good backups of the previous configuration and that you know exactly what you’re changing in that DNS server.
Many DNS servers have a very simple configuration file that’s written in text, and this is an example of one of those DNS configurations. The section at the top is the Start of Authority Record. This has some mail exchanger records inside of it, a list of IP addresses, and fully qualified domain names, and you’ve got some canonical or alias names that you’ve also assigned inside of this DNS server. This makes it relatively easy if you need to make changes to a DNS server’s configuration because you can use any text editor to modify or update this configuration file.
You might also find that the DNS service that you’re using can provide you with a web-based front end to the configuration, so instead of understanding all of those different records and understanding where they go in the configuration file, you can put them all into a web-based front end and make your changes from there.
The first record will look at and perhaps one of the most common records you see in a DNS server is an address record. We often refer to these as in A record or a AAAA record. The A records are address records for IP version 4. So this a record will have a fully qualified domain name and the associated IP version 4 address. The quad A records are for IPv6. The same thing applies. We’d have a fully qualified domain name, and we would associate the IPv6 associated with that domain name.
Here’s an example of an A record that’s on the professormesser.com DNS server. You can see that I am specifying that www.professormesser.com is an internet address using the A record, and the IP address associated with that fully qualified domain name is 162.159.246.164. If you’re configuring this in a DNS text file, then you also have the option to add remarks or other comments on that record line.
If the front end to your DNS server is in a web-based configuration, it’s the same information, but we’ve separated out the A record, the hostname, the IP address, and the time to live for this IP address. The time to live in a DNS server is specifying how long an end station will remember this match between fully qualified domain name and IP address.
This 15 minute time to live means that a device will make the request to a DNS server and store or cache that information for 15 minutes. After 15 minutes, that information is removed from the cache, and if this device needs to communicate back to the www server, it will need to request, again, the IP address for that particular record.
Here’s the same thing, but from the perspective of IPv6, where we’re configuring a quad A record, and we have a hostname, an IPv6 address, and, again, a time to live.
Another important record in a DNS is where all of your emails should be delivered. This is a mail exchanger record or an MX record. To make this work, you would need two separate records inside of your DNS server. The first would be the MX record. You can see the mail exchange record in this server points to mail.mydomain.name. To be able to obtain the IP address for mail.mydomain.name, we would need to look at an A record, and you can see there is an A record for the mail.mydomain.name, which is 123.12.41.41, and it is a Linux server.
DNS servers have many different functions they can provide. One of those is to stored text information that can then be used for other purposes. We would store the text information in a text record or TXT record. This is usually public information. Since people are able to query these text records on your server, these text records were originally designed for very informal purposes.
But today, we have very specific uses for a TXT or text record in our DNS server. For example, we might use this for verification purposes. We might be making a configuration change to our domain, and that domain change requires that you add something very specific to a text record in your DNS server. This is because the DNS server configuration is usually very secure, and only authorized individuals would have access to make changes to a DNS server’s configuration.
We also use this text record extensively for email security, and you’ll see in a moment how we’re able to add information to a text record that can help verify the origination of a particular email. If you want to see some example of text records, you can look at the text records that are on the professormesser.com DNS server. If you’re running dig, you can use dig professormesser.com and then txt. And then it will show all of the text records that I have currently configured on my DNS server. You can see that I have two currently configured, one for a stripe verification, and another one that is used for mailgun.org, which is used to send out my email messages.
If dig isn’t available, you can also view these using an nslookup. You would use nslookup-type=txt, and then the domain name such as google.com or professormesser.com. You can see when you perform a google.com lookup that Google has a number of text records on their device, which include things like a Facebook domain verification, a Google site verification, and a DocuSign text record.
A common text record you might find is an SPF record, or a sender policy framework. This is a list of all of the email servers that are authorized to send messages using your fully qualified domain name. This was created to help prevent others from spoofing your fully qualified domain name and sending email as if you would send it yourself. A mail server receiving an email that says it was from professormesser.com will query the professormesser.com DNS server, retrieve this SPF record in the DNS server, and be able to determine is this something that really came from an authorized host?
Here’s the same process for creating a text-based DNS record, and you can see, you just paste in the text that is associated with the record that you’d like to add. In this example, you can see that I’m adding the SPF record into my DNS server, and, again, I have a TTL of 15 minutes.
We can even take this email security one step further and provide a digital signature that we can associate with outgoing mail. We do this through the use of a DKIM text record, or Domain Keys Identified Mail. This is going to be validated by the mail servers as that message is traversing the network, and the public key associated with this digital signature is added to a text record in your DNS server.
Here’s the same configuration for that DKIM record, except we’re making the configuration change in this web-based front end, and you can see, it’s a large bit of text that is the public key for all of the digital signatures that have been sent from my domain.
Now that we have a way to verify messages that have been sent and to digitally sign messages that are being sent, we need some way to determine what we do with those messages if the verification fails. We would use DMARC for that purpose. This is the Domain-based Message Authentication Reporting and Conformance. This is an extension of the SPF and DKIM processes that we’ve already seen, except DMARC takes the extra step to determine the disposition that should be used when someone receives a message that can’t be validated.
You might create a DMARC record on your DNS server that says, if a message is not validated, simply accept it, or maybe send it to a spam folder, or simply reject the email entirely. The mail servers behind the scenes keep track of how many mail messages have been validated and how many have failed the validation, and then you can receive a report that shows exactly how many messages were able to get through based on the SPF or DKIM configuration.
And here’s an example of adding one of those DMARC text records to your DNS. You can see that the content specifies what to do with the email messages and where to send the report so that you can examine how your mail has been distributed.