Supporting ISA Firewall Networks Protecting Illegal Top-level Domains: You Need a Split DNS!

 Supporting ISA Firewall Networks Protecting Illegal Top-level Domains:
You Need a Split DNS!

by Thomas W Shinder MD, MVP

Whatever the reason, the fact is that a split DNS can make your life, and even more, your user’s lives, much simpler. When you have a split DNS infrastructure in place, you can achieve the following:

In this article I’ll take about how to put together a split DNS to support organizations who have domains using illegal top level domains. An illegal top level domain is one that is not valid on the Internet and can’t be registered with an Internet Domain Registrar.

Examples of illegal top level domains include: .local, .home, .lan, .private, .blah and .whateveryoulike. A list of legal top level domains at the time this article was written can be found at http://data.iana.org/TLD/tlds-alpha-by-domain.txt

You can also use the principles discussed in this article to provide a split DNS infrastructure even if your internal network domain isn’t using an illegal TLD. For example, you might want to host your publicly accessible resources in the remotecorp.com domain while keeping the name internalcorp.net domain for internal use only. The same principles that apply for those using illegal TLDs can be used for these organizations.

A split DNS makes resources you want accessible to both internal and external users location transparent or independent. What I mean by location transparent is that users never need to use different names, or reconfigure client applications to use different names, based on where the user is located at any point in time.

For example, if the user is located on the corporate network and needs to access a SharePoint Portal Server using the sps.domain.com, the user should also be able to use sps.domain.com when connecting to the SharePoint Portal Server site from an external location somewhere on the Internet.

Another example is for Outlook Web Access (OWA). If the user is located on the corporate network and uses the name owa.domain.com to access the OWA Web site, then the user should be able to access the OWA Web site from an external network location using the same name, owa.domain.com.

The split DNS infrastructure works because there are two or more DNS servers available that host zones authoritative for the same domain name. One or more of the DNS servers is responsible for name resolution for hosts located on the corporate network, and one or more DNS servers is responsible for name resolution for hosts located on the Internet.

The DNS server responsible for name resolution on the corporate network contains DNS resource records that map server names to their internal network IP addresses, which are typically the actual addresses used by the servers on the corporate network. The DNS server responsible for name resolution for external, Internet-located users resolves names to a public IP address allowing inbound access to the corporate resource.

For example, suppose you your Active Directory DNS name is domain.local. This is a common situation for Small Business Server customers. Since the .local top level domain is illegal or invalid, we can’t register that domain with a public Domain Registrar. However, we could register another domain, such as mydomain.net and use that as part of our split DNS.

You create a new DNS zone on your internal network DNS for the mydomain.net domain and you then register with a public Domain Registrar the mydomain.net domain. On both your internal and external DNS servers you create resource records for only those resources that will be accessed by both internal and external users.

Some resources that might be accessible to both internal and external network users include:

Suppose you have Microsoft Exchange and Microsoft SharePoint Portal Server on the corporate network. On the internal DNS server you create two Host (A) records in the mydomain.net DNS zone:

owa.mydomain.net (maps to private IP address on the corporate network)
sps.mydomain.net (maps to the private IP address on the corporate network)

On the public DNS server for the mydomain.net domain, you also create two Host (A) records:

owa.mydomain.net (maps to the public IP address used to access the private resource)
sps.mydomain.net (maps to the public IP address used to access the private resource)

The corporate network uses DHCP to assign IP addressing information to network hosts. The DHCP server assigns the IP address of the internal DNS server to hosts on the corporate network. The DNS servers assigned to the corporate network hosts are authoritative for both the domain.local and mydomain.net domains. When users on the corporate network connect to owa.mydomain.net they directly access the OWA site on the corporate network, bypassing the firewall or any other device used to provide public access to the OWA site.

