DNS Records Explained (with Examples)
DNS makes the internet a lot easier for humans to navigate. DNS eliminates the need for us to know specific IP addresses like 126.96.36.199. If we know the more human-friendly domain name — Yahoo.com in this case — we can access the resources we want. That general IP address to name functionality is easy to comprehend.
However, there is a lot more going on once you dive into the nuts and bolts of DNS. A big part of understanding DNS is understanding DNS records. DNS records are effectively the instructions that make nameservers work. Understanding DNS records not only helps with various IT certifications, it's also useful in day-to-day systems administration tasks. Here, we'll look at eight common DNS records and explain what they do.
Using dig for Looking Up DNS records
Domain Information Groper (dig) is part of the Internet Systems Consortium's BIND suite of tools. Bind can be installed on *nix and Windows platforms and dig is a great tool for querying and troubleshooting DNS. Because of dig's popularity and utility, we recommend getting used to it early on in your DNS studies. To help you get started, we'll use dig for our examples in the following sections.
The output in our dig queries will give us back five specific fields for each resource record (RR):
Name. The host name associated with the record.
Time-to-Live (TTL). A TTL value in seconds. This is how long a given record can be stored in cache.
Class. Generally, this value is IN for "Internet Protocol". While there are other values you could see here, IN is all we need to worry about for now.
Type. The type of DNS record. For example, DNS A records will have an "A" in this field.
Data. This is the specific data associated with the record. Examples of data values include IPv4 addresses (in A records), IPv6 addresses (in AAAA records), and hostnames (in CNAME records).
You'll notice that all of our command examples here have "+noall +answer" in them. This is simply to clean up output to focus on the responses (a.k.a. answers). It's possible to use a .digrc to make this happen without typing "+noall +answer" every time, but sometimes full dig output is useful.
DNS A Records
A records, also known as Address records, are one of the most important types of DNS records. DNS A records map domain names (like cbtnuggets.com) to IPv4 addresses. To query the A records for cbtnuggets.com, we can use the command "dig +noall +answer A cbtnuggets.com." Let's see what that gets us:
:~$ dig +noall +answer A cbtnuggets.com cbtnuggets.com. 60 IN A 188.8.131.52 cbtnuggets.com. 60 IN A 184.108.40.206
Reading the output we can see that there are two IP addresses (220.127.116.11 and 18.104.22.168) that there are two separate addresses that resolve to cbtnuggets.com. Each has a 60 second TTL, uses the Internet Protocol class, and is an A record.
DNS AAAA records
AAAA records are the IPv6 answer to A records. We can query an AAAA record for google.com using the "dig +noall +answer A google.com" command.
:~$ dig +noall +answer AAAA google.com google.com. 111 IN AAAA 2607:f8b0:4009:816::200
In the output we see 2607:f8b0:4009:816::200 is the IPv6 address associated with google.com.
DNS CAA records
A Certification Authority Authorization (CAA) DNS record is used to specify what Certificate Authorities (CAs) are allowed to issue certificates for a given domain. Not all websites will have CAA records. We can use the command "dig +noall +answer CAA duckduckgo.com" to see what CAs are valid for Google's privacy-focused competitor.
:~$ dig +noall +answer CAA duckduckgo.com duckduckgo.com. 3600 IN CAA 0 issue "digicert.com" duckduckgo.com. 3600 IN CAA 0 issue "letsencrypt.org"
In the output we can see that letsencyrpt.org and digicert.com are the two CAs called out. The "0" value is a flag and issue is a tag. You can learn more about this syntax in section 5 of RFC6844.
DNS CNAME records
Canonical Name records (CNAME records) maps a subdomain (e.g. blog.onecoolwebsite.xyz) to another domain name (e.g. onecoolwebsite.xyz). The domain name that you map to (onecoolwebsite.xyz in our case) is the canonical name.
In many cases, when you do a CNAME lookup, you may see that a hostname is routed to a CDN (content delivery network) or web hosting platform. For example, check out the output when we use "dig +noall +answer CNAME blog.mozilla.com":
:~$ dig +noall +answer CNAME blog.mozilla.com blog.mozilla.com. 60 IN CNAME mozilla.wpengine.com.
A few important notes about CNAME records:
CNAME records never point to IP addresses, only domain names.
MX and NS records must NOT point to CNAME aliases. See section 10.3 of RFC2181.
A CNAME alias should NOT have any other resource records associated with it. For example, if you have a CNAME entry for blog.onecoolwebsite.xyz, you should not also have an A record or a TXT record.
DNS MX records
Mail exchanger records (MX records) tell us the mail server that accepts mail for a domain. You'll notice that the domains in an MX record's data field are preceded by a number. These numbers define priority. A server with a lower priority number is used first. We can use "dig +noall +answer MX google.com" to take a peak at the different mail servers used by google.com.
:~$ dig +noall +answer MX google.com google.com. 202 IN MX 20 alt1.aspmx.l.google.com. google.com. 202 IN MX 40 alt3.aspmx.l.google.com. google.com. 202 IN MX 10 aspmx.l.google.com. google.com. 202 IN MX 30 alt2.aspmx.l.google.com. google.com. 202 IN MX 50 alt4.aspmx.l.google.com.
Based on that output, aspmx.l.google.com is the mail server that would be used first.
DNS NS records
Name server records (NS records) are the DNS records that indicate the authoritative DNS servers for a domain. An authoritative DNS server is the server that contains a given domain's DNS actual records. With the command "dig +noall +answer NS yahoo.com" we can see 5 authoritative DNS servers for yahoo.com.
:~$ dig +noall +answer NS yahoo.com yahoo.com. 156447 IN NS ns4.yahoo.com. yahoo.com. 156447 IN NS ns3.yahoo.com. yahoo.com. 156447 IN NS ns5.yahoo.com. yahoo.com. 156447 IN NS ns2.yahoo.com. yahoo.com. 156447 IN NS ns1.yahoo.com.
DNS PTR records
A pointer record (PTR record) is the opposite of an A record. This DNS record tells you the domain name of an IP address. If you want to do a reverse lookup, a PTR record query can help. Note that we use dig with the -x switch to do reverse lookups. Using our earlier A record query for cbtnuggets.com as a reference, an example PTR query to check the 22.214.171.124 IP address is "dig +noall +answer -x 126.96.36.199."
:~$ dig +noall +answer -x 188.8.131.52 xxx.in-addr.arpa. 300 IN PTR ec2-x-xxx-xx-xxx.compute-1.amazonaws.com.
It may be confusing that the PRT record doesn't come back with the input for the A record query. Instead it points to the AWS cloud. This is a good example of how DNS and networking can be more complex as you dig into things. CDNs, cloud providers, load balancers, and firewalls can all add complexity. Don't worry about this too much for now, but keep it in mind as you go.
DNS TXT records
Text records (TXT records) are used to put human or machine readable data into DNS records. One common reason to use TXT records is to verify that you own and control a given domain. For example, Google lets users verify their domain with a TXT record. Facebook offers business users a similar TXT record-based verification process. We can use dig to look up TXT records associated with yahoo.com using the command "dig +noall +answer TXT yahoo.com."
:~$ dig +noall +answer TXT yahoo.com yahoo.com. 868 IN TXT "v=spf1 redirect=_spf.mail.yahoo.com" yahoo.com. 868 IN TXT "edb3bff2c0d64622a9b2250438277a59" yahoo.com. 868 IN TXT "facebook-domain-verification=gysqrcd69g0ej34f4jfn0huivkym1p"
In the output, we can see yahoo.com is one of the many domains using TXT records for Facebook domain verification.
Those are some of the most common DNS records you'll come across. At this point, you should have a solid basic understanding of DNS records. However, there is plenty more to learn when it comes to networking in general and DNS in particular. For a deeper dive on DNS in Windows environments, check out Garth Schulte's Implement Domain Name System (DNS) training.