Thank you for the well thought out explanation. My existing network Is a .local and is a small company 10 on site users and 40 remote exchange only users. and I plan to use some of the exchange 2003 features rpc over http the new push technology on sp2 for mobile devices and file sharing with webdav. I will be setting up a certificate server and have concerns about the unknown issues that may arise with users on the outside resolving to exchange with a public domain name via public dns and users on the inside resolving to a .local domain via private dns. Usually when I set this up I used your option 1 and it has worked fine, by me updating the public DNS with the proper mx and and then updating the internal dns with any external www addresses. My first thought is to run dcpromo and rename the .local to a .com Thanks Jeff _____ From: ChongJa@xxxxxxxxxxxxxxxx [mailto:ChongJa@xxxxxxxxxxxxxxxx] Sent: Saturday, January 14, 2006 11:09 AM To: [ExchangeList] Subject: [exchangelist] RE: Domain.local versus domain.com Here are your 3 options for DNS namespace planning, advantages and disadvantages of each. Option #1: Same internal and external DNS domain name. The administrator(s) maintain 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 (currently 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) 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). 2) 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), 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://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> http://homepages.tesco.net./~J.deBoynePollard/FGA/dns-split-horizon-c... ---------------------------------------------------------------------------- ------------ Option #2: Delegated subdomain. This is subdomain of the public DNS zone. For example, externaldnsdomain.com and subdomain.externaldnsname.com. Advantages: 1) Like Scenario 1, this method also isolates the internal company network but note this at the same time is also a disadvantage (see below). 2) 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. 3) Better than Scenario 1, DNS records for the public DNS zone do not need to be manually duplicated into the internal AD/DNS zone. 4) 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. Disadvantages: 1) While there is security in an isolated subdomain, there is a limited 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. Hackers could use this information to gather information about your network. To the extent however that internal networks 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. 2) Longer DNS namespace. This may not look appealing (or "pretty") to the end-users. 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/deplo yguide/en-us/default.asp> http://www.microsoft.com/resources/documentation/windowsserv/2003/all... ---------------------------------------------------------------------------- ------------ 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. This option is usually best for beginners b/c 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... Disadvantages: 1) 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 IE and simply types "server1" in the address bar (happens often), then which "server1" is really the correct answer? The answer may notbe what the user was looking for, and it will base off of the configuration settings for DNS under TCP/IP properties, the machine's domain membership, whether or not it is using a proxy server, and finally the DNS suffix search order. 2) Another disadvantage is the inability of many administrators to escape a very common pitfall when internal and external domain names are the same. If one is not careful, setting the internal AD domain to the same name as the external (public) DNS domain name will typically have such consequnces of internal user not being able to resolve the public website and slow logins to the internal AD *if* the internal clients configure a public DNS server in their TCP/IP properties. For a broad overview of this entire topic, see below. DNS Namespace Planning <http://support.microsoft.com/default.aspx?scid=kb;en-us;254680> http://support.microsoft.com/default.aspx?scid=kb;en-us;254680 _____ From: Jeff Bushberg [mailto:jeff@xxxxxxxxx] Sent: Sat 1/14/2006 2:55 AM To: [ExchangeList] Subject: [exchangelist] Domain.local versus domain.com http://www.MSExchange.org/ I am setting up a 2003 Exchange server on a domain that has a .local I was wondering if I will run into any problems. In the past I have set up with the correct dns "domain".com name. Also I plan to implement rpc over http will a .local create any issues. There is a existing win2k server with exchange 2000. I plan to keep the existing win2k dns server but remove the 2000 exchange and add a new 2003 server with exchange 2003 Thanks Jeff ------------------------------------------------------ List Archives: http://www.webelists.com/cgi/lyris.pl?enter=exchangelist Exchange Newsletters: http://www.msexchange.org/pages/newsletter.asp ------------------------------------------------------ Visit TechGenix.com for more information about our other sites: http://www.techgenix.com ------------------------------------------------------ You are currently subscribed to this MSExchange.org Discussion List as: chongja@xxxxxxxxxxxxxxxx To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=exchangelist Report abuse to info@xxxxxxxxxxxxxx