When users move from the corporate network to an external network, they connect to the external network LAN or ISP and receive IP addressing information via DHCP. The external host is assigned a DNS server that can resolve Internet host names. When the external network user connects to owa.mydomain.net, the DNS server provides the external network host the public address you configured for that resource in the external DNS server authoritative for the mydomain.net domain.

The figure below shows the DNS and connect actions for both internal and external hosts utilizing the split DNS infrastructure.

Key Points and Misconceptions Regarding the Split DNS Infrastructure

Before getting into some of the details of implementing a split DNS infrastructure, there are a few key issues and misconceptions about the split DNS infrastructure that should be addressed. There are several facts that you should know that will dispel any misconceptions you have regardless split DNS infrastructures:

This is the main point of this article. You can continue to use your current Active Directory domain name and still use the split DNS infrastructure to support connections to resources that are accessed by both internal and external network hosts. Intradomain communications will continue as they always have among domain controllers and domain member servers and clients. The addition of the new zone to support the split DNS infrastructure will have no effect at all on the normal Active Directory intradomain communications.

This is true whether or not you’re using an illegal top level domain. You might be using a legal top level domain for which you are already using a split DNS infrastructure, but want to add a second domain that is dedicated to support only resources accessed by both internal and external network hosts. There’s no problem with doing that, and adding the domain will have no effect on your current intradomain communications, or your current split DNS infrastructure.

FACT: The Split DNS Does Not Represent a Security Risk to you Internal Network

There is a misconception that a split DNS infrastructure will somehow lead to a security compromise of the corporate network. I’ve never understood where this misconception stems from, but its most likely that these folks don’t really understand how the split DNS works, and they may be co-locating split DNS records on the same DNS server that hosts their private domain records.

The fact is that a properly implemented split DNS never exposes your corporate network to a potential security risk which might arise by malicious users obtaining comprehensive information about your corporate network naming infrastructure. Remember, there are two groups of DNS servers participating in the split DNS: the public DNS servers and the private DNS servers. External hosts never contact the private DNS server and internal hosts never contact the public DNS server.

I suspect that this misconception might be related to incorrect implementation of the split DNS infrastructure, in the context of using the same domain name for the Active Directory network and for both the publicly and privately accessible resources. I prefer to use the same name for both the internal network domain and enable external users to access internal resources using the same domain name. However, you must implement the configuration correctly or else you might expose too much information to Internet users.

To completely dispel the myth of the security risks related to a split DNS infrastructure, let’s look at an example of an incorrectly configured split DNS (which isn’t a split DNS at all).

Suppose your internal network Active Directory domain name is split.com. You want to implement a split DNS infrastructure. What you could do, but should never do, is host resource records on the internal DNS server for both private and public resources.

For example, on the Active Directory DNS server, there are resource records for all the machines and devices on the internal network. In addition, you create resource records that all users (internal and external) can use, such as:

owa.split.com
sps.split.com
rpc.split.com

When you create these Host (A) records, you map them to the public address external users use to access the site (typically through an ISA firewall Web or Server Publishing Rule). You then publish your internal network DNS server that is hosting these records. This is easy to do, as you just configure the IP address that publishes your private DNS server to the Internet as your authoritative DNS server for that domain with your public Domain Registrar.

These are several problems with this configuration:

As you can see, in order to create a security issue with a split DNS infrastructure, you have to make multiple mistakes that violate the core principles of a split DNS infrastructure.

FACT: The Split DNS Infrastructure Does Not Make DNS Management More Complex

There is a misconception that a split DNS infrastructure makes DNS management more complex. While there is a little bit more work to do (a very little bit), there is no additional complexity associated with that work.

The reason why there isn’t additional complexity is that you do not mirror your internal network domain DNS servers to external DNS servers, and you don’t include all your internal network resources in your split DNS infrastructure.

The only records you need to include in your split DNS are those for servers that are accessed by both internal and external network clients. This will include mail servers, SharePoint servers, publicly accessible Web servers, and other server resources that both internal and external users need access.

