Many organizations find it desirable to implement a split DNS infrastructure to support proper name resolution when the same domain name is used for both internal and external resources. To enhance the security of a split DNS infrastructure, it is necessary to set up separate DNS servers that are both authoritative for the intranet and extranet DNS Resource Records. You can further enhance the security of a DNS infrastructure by separating the DNS. DNS servers can be hardened to mitigate common DNS threats. This configuration can be complemented by ISA Server configurations to provide an added layer of protection.

This chapter discusses possible configurations that provide both enhanced security and availability for DNS services. This chapter provides detailed step by step examples of how to configure DNS servers to provide greater security and functionality and how to configure a server publishing rule to make DNS servers available to external clients for name resolution and zone transfers.

This chapter provides information on configuring a DNS infrastructure to support intranet and extranet deployments of SharePoint Portal Server. The chapter begins with an overview of the need for DNS name resolution and the common threats specific to the DNS service. It then discusses situations in which it desirable to implement a split DNS infrastructure to ensure proper name resolution when a resource has to be accessible through either an internal or external IP address depending on the location of the client. Finally, the chapter provides step-by-step instructions for configuring a split DNS infrastructure that has a fairly high degree of security and availability.

In general, the steps for creating a split DNS infrastructure are as follows:

· Setting up authoritative DNS servers for the intranet and extranet access.

· Configuring DNS servers to resist common DNS threats

· Configuring ISA Server 2000 Server Publishing rules to protect and to provide appropriate access for DNS queries and zone transfers.

DNS Overview

Efficient and correct name resolution is critical for the smooth operation of your network. Weak or incorrect name resolution is the source of many difficulties that are sometimes very hard to troubleshoot. Some of the problems caused by weak name resolution include inability to locate resources (including domain controllers), excessive waits to connect to resources, time-outs, and so on.

One of the requirements of SharePoint Portal Server 2003 is that it must be running on a member server of a Windows domain. If the domain is a Windows 2000 or Windows 2003 domain, a DNS infrastructure to perform name resolution for internal clients is already in place. However, you will need to implement a DNS infrastructure to allow external clients to connect to extranet resources if you plan to make a SharePoint or other server, such as Exchange, available to extranet clients. Also, your DNS infrastructure has to support external name resolution if you plan to allow internal clients and computers access to Internet resources.

There are many different DNS infrastructures topologies that can be implemented to support internal, external, and extranet name resolution. These topologies will be dependent to some extent on DNS namespace design, the presence of ISA Server 2000, and the configuration of ISA Server clients (Web proxy, Firewall client, and SecureNAT clients). Furthermore, the configuration of the ISA Server 2000 firewall may determine the need for a particular kind of design infrastructure DNS. For example, RPC publishing for external Outlook clients that you create a split DNS infrastructure.

IDNS services are often a prime target of malicious users. Threats that are specific to DNS services include the following:

· Footprinting.
This is a process where a malicious user gains access to internal DNS records. The hacker can infer information about the organization because server resources are often given names that indicate their function. For example, if the organization has set up servers to test products under development and the servers are named after these products, the user can infer confidential information. The hacker can also use internal DNS records as a starting point for launching data modification attacks using spoofed IP addresses.

· Redirection Attacks.
This kind of attack occurs when a hacker is able to modify DNS records (either resource records in the DNS zone file itself or information stored in the DNS cache) and redirect traffic to inappropriate servers. A redirection attack can form the basis for a Denial of Service (DoS) attack, data modification, or other attacks.

· Denial of Service (DoS) Attacks.
A DoS attack causes network resources to be unavailable. A DoS attack can be in-band or out-of-band. An in-band DoS attack leverages the DNS service and protocols. For example, a DNS server could be flooded with so many illegitimate DNS queries that it can not respond to legitimate queries. A buffer overflow attack can be launched against the DNS server using the DNS application layer protocols. An out-of-band attack occurs when an attack against the DNS server does not use the server’s application layer protocol to disable the server. An example of such an attack would a SYN attack, which is not specifically targeted at the DNS service but still can disable the DNS server computer.

