Hopefully, we all know what the recommendations for naming an Active Directory forest are, and they're pretty simple. Namely, it can be summed up in a single sentence.
Use a subdomain of an existing, registered domain name, and pick one that's not going to be used externally. For example, if I were to incorporate and register the hopelessn00b.com domain, my internal AD forest should be named internal.hopelessn00b.com or ad.hopelessn00b.com or corp.hopelessn00b.com.
There are overwhelmingly compelling reasons to avoid using "fake" tlds or single-label domain names, but I'm having a hard time finding similarly compelling reasons to avoid using the root domain (hopelessn00b.com) as my domain name and use a subdomain such as corp.hopelessn00b.com instead. Really, the only justification I can seem to find is that accessing the external website from internal requires an A name DNS record and typing www. in front of the website name in a browser, which is pretty "meh" as far as problems go.
So, what am I missing? Why is it so much better to use ad.hopelessn00b.com as my Active Directory forest name over hopelessn00b.com?
Just for the record, it's really my employer that needs convincing - the boss man is back-peddling, and after giving me the go ahead to create a new AD forest named corp.hopelessn00b'semployer.com for our internal network, he's wanting to stick with an AD forest named hopelessn00b'semployer.com (the same as our externally registered domain). I'm hoping that I can get some compelling reason or reasons that the best practice is the better option, so I can convince him of that... because it seems easier than rage quitting and/or finding a new job, at least for the moment. Right now, "Microsoft best practices" and internally accessing the public website for our company don't seem to be cutting it, and I'm really, really, really hoping someone here has something more convincing.
So much rep to be had. Come to me precious.
Ok, so it's pretty well documented by Microsoft that you shouldn't use split-horizon, or a made up TLD as you've linked to many times (shout out to my blog!). There are a few reasons for this.
The
wwwproblem that you've pointed out above. Annoying, but not a deal breaker.It forces you to maintain duplicate records for all public-facing servers that are also accessible internally, not just
www.mail.hopelessnoob.comis a common example. In an ideal scenario, you'd have a separate perimeter network for things likemail.hopelessnoob.comorpublicwebservice.hopelessnoob.com. With some configurations, like an ASA with Internal and External interfaces, you either need inside-inside NAT or split-horizon DNS anyway but for larger organizations with a legitimate perimeter network where your web-facing resources aren't behind a hairpin NAT boundary - this causes unnecessary work.Imagine this scenario - You're
hopelessnoob.cominternally and externally. You have a corporation that you're partnering with calledexample.comand they do the same thing - split horizon internally with their AD and with their publicly accessible DNS namespace. Now, you configure a site-to-site VPN and want internal authentication for the trust to traverse the tunnel while having access to their external public resources to go out over the Internet. It's next to impossible without unbelievably complicated policy routing or holding your own copy of their internal DNS zone - now you've just created an additional set of DNS records to maintain. So you have to deal with hairpinning at your end and their end, policy routing/NAT, and all kinds of other trickery. (I was actually in this situation with an AD that I inherited).If you ever deploy DirectAccess, it drastically simplifies your name resolution policies - this is likely also true for other split-tunnel VPN technologies as well.
Some of these are edge cases, some are not, but they're all easily avoided. If you have the ability to do this from the beginning, might as well do it the right way so that you don't run into one of these in a decade.
This statement : "Really, the only justification I can seem to find is that accessing the external website from internal requires an SRV DNS record and typing www. in front of the website name in a browser" is not true.
It means you need to keep a copy of all of your public records in your AD DNS servers, which might cause problems, particularly if you don't do it properly - miss some, etc. If someone wants to get to ftp.company.com but you forget to create the alias in internal DNS (or didn't automate it properly), in-house folks can't hit the public FTP site at all.
This is pretty well fleshed out in the question you linked to : Windows Active Directory naming best practices?
If maintaining multiple copies of your DNS zones is an easy problem for you to solve correctly, forever, then I suppose you can do what you want. Until MS changes something that breaks it. You could just follow their recommendations.
I don't care enough about the rep to create a long answer today...so I'll keep it short.
I used to be fine with split-dns and implemented it multiple times until Evan and Mark convinced me otherwise. It's honestly NOT that it cannot be done...it can, and some might be just fine with it (despite the overhead and work done for it).
2 specific things came up years ago for me that solidified NOT using it:
wwwwouldn't bring up the actual website, since the domain record corresponds to the AD domain and isn't a catch-all for getting towwwand CAN'T BE internally.Hope that helps.