Get a handle on your conditional forwarder DNS rules

When cloud applications move to different places, conditional forwarder DNS rules act as the network version of a detour sign. For a local DNS server to answer queries from a client, it needs to know the data’s location. When data moves, the conditional forwarding rule diverts queries to the correct location.

When you have independently managed DNS zones on your network, it can also get pretty complicated. Instead of sitting in a single, predictable location, DNS data is dispersed.

In modern hybrid cloud environments, the scale of conditional forwarding rules can get unmanageable quickly.

This post will define conditional forwarding. Then it will explore some of the downsides to too many conditional forwarder DNS rules and look at a real customer example. Finally, it will discuss ways BlueCat can help keep conditional forwarding under control.

What is a conditional forwarder?

Enterprises commonly use DNS forwarding rules to improve network performance and resilience.

First, a reminder of a standard domain name system (DNS) query. The query is either handled or forwarded on for resolution by the initial DNS server contacted by a client device.

With DNS forwarding, particular sets of DNS queries are forwarded to a designated server to resolve. They are forwarded according to the domain name in the query.

Conditional forwarders are DNS servers that only forward queries for a specific domain name. In a standard DNS lookup, the server attempting to resolve it would forward all queries it cannot answer locally. A conditional forwarder is configured to forward queries to a specific forwarder based on the domain name in the query. It essentially adds a name-based condition to the forwarding process.

The downside of conditional forwarders

In dynamic cloud or hybrid environments, these conditional forwarding rules can result in application failures across the enterprise.

First of all, the number of conditional forwarding rules can quickly become overwhelming. Think of all of the IP address data to account for in the cloud. And then think of all of the possible places it could end up. Now multiply all of those data points by all of the locations.

And now you have a rough sense of how many conditional forwarding rules might be needed.

Second, once a conditional forwarder is configured 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.

Without a centralized system to keep track of these rules, dropped connections, errors, and outages can happen. If you’re trying to maintain these rules manually (that is, without network 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 forwarder rules: A customer example

Recently, a large company with global operations and supply chains considered a move to BlueCat’s DNS management platform. They have an enormously complex network that spans on-prem and multiple cloud environments.

Actually, this is the simplified version. If it included all of their Active Directory DNS and Windows servers, it would number more than 100. To be sure, it would have looked something like a giant ocean blob of conditional forwarding rules.

For the sake of simplicity, BlueCat collapsed each Active Directory domain into one node on the diagram. This produced 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.)

Conditional forwarder DNS best practices

What can network administrators do when DNS conditional forwarders consume their time?

If you centralize and automate your DNS infrastructure, you have a solid baseline of functionality that conditional forwarders can call on. This is a necessary first step—a single source of truth must provide immediate answers about where assets reside.

But what happens you still need to call upon data from different places? BlueCat places software on a service point in the “first hop” of any DNS query. BlueCat calls it intelligent networking. 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. Sometimes a DNS query to a certain location may come back with an NXDOMAIN response. In those cases, BlueCat’s platform can send the query to an alternative location. And then another, down the administrator-defined chain until it gets an answer.

This avoids constant management of conditional forwarding rules. It cuts through the complexity of cloud deployments and dramatically decreases the need for maintaining all of those rules over time.

BlueCat offers a centralized portal for managing all of these rules. This reduces errors and ensures that forwarding rules stay current as underlying DNS architectures change.