[Hopefully](https://serverfault.com/q/473529/118258), we [all know](https://serverfault.com/q/38208/118258) what le [recommendations for naming an Active Directory forest are](http://www.mdmarra.com/2013/07/more-documentation-from-microsoft-about.html), et 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.](http://technet.microsoft.com/en-us/library/cc738121%28WS.10%29.aspx) Par exemple, si I were to incorporate et register le `hopelessn00b.com` domain, mon internal AD forest should be named `internal.hopelessn00b.com` ou `ad.hopelessn00b.com` ou `corp.hopelessn00b.com`.
Il y a overwhelmingly compelling reasons to avoid using ["fake" tlds](http://www.mdmarra.com/2012/11/why-you-shouldnt-use-local-in-your.html) ou [single-label domain names](http://support.microsoft.com/kb/300684/en-us), mais Je suis having a hard time finding similarly compelling reasons to avoid using le root domain (`hopelessn00b.com`) as mon domain name et use a subdomain such as `corp.hopelessn00b.com` instead. Really, le seulement justification I can seem to find is that accessing le external website depuis internal requires an `A name` DNS record et typing `www.` in front of le website name in a browser, qui 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 mon Active Directory forest name over `hopelessn00b.com`?**
Just for le record, c'est really mon employer that needs convincing - le boss man is back-peddling, et après giving me le go ahead to créez un nouveau AD forest named `corp.hopelessn00b'semployer.com` for our internal network, he's wanting to stick avec an AD forest named `hopelessn00b'semployer.com` (the même as our externally registered domain). Je suis hoping that I can get certains compelling reason ou reasons that le best practice is le better option, so I can convince him of that... parce que it seems easier than rage quitting and/or finding a nouveau job, at least for le moment. Right now, "Microsoft best practices" et internally accessing le public website for our company ne seem to be cutting it, et Je suis *really*, **really**, ***really*** hoping someone here has something more convincing.
Nommer une nouvelle forêt Active Directory - pourquoi le DNS split-horizon n'est-il pas recommandé ?
Re: Nommer une nouvelle forêt Active Directory - pourquoi le DNS split-horizon n'est-il pas recommandé ?
*So much rep to be had. [Come to me precious.](https://i.sstatic.net/rZIh1.gif)*
Ok, so c'est pretty well documented by Microsoft that you ne devrait pas use split-horizon, ou a made up TLD as you've linked to beaucoup de times (shout out to mon blog!). Il y a a peu de reasons for this.
-
The `www` problem that you've pointed out above. Annoying, mais pas a deal breaker.
-
It forces you to maintain duplicate records for **all** public-facing servers that are aussi accessible internally, pas juste `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` ou `publicwebservice.hopelessnoob.com`. With certains configurations, [like an ASA with Internal and External interfaces](https://serverfault.com/questions/508605/why-dont-more-organizations-use-inside-to-inside-nat-or-similar-solutions-to-al), you soit need inside-inside NAT ou split-horizon DNS *anyway* mais for larger organizations avec a legitimate perimeter network où votre web-facing resources ne sont pas behind a hairpin NAT boundary - this causes unnecessary work.
-
Imagine this scenario - You're `hopelessnoob.com` internally et externally. Vous avez a corporation that you're partnering avec called `example.com` et they do le même thing - split horizon internally avec leur AD et avec leur publicly accessible DNS namespace. Now, you configure a site-to-site VPN et want internal authentication for le trust to traverse le tunnel tandis que having access to leur external public resources to go out over le Internet. C'est suivant to impossible sans unbelievably complicated policy routing ou holding votre own copy of leur internal DNS zone - now you've juste created an additional set of DNS records to maintain. So you have to deal avec hairpinning at votre end *and* leur end, policy routing/NAT, et tous kinds of autre trickery. (J'étais actually in this situation avec an AD that I inherited).
-
If you ever deploy [DirectAccess](http://en.wikipedia.org/wiki/DirectAccess), it drastically simplifies votre name resolution policies - this is likely aussi true for autre split-tunnel VPN technologies as well.
Some of these are edge cases, certains are not, mais they're tous *easily* avoided. If you have le ability to do this depuis le beginning, might as well do it le right way so that you ne run into one of these in a decade.
Ok, so c'est pretty well documented by Microsoft that you ne devrait pas use split-horizon, ou a made up TLD as you've linked to beaucoup de times (shout out to mon blog!). Il y a a peu de reasons for this.
-
The `www` problem that you've pointed out above. Annoying, mais pas a deal breaker.
-
It forces you to maintain duplicate records for **all** public-facing servers that are aussi accessible internally, pas juste `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` ou `publicwebservice.hopelessnoob.com`. With certains configurations, [like an ASA with Internal and External interfaces](https://serverfault.com/questions/508605/why-dont-more-organizations-use-inside-to-inside-nat-or-similar-solutions-to-al), you soit need inside-inside NAT ou split-horizon DNS *anyway* mais for larger organizations avec a legitimate perimeter network où votre web-facing resources ne sont pas behind a hairpin NAT boundary - this causes unnecessary work.
-
Imagine this scenario - You're `hopelessnoob.com` internally et externally. Vous avez a corporation that you're partnering avec called `example.com` et they do le même thing - split horizon internally avec leur AD et avec leur publicly accessible DNS namespace. Now, you configure a site-to-site VPN et want internal authentication for le trust to traverse le tunnel tandis que having access to leur external public resources to go out over le Internet. C'est suivant to impossible sans unbelievably complicated policy routing ou holding votre own copy of leur internal DNS zone - now you've juste created an additional set of DNS records to maintain. So you have to deal avec hairpinning at votre end *and* leur end, policy routing/NAT, et tous kinds of autre trickery. (J'étais actually in this situation avec an AD that I inherited).
-
If you ever deploy [DirectAccess](http://en.wikipedia.org/wiki/DirectAccess), it drastically simplifies votre name resolution policies - this is likely aussi true for autre split-tunnel VPN technologies as well.
Some of these are edge cases, certains are not, mais they're tous *easily* avoided. If you have le ability to do this depuis le beginning, might as well do it le right way so that you ne run into one of these in a decade.