Naming AD Domain

I have a question regarding best practices for naming a new Active
Directory domain. The domain is responsible for receivng and sending of all
mail messages using Exchange. Should we use

mydomain.inc
or mydomain.local OR should we register
a domain within a real name (.com - the same as the Email domain) and use it
for our Active Directory FQDN?


Thanks

Howdie!

microsoft schrieb:
> I have a question regarding best practices for naming a new Active
> Directory domain. The domain is responsible for receivng and sending of all
> mail messages using Exchange. Should we use
>
> mydomain.inc
> or mydomain.local OR should we register
> a domain within a real name (.com - the same as the Email domain) and use it
> for our Active Directory FQDN?

You can configure further domains Exchange can accept for mail delivery
other than the domain name. You can name your AD forest just like your
internet domain like mycorp.net or like a sub domain ad.mycorp.net.
Exchange can be configured to accept emails for both domains.

Cheers,
Florian
--
Microsoft MVP - Group Policy
eMail: prename [at] frickelsoft [dot] net.
blog: http://www.frickelsoft.net/blog.
Maillist (german): http://frickelsoft.net/cms/index.php?page=mailingliste

Hello Microsoft,

"You can also use the same name for the internal domain and the external
domain. However, this method is not recommended. It creates name resolution
problems because it introduces DNS names that are not unique. This method
requires additional configuration to enable optimized performance."

From: http://technet.microsoft.com/en-us/l.../cc755946.aspx

Also see this one:
http://technet.microsoft.com/en-us/l.../cc759036.aspx

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm


> I have a question regarding best practices for naming a new Active
> Directory domain. The domain is responsible for receivng and sending
> of all
> mail messages using Exchange. Should we use
> mydomain.inc
> or mydomain.local OR should we register
> a domain within a real name (.com - the same as the Email domain) and
> use it
> for our Active Directory FQDN?
> Thanks
>

microsoft <microsoft@discussions.microsoft.com> wrote:
> I have a question regarding best practices for naming a new Active
> Directory domain. The domain is responsible for receivng and sending
> of all mail messages using Exchange. Should we use
>
> mydomain.inc
> or mydomain.local OR should we register
> a domain within a real name (.com - the same as the Email domain) and
> use it for our Active Directory FQDN?
>
>
> Thanks

The internal domain has nothing to do with a) the registered Internet domain
and b) any internet domains you might eventually use for email.


I would either use companyname.local (or companyname.lan) or use
internal.companyname.com ....or better yet, you can be totally generic,
which is nice in the event that your company changes names (or changes
hands). How about office.local, with server01, server02, etc.? Domain
renames are an enormous pain especially if you use Exchange.

"Lanwench [MVP - Exchange]"
<lanwench@heybuddy.donotsendme.unsolicitedmailatyahoo.com> wrote in message
news:%23aQfxxw0JHA.1712@TK2MSFTNGP03.phx.gbl...

> I would either use companyname.local (or companyname.lan) or use
> internal.companyname.com ....or better yet, you can be totally generic,
> which is nice in the event that your company changes names (or changes
> hands). How about office.local, with server01, server02, etc.? Domain
> renames are an enormous pain especially if you use Exchange.

I like companyname.loc, thats what I use here. I use ".loc" rather than
".local" because some non-MS OS's have trouble if the TLD is more than three
characters.

I don't like three-word domain names (internal.companyname.com) because it
makes them confusing to distinguish them from a Child Domain or fully
qualified hostnames.


--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

Phillip Windell <philwindell@hotmail.com> wrote:
> "Lanwench [MVP - Exchange]"
> <lanwench@heybuddy.donotsendme.unsolicitedmailatyahoo.com> wrote in
> message news:%23aQfxxw0JHA.1712@TK2MSFTNGP03.phx.gbl...
>
>> I would either use companyname.local (or companyname.lan) or use
>> internal.companyname.com ....or better yet, you can be totally
>> generic, which is nice in the event that your company changes names
>> (or changes hands). How about office.local, with server01, server02,
>> etc.? Domain renames are an enormous pain especially if you use
>> Exchange.
>
> I like companyname.loc, thats what I use here. I use ".loc" rather
> than ".local" because some non-MS OS's have trouble if the TLD is
> more than three characters.

Hmmm, maybe. I don't think Macs care (OSX anyway) - do *nix boxen?
>
> I don't like three-word domain names (internal.companyname.com)
> because it makes them confusing to distinguish them from a Child
> Domain or fully qualified hostnames.

It is a child domain, really. Just a private one. I personally like the
generic idea best these days - how often do we see people posting questions
about domain renames after a merger/acquisition? internal.lan or office.lan
works perfectly well.

"Lanwench [MVP - Exchange]"
<lanwench@heybuddy.donotsendme.unsolicitedmailatyahoo.com> wrote in message
news:uBim28x0JHA.1196@TK2MSFTNGP03.phx.gbl...

