Design Your DNS Infrastructure for DirectAccess

Applies To: Windows 7, Windows Server 2008 R2

The design of your Domain Name System (DNS) infrastructure can impact how you configure DirectAccess. The biggest design aspect of your DNS infrastructure is whether you use split-brain DNS.

Split-brain DNS

Split-brain DNS is the use of the same DNS domain for both Internet and intranet resources. For example, the Contoso Corporation is using split brain DNS; contoso.com is the domain name for intranet resources and Internet resources. Internet users use https://www.contoso.com to access Contoso’s public Web site and Contoso employees on the Contoso intranet use https://www.contoso.com to access Contoso’s intranet Web site. A Contoso employee with their laptop that is not a DirectAccess client on the intranet that accesses https://www.contoso.com sees the intranet Contoso Web site. When they take their laptop to the local coffee shop and access that same URL, they will see the public Contoso Web site.

When a DirectAccess client is on the Internet, the Name Resolution Policy Table (NRPT) sends DNS name queries for intranet resources to intranet DNS servers. A typical NRPT for DirectAccess will have a rule for the namespace of the organization, such as contoso.com for the Contoso Corporation, with the Internet Protocol version 6 (IPv6) addresses of intranet DNS servers. With just this rule in the NRPT, when a user on a DirectAccess client on the Internet attempts to access the uniform resource locator (URL) for their Web site (such as https://www.contoso.com), they will see the intranet version. Because of this rule, they will never see the public version of this URL when they are on the Internet.

If you want users on DirectAccess clients to see the public version of this URL when they are on the Internet, you must add the fully qualified domain name (FQDN) of the URL as an exemption rule to the NRPT of DirectAccess clients. However, if you add this exemption rule, users on DirectAccess clients will never see the intranet version of this URL when they are on the Internet.

For split-brain DNS deployments, you must list the FQDNs that are duplicated on the Internet and intranet and decide which resources the DirectAccess client should reach, the intranet version or the public (Internet) version. For each name that corresponds to a resource for which you want DirectAccess clients to reach the public version, you must add the corresponding FQDN as an exemption rule to the NRPT for your DirectAccess clients.

In a split-brain DNS environment, if you want both versions of the resource to be available, configure your intranet resources with alternate names that are not duplicates of the names that are being used on the Internet and instruct your users to use the alternate name when on the Intranet. For example, configure and use the alternate name www.internal.contoso.com for the intranet name www.contoso.com.

In a non-split-brain DNS environment, the Internet namespace is different from the intranet namespace. For example, the Contoso Corporation uses contoso.com on the Internet and corp.contoso.com on the intranet. Because all intranet resources use the corp.contoso.com DNS suffix, the NRPT rule for corp.contoso.com routes all DNS name queries for intranet resources to intranet DNS servers. DNS name queries for names with the contoso.com suffix do not match the corp.contoso.com intranet namespace rule in the NRPT and are sent to Internet DNS servers.

With a non-split-brain DNS deployment, because there is no duplication of FQDNs for intranet and Internet resources, there is no additional configuration needed for the NRPT. DirectAccess clients can access both Internet and intranet resources for their organization.

DNS server requirements for ISATAP

If you are using Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) for IPv6 connectivity on your intranet, for the intranet DNS servers that are being used by DirectAccess clients, you must use the following:

