0

I have a domain controller set up on Windows Server 2016, the domain name for the AD domain is example.com. Every computer connected to this domain is assigned a domain name, which I can see in the Forward Lookup Zones of DNS manager, for example:

DC01.example.com
PC01.example.com
PC02.example.com

I also have a few external servers set up which are not connected to the AD domain, but they use the same domain name, for example:

webapp.example.com
mail.example.com

The issue that I am facing is that the DNS resolver on DC01.example.com doesn't seem to be forwarding on requests to the DNS server that I have set up under the Forwarders section

For example if I am on PC01, which is connected to the domain, and I try to perform an nslookup for webapp.example.com I get an error. I think this is because DC01 looks at its Forward Lookup Zones, sees that nothing is there for webapp and just reports that it cannot be found.

In case it makes any difference, the DC has no Internet access and instead relies on an intermediate DNS server, this is at 10.0.0.2, I know that this resolver is working correctly because when I use nslookup webapp.example.com 10.0.0.2 it works without issue.

What configuration is needed to make it so that the domain computers are able to get DNS responses for the external domains?

  • for this reason i never use o tld directly, in cade you had used an sub-domain in my mind you wont consider, howwver this has to be definied in the dns settings to say that its not internal, but in case there are the sane, as work aroubd use cnames – djdomi Sep 6 '19 at 19:42
  • @djdomi I don't think I would set it up this way if I was to do it again, unfortunately the decision was made years ago and rolling it all back now isn't really an option – Campbell Sep 6 '19 at 20:04
3

You've got what is known as a "split-brain DNS" situation. Because example.com is listed as a Forward Lookup Zone, that's the only place your DNS server will look when it is asked to resolve webapp.example.com. It will only use the forwarders on the Forwarders tab if it fails to find a zone under Forward Lookup Zones.

So, you'll need to make an A record for webapp.example.com in both the example.com Forward Lookup Zone and in whatever DNS system you are using for the general public to be able to resolve your external-facing sites' addresses.

A side benefit of this is that you have the option of using an internal (aka RFC 1918) IP address for webapp.example.com in the Forward Lookup Zone entry, and a public address in the public DNS system. That way, your internal users can get to your website at, say, 192.168.100.100, presuming that you have an internal connection from your internal users to your web servers. That keeps the traffic from having to go outside through your firewall only to turn right around (aka "hairpin") and come back in.

  • Thanks, is there any way to automate this process. It works fine in the example that I gave, but scale it up by 10 and all of a sudden that isn't very feasible. Especially if things are updated in one place but not the other. – Campbell Sep 6 '19 at 20:06
  • I struggle with that, too. We have a similar setup and we haven't found a better way, so we just remind everyone that it is important to update both locations whenever a change is made. We made some mistakes early, but now it is just part of the process, and we haven't messed up in quite a while. Automation: If your external DNS host has an API, you could write a script that updates your internal DNS and the external DNS (through the API) in a single process. Alternative: don't use the same domain for AD that you do for the public-facing stuff. – Doug Deden Sep 6 '19 at 20:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.