DNS Considerations for ISA Server 2000 Branch Office Networks

Chapter 9
DNS Server and Name Resolution Support for Branch Office Deployments

Contents


Introduction. 1

The Split DNS Infrastructure. 2

Scenario 1: Organization uses the same Domain Name for Internal Network and Publicly Accessible Resources  2

Scenario 2: Organizations Use Different Domain Names for Internal and External Network Resources  3

Scenario 3: Same Domain Name for Internal and External Network Resources, External Resources are Hosted by Third Party Hosting Company. 5

DNS Servers at the Branch Offices and Subdomains. 7

Name Resolution for SecureNAT, Firewall and Web Proxy Clients. 8

The SecureNAT Client 8

The Firewall Client 9

The Web Proxy Client 10

The Importance of Primary Domain Name Assignment for ISA Server 2000 Clients. 13

Conclusion. 15

 

Introduction

Name resolution is an essential component of networking. One of the most common causes that prevents ISA Server 2000 clients on branch office and main office networks from connecting to resources correctly through the VPN network or to the Internet are DNS related issues. DNS name resolution problems prevent hosts on the branch office networks from connecting to resources on the main office network and prevent access to Internet-based resources. Name resolution issues can also prevent main office located services from connecting to resources on the branch office networks.

There are a number of issues you should address to ensure that you have a solid DNS infrastructure that supports both your main office and branch office networks. These issues include:

·         Creating an appropriate split DNS infrastructure

·         Placing DNS servers at branch offices and using subdomains for branch office resources

·         Ensuring proper name resolution for SecureNAT, Firewall and Web Proxy clients

·         Assigning the correct primary domain name to main office and branch office clients

In this document we will discuss each of these issues in detail and describe procedures you can perform to create a stable DNS infrastructure for your organization.

 

The Split DNS Infrastructure

A split DNS infrastructure can solve a multitude of problems for organizations that require access to corporate resources when users are located on the corporate network and when they 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.

The split DNS infrastructure solves common DNS issues that affect almost all organizations that use ISA Server 2000 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.

Scenario 1: Organization uses the same Domain Name for Internal Network and Publicly Accessible Resources

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

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 the domain 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 2000 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 publishing and Outlook Web Access Publishing.

1.       The external client needs to access Exchange e-mail located on the internal network Exchange 2003 Server. The ISA Server 2000 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. 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 2000 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 2000 firewall publishing the Exchange Server’s OWA Web site.

3.       The ISA Server 2000 firewall accepts the inbound request and authenticates the external user. When the user is successfully authenticated, the request is forwarded to the Exchange Server on the internal network.

4.       An internal network client needs to access the OWA Web site on the internal network. The internal network client is configured to use the internal DNS server. The internal DNS server is configured with a DNS zone file containing resource records for the msfirewall.org domain. 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.

Scenario 2: Organizations Use Different Domain Names for Internal and External Network Resources

Many organizations have not been able to benefit from being able to plan their DNS naming convention in advance and end up using different domain names for internal and external network resources. Even when different domains names are used, you can still leverage the power and flexibility of the split DNS infrastructure to allow transparent access for hosts that move 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 been complaining about this situation for several months, and there has been a significant number of help desk calls related to problems with reconfiguring the e-mail clients. 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. The DNS server resolves the name and returns the address of the external interface of the ISA Server 2000 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 2000 firewall.

3.       The ISA Server 2000 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 2000 firewall. They connect directly to the internal resource.

Scenario 3: Same Domain Name for Internal and External Network Resources, External Resources are Hosted by Third Party Hosting Company

Another 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.

DNS Servers at the Branch Offices and Subdomains

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 server, primary DNS server 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 configure 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  

Name Resolution for SecureNAT, Firewall and Web Proxy Clients

There are three ISA Server 2000 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 2000 client types you deploy in your branch office networks.

The SecureNAT Client

The SecureNAT client computer must resolve all DNS names itself. The ISA Server 2000 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 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 branch 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 2000 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 branch office network and access that server by using the site to site VPN link.

The Firewall Client

In contrast to the SecureNAT client, the Firewall client can use the ISA Server 2000 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 2000 firewall to resolve the name, the ISA Server 2000 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 2000 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 2000 machine.

2.       The ISA Server 2000 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 2000 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 2000 machine a connection request to the IP address of the www.web.com site.

4.       The ISA Server 2000 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 2000 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 not applied to the connection request because all networks connected via the VPN network are contained in the LAT. 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.

Notice in this example that the Local Address Table contains the addresses of all the networks joined by the site to site VPN networks. The is a critical configuration, as you do not want the Firewall service to intercept the requests destined for internal sites joined by the VPN site to site networks. If the Firewall Service were to intercept these requests, then the ISA Server 2000 firewall would attempt to forward the requests to external locations and would not pass the requests to the VPN demand-dial interface. The result would then be a failed connection attempt.

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 2000 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

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 Local Address Table and Local Domain Table to determine which sites are internal and which are external. However, the Web Proxy clients can be configured to use the autoconfiguration script provided by the ISA Server 2000 firewall to determine which sites are internal and should not be handled by the Web Proxy Service, and which sites are external and should be handled by the Web Proxy Service.

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 2000 machine.

2.       The ISA Server 2000 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 2000 Web Proxy Service.

3.       The Web Proxy 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 2000 machine a connection request to the IP address of the www.web.com site.

4.       The ISA Server 2000 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 2000 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 not applied to the connection request because all networks connected via the VPN network are contained in the LAT. 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.

Note that the Web Proxy client bypasses the Web Proxy service to connect to the OWA site at the branch office. Like the Firewall client, the Web Proxy client computer will need to know the route to the branch office. If the Web Proxy and Firewall client computers are configured as SecureNAT clients, then they can use their default gateway configurations to access the branch office. If not, then the routing tables on the network routers that the Firewall and Web Proxy clients use to access remote subnets must have routes configured on them that send requests to networks joined by site to site VPN links to the internal interface of the ISA Server 2000 firewall computer.

The Importance of Primary Domain Name Assignment for ISA Server 2000 Clients

Hosts on the main office and branch office networks that are 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 that use autodiscovery to automatically obtain configuration information to connect to the ISA Server 2000 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 2000 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 2000 firewall and sends that IP address to the Web Proxy client.

2.       The Web Proxy client connects to the ISA Server 2000 firewall to obtain autoconfiguration information. The ISA Server 2000 firewall sends the autoconfiguration information to the Web Proxy client.

3.       The Web Proxy client can now connect 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 2000 firewall and sends that IP address to the Firewall client.

5.       The Firewall client connects to the ISA Server 2000 firewall to obtain autoconfiguration information. The ISA Server 2000 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

Each of these methods is detailed in the ISA Server 2000 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.

 

Conclusion

The DNS infrastructure is a critical component to all ISA Server 2000 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.