• DNS servers that run Windows Server 2008 R2, Windows Server 2008 with the Q958194 hotfix (https://go.microsoft.com/fwlink/?LinkId=159951) installed, or Windows Server 2008 with SP2 or later. The DNS Server service in these versions of Windows supports processing DNS traffic on ISATAP interfaces.

• Non-Microsoft DNS servers that are capable of processing DNS traffic on ISATAP interfaces.

By default, the DNS Server service in Windows Server 2008 and later blocks name resolution for the name ISATAP through the DNS Global Query Block List. To use ISATAP on your intranet, you must remove the ISATAP name from the list for all DNS servers running Windows Server 2008 and later. For more information, see Remove ISATAP from the DNS Global Query Block List in the DirectAccess Deployment Guide.

AAAA records for servers that do not perform DNS dynamic update

For servers running IPv6-capable non-Windows operating systems that do not support DNS dynamic update for IPv6 addresses, manually add AAAA records for the names and IPv6 addresses of these servers.

Local name resolution behavior for DirectAccess clients

If a name cannot be resolved with DNS, the DNS Client service in Windows 7 and Windows Server 2008 R2 can use local name resolution, with the Link-Local Multicast Name Resolution (LLMNR) and NetBIOS over TCP/IP protocols, to resolve the name on the local subnet.

Local name resolution is typically needed for peer-to-peer connectivity when the computer is located on private networks, such as single subnet home networks. When the DNS Client service performs local name resolution for intranet server names and the computer is connected to a shared subnet on the Internet, malicious users can capture LLMNR and NetBIOS over TCP/IP messages to determine intranet server names.

In Step 3 of the DirectAccess Setup Wizard, you configure the local name resolution behavior based on the types of responses received from intranet DNS servers. You have the following options:

• Use local name resolution only if the internal network DNS servers determined that the name does not exist

  This option is the most secure because the DirectAccess client will only perform local name resolution for server names that cannot be resolved by intranet DNS servers. If the intranet DNS servers can be reached, the names of intranet servers will be resolved. If the intranet DNS servers cannot be reached or if there are other types of DNS errors, the intranet server names will not be leaked to the subnet through local name resolution.

• Use local name resolution if the internal network DNS servers determined that the name does not exist or if the internal network DNS servers are not reachable and the DirectAccess client computer is on a private network

  This option is moderately secure because it allows the use of local name resolution on a private network when the intranet DNS servers are unreachable.

• Use local name resolution if there is any type of error when attempting to resolve the name using internal network DNS servers

  This is the least secure option because the names of intranet network servers can be leaked to the local subnet through local name resolution.

Choose the option that complies with your security requirements.

NRPT rules

In step 3 of the DirectAccess Setup Wizard, you configure the rules in the NRPT, an internal table used by the DNS Client service to determine where to send DNS name queries. The DirectAccess Setup Wizard automatically creates two rules for DirectAccess clients:

• A namespace rule for the domain name of the DirectAccess server and the IPv6 addresses corresponding to the intranet DNS servers configured on the DirectAccess server. For example, if the DirectAccess server is a member of the corp.contoso.com domain, the DirectAccess Setup Wizard creates a namespace rule for the .corp.contoso.com DNS suffix.

• An exemption rule for the FQDN of the network location server. For example, if the network location server URL is https://nls.corp.contoso.com, the DirectAccess Setup Wizard creates an exemption rule for the FQDN nls.corp.contoso.com.

You might need to configure additional NRPT rules in step 3 of the DirectAccess Setup Wizard in the following cases:

• You need to add more namespace rules for the DNS suffixes for your intranet namespace.

• If the FDQN of your intranet and Internet CRL distribution points are based on your intranet namespace, you must add exemption rules for the FQDNs of your Internet and intranet CRL distribution points.

• If you have a split-brain DNS environment, you must add exemption rules for the names of resources for which you want DirectAccess clients located on the Internet to access the public (Internet) version, rather than the intranet version.

• If you are redirecting traffic to an external Web site through your intranet Web proxy servers, the external Web site is only available from the intranet, and the external Web site is using the addresses of your Web proxy servers to permit the inbound requests, then you must add an exemption rule for the FQDN of the external Web site and specify that the rule use your intranet Web proxy server, rather than the IPv6 addresses of intranet DNS servers.

  For example, the Contoso Corporation is testing an external Web site named test.contoso.com. This name is not resolvable via Internet DNS servers, but Contoso’s Web proxy server knows how to resolve the name and to direct requests for the Web site to the external Web server. To prevent users who are not on the Contoso intranet from accessing the site, the external Web site only allows requests from the Internet Protocol version 4 (IPv4) Internet address of the Contoso Web proxy. Therefore, intranet users can access the Web site because they are using the Contoso Web proxy but DirectAccess users cannot because they are not using the Contoso Web proxy. By configuring an NRPT exemption rule for test.contoso.com that uses the Contoso Web proxy, Web page requests for test.contoso.com will be routed to the intranet Web proxy server over the IPv4 Internet.

You can also configure NRPT rules from Computer Configuration\Policies\Windows Settings\Name Resolution Policy in the Group Policy object for DirectAccess clients. For more information, see Configure the NRPT with Group Policy in the DirectAccess Deployment Guide.

DNS server querying behavior for DirectAccess clients

A DirectAccess client with active rules in the NRPT is configured with two sets of DNS servers; the DNS servers in the namespace rules of the NRPT and interface-configured DNS servers. If an FQDN matches a namespace rule, only the DNS servers specified in the namespace rule are queried. Even if the DNS servers in the matching namespace rule are not reachable, the DirectAccess client does not query the interface-configured DNS servers.

A DirectAccess client with active rules in the NRPT will only query interface-configured DNS servers in the following cases:

• The FQDN matches an exemption rule.

• The FQDN does not match any NRPT rules.

Unqualified, single-label names and DNS search suffixes

Unqualified, single-label names are sometimes used for intranet servers so that you can specify a single name, such as https://paycheck. The DNS Client service combines these names with your DNS suffix search list to create a series of FQDNs to resolve with DNS. By default, your computer’s domain name is in the DNS suffix search list and additional DNS suffixes can be added. For example, when a user on a computer that is a member of the corp.contoso.com domain types https://paycheck in their Web browser, Windows constructs the name paycheck.corp.contoso.com as the FQDN.

To ensure that unqualified, single-label names resolve to the same intranet resources whether DirectAccess clients are connected to the intranet or the Internet, your DNS suffix search list should match the namespace rules in your NRPT. As a general rule, each DNS suffix for an intranet namespace should correspond to a namespace rule in your NRPT.

External DNS

The DirectAccess Setup wizard configures DirectAccess clients with the IPv4 addresses of the 6to4 relay and the Teredo server with Group Policy settings in Computer Configuration\Policies\Administrative Templates\Network\TCPIP Settings\IPv6 Transition Technologies. For the URL for the Internet Protocol over Secure Hypertext Transfer Protocol (IP-HTTPS) server (the IP-HTTPS State setting), the DirectAccess Setup Wizard configures https://Subject:443/IPHTTPS, in which Subject is the Subject field of the HTTPS certificate that you specify in Step 2 of the DirectAccess Setup Wizard. If the Subject field of the IP-HTTPS certificate is an FQDN, you must ensure that the FQDN is resolvable using Internet DNS servers.

If you modify the 6to4 Relay Name or Teredo Server Name Group Policy settings to use FQDNs rather than an IPv4 address, you must ensure that the FQDNs are resolvable using Internet DNS servers.

You must also ensure that the FQDNs for your Internet-accessible certificate revocation list (CRL) distribution points are resolvable using Internet DNS servers. For example, if the URL https://crl.contoso.com/crld/corp-DC1-CA.crl is in the CRL Distribution Points field of the IP-HTTPS certificate of the DirectAccess server, you must ensure that the FQDN crl.contoso.com is resolvable using Internet DNS servers.