Understanding DNS Records

In a previous article, What is DNS?, I gave an overview of the Domain Name System (DNS), broadly focusing on how it works and the purpose that it serves. In this article, I will delve a little bit more into the specifics by discussing DNS records, their individual functions, and why they are useful to you.

You will recall that domain names are essentially labels that allow internet users to easily direct programs and computers to certain servers without having to remember those servers’ IP addresses. Computers, however, still need those IPs in order to communicate with each other, and DNS is the decentralized system that makes domain-to-IP resolution possible. This system relies on the existence of nameservers that either store the individual records of the correct IPs, or else know which other nameservers to query for such information.

Nameservers work by listening for certain DNS lookup requests and replying with stored information. The stored information is in what is called a zone file. Zone files are simply plain text files that contain any number of specially formatted specific records for a domain name.

Fortunately, zone files are rarely edited by hand these days. Instead, most people are able to add, remove, or edit DNS records either through a web interface provided by their domain registrar, or (more commonly), through their website’s control panel used at their web hosting provider. Which system you’ll need to use will depend on whether your domain is set to nameservers belonging to your web host or not. Remember, nameservers are the systems responsible for a domain’s zone file. If your domain is set to nameservers belonging to your web host, then changing your DNS records will take place there. If the nameservers belong to your domain registrar, then any DNS changes must take place through them.

If you don’t remember which nameservers your domain is set to, you can always use a lookup service such as LeafDNS.

There are a number of different DNS record types, but the ones you should be familiar with are: A, CNAME, and MX. I will discuss each of these in turn using “example.org” as a domain name. (Note that this domain is reserved by ICANN for example purposes, and is not actually owned by me.)

A records, or address records, map domains and subdomains to IP addresses. As you can see in the screenshot above, which is taken from cPanel, there are two A records set in the zone file for “example.org.” The first is for the domain itself, and the IP address (172.31.59.76) is that belonging to the server that example.org is hosted on. This ensures that when you type “example.org” into your browser, you are pointed to that server and none other. If I later decided that I want example.org to resolve to a different server, I would need to edit the A record with the new IP.

The second A record, for blog.example.org, points to an entirely different IP. This may be because I decided to host my blog on a different server, or perhaps I’m designing a blog elsewhere and am using blog.example.org temporarily until I’m ready for production. I can setup any number of A records of this kind, including giving a subdomain to a friend for him to host whatever he wants, such as david.example.org.

CNAME records, or Canonical Name records, are another record type shown in the example above. These are simply aliases for other domains. The most obvious one is “www.example.org” being a CNAME for “example.org.” Having this CNAME set ensures that you will reach my site whether you type “example.org” or “www.example.org” into your browser. The reason for making www.example.org a CNAME for example.org, rather than an A record that simply points to the same IP (though you can do that too), is for convenience. If I were to later change the A record for example.org, all CNAME records pointing to it could be left untouched. They are all just aliases, and will point to wherever example.org points to.

The last CNAME record is for shop.example.org, and it points to my Shopify site. This is to demonstrate that CNAMEs need not be aliases for your own domain. If I were to navigate to http://shop.example.org (assuming it’s a working domain), I would be shown the content of http://example-shop.myshopify.com (assuming that’s a real Shopify shop) though my browser’s URL would still read http://shop.example.org.

MX records, or Mail Exchanger records, are the last DNS record type we will look at in this article. You will notice that you do not see any entries for MX records in the screenshot above. That is because cPanel handles MX records in a different area (the MX Entry icon in the Mail section), though they are as much a part of your DNS zone as the other records.

In another article, I discussed how email services work on your web server. DNS in general, and MX records in particular complement those services by determining where email is supposed to be routed when sent to an address on your domain. So depending on what I have set for my MX records, email sent to galen@example.org can be routed to the email service being hosted on my web server, or it could be routed somewhere else that I’ve determined, such as to Google if I am using Google Apps. The two screenshots below help to illustrate: