Domain Name System (DNS)
The Domain Name System, or DNS, acts like the internet’s phonebook. It translates human-readable domain names into IP addresses. Humans are not good at remembering strings of numbers like IP addresses, and to make things worse, these IP addresses can change, either manually or dynamically.
To understand how DNS works, consider a user trying to resolve a DNS name like google.com. For humans, a DNS name like google.com is easy to remember, but not the IP address. The request is sent to a DNS server.
The DNS server will return the IP addresses for google.com to the user. This process is fundamental to online navigation to ensure the vast network of the internet remains accessible and user-friendly. DNS needs to be simple to use and capable of distributing across the internet with redundancy in mind. Thus, there are a lot of moving parts. Let’s have a closer look at what makes it work.
Fully Qualified Domain Name (FQDN)
DNS uses Fully Qualified Domain Names (FQDN). It works like this: at the very top is the top-level domain. This is the right most part of a domain name, for example, com or org. The next level is the domain name. These can be registered by someone, so effectively, it is theirs for a period of time. For example, registering the domain names ITFreeTraining and HighCostTraining.
Registering domain names like these means that the person who registered them can add hosts to the domain name or even subdomains if they wish. For example, a mail server could be added to both domains.
In DNS, using Fully Qualified Domain Names, it is impossible to have a duplicate FQDN. Although the host names are the same in both domains, the FQDN in each domain is different.
Having a hierarchical system like this allows DNS to have central management with decentralized control. DNS also supports redundancy and load balancing. Let’s break down the DNS hierarchy so we can better understand how it works.
Root Name Servers
To better understand how DNS works, let’s consider the process that a DNS server first uses to resolve a fully qualified domain name. At the top of the DNS hierarchy are the root name servers. There are currently 13 root name servers on the internet, often referred to as root servers or dot. While often referred to as “servers” for simplicity, each named root server in the Domain Name System is not a single physical machine. Instead, it’s a geographically distributed cluster of redundant servers working together as a single logical entity.
All FQDNs end with a dot. You may never have been aware of this because software automatically adds it, so you don’t need to worry about it. Technically speaking, an FQDN gets resolved from right to left. So, for the domain name example.com, we would start from the very right, which is the dot.
To resolve the dot, the DNS server has statically configured the DNS root name servers, which contain the IP addresses for IPv4 and IPv6 of all 13 logical root DNS servers. In reality, there are hundreds of physical DNS servers all around the world. The limit is 13 because this was a limitation of the older DNS standard.
Although it is possible for the IP addresses of the root name servers to change, this happens very rarely. Depending on the implementation of the DNS server, it will choose a root name server from the list and attempt to contact it. This may be done completely randomly or based on other factors like physical location and response times of the name server. You don’t need to worry about keeping the root name server list up to date; this will be automatically updated when you update the DNS server.
Top-Level Domains (TLDs)
The next highest level is the Top-Level Domains or TLDs. Going from right to left, they are the next part of the FQDN. For example, .com, .net, and .gov. This also includes country codes, for example, .uk.
To better understand the process, let’s consider a DNS server trying to resolve example.com. To start with, it will contact one of the root name servers. In this case, let’s consider it has contacted root name server e. If the response were to timeout, the DNS server would try another root name server.
In this example, the root name server returns a list of DNS servers for .com. The DNS server will cache this list; thus, it does not need to contact the root name server each time. Once it has a list of DNS servers for .com, it will contact one of them.
The request will be for a DNS server that holds records for example.com. The DNS server will then respond back with a DNS server for example.com if it knows it. If it does not know it, it will respond back accordingly. If the DNS server does not get a response back or gets a negative response, it may try another DNS server.
In the real world, it is not uncommon for the Top-Level Domains for common domains like .com to also be on the root name server. When this occurs, the same process is still followed. That is, the root name server will receive the request for .com and then receive a second request for example.com.
Now that we know all this theory, let’s have a look at how we can apply it.
Registering a Domain Name
For the A+ exam, you won’t need to know how to register a domain name. Looking at the process will help you understand the DNS hierarchy. I think this will give you a better understanding of how DNS works.
To register the domain name, I will use Cloudflare. There are many companies out there that you can register domain names with. Regardless of which one you use, the process is much the same; only the interface changes.
To start with, I will select the option to add a site. Most domain registrars will also offer hosting and email services. Thus, you will find that the registration process may also be linked to creating a web host and other services. The advantage of this is that the associated DNS records will be automatically created for you. In this case, I will only be using Cloudflare to register a domain name.
Since I don’t want to create a website, I will select the option at the bottom, “register a new domain.” I need to enter a domain name to register, so I will enter ITFreeTraining. This domain name is not available, but you will notice some alternative domain names that are available have been shown.
In this example, I will select the second option. To register it, I just need to press the “Purchase” button. If the domain is available, the next screen will allow you to select a time period to register the domain. Once this time period expires, the domain becomes available for others to register.
Different domains will cost different amounts. .com domains tend to be relatively inexpensive. Other domains can vary in price. There can also be significant differences in prices. Some domain registrars charge quite a lot of money compared with others. Some will offer cheaper prices, but you will need to purchase a hosting package to get the low price.
You will need to fill in all the details, including registration details and credit card details for the payment. In the case of Cloudflare, your details won’t be publicly available. However, with other DNS registrars, they will be made available unless you pay an extra fee to have them removed from being publicly available. Keep this in mind, as one of the questions is a contact phone number. If the phone number is made publicly available, be prepared to receive a lot of spam phone calls from people who want to sell you web products.
I will now press “Complete purchase” to finish the domain registration. The process should not take too long to complete. Once complete, I will have use of the domain for the next year. As long as I continue to re-new is before it expires, no-one else will be able to register it.
Name Servers
To better understand how DNS works, I am going to use a free tool to look at the DNS records that have been created. The tool is MX Tool Box. You will notice that there are a lot of different queries the tool can perform. When trying to find out more information or troubleshooting DNS-related issues, tools like this can be very useful.
In this case, I will select the option “Whois Lookup.” I will perform the query for the domain I just registered. This query provides registrant contact information, name servers, contact information, and domain status for the domain.
Notice at the top who is currently the registrar of the domain name, in this example, Cloudflare. This is the registrar that currently holds the domain name and can make changes to it. Domain registrars provide an intermediary between the registrant of the domain name and the DNS. It is the part of DNS that allows it to be distributed.
To do this, name servers are used. You can see in this example there are two name servers listed. It is also possible to use more, but there needs to be a minimum of two. When dealing with DNS, there is often a requirement to have two for basic redundancy.
When I scroll down, notice that contact and other information has been redacted. Cloudflare does this automatically, but with other DNS registrars, you may need to pay an additional fee for this to occur. When registering domain names, I would keep this in mind. I would personally, after registering a domain name, perform this basic check to see what information is publicly available. Let’s have a closer look at what has occurred.
DNS works as a hierarchy. At the top are the root name servers. The root name servers keep a list of DNS servers that can resolve the next part of the domain name. In this example, the next part is .com. Thus, the root name servers provide a list of .com DNS servers, otherwise known as Top-Level domain servers.
The Top-Level domain servers contain the name server records. In this example, they contain the two DNS records pointing to the Cloudflare DNS servers. The top-level domain servers also contain the start of authority or SOA record. The SOA records contain the contact information and other configuration details for the domain. Modern registrars will automatically configure the SOA and name server records as required.
DNS also allows DNS records to be created, which can be used to point to services. In order to do this, DNS records are stored on the Cloudflare DNS servers. These DNS servers are known as authoritative DNS servers. Let’s have a look at what that means.
Authoritative DNS Servers
Authoritative DNS servers are responsible for containing and providing authoritative DNS records for specific domains. These servers have the final say over the DNS records for the domains they manage.
In the realm of DNS records, an authoritative DNS server has the final say. It stands as the undisputed source of truth. The authoritative DNS server holds a unique position of trust, acting as the gatekeeper of information, and other servers rely on its accuracy without question. This underscores the importance of meticulous configuration, as any errors in the DNS server can ripple across the internet.
The way this works is that non-authoritative DNS servers will use cached records from an authoritative DNS server for the time to live or TTL. The TTL is measured in seconds. Essentially, the authoritative DNS server has the authoritative DNS record. The non-authoritative DNS server will request this record from the authoritative DNS server and use it until the TTL expires.
You can start to understand why DNS record changes can take a long time to take effect. If the TTL is quite high, it needs to expire before the cached version of the DNS record will be updated. Before I look at how to create some DNS records, I will first look at what DNS records can be created.
DNS Records
There are over 70 official DNS records, but only a few are commonly used. Later in the video, I will show you how to create the commonly used DNS records. The most commonly used DNS records are the A record and Quad A records. An A record maps an IPv4 address to a hostname. The Quad A records do the same thing, however, they work with IPv6 addresses.
Other commonly used DNS records include the Mail Exchanger record, or MX record. A Mail Exchange or MX record is used to identify an email server for the domain so that other servers can send messages to it. In a typical network, multiple servers are installed to provide redundancy, and each one will be represented by an MX record. Each MX record is given a preference value, with the lowest numbered entry preferred. The hostname identified in an MX record must have an associated A or Quad A record.
A TXT record was originally created to store human-readable text. Nowadays, the text in these records is used by many different services, for example, for authenticating ownership and securing email.
The last DNS record I will look at is the canonical name or CNAME record. This DNS record is not covered in the CompTIA study guide, but I think it is important to know because it is used quite often. The CNAME record essentially points to an address record, effectively creating an alias record. For example, you could create a CNAME record called mail that points to server1. If you move mail to server2, you would change the CNAME record to point to server2. The clients on the network would still use the hostname mail and would not need to change even though the mail server has changed.
I will look at how to create DNS records soon, but before I do that, I need to look at DNS zones.
DNS Zone
A DNS zone is a collection of DNS records that belong to a domain. Thus, when I registered the domain name with Cloudflare, there needs to be a location to store the DNS zone. Let’s consider what has occurred so far. Cloudflare registered the domain name with the Internet Assigned Numbers Authority or IANA. We cannot register a domain name with IANA directly and require a service provider to do that on our behalf. When I registered the domain name, the name servers were automatically pointed towards Cloudflare. Thus, the DNS zone currently being used by the domain name is the one hosted by Cloudflare.
So, the question I have for you is: does the DNS zone need to be stored on the same service provider that registered the domain name for us? The answer is no. Cloudflare, at a minimum, needs to give us access to the name server records. Thus, we can always change the name servers to point to a different DNS solution; any DNS servers can be used. This could be another hosting company or your company’s private DNS servers. If you do use your own company DNS servers, which is quite common, you need to make sure that you have at least two DNS servers that are publicly accessible to the internet.
The point to take away here is that as long as I keep making my payments to Cloudflare for the domain, I can keep using it. Cloudflare passes part of that payment to IANA. The payment to IANA is used to keep the infrastructure working that effectively runs the internet. If I decide that I want to use a different registrar for my domain, I can always transfer the domain to a different registrar. Usually, when you do this, the new registrar will want you to pay for another year of registration at a minimum or purchase any package as part of the deal.
I will now have a look at how I can create DNS records for my newly registered domain.
Creating DNS Records Demonstration
For the domain name that I just registered, there are currently no DNS records. While the A+ exam may not explicitly focus on creating them from scratch, understanding how to identify and rectify errors within existing records is crucial. You may be presented with scenarios involving incorrect DNS records, requiring you to identify problems or make changes. So, it is important to understand how each DNS record works.
Since I registered the domain name with Cloudflare and the name servers are currently pointing to Cloudflare, I need to make DNS record changes on Cloudflare. If I change the name servers to point to a different DNS server, I need to make the changes to the DNS server that the name servers are pointing to.
To make changes to the DNS records, I need to select the option on the left-hand side, DNS, and then select records. When I scroll down, you will notice there are no DNS records currently created. If you purchased services with the domain registration, the registrar will most likely automatically create DNS records for the services that you purchased with the domain name.
To create a new DNS record, I will select the option on the far right-hand side, “Add record.” To start with, I will create an A record, which is the default option. I will next add the IPv4 address I want to use for this A record. In this case, the IP address is the IP address of my web server; thus, when the domain name is resolved, it will go to my web server.
In this case, I want this A record to point to just the domain name. Different interfaces will do it differently. In this interface, I can add the domain name into the name section, or I can use an @ symbol. In some interfaces, you can leave this option blank if you are referring to just the domain name.
Cloudflare has an option where DNS queries can be proxied. This works only for address records. When this option is enabled, the Cloudflare DNS server will respond to the query rather than going to the DNS server that is configured. Since Cloudflare has DNS servers all over the world, this decreases the response time and also helps against denial of service attacks. It also acts as a man in the middle and thus hide the IP address of your web server. This feature is not available on most domain name registrars, so I will switch it off.
Before I save the DNS record, notice there is an option where I can add a comment. This allows you to add any comment you wish. This comment is for administrative purposes only and does not affect the DNS record. Not all interfaces will have the option to add a comment.
I will press save, and the DNS record will be created. I will next press “Add record” to add the IPv6 address. To create an IPv6 address, I need to select the Quad A record from the pull-down menu.
For the name, I will enter the domain name since I want this IPv6 address to be returned when the domain name is resolved for IPv6 addresses. Next, I will enter the IPv6 address. When the IPv6 address is requested for this domain name, this IPv6 address will be returned.
Like before, I will switch the proxy option off. I will press save to create the DNS record. I now have an A record and Quad A record configured to the IP addresses of my web server. Thus, if this domain name is opened in a web browser, it will resolve to these IP addresses and go to my web server.
I will now press “Add record” to create another DNS record. I will attempt to create a mail exchange or MX record. It will be an attempt because, as we will see, it won’t work. For the name, I have entered the @ symbol, thus it will be created as the mail record for the domain. For the mail server, I have entered the IP address. However, as we will see, this will not work.
For mail exchanger records, I need to enter a priority. In this case, I will enter 10. Low priority records will be tried first. If there are multiple MX records with the same priority, the sending email will spread the emails over the available mail servers.
When I press the save button, notice that I get an error message. For MX records, an IP address can’t be used. Either an address record or CNAME record needs to be used. I will press “Add record” to reset the add record process.
I will add a new A record for mail1 and enter an IP address. The host name will automatically be appended to my domain name. I will switch the proxy setting off. Notice there is an option for TTL. This is Time to Live. So far, I have been leaving this on the default setting.
TTL will determine when a cached version of the DNS record will expire. If the IP address associated with the DNS record changes frequently, you may want to set the TTL lower. For example, for services like failover content delivery and edge servers, you may want a low TTL. Having a lower TTL allows fast changes if the infrastructure behind it changes and allows for better load balancing by distributing the load more efficiently.
If you are performing a server migration, you may want to set this value low before starting the migration. This allows changes to take effect faster, and if something goes wrong, you can change it back to the original setting, and the DNS will revert back faster.
In this case, I will set the TTL to 1 hour. My plan is to install a new mail server that will replace this one later on. So, I will set the TTL low. Once I have my new mail server running, I will change the DNS record to the IP address of the new server. Once I have tested the new server and it is stable, I will set the TTL back to auto.
I will now press save to create the A record for the mail server. Next, I will create a second A record for a second mail server. Once I have entered the details, I will press save to create the DNS record.
I will now create a mail exchanger record by selecting MX from the list. For the name, I will enter @ since it will be a mail record for the domain. For the mail server, I will enter the address of mail1. The address needs to be a fully qualified domain name. If you only put the hostname, it will not work.
I will next enter a priority of 10. You are free to use whatever values you wish for priority; however, the DNS record with the lowest priority will be tried first. I will now press save to create the record.
I will now create a second MX record. The second MX record will point to the second mail server. For this MX record, I will set the priority to 20. If the first mail server fails or is not contactable, the mail server with the next highest priority will be tried.
I will now save the record, and it will be created. I will create one last DNS record; this is for Canonical Name or CNAME. This is effectively an alias record that points to another DNS record.
For this record, I will enter w w w followed by the FQDN for the A record I created for the domain name earlier. A DNS name starting with w w w followed by my domain name will now resolve to the A record I created for the domain name earlier, which points to my web server.
When you have servers that hold multiple services, it is not uncommon to use CNAMEs. For example, if the server also had FTP installed, I could create a CNAME for FTP.
I will switch off the proxy and save the record. Cloudflare only proxies address records and CNAME records. I will now save the record.
You can see all the DNS records that I have created. It does not take too many services before you start getting a few DNS records.
Name Resolution Example
Let’s look at an example of how name resolution works. A device on the network is attempting to resolve the DNS name www.it-free-training.com. To do this, the request is sent to a DNS server. Your network may be different. Generally, if a DNS server is not configured to resolve a request, it will forward it to a DNS server that can. For example, the ISP’s DNS servers.
The DNS server won’t be able to answer the request unless it is an authoritative DNS server or the DNS server has the record in its cache. The DNS server will perform a recursive DNS query. A recursive DNS query is one that traverses the DNS hierarchy until it finds a DNS server that can determine if the request can be answered or not.
Assuming there are no records in the DNS cache, the next step is for the DNS server to contact a root name server. The root name server is not authoritative for the domain name, so it will return a list of Top-Level domain servers to the DNS server trying to resolve the request.
Since the DNS server is using a recursive request, it will use the newly obtained top-level domain information to contact a top-level domain server. The top-level domain server will return the authoritative DNS server, in this case, the Cloudflare DNS servers.
The DNS server will then contact the authoritative DNS servers which are also currently stored at Cloudflare. However, they could be moved elsewhere if required. Since the Cloudflare servers are authoritative servers and hold the DNS zone for the domain, the DNS server will return the DNS record.
The DNS server will put the record in its cache and return it to the client. The client will now have the DNS record. Regardless of which type of DNS record is being requested, the process is the same. Keep in mind that DNS servers will utilize caching to speed up the process. Not every request requires a query to the root name servers or the top-level domain servers. Once the DNS servers have cached the records, they will keep using them until they expire.
Common Text Records
I will next look at the Sender Policy Framework or SPF and DomainKeys Identified Mail or DKIM records. Both of these records are text records that are added to the domain. Shown here is an example of an SPF record and an example of a DKIM record.
It is not that important to understand the format of these text records, as they are generally provided by your email administrator or domain registrar. If your email is hosted by your service provider, they may have already been created for you. Otherwise, you may need to create the text DNS records yourself, which will often involve copying and pasting the required data.
Let’s have a look at what they both do. Let’s consider that a user sends an email to their email server. The email will then be forwarded to the receiving email server either directly or forwarded through other email servers until it reaches its destination.
The receiving server needs to authenticate the email’s origin before deeming it trustworthy. Even if the email seems to come from a reputable source, spammers can cleverly set up their own email servers and disguise their messages as legitimate ones from your domain.
To authenticate the sending email server, the receiving email server will request the SPF information for that domain name. This will contain the addresses of the email servers that are authorized to send emails from that domain name. If the sending email server does not appear on that list, the email will be rejected. Thus, SPF works to ensure only authorized email servers can send email for that domain.
DKIM works on the email level. It does this by signing the email with a digital signature. The digital signature is sent with the email to the receiving email server. The email server will use the DKIM record to verify the email. DKIM thus adds a way to check the contents of the email to ensure they come from a trusted source and have not been modified.
If you were to get an exam question on this, it would probably test your basic knowledge of each. So, remember that SPF tests the sending email server, and DKIM uses digital signatures to verify emails.
DMARC
The last topic I will look at is Domain-Based Message Authentication Reporting and Conformance or DMARC. This is quite a mouthful, so let’s just look at what it does. Consider a user sending an email to their sending email server. The email is sent to the receiving email server.
SPF is run to check that the email came from an authorized email server. DKIM is run to check the digital signature on the email. So far, everything is running as expected.
DMARC provides a framework that uses SPF and DKIM, essentially configured using another DNS text record. DMARC configures what should happen with SPF and DKIM. For example, should the email be rejected, accepted, or quarantined? Configuration can be done based on SPF passing or failing. It can also be done based on DKIM passing or failing. Or you could do a combination of both.
DMARC can also be used by all email servers, including for statistical reports. This means that any email servers that support DMARC can use your configuration to decide what to do with the email. For example, if the email is being forwarded by an email server before it reaches your email server, the email server can check the SPF and DKIM and reject the email before it even gets to you. If an intermediate email server rejects the email, you will never even know that it was rejected. Thus, DMARC can be configured so that the intermediate email server that rejects the email will send you a report telling you it was rejected. This can help you gather statistics on how many spam or other unauthorized emails have been sent to your domain name.
The main point to remember is DMARC configures what to do when emails fail SPF and DKIM, plus provides mechanisms for reporting these failures.
End Screen
That concludes this video from ITFreeTraining on DNS. I hope this video has been informative. Until the next video, I would like to thank you for watching.
References
“The Official CompTIA A+ Core Study Guide (Exam 220-1101)” pages 191 to 194
“Picture: Cloudflare logo” https://en.wikipedia.org/wiki/Cloudflare#/media/File:Cloudflare_Logo.svg
“Picture: IANA logo” https://en.wikipedia.org/wiki/File:Internet_Assigned_Numbers_Authority_logo.svg
Credits
Trainer: Austin Mason http://ITFreeTraining.com
Voice Talent: HP Lewis http://hplewis.com
Quality Assurance: Brett Batson http://www.pbb-proofreading.uk
