DNS Support for ISA Server 2004 Connected Branch Offices

A split DNS infrastructure can solve a multitude of problems for organizations requiring access to corporate resources when users are located on the corporate network and when those same users must leave the corporate network and connect to resources from remote locations. The split DNS infrastructure provides a seamless computing experience by allowing users to connect to resources on the main office and branch office networks without requiring users to reconfigure their client applications. Without a split DNS infrastructure, users must reconfigure the client applications, such as Outlook and Web browsers, to support name resolution for their current location.

The split DNS infrastructure solves common DNS issues affecting almost all organizations that use ISA Server 2004 as a corporate firewall. Let’s review a few examples to gain an understanding of how a split DNS infrastructure solves common name resolution issues.

In this example, the company uses the same domain name for their internal network resources accessible to internal network computers, and for resources that are accessible from the Internet. The company uses ISA Server 2004 to publish Web and Mail Servers to the Internet so that traveling employees can access company resources and their Exchange e-mail accounts. Management has dictated that users should never need to reconfigure their email clients or manually reconfigure their IP address settings on their laptop computers or other mobile devices to gain access to required corporate resources.

You can accomplish this goal by using a split DNS infrastructure. In the split DNS infrastructure, separate DNS server machines contain different DNS zone file entries for domains of the same name. Internal network clients use the DNS zone designed for internal network client use and external network clients use a second DNS zone designed for external network client use. These DNS zones are designed so that internal network clients can directly access internal network resources and external network clients can access internal network resources via the ISA Server 2004 firewall that publishes the resource.

The figure below shows how the split DNS infrastructure makes access to Exchange Server resources transparent to uses, regardless of the user’s location. In this example, the internal network Active Directory domain name is msfirewall.org and external users access the internal Exchange Server via secure Exchange RPC Sever Publishing and Outlook Web Access Web Publishing.

1. The external client needs to access Exchange e-mail located on the internal network Exchange 2003 Server. The ISA Server 2004 firewall publishes the Exchange Server services so that hosts located on the Internet can securely access them. When the user located at a remote location enters http://owa.msfirewall.org, the client operating system first resolves the name owa.msfirewall.org to an IP address. The external client sends the DNS name resolution request to a public DNS server that contains the DNS zone that is designed for external network clients. The public DNS server is able to resolve the name owa.msfirewall.org to the IP address on the external interface of the ISA Server 2004 firewall that is publishing the Exchange Server services.
2. After the DNS server returns the IP address for owa.msfirewall.org, the client sends an HTTP connection request to the external interface of the ISA Server 2004 firewall publishing the Exchange Server’s OWA Web site.
3. The ISA Server 2004 firewall accepts the inbound request and authenticates the external user. When the user successfully authenticates, the request is forwarded to the Exchange Server on the internal network.
4. Now let’s switch our attention to Internal network clients located behind the ISA Server 2004 firewall. An internal network client needs to access the OWA Web site on the internal network. Internal network clients use the internal DNS server. The internal DNS server is configured with a DNS zone file containing resource records for the msfirewall.org domain in the same way as the external DNS server. However, the resources records on the Internal DNS server contain the private IP addresses used by resources on the Internal network, not the public addresses used by the external interface of the ISA Server 2004 firewall. When the client operating system on the internal network client sends a DNS query to the internal DNS server for owa.msfirewall.org, the DNS server returns the internal IP address of the Exchange Server.
5. The internal network client connects to the internal IP address of the Exchange Server. The internal network client does not loop back through the firewall to access internal network resources.

Many organizations have not planned their DNS domain naming system in advance, or because of circumstances beyond their control, have not been able to implement a clean split DNS infrastructure. While at first blush this might appear to pose a problem, the fact is that even when different domains names are used for internally and externally accessible resources, you can still leverage the power and flexibility of the split DNS infrastructure to allow location independent name resolution transparency for hosts moving between the internal and external networks.

For example, the organization has an established Active Directory domain name, which is corp.com. The company already has an established public presence using the name msfirewall.org. The company hosts its own Exchange 2003 e-mail services.

The problem is that when users are on the internal network, they need to configure their e-mail client applications to connect to the Exchange Server using the name owa.corp.com and when the users are at remote locations, they need to reconfigure their e-mail clients to use the name owa.msfirewall.org.

Users have complained about this situation for several months, and there has been a significant number of help desk calls related to errors and misunderstandings related to reconfiguring e-mail clients based on the user’s current location.

