Re: How to use sub-domain
- From: "Todd J Heron" <todd_heron(delete)@hotmail.com>
- Date: Sun, 23 Oct 2005 01:07:24 -0400
AD/DNS Namespace Planning - The Standard Three Options with
Advantages/Disadvantages
Can't decide on domain.com or domain.local for your AD domain? There are
three differing views to this classic question and while they ultimately
depend upon company preference, much of the direction will be driven by
administrator experience. The three basic options outlined below are the
most commonly-given answers to the question, and some companies use a
combination of these scenarios. When explaining these to a relative
beginner, many advanced AD/DNS administrators routinely their reasoning from
their responses, but the explanations that follow contain detailed pros and
cons of each.
Option #1: Same internal and external DNS domain name.
The administrator maintains entirely separate DNS implementations (no zone
transfers, etc.), where the internal AD/DNS domain has manually configured
static records (web, mail, etc..) to get to frequently used IP hosts in the
public DNS zone of the same name (most likely provided by your ISP, unless
you are a very large company). The private AD/DNS zone is protected inside
the network perimeter and is used to support the internal AD. This is known
as "shadow DNS", "split DNS", "split-brain" DNS, or "split-horizon" DNS.
Advantages:
1. 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.
2. 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".
Disadvantages:
1. Name resolution trap: If one is not careful, setting the internal AD
domain to the same name as the external (public) DNS domain name will have
the following consequences for internal AD users if their client machine's
DNS settings are pointing to the external namespace DNS servers: Inability
to access the public website, slow network logons, no group policy updates.
2. Administrative overhead: 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 also be changed manually in the internal AD/DNS
zone if internal users will be accessing these hosts from inside the network
perimeter (a common circumstance).
3. VPN resolution: 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), or they must use special VPN
software (usually expensive).
For further reading on this scenario:
http://www.isaserver.org/tutorials/You_Need_to_Create_a_Split_DNS.html
http://homepages.tesco.net./~J.deBoynePollard/FGA/dns-split-horizon-common-server-names.html
---------------------------------------------------------------------------------------
Option #2: Delegated subdomain.
This is subdomain of the public DNS zone. For example,
externaldnsdomain.com and subdomain.externaldnsname.com.
Advantages:
1. Security: Like Option #1, this method also isolates the internal company
network (please note that this is also a disadvantage due to a longer DNS
namespace (see note under 'Disadvantages' below).
2. Administration: DNS records for the public DNS zone do not need to be
manually duplicated into the internal AD/DNS zone.
3. DNS resolution: Internal company (Active Directory) clients can resolve
external resources in the public DNS zone easily, once proper DNS name
resolution mechanisms such as forwarding, secondary zones, or delegation
zones are set up.
4. VPN resolution: 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.
Disadvantages:
1. Longer DNS namespace: This may not look appealing (or "pretty") to the
end-users.
2. Security: While there is security in an isolated subdomain, there is a
potential for exposure to outside attack, albeit extremely limited. 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. Hackers could use this information to gather information about
your network. To the extent, however, that internal networks are only
accessible to the outside world via VPN (and/or exists within a non-Internet
routable IP range) then this scenario is not a security disadvantage.
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/documentation/windowsserv/2003/all/deployguide/en-us/default.asp
---------------------------------------------------------------------------------------
Option #3: Different internal and external DNS domain names.
For example, dnsname.com and dnsname.local. The administrator(s) maintain
external records on the external DNS servers, and internal records on the
internal DNS servers. For the internal domain, you can use any extension
you want, such as .ad, int, .lan, etc...
This option is usually best for beginners 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. But this
option does make VPN resolution difficult (like Option #1) and, Exchange
message headers will show the company internal AD name which looks
unprofessional.
Advantages:
1. Easy setup. This method is the easiest to setup. DNS namespace
collisions are avoided from the beginning. The internal AD domain will
never conflict with any public domain.
Disadvantages:
1. Non-FQDN resolution. The chief disadvantage to this approach comes in
when users have to access resources and don't use FQDNs. A Windows 2000/XP
box where a user types "ping server1", for example, or types "server1" in
IE, could potentially get unexpected results. For example, there is a
machine named server1.internalname.com and there is also a server named
server1.externalname.com. If a user opens Internet Explorer and simply types
"server1" in the address bar (as often happens), then which "server1" is
really the correct answer? The answer may not be what the user was looking
for, and it will be based off of the configuration settings of the
following: DNS settings under the client's TCP/IP properties, the DNS
suffix search order, WINS forwarding, domain membership, and whether or not
it is using a proxy server.
2. VPN resolution. VPN clients may encounter problems when trying to access
internal resources. Newer VPN clients, such as those offered by Cisco and
Nortel, once connected, provide name resolution by passing internal name
servers (WINS, DNS) to the TCP/IP stack. If the VPN client cannot do this,
add the host names of important internal hosts to the internal (WINS, DNS)
name servers so that the VPN client will be able to resolve these names.
Otherwise, you will need to use a Hosts (and Lmhosts if necessary) file,
which is both manually intensive and will need to be updated whenever one of
the listed IP host changes it's name or changes it's IP address, which
happens often in an enterprise environment.
For a broad overview of this entire topic, visit:
DNS Namespace Planning
http://support.microsoft.com/default.aspx?scid=kb;en-us;254680
Assigning the Forest Root Domain Name
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/DepKit/4bb9f469-df87-4830-96a8-b28ec71bafa9.mspx
Conclusion:
All three approaches will have to take both security and 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 single approach
should be considered the best solution under all circumstances. For any
host name that you wish to be able to access from both your internal network
and the Internet, you need Option #1, although it is the most
administratively intensive over time. If you do not select this option and
go with Option #2 or #3 only, then 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, at
home or on the road.
--
Todd J Heron, MCSE
Windows Server 2003/2000/NT; CCA
----------------------------------------------------------------------------
This posting is provided "as is" with no warranties and confers no rights
<jonathanm@xxxxxxxxxxx> wrote in message
news:1129862550.011564.32240@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I saw this post on this group:
In my opinion best choice would be to take a sub-zone of your
registered
domain name (e.g. you have registered domain name company.us. For
internal
use make a sub-zone e.g. named ad.company.us or lan.company.us or
loca.company.us ...).
Try to avoid name company.local or similar....
While it goes against common convention for Server 03, it does appeal
to me for various reasons including the support of Macs on my network.
Can someone explain how this works? Do I need to contact my ISP or
domain registrar? Details please!
Regards,
MDJ
.
- References:
- How to use sub-domain
- From: jonathanm
- How to use sub-domain
- Prev by Date: Re: Office 2000 stopped working after 4 days
- Next by Date: Re: Windows server account always gets locked - repost
- Previous by thread: How to use sub-domain
- Next by thread: RE: VPN DNS setup for default DNS server
- Index(es):
Relevant Pages
|
