Our organization uses the same domain, example.domain, for both internal and public services. A Windows Server running Active Directory DNS serves LAN clients and contains records for internal-only systems, while BIND9 serves the DMZ and public-facing records.
Internal clients must reach DMZ services through the WAN using hairpin NAT; direct routing from the LAN to the DMZ is not allowed. We also cannot change the domain structure, use separate internal or DMZ subdomains, or rely on wildcard records.
The problem is that Windows DNS is authoritative for the entire zone. When it receives a query for a hostname it does not know, it returns NXDOMAIN instead of forwarding the request to BIND9. Is there a supported Windows DNS configuration—such as zone delegation, conditional forwarding, or DNS policies—that allows Windows DNS to answer records it owns while forwarding unknown names in the same zone to BIND9? If not, what is the least painful operational design?
4 Answers
For a Windows-and-BIND setup with one shared zone, the practical choices are usually duplicating the needed records or automating synchronization. Keep the authoritative data in one controlled source and use Ansible, PowerShell, or a small DNS-management script to publish the public or DMZ records into Windows DNS. Include validation, change logging, and deletion handling so stale records do not accumulate. It is less elegant than split namespaces, but it is predictable and easier to troubleshoot than relying on unsupported DNS behavior.
The cleanest design would be separate internal and external namespaces, or at least delegated subdomains. You could create the relevant subdomain on the Windows server and delegate it to BIND9, allowing BIND to manage all records beneath that delegation without copying each record. If changing the naming scheme is genuinely prohibited, that option is unavailable, but it is still worth documenting the extra complexity and support burden created by the restriction.
Separate subdomains are unfortunately not permitted in this environment, so I’m looking for the least-bad solution under that constraint.
Windows DNS cannot generally act as a fallback resolver for unknown names inside a zone for which it is authoritative. Once it owns the zone, an unknown record is answered with NXDOMAIN; normal forwarding does not apply to individual missing names in that zone. That behavior is fundamental to how authoritative zones work, not something DNS policies usually override.
If BIND9 is capable of serving the required views, consider making BIND the resolver for clients and using split-horizon views based on source network. One view can return internal addresses, while another can return the DMZ or public addresses. Be careful to preserve all Active Directory records, including the LDAP and Kerberos SRV records, if Windows clients still depend on AD. This is a larger change than simply adding a forwarder, but it matches the problem better than trying to make an authoritative Windows zone forward selectively.
Automated synchronization is probably the most realistic option if the naming and routing requirements cannot be changed.