The solution is the split DNS infrastructure. The figure below shows how the split DNS infrastructure solves the problem when the internal and external domain names are different.

1. An external client wants to connect to the OWA site on the internal network. The user enters http://owa.msfirewall.org into the browser. The client operating system sends a request to a public DNS server to resolve the name owa.msfirewall.org. This is a public access DNS server that you have configured to support your publicly accessible resources, such as OWA and secure Exchange RPC. The DNS server resolves the name and returns the address of the external interface of the ISA Server 2004 firewall used to publish the OWA Web site.
2. The external client connects to the IP address on the external interface of the ISA Server 2004 firewall.
3. The ISA Server 2004 firewall authenticates the user and forwards the connection request to the OWA site on the internal network.
4. A host on the internal network needs to connect to the Exchange Server’s OWA site on the internal network. The internal network client enters http://owa.msfirewall.org into the browser. The client operating system sends the DNS query to the internal network DNS server. The internal network DNS server hosts DNS zones for the internal network’s Active Directory and the msfirewall.org DNS zone to be used by the internal network clients. The internal network DNS server is authoritative for the msfirewall.org zone and returns the internal IP address of the OWA Web on the internal network. Note that the DNS server can resolve both the Active Directory DNS names and the names used for the split DNS infrastructure. You can enhance the split DNS infrastructure even more by configuring the internal network clients to use the Active Directory domain name and the split DNS domain name as primary domain names or adapter specific names as part of a DNS server search list.
5. The internal network client connects directly to the internal network Exchange 2003 OWA site. The internal network clients do not connect to internal network resources by looping back through the ISA Server 2004 firewall. They connect directly to the internal resource.

The next example of a split DNS infrastructure departs from the full DNS split infrastructure that we’ve discussed in the first two scenarios. A common situation encountered by smaller organizations occurs when they use the same domain name for internal and externally accessible resources, and the external resources are hosted by a third party Web hosting company.

The figure below shows what happens in this scenario.

1. An external network client enters http://www.msfirewall.org in the Web browser. The client operating system sends a DNS query to a public DNS server. The DNS server resolves the name www.msfirewall.org to the public address of the www.msfirewall.org Web site hosted by the Web hosting company.
2. The external network client sends a connection request to the public Web server and accesses resources on the www.msfirewall.org Web server.
3. An internal network client enters http://www.msfirewall.org into the browser. The client operating system sends a DNS query to resolve the name to the internal network DNS server.
4. The internal network DNS server is authoritative for the msfirewall.org domain. The internal network Active Directory domain name is msfirewall.org. There are no internal network resources that go by the name of www.msfirewall.org. The internal network DNS server returns a server failure to the client and the client is not able to connect to the www.msfirewall.org Web server on the Internet because the DNS server does not forward the request to another DNS server, because it is authoritative for the msfirewall.org domain. Another potential problem could be encountered if there is a resource record on the internal network DNS server for the www.msfirewall.org name, but it points to an internal network server.

The solution to this problem is not to create a separate DNS zone that goes by the same name; we already have two DNS zones. The problem in this case is that the internal DNS server resolves the msfirewall.org domain to internal network names. You can fix this problem by creating individual Host (A) resource records in the internal network DNS that resolve to the public addresses used by the servers. In this example, you would enter the public address of the host www.msfirewall.org into the internal DNS server’s msfirewall.org zone.

Branch offices can be part of the same Active Directory domain as the main office, or you can assign branch office machines to another DNS domain. Segregating resources into different domains makes them easier to identify and manage.

For example, the figure below shows three sites joined by VPN site to site network links. The main office resources are located in the msfirewall.org DNS domain. The first branch office’s resources are located in the nw.msfirewall.org domain, and the third branch office’s network resources are located in the sw.msfirewall.org domain. It becomes simple to identify the location of network resources when you identify them by different domain names.

This example shows the main office domain at the top level domain in the organization and the branch offices as subdomains. The advantage of using a top level/subdomain configuration for your DNS topology is that all these domains can belong to the same DNS zone.

The DNS servers can all be Active Directory integrated DNS, primary DNS or secondary DNS servers.

Active Directory integrated DNS servers must be located on domain controllers. The advantage of using Active Directory integrated DNS servers is that the DNS replication topology mirrors the Active Directory replication topology. You do not need to create two separate replication topologies.

