How do I resolve my external website when my internal name is the same as my external name (split zone)?
We are hosting our webserver internally, on our LAN, and internet users can access the website without problems, but when we are inside the office, we can't access our domain name. This also applies to Exchange OWA.
By Ace Fekay, MCT
There can be multiple scenarios. Choose your scenario.
Your internal domain name and external domain name the same, and the webserver is hosted externally.
This type of same name scenario is called a split zone.
To handle a split-zone,
There are two ways to get to your website:
- By http://www.yourdomain.com/, using 'www' in front of your domain name.
- By http://yourdomain.com/, without the 'www'in front of the name.
1. The simplest way to allow your internal users to get to your external website is to simply create a "A" www record under your current internal AD zone name in DNS (DO NOT create an Alias or CNAME record), and provide the IP address of the external web server.
To create the 'www' record:
Open DNS console
Right-click your zone name, such as yourdomain.com, choose New Host Record
Type in www
Type in the IP address of the external website
2. However, if your web hosting provider uses more than one web servers, such as in a server farm, or they have multiple IP addresses for the website, and facing the possibility hey may change it without warning, you would have to do something different to account for this. Therefore, instead of creating an "A" 'www' record, I would suggest to create a delegation for 'www' to the public name servers that are authorative for your zone. What a delegation does, instead of providing a direct IP, DNS will query the SOA of your public domain name to get the current IP address of your website. To create a delegation, you will need to find the SOA name of your public zone. The SOA, or Start of Authority, are the public name servers on record that you want your delegation to query for your 'www' record.
Therefore, you would need to query an outside DNS server for your SOA record (your external DNS hostname servers hosting your public domain name)
How do you find the SOA for your public domain name? Use nslookup.
In a command prompt, type in nslookup, hit enter.
Then type in the following:
> set q=soa
> server 188.8.131.52
Once you've found who the SOA names and IP are, you can create the delegation. To create the delegation, simply right-click your zone name, choose new delegation, type in www, and provide the SOA of your public domain.
As for resolving the domain name with http://domain.com/ (without the www in front of it), is a little more complex. Normally if you are not using Active Directory internally, you would simply create a new Host record (as in step#1), but without typing anything in for the hostname, and simply type in the IP address. This is called a blank domain name, which allows the name to resolve without the 'www' in front of it. However, if you are using Active Directory, this 'blank' domain name is actually used by the domain controllers in the domain. It's a unique record that each domain controller registers into DNS with an IP address, without a hostname, which appears under your internal zone name as:
(same as parent) A x.x.x.x
This record that the DCs register, is actually called the "LdapIpAddress." Each DC registers one for itself. AD uses these records for a number of things, such as DC to DC replication, Sysvol replication, GPOs and DFS. Don't mess with it please or expect problems. The DCs will re-register this record anyway if you delete it and thwart your attempt. If you create a blank record for your website, it will get cause problems with AD.
To get around that, you can use a workaround. The workaround is, on EACH DC, install IIS. Then open Internet Information Services console. In the default website properties, Directory tab, select redirect, and redirect it to http://www.domain.com/. This way when any one of your users type in http//domain.com, it will resolve to the www record you've created in Step#1 or #2 above. But this procedure must be performed on each DC.
Your public domain name is different, and you are hosting your webserver internally.
In this scenario, internet users access your domain name by connecting to the WAN (outside) IP address of your router.
To make this scenario work, with a different domain name than your internal domain name, you would need to create the external domain name as a zone on your DNS server.
Create a new zone using your external domain name.
Open DNS console.
Click on Forward Lookup Zones.
Right-click, choose new Zone, type in the name of the external domain name.
Once created, right-click the zone you just created, choose New Host Record.
Type in 'www' (without the quotes), and provide the internal Private IP address of your internal webserver.
If you want to access the site with http://domain.com/ (without the www), you would need to create a 'blank' host record.
Right-click the zone name you just created, choose New Host Record.
Leave the name field blank, and provide the internal Private IP address of your internal webserver.
If you have a different internal domain name and external domain name, and the website is hosted externally:
There's nothing to do. Internet resolution will handle everything.
Don't forget, ALWAYS and ONLY use the internal DNS servers in your AD environment for all machins (DCs, member servers and workstations, including your VPN clients),or this won't work. Never use your ISP's DNS servers anyway, or your router's IP address as a DNS address in any internal machine's IP properties. Otherwise, expect AD problems as well.
Don't forget to configure a forwarder for more efficient internet name resolution. I've always used this as a best practice. It offloads internet name resolution to your ISP's DNS addresses so your server doesn't have to use the Root Hints to resolve external names.
Ace Fekay, MCT
By Ace Fekay, MCT, MCTS Exchange, MCSE, MCSA
First published: January, 2003, updated July, 2006
A Multihomed DC is a domain controller with more than one NIC and/or IP address, and/or RRAS installed on it (for VPN, routing, dialup, etc), or with a PPPoE adapter from your ISP's ADSL line.
Multihomed DCs wiill cause numerous issues. The only exception to the rule are SBS servers, but that is a completely different topic which I will not address in this blogpost.
It's highly recommended to single home all DCs and use a non-DC for the multihoming purposes. If it is the internet gateway, it is recommended to purchase an inexpensive, or cable/DSL router, or even better, a Cisco or similar firewall to perform the task, which if it is compromised by an internet attacker remotely, can't further compromise the rest of the internal network.
Also if attempting to use ICS on a DC, this further complicates matters with DC functionality, and cannot be fixed with the following steps outlined in this article.
To explain why will require a little background on AD and DNS:
First, just to get this out of the way, if you have your ISP's DNS addresses.some other external DNS address, or using your router as a DNS address in your IP configuration (DCs or clients), they must be removed. If these external DNS addresses are used, it's guaranteed to cause additional problems. If not sure what I mean that you can't use a DNS server other than your internal DNS servers, please read the following article for more information:
Active Directory's Reliance on DNS, and using an ISP's DNS address:
If you have a PPPoE adapter installed (such as the WinPoet software from Verizon for ADSL lines), it will cause the same problems, for after all, they are additional interfaces as well.
I usually see errors (GPOs not working, can't find the domain, RPC issues, replication taking a nose dive, dcdiag and replmon errors, etc), when the ISP's or some other non-internal DNS servers are listed on a client, DCs and/or member servers, or with multihomed DCs. If you have an ISP's (or some other outside DNS server or even using your router as a DNS server) DNS addresses in your IP configuration (all DCs, member servers and clients), they need to be REMOVED and ONLY use the internal DNS server(s). Otherwise, expect problems. Surprisingly I've heard of some customers say, "I've been using it for years this way and have never had problems." Consider yourself lucky.
Basically, AD requires DNS. DNS stores AD's resource and service locations in the form of SRV records, hence how everything that is part of the domain will find resources in the domain. If the ISP's DNS is configured in the any of the internal AD member machines' IP properties, (including all client machines and DCs), the machines will be asking the ISP's DNS 'where is the domain controller for my domain?", whenever it needs to perform a function, (such as a logon request, replication request, querying and applying GPOs, etc). Unfortunately, the ISP's DNS does not have that info and they reply with an "I dunno know", and things just fail. Unfortunately, the ISP's (or your router as a DNS server) DNS doesn't have information or records about your internal private AD domain, and they shouldn't have that sort of information.
Also, AD registers certain records in DNS in the form of SRV records that signify AD's resource and service locations. When there are multiple NICs, each NIC registers. IF a client, or another DC queries DNS for this DC, it may get the wrong record. One factor controlling this is Round Robin. If a DC or client on another subnet that the DC is not configured on queries for it, Round Robin will kick in offering one or the other. If the wrong one gets offered, it may not have a route to it. On the other hand, Subnetmask Priortization will ensure a querying client will get an IP that corresponds to the subnet it's on, which will work.
To insure everything works, stick with one NIC.
Since this DC is multi-homed, it requires additional configuration to prevent the public interface addresses from being registered in DNS. This creates a problem for internal clients locating AD to authenticate and find other services and resources such as the Global Catalog, file sharing and the SYSVOL DFS share and can cause GPO errors with Userenv 1000 events to be logged, authenticating to shares and printers, logging on takes forever, among numerous other issues.
But if you like, there are some registry changes to eliminate the registration of the external NIC or simply use the internal networking routing to allow access.
Another problem is the DC now becomes part of two Sites. This is another issue that can be problematic.
But believe me, it's much easier to just get a separate NAT device or multihome a non-DC then having to alter the DC. If the both NICs are internal, I would suggest to pick a subnet, team the NICs and allow your internal routers handle the traffic between subnets - Good luck!
The following are the manual steps to follow:
- Insure that all the NICS only point to your internal DNS server(s) only and none others, such as your ISP’s DNS servers’ IP addresses.
- In Network & Dialup properties, Advanced Menu item, Advanced Settings, move the internal NIC (the network that AD is on) to the top of the binding order (top of the list).
- Disable the ability for the outer NIC to register. The procedure, as mentioned, involves identifying the outer NIC’s GUID number.
This link will show you how: 246804 - How to Enable-Disable Windows 2000 Dynamic DNS Registrations (per NIC too): http://support.microsoft.com/?id=246804
- Disable NetBIOS on the outside NIC. That is performed by choosing to disable NetBIOS in IP Properties, Advanced, and you will find that under the “WINS” tab.
You may want to look at step #3 in the article to show you how to disable NetBIOS on the RRAS interfaces if this is a RRAS server.
296379 - How to Disable NetBIOS on an Incoming Remote Access Interface [Registry Entry]:
A standard Windows service, called the “Browser service”, provides the list of machines, workgroup and domain names that you see in “My Network Places” (or the legacy term “Network Neighborhood”). The Browser service relies on the NetBIOS service. One major requirement of NetBIOS service is a machine can only have one name to one IP address. It’s sort of a fingerprint. You can’t have two brothers named Darrell. A multihomed machine will cause duplicate name errors on itself because Windows sees itself with the same name in the Browse List (My Network Places), but with different IPs. You can only have one, hence the error generated.
- Disable the “File and Print Service” and disable the “MS Client Service” on the outer NIC. That is done in NIC properties by unchecking the respective service under the general properties page. If you need these services on the outside NIC (which is unlikely), which allow other machines to connect to your machine for accessing resource on your machine (shared folders, printers, etc.), then you will probably need to keep them enabled.
- Uncheck “Register this connection” under IP properties, Advanced settings, “DNS” tab.
- Delete the outer NIC IP address, disable Netlogon registration, and manually create the required records
- In DNS under the zone name, (your DNS domain name), delete the outer NIC’s IP references for the “LdapIpAddress”. If this is a GC, you will need to delete the GC IP record as well (the “GcIpAddress”). To do that, in the DNS console, under the zone name, you will see the _msdcs folder.
Under the _msdcs folder, you will see the _gc folder. To the right, you will see the IP address referencing the GC address. That is called the GcIpAddress. Delete the IP addresses referencing the outer NIC.
- To stop these two records from registering that information, use the steps provided in the links below:
Private Network Interfaces on a Domain Controller Are Registered in DNS
- The one section of the article that disables these records is done with this registry entry:
(Create this Multi-String Value under it):
Registry value: DnsAvoidRegisterRecords
Data type: REG_MULTI_SZ
- The following link provides more information on these and other Netlogon Service records:
Restrict the DNS SRV resource records updated by the Netlogon service [including GC]:
- Then you will need to manually create these two records in DNS with the IP addresses that you need for the DC. To create the LdapIpAddress, create a new host under the domain, but leave the “hostname” field blank, and provide the internal IP of the DC, which results in a record that looks like:
(same as parent) A 192.168.5.200 (192.168.5.200 is used for illustrative purposes)
- You need to also manually create the GcIpAddress as well, if this is a GC. That would be under the _msdcs._gc SRV record under the zone. It is created in the same fashion as the LdapIpAddress mentioned above.
- In the DNS console, right click the server name, choose properties, then under the “Interfaces” tab, force it only to listen to the internal NIC’s IP address, and not the IP address of the outer NIC.
- Since this is also a DNS server, the IPs from all NICs will register, even if you tell it not to in the NIC properties. See this to show you how to stop that behavior (this procedure is for Windows 2000, but will also work for Windows 2003):
275554 - The Host's A Record Is Registered in DNS After You Choose Not to Register the Connection's Address:
- If you haven't done so, configure a forwarder. You can use 184.108.40.206 if not sure which DNS to forward to until you've got the DNS address of your ISP.
How to set a forwarder? Good question. Depending on your operating system,choose one of the following articles, depending on your operating system.
300202 - HOW TO: Configure DNS for Internet Access in Windows 2000
323380 - HOW TO: Configure DNS for Internet Access in Windows Server 2003 (How to configure a forwarder):
Active Directory communication fails on multihomed domain controllers
Some additional reading
More links to read up and understand what is going on:
To set it up:
Go to the respective carrier's site link below, setup a new email address (keep your current carrier's email), add an account, provide the Exchange email address, and hit next. Let it time out when it says it can't find it, then tell it you'll set it up manually, then set it up manually by indicating it's a corporate account using OWA, hit next, provide the OWA address, user alias, password, domain name, etc.
Or you have the option to use the free version of Blackberry Enterprise Server. The last I checked, the first CAL is free. You can CALS for $99, upto 30 maximum units. Call Blackberry sales for more info.
Want to get up and running quickly with BlackBerry Professional Software?
BlackBerry® Professional Software Express