It is possible to enable a DNS application filter to protect DNS servers against some of these threats when DNS services are published through an ISA Server 2000 firewall. In particular, the DNS application filter protects published DNS servers against DNS buffer overflow attacks. The DNS application filter can not protect DNS servers against DNS redirection attacks, such as a cache pollution attack, or footprinting attacks. Protection against these types of attacks occurs through appropriate DNS namespace design, DNS infrastructure design, DNS server configuration, and ISA Server configuration.

In general, a secure DNS infrastructure design shares some or all of the following characteristics:

· Any DNS traffic entering or leaving the internal network is tightly controlled through a combination of strictly enforced rules on the ISA Server 2000 firewall (Server Publishing rules, packet filter configuration, Protocol Rules, client address sets, and so on) and DNS server configuration (for example. the use of forwarders, root hints, and so on).

· No external clients are allowed to query DNS servers that are authoritative for internal zones containing internal resource records.

· Internal clients are not allowed to directly query DNS servers on the Internet for external name resolution.

· Where possible, the ISA Server 2000 firewall performs external DNS name resolution on behalf of Web proxy and Firewall clients.

· There is no single point of DNS failure. For example, Internet-facing DNS servers used for extranet name resolution are distributed across multiple subnets that are served by different devices.

· DNS servers configured to provide name resolution for extranet resources respond to queries from external clients only for extranet resources and no others. (recursion is disabled on the DNS server so that it answers only for name in domains for which the server is authoritative)

· Dynamic DNS (DDNS) updates are disabled on all Internet-facing DNS servers.

· Zone transfer traffic from master DNS servers to secondary (slave) DNS servers is strictly limited to a pre-defined list of DNS servers through both the DNS server and firewall configuration.

· All DNS servers are hardened against cache pollution attacks.

· External and internal DNS resource records are not hosted on the same DNS server.

This list serves as a starting point for thinking about designing a DNS infrastructure in combination with ISA Server 2000 and is by no means complete. Other measures may need to be taken In high security environments. For example, it may be necessary to remove the default root hints files or install a root (.) zone on all internal DNS servers to prevent name resolution on the Internet.

It is not possible to meet these needs with a single DNS server. Multiple DNS servers are required to implement a secure and fault tolerant DNS infrastructure. Ideally, these DNS servers will have dedicated and narrowly defined roles.

For example, internal Web proxy or Firewall client computers can be configured to use internal DNS servers for internal name resolution. They will not be configured to query DNS servers that are capable of providing name resolution for Internet resources. When these clients attempt to connect to Internet resources using the Web proxy or Firewall service, the ISA Server 2000 firewall contacts a DNS server to perform Internet name resolution on behalf of the clients.

The Need for a Split DNS Infrastructure

The DNS namespace used for internal name resolution and Active Directory should be based on a domain name that is unique and registered for the organization’s exclusive use. The name of the internal network domain an be the same or different from the domain name used by external users to access resources located on the internal network.

For example, if the registered namespace is example.com, the internal namespace could be something like example.corp. Or the internal namespace could be contiguous with the name publicly accessible namespace, for instance, AD.example.com. In addition, the namespace used for both internal and external name resolution can be the same.

Some people prefer using different names for internal and external domains. This is the perspective of those who look at the problem from the single vantage point of DNS security. A DNS suffix like .corp can not be resolved accessed by external network clients because it is not a publicly available top level domain name.

However, whatever security advantages that may be gained by this DNS design are mitigated by the complications and user dissatisfaction you’ll encounter when using different domain names for internal and external network resources.

For example, employees must remember two different FQDNs. One of the domain names must be used when they access internal network resources from remote locations and the second domain name is used when users are directly connected to the corporate network.

Imagine a scenario in which an extranet SharePoint Web Site is set up exclusive use of external clients. When internal network clients try to connect to the server using the external FQDN of the extranet Web site, the DNS query resolves the name to the external IP address of the published Web site on the ISA Server 2000 firewall, the connection attempt will fail depending on the type of client.

If the connection request is from a Web Proxy or Firewall client, the request will be loop back through the proxy or firewall services. But, if the connection attempt is from a SecureNAT client, the connection will fail because the client is expecting a response from the Web server, not the ISA Server 2000 firewall. Another significant problem is that resources are needlessly consumed on the ISA Server 2000 firewall when internal network clients loop back through the external interface of the firewall to access internal network resources.