Note that even though the branch offices are configured as subdomains, they are not required to be part of the same zone as the top level domain. You can create separate zones for each of the branch offices if you wish, and then configure the hosts to register an adapter specific DNS suffix when they perform dynamic DNS updates.

For more information on DNS configuration for branch office configurations, please refer to Active Directory Branch Office Guide Series — Deployment Guide at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/ad/windows2000/deploy/adguide/addeploy/default.asp

There are three ISA Server 2004 client types:

• The SecureNAT client
• The Firewall client
• The Web Proxy client

Each client type resolves names differently. It is critical that you understand how these different client types resolve names so that you can configure your DNS infrastructure to support the ISA Server 2004 client types you deploy in your branch office networks.

The SecureNAT client computer must resolve all DNS names itself. In contrast to Web proxy and Firewall clients, the ISA Server 2004 firewall will not resolve any names for the SecureNAT client. All SecureNAT clients must be configured with a DNS server address that can resolve both internal and Internet host names.

The figure below shows how the SecureNAT client handles name resolution on the branch office network.

1. The SecureNAT client makes a request to connect to www.web.com. The client operating system sends a query to a DNS server to resolve the name www.web.com to an IP address. The DNS server returns to the SecureNAT client IP address of the www.web.com site.
2. The SecureNAT client sends an HTTP request to the Web site at the IP address for www.web.com.
3. The SecureNAT client needs to connect to a resource located on an OWA server on the corporate network located at the main office. The SecureNAT client sends a DNS query for mail.msfirewall.org to the DNS server located at the branch office. The branch office DNS server is a standard secondary DNS server for the main office DNS server that is the primary DNS server for the msfirewall.org domain. The DNS server at the branch office returns to the SecureNAT client the internal IP address of the mail.msfirewall.org Web server at the branch office.
4. The SecureNAT client sends a connection request to the mail.msfirewall.org OWA server by going through the site to site VPN link connecting the offices.

In this example, we saw how the SecureNAT client was able to connect to Internet resources by resolving the name of the public Web site and then going through the ISA Server 2004 firewall to connect to the Internet based Web server. We also saw how the SecureNAT client was able to resolve the name of the internal OWA Web server located on the main office network and access that server by using the site to site VPN link.

In contrast to the SecureNAT client, the Firewall client can use the ISA Server 2004 firewall to resolve names on its behalf. By default, Firewall clients resolve names in two ways:

• If the name of the resource is contained in the Local Domain Table, then the Firewall client computer will use the DNS server configured on its own network interface’s Properties dialog box to resolve the name
• If the name of the resource is not contained in the Local Domain Table, then the Firewall client allows the ISA Server 2004 firewall to resolve the name, the ISA Server 2004 firewall returns the address to the Firewall client, and then the Firewall client connects to the IP address returned to it by the ISA Server 2004 firewall computer.

The figure below shows the sequence of events for name resolution and subsequent connections for Firewall client computers.

1. The firewall client issues a request to connect to www.web.com. The connection request is sent to the Firewall Service on the ISA Server 2004 machine.
2. The ISA Server 2004 Firewall Service sends a query to the local DNS server for www.web.com. The DNS server returns the IP address of the Web site to the ISA Server 2004 Firewall Service.
3. The Firewall Service returns the IP address of the www.web.com Web site to the Firewall client computer. The Firewall client computer then sends to the Firewall Service on the ISA Server 2004 machine a connection request to the IP address of the www.web.com site.
4. The ISA Server 2004 firewall computer forwards the connection request to the www.web.com Web site.
5. The Firewall client needs to connect to the OWA Web site at the main office. The domain name, msfirewall.org, is contained in the Local Domain Table on the branch office ISA Server 2004 firewall. The Firewall client on the branch office is configured with the IP address of the DNS server on the branch office network and sends a DNS query request to the DNS server. The Firewall client sends the DNS query directly to the DNS server because the request is to connect to mail.msfirewall.org machine and the msfirewall.org domain is in the Local Domain Table. The DNS server is a secondary DNS server for the main office DNS server that is the primary DNS server for the msfirewall.org domain. The local DNS server at the branch office returns the internal IP address of the mail.msfirewall.org site to the Firewall client.
6. The Firewall client machine sends the request to the mail.msfirewall.org OWA Web site at the main office. Firewall Policy is applied to the connection request because all networks connected to the ISA Server 2004 firewall as subject to firewall policy. The Firewall client computer on the branch office network connects to the OWA Web site at the branch office network through the site to site VPN link only if there is a firewall policy in place that allows the connection.

