Active Directory Domain Naming in the Modern Age

April 15, 2013 64 Comments

One of the subjects that doesn’t get a whole lot of coverage in IT is how to name an Active Directory domain. There’s a lot of confusion around the how and why to name a Domain primarily because the best practices for doing so have changed a number of times over the past decade or so. A short discussion I got into on my last post prompted me to go into a good bit more depth on this subject, since it’s something there is a lot of misunderstanding about.

Current Strategies

There are currently two basic strategies that are in common practice when IT administrators and systems engineers decide on their domain names.

  1. Use an Internal private domain name
  2. Use an External Public domain name

An Internal Private domain name would be something like domain.local or company.internal. A private domain is essentially just a domain that is not publicly available on the Internet. This is because the .internal and .local are not Top Level Domains (TLDs) that are recognized by the Internet Corporation for Assigned Names and Numbers (ICANN), which is the organization that regulates domain names and IP addresses on the Internet. Because ICANN doesn’t recognize internal TLDs, no public DNS servers have zones that include them, so there is no way a domain that uses domain.local or company.internal can be resolved to an IP address on the public Internet.

An External Public domain name is something like domain.com or company.net. These are domain names that use TLDs recognized by ICANN and that can be resolved by public DNS servers.

What most people don’t know, however, is that Microsoft doesn’t really recommend either of these strategies for domain naming any longer. Before I explain what the new recommendations from Microsoft are, I’ll explain what the traditional pros and cons of these strategies are as well as a little history about them, in case you end up in an environment that uses these strategies, since my main purpose with this blog is to help people understand best practices and why they’re best practices rather than just telling people what they are.

 

Public Domains in Active Directory

Using a public domain for your Active Directory Domain Name may seem like a great idea if you own a public domain (which, now, is most businesses). However, there are some distinct disadvantages to doing so. Microsoft used to recommend that businesses avoid using their public domain name for their Internal domain for a lot of reasons.

The big reason to avoid using the same domain name internally and externally is a phenomenon known as Split DNS. Split DNS is where you have two completely separate DNS servers or server groups managing the exact same DNS Forward Lookup Zone. Split DNS isn’t necessarily a bad thing, but it does greatly increase the administrative burden of managing DNS. This is because you have to create a new record on both DNS servers every time you add a new server if you want it to be accessible publicly and privately. Active Directory also throws an additional wrench into this because domain.com is always reserved as a host name for discovering Domain Controllers. If you have an external DNS server that uses domain.com as an A record to a web server, that web server will never be directly accessible from inside your network.

Even more annoying, though, is the possibility that you might end up with a host name that points to a completely different server externally and internally. In this situation, users that go to www.company.com when outside the company network would be forwarded to one web server (Say, a public web page for the general public), and users that go there while inside the company network would go to a different server (An Intranet Publication site, for instance). In this situation, a user that connects to the company network by VPN would actually have the public web page stuck in their DNS cache and would be unable to access the Intranet Publication site without clearing their DNS cache. I’ve seen this happen in a couple of different environments and it results in a lot more helpdesk calls than is necessary, which in turn costs the company a lot of money.

Private Domains in Active Directory

Because of the limitations inherent in using Public domains for Active Directory, Microsoft recommended using Private domains when selecting an Active Directory Domain name from the release of Windows 2000 til about 2007. With a private internal domain, there is no need to manage Split DNS. Users would connect to external DNS servers when they wanted to access the servers on the public Internet and connected to internal DNS servers when accessing internal resources without any need to manage multiple DNS zones. It was also thought that using a private domain added a level of security, since no one outside the company would know the domain name for the internal network. This, of course, is just security through obscurity, and doesn’t really provide much security at all (if any). Because of the decreased administrative burden and presumed added security, administrators have used Private domain names for Active Directory for well over a decade now.

Big Changes, the Future is Now

But, as things so often do, technology has changed significantly and Microsoft made a number of changes to their products that necessitated changes to their best practices. One of the biggest changes to Microsoft’s solution base was Exchange 2007.

