Designing the DNS Infrastructure to Support Exchange Remote Access

 

Configuring Exchange and ISA Servers to allow remote access to Exchange services is relatively easy because of the intuitive nature of Microsoft server configuration interfaces. However, in spite of the ease of server configuration, one issue consistently creates problems for the ISA Server firewall administrator who wants to allow remote users access to Exchange Server resources on the internal network: DNS.

 

DNS name resolution issues continue to vex a large number of network administrators because of the DNS’s inherent complexity. In this ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document we’ll cover the following issues:

 

 

The Exchange Server must be able to resolve Internet MX domain names so that it can forward SMTP messages to the correct mail server on the Internet. There are several ways this can be configured and we’ll discuss each of these options.

 

 

There are a number of common DNS name resolution issues that crop up for remote clients that either stay on the external network, or move between the local and remote networks. We’ll discuss a number of these scenarios and how to accommodate each of them with the correct DNS configuration.

 

 

 

Creating a DNS Infrastructure to Support the Exchange Server for Outbound Access

 

The Exchange Server’s SMTP service must be able to resolve the MX domain name for SMTP messages it needs to relay. For example, the Exchange Server is responsible for mail to users in the internal.net domain. All mail destined to mail domains other than internal.net must be forwarded to another SMTP server.

 

When this Exchange Server’s SMTP service receives a message destined for the domain domain.com, the SMTP services must use the information contained in a DNS MX record to deliver the message. A DNS MX record contains the name of a server; that server must also have a Host (A) record mapping the actual IP address used by that server. The server contained in the MX record for a mail domain is the server responsible for receiving mail for that particular domain.

 

The SMTP service must be able to find the name of the server contained in the MX record and then find the IP address of the name found in the MX record. This is done via DNS queries. The SMTP service can use one of several methods to resolve the MX domain name. These methods include:

 

 

Let’s look at each of these options in more detail.

 

Query an Internal Network DNS Server to Resolve the MX Domain Name

 

By default, the Exchange Server’s SMTP service uses the DNS server configured on its network interface to resolve DNS names. The Exchange Server must belong to a Windows Active Directory domain and therefore must be configured to use an internal network DNS server to contact the Active Directory. The DNS server the Exchange Server uses to contact the Active Directory can also be used to resolve MX domain names for Internet mail domains.

 

The internal network DNS server must be configured to resolve Internet MX domain names either by performing recursion on its own, or by using a forwarder. I generally do not recommend allowing an internal network DNS server to perform recursion on its own because this requires the internal network DNS server be in direct contact with multiple Internet DNS servers. This situation increases the chance of the DNS server on the internal network being compromised by a DNS exploit.

 

Instead of allowing the internal network DNS server to perform recursion, you can configure the DNS server to use a forwarder. In this case the DNS server forwards requests for all domains for which it is not authoritative. These name resolution requests are forwarded to another DNS server.

 

The ideal configuration is to set up the ISA Server firewall as a caching-only DNS server and configure the internal network DNS server to use the ISA Server firewall’s caching-only DNS server as its forwarder. This protects the DNS server on the internal network, and the zones contained within it, from attack from external DNS servers. It also allows you to focus your attention on hardening the caching-only DNS services located on the ISA Server firewall.

 

This configuration, where the internal network DNS server uses a caching-only DNS server on the ISA Server firewall as a forwarder is the preferred configuration. However, if you prefer not to use this method, there three alternatives available to you.

 

Query an External Network DNS Server to Resolve the MX Domain Name

 

It is possible to include the IP address of an external DNS server on the DNS server list on the Exchange Server’s network interface. For example, some network administrators may configure the network interface on the Exchange Server computer with the IP address of a DNS server that allows the Exchange Server to contact the Active Directory and the IP address of a DNS server on an external network (such as the ISP’s DNS server).

 

I mention this option only to warn you against it. You should never bind an external DNS server address on the Exchange Server’s network interface. This type of configuration can lead to the Exchange Server being unable to contact the Active Directory and essentially disabling the Exchange Server’s functionality.

 

Do not configure the Exchange Server’s network interface card with the IP address of an external DNS server. Instead, use the configuration described in the next section where you configure the SMTP service to use an “external” DNS server.

 

Query an Exchange SMTP Service External DNS Server

 

Microsoft realized the problems with configuring the network interface card with the IP address of an external DNS server, so they designed the Exchange Server’s SMTP service to accept IP addresses of DNS servers on an external network to be used only by the SMTP service and allow the computer to use an internal DNS server for all other name resolution services.

 

