How to deal with too many conditional forwarder DNS rules

When you have a network of independently managed DNS zones, managing a network can get pretty complicated.  Instead of sitting in a single, predictable…

When you have a network of independently managed DNS zones, managing a network can get pretty complicated.  Instead of sitting in a single, predictable location, DNS data is dispersed.  In order for a local DNS server to answer queries from a client, the server needs to know where the data is located.

This is where DNS conditional forwarding rules come in.  When cloud applications are moved to different places, conditional forwarding rules act as the network version of a detour sign.  When data is moved, the conditional forwarding rule diverts queries to the correct location.

The downside of DNS conditional forwarders

Here’s the thing:  in dynamic cloud or hybrid environments, these conditional forwarding rules can become a source of application failures across the business.

First of all, the number of conditional forwarding rules can quickly become overwhelming.  Think of all of the IP address data that needs to be accounted for in the cloud, and all of the possible places it could end up.  Multiply all of those data points by all of the locations, and you have a rough sense of how many conditional forwarding rules might be needed.

Second, just setting up a conditional forwarding rule doesn’t mean you’re done.  When the network architecture changes, or when DNS domain data moves around, that conditional forwarding rule has to change as well.  Maintaining all of those rules is a gargantuan task over time and inevitably leads to inconsistencies.

If you don’t have a centralized system to keep track of these rules, they can easily result in dropped connections, errors, and outages.  If you’re trying to maintain these rules manually (that is, without automation), the resource implications are enormous.  Plus, it’s not like network architectures are getting more streamlined these days.  If anything, the back-end is getting more complex by the day, meaning even more conditional forwarding rules to come.

Mapping conditional forwarding rules

BlueCat is currently working with a customer who is considering a move to our centralized, automated DNS management system.  This is a large, well-known company with operations and supply chains all around the world.  They have an enormously complex network which spans on-prem and multiple cloud environments.

We decided to map their conditional forwarding rules to demonstrate just how complex their network had become over time.  Here’s what it ended up looking like:

Actually, this is the simplified version.  If we included all of their Active Directory DNS and Windows servers, which is over 100 servers, it would have just looked like a giant blob of conditional forwarding rules.  For the sake of simplicity [!] we collapsed each Active Directory domain into one node on the diagram, producing a more manageable fourteen nodes to deal with.  (These 14 nodes were forwarding to a lot of unidentified DNS servers. These are the other nodes on the diagram.)

DNS forwarders best practices

What can network administrators do when their lives are consumed by DNS conditional forwarders?  The answer lies in what BlueCat likes to call intelligent DNS.  Here’s how it works. 

When your core DNS infrastructure is centralized and automated, that provides a solid baseline of functionality which conditional forwarding rules can call on.  This is a necessary first step –a single source of truth must provide immediate answers about where assets reside. 

If there is still a need to call upon data from different places, BlueCat then places software on a service point in the “first hop” of any DNS query.  This allows administrators to steer DNS traffic coming off of any client device.

Using this infrastructure, administrators can then set up a logic for answering queries.  If a DNS query to a certain location comes back with an NXDOMAIN response, BlueCat’s software can send the query to an alternative location.  And then another one, down the administrator-defined chain until an answer is received.

This prevents the need for constant management of conditional forwarding rules, cutting through the complexity of cloud deployments and dramatically decreasing the need for maintaining all of those rules over time.  BlueCat also offers a centralized portal for managing all of these rules, reducing errors and ensuring that forwarding rules stay current as underlying DNS architectures change.

Learn more about BlueCat intelligent networking.

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.

Join the conversation

Read more

Five cloud challenges for DDI and how to beat them

The cloud-first transition has splintered network visibility and control for NetOps. But the DNS, DHCP, and IPAM hurdles they face can be overcome.

Read more
Seven best practices to keep your NTP resilient

When NTP, which synchronizes network clocks, gets off-kilter, DNS and other network disruptions follow. Keep your NTP in shape with BlueCat’s expert tips.

Read more
Six non-hype network automation lessons from IT pros

Five IT pros get real about network automation during the first Critical Conversation on Critical Infrastructure hosted in the Network VIP community.

Read more
BlueCat’s DDI Adaptive Plugins and Applications help IT teams better leverage ServiceNow, Ansible, Microsoft, and more

A growing suite of Adaptive Plugins and Applications will help automate existing BlueCat capabilities along with adjacent customer technologies.

Read more

Products and Services

From Core Network Services to multicloud management, BlueCat has everything you need to build the network you need.

Learn more