I was out last week for dinner (I was in Redmond for a technical conference) and a fairly heated discussion came up about DNS Naming Strategies for Active Directory. Take an x-enterprise strategy consultant, AD design consultant and an x-RedHat/Oracle engineer and throw them the DNS naming strategy topic and some interesting points get raised. I won't tell you who raised which strategy - I'll let you make your own.
Option 1 - Use the same Internal and External domain names.If I already own rickcomapny.ca and I use it externally, why not use it internally as well? Humm... Maintain 2 DNS zone files on two servers that will from this day forward never exchange information and will need to be separately managed. This might seem like a good KISS principle and minimize internal client "comfort" of not having to change DNS namespace. In actual fact - it places much more administrative burden on the DNS admins and is not exactly "future proof" for changing business needs. You will have to manually add external entries into your internal zone. You will have to selectively add internal resources to your external zone. How will you handle internal and external records when you transition to IPv6?
I'm not knocking this method - I've implemented it for customers in the field - after they have reviewed all the Pros and Cons.
Option 2 - Use a delegated sub domain of the external domain for the internal domain.Once again - if I own rickcompany.ca and I use it externally (either I host it on a set of servers or my ISP hosts it), I create a sub domain internally only (at this time) that could be called corp.rickcompany.ca or ad.rickcompany.ca or whatevermakessense.rickcompany.ca. Because this sub domain is only maintained internally on the internal DNS servers, it can't be accidentally placed on the outside servers. Clients and servers would be part of the internal sub domain of rickcompany.ca and function as normal in an AD environment. If you already had a large (or small) DNS zone of rickcompany.ca, the records could be transferred internally as secondary zones and maintained on which ever servers required the zones. This is by far the easiest one to manage, since you control the zone and don't have to worry about what is inside and outside. You are also futureproofing your design, since you have unique names inside and out. If your internal clients have the bad habit of not fully qualifying resources in the rickcompany.ca domain, you can add it to your list of search domains to ensure proper name resolution.
Option 3 - Use a non-standard internal domain. (Dustin Norman reminded me of this one). I have used this one on only one occasion. I warn you that you should use this one with caution - as it severely limits your ability to easily manage externally accessible internal resources. If you choose to use rickcompany.internal or rickcompany.local as your internal DNS domain name, you virtually guarantee that your internal hosts will never be resolvable from the outside world without jumping through hoops. It is not generally a recommended best practice to use this type of non standard DNS domain naming convention without looking at all the implications.
I'll end off this conversation by saying - make sure to understand all the implications of DNS naming convention. Only after you have evaluated all the options should you make your choice. You need a rock solid understanding of DNS and how it works in order to ensure a strong foundation for AD and name resolution.
How do I answer when someone asks me the naming question? "It depends....."
Here's a link to the Windows Server 2003 Deployment guide discussion on DNS naming conventions.http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dnsbd_dns_tvnd.asp