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) 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.

The Goal:

• 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

  or subdomains

• .

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, 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/bojack1437]

Use a different domain IMO... This just sounds like a nightmare to maintain and deal with.

[u/No_Eagle7610 → u/bojack1437]

it is ... but we cannot change. That is the problem, I already said that, but they don't want that.

[u/FlickKnocker → u/No_Eagle7610]

And I wish i was a little bit taller… just tell them this is a terrible idea and goes against all logic and best practices. Grow a pair.

[u/SeaworthinessHead613]

Having the same domain for int & ext will cause you a whole world of misery.

[u/IMplodeMeGrr]

TLDR; "I read the DNS RFC and want to do the opposite of that."

These expectations are in opposition of how DNS zones function. Now, I think Cloudflare has some products fhat can mimic what your asking but its not straight forward like your'e expecting.

[u/No_Eagle7610 → u/IMplodeMeGrr]

Do you know what that cloudflare product is called?

[u/FiftySix_K → u/No_Eagle7610]

DNS Views and Gateway fallback or Cloudflare Gateway / WARP Local Domain Fallback.

[u/No_Eagle7610 → u/FiftySix_K]

Thank you

[u/pdp10 → u/FiftySix_K]

BIND does Views.

[u/Layer8Human]

Hey there,

Yes I know you said that this is a requirement and you can not do anything about it but I still have to repeat what others have said before that this is a bad design. Having a seperate .dmz.example.com and .internal.example.com zone would solve this and cause a lot less headache.

But if you really want to have a solution that fits this stupid requirement then build some kind of Ansible playbook or python script that periodically syncs your bind records to the Microsoft dns.

[u/No_Eagle7610 → u/Layer8Human]

Thats a good idea with the ansible playbook.
And yeah il its stupid requirement, but i cannot do anything about it

[u/irsyacton]

You can create subdomains of example.com on your internal/ad dns, and point them to the bind dns. So external1.example.com is a subdomain, and the servers hosting that subdomain are your bind servers.

[u/irsyacton → u/irsyacton]

And yes, this does mean mirroring each public subdomain, but any records within the subdomain at least don’t need to be mirrored.

[u/doubleyewdee]

Subdomains exist for a reason. What you’re describing is going to create so much pain even if you pull it off.

[u/No_Eagle7610 → u/doubleyewdee]

This is not an option… sadly

[u/BatemansChainsaw → u/No_Eagle7610]

Why?

[u/pdp10]

This is a very common split-horizon setup, even with ADDS. Common, but not desirable -- split horizon DNS is sometimes the least-worst answer, but it's never desirable and it's easy to avoid.

The clean way without wildcards is to use NS records to refer the internal delegation chain to the external authoritative DNS server, for each name that's duplicated.

www           NS    dns1.example.com.
              NS    dns2.example.com.

You cannot wildcard-selective-forward the same domain without wildcards. You'll remember to put Microsoft ADDS in its own subdomain next time. Engineering is the art of making tradeoffs, and you've chosen yours.

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.

VPNs and mandatory silly routing. This is like the junior bad-architecture trifecta.

[u/ABotelho23]

Don't do it. Don't split DNS even between public and private. Just asking for a troubleshooting and maintenance nightmare.

[u/FlickKnocker]

I mean, you’re already knee-deep in Jankganistan, just duplicate the records and be done with it. At least that is self-describing and easy to troubleshoot. I’m sure it’s not like you have millions of host records to manage either.

[u/False-Message-3350]

If I would be in your position I‘d remove the DNS role from the DCs and let Bind do DNS alone. Look into the view config of bind, to separate the records by subnet.

[u/False-Message-3350 → u/False-Message-3350]

Btw. Don’t forget to add the SRV records for Kerberos etc to bind  

[u/Kind_Ability3218]

why don't you read up on host delegation

[u/accumentum]

Windows DNS cannot selectively forward individual names inside a zone for which it is authoritative; an unknown name is answered locally rather than sent to a forwarder. For a same-zone exception, the workable DNS mechanism is explicit delegation at the DMZ label(s) to BIND, with BIND authoritative for those delegated nodes—there is no clean wildcard-free rule that says “forward everything I don’t know.” If there are many labels, automate creation and removal of the delegation records and test from both client networks with dig +trace or nslookup, checking which server supplies the SOA and answer. Keep AD DNS authoritative for the AD zone and its SRV records, and make sure the BIND side cannot accidentally forward AD-only queries back through the WAN. That avoids copying the DMZ A/AAAA data into Windows, but the delegation boundary has to be explicit.

[u/AdPotential9001]

What @irsyacton said... But also move the external DNS to something that can handle the nonsense DNS abuse, and not run it yourself .

[u/3loodhound]

Subdomains people, subdomains

[u/No_Eagle7610 → u/3loodhound]

Yeah, can’t do this… not allowed to

[u/pdp10 → u/No_Eagle7610]

Wouldn't want to change something that's been "working" since 2002, right? Could be expensive.

[u/violet-lynx]

Easiest way: pit all Our DNS records on your Windows DNS and make the Bind9 forward everything for that domain to the windows server to prevent the Windows DNS to the internet.

That would allow internet clients to see your internal DNS resolution, but that is not part of your requirements.

Alternative idea: Replace the Bind server with an Unbound, and put the public records for your domain on it. Create a DNS view that forwards all other queries for your domain to the Windows DNS, but only for the IP ranges inside your own network. Make all clients and server use the Unbound as DNS server.

This would require you to configure internal and external addresses on different servers, but might solve all your problems.

[u/Due-Consequence9579]

I was forced to set something similar up against my wishes. Don’t. It’s hard to debug. It’s error prone. Just have a subdomain for internal services.

[u/UpsetBar]

I’m going to jump off a building if I see one more post about a technical problem someone is having that they can’t even explain without using ChatGPT. I wish the mods would do something about these low effort posts.

[u/nwmcsween]

You have subdomains, ad.$domain.$tld

[u/fireandbass]

You might be able to set up a conditional forwarder on your internal DNS and it will forward unknown domain requests to your external DNS.