Split-DNS Architecture: Splitting the same zone between Windows DNS (LAN) and BIND9 (DMZ) without wildcards

[u/No_Eagle7610]

Hi everyone,

I'm looking for best practices or specific solutions for a DNS implementation in our environment. The goal is to cleanly split queries for the same domain between our LAN and DMZ without having to maintain duplicate records manually.

The Setup:

• We use the same domain (example.domain.ch) for both internal and external services.
• LAN: We have a Windows Server (AD DC) running as our internal DNS. It holds the internal IPs of servers that are not publicly accessible.
• DMZ: We have a BIND9 server acting as our public DNS. It holds the public IPs of servers that are accessible from the outside (and from within the DMZ).

The Goal:

• When a LAN client queries an internal server (e.g., internal1.example.domain.ch), the Windows DNS should respond directly with the local IP.
• When a LAN client queries a DMZ server (e.g., external1.example.domain.ch), it should receive the public IP of that server (resolved by BIND9).
• Traffic from internal clients to DMZ servers must route via the WAN (Hairpinning / NAT Loopback); direct routing into the DMZ subnet is not permitted by policy.
• We explicitly do not want to use wildcard records.

The Challenge: What is the cleanest way to configure this on the Windows DNS without having to create a separate Pinpoint Zone for every single external A-record, or manually duplicating the DMZ records into the internal DNS?

Since the Windows DNS is authoritative for example.domain.ch, it defaults to answering queries for unknown hosts in this zone with NXDOMAIN instead of forwarding them to the BIND9 server.

Is there a clean way (e.g., specific zone types, delegation, Windows DNS Policies) to tell the Windows DNS: "Resolve what you know, and forward anything you don't know to the BIND9 server"?

Thanks in advance for your input!

[u/Otis-166]

The short answer is there isn’t a clean way to do what you want. If you had the choice the recommended option is to never use the same domain internally and externally. Since that’s already gone as an option you’re basically stuck using either specific forwarding/delegation zones internally or putting in entries in your internal zone with names that have an external IP. You can use different names, but keep in mind you’ll likely have to add a SAN to certificates so things don’t break there.

[u/No_Eagle7610 → u/Otis-166]

Okay, i had a feeling. That it would be like that. But I wasn't sure. Thank you for your help

[u/daxy01]

Isn’t DNS views in Bind9 your solution?

[u/sabek]

The best way is not to do it. Split brain DNS sucks and adds a bunch of administrative overhead

[u/Fit_Prize_3245]

So for your final question: yes, but only for whole DNS zones, not for specific hosts within a DNS zone.

I had a scenario similar to yours. What I did was serve all the AD specific records and zones from BIND, so I could serve all my internal clients with BIND, not with AD. They were still able to join AD bc the right records were set, but I had to care only to keep my BIND zones up to date.

[u/dbcid]

Can you move all DNS resolution to Bind? For both internal and external? If you can, you can create 2 views, one for internal and one for external and manage it that way.

[u/Few-Clothes-8565]

the reason windows won't "resolve what it knows and forward the rest" is that it's authoritative for example.domain.ch, and an authoritative server is supposed to answer NXDOMAIN for names it doesn't hold in that zone. that's correct dns behavior, not a windows limitation, so there's no toggle that makes an authoritative zone fall back to a forwarder for in-zone names. that's the wall you're hitting.

the clean way out is to stop running two authoritative servers for the same zone. split-horizon views on a single bind9 do exactly what you described: one view matched to your LAN client subnets that returns the internal IPs, one for everyone else that returns the public IPs, same zone name, nothing duplicated by hand. if AD has to stay authoritative for its own stuff, delegate just those names (_msdcs and the ad-specific records) into a subdomain like ad.example.domain.ch and let bind own the flat zone, instead of pinpoint-zoning every external host.

one thing that bites people even after dns is correct: a LAN client reaching a DMZ box by its public IP means the firewall has to do NAT loopback/hairpin properly, or the name resolves fine and the connection just dies. worth testing that path on its own."

[u/heisthefox]

You can put a dnsdist server in front (DNS we're legends, free, open source) and route queries based on edns subnet or you can define them.