DNS Configuration – CompTIA A+ 220-1201 – 2.4

DNS stands for the Domain Name System, and this is one of the most critical resources and services available on our networks. That’s because we use DNS to be able to provide IP addresses, when all we remember is a fully qualified domain name.

For example, you could type into your browser www.professormesser.com, and behind the scenes a DNS resolution occurs that translates the name www.professormesser.com into the IP address that is associated with that particular web server address. This means that we don’t have to remember any specific IP addresses. All we have to remember is the name of the server that we want to communicate to. Behind the scenes, DNS will make sure that we’re able to connect to that IP address.

DNS provides this resolution and many other features as well, some of which we’ll learn about in this video today. This DNS database is a hierarchy that allows us to find the IP address of any fully qualified domain name on the worldwide internet. We refer to DNS as a distributed database because this is a database that is scattered throughout the entire internet. Portions of this database are contained on different servers located on different networks around the world.

If we were to drill down on the specifics of the DNS standard, you would see that there were 13 separate root server clusters. This cluster is more than simply 13 separate servers. In reality, there are over 1,000 servers making up that root server cluster. That root cluster allows us to then communicate with DNS servers that are handling top level domains.

These generic top level domains, or GTLDs, are the ones that you might recognize, a .com, a .org, a .net, and so on. You might also see these top level domains separated by country. There are about 275 country codes. For example, the United States is the .us domain. Canada is .ca, the United Kingdom is .uk, and so on.

When we say that the DNS database is a hierarchy, this is a visual representation of what we mean. Underneath the top level domains is a domain name such as www.professormesser.com. And you’ll notice there is the .com and just under the .com is the .professormesser. You can continue to add layers to this hierarchy. For example, our web server at Professor Messer is www.professormesser.com. We might also have a mail.professormesser.com and so on.

And of course, you could have individual servers and devices underneath those domain names as well. So you could have a katie.east.professormesser.com or a judy.west.professormesser.com. This allows you to organize your DNS infrastructure into a way that makes sense for your organization, and have it accessible to anyone in the world.

If you wanted to get some insight into how a particular DNS server might be configured, you might want to use different tools to be able to access that database. One of these tools is the dig command. Dig is a common command on Linux and macOS, and some versions of Windows also have a dig version that you could install. Dig allows you to perform a query against a DNS server.

So if we dig www.professormesser.com, we get the results that are on this page. It shows us what commands we are using, gives us exactly what question is being asked of that particular DNS server, and then provides answers to the question that was asked.

In this case, making a query for www.professormesser.com results in three separate IP addresses being returned. This represents the three possible addresses you could use to communicate to our web server. The reason we get three separate IP addresses in the results is that we have created a redundant series of web servers so that if one IP address is suddenly not available, you can use any of the remaining IP addresses to communicate to our web server.

If you’re on Windows, you can use the nslookup command to provide the same information. For example, nslookup of professormesser.com will return the same answers with the same three IP addresses.

When we make that query to the DNS server, we are returned information that is contained within the records of that DNS database. Those records are referred to as resource records or RR. Those resource records contain information about the IP addresses we’d like to query, their certificate information, email details, host alias names, and much more.

This is one of the reasons that we often say that a DNS configuration is not something you should toy around with if you’re not familiar with what you’re doing. One mistake made to the database inside this DNS server could cause one or more of your devices to suddenly become unavailable to anyone else on the internet. If you are going to make a change to a DNS server, just keep in mind that you should always have a backup and a way to easily revert to that backup if you run into any problems.

If you manage your own DNS server, then this will probably look familiar. This is a configuration of a DNS server. You can see there is an SOA record at the top, an MX record, some A records along with that, and CNAME records also at the bottom. In this video, we’ll go through each of these different record types so that you’ll be familiar with why we would add that information into our DNS server config.

My DNS server doesn’t provide me with a way to look at the raw text configuration file, but there is a web based front end that I can view. So this is the same information, but it’s from a web front end for my DNS server. From this web based front end, I can add new records, I can modify the records that are already here, or make any changes that I need to in my DNS configuration.