How much work you want to do is up to you. You can create as many Host (A) records you like. For example, if you have a front-end Exchange Server, you can create these host records:

All of which map to the same IP address on the private DNS server (which maps to the private address used by the front-end Exchange Sever) and the same address on the public DNS server (which maps to the public address used to access these resources on your private network). Or you can create a single resource record:

The key is to create resource records on both the internal and external DNS servers that include the same names but that map to different IP addresses. Since server IP addresses on the internal network rarely change, and public IP addresses assigned by your ISP rarely change, making changes to your split DNS infrastructure should be a relatively rare event.

FACT: The External DNS server in the Split DNS Infrastructure Never Participates in a Master/Slave Relationship (Zone Transfer) with the Internal DNS Server

I think this is one of the primary misconceptions regarding the split DNS infrastructure that leads to concerns over complexity and security. I’ve read in many mailing lists, newsgroups and Web boards that admins think they need to perform zone transfers between the internal and external DNS servers responsible for the split DNS infrastructure. This is patently false and violates the core tenets of the split DNS.

There is no reason to ever perform a zone transfer between the internal DNS server and external DNS server participating in the split DNS infrastructure. The reason for this is:

Because there is no relationship between the internal and external DNS zone except for the domain and host names, changes in one zone have no effect on the other. It is a rare event that you need to change a Host (A) record on both the internal or external DNS server. This would only happen in situation like when the company is renumbering its internal network and changing ISPs).

To see how we can implement this solution in an organization using an ISA firewall to publish internal resources to external users, we will go through an example of how a company with an illegal TLD can use a split DNS infrastructure to support transparency for users who access corporate resources from both the internal and external networks.

The example company is using the Active Directory domain name ISASERVER.LOCAL as its fully qualified domain name. Since the .local TLD is illegal, this company cannot use it when connecting to corporate resources from external locations. The company has no interest in changing their internal network domain name. What they would like to do is implement a split DNS by using the domain name isaexternal.com, and be able to access resources on both the internal and external networks using the isaexternal.com domain name.

The company would like to enable secure remote access to the following Exchange Server 2003 resources:

The figure below shows the salient details of the company’s network for scenario 1, where the company hosts its own public DNS server resources. On the Default Internal Network behind the ISA firewall, there is a front-end and back-end Exchange Server and a Windows Server 2003 Active Directory domain controller. The domain controller hosts an Active Directory integrated DNS server which is authoritative for both the internal network domain, ISASERVER.LOCAL and the internal side of the split DNS isaexternal.com. External users will access resources on the back-end Exchange Server by assessing those resources by connecting to publicly available resources at isaexternal.com. Note that the front-end and back-end Exchange Server are members of the ISASERVER.LOCAl domain and recipient policies are configured so that users can send and receive from and to the isaexternal.com domain.

On a private address DMZ segment behind the ISA firewall are two DNS servers acting as the primary and secondary authoritative DNS servers for the public isaexternal.com domain. The DNS servers are available to Internet users via two Server Publishing Rules. Each public IP address used on the external interface of the ISA firewall for the DNS Server Publishing Rules is registered with the public Domain Registrar as an authoritative DNS server address for the isaexternal.com domain.

The next figure shows the setup for scenario 2, where the company outsources hosting of its public DNS resources with either an ISP, DNS hoster, or Dynamic DNS provider. In this scenario, the company decides to host the public DNS zones at an off-site location. The off-site location can by the company’s ISP’s DNS servers, a dedicated DNS hoster (like www.eservicesforyou.com), or a Dynamic DNS service provider (www.tzo.com is one of the very best).

The Dynamic DNS (DDNS) option is useful for companies that don’t have a dedicated IP address bound to the external interface of the ISA firewall. However, DDNS providers like TZO www.tzo.com also provide dedicated DNS hosting services for those companies using dedicated IP public addresses.

