Dealing With DNS Records
I know that a blog post about DNS, or Domain Name System, records is probably not the sexiest topic out there, but it is one that I think will help developers that are struggling to wrap their heads around what DNS records do. To start with the Domain Name System is what routes requests across the internet, and what allows us to type in pretty domain names to our browsers and have them resolve to the correct server. This is accomplished by DNS records that allow for the translation of a semantic domain name, such as "mydomain.com" into the IP address of the server that needs to receive these requests, such as "12.34.56.98". Obviously the reason for this is pretty evident. Can you imagine how hard it would be to tell you customers to take advantage of the hot deals at "64.123.1.45"?
So let's take a brief look at the types of DNS records that are associated with a domain name, and what they do. Remember, to make changes to the DNS records for a domain, you'll need to log in to your account at your domain registrar (such as GoDaddy) and make the changes, and once changed it can take 24-48 hours for DNS changes to resolve.
A Records
"A" records are what make the DNS system work, as these are the records that describe what IP address you would like the domain name to resolve to. In some respect, "A" records are almost too easy to describe, since you simply enter the IP address of the server hosting the website you would like this domain to point to, and that is that.
For example, if I was working with mydomain.com and create an "A" record pointing to 64.123.1.45, I can expect that any requests sent to "mydomain.com" will get routed to the server at the IP address of 64.123.1.45. That is, once I've waiting for the DNS changes to resolve.
NS Records
"NS" records, or Name Server, records are required for each domain. In fact, each domain is required to have one primary Name Server and at least one secondary Name Server. Name Servers are server that are updated when DNS changes are made, and they facilitate the translation of the semantic domain name into the IP address. I'm not going into detail on purpose here, as my goal is to introduce DNS records and not to outline the entire, often extremely complicated, DNS system. That being said, you will need to create at least 2 "NS" records for each domain.
The best way to describe this is with an example. Let's say that I am hosting my website at GoDaddy, and they have provided the following nameservers that I should use to correctly set up my site:
- ns1.godaddy.com
- ns2.godaddy.com
If I want the domain mydomain.com to point to the website that I am hosting at GoDaddy, I would need to create an "NS" record for each of those Name Servers. This will establish that the Name Servers at GoDaddy are authoritative for my domain, and ensure that the requests get routed to the proper place. "NS" records are pretty straight forward, and the name servers that you need to create these records are generally provided by your hosting company.
CNAME Records
"CNAME" records are a bit more difficult to understand, and if you aren't careful can cause real problems. The term CNAME refers to Canonical Name records, and without going into too much detail they are used to create aliases for domains true Canonical Name. Confused yet?
In other words, for the example I have been using of mydomain.com, the true canonical name for the domain is mydomain.com. CNAME records allow us to alias this, which the most common use case is for directing subdomains to another server. Why another server? Because any time you put in a request to mydomain.com the "A" record will route the request to the correct server. Any requests to subdomain.mydomain.com will also get routed to that server since the canonical name is still the same.
But what if you wanted requests to shop.mydomain.com to get routed to another server, such as a hosted online shopping cart system. The idea here is that a user should still see shop.mydomain.com in the URL bar of their browser, but the requests should be sent to a server that is different than the one defined in the "A" record. To achieve this, you would create a "CNAME" record for shop.mydomain.com that points to the server you want requests routed to, such as myshop.shopify.com, to use a common example.
MX Records
Finally, there are "MX", or Mail eXchange, records that developers will frequently need to work with. These DNS records are used to route email requests, and in order for a domain to receive email it must have an "MX" record set up in addition to an "A" record. Most often, developers will need to mess with "MX" records in order to either set up email on a new domain, or to host email on another server.
To use an example that is similar to the "CNAME" records, let's say that we host mydomain.com on the server that we are pointing to in our "A" record, but we do not want to host email services on that machine. Personally, I prefer to move all email-related hosting and such to another machine, so that mail-related things cannot bring down a website. Rather, I want all of the email messages sent to addresses @mydomain.com to get routed to my email server, which in this example would be hosted with MailTrust.
To accomplish this, I would set up an "MX" record for mydomain.com that would point to emailsrvr.com. That will tell the DNS system to route all email sent to mydomain.com to the server at emailsrvr.com to be handled. With "MX" records there is another value, which has to do with setting up redundant servers. I could set the value of that record to 20, and then create another identical "MX" record, only this one would point to emailsrvr1.com and the auxiliary value would be 10. This says that if you cannot find the first server for some reason, use the second one.
I know that when I was learning how to use DNS records I got confused a lot. It doesn't help that it often takes a few hours to see the changes (or mistakes) that you've made. There are many more complicated things that can be done with DNS records, but hopefully this brief overview will help someone out there to understand them better.
This post is filed under Developers' Corner and has the following keyword tags: DNS, MX, domain name.
2 Comments
pfk98 says:
Plain English, please.
gogglespaizanno says:
How much more PLAIN English does it need to be...that's what the point of the article is. Even I understood all of this, and believe me that's not sayin' much!
