How to deal with too many conditional forwarder DNS rules

BY Ben Ball

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.

Ben Ball

Ben Ball is a Government Market Manager at BlueCat, handling business development and marketing outreach in the Federal, State, and local government markets. Ben served for ten years as a Federal employee, with three tours as a Foreign Service Officer (Saudi Arabia, Turkey, Jordan), and five years at the Department of Homeland Security, where he focused on immigration issues. A graduate of the Fletcher School of Law and Diplomacy and Pitzer College, Ben lives in the San Francisco Bay Area.

View more articles by Ben Ball