Another source of difficulty arises when you try to use secure Exchange RPC publishing to allow external full MAPI Outlook clients to connect to an internal Exchange Server. These clients must use DNS name resolution to resolve the host name for the Exchange Server to the external IP address of the ISA Server 2000 firewall.

For example, the Exchange Server’s internal FQDN is exchange.example.com. When an Outlook client makes an initial RPC connection to the Exchange Server, the client resolves the name and places the host portion of the name (EXCHANGE, in the example) in the Outlook configuration dialog box. Using different internal and external domain names creates an unsupportable situation for laptop users who move between the internal network and remote locations on a regular basis.

Each time the laptop user connects to the Exchange Server, the laptop computer must be able to access the Exchange Server based on the laptop’s current location. When the user is located on the corporate network, the Outlook client connects directly to the Exchange Server using the internal address of the Exchange Server computer. When the user is located at a remote location, Outlook must connect to the Exchange Server using the IP address on the external interface of the ISA Server 2000 firewall being used by the secure Exchange RPC Publishing Rule. The laptop user could reconfigure a Hosts file entry every time the laptop is moved between locations, but this creates considerable inconvenience for the laptop user and lead to significant user dissatisfaction and reduced productivity.

Solving Remote Access Problems to Microsoft Exchange with a Split DNS Infrastructure

Many organizations find it desirable to implement a split DNS infrastructure to solve the problem of name resolution for users to move between the corporate network and remote locations.

A split DNS infrastructure occurs when two different DNS servers are configured to be authoritative for the same DNS domain namespace. A DNS server is authoritative for a domain name when it contains Resource Records (RRs), for example, the A, NS, MX, CNAME, SOA RRs, for the domain name in a text-based zone file or in Active Directory (when Active Directory Integrated zones are used).

In the split DNS infrastructure, one of these authoritative DNS servers contains RRs for external clients; that is, the zone file used by external network clients contains no RRs used for name resolution on the internal network. The other authoritative DNS server contains RRs for internal network clients; that is, the zone files do not contain RRs that point to the external IP addresses of published resources.

This DNS design eliminates problems of internal clients connecting to internal resources through external interface of the ISA Server 2000 firewall. For example, if an internal network client tries to connect to an internal network server that has been published via a Web or Server Publishing rule and then resolves the server name to the public IP address on the external interface of the ISA Server 2000 firewall, then the client loops back through the external interface of the ISA Server 2000 firewall and the connection attempt will fail. It is critical that internal clients resolve names to internal IP address and external client resolve names to external (public) addresses.

The split DNS infrastructure requires a bit more administrative effort because internal network server resources published through the ISA Server 2000 firewall require RRs in both the internal and external DNS zone files. In addition, this configuration requires multiple physical DNS Servers. For fault tolerance, there should be at least two authoritative DNS servers for both the internal and external zone files. These authoritative servers should be placed on different subnets that are served by different routers to eliminate a single point of failure. For example, an organization could ask its ISP to host authoritative secondary zones of the extranet DNS servers to enhance availability and fault tolerance.

The following section provides details of a possible configuration of a split DNS infrastructure to help ensure DNS security and availability.

Split DNS Infrastructure Topology for DNS Advertisers

A minimum of two DNS servers are required to implement a split DNS infrastructure. Each DNS server is authoritative for the same domain name, but each contains different RRs according to their respective roles as internal or external DNS servers. Both the internal and internal DNS servers are configured as primary DNS servers. As primary DNS servers, they both contain an updatable copy of the zone records. The external DNS server could be placed in a DMZ or be hosted by your ISP or a third party DNS hosting entity. The internal DNS server is placed on the internal network.

Additional DNS servers should be set up as secondary DNS servers to provide for fault tolerance. A secondary DNS server receives a read-only copy of the zone information from a master DNS server (this can be the primary DNS server or another secondary DNS server) through a process known as zone transfer, which occurs over TCP port 53.

Internal network DNS zones can be set up as Active Directory Integrated zones. There are a number of advantages to this zone type over standard zone types. For example, Active Directory methods of replication are used to transfer zone information, and each instance of the Active Directory Integrated zone is updatable. This is in contrast to traditional primary and secondary DNS zones, where only the primary zone file is updatable and the secondary DNS file is read-only. Zone transfer traffic moving between primary and second DNS servers is unencrypted and potentially exposes DNS records to network sniffing attacks.