This configuration allows the Exchange Server’s network interface to be configured with the IP address of a DNS server on the internal network. This DNS server allows the Exchange Server to communicate with the Active Directory. However, this internal network DNS server is not able to resolve Internet host names. The Exchange Server’s SMTP service doesn’t use the internal DNS server to resolve Internet host names (in this case, Internet MX domain names). Instead, it uses its own custom configured DNS server.

 

You can find this custom SMTP service DNS server configuration by performing the following steps:

 

  1. Open the Exchange System Manager, expand the Servers node and then expand your server name.
  2. Expand the Protocols node and then expand the SMTP node. Right click on the Default SMTP Virtual Server and click the Properties command.
  3. Click on the Delivery tab. On the Delivery tab, click on the Advanced button.
  4. On the Advanced Delivery dialog box, click the Configure button that lies to the right of the Configure external DNS Servers description.
  5. In the Configure dialog box, click the Add button. In the Add dialog box, enter the IP address of an external DNS server and click OK.
  6. Repeat the procedure if you want to add more DNS external DNS servers. Click OK in the Configure dialog box.
  7. Click OK in the Advanced Delivery dialog box.
  8. Click Apply and then click OK in the Default SMTP Virtual Server Properties dialog box.
  9. Restart the SMTP service.

 

Now the SMTP service uses this DNS server to resolve MX domain names. No other service on the Exchange Server computer will use this DNS server. All other services on the same computer as the Exchange Server use the DNS server configured on the network interface card on the Exchange Server.

 

Use a Smart Host to Offload MX Domain Name Resolution

 

A smart host is an SMTP server that receives outbound SMTP messages from the Exchange Server’s SMTP server and forwards the SMTP messages to the correct destination after resolving the MX domain name for the message. The smart host offloads the responsibility for resolving MX domain names from the Exchange Server’s SMTP service to the smart host SMTP server.

 

For example, our Exchange Server is responsible for mail in the internal.net domain. The Exchange Server receives a message for a user in the domain.com domain. The SMTP service does not try to resolve the MX domain name for domain.com. Instead, the Exchange Server’s SMTP service forwards all mail not destined to the internal.net domain to the smart host. The message for the user at domain.com is sent to the smart host. The smart host resolves the MX domain name for domain.com and forwards the message to the SMTP server responsible for the domain.com domain.

 

There are several advantages to using a smart host: the Exchange Server does not need to generate traffic related to DNS name resolution, you don’t have to configure a DNS server on the internal network to be able to resolve Internet host names, you don’t have to configure the Exchange Server’s SMTP service to use a custom “external” DNS server and you don’t have wonder where the SMTP messages are sent. They’re all send to the smart host computer.

 

The smart host can be another SMTP server on the internal network, or an SMTP server on an external network, such as a DMZ segment or your ISP. You can even use the IIS SMTP service on the ISA Server firewall as a smart host. If you have a good ISP that you trust to maintain high quality and high performance SMTP services, it might be best to use their SMTP server as a smart host. On the other hand, you might want to use an SMTP relay computer on your internal network as a smart host. The advantage of this approach is that you can configure the SMTP relay under your administrative control to filter outbound mail for key words and attachments using the ISA Server 2000 SMTP Message Screener.

 

 

 

Creating a DNS Infrastructure to Support Remote Access Clients

 

Remote clients need to be able to resolve the name of the Exchange Server’s services so that they can contact these services over the Internet from a remote location. The problem for remote hosts is that they don’t always resolve the same name to the same IP address.

 

If the email client moves to the internal network, it needs to know the actual P address of the Exchange Server. When the email client is on an external network, the machine needs to know the IP address on the external interface of the ISA Server firewall that is being used in the Web or Server Publishing Rule that is making the service available to remote clients.

 

We cover the following issues in this section on designing and configuring DNS to support remote email clients:

 

 

Let’s look at each of these subjects in more detail.

 

Configure a Split DNS Infrastructure

 

A split DNS infrastructure allows email clients to move between the internal network and remote locations without requiring changing settings in email client applications. The split DNS allows users to plug into whatever network they need to connect to and properly resolve the name of Exchange Server based on that location. The split DNS infrastructure allows the users email experience to be location independent and greatly enhances the user’s email experience.

 

Let’s look at some examples to see how a split DNS infrastructure is superior to the traditional approach of using different domain names for internally and externally accessible resources.

 

The first example is of an organization that has decided to use the name internal.local on the internal network and internal.net for resources accessible to external network hosts. Hosts on the internal network connect to the Exchange Server using the name mail.internal.local and remote users at external network locations use the name mail.internal.net.

 

