Designing DNS conditional forwarders for an isolated network that must resolve only vendor domains

A tightly isolated network can resolve approved vendor namespaces through conditional forwarders while restricting outbound DNS, logging change and validating failover.

1. Conclusion and scope

A conditional forwarder is not intended to give the internal network general internet access. It sends queries for named namespaces through an approved resolver path. The design must cover namespace boundaries, upstream resolvers, TCP and UDP 53, consistency between DNS servers, caching and vendor CDN changes.

This issue involves DNS, networks, VPN, firewall and controlled access. Validate query path, ports, return traffic and logging in layers.

2. Risk signals that deserve priority

• Business clients need only update, licensing or API names while general internet access must remain blocked.
• A global forwarder would send every unknown query outside the network and violate the intended security boundary.

3. Pre-change assessment checklist

1. Ask the vendor for required parent domains, subdomains, CNAME chains and CDN use rather than collecting only current IP addresses.
2. Confirm upstream resolver addresses, access control, logging retention and bidirectional TCP/UDP 53 policy.
3. Compare conditional-forwarder, timeout, recursion and cache settings on both internal DNS servers.
4. Check whether internal zones, stub zones or hosts entries could intercept the required namespace.

Get-DnsServerConditionalForwarderZone
Resolve-DnsName vendor.example -Server 192.0.2.53
Get-DnsServerCache
Clear-DnsServerCache -Force

4. Recommended implementation sequence

1. Create forwarders for the minimum necessary namespaces, using a manageable parent-domain boundary where appropriate.
2. Allow only the authorised DNS servers to reach approved upstream resolvers; block clients from sending DNS directly outside.
3. Synchronise both DNS servers, clear caches and test A, AAAA, CNAME and negative responses separately.
4. Maintain a vendor-domain change register and periodic review rather than a permanent list of CDN IP addresses.

5. Validation, rollback and common mistakes

• Approved names resolve reliably while unrelated external names still fail according to policy.
• Clients continue to resolve through the secondary DNS server when the primary is unavailable.
• DNS and firewall logs show the intended path and no client bypass of internal DNS.

Common mistakes

• Leaving the forwarder target empty or pointing it to an unreachable resolver.
• Allowing only UDP 53 and forgetting TCP 53 for large responses and fallback.
• Treating the current CDN address set as permanent.

Frequently asked questions

Does a conditional forwarder give users internet access?

No. It controls DNS resolution only; routing and firewall rules still govern actual connections.

Must CDN IP addresses be tracked continuously?

Usually no. Let DNS return changing addresses and enforce the business access policy at the appropriate layer.