Designing the DNS Infrastructure for DirectAccess

TechNet Library
Windows Server
Windows Server R2 und Windows Server 2008
Browse Windows Server Technologies
Networking
DirectAccess
DirectAccess for Windows Server R2
DirectAccess Design Guide
DirectAccess Deployment Strategy Planning
DirectAccess available resources for clients
Select Intranet IPv6 Connection Design
Select a solution for IPV4-only Intranet resources
Select Access model
Choosing a Configuration method
Remote Management design
Design for Intranet server availability before users log on
Design packet filtering for DirectAccess
Choose an authentication and authorization scheme
Design addressing and routing for DirectAccess servers
Active Directory designed for DirectAccess
Designing the DNS Infrastructure for DirectAccess
Designing a PKI for DirectAccess
Designing a WEB server for DirectAccess
Select Internet Communication Separation Design
Design protection for communication between DirectAccess clients
Designing an Intranet for enterprise connectivity detection
Choose DirectAccess and VPN coexistence design
Using the DirectAccess Connection Assistant (DCA)
Expand
Designing the DNS Infrastructure for DirectAccess

Update Time: October 2009
Apply to: Windows 7, Windows Server R2
Important Important matters
This topic describes the design considerations for DirectAccess in Windows Server R2. For information about DirectAccess design considerations in Microsoft Forefront Unified Access Gateway (UAG), see the Forefront UAG DirectAccess Design Guide (http://g o.microsoft.com/fwlink/? linkid=179988) (may be in English pages).
The design of the domain Name System (DNS) infrastructure affects how DirectAccess is configured. The most important aspect of the DNS infrastructure design is whether you use split-fraction DNS.
Split-Fraction DNS
Split-fraction DNS refers to the use of the same DNS domain for Internet and Intranet resources. For example, Contoso uses a domain name that splits dns;intranet resources and Internet resources to be contoso.com. Internet users use http://www.contoso.com to access Contoso's public Web site, and Contoso employees on the Contoso Intranet also use http://www.contoso.com to access Contos O's Intranet site. If the Contoso employee accesses http://www.contoso.com on the intranet using a non-DirectAccess client portable computer, the Contoso intranet site is displayed. If they take their laptops to a local coffee shop and access the same URL, the Contoso public website is displayed.
When the DirectAccess client is on the Internet, the Name resolution Policy table (NRPT) sends a DNS name query to the intranet resource to the intranet DNS server. Typical NRPT for DirectAccess will contain the organization's namespace rules (for example, contoso.com for Contoso) and the Internet Protocol version 6 (IPV6) address of the Intranet DNS server. It is because of this rule in NRPT that the Intranet version is displayed when DirectAccess client users on the Internet try to access a Uniform Resource Locator (URL) for their web site, such as http://www.contoso.com. As a result, they will never see a public version of this URL when they are on the Internet.
If you want users on the DirectAccess client to see a public version of this URL when they are on the Internet, you must add the fully qualified domain name (FQDN) of this URL as an exemption rule to the NRPT of the DirectAccess client. However, if you add this exemption rule, they will never see the Intranet version of this URL when users on the DirectAccess client are on the Internet.
For split-fractional DNS deployments, you must list the duplicate FQDNs on the Internet and the intranet and determine whether the DirectAccess client should access the Intranet version or the public (Internet) version of the resource. For each name of the public version resource that you want DirectAccess client access to, you must add the appropriate FQDN as an exemption rule to the NRPT of the DirectAccess client.
In a split-fractional DNS environment, if you want to use two versions of resources, configure the Intranet resource with an alternate name that is not duplicated with the name that is used on the Internet, and instruct the user to use this alternate name when they are on the Intranet. For example, configure and use the alternate name www.internal.contoso.com to represent the Intranet name www.contoso.com.
In a non-split DNS environment, the Internet namespace differs from the Intranet namespace. For example, Contoso uses contoso.com on the Internet to use corp.contoso.com on the Intranet. Because all intranet resources use the corp.contoso.com DNS suffix, corp.contoso.com's NRPT rule routes all DNS name queries for intranet resources to the intranet DNS server 。 DNS name queries with names with the contoso.com suffix do not match the corp.contoso.com Intranet namespace rules in NRPT, so these queries are sent to the Internet DNS server.
For non-split DNS deployments, no additional configuration is required for NRPT because the FQDN of the Intranet and Internet resources are not duplicated. DirectAccess clients can access their organization's Internet and Intranet resources.
Note Notes
DirectAccess test Lab (http://go.microsoft.com/fwlink/? linkid=150613) use contoso.com on the analog Internet to use corp.contoso.com on the emulated Intranet.
DNS Server Requirements for ISATAP
If you establish an IPV6 connection on the intranet using the in-Station Automatic Tunneling Protocol (ISATAP), the following items must be used for the intranet DNS server used by DirectAccess clients:
Run Windows Server R2, with Q958194 hotfixes (http://go.microsoft.com/fwlink/? linkid=159951) for Windows Server 2008 or for Windows Server SP2 or a later version of DNS server. The DNS Server service in these versions of Windows supports processing DNS traffic on the ISATAP interface.

A non-Microsoft DNS server that can handle DNS traffic on the ISATAP interface.

By default, the DNS Server service in Windows Server 2008 and later releases the DNS Global query block list to block name resolution for name ISATAP. To use ISATAP on an Intranet, you must remove the ISATAP name from the list of all DNS servers that are running Windows Server 2008 and later. For more information, see Removing ISATAP from the DNS Global query block list in the DirectAccess Deployment Guide.
AAAA records for servers that do not perform DNS dynamic updates
for servers running non-Windows operating systems that support IPV6 (DNS dynamic updates that do not support IPV6 addresses), manually add the names of these servers and AAAA records for IPV6 addresses.
DirectAccess Client Local name resolution behavior
If DNS cannot be used to resolve names, the DNS Client service in Windows 7 and Windows Server R2 can use local name resolution, link local Multicast name resolution (LL MNR) and the NetBIOS protocol on TCP/IP to resolve the corresponding name on the local subnet.
When a computer is on a private network, such as a single subnet home network, the peering connection usually needs to use local name resolution. If the DNS Client service performs local name resolution on the intranet server name and the computer is connected to a shared subnet on the Internet, a malicious user can capture NetBIOS messages on LLMNR and TCP/IP to determine the Intranet server name.
in step 3 of the DirectAccess Setup Wizard, you can configure local name resolution behavior based on the type of response received from the Intranet DNS server. You have the following options:
Use local name resolution only if the internal network DNS server determines that the name does not exist

This option is the most secure because the DirectAccess client performs local name resolution only on server names that cannot be resolved by the Intranet DNS server. If the intranet DNS server cannot be accessed, the name of the intranet server is resolved. If you cannot access the intranet DNS server or there are other types of DNS errors, the intranet server name is not leaked to the subnet through local name resolution.

Use local name resolution if the internal network DNS server determines that the name does not exist, or if the internal network DNS server is inaccessible and the DirectAccess client computer is on a private network

This option allows you to use local name resolution on the private network when you cannot access the Intranet DNS server, so the security for this option is medium.

Use local name resolution regardless of what error is returned when attempting to resolve names through the internal network DNS server

Because the name of the Intranet network server can be leaked to the local subnet through local name resolution, this option is the least secure.

Select the option that meets your security requirements.
NRPT rules
In step 3 of the DirectAccess Setup Wizard, you can configure the rules in NRPT, the internal table that the DNS Client service uses to determine the destination of the DNS name query to send. The DirectAccess Setup Wizard automatically creates two rules for DirectAccess clients:
The domain name of the DirectAccess server and the namespace rule for the IPV6 address that corresponds to the Intranet DNS server 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.

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

You may need to configure additional NRPT rules in step 3 of the DirectAccess Setup Wizard in the following situations:
You need to add more DNS suffix namespace rules for the Intranet namespace.

If the FDQN of the intranet and Internet CRL distribution points are based on the intranet namespace, you must add an exemption rule for the FQDN of the Internet and Intranet CRL distribution points.

If you have a split DNS environment, you must add an exemption rule for its name for resources that you want DirectAccess clients on the Internet to access their public (Internet) version, not the Intranet version.

If you redirect traffic to an external Web site that is accessible only from the intranet through the intranet Web proxy server, and this external Web site allows inbound requests by using the address of the Web proxy server, you must add an exemption rule for the FQDN of this external Web site, and specify that this rule use The intranet Web proxy server, not the IPV6 address of the intranet DNS server.

For example, the Contoso company is testing an external Web site called test.contoso.com. This name cannot be resolved through an Internet DNS server, but Contoso's WEB proxy server knows how to resolve this name and how to direct requests for that site to an external WEB server. To prevent users outside of 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. As a result, Intranet users can access the site because they are using the Contoso Web Proxy, and DirectAccess users cannot access the site because they are not using the Contoso Web Proxy. By configuring NRPT exemption rules for test.contoso.com that use the Contoso Web Proxy, test.contoso.com Web requests are routed through the IPv4 Internet to the Intranet Web proxy server.

You can also configure NRPT rules from the computer Configuration \ policies \ Windows settings \ Name resolution policies in the DirectAccess client's Group Policy object. For more information, see Configuring NRPT with Group Policy in the DirectAccess Deployment Guide.
Note Notes
The maximum number of rules in NRPT is 1000.
If you are configuring namespace rules and the DNS servers are located outside the Intranet, you should use Internet Protocol security (IPSEC) or DNS security extensions (DNSSEC) to protect DNS queries against these servers.
DirectAccess test Lab (http://go.microsoft.com/fwlink/? The DirectAccess Setup Wizard in linkid=150613 creates the following two rules in NRPT: Create a namespace rule for corp.contoso.com that has an IPv6 address for the Intranet DNS server; contoso.com Create an exemption rule. You can view the NRPT rules that are configured by using Group Policy in CLIENT1 by running the Netsh namespace show policy command at a command prompt. You can use the Netsh namespace show effectivepolicy command to view valid NRPT rules.
DNS Server query behavior for DirectAccess clients
The DirectAccess client that contains the active rule in NRPT is configured with two sets of DNS servers, a DNS server in the NRPT namespace rule, and a DNS server that configures the interface. If the FQDN matches the namespace rule, only the DNS server specified in the namespace rule is queried. Even if the DNS server in the matching namespace rule cannot be accessed, the DirectAccess client does not query the DNS server that configures the interface.
The DirectAccess client that contains the active rule in NRPT queries the DNS server that configures the interface only in the following cases:
The FQDN matches the exemption rule.

The FQDN does not match any of the NRPT rules.

Unqualified single-label names and DNS search suffixes
An unqualified single-label name is sometimes used for an Intranet server so that you can specify a single name, for example, Http://paycheck. The DNS Client service uses a DNS suffix search list to group these names together to create a series of FQDNs that can be resolved using DNS. By default, the DNS suffix search list contains the domain name of the computer, and additional DNS suffixes can be added. For example, when a user on a computer that is a member of a corp.contoso.com domain types Http://paycheck in their Web browser, Windows can construct the paycheck.corp.contoso.com name as the FQDN.
Note Notes
Use the Computer Configuration/Administrative Templates/Network/DNS client/DNS Suffix search list Group Policy setting to add a DNS suffix to the DNS suffix search list for client computers joined to the domain.
To ensure that unqualified single-label names can resolve to the same intranet resource, regardless of whether the DirectAccess client is connected to the intranet or the Internet,dns suffix search list should match the namespace rules in NRPT. In general, each DNS suffix for the Intranet namespace should correspond to the namespace rules in NRPT.
Note Notes
If the server name on the local subnet is duplicated with the server name on the intranet, the DirectAccess client always connects to the intranet resource. For example, if a home network server is named Server1 and an intranet server with the same name exists, you will always be connected to the intranet Server1. To connect to a local subnet resource, append ". Local" after the server name. For example, to connect to a local subnet server named Server1, use the name server1.local.
External DNS
The DirectAccess Setup Wizard configures the DirectAccess client with the IPV4 address of the 6to4 relay and uses the Group Policy settings configuration in Computer Configuration \ policies \ Administrative Templates \ network \ TCPIP settings \ IPV6 Conversion Technology Teredo server. For the URL of an Internet protocol (IP-HTTPS) server based on the Secure Hypertext Transfer Protocol (IP-HTTPS status setting), the DirectAccess Setup Wizard configures the https://topic: 443/iphttps, where the subject indicates that you DirectAccess the "Subject" field of the HTTPS certificate specified in step 2 of the Installation Wizard. If the subject field of the Ip-https certificate is FQDN, you must ensure that the FQDN can be resolved by using an Internet DNS server.
If you modify the 6to4 relay name or the Teredo server name Group Policy setting to use the FQDN instead of the IPV4 address, you must ensure that the appropriate FQDN can be resolved by using an Internet DNS server.
In addition, you must ensure that you can use an Internet DNS server to resolve the FQDN of a certificate revocation list (CRL) distribution point that can access the Internet. For example, if the CRL distribution point for the IP-HTTPS Certificate of the DirectAccess server is a URL http://crl.contoso.com/crld/corp-DC1-CA.crl, you must make sure that you can use the Internet DNS The server resolves the FQDN crl.contoso.com.
Community Additional Resources

Designing the DNS Infrastructure for DirectAccess