This article is part three in a series dedicated to the DNS Management; DNS Record Types Explained. We recommend you read the first two entries in this series, Registrars and Nameservers and Zones, Record Types, and Record Composition before continuing with this article.
In this article, we’re discussing a few of the more commonly used record types and when you might use them.
A Records are the most basic type of DNS record and are used to point a domain or subdomain to an IP address. Assigning a value to an A record is as simple as providing your DNS management panel with an IP address to where the domain or subdomain should point and a TTL.
The screenshot above is a sample of A Record listings of different types. You can see that the wildcard ( * ), @ symbol, and named hostname entries were used. Here, the primary naked domain record (@) and blog subdomain point at the same IP address, but are separate records and can be changed individually at any time. A Records are only able to take an IP address as their value and you can point the same domain/subdomain to multiple IP addresses by adding another A Record with the same name but with a different IP address for the value.
You’ll want to use an A Record for your DNS entry if you have an IP address that the domain/subdomain should point to or if you want to establish a domain/subdomain to be used as the place to point a CNAME. You can find out more about why you might want to do this in the CNAME portion of this article.
CNAME records are another commonly used type of DNS entry and are used to point a domain or subdomain to another hostname.
In the screenshot above, you can see immediately that one of the important differences from A Records is that the value portion of the record is required to be an existing subdomain/domain. You can see that the “journal” hostname points to my blog.iamrobertv.com A Record, which points to 18.104.22.168. What this means is that, if the value of the blog’s subdomain is ever changed, the journal subdomain’s value will also be changed.
As a host, we can use CNAMEs for customers as a means of being able to change the IP address of a server or cluster of servers transparently and without users having to make their own DNS adjustments. You can see an example of this in the store hostname that points to a cluster of servers that sit behind the thor.openhostingservice.com subdomain. Finally, you can see the use of the @ symbol to indicate that the www hostname should point to the naked domain and use its value, which when you see the A Record sample image above, points to 22.214.171.124. This also means that, if the value of the naked/primary domain changes, the record of www will end up being affected accordingly.
Mail Exchanger (MX) records are used to help route email according to the domain owners’ preference. The MX record itself specifies which server(s) to attempt to use to deliver mail to when this type of request is made to the domain. They differ from A Records and CNAMEs in the way that they also require a “priority” value as a part of their entry. The priority number is used to indicate which of the servers listed as MX records it should attempt to use first.
In the screenshot above, you can see that I am using two MX records that have separate priority values and point to different subdomains. These subdomains are pointed at two different email servers that are designated to handle email. The MX record with the lower priority number (“0” in this case) is the first to be tried for email delivery. If this server is unable to handle the mail request, the next lowest priority number is used, which in this case would be 10.
Some email providers have only one MX record and some have well over two. The number of MX entries you will need to create depends largely on the mail provider and how they expect the load on these email servers to be handled.
You’ll notice the hostname here is designated as the naked/primary form ( @ ). If you wanted to receive mail on a subdomain, you would adjust the hostname accordingly and ensure your email provider is set up to handle email from the subdomain.
A TXT record is used to store any text-based information that can be grabbed when necessary. We most commonly see TXT records used to hold SPF data and verify domain ownership.
The screenshot above gives an example of how a TXT value would be formed for both an SPF entry or an ownership verification for the naked/primary host/name using the @ symbol. If you need to verify or provide an SPF record for a specific subdomain, then you will need to use the appropriate hostname in place of the @ symbol. The rule of thumb for TXT records is that they require an attribute name, followed by an equals sign, followed by a value for the attribute. You can use this to relay any sort of information you’d like using a DNS record, so long as you have a purpose for it, and the record is properly formatted.
We won’t go into the details of properly formed SPF records and what their different pieces mean, but these will commonly be supplied to you by the mail provider you are working with. In the same way, places that require domain verification through the use of a TXT record will also provide you with a properly formatted TXT record value to use.
Managing your own DNS can be a tricky endeavor, especially if you haven’t ever considered what this means or ever even seen a DNS record. Ideally, this series of articles will help you understand the general how a website’s DNS works for a domain from the time it is typed into the browser to the time your name servers handle the request. Although it can be rather easy to understand the record types themselves, knowing about nameservers, registrars, and how a specific set of DNS records gets chosen and used is a little more difficult to navigate, but is just as essential to know.