I'm familiar with Active Directory's reliance on DNS and the best practices regarding DNS in Active Directory naming (e.g. use a subdomain of the corporate domain dedicated to AD). I have just a rather conceptual question about this, though:

  1. How necessary is it for a DNS record (anywhere really) to be pointed to the domain controller? For instance, say my network owns example.com and I was considering allocating ad.example.com to the domain. Since the domain controller is the authoritative DNS server for the network, if you call it ad.example.com, even without adding a CNAME DNS record for it, all requests on the domain for ad.example.com will be fulfilled properly by the domain controller - and it doesn't really matter if external requests aren't. Am I missing something? What difference does adding a DNS record make, since the DC isn't supposed to be reachable from the outside, anyways? Can you get away without doing it (functionally)? This answer seems to suggest so, but the OP there also says he uses public DNS records.

  2. I know everyone decries it, but most of my experience with AD domains has been seeing organizations use their root DNS domain as the AD domain name (e.g. just example.com). Supposing I wanted to go this route as well (and won't be dissuaded from doing so), what are the steps to take/things to consider when doing this? I keep hearing about "conflicts" but it's unclear in what sense these conflicts exist. Would it just be requests to the website example.com will go to the domain controller itself, which needs to redirect requests based on the port? What's the "proper" way of handling these conflicts when you reuse the root domain for AD?


For your first question, I'm not sure what you're getting at. Are you saying that you don't think it's necessary to have a public DNS record for your domain? You're right, you don't, technically. The thing is, your domain namespace should be unique worldwide, and if it's subordinate to a namespace you already own, then you can be guaranteed it is unique. It makes life a lot easier if you have a public namespace when it comes to integration later

This advice goes back to Windows 2000 days, and it's still relevant.

For your second question, if you own a namespace, do not, do not, place your AD domain at the root of that namespace. Always, always, always, create a subordinate namespace for your domain.

You do not want domain controllers exposed to the internet. You will always need some kind of DNS "shim" to separate your domain controllers from your publicly-facing DNS, and in that case, you might as well simply host your root namespace there.

Having a separate namespace means you do not run into the pain and agony of keeping a split-brain DNS in order. That link from Dell gives a really good summary of the kind of issues you can run into.

Yes, there are solutions like Infoblox "DNS Views" (even Microsoft provides something like that now), but it requires care and feeding too. You need skilled people to set it up and maintain it properly. Otherwise, per the Dell article, it can be (it always is IME) incredibly painful if you have two disparate systems "authoritative" for the same namespace without these extra goodies.

If you have your web services in your root namespace, and perhaps other things like other namespaces for bulk email (to make SPF easier) or non-Windows systems or practically any third party service that you might want to share your namespace with, it is much better to keep your domain separate. If you might ever want to do those things (hint, if it's an enterprise or public organisation of any description, you will).

It's a tiny bit of security via obscurity. Not much, to be sure, but a little.

From a system management point of view, your DNS delegations and resolvers are that much easier. You have your root namespace, and that DNS server delegates the subordinate domain namespace to the DCs, which are authoritative for it. Any domain client can then do nice secure DNS registrations, the root DNS remains authoritative for the root namespace. The AD DNS zone can be safely set to scavenge stale records, since modern Windows clients are fine with reregistering as necessary. Of course you can still create static entries for your servers.

For name resolution, DCs have their resolvers configured to point to the upstream DNS, and for both external and root zone name resolution, it's nice and clean for both domain and non-domain clients. Obviously you would only allow your internal non-domain clients to query the internal domain namespace, not external clients.

I'd actually recommend having a separate subordinate namespace for internal non-windows hosts as well - that can be hosted on the upstream DNS, or delegated onto the Windows DCs, or even a completely separate DNS host. Or, if you've only got some nice modern Linux to worry about, join them into the AD domain, done.

Finally, I've been managing AD domains since 2000 (and NT domains before that), and literally the number one issue I've encountered with domain design is if it's been done under a split-brain DNS in the root namespace. The dreaded "single label" domain is way down the rank of domain problems, because it's quite rare. Much more rare than this root AD namespace issue.

I'm supporting an environment like that right now. The domain has 10s of 1000s of accounts and has been around since 2002. We have hundreds of web services, cloud services (multiple cloud provider), third party SAAS and PAAS integrations, telephony, external domains with disjoint namespaces, Windows and non-Windows non-domain systems in the environment -- all interacting with that root namespace and/or the internal AD. The poor DNS design authority and I literally spend hours each month pulling our hair out over it for one reason or another. There is a lot of manual handling to get around the problems it causes.

One more option is to register a completely disjoint namespace for the sole purpose of hosting your domain, while all the public stuff remains in the primary namespace. For examples, entities that register a enterprise.com/.org for their public namespace, and enterprise.net.cc or something for their Windows domain. That's perfectly fine, but then you have an additional management overhead of registering MXes and TXT records and creating custom UPNs (maybe) for your disjoint namespace to integrate with things like your public email addresses/cloud services. Doable, but a little more expense and work for not really much benefit. And you need to ensure that shadow IT doesn't sneak in using the "wrong" namespace and then suddenly it has to be publicly accessible as well.

TL;DR - the reason why there's no good advice on a "proper" way to do it is that there literally is no proper and manageable way to do it. There is no benefit from having your AD in the root namespace; there are plenty of drawbacks if it is there.

Unless you're in a tiny environment and you don't really care about your AD. In which case, I'd actually suggest that you don't bother with AD at all and simply go straight to Azure AD cloud-based identities.

| improve this answer | |

The use of a subdomain as a forest root can be done when there are other DNS servers authoritative for the domain root you own and also sometimes to manage overhead. In a heterogeneous environment (With Linux, Solaris, other windows servers using a DNS service such as QIP(e.g) , which you dont want to use for Active Directory as for that you want AD integrated DNS, which is not mandatory but advised) where you are creating a green field AD design, you designated a domain specifically for your DCs and the clients and users the DC would manage.In the cloud world, you may however add the root domain to your UPN suffixes as you might want to use GCP, Azure AD services.In the ADDNS you create a stub for your root domain DNS for your AD integrated clients and servers.

Conflict: I think its more like a overhead than a conflict. We maintain your external DNS records in the Public DNS and internal ones in your private DNS/ADDNS. Then we use a DNS forwarding address in the ADDNS/Private DNS. Specially when you use a lot of hosted/cloud websites and applications.

| improve this answer | |

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.