The primary and secondary (or Active Directory Integrated) DNS Servers on the internal network must never be accessible to external network clients. Strict rules on the ISA Server 2000 firewalls prevent all access to these servers. Internal clients use these DNS servers to resolve names to internal IP addresses.

The primary and secondary DNS Servers in the perimeter network (DMZ) contain the external DNS RRs and are accessible to external clients through strictly enforced firewall rules. The ISA Server 2000 firewall firewall on the corporate network edge and internal network clients never use the external DNS Servers to resolve names. These DNS servers should be configured to resolve queries for the external zone only and should not be able to resolve names contained in other domains for which the DNS server is not authoritative. These servers are configured as DNS Advertisers. This means additional servers configured as DNS Resolvers will be required to provide Internet DNS name resolution for the ISA Server 2000 firewall and possibly internal network clients, depending on the ISA Server and ISA Server client configurations.

Additional secondary DNS servers for the external RRs should be set up in another location to provide fault tolerance. For example, the ISP could provide the locations for the secondary DNS servers. DNS query traffic can be offloaded to the DNS servers at the ISP through the name server information provided to the domain name registrar. For example, DNS resolvers resolve names with specific DNS servers according to the order in which they are registered with domain name registrar. It is not necessary to list the primary DNS server at all with the domain name registrar, as long as at least two DNS can be listed.

The DNS configuration on the primary DNS server allows zone transfers to occur only to a pre-configured list of the IP addresses representing the secondary DNS servers. Rules on the ISA Server 2000 firewall enforce the requirement to allow zone transfers only to the secondary DNS servers at the ISP.

A split DNS infrastructure is represented in the figure below.

Figure 1 Split DNS Infrastructure Topology

Configuration Details for Extranet DNS Advertisers and ISA Server

It is necessary to configure both the DNS server and the ISA Server 2000 firewall appropriately in order to provide enhanced security for the external DNS Servers. For example, cache pollution protection should be enabled on the DNS Server to prevent certain kinds of redirection attacks.

Cache pollution occurs when a DNS server contacts another DNS server to resolve a particular DNS name. The DNS server responds with its authoritative records, but also provides responses for records for domains for which it is not authoritative and for domain namespaces outside of the scope of the initial query.

For example, a DNS server queries another DNS server for the address RR for www.evil-dns.com. The DNS server authoritative for evil-dns.com responds with the record for www.evil-dns.com, and also provides RRs for the other domains, such as microsoft.com or the root level DNS servers, in the reply. The original DNS server places these records in its DNS cache.

If the original DNS server subsequently receives a request for one of these cached records, it will respond with the information from its cache and the user will be redirected to a resource controlled by the evil-dns.com domain instead of the correct location. The DNS server will not cache records outside the scope of the originally requested domain namespace when protection against cache pollution is enabled.

This kind of attack is prevented by ensuring that the DNS Advertiser is not able to resolve Internet names. You can disable Internet name resolution by disabling recursion on the DNS Server. Deleting or renaming the root hints file (%SystemRoot%\system32\dns\cache.dns) also disables the ability to resolve names on the Internet. The DNS server will respond to queries for RRs it is authoritative for (the RRs in its zone files), but send a server failure message back to the DNS resolver when it is queried for RRs it is not authoritative for, when recursion is disabled,.

An additional advantage of disabling recursion is that it also provides protection against DoS attacks that rely on flooding the DNS with bogus DNS queries.

The primary DNS Server should be configured to allow zone transfers to occur only to a pre-configured list of IP addresses. The firewall configuration should complement this requirement by allowing only zone transfer to occur between the extranet DNS server in the DMZ and secondary DNS servers located at the ISP.

The following provides step-by-step instructions for hardening the extranet DNS Server.

Step-by-Step How To: Configuring External DNS Servers and ISA Server 2000 Server Publishing Rules for DNS Service

To provide enhanced security for DNS servers that are authoritative for externally accessible Resource Records, it is necessary to do the following:

Configure Advertising-only DNS Severs

