4

Note - I know there are a ton of questions around AD Naming. I do not believe though that this is a duplicate question. If it is please link me to a relevant one :).

We are implementing AD. Our big issue is the domain name. We already have decided against .local after reading the many articles out there and speaking with people (We are 70/30 Mac right now).

We're trying to figureout if we should go with ourdomain.com or corp.ourdomain.com for our Domain Name.

We know already if we went with ourdomain.com we'd have potential issues if people didn't prepend www. to our site's URL, and we are willing to live with that.

Our concern is if there are any other consequences we don't know about. E.g. If we have an Exchange server of ours hosted in a Data center that isn't part of the LAN, would it have issues with DNS?

To give an overview of what we have -

Our site is hosted in an external datacenter, we currently use Google Apps but plan a migration to Exchange (Yes, we know it's against the trend..) which may also be hosted in a datacenter or onsite.

We also make extensive use of our UTM Firewalls VPNs and are looking at a Cisco VPN or Citrix solution as we scale up.

There are also plans to institute Windows Distributed File Sharing and possibly use Centrify or Extreme-Z IP if we find Native Mac Integration lacking.

We also plan to use AD as our authentication backbone using it for RADIUS and LDAP services for authentication and role management across our internal web apps and wireless.

We did read http://msmvps.com/blogs/acefekay/archive/2009/09/07/what-s-in-an-active-directory-dns-name-choosing-a-domain-name.aspx but I was hoping for some more up to date information from anyone well versed in maintaining AD especially in hybrid/distributed environments.

CogitoErgoSum
  • 522
  • 5
  • 13

1 Answers1

5

There is absolutely no reason to use the same AD domain DNS name as your external web-facing DNS zone. None. At all.

Microsoft recommends using a subdomain of an existing domain, so something like corp.yourdomain.com or ad.mydomain.com is fine. If you don't want your users to see that their login name is corp\user you can set the domain's NetBIOS name to MYDOMAIN during the DCPROMO process of the first DC in your domain. The end result would be that your domain's FQDN would be corp.mydomain.com but your users would see mydomain\user. This way you can have "prettier" logins, without the complete shitmess of split-horizon DNS.

Seriously, there's no valid reason to ever have split-horizons DNS with your AD infrastructure.

MDMarra
  • 100,734
  • 32
  • 197
  • 329
  • What would you think about a end TLD e.g. yourcompany.co or yourcompany.us instead? – CogitoErgoSum Aug 09 '12 at 15:00
  • @CogitoErgoSum As long as it's a **valid** domain name that you own, that's fine, though far less common. Why are you so hesitant to use a sub-domain? It's pretty standard. – MDMarra Aug 09 '12 at 16:17
  • We're trying to explore all options. From a management point of view they prefer things as 'pretty' as possible however the NetBIOS name could be a solution as well. – CogitoErgoSum Aug 09 '12 at 17:54
  • Split-Horizons DNS is a **very important** architectural choice when building out a secure infrastructure. See http://security.stackexchange.com/questions/98088/how-important-is-split-horizon-dns – user2320464 Jul 01 '16 at 00:56
  • @user2320464 nowhere did I recommend publishing internal records publicly. There's no reason for any AD DNS to be available on the public internet, so there's no reason for public DNS for that zone. And thus, no security issues. – MDMarra Jul 01 '16 at 04:11
  • _"Seriously, there's no valid reason to ever have split-horizons DNS with your AD infrastructure."_ The premise of split-horizon DNS is segregating DNS records between public and private. – user2320464 Jul 01 '16 at 13:58
  • @user2320464 there's typically no reason to publish your AD DNS publicly, so there's no reason for split DNS. AD DNS should be 100% private. Not sure what you think is so controversial here. – MDMarra Jul 02 '16 at 01:26
  • @MDMarra, seems we have a misunderstanding. We both agree that AD DNS should be kept private. Therefore to make certain DNS records public one should use separate DNS infrastructure and ideally one shouldn't use internal resolvers for recursion. Thus the need for split-horizon DNS. Your last sentence writes off this design as unnecessary which isn't accurate and really beyond the scope of the OP. – user2320464 Jul 02 '16 at 18:14
  • 1
    @user2320464 there is absolutely no reason to publish any record from an AD DS domain in a public DNS zone unless you're working in an environment that's been poorly architected. It's as simple as that. If your internal AD DS domain is `ad.example.com` no single record for the `ad.example.com` zone should ever exist on the public internet. Full stop. End of story. Do not pass go. Do not collect $200. – MDMarra Jul 03 '16 at 02:10