Creating a sub domain of our public domain for corporate/internal Active directory use. The public domain is also our Office 365 and Azure domain

Question

Our current internal AD domain is example.local (set up long before I joined our team when this was a best practice)

Our Office 365 domain is a public, registered domain with GoDaddy which we use for email, sharepoint, teams, etc and an Azure tenant, call it example.com. I know it is a best practice these days to set up a subdomain of the public one and we are fine with corp.example.com as our subdomain that will be used for our AD/internal DNS.

I am fairly familiar with DNS, although no expert, and I have never set up a subdomain of a public one.

In brief steps, can someone please outline how to go about doing this? I have read as much documentation as is out there and most of it is agrees in concept with the subdomain thing, but is conflicting on how to actually go about doing this. We do not have a lot of corporate users, most of them are at remote sites and do not need to access our corporate AD. Our AD is fairly simple, not a lot of group policies or anything that might get lost when creating a new domain.

I am planning to blow away our current example.local domain (not going to try to rename it) and set up a new server /DC for the subdomain and AD. I have the ability to manage our DNS on GoDaddy, I just need to know the proper steps and how to translate that back down to AD.

Can anyone out there guide me by providing a brief outline of steps to be taken and in what order to do them? I am a little confused on how to tell AD and internal DNS that it is a subdomain of a public registered one.

I don't think split brain dns is going to be necessary as we have a totally different domain that is not involved in any of this for our public website. Right now, as things stand, our internal servers' fqdn is server.example.local. My expectation when I am finished with this is that our internal servers' fqdn is going to be server.corp.example.com. (as mentioned before, example.com is the primary, public domain that I am using to create the subdomain under.)

Thanks in advance for any help you can provide. The internal AD/DNS server for the new sub domain is running windows 2019 standard.

Sharyn

Answer 1

I personally have no idea why it could be beneficial to have an internal domain named corp.company.com instead of, for example, company.lan. Or anything else really. If you know any benefits, please share them.

If you go with public subdomain for AD, you don't have to add anything to your public DNS zone config. It is important not to publish any internal records publicly.

The only bad idea would be to use your public domain name company.com as internal AD domain name. Other than that you will be fine

Answer 2

This MSFT doco outlines the basic setup in the subdomain scenario that you describe: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc772970(v=ws.10)

You don't need to "tell" your DCs as such that they are subordinate to the upstream zone. Simply install the AD and DNS role, specify the domain FQDN, and it'll configure the subzone as authoritative on the DCs during setup.

Setup will give you an warning if you have the DNS client configured on the DC's network adapter with an external DNS host address, because it will try and register its new DNS name. But ignore that, upstream DNS doesn't need to know about it.

For resources hosted internally that need to be accessed from the Internet, you'd allocate a public IP and a public DNS name to your internal resource - like a website or VPN - and get to it that way rather than exposing/delegating the private namespace at all - that's definitely to be avoided if at all possible. This is the scenario described in the MSFT doco. Re point 4, you won't need to worry about disabling dynamic registrations on your DNS provider, since I doubt it's enabled anyway.

The main decision would be how you do external name resolution for your domain members. The members should use the DCs as their DNS hosts, of course. The DCs will need to resolve names on the internet. Ideally, the DCs would forward queries to a specific DNS provider - this makes life easier when it comes to firewalling. Point 5 in the article I linked discusses the options.

I think in your scenario, you'd use your ISP's DNS - however you're doing it now. It's worth looking at DNS service providers like OpenDNS or Cloudflare that provide DNS security if your current provider doesn't - extra protection from phishing sites and so on is great, and these services can be free or quite inexpensive. Just make sure the one you select has local points of presence (at least national) if you go that route. The fallback is to let the DCs use root hints, but that means they need to do queries all over the Internet, and I'd certainly prefer OpenDNS etc over that option. You should define multiple forwarders, unless you know that the forwarder IP is actually a VIP with multiple hosts underneath.

The MSFT doco also has a number of other chapters that might be worth glancing over. However, stuff like an internal DNS root server is irrelevant unless you're going to expose your internal namespace and delegate to it from your upstream DNS registrar. Again, that's a scenario you want to avoid.

Also, once your first DC installed, in the network config, remember to check its own IP is the primary DNS host, plus 127.0.0.1. If the DNS forwarder is set up to relay queries to your external DNS, I don't think you need it defined in the network config as well (test to verify the DC can resolve external names, of course).

For subsequent DCs, prior to installing ADDS, configure the network so that the first DC is its primary DNS, then itself, then 127.0.0.1. Once Setup is done on the second DC and replication has completed, ensure the first DC can resolve it, and set its network config so the second DC is the first DNS host (retaining the other entries).