12 DNS Records Explained

The domain name system (DNS) is integral to today's Internet, and on the surface, it seems extremely complex. It's little wonder that DNS confuses so many people. However, if you get to know some of the most common DNS records - and how they're used - it's easy to get a sense of how this technology works. Here we'll look at the 12 most common DNS records.

A Records

In order to associate a domain name with an IP address, it's usually necessary to use A records. These can be in the form of many different host names and subdomains. This is done by declaring a record - such as mail.techopedia.com or www.techopedia.com or ntp.techopedia.com. In this case, "mail", "www" or "ntp" would be the defined A records. These might point at any IPv4 IP address, such as 12.34.56.78. Looking up which IP address is associated with a domain name in this way occurs through a forward DNS lookup, or query.

AAAA Records

As IPv6 becomes more prevalent, the AAAA record (or "quad-A") will become more popular. This is simply the IPv6 equivalent of the IPv4 version, and it differs because IPv6 uses 128-bit addresses. This means that AAAA records are notated using eight groups of 16-bit values, such as: fe80::226:18ff:fed3:cc2a. (Learn more about the new IP infrastructure in The Trouble With IPv6.)

CNAME Records

Canonical records (CNAMEs) are useful for pointing one host name at another. This eliminates the need for explicitly declaring an IP address and means that the IP address can be changed once rather than twice if a CNAME record simply points at an already established host name, as shown in the following example:

hostname.techopedia.com 1.2.3.4 cname.techopedia.com hostname.techopedia.com

Here, cname.techopedia.com will also return the IP address 1.2.3.4 as it points at hostname.techopedia.com.

MX Records

MX records are those that are looked up by mail servers when email needs to be delivered. They will usually make up more than one mail server for reliability, but this is not always the case, and may be a breach of Request for Comments (RFCs). Configured using a simple hierarchy, an administrator can define which mail server should receive mail first and so on. An example might be as follows, where Priority 5 is the preferred mail delivery host with IP Address 1.2.3.4:

mail1.techopedia.com 5 1.2.3.4 
mail2.techopedia.com 10 5.6.7.8 
mail3.techopedia.com 20 9.8.7.6

NS Records

At the root server level, it's important that there is an authoritative name server configured to respond to queries against a particular domain name. Each domain name should have name server records set up in order to function; using too few name servers may breach RFCs. An example held on a WHOIS record might look like this, where ns1 returns the IP address 1.2.3.4 and so on.

ns1.techopedia.com 1.2.3.4
ns2.techopedia.com 4.5.6.7

SOA Records

Each DNS zone (or publicly announced configuration of DNS settings) must contain some indication of how the delegated DNS entries are run. The Start of Authority (SOA) record can show the primary name server for the domain name, the serial number (this should be when the last revision was made to the DNS configuration for the zone if it's shown in the correctly specified date format), and other pertinent information relating to how the zone is run by the administrator.

RP

Also shown inside the SOA record is an email address of whom to contact, or the responsible person (RP), in the event of a misconfiguration or some other issue relating to the DNS zone. This might be something like hostmaster@techopedia.com.

TTL

Within the SOA, it's important to announce how other machines should react when communicating with the authoritative name servers for a DNS zone. Such an example might be:

techopedia.com has SOA record ns10.dnsmadeeasy.com. dns.dnsmadeeasy.com. 2009010181 43200 3600 1209600 180

Here we see the domain name for techopedia.com's primary name server is ns10.dnsmadeeasy.com and that the human contact is dns@dnsmadeeasy.com (note the @ sign is never shown in an SOA entry but is instead implied). Finally, we can see its serial number (suggesting in this case that salient changes haven't been made since 2009), followed by a number of time to live (TTL) values that control how long data received from a name server might be trusted before being considered stale, among other things.

SPF Records

With the ever problematic unsolicited mail issue on the Internet, one common method of combating it was to use DNS to declare which outbound mail servers were allowed to send mail from a domain name. A Sender Policy Framework (SPF) record might look like this for that reason:

techopedia.com has SPF record "v=spf1 mx ptr ip4:184.72.216.57 ip4:66.51.97.134 a:list.janalta.com a:webmail1.janalta.coma:list.technewsletters.com include:_spf.google.com ~all"

Here we see a list of machines allowed to send email and some IP addresses as well.

TXT Records

These records can be used for a number of purposes, but a good example can been seen here:

techopedia.com descriptive text "google-site-verification=3gxUc6RH0WccwA6LNaDwENjhKlfUydMOVMtmCIOJBnE" techopedia.com descriptive text "google-site-verification=C_-veU9lL8A7lVTeFpxNDiuW4dwjhcpittNkfCa83bA"

Google's site verification system has obviously needed a way to identify that a particular domain name or host name belongs to an administrator during a configuration process request. In this case, it has asked for DNS entries to be created to authenticate that request. Google most likely assumes that only the owner of the domain name will have access to the name servers responsible for running the domain name and therefore, only they will be able to makes DNS changes to the domain name.

DNSKEY Records

Because security is so important on the Internet, including when it comes to the pervasive DNS, DNSSEC was created to bolster the domain name system. The DNSKEY record is a cryptography method for declaring configuration for security and may look like this:

ripe.net has DNSKEY record 257 3 5 AwEAAXf2xwi4s5Q1WHpQVy/kZGyY4BMyg8eJYbROOv3YyH1U8fDwmv6k BVxWZntYtYUOU0rk+Y7vZCvSN1AcYy0/ZjL7cNlkc3Ordl2DialFHPI6 UbSQkIp3l/5fSWw5xnbnZ8KA7g3E6fkADNIEarMI4ARCWlouk8GpQHt1 1wNW1c65SWB8i958WZJ6LI0pOTNK+BIx8u98b+EVr7C08dPpr9V6Eu/7 3uiPsUqCyRqMLotRFBwK8KgvF9KO1c9MXjtmJxDT067oJoNBIK+gvSO9 QcGaRxuGEEFWvCbaTvgbK4E0OoIXRjZriJj8LXXLBEJen6N0iUzj8nqy XSCm5sNxrRk=

Regional Authorities and in-addr.arpa

In order to provide data for reverse DNS lookups (where an IP address is converted into a domain name, instead of the other way round) IPv4 uses in-addr.arpa. Separate from the root servers running the delegated forward DNS for domain names, the reverse DNS is configured by five regional Internet registries (RIRs), each of which is responsible for a certain geographic region.

An example PTR (or pointer) record delegated by an RIR to an authoritative name server that is ready to answer reverse DNS queries might be as follows. Notice that the notation is reversed:

 4.3.2.1.in-addr.arpa www.techopedia.com

The five global RIRs are:

• African Network Information Center (AfriNIC)
• American Registry for Internet Numbers (ARIN)
• Asia-Pacific Network Information Center (APNIC)
• Latin America and Caribbean Network Information Center (LACNIC)
• NCC Réseaux IP Européens Network Coordination Center (RIPE)

Even among seasoned technical staff, the fact that reverse DNS is delegated by RIRs is sometimes overlooked and missed during troubleshooting. The other record types are more straight-forward.

DNS? No Sweat

Although we have barely scratched the surface of the ins and outs of DNS and its clever functionality, next time a Web hosting company needs you to add an A record to your domain name's DNS for a new website launch, you won't have to break a sweat.

Tags: Standards Internet