DNS is something that sounds incredibly complicated and takes quite a bit of messing around with to actually learn and get a decent grasp of. So I decided to make a guide that tells you exactly what you need to know to work with your own website or, as a web developer, to work on client websites. I’m going to try to keep this thorough yet concise; I don’t think it’s necessary to know HOW everything works, just that it does! And truth be told, I don’t know all of the behind-the-scenes stuff anything. What I have is a very practical working knowledge of DNS and how it works, which I will share with you now.
The purpose of DNS is basically to tell visitors what server a website is hosted on. There is a lot of fluff beyond that, but really that’s what it comes down to. To understand how it works, we first need to understand all the pieces involved with determining where the DNS records are. To do that, we need to understand the following terms:
This basically says, “This is where the nameservers (see below) are located”. Most of the time, this will be set for you and you won’t have to mess with it, especially if your site is hosted through your domain name registrar. If you are ever trying to change your DNS records and you see a message like, “This domain’s zone file is not hosted here,” it could be because you have a hostname that points to a different server, though more than likely it’s because your nameservers are pointed elsewhere. Honestly, I’m not sure why you would ever mess with the hostname and I don’t think all hosts/registrars even have an option for it.
Don’t worry about this. I barely understand it, and I can tell you that I’ve never once needed to know how it works or had to do anything with it.
Tired of dealing with your slow WordPress website? Email me at firstname.lastname@example.org and mention the code #FreeHosting10 for two free months of lightning-fast WordPress hosting. We will even migrate you for free!
The nameservers are the servers where the DNS records are physically located (within the zone file). I believe every website is supposed to have a minimum of two separate nameservers, though in practice, every site pretty much has exactly two. I believe this is done for redundancy, though you don’t really need to know why, just know that there are two. They are always a name, never an IP address. The often will look like “ns1.example.com” and “ns2.example.com” and are typically always a subdomain. Hosts like Godaddy often use their own nameservers for your websites which usually look like ns64.domaincontrol.com and ns65.domaincontrol.com. In fact, that’s one way to determine that the DNS is being hosted by Godaddy: if the nameservers are on the domaincontrol.com domains. Other websites and hosts will frequently locate the nameservers directly on the domain name (e.g. ns1.example.com).
The zone file is a file that resides on the nameservers and contains the DNS records themselves. It contains all different types of records in one file. You will likely never edit the file itself; instead, you’ll work within an interface to add or edit entries. Sometimes this will be called a “Zone File Editor”, while other times you will just have to follow instructions for “Changing the DNS” or “MX Record Entry” for email records.
The records themselves are what determine where a site is hosted, where email should be routed, and more! A record typically consists of a value, a location (IP Address or domain), and a TTL (time to live – this is just telling other servers how often they should check back and see if the record has changed, usually in seconds). There are several types of records within a zone file.
These are the main host records and should point to an IP address. These should be reserved for your main host record, whose value is simply “@”. The “Points To” field should be the IP address of your hosting server. TTL can vary, 600 seconds is a common value. You would also put subdomains here (e.g. blog.example.com). A subdomain also points to a server, and behaves like its own domain in virtually every way. The value for the subdomain in the example would simply be “blog”.
Cnames are for domain prefixes that aren’t their own subdomains and aren’t their own website within your website, such as ftp.example.com or smtp.example.com. The most commonly used one here is “www” and it’s how you make sure that visitors to the “www” version of your site are seeing the same thing. The value would simply be “www” and the “Points To” would be “@”. The “@” symbol basically just points it to your main host record, which is what you want here.
Note that Cnames should be domains or “@”, not IP Addresses.
MX Records are for email. Usually, your mail host will tell you exactly what values you should be using. These records also have an additional field, “Priority”. I believe you need to never have more than one record with the same priority. Again, ask your mail host what records you should be using.
Really the only other main one you might need to know for troubleshooting purposes is the AAAA record, which is just like an A record except it uses IPv6 addresses, which are the new IP addresses and are more complicated. I don’t believe it is ever necessary, and in fact sometimes I’ve seen it cause problems. If your hosting server definitely has an IPv6 address assigned to it and you know for sure what it is, go ahead and use it. If not, it could cause trouble! I’ve seen a website that seemed to unpredictably be offline for just some people, and it’s because they used an AAAA record when they weren’t supposed to be.
There are also TXT and SRV records, but you don’t need to know much about them. Sometimes you may be asked to add one, but if you are, you’ll be given everything you need.
You might hear about “propagation” from time to time. You don’t need to know how it works, but just know that it can take some time for your newly-saved records to “go live” across the internet. During the transition period, some users may see the old record, some may see the new. It can take 24-48 hours officially for a change to “Propagate” and go live across the internet. However, depending on many mysterious factors, it can take much, much less time than that. Sometimes, especially with Godaddy, it is often less than 5 minutes.
Always plan for some lag time, and prepare accordingly.
Tips & Tricks
DNS can be complicated, but most issues can be flushed out just by checking some things.
- Use this tool. It can tell you whether your changes have propagated, including Nameservers and all other records. It shows different locations across the globe and what they are seeing, so you can get a good feel for whether it is in transition. Sometimes the tool intoDNS is helpful too, but I get the feeling its information is not always up-to-date.
- If your changes don’t seem to have any effect, double check the Nameservers using that last tool. Sometimes you’ll find that the zone file you are editing is not at the correct location! Might want to have your host support help you.
- Plan major changes for weekends and nights. That way if there is downtime, fewer people are around to see it.
- Don’t recklessly change Name Servers, especially if you don’t have access to the old ones. Odds are you’ll take down the website AND email for that domain.
- Email is tricky, and difficult to change without having downtime; plan accordingly. And make sure you actually have email inboxes set up at the new location.
- You can change the host records without affecting email, as long as you leave the MX records alone.
DNS is a tricky beast, but most of the time you don’t have to get too complicated with it. Let me know if you have any other tips or tricks!