Disable dynamic updates (if necessary) on all external DNS Servers
Disable recursion on all external DNS Servers
Enable protection against cache pollution on all external DNS Servers.
Remove the root hints on all external DNS Servers
Configure the primary DNS server to allow zone transfers to a pre-determined list of IP addresses

Configure the ISA Server 2000 firewall to restrict inbound and outbound DNS traffic

Configure server publishing rule for DNS queries from all external clients
Configure server publishing rule to allow zone transfers to only external secondary DNS servers located at ISP or other hosting service.

Configuring the External DNS Advertisers

To configure a DNS Server as an Advertising-only DNS Server (that is, one that responds only to queries for zones for which it is authoritative),

On the taskbar of the primary DNS server, click Start, point to Programs | Administrative Tools, and click DNS.

In the DNS console, right click on the DNS server name and click Properties.

Figure 2 DNS MMC Console

In the <Name-of-DNS-Server> Properties dialog box, click on the Advanced tab, verify that the check box for Secure cache against pollution is selected (this is a default setting), and place a checkmark in the on the check box to Disable recursion (also disables forwarders).

Figure 3 DNS Properties Advanced Tab

At this point, you can remove the root hints file to further prevent the possibility that the DNS server can resolve Internet names. There are a number of ways to do this. However, the most expedient method is to remove them using the DNS MMC Management console.

Click on the Root Hints tab of the Properties page, click the Remove button multiple times until all the entries are removed, and click OK. (Alternatively, you can delete or rename the %SystemRoot%\system32\dns\cache.dns file.)

Figure 4 Root Hints Page

The above steps should be performed on all the DNS servers that will resolve queries for the domain namespace.

The next step is to restrict DNS zone transfers to a pre-determined list of IP addresses. The next set of steps can only be performed on the master DNS server (a secondary DNS server can also be a master DNS server to another secondary DNS server). To restrict zone transfers to a list of secondary DNS servers,

Open the DNS console, expand the server node, expand the Forward Lookup Zones node, right click on <Name-of-domain> folder, and click Properties.

Figure 5 Accessing Properties of DNS Zone

The <Name-of-domain> Properties dialog box appears as in the figure below.

Figure 6 General Tab of Zone Properties

On the General tab, verify that the zone type is set to Primary and that Dynamic Updates is set to None.

Click on the Zone Transfers tab, select the check box to Allow zone transfers, select the option to allow zone transfers Only to the following IP addresses, enter the IP address of the secondary DNS servers, and click Add after entering each IP address.

Figure 7 Zone Transfers Tab

If you wish to optimize zone transfers to secondary servers, you can specify the IP addresses of the DNS servers by clicking on the Notify tab. When this setting is configured, the master DNS server notifies the list of secondary DNS servers whenever a change occurs in the zone file. Otherwise, zone transfers occur according to the interval specified in the Start of Authority (SOA) Resource Record.

Note:
Active Directory Integrated zones do not use standard zone transfer mechanisms to synchronize DNS records. Instead, Active Directory replication is responsible for synchronizing zone records across Active Directory Integrated zones. Because of this, the notify setting should never list IP addresses of domain controllers containing Active Directory Integrated zones as this may in fact degrade performance.

Configuring Server Publishing Rules for DNS Advertisers on ISA Server

Once the DNS Advertisers are properly configured to mitigate common threats, it is necessary to create a Server Publishing rule to allow external users to query the DNS server through the ISA Server 2000 firewall. Setting up this Server Publishing rule is straightforward because ISA Server 2000 has a pre-configured protocol definition for DNS queries (UDP Port 53) and because we want to allow this protocol inbound from all external clients.

Another server publishing rule is needed to allow only the external secondary servers to transfer zone information from the master DNS if externally located secondary DNS servers have also been configured at an ISP or DNS hosting provider. As with DNS queries, ISA Server 2000 is pre-configured with a protocol definition for DNS zone transfers (TCP Port 53). However, since it is desirable to allow only a strictly limited list of external secondary servers to communicate with the internal DNS server to transfer zone information, it is also necessary to create a client address set to use with the server publishing rule.

Note:
If you are also controlling outbound access through ISA Server 2000 Protocol Rules or packet filters, and you have configured the DNS server to notify external secondary servers whenever there are changes to the zone information, you will have to configure the ISA Server 2000 firewall so that the master DNS server(s) can send DNS notification messages to the external secondary servers.