Exchange 2007 represented a massive paradigm shift in Microsoft’s Email platform. It was vastly different from all other Exchange versions before it, primarily because the needs of the corporate world changed drastically between the release of Exchange 2003 and 2007. Email needed to be more secure, and Microsoft was working toward the now burgeoning world IT automation. One of the most important new automation features that Exchange 2007 introduced was Autodiscover.

Autodiscover allowed users to configure their mail clients without having to enter server names, user names, and all that other stuff that got in the way of users and their email and resulted in loads of extra work for IT support personnel. All it required was an entry in DNS to allow the mail client to reach an XML file that contained all the necessary settings and the client could then use those settings to set itself up without user interaction. However, the mechanism that controlled that caused some conflict with the existing best practices for Active Directory Domain Naming. In order to work, Autodiscover required SSL certificate validation, and Exchange automatically configured itself to use a the Active Directory domain name as the server name to use for automatically configuring clients on the internal network, and with the best practice of using private domain names, that meant that you had to reconfigure Exchange to point clients to the whatever name was on the SSL certificate for the server. If you didn’t do this, clients would get certificate error messages when they used a mail client (For more details on that, read my blog bost here: http://acbrownit.wordpress.com/2012/12/20/internal-dns-and-exchange-autodiscover/).

The problems with autodiscover were actually pretty simple to solve with the use of certificates that supported Subject Alternate Names (SAN). These certificates were basically valid for any server name that was listed on the certificate. Most companies decided to add their internal domain name to their SAN certificates so they could go without worrying about the Autodiscover issues.

However, times change and now the major public Third Party Certificate Authorities (The people who sell SSL certificates) are refusing to issue SSL certificates that included .local and other common private TLDs. Why? Because a couple years ago ICANN announced that, for a nominal fee, companies or individuals could register any TLD they could think of for distribution to public DNS servers around the Internet. This meant that  .local and .internal could potentially resolve on the public internet! And part of the Third Party CA chain of trust requires them to ensure that whoever purchases an SSL owns all the domain names used on their SSL certificates. This causes a huge problem with Autodiscover and similar features that rely on SSL certificates when used with Active Directory Domains using Private Domains. The private domain name could now *never* be added to the SSL certificate (until .local or whatever become publicly resolvable) and any attempt to connect to a .local server would generate a certificate error.

The New Best Practice

I call the current best practice new despite the fact that Microsoft has recommended it since 2007. I do that because it wasn’t necessary to use this best practice until the changes to SSL certificate creation policies. You could just add .local to the certificate and be done with it. You can’t any more. So we have to use a different best practice for managing our domain.

So, the new best practice is as follows, For your Active Directory Domain Name, use a subdomain of your public domain. What does that mean? Well, if your company has a public domain of company.com, set your Active Directory domain name to be something like internal.company.com or private.company.com. You can really use anything you want for the subdomain name as long as the primary domain matches a public domain name that you own (ownership is extremely important. Never pick a public domain name that you don’t own).

Why is this the Best Practice?

The answer here is relatively simple, it allows you to have a domain name in AD that can have SSL certificates generated by a public Certificate Authority, and you don’t have to manage a split DNZ zone. It’s basically the best of both domain naming strategies. There is, of course, a small drawback to this strategy, which is part of why it hasn’t been widely adopted yet (aside from lack of publicity). It means you have to type more when you are typing out FQDNs on your internal network. This is a miniscule issue, but one that seems to bother IT admins around the world. To those who this bothers, I would suggest using a short subdomain like ad.company.com, or even just a single letter, like i.company.com.

Avoiding Issues with Certificates in Exchange 2007+

For information, modern Active Directory Best Practices can help you avoid having trouble with certificate errors in Exchange. I wrote a blog on the best practice that can help you avoid Exchange Certificate issues here. If you follow that best practice when creating your AD environment, you won’t have to worry about certificate errors in Exchange. However, if you can’t build a new environment or aren’t already planning to migrate to a new AD environment in the near future, it isn’t worth the effort to do so when small configuration changes like the one above can fix certificate errors.

 

 

64 thoughts on “Active Directory Domain Naming in the Modern Age”

  2. Hi AC,

    Thanks for a terrific article, I like many others really appreciate the thoughtful effort you put into your post.

    Question: Let’s say we used a subdomain for AD, thus the root for AD is ad.company.com. Well, I’d like have all the DNS names resolved under company.com (so users would access server1.company.com, server2.company.com etc.) Likewise user workstations also should live in the company.com DNS zone. Is that a practical expectation or should I resolve myself to putting all the address resource records under the ad.company.com zone? If it is an ok practice, what else should I do to ensure it operates smoothly (like how clients register themselves)?

    Thanks again for a great post.

    1. It’s possible to do so if you wish, but does require significant effort to accomplish. Specifically, you would need to set the DNS Suffix on your Network Adapters’ Advanced DNS settings to be company.com (This may also be done using DHCP, I believe), then set the adapters to register themselves using that domain name. I would avoid doing so on the Domain Controllers, though, since they will register the Root domain of company.com as the AD Root Domain. This would allow you to use domain.com for purposes other than AD. It’s not really a best practice to do so, and it does significantly increase administrative effort in configuring clients, but as I said, it’s possible.

      Note, though, that the clients could end up registering themselves in two different DNS zones. If that doesn’t happen, though, AD would probably suffer from it, since it relies so heavily on DNS.

  3. Hi

    Your article is the most complete around, congrats on the result.

    Our name has changed a couple of times, we still control previous domain names (external) for maybe one more year. Our users still authenticate with the first name and we are looking forward to set up everything from zero. We have Exchange and the posibility of a new name after that still remains. My opinion is to buy a “service” domain for internal use with no e-mail nor web page and just create as many mail conectors as the company needs with the name changing, does this sound ok?, how about the certificates

    Thanks
    Al

    1. A service domain for internal use only would work well, for the most part. If it’s only used internally, there aren’t really any downsides to using the actual domain for your AD domain name, since you don’t have to struggle with split horizon in that situation.

      As far as Exchange goes, though, be aware that it does get a little more difficult to manage autodiscover with that setup, since there can only be one usable “from” address. You can have mail deliver to as many addresses as you want, but only one will ever be able to respond on each mailbox.

      For certificate purposes, you would use a SAN cert that includes all the names that the server can use (Mail.domain1.com, mail.domain2.com, etc.) to allow autodiscover to function properly.

  4. Like others I just found this article and it’s great. I was hoping to get a little clarification for our current setup and moving it. Here’s how we are currently setup. internal is mycompany.lan and we do own and use mycompany.com for website and email hosted by Google. Can I move my domain directly over to ad.mycompany.com without moving users and everything or do I have to first change the name to mycompany.com. Then create a sub-domain called ad.mycompany.com and then move everything into the new domain? I think I’m over-complicating things.
    Any thoughts would be appreciated.

    Cheers,

    Dan

    1. You can directly rename the domain to ad.mycompany.com, but be aware that if you have Exchange or other heavily AD integrated solutions, renaming the domain will break them thoroughly. As such, moving to a new domain is recommended if you want to use this method.

      That said, most of the problems surrounding the use of an “internal” domain name can be worked around with a little effort and thought, so unless you are already planning to build a new domain for some reason other than just needing to rename, it isn’t worth the effort involved to do so.

      1. That’s great to hear, the reason I was looking at it is that we have been moving several services over to hosted solutions and we would like to use LDAPS to do authentication. I figured it would make life easier to have our internal FQDN to match our external.

        Thanks again!

        Dan

  5. There’s a problem I’ve run into with using a subdomain. There’s a high likelihood of the subdomains conflicting between two domains when forming a trust. Take, for instance, corp.contoso.com and corp.adatum.com. The single label names for both of these domains would be corp. There will be a lot of difficulty establishing a trust between these two domains.

  6. Thanks again !

    The only concept remaining is how would clients access autodiscover and e-mail etc in this scenario. Is at as simple as the internal clients pointing to a internal address for autodiscover/e-mail and external clients pointing to a public ip which redirects through the router to the CAS ?

    Thank you

    1. You just need to make sure DNS is pointing to the server for all of those Host names. Internal DNS points to Internal IP, External DNS points to External IP. Since outlook uses the user’s Email Domain to do Autodiscover lookups, you’ll need to make sure your firewall allows traffic to go from internal to external IPs or configure a pinpoint DNS zone for each of the external host names with the Internal IP address assigned to them. This will allow Autodiscover to work properly when using an email domain that matches your External domain. This is mostly for devices not connected to the Domain, though. For domain connected computers, you will need to set the Autodiscover Service URI to use your Internal Host name for the mail server. I wrote another article on this subject (http://wp.me/pUCB5-7X ) that explains the process.

  7. Fantastic thread by the way.

    Internal AD : euc.contoso.com
    External DNS : contoso.com

    If I had two Exchange 2013 servers hosted internally with the following

    mail.euc.contoso.com
    autodiscover.euc.contoso.com

    From your above comments, that would mean the wildcard certificates would not work in this situation. Could I ask what certificates would you recommend so that internal and external users could authenticate to exchange without error messages

    I’ve heard mention of multi-domain certificates being used?

    1. A SAN (subject alternate name) cert can be used for your situation. These do tend to be more expensive than wildcards, but are more secure. I wrote another article in December 2015 that explains why.

      That said, you can also still use your wildcard cert for the external DNS zone for autodiscover, but you would either need to use your external IPs and DNS, or you can use pinpoint DNS to avoid having to manage split horizon DNS. Exchange 2013 only allows access from outlook through outlook anywhere/mapi over https, so using you public IPs won’t break things or require additional setup in outlook. You’ll just need to make sure your firewall allows internal clients access to public resources.

      1. Thanks again for the reply and I’m glad to see I’m not the only one working through the concepts!

        So, if I had a multi-domain cert containing the following then internal and external clients could authenticate without certificate errors or have I got that hopelessly wrong?

        contoso.com (external)
        mail.contoso.com (external)
        autodiscover.contoso.com (external)
        euc.contoso.com (internal)
        mail.euc.contoso.com (internal)
        autodiscover.euc.contoso.com (internal)

        Thanks for your help

        1. That would work, yes, but you wouldn’t need to use contoso.com unless you wanted people to access the mail server by using the root domain name. Euc.contoso.com can never be used to access the Exchange server, since the root domain name in an AD environment is reserved to point to Domain Controllers only.

          So what you would need for your situation is these host names on your cert:

          mail.contoso.com
          autodiscover.contoso.com
          mail.euc.contoso.com
          autodiscover.euc.contoso.com

  8. Pingback: Welcome! | AC Brown's IT World

  9. Only just come across this – for years I’ve been using .local! Tell me, if I have the website contoso.com, and make my AD domain internal.contoso.com, do I have to do anything special with the management of the domain? Do I have to create the subdomain on my domain management website (GoDaddy in this instance)? Or can I just leave it?

    Many thanks!

    1. You can just leave it. Basically, internal DNS will cause your internal clients to use External DNS when attempting to connect with http://www.domain.com. If this website is hosted by a third party, you’ll have no problems, but if you host the website on your own network, you’ll want to make sure your router/firewall is properly configured to allow internal sources to reach public IP addresses.

      You don’t have to have a zone for internal.domain.com in Godaddy, since that zone will only reach internal sources.

      I will note, though, that if you use this method, abandon any thoughts of utilizing Wildcard certificates, as they do not support subdomains. In other words, if you have a certificate for *.domain.com, it won’t be valid on a server you access using server.internal.domain.com. So there are trade offs for every method, but the subdomain method is currently recommended due to the way AD integrated apps like Exchange work now.

      1. Thank you very reply for your reply and help! We don’t run Exchange or any other ‘fancy’ domain roles, just AD, WSUS, WDS, DNS and DHCP – the basics! Again, thanks!

  10. Wow, great article! This is exactly what I needed to see with deciding on a new local domain name for my client. They’re running into the very issue you described, where they already have a .local domain and they’re running their own Exchange server and we can no longer get a proper certificate for it. So I went looking into best practices on what naming convention to use for the new domain, but I always saw either outdated information or people who would just say to use a certain method without any reason as to why or and no references to back them up. Thank you for writing this!

  11. Hi, we are in a process of migrating from using internal name in AD to a valid DNS name. The DNS name also happens to be our internet presence. We are currently debating whether or not we should use a subdomain (for e.g. use ad.domain.com vs use domain.com). My take on this is that if we use ad.domain.com, it will keep our current internet presence intact (i.e. http://domain.com would continue to work and not break). However, our AD expert insist that even if we use ad.domain.com, we’d still need to point both ad.domain.com and domain.com to IPs of DC. I have tried to find specific answer to this but so far have not been successful. When I stumbled upon this blog entry thought should ask this question. Would highly appreciate your response.

    1. No, you would not have to point domain.com to a DC if you use ad.domain.com. As far as Active Directory is concerned, ad.domain.com is the root domain, meaning it’s the lowest level of the domain hierarchy. You *can* set up a DNS zone internally for domain.com, but you would not need to point the domain name’s A record to a DC if you did that. You would be free to point domain.com to any IP you wish, which is not the case in a situation where you use domain.com as the root AD domain name.

  12. This is all well and good, but something nobody mentioned is when some application or appliance with an embedded OS decides it can’t handle the extra level of your subdomain. I’ve had errors because the developers of the problem software or hardware never expected to see 4 levels of a domain. They just expect it to be in the format of host.domain.tld. It ends up using your subdomain name as the host,

    1. Lazy developers are always going to cause problems. There’s little we can do about that except refuse to use their stuff if it doesn’t work right because the environment utilizes modern best practices. I realize this isn’t always possible to do, but these kinds of things are usually easy to fix programmatically, so if you run into this kind of issue, the best thing to do is talk to the vendor and tell them what’s up.

  13. Hello,
    Is it a good configuration ? :

    internet domaine name is : contoso.com
    AD forest is : internal.contoso.com
    2 childs domain AD : A.internal.contoso.com and B.internal.contoso.com

    Thank You

  15. Pingback: Active Directory Domain Naming Best Practices | Oxford SBS Guy

  17. Thanks for the article.

    Our AD domain is public, and the domain is not even registered by us. I contacted the owner of the domain and they want $15k+ to sell it (they are one of those companies that buy up lots of domain names.)

    Our AD domain has been setup this way for 14 years. We have no issues that I’m aware of, but I’ve always known this is something that was configured incorrectly. In my research to rename our AD domain I came upon your article.

    Is it worth the effort for me to rename my AD domain for the reason that I don’t own it and can’t buy it? What are the potential problems or issues that would occur by continuing to use an AD domain we don’t own? (other than the obvious that we can’t visit that domain from our internal network.)

    1. If you have Exchange or other Domain-centric applications, you won’t be able to rename, but would have to migrate to a new forest. There generally isn’t a big deal with having an internal AD Domain Name that someone else owns, you just won’t ever be able to get to websites hosted on that domain from your network.

      1. We are in this situation for a long time and I have been defending that there is no need to rename or migrate to a new forest name just because the current AD domain is not owned by us though a lot of pressure from security team still prevails. Hence, in order to substantiate my stand, I have to provide some solid reasoning. Can you please explain what are the security risks existing and how to mitigate them, if any.

        1. It kind of depends, really. If you use something like .local or .internal for your internal network and no one else owns that domain publicly, there is no realistic security issue with retaining your existing setup. I would recommend obtaining the public version of that domain if possible. If it is not possible to purchase the domain because there are no domain name registrars for the root domain (.com, .org, etc are root domains), there is absolutely no security issue involved in retaining and continuing to use that domain name. http://www.iana.org/domains/root/db has a list of current root domains that can be obtained and the Registrars that sell them.

          If, however, the root domain for your internal domain *is* available for purchase, you should immediately do so. If someone else owns that domain, you do actually have a significant security risk. Here’s why. The owner of a domain on the Internet is considered authoritative for all actions involving that domain. This includes creating new DNS records, defining mailflow, and purchasing digital certificates for server authentication. The most significant risk you face is that the real owner of the domain you are using could potentially create Digital certificates with a Public CA that would automatically be trusted by all clients on your network. Such a certificate could then be used to perform a man-in-the-middle attack against any system on your network. Because the certificate is considered valid by virtue of being issued by a public CA, there would be no way to determine whether encrypted data between systems on your internal network is being spied on. By way of example, using an internal domain name that someone else owns is like buying a house that someone you don’t know has all the keys for. The likelihood of someone actually breaking into your network because they own your domain is extremely small, but the mere existence of such a possibility is enough to put security guys on edge. If you are using an Internal domain name that someone else owns, I would highly recommend migrating away from it or purchasing the domain from the current owners (if you can).

          Now, if the domain you are using cannot be owned (as verified by the list I linked you to above), there is no security issue because you are the only one who can control that domain. Even if someone else has the same internal domain name on their network, they cannot control your network because nothing in your network would trust anything in their network. There are some administrative concerns with using an un-ownable domain name, and there is no guarantee that no one will ever offer that root domain in the future, so be wary of creating new domains that use “private” root domains. If you already have one and there is no other reasoning to support a migration to a new forest (you’re not merging with another company, for instance), the effort required to migrate solely for the purpose of changing the domain name is simply not justifiable.

      2. We are in this situation for a long time and I have been defending that there is no need to rename or migrate to a new forest name just because the current AD domain is not owned by us though a lot of pressure from security team still prevails. Hence, in order to substantiate my stand, I need to provide valid reasoning. Can you please explain what are the security risks existing and how to mitigate them, if any.

      3. I was counting on your first reply “There generally isn’t a big deal with having an internal AD Domain Name that someone else owns, you just won’t ever be able to get to websites hosted on that domain from your network.” but your reply to my query is confusing me. Anyway, let me make our situation clear… The AD domain name is in .NET TLD and obviously, there are no internet facing services in this domain since it is not owned by us. Yes, it is available for purchase but there is a price. All our internet facing services are in different TLD and some of the applications are getting authenticated by our internal AD which is in .NET domain. On all laptops, we have a VPN client which will connect to office network only. Does this scenario still pose risks?

        1. There is a definite security risk in having an internal domain name that someone else owns. Specifically, it opens up the potential for a difficult to detect man-in-the-middle attack against servers in your environment. But it is worth noting that the actual likelihood of this happening is so small that most environments need not worry about it. However, environments that have to meet the demands of some regulatory compliance laws (particularly those required by financial institutions and government) would want to resolve such an issue ASAP, since it would raise red flags during security audits and likely prevent them from being able to obtain a Certificate of Networthiness.

  19. I keep hearing this but the .local TLD is reserved for multicast DNS. Stop using it for AD because it confuses the hell out of systems which use mdns technologies.

    1. Generally, Windows systems don’t utilize mDNS (yet). The only time this really becomes a major problem is if you are interfacing with systems that utilize Bonjour or Linux based mDNS. Neither solution is currently utilized heavily in networks that have AD. That said, mDNS is part of the reason third party CAs are refusing to approve SSL certificate requests that have that TLD.

  21. so let’s say we call our domain ad.company.com. our internal servers would then be server1.ad.company.com, server2.ad.company.com etc? and we would create similar entries on our external DNS, so users can always enter the same URL to get to the same site regardless of whether they were internal or external… but what about wildcard SSLs? They only work for one level of subdomain… so right now we are able to use a wildcard SSL to cover server1.company.com and server2.company.com etc. Wouldn’t naming our domain ad.company.com prevent us from being able to do this?

    1. Users would be able to get to the same location with the same URL even if you don’t publish your internal DNS externally. You could easily add an internal version of company.com and instruct users to use that for DNS lookups. You can even configure client machines to register themselves in that Zone.

      The issue with using the same domain internally and externally is that internally, there is no way for users to reach a website at http://company.com, since that host name is reserved for DC lookups. I have clients who have websites designed to use company.com as a source for images, and those images never show up internally, and there is no way to make them. The site has to be redesigned.

      With a subdomain as the AD domain, that stops being a problem, and an internal version of company.com can be used without issues.

      So using company.com and company.local create problems that can be very problematic to work around.

      If you use wildcard certs with ad.company.com as the internal domain, you can make those certs valid with an internal DNS zone, like you would if using .local, but realistically, wildcard certs are technically less secure than a SAN cert, so you would actually want to use SAN certs rather than Wildcard if you’re using this technique. It takes more work to do so, in that you have to make sure you have defined every possible server name on the cert, but it’s more secure because because the authentication of that cert is restricted more heavily.

      1. to clarify – many of our users have laptops and work from home, starbucks etc. i don’t want them to have to keep track of which URL to use depending on where they are – the same URL should work to access our internal servers, whether they are here in the office or at starbucks using public wifi. when i say internal servers, i just mean servers inside our office; they are publicly accessible over the internet.

        if we are creating internal DNS records for company.com then we haven’t avoided the extra work of a split domain at all – so the ONLY advantage of using the subdomain for the AD name is the issue of the company.com website? a real concern, to be sure, but it seems to be the only actual disadvantage.

        the wildcard certs are secure enough for our needs, we use many different subdomains for internal project development and keeping SANs for all of them would be a huge headache.

        1. Best practices are recommendations, not requirements. Maintaining split DNS is less of a problem if you do it right, but not being able to use company.com can actually be a major issue with some applications.

          If that doesn’t affect you, you’re more than welcome to do whatever you want. It’s just important to know the risks and problems with using a specific technique in your environment before doing so.

  22. Nice job. I hadn’t thought of the sub-domain option before. We’d been using a workaround called pin-point dns for our existing Exchange/AD environments. It works well, but the sub-domain is a great idea for greenfield AD forest/domains as you don’t have to register/remember multiple public domains.

  24. Any suggestions for multiple domains that are in the same forest? If we have two locations and called them nyc.company.com and dal.company.com, the root domain for the forest is then going to be company.com. Which gets us back to the same problem of using our company public presence. Any way to get around that without changing our naming convention?

    1. With the Forest Root being the same as your external domain, there isn’t a whole lot you can do about your problem without completely rebuilding the forest, so you’re going to be stuck dealing with Split Horizon DNS until you can migrate to a new forest. This is something that people will be dealing with for years and it isn’t a huge problem, you just have to understand how to work around this problem by making sure your DNS settings for your root domain mirror your external DNS (But possibly with Internal IP addresses for resources instead of External IPs).

  25. Unfortunately SBS 2011 (which we are still rolling out to customers) will automatically assign .local to any domain name you choose during the wizard otherwise I would have implemented this.

  26. A bit late to the discussion…

    We seem to rename/buy/divest bits and pieces of our company rather frequently, so we picked a completely unrelated tld.net and used that. It works a treat but does mean we have to manage some horrendous SANs in certificates sometimes. It’s a trade off for this against “what our company is called today” type issues.

  27. Instead of making the AD domain a child domain of your public domain, why not just use a different public domain (that you own of course), i.e. company.net, No split domain, no certificate issues AND you don’t have to type in extra long FQDN

    1. But you do have to pay for and keep track of multiple Domain Names. It’s an acceptable practice to have a separate owned domain internally. Some Certificate Authorities may also have issues with attempts to generate SANs with multiple root domains listed on them, and wildcard certs outright cannot yet be issued for multiple domains. With a subdomain of the public domain, a wildcard certificate will work for all servers on the internal and external domains.

  28. Thank you. You’ve just save me a lot of headache with a great explanation of why. I was this close to doing it the old school way (.local) in a redesign of a network I inherited that actually uses a public domain name owned by someone else.

    1. Agreed. I’m in a similar situation right now. Did you do a domain rename, or just drop in a new AD server and disconnect/reconnect all domain attached machines?

  29. Awesome article, unfortunately for me it does show that I’m getting old. Started building a new domain as was told what i was doing wasnt best practice anywhere…… Still learning……

  33. Thanks for the information. The company I work for has recently restructured and I’m left with designing everything from scratch (Network, AD, Exchange, etc) and there is so much conflicting information about how things should be done.

    I’m relatively new to many aspects, so it’s nice to have something more than, “do it this way!” I like your comparison.

Leave a Reply