>> I like companyname.loc, thats what I use here. I use ".loc" rather
>> than ".local" because some non-MS OS's have trouble if the TLD is
>> more than three characters.
>
> Hmmm, maybe. I don't think Macs care (OSX anyway) - do *nix boxen?

It was the Macs before they "*nix'ed",..like version 9 or older. I don't
know if there are any others out there, but I still just like to follow it
as a "good practice".

>> I don't like three-word domain names (internal.companyname.com)
>> because it makes them confusing to distinguish them from a Child
>> Domain or fully qualified hostnames.
>
> It is a child domain, really. Just a private one. I personally like the
> generic idea best these days - how often do we see people posting
> questions about domain renames after a merger/acquisition? internal.lan or
> office.lan works perfectly well.

Ok, yea if it is a Child Domain that's fine. We used to be in one
([hostname].wand.lintv.com),..then we were sold to another company that
didn't join their Station's networks together, so I rebuilt the Domain back
to wandtv.loc like it used to be years ago. I suspect that if they ever
join things it will be an inter-forest trust rather the monkeying around
with the actual domains or forest.

--
Phillip Windell
www.wandtv.com

The views expressed, are my own and not those of my employer, or Microsoft,
or anyone else associated with me, including my cats.
-----------------------------------------------------

"microsoft" <microsoft@discussions.microsoft.com> wrote in message news:6B7CE7AA-4E1D-44F0-ADCA-5971B0D8F2F8@microsoft.com...
>
>
> I have a question regarding best practices for naming a new Active
> Directory domain. The domain is responsible for receivng and sending of all
> mail messages using Exchange. Should we use
>
> mydomain.inc
> or mydomain.local OR should we register
> a domain within a real name (.com - the same as the Email domain) and use it
> for our Active Directory FQDN?
>
>
> Thanks


In addition to everyone's great replies, here is an old blog that I put together with help from another former MVP.

==================================================================================================== ==
==================================================================================================== ==
What's in an Active Directory DNS Name?
AD Design considerations

Same name AD DNS domain name and external name (split-zone)
I must say this is a classic question that stems back to the beginning days of AD. Naming your internal domain name can be based on a number of things, whether technical or political, or previous administrative experience. This has been highly discussed (not debated) in the past. Whatever decision you make for an AD DNS FQDN domain name, just understand the ramifications. Actually I'm not going to try to get into any sort of debate, for there is really nothing to debate, nor help someone decide on what is 'right' or 'wrong' but rather just state the implications and how to get around them, no matter what the decision was based on.



The following passage below is a compilation of a discussion between myself and Todd J. Heron, a fellow MVP, from a few years ago.

===

Classic question:
"Which are the advantages of naming my domain with domain.com rather than domain.local? I have a domain.com registered for my Company that i use for my e-mail and Site Internet."

There are different answers to this classic question and while these answers ultimately depend upon company preference, much of the direction will be based upon administrator experience. The three basic scenarios outlined below are the most commonly given answers to the question, sometimes altogether and sometimes not. Some company networks use a combination of these scenarios. When explaining it to a relative beginner asking the question, many responses omit explanatory detail about all the scenarios, for fear of causing more confusion.