Notice in the figure above that the “Local Address Table” contains the addresses of all the networks joined by the site to site VPN networks. This was a requirement for ISA Server 2000 site to site connections because the ISA Server 2000 firewall did not apply firewall policy to VPN connections. In contrast, the branch office ISA Server 2004 firewall subjects all connection requests to firewall policy and connections are allowed only if there is a policy allowing the connection.

ISA Server 2004 does not use the LAT; instead, the ISA Server 2004 firewall uses the Internal network to define what addresses are local and should not be proxied. Because the Main office is not part of the Branch office’s Internal network, the ISA Server 2004 firewall at the branch office handles the request and applies firewall policy to it. Connections between hosts on the Branch office Internal network are not mediated by the ISA Server 2004 firewall.

Note that you can customize how the Firewall client machine handles DNS name queries. For example, you can configure the Firewall client to resolve all names itself and never allow the ISA Server 2004 firewall to resolve names on its behalf. For more details on this configuration, please refer to Jim Harrison’s article on configuring the Firewall client, ISA Clients – Part 3: The Firewall Client at http://www.isaserver.org/tutorials/ISA_Clients__Part_3_The_Firewall_Client.html.

The Web Proxy client handles DNS name resolution for internal and external clients in a way similar to that seen with the Firewall client. The primary difference is that the Web Proxy client does not automatically use the Internal network address list and Local Domain Table (LDT) to determine which sites should be proxied and which sites should be connected to via Direct Access.

Web Proxy clients can be configured to use the autoconfiguration script provided by the ISA Server 2004 firewall to determine which sites should be proxied and which sites should be connected to via Direct Access. Direct Access is when a machine configured as a Web Proxy client bypasses the Web Proxy service (filter) on the ISA Server 2004 firewall to connect to the destination Web site. If the Web Proxy client is configured to bypass the Web Proxy service to access a particular Web site, and that Web site is located outside of the Internal network, then the machine must also be configured as either/or a SecureNAT or Firewall client to allow the connection.

The figure below shows the sequence of events for name resolution and connections to internal and external resources for the Web Proxy client.

1. The Web Proxy client issues a request to connect to www.web.com. The connection request is sent to the Web Proxy service on the ISA Server 2004 machine.
2. The ISA Server 2004 Web Proxy Service sends a query to the local DNS server for www.web.com. The DNS server returns the IP address of the Web site to the ISA Server 2004 Web Proxy Service.
3. The Web Proxy service returns the IP address of the www.web.com Web site to the Web Proxy client computer. The Web Proxy client computer then sends to the Firewall Service on the ISA Server 2004 machine a connection request to the IP address of the www.web.com site.
4. The ISA Server 2004 firewall computer forwards the connection request to the www.web.com Web site.
5. The Web Proxy client needs to connect to the OWA Web site at the main office. The domain name, msfirewall.org, is contained in the Local Domain Table on the branch office ISA Server 2004 firewall. The Web Proxy client is configured to use the autoconfiguration script and is configured to bypass the Web Proxy service for entries in the LDT. The Web Proxy client on the branch office is configured with the IP address of the DNS server on the branch office network and sends a DNS query request to the DNS server. The Web Proxy client sends the DNS query directly to the DNS server because the request is to connect to mail.msfirewall.org machine and the msfirewall.org domain is in the Local Domain Table. The DNS server is a secondary DNS server for the main office DNS server that is the primary DNS server for the msfirewall.org domain. The local DNS server at the branch office returns the internal IP address of the mail.msfirewall.org site to the Firewall client.
6. The Web Proxy client machine sends the request to the mail.msfirewall.org OWA Web site at the main office. Firewall Policy is applied to the connection request because all networks connected to the ISA Server 2004 firewall are exposed to firewall policy. The Web Proxy client computer on the branch office network connects to the OWA Web site at the branch office network through the site to site VPN link and not over the Internet.

Note that the Web Proxy client bypasses the Web Proxy service to connect to the OWA site at the branch office. Because of this, the Web Proxy client computer must be configured as either a SecureNAT or Firewall client to connect to the Main office. If the machine is configured as a Firewall client, you do not need to create a supporting routing infrastructure, as the connection request is forwarded directly to the Branch office ISA Server 2004 firewall. However, if the machine is configured as a SecureNAT client and not a Firewall client, then the routing infrastructure must be in place to forward the connection request to the internal interface of the ISA Server 2004 firewall.