In order to make this traditional, non-split DNS infrastructure work, you will need two DNS zones. One DNS zone contains the internal.local DNS zone and the other DNS zone contains the internal.net DNS zone. The DNS server with the internal.local DNS zone is used by only internal network hosts and that DNS server is located somewhere on the internal network behind the ISA Server firewall. The DNS zone containing the internal.net DNS zone is located either on an external network location, such as your ISP, or is located on the internal network and published via an ISA Server Publishing Rule.

 

Note in this example of the non-split DNS that a single DNS server can be used to support the two DNS zones. The internal.local and the internal.net zones can be contained on the same Windows-based DNS server. As you’ll see later, a split DNS infrastructure requires that you have two physically separate DNS servers.

 

The internal and external DNS zones contain records that allow their respective clients access to the Exchange Server. The internal DNS zone containing the internal.local zone contains a Host (A) resource record that maps the name mail.internal.local to 10.0.0.2. The external DNS zone containing the internal.net zone maps the name mail.internal.net to the public IP address used in Server and Web Publishing Rules to allow inbound access to the Exchange Server, which in this case is 131.107.0.1.

 

This setup works great for clients that always remain either on the internal network or at a remote location. The users who are always on the internal network configure their email applications to use mail.internal.local to access the Exchange Server’s services. Users who are always located on a remote network configure their email client applications to use the name mail.internal.net to access the Exchange Server’s services.

 

This setup falls down when users need to move from an external network to the local network and when they move from the local network to an external network. For example, suppose your Senior VP of Sales needs to travel to a customer site three thousand miles away. His laptop computer is configured to use the name mail.internal.local to connect to the Exchange Server’s services. What happens when the VP tries to access his email from the remote location?

 

The VP won’t be able to access his mail from the remote location because there is no way for his computer to resolve the name mail.internal.local. The .local domain is not valid on the Internet. To solve this problem, the VP needs to go into his email client application and change all the server references from mail.internal.local to mail.internal.net. This also includes using mail.internal.net instead of mail.internal.local when connecting to OWA and other published services. The probability is good (approaching 100%) that the VP won’t be happy with this situation and will demand the problem be fixed ASAP.

 

How will you fix it? By using a split DNS. With a split DNS infrastructure, you use the same name for internal and external access to resources. Instead of naming the internal network domain internal.local, you can use the name internal.net. There are no contraindications to using the same domain name for internal and external network access, and it simplifies things for your users by orders of magnitude.

 

Note that if you already have an Active Directory domain in place that incorporates a top level domain that you cannot use from the Internet (such as the .local or .private domain), you can still use the split DNS infrastructure. All you need to do is create a DNS zone for the domain name you would like to use from the Internet. For example, even though the Active Directory domain name in this example is internal.local, you can still create a DNS zone on the internal DNS server for internal.net and enter the appropriate internal (private network addresses) Host (A) and MX records that allow internal network clients to connect directly to the Exchange Server on the internal network.

 

Lets look at what happens when we convert to a split DNS infrastructure. We have two DNS servers: one of them is configured to support internal network clients and the other configured to support remote access clients on the Internet. The internal DNS server has a zone for the internal.net domain and has a Host (A) record for the Exchange Server that maps the name mail.internal.net to the IP address 10.0.0.2. The external DNS server also has a zone for the internal.net domain, but the external DNS server has a Host (A) record mapping the name mail.internal.net to 131.107.0.1.

 

Notice that both the internal and external DNS servers have a mapping for mail.internal.net. The only difference is that the internal DNS server maps the name to the actual IP address used by the Exchange Server, while the external DNS server maps the mail.internal.net name to the public IP address used in the ISA Server firewall’s Server Publishing Rule.

 

Now what happens to the VP who tries to get mail the Exchange Server when connected to the internal network and when he travels to remote locations?

 

His email client application is configured to connect to the Exchange Server using the name mail.internal.net. When connected to the internal network his laptop computer resolves the name mail.internal.net to the Exchange Server’s internal address and directly connects to the Exchange Server via 10.0.0.2. When traveling to a customer location, he still connects to the Exchange Server using mail.internal.net, but this time connecting via IP address 131.107.0.1 -- the address on the external interface of the ISA Server firewall that you used in your Web and Server Publishing Rules to publish your Exchange Server’s services on the internal network.

 

The core of the split DNS is:

 

 