The following steps show you how to configure server publishing rules for DNS queries and zone transfers. ISA Server 2000 comes pre-configured with a DNS intrusion detection application filter to protect against a number of DNS attacks. Before creating the server publishing rule for the DNS server, it is a good idea to check that this filter is enabled and is configured appropriately.

Verifying DNS Intrusion Detection Application Filter

To verify that the DNS application filter is enabled and to view its properties,

Open the ISA Management console, expand the Servers and Arrays node and then expand your server name. Expand the Extensions node, and click on Application Filters. The list of installed application filters appears in the contents pane of the console. A red down arrow indicates that the filter is disabled.
If the filter is disabled, right click on the DNS intrusion detection filter, and click Enable.

To view the properties of the filter, right click on the DNS intrusion detection filter, and click Properties from the context menu, as in the figure below.

Figure 8 DNS Intrusion Detection Filter

In the DNS Intrusion Detection Filter Properties page, click on the Attacks tab, as in the figure below.

Figure 9 Attacks Tab of DNS Intrusion Detection Filter

Click OK to close the property pages for the application filter.

Creating Client Address Set for DNS Zone Transfer Server Publishing Rule

After verifying that the DNS application filter is enabled, the next step is to create the Server Publishing rules. However, because we want to limit zone transfer traffic to specific external DNS server, the first step is to create a client address set for the external DNS servers. (It is also possible to create a client address set during the creation of the server publishing rule.)

To create a client address set,

Open the ISA Management MMC console, expand the Policy Elements node, right click on Client Address Sets, and select New from the context menu, as in the figure below.

Figure 10 Creating New Client Address Set

In the Client Sets page, enter a descriptive name in the Name text box, and then click the Add button to add the IP addresses of the external secondary DNS servers.

Figure 11 Adding IP Addresses to Client Address Set

If the addresses of the remote clients form a contiguous range of IP addresses, enter the range in the From and To boxes and click OK. If the addresses of the remote clients do not form a contiguous range, enter the same IP address in the From and To boxes, and click OK; then, repeat these steps for each non-contiguous IP address.
When finished adding IP address, click OK on the Client Set page to complete the process of creating the client address set.

Creating Server Publishing Rules for DNS Queries and Zone Transfers

Once you have created the client address set, you can create a server publishing rule to allow zone transfers to external secondary DNS Servers. A similar procedure can be used to create the server publishing rule for DNS queries from external clients.

To create the server publishing rules,

Open the ISA Management console, expand the Publishing node, right click on Server Publishing Rules, and select New | Rule from the context menu, as in the figure below.

Figure 12 Creating New Server Publishing Rule

2. In the Welcome to the New Server Publishing Rule Wizard page, enter a descriptive name in the Server publishing rule text box, and click Next to proceed to the Address Mapping page.

Figure 13 Address Mapping Page

In the Address Mapping page, enter the internal IP address of the Web site and the external IP address on the ISA Server, and click Next. The external IP address you select here must be one that is registered with the domain name registrar as a location of a name server for the domain.

Note:
If you have only one external IP address, you will only be able to publish a particular service one time. For example, you can have a single server publishing rule for TCP Port 53 inbound (zone transfers) and another server publishing rule for UPD Port 53 inbound (DNS queries). However, you can enhance fault tolerance by configuring Windows Network Load Balancing on multiple internal DNS Servers and publish the single NLB address.

In the Protocol Settings page, select the DNS protocol you wish to publish, either DNS Query Server or DNS Zone Transfer Server as in the figure below, and click Next.

Figure 14 Protocol Settings Page

After you specify the protocol, the Client Type page appears which allows you to specify whether the rule applies to any request or a request from a specific client address set. Depending on whether or not you are creating a server publishing rule for DNS zone transfer or DNS queries will determine the next set of steps.

If you are creating a Server Publishing rule for DNS queries, select Any request on this page and complete the Server Publishing wizard. However, if you are creating a Server Publishing rule for DNS zone transfers, you use the client address set you configured in the previous steps.

The steps for configuring a server publishing rule for DNS zone transfers using a client address set are as follows:

In the Client Type page, select Specific computers (client address sets), and click Next, as in the figure below.

Figure