Behind every website is a little-known system that is the glue holding the internet together. It’s called the DNS, or the Domain Name System.
Thirty years ago, when the Internet was still in its infancy when you wanted to visit a website you had to know the IP address of that site. That’s because computers are and were only able to communicate using numbers.
This is an IP address: 127.33.54.200.
It’s long, hard to remember, and we (humans, I presume) are not robots. We needed a way to translate computer-readable information into human-readable. And it had to be fast, lightweight, and scalable.
In the early 1980’s, Paul Mockapetris came up with a system that automatically mapped IP addresses to domain names.. and the DNS was born. This same system still serves as the backbone of the modern Internet, today.
And yet, only a small subset of the world knows that it exists, and an even smaller group understand what it does. The real problem is that the people that need to know how it works and could benefit from this knowledge… don’t take the time to learn.
If you’re a webmaster, web designer, front-end developer, IT, or technical support you need to know the basics of how DNS works and how it can help you manage your domain’s presence on the Internet.
Before we get into how you can use the DNS, we need to understand how the system works. We already know that it maps IP addresses to domain names, but where is this information stored? On nameservers!
Name servers store DNS records which are the actual file that says “this domain” maps to “this IP address”. So is there a room somewhere that has all the nameservers and DNS records for every site on the Internet? No… that would be ridiculous.
They are really distributed all around the world. These nameservers are called the root nameservers and instead of storing every domain ever, they store the locations of the TLD (top level domains).
TLD’s are the two or three character strings like .com that end a domain name. Each TLD has their own set of nameservers that store the information that says who is authoritative for storing the DNS records for that domain.
The authoritative nameserver is typically the DNS provider or the DNS registrar (like GoDaddy that offers both DNS registration and hosting). And here we can find the DNS record that maps example.com to the IP address 127.66.122.88.
Let’s put that all together. When you query a domain name your first step won’t begin at the root name servers. Instead, your browser will ask your local resolving name server if they have the DNS records for that domain cached.
The resolving name server is typically your ISP (Internet Service Provider), and if it’s a popular website like youtube.com they will likely have the record in their cache. In this case, you would skip the rest of the DNS lookup process.
However, these records are only stored for a short period of time. Whenever you create a record, you have the option to set a TTL (Time to Live). TTL’s tell resolving name servers how long they can store the record information. TTL’s can range anywhere from 30 seconds to a week.
What if the record we are looking for isn’t cached? Then the resolving name server will ask the root name servers for the TLD for that domain, which will point you to the provider authoritative for hosting the records.
Okay, that was a lot of steps to go through just to find the IP address. Oh, and by the way, this process happens in just a couple milliseconds. A little perspective, you blink your eye in roughly 50 milliseconds. You can resolve most DNS queries in under 30.
Think this is cool? Learn more about how the DNS works.
Now we are going to take a look at how this very simple system can be used to help you keep your website online, improve website load times, email delivery, and so much more.
Your first encounter with DNS almost always happens at your domain registrar –where you bought your domain name.
Ok so you have a domain name, cool, but it doesn’t do anything yet. If you type your brand spanking new domain into your browser, I bet you’ll see a placeholder page courtesy of your registrar.
Placeholder page for a new domain without a website.
First things first, get off your registrar’s DNS. There are many reasons why, and you can read more about those here.
You will need to change your domain’s nameservers to those of a specialized DNS provider (psst! Try Constellix!).
How you do it depends on your current provider, but basically what you want to do is make note of all of your existing DNS records. There may also be an option to export them into a zip file. Though, it’s likely won’t have any records unless you bundled with web hosting or another service. If you do, you’ll want to create the exact same records at your new provider.
Now you can add your domain to your new provider. You’ll be prompted to update your nameservers through your registrar. This tells the company you bought your domain from that you are going to be using another provider for DNS hosting. You may need to wait a few minutes, but if you have Constellix this takes only a few seconds thanks to our instant propagation.
One thing to note, changing DNS providers DOES NOT change who your registrar is. Your domain is still registered through your registrar, but you are now hosting your DNS information (records) through a different provider.
Now that you have moved to an external provider, you can start adding records. Let’s assume you don’t have any yet. You will need a handful to get your site up and running, which only takes a few minutes.
Before we go any further, you need to decide whether you want to send your users to www.yourdomain.com or yourdomain.com. The latter is called a “naked domain” or “CNAME flattening” and it’s the latest craze because frankly, it just makes life simpler.
We’re going to assume you, like the rest of the world, prefer to not type in the extra 4 characters of www.
But what if someone enters www.yourdomain.com into their browser? Where will they go?
Nowhere. Because we have to tell them that www is not the preferred version of our site. We can do this using a CNAME record.
CNAME records point domains (or hostnames) to other domains (or hostnames). They are also called Alias records because they tell the user that the record information is really hosted somewhere else.
You can even use CNAME records to point to external domains like www.yourdomain.com to www.google.com. Just remember to add a dot at the end, or the hostname will be appended to the beginning of your domain like www.google.com.yourdomain.com.
Keep in mind that CNAME records are different from Web Redirection because you can only point domains to other domains, no fancy URL paths. You wouldn’t be able to say www.yourdomain.com points to www.google.com/this-is-not-a-page.html.
Another thing to note, CNAME records cannot be used at the root level. So once we make our domain naked, we won’t be able to use a CNAME record to point your domain to another hostname… more on this in a few minutes.
For this use case, we need to point www.yourdomain.com to yourdomain.com. That means we are telling the user that the IP address for www.yourdomain.com is stored at yourdomain.com.
Now we need to create a CNAME record that tells everyone who types in www.yourdomain.com to go to yourdomain.com.
For the record name enter www and point that to the host: yourdomain.com. Make sure you do not add a period/dot/stop at the end. You only want to use those if you are pointing to an external domain like google.com.
Once you commit your changes, your domain will be naked! Go ahead and try it. Constellix propagates changes instantly to all of our nameservers around the world. That means your users in Australia can see the changes you made in under a second after you commit them.
Ok, we’re live on our new DNS provider and our domain is naked… but you don’t have a website. It just shows a blank page.
You need to create a record that tells your users how to get to the web server where you are hosting the files for your website. Let’s assume you already have a web server and at least a homepage (index.html) setup. Your web hosting provider will give you an IP address or hostname for the server your site is hosted on.
You need to tell users who visit your domain that they need to actually be going to the web server to see your website files. You can do that with an A record which answers users with the IP address of the web server or an ANAME (read more about this later) record that points to the hostname of the server.
In this example, we are going to use Constellix to show you how to create an A record. Leave the name field blank, since we want this to work at the root (naked) level of our domain. In the IP field, enter the IP address of your web server.
Your changes will propagate instantly. Now, when you type your domain name into your browser you will see the index.html page you have stored on your web server. All thanks to DNS.
The next thing you need to do is setup your FTP (how you upload website files) and mail servers. Both of these services will most likely need to point to your web server. There are two ways to do this. You can take the hard way and go and make more A or CNAME records that point mail.yourdomain.com and ftp.yourdomain.com to your web server.
Or, you can create CNAME records that point to the root of our domain, which already has an A record that points to our web server.
That means, if you ever change your web server, all you have to do is update a single A record.
Have you ever accidentally added an extra “o” to google.com? It’s okay, we all have. But did you notice that you still ended up at google.com? Not gooogle.com or a blank page, but plain old google.com. That’s because Google uses a CNAME record to send traffic that mistakenly adds an extra “o” to their intended destination.
When you set up your own site, you may want to do the same thing. This does mean that you have to buy domains that are similar or a letter off from your own domain. Then, all you have to do is create a CNAME record that points users to the correct domain.
So far, we’ve only discussed basic website setup using DNS, but DNS does so much more than simply tell users how to reach your site. The system has evolved to become an optimization tool to decrease load times, deliver location-specific content, and so much more.
A few months ago, I was traveling from DC to Seattle. While I was waiting in the airport, I took to Yelp to find a place to get brunch once I landed. But almost every website I tried to load took over ten seconds just to get the first image to appear.
Why? It’s simple physics, as distance increases between two points, it takes longer to reach each endpoint.
Remember earlier, how our example website was hosted on a single web server? Well, this has become outdated for any business that has customers outside of their immediate locale. I mean, sure, the brunch place I wanted to go to usually won’t have customers from DC that often; but if you have an online store or a blog that you want people in Los Angeles to see and you’re on the East Coast… you’ll need more than one web server to get your visitors to stick around.
We can solve this with a CDN service. CDN’s (Content Delivery Networks) are networks of web servers, each host a copy of your website. That means whenever a user wants to reach your site, they won’t just be sent to any old web server, but the one that is physically closest to them.
Since users have to travel less distance to reach your content, it loads faster. This can turn load times from ten (or more) seconds to under two!
But here’s the problem… right now we have an A record pointing to our web server. How do you point to the multiple web servers in a CDN?
You can’t. Instead, you have to point to the CDN using a CNAME record. The CDN will then calculate where the closest web server is and use an A record to point users to that web server.
But wait, CNAME records can’t operate at the root of a domain. So if we have a naked domain (no www.) we won’t be able to use a CDN.
Wrong! A few years ago, DNS Made Easy invented a new record type called an ANAME record. This record is like a CNAME record, but it operates at the root level.
In Constellix, all you have to do is create an ANAME record, leave the name field blank (because that’s the root) and point it to your CDN provider’s hostname (end with a dot).
PS: If you’re a reseller or manage a lot of domains with similar configurations, create a template with these records and whenever you add a new client (domain) apply this template.
Last but not least, we need to prepare for the worst. We already saw how to use a CDN to host multiple copies of our site across the world. Each of these copies acts as a sort of backup, so if one of those web servers isn’t working, users will just go to the next closest web server. Simple, right?
Well, we can use a similar technique using DNS records to automatically send users to another website or server if our main one isn’t working. This is called DNS failover.
So what if we have an A record that points yourdomain.com to an IP address like 126.96.36.199. And then we want to add another IP address 188.8.131.52, and maybe another at 184.108.40.206 because we have a couple different web servers we like to use for this website.
When a user queries our domain, how do we know which IP address will be returned? DNS records default to using Round Robin, which rotates which IP address is returned. So if we were to query our domain a bunch of times, one in every three times we would see 220.127.116.11 being returned.
Failover uses Round Robin to cycle through available endpoints, but will ONLY return endpoints that are detected as “up” or healthy.
You can use failover to send your users to backup web servers, email servers, CDN providers, and so much more.
Let’s take a look at this in Constellix. We are going to create a CNAME record that points to a CDN. We are also going to enable Failover, which tells Constellix that if our primary CDN is unavailable, then it should point to our backup CDN instead.
See the two fields for hostnames? That’s where you specify your primary and secondary CDN services (or whatever you want).
To the right of each hostname is a drop-down for a Sonar check. This is a simple monitoring check you can set up using our integrated network monitoring service. If Sonar detects one of your endpoints as DOWN (big red letters, can’t miss it) then it will no longer point users to that endpoint.
Let’s say our primary CDN, mycdn.com, was unavailable. Failover will automatically send all your traffic to othercdn.com. It’s not magic, it’s DNS!
I know there’s a lot going on here, but bear with me. This little setting could decide whether or not your site is online or not.
Sh%t happens, especially on the Internet. I mean look at this calendar of just some of the major outages that happened last year. In almost every instance, a single service was responsible for knocking that website or application offline.
What aspect of your online business or website do you find crucial? If something failed, would you lose a day of revenue? How much is that worth to you?
Take the time to set up backup services for what you find crucial and then use your DNS provider to set up failover records. We only showed you how to do this for a CDN service, but you can use this for web servers, email servers, and a myriad of other online services.
DNS is more than just the glue that holds the Internet together, it’s an invaluable tool that developers and webmasters need to take advantage of.