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.

Subscribe to our blog

Get in touch

We’re the DDI provider you’ve been looking for.
Drop us a line and let’s talk.

Read more

BlueCat Enhances Cloud Discovery & Visibility Capabilities

BlueCat’s Cloud Discovery & Visibility offering now supports Microsoft Azure, giving network teams a single source of truth over more of their…

Read more!
Webinar: The myth behind AD and DNS

Graham Lockwood, Senior Solution Architect at BlueCat discusses what AD really needs from a DNS system, and provides information regarding best working…

Read more!
BlueCat brings DDI automation to ServiceNow

BlueCat now offers Gateway’s powerful automation capabilities through the ticketing infrastructure of ServiceNow.

Read more!
Webinar: Cloud Discovery & Visibility

Brian Shorland, BlueCat’s Director of Product Management, walks our webinar guests through a demo of our Cloud Discovery & Visibility feature.

Read more!

Customer Care Portal

Looking for more in-depth information on our products and services? Come get some.

(You’ll also find multi-channel support from our team of experts and your fellow BlueCat customers.)

Customer Care Portal

Training Portal

Are there some gaps in your DNS knowledge?
Not in ours.

From the basics to the not-so-basics, our Training Portal contains everything a NetOps team needs to know.

Training Portal

Products and Services

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

Learn more