Last updated on June 21, 2021.
In hybrid enterprises, the network team often has to find ways to bridge the gaps in DNS resolution between cloud and on-premises environments.
This commonly results in building and managing conditional forwarding DNS rules. It is easy to end up with thousands of rules to patch everything together.
Automation might help sort out this unwieldy mess, but public cloud DNS services fall short. And cloud DNS doesn’t allow for centralized control and management of enterprise-wide DDI, either. (DNS, DHCP, and IPAM are together known as DDI.)
This post will examine how and why network teams frequently use conditional forwarding rules to bridge the cloud and on-premises DNS management gap. Furthermore, it will delve into some of the consequences of forwarding rule complexity. Finally, it will explore how, with a single source of truth for DDI, network teams can use BlueCat’s automation tools to gain control over pathways of data and compute.
This post is part of a blog series exploring some of the challenges network teams experience in the face of enterprise cloud adoption—and how BlueCat can help solve them.
The complexity of a hybrid cloud network infrastructure
Undoubtedly, there are DNS-related challenges associated with a patchwork of hybrid cloud infrastructure. Hybrid cloud may range from portable workloads moving and scaling across data centers and clouds to simple dependencies across them. Often, the network team finds itself building and managing conditional forwarder DNS rules to bridge the gaps between different environments.
A rat’s nest of forwarding rules
Best practices offered by public cloud vendors push organizations to spin up private clouds in many regions. Each has separate networks to isolate critical functions and provide security controls. Add that to the scale and speed of cloud adoption at many large enterprises and it is easy to end up with thousands of conditional forwarding rules to patch everything together.
Furthermore, as workloads move and new applications are developed, these rules will need constant updating. Conditional forwarding rule management quickly becomes someone’s full-time job.
This creates unmanageable complexity in many organizations. It falls to a single person or a small group of experts to maintain this rat’s nest of routing and forwarding rules. Only they actually understand how the system of rules was built and how to maintain it. Their full-time job becomes the maintenance of these rules.
This pulls resources away from more important things, like bringing critical new services to end-users and customers quickly.
Public cloud DNS falls short
Ordinarily, administrators want to apply some kind of automation to sort out this mess. The challenge is that none of the public cloud DNS services support automation outside of their own environment.
Maintaining dozens of islands of automation for each of the cloud instances is just more trouble than it’s worth. Consequently, organizations turn to complex overlay solutions that again require constant maintenance and development to keep up with business requirements.
Assembling or reassembling networks is highly manual and error-prone, especially when provisioning new cloud environments. Network teams want to provision services with speed using cloud and third-party applications.
The impacts of complexity in DNS forwarding rules
Certainly, a mess of DNS forwarding rules subjects the network to risks for delays, outages, and suboptimal balancing. But, ultimately, it leaves network teams with even less control.
The jumbled disarray of forwarding rules can result in slow service delivery. And when DevOps and cloud teams that are used to moving at breakneck speed encounter slow-downs, they can resort to their own IT solutions. Shadow IT and unknown or unnecessary IT expenses apart from network teams’ purview can crop up and become the norm.
Furthermore, to avoid dealing with the convoluted mess, users (whether cloud, DevOps, or even a network team member) create their own forwarding rules instead. A workaround for them, sure. But in the end, it’s just complexity begetting even more complexity.
Worse, any influence or authority that network teams had over cloud decisions further erodes.
BlueCat connects cloud and on-prem DNS without adding complexity
BlueCat gives network teams the control they need over pathways of data and compute flowing through hybrid cloud environments.
With the foundation of a standardized DDI infrastructure in place, BlueCat uses automation to solve the problem of conditional forwarders (and stub zones, zone overlap, and more).
Here’s how: Instead of managing a complex and changing set of single-option DNS resolution paths, network teams can use BlueCat’s Intelligent Forwarding to provision multiple resolution possibilities. If the first DNS query comes back with an NXDOMAIN response, the query will automatically re-route to the next priority location. The solution continues to attempt multiple paths until it finds the right answer.
Learn more about Intelligent Forwarding in this video:
Managing multiple resolution paths across a hybrid cloud environment is much easier when they are all represented in a single IPAM interface. That enables network administrators to have the enterprise-level visibility and control of DDI needed to operate hybrid cloud environments at scale, taking full advantage of the nimble DevOps and cloud development tools.
Upcoming blog posts will explore the biggest hybrid cloud challenges for DDI. And they will highlight the solutions that BlueCat offers to alleviate them. In the meantime, read the Using BlueCat Adaptive DNS in the Cloud whitepaper.