One of the most common records in a DNS server is an A record. You might also see these as a quad A record or AAAA record. These are records that define the IP address for a particular hostname. If you’re adding or modifying an A record, that address record is used for IP version 4 addresses. If you’re modifying a quad A record, that record is being used for IP version 6 addresses.

To be able to see what this might look like in a configuration file, I have a record here for my web server, www.professormesser.com. This is an internet address or IP version 4 address, and the A specifies that this is an address record. And the other part of this record shows it to be 162.159.246.164. That is the IP address that I would like returned to an end user if they requested for www.professormesser.com. So if someone sends a request to a DNS server and asks what’s the IP address of www.professormesser.com, this record is accessed, and it provides the answer of 162.159.246.164.

If you’re not editing a DNS server’s text based configuration file, then you might be adding a record through the web based front end like I do. I’m adding an A record. The name of the host is www. The IP address is 162.159.246.164. And the time to live, which is how long someone will remember this IP address, is set to 15 minutes.

After 15 minutes, this record will time out from a user’s workstation, and they will need to rerequest that IP address to continue communicating to www.professormesser.com. This allows me to make changes to this IP address at any time, and I know that all of those changes will eventually be rolled out across the internet in no more than 15 minutes.

The process for adding a quad A record is very similar. We specify a quad A record, the name of the device, the IP version 6 address that we’d like to use, and the time to live that we would associated with that record.

There may be times when a particular server is referenced using different names. For example, you might have one server that’s used as a web server. That might also be your DNS server. It might also be an NTP server, and it also might be a mail server. But instead of referencing that server with a single name, we can use different names to associate the different resources.

For example, if you have a server called mail.example.com, you might also want to use canonical names or C names for that server for chat, FTP, and www. This means every time somebody references chat.example.com, ftp.example.com, or www.example.com, they are all really communicating to a single server called mail.example.com. This makes it very easy to administer if you ever need to change the IP address of mail.example.com. You simply change the A record for mail.example.com, and all of the canonical records can stay exactly the same.

One of the most critical records on any DNS server has got to be the MX records. This stands for the mail exchanger records, and these make sure that you’re able to both send and receive email messages from your domain. The MX record itself is relatively straightforward. It starts with an IN for the internet. MX stands for the mail exchanger record, and then you simply have the name of the mail server. In this case, it’s mail.example.com.

When other mail servers need to send an email message to james@professormesser.com, they reference my mail server to see where the MX record is, determine the name of the mail server, then perform another lookup to determine the address record for that mail server. And now they know exactly what IP address they should be sending that email to.

In this particular case, that remote email server would reference our DNS. They would see that there is an MX record specifying mail.example.com. Then they would look at the address records and see that mail.example.com is 123.12.41.41.

Each domain has its own set of MX records. Here’s another MX record I use for a different domain name. This is one that I use through this web based front end. The name of the host is mail and the target name is mail.hover.com.cust.hostedemail.com. By using this front end, I’m able to make changes to that MX record to be able to send mail exactly where I need it to go.

If you’re configuring your MX record through a web based front end, then it’s the same editing process we’ve already used, where we would choose the name of the record, specify the host name, the target name, and the time to live.

So far, we’ve talked a lot about IP addresses, fully qualified domain names, and the resolution between those two in our DNS server. But we can also use our DNS server to store important information that we would like others to be able to access. We refer to these records as text records or TXT records. These are human readable text records that anyone could reference from our DNS server, and we’ll look at an example of those in just a moment.

Sometimes you’ll see these DNS records being used for verification. Often you’ll be configuring an email setting, and the email configuration needs to ensure that you have control of your DNS server. And to be able to verify that, you add a special text record into your DNS that they can then access from their site. And there are a number of text records that we use to minimize the instance of spam. And we’ll talk more about those specific text messages as well.

If you wanted to view the text records available on my DNS server, you can use the dig command with a dig professormesser.com and then specify TXT. It will then show you all of the different text messages that are currently configured on my DNS server.

