Name Servers are a forgotten piece of the internet puzzle. Having failover name servers for reliability and uptime is a consideration often overlooked from the client, to the web services provider, and all the way up to the webhost. While name servers are (theoretically) geographically separated and located on separate networks, they are not impregnable and/or exempt from issues that result in downtime for a website.
This article serves as a ‘proof of concept’ more than a actual tutorial.
What the Name Server Does
Broadly speaking, a Name Server is an internet phone book. You type into your browser ‘http://www.example.com’ and your internet service provider sends your request to the phone book. The Name Server looks for what is called a ‘zone record’ for example.com and returns the proper IP address where the domain you are looking for is hosted. This is known as ‘resolving’. The name server resolves the domain to an IP address. With that information in hand, your request is sent to the appropriate server and the content you were looking for is delivered to your screen. Name servers also help with routing e-mail and subdomains, among other things.
Every publicly available website has zone records on at least two name servers. The idea is that if one name server cannot return the correct information, the request will be kicked to the next server listed in an attempt to retrieve the information necessary.
Name Server Vulnerability
Name Servers, like any other piece of internet hardware, are subject to failure for time to time. The failure could be the result of any number of occurrences from natural disaster, to human error, to malicious activities. Despite these types of vulnerabilities, name servers can be configured to almost guarantee 100% uptime for dns resolution.
Most web hosting services and domain registrars offer basic DNS services. That is, they will allow you create subdomains, specify mail exchange services, etc. However, they generally will not allow you to specify an alternate backup DNS service (known as a slave) that automatically syncs with their master zone records.
Additionally, as of today, if you tracert or ping GoDaddy’s name server pairs (ex: ns25.domaincontrol.com and ns26.domaincontrol.com) you will see that both of them resolve to the same IP address. That means that your ‘two’ name servers are really just one server that has two IP addresses. If that server goes down, or any of the servers/routers in between, your DNS resolution will fail and your site disappears.
As previously stated, name servers are neglected when it comes to mapping out a plan for web service reliability. The instances of name server failure are generally low, but when time is money, any potential downtime should be mitigated as much as possible. Fortunately, it is easy to ensure your own name server failover. This tutorial will help accomplish that task.
Proof of Concept: Creating Name Server Failover
Register a domain for your name servers.
This isn’t actually 100% necessary, but it will save you from having to create an extra A Record for each name server if you try to use subdomains of your main domain to house the name servers. For instance, if you own example.com, putting name servers on ns1.example.com and ns2.example.com will require you to have an A Record for both in the DNS zone file. On the other hand, if you register ‘example-ns.com’ or even ‘example.net’ (as long as there isn’t a site on that domain that will be served by the name servers), you will not have to remember to add the A Records for the name servers. It’s not a big deal, its just one less thing to remember.
If you are a web developer or web provider, it may not be a bad idea to have a few of your own name servers. Here are a few reasons why:
- Many registrars and hosting providers use either a single name server with two IP addresses or two name servers in the same data-center behind the same routers. When they have a problem and your customer’s site(s) disappear, you look bad for not having answers.
- Have at least two physically separate and properly configured name servers all but guarantee 100% uptime for DNS resolution.
- If there is a name server issue on your end, you can diagnose the issue and give your customers an accurate status update.
- Having ‘ns1.mywebcompany.com’ and ‘ns2.mywebcompany.com’ enhances and solidifies your brand. This will keep your sub contractors out of the loop and aid in reputability and boost consumer confidence (assuming of course that you keep the service up and running).
- Large web service providers are more likely to be the target of or succumb to malicious activities. Conversely, a couple of obscure name servers are much less likely to fall into the cross hairs of an attack.
Deploy some servers to run a DNS service.
Running a DNS service on a server is not a an exercise in rocket science. We prefer to use BIND which, for all intensive purposes, is the defacto name server daemon. Further, CentOS has a comprehensive BIND package that can be installed as well as restrictive firewall rules right out of the gate. You’ll have to open port 53 for TCP and UDP traffic in order for your name server to operate.
The key is to have one of the name servers be a master name server and the other a slave. The slave will query for updates at a specified interval and thus stay relatively up-to-date. If the master name server fails, you have time to restore it before the slave server times out.
Your servers could be run out of an office or collocation data-center but an alternate more affordable approach would be to deploy on-demand cloud servers. These servers can be configured in a variety of ways without the need to be concerned with hardware maintenance and upgrades. Ideally you would deploy two cloud servers with different providers over different networks.
Register your name server
Once your servers are set up and the slave is properly querying the master server, it’s time to register your name server. Glue records are created by approved internet registrars. Some registrars will allow you to create glue records on your own, others will require you to submit a support ticket. In the GoDaddy interface glue records are created in the host summary interface. Simply provide the FQDN (fully qualified domain name) of the name server and its static IP address. It will take a while for these glue records to propagate, but once they do, you are off to the races. The only thing left to do is set your web site(s) name servers to reflect your name servers and wait for the changes to propagate.
Further Failover Measures
You can ensure even more failover. Create an account with a free name server provider such as Zone Edit or DNS Park. You can configure your zones and instruct them to obtain up-to-date information from your master (or slave) DNS server. You’ll need to explicitly allow this in your name server config, but doing so will bring you up to 4 or more name servers capable of serving your DNS resolution needs.
Summary
Name server failover is the forgotten piece of the web services paradigm. Whether you are running your own web site or you are a web services provider, neglect of the name server issue is a serious gamble. This proof of concept shows that name server failover protection is not only feasible, but also affordable and beneficial. The rise of cloud computing and virtual servers makes deploying a dedicated name server relatively easy and uncomplicated.
More info
blog.dephuedatadesign.com/failover-name-servers-for-reliability-and-uptime