Forwarders vs Root Hints DNS: Choosing Resolution

Forwarders vs. Root Hints: Choosing How to Resolve External DNS

An internal DNS server can resolve external names by sending queries to designated resolvers or by walking the public hierarchy from root servers. Both paths work, but they have different consequences for filtering, privacy, traceability, firewall rules, and dependency. The common mistake is configuring forwarders and forgetting that root hints can serve as a fallback.

[!TIP]
The external path should be a visible decision, not the residual of defaults. Design failure as carefully as success and keep internal authority separate.

Why This Matters for Forwarders vs Root Hints DNS

How your DNS resolves external names determines what your upstream provider sees, how filtering policies are enforced, and what happens when things break. Forwarders give you centralized control but create dependency. Root hints give you independence but require broader egress and more operational overhead. Neither is universally "better" — it depends on your requirements.

Two Architectures, Not Two Speeds

With forwarders, your internal DNS delegates external recursion to one or more upstream resolvers. This centralizes logging, filtering, and policy but introduces dependency and sends query information to the provider. With root hints, the server contacts the root and follows references to TLDs and authoritative servers; this requires broader UDP/TCP 53 egress and its own cache management.

Microsoft documents cache.dns as the root hints base and fallback behavior based on configuration. If policy requires every query to pass through a security service, disabling root hints as an alternative is part of the requirement. If you need independence from upstream, maintain and test the iterative path.

What You Need

• Defined networks that can perform recursion vs. those that only receive authority
• Confirmed clients use internal DNS (no public resolvers on adapters)
• Documented upstreams, contracts, filtering, DNSSEC, and retention
• Validated UDP and TCP 53 (truncated responses may switch to TCP)
• Configuration, cache, timings, and results captured from more than one site

Get-DnsServerForwarder
Get-DnsServerRootHint
Get-DnsServerRecursion
Resolve-DnsName 'www.example.com' -Server '<INTERNAL_DNS_IP>' -DnsOnly

Step-by-Step: Configuring Forwarders

Step 1 — Set Approved Forwarders

Use approved addresses, at least two when the service allows, and avoid long lists without studying timings. Microsoft explains that ForwardingTimeout and RecursionTimeout limit how many upstreams get tried.

$forwarders = @('192.0.2.10','192.0.2.11')
Set-DnsServerForwarder -IPAddress $forwarders -PassThru
Get-DnsServerForwarder |
  Select-Object IPAddress, ForwardingTimeout, UseRootHint

The TEST-NET addresses are documentation placeholders. Replace them and test each upstream directly from the DNS. Then clear only the test name's cache if you need to measure a cold path — flushing the entire cache during production hours increases traffic and hides evidence.

Step 2 — Validate Behavior Including Failure

Test an authoritative internal name, an existing external name, a non-existent name under a controlled domain, and a large response that might use TCP. Log time and server. Block an upstream only in a lab or approved window to demonstrate failover — don't simulate results.

With root hints, verify the network allows reachability to root/TLD/authoritative servers and that Get-DnsServerRootHint returns entries. With mandatory forwarders, demonstrate that when both fail, you get a controlled failure and not an unexpected direct exit.

Step 3 — Test from Client Subnets

A local query doesn't traverse the same path as a client query. From a pilot subnet, explicitly use the new DNS IP, log time, name, record type, and result. Only then change DHCP or static configuration.

Common Pitfalls

• SERVFAIL after several seconds? Upstream timeout, recursion exhausted, or egress blocked. Test from the server, check timings and each upstream.
• UDP works, some domains fail? TCP 53 blocked or large responses. Validate TCP end-to-end and EDNS per documentation.
• Filtering bypassed during an outage? UseRootHint allows fallback. Align the option with policy and test the failure.
• Only fails from clients? Client uses a different DNS or ACL/firewall between segments. Confirm ipconfig /all and actual path.
• Fourth forwarder never gets queries? RecursionTimeout expires before reaching it. Reduce the list or design highly available upstreams.

Alternative Open-Source Options

• Unbound — built for recursive resolution with root hints by default. Excellent for environments that want to avoid forwarder dependency.
• BIND — supports both forwarders and root hints with fine-grained control over timeouts and fallback behavior.
• dnsmasq — simpler forwarding-only model. Good for small networks that don't need full recursive resolution.

Conclusion

The external path must be a visible decision, not the residual of default values. Design failure as carefully as success and keep internal authority separate from external resolution.

Try It

Run Get-DnsServerForwarder and Get-DnsServerRootHint on your DNS server right now. Check what's configured — you might find forwarders pointing to IPs nobody remembers setting, or root hints that haven't been updated in years.

Related Posts

• Conditional Forwarders for Cross-Org DNS — route specific suffixes to partner DNS
• Install the DNS Role on Windows Server With PowerShell — get the DNS engine running first
• Forward and Reverse DNS Zones Without Operational Gaps — design paired zones with clear authority