All three approaches will have to take both security and the end-user experience into perspective. This perspective is colored by company size, budget, and experience of personnel running Active Directory and the network infrastructure (mostly with respect to DNS and VPN). No one approach should be considered the best solution under all circumstances. For any host name that you wish to have access from both your internal network and from the external Internet you need scenario 1, although it is the most DNS-intensive over time. If you do not select this option and go with scenario 2 or 3 only, consideration will have to be given to the fact that company end-users will need to be trained on using different names under different circumstances (based on where they are (at work, on the road or at home).

===


Scenario 1.
Choosing the same name internal/external (spilt-zone, or split-brain, whatever you want to call it) has the most administrative overhead. Why chosen? Either because a misunderstanding of the pros/cons, political, or for ease of use.

Pros:
1. Their email address is their logon name. Easier to remember.

2. Security. Each DNS zone is authoritative for the zone of that name so therefore the external DNS zone and internal AD/DNS zone will NOT replicate with each other thereby prevent internal company records to be visible to the outside Internet.

3. Short namespace. Users don't have to type in (or see) a long domain name when accessing company resources either internally or externally. Names are "pretty".

Cons:
1. Administrative overhead. If trying to get to your externally hosted website, it won't resolve because a DNS server will not forward or resolve outside for what a zone that it hosts. You can overcome resolving the www.domain.com dilemma by using a delegation. Rt-click your zone, new delegation, type in 'www' and provide the public SOAs for the nameserver(s). This way it will send the resolution request to the SOA and resolve that way. As for http://domain.com, that is difficult and would instruct all users to only use www.domain.com. This is because of the LdapIpAddress, the record that shows up as (same as parent), which EACH domain controller registers. So if you type http://domain.com, you will round robin between the DCs. To overcome that, on EACH DC, install IIS, then under the default website properties, redirect it to www.domain.com and let the delegation handle it. Now if you were to be using Sharepoint services, or something else that connects to the default website (no sub folders or virtual directories), then it becomes a problem. I know numerous installations setup with this and have operated fine for years.

2. Security. Each DNS zone is authoritative for the zone of that name so therefore the external DNS zone and internal AD/DNS zone will NOT replicate with each other thereby prevent internal company records to be visible to the outside Internet.

3. Any changes made to the public DNS zone (such as the addition or removal of an important IP host such as a web server, mail server, or VPN server) must added manually to the internal AD/DNS zone if internal users will be accessing these hosts from inside the network perimeter (a common circumstance).

4. VPN resolution is problematic at best. Company users accessing the network from the Internet will easily be able to reach IP hosts in the public DNS zone but will not easily reach internal company resources inside the network perimeter without special (and manual) workarounds such as maintaining hosts files on their machines (which must be manually updated as well everytime there is a change to an important IP host in the public zone), entering internal host data on the public zone (such as for printers, SRV records for DCs, member server hosts, etc), which exposes what internal hosts exist, or they must use special VPN software (usually expensive), such as Cisco, Netscreen, etc, which is more secure and reliable anyway.

For further reading on this scenario:
http://www.isaserver.org/tutorials/Y...Split_DNS.html
http://homepages.tesco.net./~J.deBoy...ver-names.html

===

Scenario 2.
Choosing a child name or delegated sub domain name of the public zone. This is one recommendation. Name such as 'ad.domain.com', or 'corp.microsoft.com'. The AD DNS domain name namespace starts at corp.domain.com and has nothing to do with the domain.com zone.

Pros:
1. Mimimal administrative overhead.

2. Forwarding will work.

3. The NetBIOS name will be 'AD' or 'CORP', depending on what you chose and what the users will see in the three-line legacy security logon box.

4. Like Scenario 1, this method also isolates the internal company network but note this at the same time is also a disadvantage (see below).

5. Better than Scenario 1, internal company (Active Directory) clients can resolve external resources in the public DNS zone easily, once proper DNS name resolution mechanism such as forwarding, secondary zones, or delegation zones are set up.

6. Better than Scenario 1, DNS records for the public DNS zone do not need to be manually duplicated into the internal AD/DNS zone.

7. Better than Scenario 1, VPN clients accessing the internal company network from the Internet can easily navigate into the internal subdomain. It is very reliable as long as the VPN stays connected.


Cons:
1. Confusion on users if they decide on using their UPN.

2. While there is security in an isolated subdomain, there is potential for exposure to outside attack. The potential for exposure of internal company resources to the outside world, lies mainly in the fact that because when the public zone DNS servers receives a query for subdomain.externaldnsname.com, they will return the addresses of the internal DNS servers which will then provide answers to that query.

3. Longer DNS namespace. This may not look appealing (or "pretty") to the end-users.

4. Security. We are assuming that we can only access the internal servers thru a VPN and assuming they are in a private subnet, they won;'t be accessible. Also assuming to secure the VPN with an L2TP/IPSec solution and not just a quick PPTP connection. If this is all so, we can assume it is secure and not accessible from the outside world.

The scenario is the recommendation from the Windows Server 2003 Deployment Guide. It states to the external registered name and take a sub zone from that as the DNS name for the Forest Root Domain:
http://www.microsoft.com/resources/d...us/default.asp

===

Scenario 3. Choosing a different TLD: Choosing a different TLD, such as domain.local, domain.corp, domain.net, etc. This option is usually best for either beginners or the expert, because it's the easiest to implement primarily because it prevents name space conflicts from the very beginning with the public domain and requires no further action on your part with respect to that.

But this option does makes VPN resolution difficult (like option 1) and Exchange headers when examined closely will show the company internal AD name which looks unprofessional. You can use any extension you want here such as .ad, .int, .lan, etc...

Pros:
1. Easy to implement with minimal administrative overhead. Requires minimal action on administrators.

2. Prevents name space conflicts with external domain name.

3. Forwarding works.


Cons:
1. Domain name may look unprofessional.

2. VPN resolution difficult (like option 1). That can be a sticky issue and depending on the VPN client will dictate whether it will work or not. I know one of the other MVPs (Dean Wells) created a little script to populate a user's laptop or home PC's hosts file with the necessary resources and would remove them once the VPN is dissolved.

3. Exchange HELO name must be altered (to accomodate anti-spam, SPF, and RBL software), via MetaEdit, Metabase Explorer and thru the SMTP VS properties.

===

For a broad overview of this entire topic, see below.

DNS Namespace Planning
http://support.microsoft.com/default...b;en-us;254680

Assigning the Forest Root Domain Name:
http://www.microsoft.com/resources/d..._logi_kqxm.asp
==================================================================================================== ==
==================================================================================================== ==

--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSA Messaging, MCT
Microsoft Certified Trainer
aceman@mvps.RemoveThisPart.org

For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

"Efficiency is doing things right; effectiveness is doing the right things." - Peter F. Drucker
http://twitter.com/acefekay