Now customize all response codes in DNS Edge

Conditional forwarding can be useful during migrations and when relying on a central data center for query resolution.

BlueCat DNS Edge makes conditional forwarding even more robust. Using namespaces, it directs queries based on the queried domain, the source IP address, or even the DNS response code received.

Now, the latter feature has expanded to be fully customizable, giving admins even more control.

This post will first explore two common use cases for conditional forwarding. Then, it will examine BlueCat’s approach to conditional forwarding in DNS Edge using namespaces. Finally, it will delve into the details of its latest feature update that expands forwarding configuration for all DNS response codes.

Conditional forwarding use cases

For most domain name system (DNS) queries, a DNS servers either resolves them locally or forwards those that it cannot answer up the chain.

Meanwhile, conditional forwarders are DNS servers that only forward queries based on a specific domain name in the query. They essentially add a name-based condition to the forwarding process.

BlueCat sees two common use cases for conditional forwarding.

Migrating data center hardware

A common use case for conditional forwarding is data center migration. This could simply be migrating from old hardware to new hardware. Or it could be a migration from the data center to the cloud, perhaps for a hybrid cloud environment.

Regardless, network teams want these migrations to happen while trying to keep a seamless DNS query and resolution experience. In reality, that can be a tall order.

Network admins turn to conditionally forwarding the DNS queries from client devices while the migration to the new environment is underway.

Relying on a central data center for all query resolution

Another common use case presents itself when enterprises have multiple geographic locations but rely on a connection to a central data center for all DNS query resolution, regardless of final destination.

Many enterprises still use this legacy centralized data center model. It allows the data center to see, monitor, block, and/or allow network traffic according to policy or governance.

For example, you may have multiple branch offices along the U.S. eastern seaboard. But they all rely on query traffic going through one centralized data center in the Midwest. It’s no matter whether it’s Office 365, an internal application, or even just browsing the web. All that traffic is conditionally forwarded to a central data center.

Only once queries have first been forwarded to the central data center is traffic then delineated to its proper path. Admins can then, for example, route Office 365 to the closest Microsoft servers or send Google searches directly out to the primary DNS server for Google (8.8.8.8).

Routing architectures like this that require long round trips can often add latency. They can also create risks for the resiliency of your network. You’re depending on a single point of entry to resolve queries regardless of the geographic location of where the query is originating from.

BlueCat Edge’s approach to conditional forwarding

The number of conditional forwarding rules on a network can be overwhelming. Particularly in modern hybrid cloud environments, the scale can get unmanageable quickly. Before you know it, you’ve got a rat’s nest of rules that are nearly impossible to discover and keep track of. They are also brittle; one breaks and failure spreads across the enterprise.

BlueCat DNS Edge makes conditional forwarding a little smarter. In fact, we call it Intelligent Forwarding. With it, you can better optimize DNS resolution and improve network performance.

With DNS Edge, all queries pass through an Edge service point. Sometimes this is dubbed the “first hop”, because it is typically located at the recursive resolver closest to the originating client. Within each service point reside namespace configurations⏤a customizable set of forwarding rules.

The rules can direct a query to a specific set of forwarders. They can do so based on the queried domain, the source IP address of the client, and even the response code returned by the first set of forwarders.

With Edge, admins can also control who can set the conditional forwarder DNS rules and even who can override the default conditions.

Edge keeps a list of all of your namespaces. Furthermore, its query logs allow admins to see the path that a particular DNS query took. Its user interface shows all the namespaces utilized in the path to resolve a particular query. The query log will also show the corresponding response code next to each of the namespaces utilized to resolve each query.

Edge also allows you to provision multiple resolution paths in hybrid cloud environments, too.

Learn more about Intelligent Forwarding in this quick video:

New Edge feature for configuring response codes in namespaces

Now, the response code is entirely configurable. Admins can set any DNS response code as a triggering factor for a conditional forwarding action. This can include NXDOMAIN, SERVFAIL, REFUSED, or other response codes that indicate something is amiss.

Any DNS response code and chain of resolution visibility

Now, Edge can switch between namespaces to find a resolution path for any DNS response from the first set of forwarders. And, using its namespaces capability, continue to try forwarding rule after rule until it gets what it’s looking for.

This update will also allow admins to see the chain of resolution when these response codes are returned. A SERVFAIL won’t lay silently in the background. Instead, admins can see the reason why that query path chose the set of forwarders that it did to resolve it.

Here is an example of how namespaces can direct query traffic based on each response code condition:

Why this feature matters

In the traditional way that DNS is built, if your initial forwarding rule sends a client to something that no longer exists or is otherwise problematic, the client automatically gets an NXDOMAIN or other relevant error response code. With Edge, instead of returning the NXDOMAIN (or any other unwanted response, no matter the code is), it can try additional forwarding rules on your network until it can find a way to resolve.

This unique namespaces feature increases the resilience of your network infrastructure. And it essentially does by leveraging the DNS queries themselves. Conditionally forwarding queries based on queried domains, a client’s IP address, and⏤now⏤any query response code helps admins configure more efficient paths for resolution.

Using Edge strengthens network redundancy. And it provides a central management tool for all of your conditional forwarder DNS rules. Learn how BlueCat can help you get started. You can also delve into the details of namespaces and forwarders in our DNS Edge User Guide.