23

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.

Community
  • 1
HopelessN00b
  • 53,385
  • 32
  • 133
  • 208
  • 1
    Minor correction - it would require an internal A record, not an SRV record for `www`. – MDMarra Jan 16 '14 at 17:34
  • @HopelessN00b - Mark is spot-on w/ everything I'd have said and more. His "partner" scenario is icing on the cake. I haven't had the "pleasure" of running into that scenario w/ split-horizon DNS. I would have just mentioned it makeing name resolutions in a VPN suck, but I didn't think about DirectAccess in particular.) If I should think of anything I'll throw it out. I'm just horrified at the makework and potential for mistakes it creates. That alone is reason enough to justify not doing it. Most of all, I'm still galled by people who say "big companies do it so it's okay" as an excuse. – Evan Anderson Jan 16 '14 at 19:21

3 Answers3

25

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.

  1. The www problem that you've pointed out above. Annoying, but not a deal breaker.

  2. It forces you to maintain duplicate records for all public-facing servers that are also accessible internally, not just www. mail.hopelessnoob.com is a common example. In an ideal scenario, you'd have a separate perimeter network for things like mail.hopelessnoob.com or publicwebservice.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.

  3. Imagine this scenario - You're hopelessnoob.com internally and externally. You have a corporation that you're partnering with called example.com and 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).

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

Community
  • 1
MDMarra
  • 100,183
  • 32
  • 195
  • 326
  • 1
    Awesomesauce. I think 3 and 4 might seal the deal... but I'm gonna leave it open to see if anyone's got anything else. And hopefully encourage more precioussssses your way. Two upvotes for that answer is pretty weak... c'mon, people. Needs moar upvotes! – HopelessN00b Jan 16 '14 at 17:55
  • 2
    +1 - I love it. Keep up the fight. – Evan Anderson Jan 16 '14 at 18:47
8

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.

Community
  • 1
mfinni
  • 35,711
  • 3
  • 50
  • 86
  • Good point. Of course, we don't have public services like that, and outsource our webhosting, so... not sure how much that'll matter, but I can add it to the list. Thanks. – HopelessN00b Jan 16 '14 at 17:23
  • 1
    As I edited - how your company's public internet identity is being used today might not accurately reflect how it will be used in 5 years. – mfinni Jan 16 '14 at 17:25
  • Yes, future proofing... another good one. Wish I could give you another +1. :) – HopelessN00b Jan 16 '14 at 17:29
5

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:

  1. Like you pointed out in your question, you simply cannot allow internal users to get to your external website via just the domain name. Don't ask why that was such a big deal, but we had internal users that would get livid that typing just the domain name into a browser without www wouldn't bring up the actual website, since the domain record corresponds to the AD domain and isn't a catch-all for getting to www and CAN'T BE internally.
  2. Exchange issues - Exchange AutoDiscover can fail to get the certs and will prompt an error. This can happen both internally AND externally. This became even more apparent when we started have "External Forest Mailboxes" on our Exchange Org and they didn't see the same internal DNS as we had.

Hope that helps.

TheCleaner
  • 32,352
  • 26
  • 126
  • 188