The following is a list of some of the most common or most used kinds of DNS Records out there. Nowadays there are around 40 active types of records in the DNS system (and around 35 are not used anymore), but only the main ones will be listed here.
Table of Contents
Type of DNS records
There are many different types of DNS records out there, the most common ones are A, NS, MX, TXT, SOA, and CNAME, however, there are others who are very important for our daily tasks as systems administrators or DevOps engineers. In this video, we will show you the basic DNS records
However, if you want to learn the deep insights of each one, keep reading:
the A records are used to point a domain or subdomain to a certain IPv4 address. For example, if you point mydomain.com to IP 22.214.171.124, then this domain will be mapped to server 126.96.36.199.
The A record is probably the most used type of DNS record in the world. Its main function is to point a domain or a subdomain to a particular IP address. In other words, thanks to the A records you are capable of reaching a website on the Internet, and without them, we would be completely unable to do 99% of the stuff we do on the Internet nowadays.
And why “A” record? The “A” actually stands for Address, because like we said, this kind of records helps you (or rather, your computer) find the correct server when you try to access a website. If you have a site called “mydomain.com” and its A record points to 188.8.131.52.1, it means that when someone makes a request to mydomain.com it will be directed to the server which has assigned the IP address 184.108.40.206.1.
The A records have a pretty simple format and are also very easy to use and configure. Let’s see an example of an A record:
mydomain.com. 14400 IN A 220.127.116.11
First, we have our domain (or subdomain), which in the example is mydomain.com, but it could be any other domain or even a subdomain like example.domain2.com, etc.
Then we have the TTL (Time to live), it’s usually set at 14400 and determines how many seconds are required for our record to go completely into effect. Usually, a TTL of 14400 is ok, but you can use a lower one if you want, for example, 1800 or 3600.
After that comes the IN class, then the “A” record type.
And last but not least we have the address, i.e. the IP to which our A record should point to. So if you want to mydomain.com to map to server 18.104.22.168, then “22.214.171.124” is the value you must set here.
MX records are very important for the proper function of the email systems. The name of this type of record comes from Mail eXchanger or MX. If this record is not properly set, then our email could end up not working at all or simply working in unexpected ways.
By using an MX record, we can tell which mail server is responsible for accepting the emails that our domain will receive. It’s even possible to set more than one MX record, with different priority, to tell which server should receive the email in case another one is not available at the moment.
A very common example of multiple MX records is the default configuration requested by services like G Suite, which in order to properly work requires the user to set a few different MX records. Nowadays, the configuration is the following:
mydomain.com. 3600 MX 1 ASPMX.L.GOOGLE.COM mydomain.com. 3600 MX 5 ALT1.ASPMX.L.GOOGLE.COM mydomain.com. 3600 MX 5 ALT2.ASPMX.L.GOOGLE.COM mydomain.com. 3600 MX 10 ALT3.ASPMX.L.GOOGLE.COM mydomain.com. 3600 MX 10 ALT4.ASPMX.L.GOOGLE.COM
As we can see, in this example we have a total of 5 MX records for the domain “mydomain.com”, each of the pointing to a different server. The differences between them are in the priority and the destination value. First, we have our plain domain, like we said “mydomain.com” as an example. We then have a TTL, in this case, set at 3600 in the 5 examples, then comes the MX record, the priority (used to tell which server should receive the email first) and the email server hostname.
In the case of the priority, less is more, so in this example, the server “ASPMX.L.GOOGLE.COM” will receive the emails before “ALT1.ASPMX.L.GOOGLE.COM” and this one will get them before “ALT3.ASPMX.L.GOOGLE.COM”. In the case of records with the same priority, any of them may receive the email.
Remember that after you set your Google MX records it will take up to 4-8 hours for full DNS propagation.
CNAME records are among the most common types of DNS records out there. The acronym “CNAME” actually stands for canonical name, and like it suggest this kind of record is used create an alias between two different domains.
Let’s say that you have a website where you store different kinds of recorded data and you usually access it using mydata.mydomain.com. What if you also want to be able to access it using a different subdomain, for example, something like myshinydata.mydomain.com? In that case, you simply have to create a CNAME record which will point myshinydata.mydomain.com to mydata.mydomain.com. Once the new CNAME record is set, you will be able to view the content of mydata.mydomain.com through myshinydata.mydomain.com
For a CNAME record to work, first, we will need an A record for the alias domain. If we want, for example, to create a CNAME record for mydomain.com which points myotherdomain.com, then the following records will be used:
mydomain.com. 14400 IN A 126.96.36.199 myotherdomain.com. 14400 IN CNAME mydomain.com.
If there’s no A record, then the CNAME record won’t display anything when we access myotherdomain.com
As you can see, the format of a CNAME record is pretty simple, we must specify our domain/subdomain first with a dot in the end, then our TTL, after that the IN class, then comes the CNAME record and in the last position the domain/subdomain we want to point to, followed by a dot (.) in the end.
The dots at the end of the domain name are very important in most systems because if we don’t use them, the DNS will take the domain as a subdomain, so instead of subdomain.domain.com you will get subdomain.domain.com.domain.com. Some systems include the dot automatically, but if you are not sure about it is always better to type the dot on your own.
The name of the NS records comes from Name Server, and they are used to point our subdomains to certain name servers. Usually, when we point a domain using a DNS provider’s Name Servers, a few NS records are automatically set, which are used to tell which is the DNS system allowed to host the records of our domain.
This is an example of an NS record:
mydomain.com. 1800 IN NS ns1.domainprovider.com.
Let’s break it up and take a closer look:
First, of course, we have our domain, which as usual must have a dot at the end, or the DNS system may confuse with a subdomain and that could be a big mess, so make sure to always use the dot at the end of the domain name.
Later there’s the TTL, which is the time our record will take to fully propagate to all systems. The DNS systems use a lot of cached records, and when the TTL expires the record is checked again to verify if it changed.
The IN class is the most common class in the DNS systems, and then we have the type of record, in this case, NS.
In the last part is the value of the record, which in the example is “ns1.domainprovider.com.”, and once again, note the dote in the end. This is the part that tells us that “domainprovider.com” has authority over the records of our domain.
We must mention that is even possible to have customized NS records if the provider allows so, of course. For this to work, we will need two things: a pair of A records of the NS records and a pair of Name Servers created in the registrar’s control panel. Let’s see an example with “ns1.mydomain.com” and “ns2.mydomain.com”, in the DNS zone the following records are needed:
ns1 14400 IN A 188.8.131.52 ns2 14400 IN A 184.108.40.206
And in the registrar’s control panel, the same records must be created, that is “ns1” (ns1.mydomain.com) pointing to 220.127.116.11 and “ns2” (ns2.mydomain.com) pointing to 18.104.22.168.
The names of the record and the IPs may change based on each provider, but the format should be the same.
The TXT records have a different function, but all of them are used to display certain kinds of information or data. The TXT records are used to manage important records as SPF, DKIM, DMARC and more.
The SPF record, also known as Sender Policy Framework record, is one of the most important records regarding email services. Why is it so important? Because it will tell which hosts are authorized to send emails from a particular domain. If an SPF record is not properly set, chances are that your emails will be rejected by 90% of the receivers.
To define an SPF record we need to use a TXT record. Creating an SPF record is actually pretty simple, let’s look at an example first:
mydomain.com. 3600 IN TXT "v=spf1 a mx ip4:22.214.171.124 include:_spf.google.com ~all"
So, what does this mean exactly? As usual, we have first our domain, then the TTL, the IN class field, the TXT type and in the last part the SPF data. In this example, we are basically telling that the servers authorized to send emails from mydomain.com are 126.96.36.199 and _spf.google.com (this is used for services like G Suite for example). If you want to authorize another server to send email, just edit the SPF data like this:
"v=spf1 a mx ip4:188.8.131.52 ip4:184.108.40.206 include:_spf.google.com ~all"
In this case, the server 220.127.116.11 has been authorized to send emails from myshinydomain.com
Very often, third-party email services providers like Zoho, Google and so on will ask the user to set an include in the SPF record, which will let you use their services to send emails from your domain, even if your domain is hosted with another provider.
Keep in mind that there shouldn’t be more than one SPF record per domain. If you try to create more than one it could lead to an error in the DNS zone or it will create a conflict for other servers to detect which is the correct one. Also, years ago existed an SPF record type, but it’s been deprecated and nowadays a TXT record is recommended instead.
The DKIM record, aka DomainKeys Identified Mail, is a very popular authentication mechanism for email services. By using it, a company is making itself responsible for the emails that are sent from its domain, which allows for the emails to be correctly validated by the recipient server. The company will be often the direct source of the email, as an author, a server tasked with email delivery, or an intermediary service used to send the emails.
The DKIM records were born as a means to fight spam emails. For example, if a spam message uses a fake “From:” field, the recipient could think that the email received is coming from a valid source and proceed to open it. In this case, the user doesn’t have a way to know if the email is coming from the real source or not, and that is the DKIM record comes into play. Thanks to it, the recipient server can verify if the email is coming from the real source or from a fake one, and therefore reject it.
DKIM records are usually a TXT record, consisting of a subdomain like dkimexample._domainkey, the TTL, the IN class field and the data field, which usually is a bunch of numbers and letters that make no sense for the common eye but does make sense for the email servers. Let’s see an example to get a better idea:
dkimexample._domainkey.mydomain.com 3600 IN TXT "k=rsa; p=MNS8HFNinmdf7gsDGDS+MBJNiKMDSOud45X2MgmO8PQHHcGxoim7mI+FhgOiOS5WgBUpZsrMXnWIS+zrR1xLOS0xDf9suh+Tl4tViX15/ItB7+x8FGU7Z5XRK6OwwNcCTQ4OHCTk3WjzF5YU/KFx0riP/wsIDAQAB;"
Using the DKIM records is very important to be able to properly authenticate our emails. If you use third-party email services like G Suite, SendGrid and so on, they probably ask you to add a proper DKIM record if you don’t have one, and they will also provide you they data key for it, which as we have said need to be used in a TXT record. In some cases, instead of this, the provider may ask you to create a specific CNAME record to authenticate your emails.
The main objective of the DNS system is to map IP domains to IP addresses, on the other hand, PTR records work on the opposite way, it is used to map an IP address to a domain name. That’s why the PTR records are also known as rDNS (reverse DNS) records.
PTR records are used, in most cases, to implement a reverse DNS lookup for an IP, but they can also be used for other tasks, for example, to set up a DNS-SD.
SOA records are very important for DNS zones because they are used to specify authoritative data regarding the DNS zone of our domain, for example, its primary name server, the serial number of our domain and the email address of the administrator.
SOA stands for Start of Authority and every domain zone must have one to work properly. What does this record do exactly? Basically, it marks the point where a domain is delegated from the parent domain. Let’s explain this with an example.
Let’s say you point domain myshinydomain.com using the Name Servers of a hosting provider. On the domain’s DNS zone, the hosting provider has to set an SOA record (often set automatically). This is an authorization to use the DNS service.
The SOA record usually looks like this:
ns1.hosingprovider.com admin.hostingprovider.com 20180120 86400 7200 604800 300
And this is the meaning of each item:
- First, we have ns1.hosingprovider.com, which in the example is the primary Name Server.
- After that, we have admin.hostingprovider.com, which is the responsible party for the DNS service.
- Next we have a date stamp, in this case it would be 2018 – January – Day 20. This helps to keep track of the most recent change in the DNS zone.
- In the fourth place is the number of seconds before refreshing the DNS zone.
- Then there’s the number of seconds before retrying a refresh in case it fails.
- Next, we have the limit in seconds before a DNS zone is not authoritative anymore.
- And last but not least we have the negative TTL, which basically means how long a negative result must be considered like that before trying again.
As you can see, the SOA record is one of the most complex DNS records out there, but is also probably the most important one, because without it probably nothing will work on the DNS zone, or at least not work properly and as expected.
ALIAS record is a particular type of DNS record that is not available to any provider, so don’t be surprised if your provider doesn’t have it. This virtual record is very useful to point your domain to a certain hostname.
Let’s say that you want to point yourdomain.com to yourapp.shinydomain.com. For this kind of record, you can’t use an A record (because those use IPs) and you can’t use a CNAME record, so the ALIAS record comes into play. With it, you will be able to perfectly point a domain/subdomain to another domain/subdomain. To resolvers, it will look like your domain is simply pointing to the same IP of the pointed domain through an A record.
This kind of record, while looking simple, actually requires a complex setup to work. It can be configured, for example, using an Erlang DNS server, which is an open-source software. This kind of server allows the administrators to perform many customizations, thanks to which is possible to create custom records like the ALIAS. To make the ALIAS records work as expected, a resolver server is also required to point the A/AAAA records to the appropriate servers. The information provided by the resolver server is used by the Erlang server to point the domain/subdomain to the right address when a request is received. Of course, all of this happens in the blink of an eye, and the system is actually not that simple to setup, this is just the surface of it.
The CAA records, also known as Certification Authority Authorization records, are used to define which are the certificate authorities that can issue an SSL certificate for a domain.
Usually, most certificate authorities are allowed to issue SSL certificates for most domains, but in some special cases is possible to allow only a certain authority to do this for a particular domain. Using CAA records, the domain owner can specify which are the certificate authorities allowed to issue an SSL certificate for the domain.
This kind of record also works as a notification when someone tries to request an SSL certificate through a certificate authority that has not been allowed. If there is no CAA record, then any certificate authorities are allowed to issue an SSL certificate for a domain. If the CAA record exists, then only the certificate authorities that are listed in the record can issue the certificate.
The CAA record can specify the certificate policy for a whole domain or for particular hostnames. The CAA records apply for subdomains too, so if we have a CAA set for mydomain.com, it will also apply for example.mydomain.com or any other subdomain. Through the CAA records, we can also control the type of the certificate that can be used, for example, if it must be for a single-name or if it must be a wildcard SSL.
Let’s see a quick example, which specifies that only the certificate authority Let’s Encrypt is allowed it issue a certificate for mydomain.com:
mydomain.com. CAA 0 issue "letsencrypt.org"
And if we want to allow COMODO too, then we must set two records, one for each certificate authority.
mydomain.com. CAA 0 issue "letsencrypt.org" mydomain.com. CAA 0 issue "comodoca.com"
There are a lot more examples we could use of course, and like we said there are a few different configurations that can we set, for example, to allow issuing only single-name certificates or wildcard certificates. If we want Let’s Encrypt to be allowed to issue a wildcard SSL, the record would look like this:
mydomain.com. CAA 0 issuewild "letsencrypt.org"
The POOL record is a special type of record not available to all providers. What does this record do? By using this kind of record, you can create CNAME records for the same subdomain. That means that a subdomain can have more than one CNAME record and each request to your subdomain will point to one of these CNAME records.
This works like a Round Robin DNS setup because it will redirect your requests to different hosts. For example, you can set one record to a host in the UK and another one to a host in the US, or anywhere else. In case one of the nods stops responding or working, you can delete one of the POOL records and set another one, but of course, some of the requests will still be redirected to the failing node until the DNS cache is cleared, which usually doesn’t take long.
So, if you want to quickly add a few CNAME records for one subdomain and redirect the requests to each of the configured nodes, then the POOL records will be very useful for this task.
URL records are a special type of DNS records that are not available to all providers and/or control panels. The task of the URL record is to redirect a hostname to a specified URL, for which a redirector tool is used.
With this kind of special record, you can, for example, redirect your domain to the URL of another domain, and you won’t have to use A records or CNAME records. A common use of this record is to redirect the visitors of www.yourdomain.com to yourdomain.com, or you can also use it to redirect something.yourdomain.com to anotherdomain.com
Which is the secret behind this? It’s actually pretty simple: the URL records usually use an HTTP 301 redirection, the same type of redirection that is used by web servers like Apache and Nginx to permanently point a domain to another domain.
Like we said, URL records are a special type of record and not all providers will have them at your disposal. While others like MX records, A records, TXT records and so on are available everywhere, URL records are not.
In the case that your provider doesn’t have the URL records available, then you can use an A record to point your domain to a server and then configure a .htaccess file (or the equivalent of the web server) to set a 301 redirection.
By using the Service Resource Records (SRV) you can tell what services you want to offer for your domain or subdomain. SRV records are used often for protocols like XMPP, LDAP and SIP, and also for services like Office 365.
This kind of record is composed of the following items: a transport protocol, a symbolic name, a priority number, a weight number, a port number, and a target.
Here you can see two examples of SRV records:
_xmpp._tcp.mydomain.com. 3600 IN SRV 5 40 4070 example1.somedomain.com. _xmpp._tcp.mydomain.com. 3600 IN SRV 5 30 4070 anotherexample.somedomain.com.
Let’s see this in detail:
_xmpp is the symbolic name that we are using for the service. Keep in mind that this symbolic name must start with an underscore (_)
_tcp will be our transport protocol. Like the symbolic name, the transport protocol must start with an underscore too.
After that, we have the TTL, IN is the usual DNS class field and then we have the priority for our record, in this case, is 5 for both of them.
Our first record’s weight is 40, while the weight of our second record is 30. Values like priority and weight are used to encourage servers to use a certain record over the other. The target with the highest weight is used first.
Last but not least, we have the port number, which is 4070 in both records, and the targets, which are two generic examples. Keep in mind that the target always has to be a record with an A or AAAA address, using a CNAME won’t work.
As we have seen, the Domain Name System (DNS) can use the information provided by the SRV records to find the servers that we are using for specific services.
The following services are often used in conjunction with SRV records: CalDAV/CardDAV, DANE, DNS-SD, Kerberos, LDAP, IMPS, SIP, STUN, XMPP, etc.