You can use the following procedures to get the solution working:

The first step is to create the internal side of the split DNS infrastructure on the internal network DNS server. We will place the internal zone of the split DNS domain on the Active Directory integrated DNS server on the internal network Active Directory domain controller. The name of your split DNS zone is isaexternal.com.

Perform the following steps to create the DNS zone:

1. Click Start, point to Administrative Tools and click DNS.
2. In the DNS console, expand the server name and then expand the Forward Lookup Zones node in the left pane of the console. Click on the Forward Lookup Zones node and then right click it. Click New Zone.
3. Click Next on the Welcome to the New Zone Wizard page.
4. On the Zone Type page, select the Primary zone option and click Next.

5. On the Zone Name page, enter the name of the split domain. In this example, the split domain is isaexternal.com. So we will enter isaexternal.com in the Zone name text box and click Next.

6. On the Zone File page, accept the default zone file name and click Next.
7. On the Dynamic Update page, accept the default setting, Do not allow dynamic updates and click Next.
8. Click Finish on the Completing the New Zone Wizard page.

After creating the internal side of the split DNS zone on the internal DNS server, you need to populate it with resource records. Remember, the only resource records you include in this zone are those for servers that are both privately and publicly accessed. Recall that we want to make the following Exchange Server services available to both internal and external network users:

The OWA, RPC over HTTP, Exchange ActiveSync and Outlook Mobile Access can all be hosted on the same Web site, bound to a single IP address on the front-end Exchange Server. However, since you can’t use the ISA firewall’s forms-based authentication using the same listener for OWA and the other Web services, we’ll need to use two IP addresses on the external interface of the ISA firewall: one to support the OWA site, and one to support the RPC/HTTP, EAS and OMA sites.

The SMTP, POP3S and IMAP4S sites can all be bound to the same IP address on the front-end Exchange Server. We can also use one IP address on the external interface of the ISA firewall to publish each of these services, since they all listen on a different socket. We can use one of the IP addresses used by a Web listener, since the Web listeners bind different sockets than any of these services.

To support publishing the Exchange Server services using the split DNS, we would create the following DNS Host (A) resource records on the internal network DNS server:

owa.isaexternal.com A 10.0.0.2
rpc.isaexternal.com A 10.0.0.2
eas.isaexternal.com A 10.0.0.2
oma.isaexternal.com A 10.0.0.2
pop.isaexternal.com A 10.0.0.2
imap.isaexternal.com A 10.0.0.2
smtp.isaexternal.com A 10.0.0.2

I prefer to create a DNS record for each service published. Since these records will rarely change, the few minutes you spend now will make things easier for you in the future if you decide to expand your operations.

In the following example we’ll create two of these Host (A) resource records:

1. Click Start, point to Administrative Tools and click DNS.
2. In the DNS console, expand the server name and then expand the Forward Lookup Zones node in the left pane of the console. Click on the isaexternal.com zone and then right click it. Click New Host (A).
3. In the New Host dialog box, enter owa in the Name (uses parent domain if blank) text box. Enter the IP address of the front-end Exchange Server in the IP address text box, and put a checkmark in the Create associated pointer (PTR) record checkbox. Click Add Host.

4. Click OK in the DNS dialog box informing you the record was created successfully.
5. In the New Host dialog box, enter rpc in the Name (uses parent domain if blank) text box. Enter the IP address of the front-end Exchange Server in the IP address text box, and put a checkmark in the Create associated pointer (PTR) record checkbox. Click Add Host.

6. Click OK in the DNS dialog box informing you the record was created successfully.
7. Click Done in the New Host dialog box.

The isaexternal.com zone would appear as seen in the figure below after adding these two resource records. You can continue to add the remaining resource records based on the scenario discussed above.

Remember, you only need to enter the resource records for servers and services that will be accessed by users on both the internal and external network, and you enter only the names that both the internal and external users will use to access those resources.

