We use example.domain for both internal services and publicly accessible DMZ services. Windows DNS on an Active Directory domain controller is authoritative for the internal view and contains private records, while BIND9 serves the public/DMZ records. Internal clients must reach DMZ services through the WAN using NAT loopback; direct routing to the DMZ is not allowed. Wildcards and separate subdomains are also prohibited.
The problem is that Windows DNS returns NXDOMAIN for names it does not know within its authoritative zone instead of forwarding those queries to BIND9. Is there a clean Windows DNS configuration—such as zone types, delegation, or DNS policies—that allows it to answer records it owns while forwarding unknown names in the same zone to BIND9? The goal is to avoid creating a separate pinpoint zone or manually maintaining every public record twice.
5 Answers
Another architecture is to use BIND as the resolver for clients and configure views. One view can return internal addresses, while another returns public or DMZ addresses, based on the source network. You would need to preserve all required Active Directory records, including the Kerberos and LDAP SRV records, and carefully test dynamic updates and AD integration before replacing the domain controllers’ DNS role.
The practical options are to maintain the public records in both systems, or automate the synchronization. An Ansible playbook or small script could export the relevant BIND records and update Windows DNS on a schedule. It is not elegant, but it is explicit, auditable, and easier to troubleshoot than trying to make authoritative DNS behave like a fallback resolver.
If you can introduce a separate recursive resolver, it may be able to provide the desired behavior: serve the public records locally and forward other queries for the domain to Windows DNS for internal clients. This still means the public and internal data live in different places, but it avoids creating a pinpoint zone for every hostname. Be careful not to expose internal answers to external clients, and validate the resolver’s split-view and forwarding behavior.
The cleanest long-term fix would be separate internal and external namespaces or delegated subdomains. Since that is ruled out, there is no simple Windows DNS policy that means ‘answer locally, then forward an unknown name from the same authoritative zone.’ Choose between synchronized duplicate records, a DNS server with properly designed views, or an external DNS service that supports this kind of split-horizon setup.
An authoritative DNS server generally cannot do a catch-all forward for unknown names inside a zone it serves. Once Windows DNS is authoritative for example.domain, an unknown name is answered with NXDOMAIN; it is not sent to another server. Delegation can solve this only for a child zone, which is why separate subdomains are the usual design.
Separate subdomains are unfortunately not permitted here, so I’m looking for the least painful alternative.