DNS high availability keeps your network humming
Does your infrastructure support DNS high availability (HA)? If you have just one DNS server, what happens if you experience a system failure? Suddenly, your network stops and your web server and web site can’t be found.
You want to be certain that your mission critical networks can keep humming along even if your DNS server grinds to a halt. You need a high availability configuration that is both redundant and resilient, with failover at the ready. You need a solution that eliminates single points of failure associated with single components and computer systems. You need a disaster recovery plan for your network - one that minimizes the amount of time needed to recover.
BlueCat buoys the operational performance of your enterprise with a comprehensive and layered approach that eliminates downtime.
It’s disaster recovery without the disaster.
Four avenues to DNS high availability
There are four avenues to achieve high availability for DNS services. On their own, each can provide some measure of a safety net, with limitations. But implement them all (including at the hardware or software levels), and the result is a comprehensive and overlapping high availability solution that maximizes your uptime.
It starts with building highly available systems right into our hardware scheme. At BlueCat, we call it xHA—crossover high availability. When the primary server fails, another backup server in the same physical location takes on the work automatically and seamlessly.
DNS itself is also inherently a redundant protocol. If one server doesn’t respond, it will purposely failover to another server instead. DNS doesn’t require a failure detection response from a specific server—any server will do.
BlueCat architects its system components so that any server outage within it has no service impact. In fact, it doesn’t matter if a particular server is available at all. The service may have to operate from a different physical spot, but the overall service keeps running without any downtime.
BlueCat can integrate with third-party products—load balancers, mainly—to provide an additional form of network high availability. These server load balancing products do health checks to ensure that the service is up. They switch over seamlessly in the background to another server if the service is down.
On their own, however, these solutions have limitations.
A single back-up server in an xHA pair might fail, too. The failover process for DNS protocol is slow. You have to wait for the first server to time out before it will try the second option. Load balancers are usually managed outside of your DNS team, leaving you with no operational control.
But implement them all, and you’ve got a layered, comprehensive approach that provides high availability from multiple angles. Each can cover for the limitations of the other to keep your network up, banish downtime, and meet your service level agreements.
How DNS high availability architectures work
How does a high availability enterprise architecture setup generally work?
The server you connect to when you enter IP addresses is your initial entry point to the DNS enterprise. At this entry point in the data center, we implement an xHA scheme. If that first server goes down, a secondary DNS server seamlessly takes over.
In addition, a DNS load balancing system knows about all the other servers in the enterprise. It redirects to the one most available at any given point in time.
Furthermore, when we talk about DNS availability, we’re not just talking about servers. A server has DNS records on it. That information needs to be reachable regardless of where it resides. What happens if you make a change to it?
Our platform ensures that those records are sent to all the additional clusters of servers upstream. This allows DNS responses from anywhere in the enterprise. Each cluster knows about the others, making the enterprise truly interwoven. If any server goes down, the others can answer for it.
The BlueCat Address Manager—our central repository of all managed DNS information on the network—sits atop this enterprise. It pushes its data downstream to all the master servers in the environment. A path from a user’s computer to the central repository exists at all times. As long as a path exists, that connection is still running without interruption, preventing data loss.
Using DNS high availability to limit human errors
Implementing high availability is not a catch-all parachute to protect your network from faulty implementations or changes. A mistake at the top is still a single point of failure. It will replicate downstream and lead to an outage.
However, our platform can limit what users do. This can mitigate the risk of introducing error. And it can meet your redundancy and resiliency requirements.
That might mean, for example, actively preventing admins from deleting everything through access or change controls. Or implementing a string of stern warnings before they do.