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 actually 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!
How a CDN works
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.
The Naked Problem
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.
When Sh%t Goes Down
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 184.108.40.206. And then we want to add another IP address 220.127.116.11, and maybe another at 18.104.22.168 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 22.214.171.124 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.