DNS high availability keeps your network humming
Does your infrastructure support DNS high availability? If you have just one DNS server, what happens if you experience a system failure? Suddenly, your network stops and your website can’t be found.
You want to be certain that your mission-critical networks can keep humming along even if that server grinds to a halt.
BlueCat buoys the operational performance of your enterprise with a comprehensive and layered approach to availability that banishes downtime.
In this post, we’ll look at why this is so important. Then, we’ll explore four avenues, that, when implemented together, create an overlapping and comprehensive solution. We’ll also delve into how these kinds of architectures work. And finally, we’ll look at how our platform can help to reduce the types of human errors that cause failures in the first place.
Welcome to disaster recovery without the disaster.
Why DNS high availability matters
Let’s say you want to visit bluecatnetworks.com. You type the URL in your web browser, and your computer or smartphone does nothing. No bueno.
You use DNS every single time you try to get somewhere on the internet. So, if bluecatnetworks.com has just one DNS server, and if that server goes down, bluecatnetworks.com becomes unreachable.
You want to make sure that your presence on the internet is uninterrupted, even if a server experiences an error. This is the definition of high availability: it aims to ensure a certain level of operational performance or uptime for a system. And the more highly available it is, the less downtime you’ll have. In many cases, a service-level agreement may mandate a certain percentage of uptime.
The key is an availability configuration that is both redundant and resilient, with failover at the ready. Furthermore, it requires a solution that eliminates single points of failure associated with particular components and computer systems.
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 solution that maximizes your uptime.
It starts with building the right systems 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. This process is called failover.
DNS itself is also inherently a redundant protocol. If one server doesn’t respond, it will purposely failover to another server instead. It 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. 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 network team, leaving you with no operational control.
But implement them all, and you’ve got a layered, comprehensive approach from multiple angles. Each can cover for the limitations of the other. You can keep your network up, banish downtime, and meet your service level agreements.
How DNS high availability architectures work
How does this kind of enterprise architecture setup generally work?
The server you connect to when you enter IP addresses is your initial entry point to the network. 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.
Also, a 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 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?
The BlueCat 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.
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 this 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.
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. Learn more about how the BlueCat platform can help you to eliminate costly human DNS errors and keep your network running.
Critical conversations on critical infrastructure
Find out how your peers are managing their networks through profound change. Watch this series of live interactive discussions with IT pros & join the debate in Slack.
Why McMaster University didn’t want another CIO
McMaster’s CTO, Gayleen Gray, highlights the importance of her unique role in a world where expectations of the CIO and CTO are colliding.
Customer situation brief on SUNBURST/Solorigate
Learn more about the attack via the SolarWinds Orion platform and how BlueCat products use DNS to help protect customers against compromises like it.
IT pros debate: Who should own DNS in the cloud?
Six networking pros dig into who should own DNS in the cloud during the third Critical Conversation on Critical Infrastructure hosted in Network VIP.
Flexibility and security can co-exist for the Red Cross
American Red Cross CISO Vikas Mahajan discusses flexible security strategies for front-line operations and his roadmap for moving toward a SASE model.