DNS forwarding is a mechanism that allows a DNS server to send queries it cannot answer locally to another DNS server for resolution. The DNS server that receives and processes these forwarded queries is called a DNS forwarder.
Understanding how DNS forwarding works, how forwarders differ from root hints, and when to use conditional forwarding, forwarding zones, or stub zones helps administrators choose the right resolution path for different DNS environments. A common misconception is that a DNS forwarder is a separate type of DNS server. In reality, forwarding is a role a DNS server performs in the resolution process.
Forwarders vs root hints: How DNS resolvers handle unknown queries
When a recursive DNS server receives a query it cannot answer from its local data or cache, it needs an upstream resolution path. It can use root hints to begin resolution from the DNS root, or it can forward the query to another DNS server configured to resolve it.
The choice determines where recursive resolution takes place and where an organization's external DNS queries are sent.
The root hints approach
Root hints are a list of the IP addresses of the DNS root servers that a recursive DNS server can use to begin iterative resolution. When forwarding is not configured, the DNS server can use these addresses to start resolving queries it cannot answer locally.
The server then follows referrals through the DNS hierarchy until it reaches the authoritative server for the requested domain and obtains the answer. The recursive server performs this resolution itself rather than relying on another DNS server to do it.
This approach gives the server a direct path to authoritative DNS infrastructure and does not require a separate upstream recursive resolver.
Learn more on how DNS works here.
The forwarder approach
When forwarding is configured, the DNS server sends eligible queries to one or more designated forwarders instead of starting resolution from the root servers itself. The forwarder is typically another recursive DNS server that either answers the query from its cache or performs the required upstream resolution and returns the result.
This changes where the recursive work takes place. The local DNS server handles the client query, while the forwarder handles resolution beyond that server.
A forwarding arrangement can:
- Centralize recursive resolution: Multiple DNS servers can send queries to shared forwarders and benefit from answers already present in the forwarder's cache.
- Provide a controlled DNS path: Organizations can route external DNS queries through designated servers for security monitoring, DNS filtering, or policy enforcement.
- Limit direct internet access: Local DNS servers do not necessarily need direct outbound DNS access to internet root and authoritative servers, which can simplify firewall policies.
- Support distributed and hybrid environments: Forwarders can provide a defined path to DNS services in other networks, including cloud and private environments.
The trade-off is that forwarding introduces a dependency on the configured forwarder. Depending on the DNS server's configuration, it may attempt another resolution path if a forwarder is unavailable. In forward-only mode, however, the server does not fall back to direct resolution through root hints. If its configured forwarders cannot answer, the query fails.k
Forward-only mode is therefore appropriate only when all applicable DNS queries must pass through the designated forwarders, such as when an organization requires external DNS traffic to go through a security or policy-enforcement layer.
Types of DNS forwarding
DNS forwarding can be configured globally, so eligible queries use the same upstream DNS servers, or conditionally, so queries for specific domains are sent to specific DNS servers.
Unconditional forwarding (regular forwarders)
An unconditional forwarder applies to eligible queries that the local DNS server cannot answer from its authoritative zones or cache. Those queries are sent to the configured forwarder without considering the queried domain.
This is the simplest forwarding configuration and is useful when:
- You want external DNS queries to pass through a specific upstream resolver, such as a corporate DNS proxy, security-filtering DNS service, or trusted public resolver.
- Your environment has a relatively simple DNS structure where a common upstream resolver can handle external queries.
- You want to centralize external DNS resolution rather than allowing individual DNS servers to resolve queries directly from the DNS root.
For example, an internal DNS server at a branch office could be configured to forward external queries to Google Public DNS at 8.8.8.8. A query for a public website that the branch DNS server cannot answer locally would be sent to the configured forwarder, which resolves the name and returns the result.
Conditional forwarding
A conditional forwarder applies only to queries for a specified domain or namespace. When a query matches that domain, the local DNS server forwards it to the DNS server configured for that namespace. Queries that do not match the condition follow the resolver's other configured resolution path, such as a regular forwarder or root hints.
For example:
| DNS namespace | Forward query to |
|---|---|
| aws-internal.corp.com | DNS server that can resolve the AWS private namespace |
| azure-internal.corp.com | DNS server that can resolve the Azure private namespace |
| All other domains | Regular forwarder or root hints |
In an AWS environment, an on-premises DNS server might forward queries for a private namespace to the DNS resolver available within the relevant VPC. In an Azure environment, DNS queries for names available through an Azure VNet can similarly be directed to the DNS infrastructure that can resolve those names.
Conditional forwarding is useful in hybrid cloud environments, where an on-premises DNS server needs to resolve private names that exist only within a cloud network. Public DNS is not authoritative for these private namespaces, so sending such queries to a general public resolver will not provide the required answer. A conditional forwarder directs the query to a DNS server with visibility into the private namespace instead.
Conditional forwarding is also useful when two organizations need to resolve each other's namespaces during a merger or acquisition. For example, queries for acquired.example.com can be forwarded to DNS servers in the acquired environment while the two DNS infrastructures are being integrated.
The key difference is therefore simple. Unconditional forwarding determines where general upstream queries go, while conditional forwarding determines where queries for specific namespaces go.
DNS forwarding zone vs forward lookup zone
DNS forwarding zones and forward lookup zones are frequently confused because their names sound similar. They serve fundamentally different purposes: a forwarding configuration tells a DNS server where to send queries, while a forward lookup zone contains authoritative DNS data used to answer queries.
| DNS forwarding zone | Forward lookup zone | |
|---|---|---|
| What it is | A forwarding configuration that directs queries for a specific DNS namespace to designated DNS servers | An authoritative DNS zone that contains resource records for a domain or namespace |
| What it contains | Forwarding instructions, such as the DNS servers to which matching queries should be sent | DNS resource records such as A, AAAA, CNAME, MX, TXT, SRV, NS, and SOA records |
| Purpose | Send queries for a namespace to another DNS server without hosting that namespace locally | Provide authoritative answers for records within the zone |
| Example | A BIND type forward configuration for cloud.corp.local that sends queries to DNS servers in the cloud environment | A corp.local zone containing authoritative records for hosts and services in that namespace |
DNS forwarding zones in BIND
In BIND, a forwarding zone is expressed with type forward; and a forwarders { }; block in named.conf. It is functionally equivalent to a conditional forwarder in Windows Server DNS. In both cases, the zone contains no records and it is purely a routing instruction.
Forwarder vs resolver
A DNS resolver receives DNS queries from clients and obtains answers on their behalf. A recursive resolver can perform the resolution process itself, contacting other DNS servers as needed to find the authoritative answer.
A DNS forwarder is a DNS server that receives queries from another DNS server and handles those queries on its behalf. In a common enterprise configuration, the forwarder is itself a recursive resolver: it can answer from its cache or perform the required resolution and return the result to the DNS server that forwarded the query.
The distinction is therefore positional, not architectural. The same DNS server can perform both roles at the same time.
For example, suppose a branch DNS server forwards an unresolved query to a central DNS server. The central server is acting as a forwarder from the branch server's perspective. If an end-user device sends a query directly to that same central server, the central server is acting as the resolver for that client.
The DNS server software does not change between these interactions. What changes is the server's role in the DNS request path.
| DNS resolver | DNS forwarder | |
|---|---|---|
| Receives queries from | Clients or applications | Other DNS servers |
| Primary role | Resolve DNS queries for clients | Handle queries delegated by another DNS server |
| Can perform recursive resolution? | Yes, for a recursive resolver | Often yes, when the forwarder is a recursive DNS server |
| Relationship | Directly serves the requesting client | Serves another DNS server |
For a detailed explanation of recursive resolvers, stub resolvers, and how resolvers differ from authoritative DNS servers, see our guide to what is a DNS resolver.
When to use DNS forwarding
DNS forwarding is most useful when an organization wants to control where unresolved DNS queries are sent rather than allowing every DNS server to perform recursive resolution independently. Common use cases include distributed sites, hybrid environments, centralized DNS security, and networks with restricted outbound access.
Branch offices and distributed sites
Organizations with multiple branch offices can configure local DNS servers to forward external queries to centralized recursive resolvers. This provides a consistent upstream resolution path and allows the organization to apply common DNS policies, monitoring, and filtering at the central resolvers. Centralized forwarders can also make cached responses available to queries from multiple sites, reducing the need for each local DNS server to independently resolve the same external names.
Hybrid and multi-cloud environments
Forwarding is particularly useful when DNS namespaces span on-premises infrastructure and private cloud networks. An on-premises DNS server can use conditional forwarding to send queries for a cloud-private namespace to DNS infrastructure that can resolve those names. The same principle works in the opposite direction: cloud-based DNS infrastructure can forward queries for on-premises namespaces to DNS servers reachable through the organization's private network connection.
This approach avoids publishing private DNS records to public DNS and gives each environment a defined path for resolving names that exist outside its local DNS namespace.
DNS security and filtering
Organizations that use a security-focused DNS service can configure internal DNS servers to forward external queries to that service. The upstream service can apply security policies, threat intelligence, category filtering, or other controls before returning a DNS response. This architecture centralizes external DNS policy instead of requiring each internal resolver to independently enforce the same controls.
Networks with restricted internet access
Some networks allow only designated systems to communicate with external DNS infrastructure. In such environments, internal DNS servers can forward external queries to an approved DNS relay or recursive resolver while remaining blocked from making direct outbound DNS connections. This limits the number of systems that require internet access on DNS ports and provides a single point where outbound DNS traffic can be monitored and controlled.
Separate or independently managed DNS environments
Forwarding can also connect DNS namespaces that are managed independently. For example, during a merger, acquisition, or phased infrastructure migration, one DNS environment can forward queries for the other organization's namespace to its existing DNS servers. This allows users and applications to resolve names across both environments without immediately consolidating their DNS infrastructure.
Stub zones: A forwarding alternative
A stub zone is an alternative to a conditional forwarder for connecting DNS servers that manage different namespaces. Both can direct queries for a specific domain toward another DNS environment, but they do so differently.
A stub zone stores limited information about a remote DNS zone, primarily its NS records, along with the SOA record. It does not contain the remote zone's complete set of resource records. When the local DNS server receives a query for a name within the stub zone, it uses the authoritative server information maintained by the stub zone to query the remote zone's authoritative DNS servers.
Here's the main difference:
- A conditional forwarder sends matching queries to a designated DNS server. That server typically acts as a recursive resolver and can answer the query from its cache or resolve it further.
- A stub zone maintains information about the authoritative servers for the remote zone and allows the local DNS server to query those authoritative servers directly.
| Aspect | Conditional forwarder | Stub zone |
|---|---|---|
| What is stored locally? | The destination DNS server(s) for the specified domain. | NS, SOA, and related information about the remote zone's authoritative servers. |
| Where does the query go? | To the configured DNS forwarder. | To an authoritative DNS server discovered from the stub zone information. |
| Role of the remote server | Typically a recursive DNS resolver. | Authoritative DNS server. |
| Who performs the resolution? | The forwarder resolves the query and returns the answer. | The local DNS server queries the remote authoritative server directly. |
| Common use | Private namespaces, hybrid cloud environments, and centralized DNS services. | Independently managed or delegated DNS namespaces where authoritative server information may change. |
Stub zones are useful when the remote namespace has its own authoritative DNS infrastructure and you want the local DNS server to discover and query those authoritative servers directly. Conditional forwarders are generally simpler when a designated recursive DNS server or cloud-provided DNS resolver should handle queries for the remote namespace, making them a common choice for hybrid cloud environments.
What to avoid when configuring forwarders
Forwarding simplifies DNS resolution, but poorly designed forwarding paths can introduce unnecessary dependencies or prevent private namespaces from resolving correctly. Three common problems are worth avoiding.
Chained forwarders: A chained forwarding arrangement occurs when Resolver A forwards a query to Resolver B, which then forwards it to Resolver C before the query is resolved. Each additional forwarding layer introduces another dependency and can add latency, particularly when the query has to traverse multiple networks before reaching a resolver that can provide the answer. Where possible, use a direct and predictable forwarding path rather than unnecessary intermediate forwarders.
Sending private DNS queries to public resolvers: A public resolver such as 8.8.8.8 generally has no authority or private-network visibility for an organization's internal DNS namespaces. Sending queries for private hostnames to such a resolver therefore cannot resolve those names. Internal zones should be answered by the DNS infrastructure that hosts or can resolve them, while external queries can be forwarded to the appropriate upstream resolver.
Leaving stale conditional forwarder addresses: Conditional forwarders commonly reference specific DNS server IP addresses. If one of those addresses changes because of a resolver migration, cloud-network change, or connectivity redesign, the conditional forwarding configuration must be updated accordingly. Otherwise, queries matching that namespace may fail until a reachable forwarder is configured. Treat forwarder addresses as part of the DNS infrastructure configuration and update them whenever the referenced DNS service changes.
Manage DNS forwarding with ManageEngine OpUtils
ManageEngine OpUtils helps network administrators manage DNS infrastructure across Microsoft DNS and AWS Route 53 environments from a centralized console. It provides visibility into DNS records and resolution, helping administrators identify DNS issues that can affect connectivity across on-premises and cloud environments.
For Microsoft DNS environments, OpUtils supports DNS management, including visibility into DNS zones and records. For AWS Route 53, administrators can monitor and manage hosted zones and DNS records alongside their broader IP address management workflows.
This visibility is useful when troubleshooting DNS forwarding issues. If a DNS record is incorrect, a resolution path is failing, or DNS information is out of sync with IP address assignments, administrators can investigate the DNS configuration alongside IPAM data instead of troubleshooting these systems in isolation.
OpUtils also brings DNS, DHCP, and IP address management into a single platform, helping administrators maintain better visibility across the infrastructure that underpins name resolution.
Download a free 30-day trial or schedule a personalized demo to explore DNS management capabilities in OpUtils.
FAQs on DNS forwarding
What is a DNS forwarder?
A DNS forwarder is a DNS server that receives queries from another DNS server and handles them on its behalf. In a common configuration, the forwarder is a recursive DNS resolver that can answer from its cache or perform the required recursive lookup and return the result to the querying DNS server.
A DNS server can act as both a resolver for client devices and a forwarder for queries received from other DNS servers.