A forwarding DNS server is a DNS server that delegates queries it cannot answer to designated upstream servers rather than performing full resolution itself, caching responses for repeated local lookups to improve performance and reduce outbound traffic. This architecture centralizes external name resolution, logging, and filtering at upstream servers while allowing branch offices and internal sites to run lightweight forwarders instead of full recursive resolvers. However, forwarding creates dependencies on upstream server availability and correctness, requiring careful management of forwarder lists, monitoring of response times, and proper configuration of conditional forwarding rules to avoid outages, security risks, and hard-to-diagnose failures.
How forwarding DNS server works
A forwarding DNS server is configured with one or more upstream servers, called forwarders. It answers what it can from local data or cache and hands everything else to those upstream servers.
- Client query: A client or stub resolver sends a recursive query for a name to the forwarding DNS server.
- Local check: The server checks the zones it hosts and its cache. If it holds a valid answer, it replies immediately.
- Forward upstream: If no answer is available, the server sends the query to a configured forwarder with the recursion desired flag set, asking the upstream server to do the full resolution.
- Upstream resolution: The upstream server resolves the name, usually by walking the DNS hierarchy from the root, or answers from its own cache.
- Cache and reply: The forwarding server receives the answer, stores it for the duration of its time to live, and returns it to the client.
Many implementations support conditional forwarding, which sends queries for specific domains to specific servers, such as a partner network's DNS servers. Some can fall back to their own iterative resolution if forwarders do not respond, while others can be set to forward only and fail the query instead.
Common forwarding DNS server issues
If every configured forwarder is unreachable, clients fail to resolve external names even though the local server is healthy. Listing at least two forwarders on separate paths reduces this risk.
Two servers configured to forward to each other, or a chain that circles back, cause queries to bounce until they time out. Symptoms are slow lookups and SERVFAIL responses for names that resolve elsewhere.
Sending queries for internal domains to a public upstream server returns NXDOMAIN or wrong answers. Conditional forwarding or locally hosted zones for those domains avoids this.
The forwarder caches whatever the upstream server returns, so a bad answer persists until its TTL expires. Flushing the cache fixes the local copy but not the upstream source.