You must make sure the email client application is assigned an address for a DNS server that can correctly resolve the name and that the client application is able to correctly resolve unqualified names correctly. The latter problem is specific for remote Outlook 2000 Exchange RPC access because of its continued dependence on NetBIOS names We’ll cover that issue the ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document Configuring the Outlook 2000 Client.

 

In most cases the email client computer obtains its IP addressing information via DHCP. The most common DHCP option assigned to DHCP clients is the DNS server option. You should configure the DHCP server on your internal network to assign the DHCP clients the DNS server address that can resolve the name of your split DNS domain.

 

For example, suppose your Active Directory domain name is internal.local. You can create a second DNS zone for internal.net on the same DNS servers that serve the internal.local domain, or you can put the internal.net domain zone on a separate DNS server. If you do put the internal.net zone on a separate DNS server, then you should create a DNS referral zone on the DNS servers serving the internal.local zone to forward requests for internal.net to the appropriate DNS servers on the internal network.

 

You do not have control over the DHCP servers on external networks. However, almost all remote networks that your users will connect will be able to assign via DHCP a DNS server that can resolve Internet host names. In this case, the email client on the remote network is assigned the address of a DNS server that can resolve Internet host names. The email client is configured to connect to the Exchange Server using the name mail.internal.net. The Internet DNS servers will resolve the name mail.internal.net to the public IP address on the external interface of the ISA Server firewall that you used in your Web or Server Publishing Rules.

 

The end result is that the email client does not need to be reconfigured based on network location. The split DNS allows the user to connect to the Exchange Server without ever needing to reconfigure the name of the Exchange Server. Email access just works.

 

 

Special Considerations for Secure SMTP/POP3/NNTP/IMAP4 and OWA SSL Connections

 

Your split DNS infrastructure supports access to all Exchange Server services. However, there are additional issues you need to consider when you want to use SSL/TLS security on connections to the Exchange Server’s services.

 

The following requirements must be met to support SSL/TLS secured connections to the Exchange Server’s services:

 

 

Let’s looks at each of these issue in more detail.

 

The Common Name on the Web Site Certificate Must Be the Same as that Used by the Email Client

 

Secure Exchange email services have a Web site certificate bound to them before they can establish a secure link with an email client. The certificate bound to the service has a common name listed that identifies the secure mail service site. For example, when you request a Web site certificate for the SMTP service, you might have used the name mail.internal.net or smtp.internal.net or exchange.internal.net. Regardless of the name listed on the certificate, the email client machine must connect to the Exchange Server using that name.

 

Note:
The name on the certificate is determined by the person who requested the certificate. The Web site certificate Wizard on the Exchange Server allows you to enter the common name used by the service you bind the certificate to. For more information on how to request a certificate for an Exchange Server service, please refer to ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document How to Obtain a Web Site Certificate

 

The Email Client Application must be Configured to Use the FQDN Listed in the Common Name on the Exchange Service’s Certificate

 

The email client application connecting to a secure Exchange Service must use the FQDN listed on the Web site certificate to connect to the service. For example, you want to use a secure POP3 connection between the Outlook Express client and the POP3 service on the Exchange Server. If the certificate bound to the POP3 service on the Exchange Server has the common name pop.internal.net, then you need to configure the email client application to use the name pop.internal.net for the POP3 email server. You can not use the IP address of the POP3 server or the IP address on the external interface of the ISA Server firewall that is publishing the POP3 service via a Server Publishing Rule.

 

The reason why you must connect using the name listed on the certificate is that the client needs to confirm the identity of the server. The service identifies itself via the common name listed on the certificate. This process of the email service on the Exchange Server identifying itself is an important part of the security provided by secure SSL/TLS connections between the email client and server.

 

The Email Client Application must Trust the Certificate Presented by the Email Service

 

The secure mail service on the Exchange Server presents its server certificate to the email client as part of the security process that creates the secure channel between the email client and Exchange Server service. Part of this process includes the email client checking whether it trusts the certificate authority that issued the certificate to the secure Exchange Service.

 

The email client checks to see if the root CA in the list of CAs listed on the Exchange Service’s certificate is included in the client’s Trusted Root Certification Authorities certificate store. If the root CA certificate is not included in that list, the connection attempt will either fail, or the user will be presented with an error dialog box indicating that his machine does not trust the server. Neither of these situations is desirable and can lead to the inability to connect, or confusion on the email user’s part.

 

The problem is solved by importing the root CA certificate into the email client’s machine certificate store. Please review ISA Server 2000 Exchange Server 2000/2003 Deployment Kit document How to Import the Root CA Certificate into Email Client Certificate Stores.