«
»

Choose your Active Directory DNS namespace wisely

7. June, 2007

Active Directory is based on three pillars – LDAP, Kerberos and DNS.

A long time ago, i’ve written some documentation about DNS.

Okay, so when you setup Active Directory for a new domain, you will have to choose your namespace. It is theoretically possible to change this later, using the Windows Server 2003 Active Directory Domain Rename Tools, but this will cause you a lot of pain – something one usually wants to avoid.

The problem with choosing your namespace is that it sometimes drifts off into philosophical discussions, and when having to setup a new AD this isn’t high on any list.

Things that are universally recognized as wrong

  • Choosing a single label Active Directory DNS namespace (like “company”). While it is possible to support a single label Active Directory namespace, it involves unnecessary hassle. If you did this in the past, consider building a new domain or renaming it – if you’re a small environment, the first is usually easier. Use ADMT to migrate accounts and settings.
  • Choosing somebody else’s namespace as your Active Directory DNS namespace – for example, naming your Domain “slashdot.org”. While this might sound stupid at first, i’ve actually seen this in reality – they weren’t able to get the name they wanted from switch, but hey, it worked internally. Don’t do this.

Things that I and some other people recognize as wrong

  • Choosing a made-up TLD for your Active Directory DNS namespace. For example, “mycorp.local”. While this probably won’t cause any problems in reality, it’s doesn’t look nice – and there’s still the theoretical chance that you have to establish a trust to a company that has the same namespace. While i haven’t seen that problem yet in the field, i know two companies that use “activedirectory.local” – they couldn’t establish a trust to each other.
  • Choosing your official second level domain as your Active Directory DNS namespace. For example, “projectdream.org”. This approach actually isn’t that bad, but it lacks a clear distinction between your internet presence and your Active Directory. In reality, this configuration is likely to cause problems when you switch web hostings.

Things that I and some other people see as being correct

  • Use a subdomain from your official second level as your Active Directory DNS namespace. For example, “ad.projectdream.org”. You can choose anything instead of “ad”, as long as it makes some sense. I’ve seen “ntds”, “int”, “corp”. As a complaint i’ve seen here is Exchange than generates the wrong addresses – but that’s just the default recipient policy, which you will need to modify. And if you want to logon using your email address, you will need to add an UPN suffix for the second level domain. I do not really know a disadvantage of this strategy.

So, there are many ways which will lead you to your goal. I would be interested in how other people handled this, and especially if you know of any disadvantages of my approach.

Category: Windows  |  Comment (RSS)  |  Trackback

6 Comments

  1. Geedoubleu:

    Good description of the issues.

    Businesses these days are sick of being stuck with an out of date domain name or having to do domain migrations when their company name changes. So they are asking for the domain to be called something generic like GLOBAL.

    So you solve the business issue by using GLOBAL.LOCAL everyone is happy. The users just see GLOBAL and IT people see myserver.global.local, great all self explanatory offers affordance. Absolutely nothing wrong with using .local or .internal.

    The problem with this is if your company aquires another company and they have also called their AD this generic name, no simple migration is possible because you can’t create a trust.

    So by using a real domain name and registering it you are making sure it is unique, trouble is there is nothing simple and generic left on the internet they have all already been registered, plus you could do your bit by following the rules, but someone could still use your name internally even if you register it on the net.

    Plus even if you find a free domain name, you can still end up with NETBIOS names clashes, as I could have mycompany.com and I try to make a trust with mycompany.net. Both NETBIOS names will be the same and this DOES cause issues.

    The business doesn’t like it but you have to go with your company name or trademark, this makes sure it is unique and by using a subdomain of your real domain you solve the DNS issues usually associated with using the same domain name internally and externally.

    There is no magic fix that solves all the problems.

    You have to ask a business question, what is more expensive and greater risk to the business?

    1/ Use your company name/brand and having to do a domain migration if the company name/brand changes
    2/ Use a generic name not registered on the internet and not being able to create a trust with another company because by chance they have called their AD the same generic name.

    I’d go with a mix of the two called it something generic based on your company name, like if you were called rainmakers insurance services plc, you could go for rainmakers.local or RIS.local. Doesn’t solve the problems but is a good compromise.

    23. October, 2008, 21:18

  2. Mel Keyser:

    Thanks for the tips. This is one of the most poorly documented areas of AD design. I’ve read a few AD books but none have really given good advice on choosing an AD DNS name. The books just mention to pick a DNS domain name, so the reader just assumes that the name must be some valid top-level domain name. I once did work at a company where their previous IT consultant named their AD domain name http://www..com. Yes, the AD domain name was WWW. How ridiculous is that? That just shows you that the person who set that up didn’t have a clue.
    I like the idea of adding “ad” to the company’s existing Internet DNS name, eg, ad.something.com. But some companies merge regularly, so they want to keep the entire name as generic as possible and not include the something.com part. But either way, if you use ad.something.com or ad.something.local, the “ad” part is still generic and it’s very possible that your company merges with or partners up with another company that uses ad.somethingelse.com, in which case the “ad” part conflicts.
    So I think a good strategy to be both safe and generic is to use a name with some variation of “ad” or “active directory” in it + a generic, non-official suffix such as .local, .dom, .msad, etc. Some examples:
    • active-dir.msad.dom
    • corp-ad.active-dir.local
    • ad-corp.ad-ms.dom
    • ent-ad.directory.local
    • law-firm-ad.activ-dir.dom
    Now that I’ve put these online, they might not be so unique, but you get the idea. . .

    30. September, 2009, 03:16

  3. One year with SBS 2008 » Lukas Beeler’s IT Blog » Blog Archive:

    [...] Always use the answer file to deploy SBS 2008. This will make it possible to choose a custom domain name. Read my post about choosing your AD DNS namespace [...]

    15. October, 2009, 16:41

  4. Anonymous:

    Thanks for explaining in fairly well-written English what I was thinking & questioning while setting up a test domain. You share some good tips. It’s too bad this isn’t up farther on Google’s results.

    16. December, 2009, 20:21

  5. Tomasz:

    Hello Lukas
    I’ve start to work in company that has A.D domain name DOMENA01.
    As you wrote it is not good idea to use that name.
    I think about changing this A.D. domain name but first I have to explain my supperior why this exisiting domain name is wrong.
    Could you help me gather some information which help me to force an idea to change this name and use for example DOMENA01.LOCAL or buy DOMENA01.NET and use it?

    5. January, 2010, 17:28

  6. Lukas Beeler:

    Hi Tomasz,

    How large is your environment? How many servers, users and desktops?

    Renaming a domain is something that can be done theoretically if you’re not using Exchange 2007/2010, but i would not recommend that.

    If you use ADMT, it’s not that hard, and in smaller environments can be done on a weekend.

    As for reasons: Unfortunately, it can be very hard to get a business case on fixing non-recommended configurations.

    Here a few MS KBs on the topic:
    http://support.microsoft.com/kb/300684
    http://support.microsoft.com/kb/914050
    http://support.microsoft.com/kb/909264

    5. January, 2010, 17:42

Leave a comment