Hosts on the main office and branch office networks configured as Firewall and Web Proxy clients need to be configured with a primary domain name that allows them to correctly resolve unqualified requests. An unqualified request is one that does not contain a complete fully qualified domain name. For example, a connection request to http://server1 is an unqualified request because it does not contain a domain name, only the server name.

Correctly resolving unqualified requests is important for Firewall and Web Proxy client machines using autodiscovery to automatically obtain configuration information to connect to the ISA Server 2004 firewall. Autodiscovery and autoconfiguration for Firewall and Web Proxy clients depends on the clients’ ability to correct fully qualify the wpad name. The Firewall and Web Proxy clients attempt to fully qualify that wpad alias and then send a query to the DNS server for the address of the ISA Server 2004 firewall that can provide them autoconfiguration information.

The figure below shows the series of events that take place when a Firewall or Web Proxy client uses autodiscovery to obtain autoconfiguration information.

1. When the Web Proxy client browser opens, it sends a request for http://wpad. The Web Proxy client operating system automatically fully qualifies the name using the primary domain suffix configured for the Web Proxy client computer. In this example, the Web Proxy client machine is a member of the msfirewall.org domain. The client operating system automatically fully qualifies the request using the primary domain name msfirewall.org and sends a query to the DNS server to resolve the name wpad.msfirewall.org. The DNS server resolves the name to the IP address on the internal interface of the ISA Server 2004 firewall and sends that IP address to the Web Proxy client.
2. The Web Proxy client connects to the ISA Server 2004 firewall to obtain autoconfiguration information. The ISA Server 2004 firewall sends the autoconfiguration information to the Web Proxy client.
3. The Web Proxy client connects to Internet resources by “remoting” Web requests directly to the Web Proxy service, using the parameters in the autoconfiguration file.
4. When the Firewall client software is configured to use autodiscovery, it sends a request for http://wpad. The Firewall client operating system automatically fully qualifies the name using the primary domain suffix configured for the Firewall client computer. In this example, the Firewall client machine is a member of the msfirewall.org domain. The client operating system automatically fully qualifies the request using the primary domain name msfirewall.org and sends a query to the DNS server to resolve the name wpad.msfirewall.org. The DNS server resolves the name to the IP address on the internal interface of the ISA Server 2004 firewall and sends that IP address to the Firewall client.
5. The Firewall client connects to the ISA Server 2004 firewall to obtain autoconfiguration information. The ISA Server 2004 firewall sends the autoconfiguration information to the Firewall client.
6. The Firewall client can now connect to Internet resources by “remoting” Web requests directly to the Firewall service, using the parameters in the autoconfiguration file.

There are several ways you can configure the clients to correctly fully qualify the unqualified request for the wpad entry:

• Join the clients to a Windows domain name that hosts a wpad alias resource record
• Manually configure a primary domain name on the Firewall and Web Proxy client machines
• Configure a DHCP server with a DHCP option that provides a primary domain name to DHCP clients

Note that using DNS for assignment of wpad information can be problematic because if Branch office machines are members of the same domain as the Main office computers, then the wpad entry must be shared by all machines in the same domain. For this reason, you may want to consider using a subdomain for your branch offices and joining those machines to the subdomain. This allows you to configure a wpad entry in the subdomain DNS that applies to machines on the branch office and enables them to use Autodiscovery to locate the local ISA Server 2004 firewall at the branch office.

On the other hand, if you are using Active Directory domains at the Main and Branch offices, a more efficient method of managing proxy configuration for the Web Proxy client is through Web browser management in the Active Directory Group Policy. Unfortunately, there are no Group Policy objects that allow you to centralized control of the Firewall client configuration.

Each of these methods is detailed in the ISA Server 2004 in Education Deployment Kit document Chapter 5: Automating ISA Server 2000 Web Proxy and Firewall Client Installation and Configuration at http://isaserver.org/tutorials/isaedukit.html.

The DNS infrastructure is a critical component to all ISA Server 2004 installations. In this document, we discussed issues related to configuring a split DNS infrastructure, DNS server placement and design for branch offices, Web Proxy and Firewall client autodiscovery and primary domain name assignment. Branch office clients will be able to more reliably connect to resources located at the main office and other branch offices using the guidelines and procedures outlined in this document.

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, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=26;t=000021 and post a message. 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