In this example, there are two text records that appear, one for a stripe verification and another one that’s being used as an SPF record. And we’ll look more at SPF records in just a moment.

You can also use the nslookup command to view these text records. Let’s look at all of the text records associated with the Google DNS. We would use nslookup -type=txt and then google.com. All of the results that you see here are the text records associated with the google.com domain name.

I mentioned earlier that we often use these text records to be able to minimize the amount of spam that someone might receive, or to be able to verify that the email messages that have been sent really did come from your domain. One of the ways we do this is with a DKIM record, a Domain Keys Identified Mail record. If you were to look at the text records on a DNS server, you may see one text record that specifies v=DKIM. That is a Domain Keys Identified Mail record.

In the DNS server itself, you’ll find a public key associated with this record. On your email server is the associated private key of this key pair. All of the outgoing messages from the Professor Messer website are digitally signed with my private key. When another mail server receives an email that I have sent, it sees that that message has been digitally signed. It then can refer to my public DNS server to retrieve the public key, and then verify that the digital signature is indeed valid. This means the recipient knows that that message really was sent from my official email server.

If you were to look at the configuration on a web based front end, it looks very similar with the text based hostname, which is usually provided by your email server. And then you can find the actual content, which is the public key that you would put into that message. This can also be configured from a web based front end by adding the DKIM parameters as the host name, and then in the text part of the field, you would add the public key as that structured content. And in this case, I’m specifying a 15 minute time to live.

It’s very common for an organization to send email from many different resources. There might be a private internal email server that’s being used for outgoing mail. There might also be a third party that’s used to send bulk email messages, perhaps once a day or once a week. And there needs to be a way that everyone can trust that all of those different email servers are legitimate and have been configured specifically to send messages on my behalf.

The way that we would provide that information is through a text record that contains Sender Policy Framework or SPF information. This SPF record allows us to put all of the email servers that we use. This means if your email server receives a message from professormesser.com, it can look at that message to see what the origination server was, and then verify that that origination server is listed in our list of SPF allowed hosts. If you receive a message from professormesser.com and the origination email server is not in this list, then you’ve probably received a message from a third party that is not associated with our domain.

And adding a text record for SPF is very similar to adding any other type of text record. We would specify the record type as TXT. In the case of an SPF record, the hostname would be all hosts or the at sign, and the content is listed here with the appropriate outgoing email server name.

This means any email server that is receiving a message can perform a number of different checks for the validity of that message. It can perform an SPF check to confirm that it really did come from a trusted server, and it can check the digital signature using the public key located in the DKIM text record.

But what if one or both of these tests is invalid? What if this message did not originate from a trusted email server for that domain? And what if it did not have a valid digital signature? In that case, the receiver of that email message needs to make a decision on what to do with that email. Is this email thrown out completely? Is the email allowed to continue through to the end user? Or is it placed in a spam or quarantine folder by default?

It would be nice if I could tell the receiving server that if you receive any messages from me that don’t validate with a proper mail server, or they don’t validate with a proper digital signature, that those mail messages should be dropped and not sent to the user. Or I might have a different policy that says, don’t remove that particular email message, but send it into the spam folder and let the user make a decision on whether that is a legitimate email or not.

The way that we’re able to let that recipient of the email message know our policy is through the use of a DMARC or Domain Based Message Authentication Reporting and Conformance record. This is a text record that allows us, the domain owner, to determine what happens with messages that are identified as spam, but have our domain associated with them. Third parties can look at this record on our DNS server and see that we would either like to allow all messages to be accepted, send those messages to a spam folder, or simply reject the email completely.

We can also include an email address with that DMARC record, so that the disposition of that particular message is sent to a central reporting tool. That means that we can create a report showing how many of our email messages got through, and how many email messages were identified as spam.

Here’s an example of a text record that contains the DMARC information. In this particular case, we’re telling anyone that receives a message that did not validate properly to put that message into their quarantine folder or spam folder, and take the results of that particular disposition and send it to the email address listed here to be able to compile it into a larger report later on.