As this point you’re ready to register your domain with a public Domain Registrar. There are many to choose from and I won’t make any recommendations other than to say that I use Network Solutions because I figure they’ll be in business at least as long I will be. This isn’t a comment on their level of service, or a negative reflection of the level of service provided by other Domain Registrars.

After you register your domain, your Domain Registrar will have a Web page you can visit that will as for the IP addresses of at least two authoritative DNS servers for your domain. If you are hosting your own DNS servers, then you will enter the IP addresses on the external interface of the ISA firewall that will be used by the two Server Publishing Rules used to publish the two DNS servers in the public access DMZ segment.

If you are using your ISP or a dedicated DNS host service, your provider will likely register the domain for you, or provide you with the addresses of the DNS servers that will be authoritative for the public side of your split DNS infrastructure.

If you are using a Dynamic DNS (DDNS) provider, then all you need to do is register your domain with the DDNS provider (like TZO at www.tzo.com) and install the client software on any machine on the internal network that is using the ISA firewall as its default gateway. The client software will automatically detect the public IP address on the external interface of the ISA firewall assigned by your ISP’s DHCP server. Note that you will need to create Protocol Definitions and Access Rules to support the client software. The TZO site, and other DDNS provider sites, are very good about providing you good information about the protocols required by their clients.

The key to success in configuring the external side of the split DNS is to enter the same names as that you have on the internal side of the split DNS, but in the case of the external side of the DNS zone, you enter the public addresses used to access those services.

Once the public authoritative DNS servers for the public side of your split DNS infrastructure registered, you need to enter the appropriate resource records. In the scenario discussed in this article, we might create the following records:

owa.isaexternal.com A 2.2.2.1
rpc.isaexternal.com A 2.2.2.2
eas.isaexternal.com A 2.2.2.2
oma.isaexternal.com A 2.2.2.2
pop.isaexternal.com A 2.2.2.2
imap.isaexternal.com A 2.2.2.2
smtp.isaexternal.com A 2.2.2.2
ns1.isaexteranl.com A 2.2.2.1
ns2.isaexternal.com A 2.2.2.2

A couple of entries of note here. First, notice that the OWA entry uses a different IP address than other Web services. The reason for this is that we want to enable OWA forms-based authentication on the ISA firewall’s Web Publishing Rule for the OWA site, and we can use the same Web listener for OWA forms-based authentication and publishing other Exchange Web services (RPC/HTTP, OMA, EAS). So we need to associate those other services with a different IP address that we will use for a second Web listener.

Second, notice that there are two records for the DNS servers, ns1.isaexternal.com and ns2.isaexternal.com. These records are only required if you plan on hosting your own public DNS servers for your split DNS solution.

Create Two Server Publishing Rules Publishing Your Public DNS Servers (if you host your own DNS servers)

I you plan on hosting your own DNS servers, then you will need to create two Server Publishing Rules using two different IP addresses on the external interface of the ISA firewall. I highly recommend that you place these DNS servers, which are responsible for the external zone of your split DNS, on an anonymous access DMZ segment. Hosts on this DMZ segment should not have any access to your internal network and no primary connections should be allowed outbound from the DMZ segment. The only outbound traffic from this segment (at least from the DNS servers), should be response traffic in response to DNS queries made via the DNS Server Publishing Rules.

You should take special care in configuring these public DNS servers. Several settings will go a long way to securing the external end of your split DNS:

By applying these DNS configuration options you’ll significantly reduce the risk of potential attacks against your DNS server.

Summary

In this article we went over the principles that underlie the split DNS infrastructure and how you can use a split DNS infrastructure even when your internal network domain uses an illegal top level domain. In addition, you can use the principles discussed in this article to provide a split DNS that enables location transparent access to resources using a alternative domain name, even if you are currently using a legal top level domain for the internal network’s Active Directory domain.

I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, ask at http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=26;t=000359. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy