Designing a DNS infrastructure for Forefront UAG DirectAccess

Updated: June 1, 2010

Applies To: Unified Access Gateway

The design of your DNS infrastructure can impact how you configure Forefront UAG DirectAccess.

The following topics describe how to design your DNS infrastructure:

  • Split-brain DNS

  • DNS server requirements for ISATAP

  • DNS servers that do not perform DNS dynamic update

  • AAAA records for servers that do not perform DNS dynamic update

  • Local name resolution behavior for DirectAccess clients

  • NRPT rules

  • Unqualified, single-label names and DNS search suffixes

  • External 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 uses 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 use https://www.contoso.com to access Contoso’s intranet Web site. A Contoso employee, with a laptop that is not a DirectAccess client on the intranet, who accesses https://www.contoso.com sees the intranet Contoso Web site; when accessing that same URL from the local coffee shop, the public Contoso Web site is seen.

When a DirectAccess client is on the Internet, the Name Resolution Policy Table (NRPT) causes DNS name queries for intranet resources to be sent to the DNS64, which forwards them to the intranet DNS servers. A typical NRPT for Forefront UAG DirectAccess has a rule for the namespace of the organization, such as contoso.com, 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 see the intranet version. Because of this rule, they never see the Internet version of this URL when they are on the Internet. For users on DirectAccess clients to see the Internet version of this URL on the Internet, you must add the fully qualified domain name (FQDN) www.contoso.com as an exemption rule to the NRPT of DirectAccess clients. When you do, users on DirectAccess clients never see the intranet version of this URL.

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 or the Internet version. For each name that corresponds to a resource for which you want DirectAccess clients to reach the Internet 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 used on the Internet, and instruct your users to use the alternate name when on the Intranet. For example, configure the alternate name www.internal.contoso.com for the internal 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

For DirectAccess clients, you must use either at least one DNS server running Windows Server 2003, Windows Server 2008, Windows Servers 2008 R2, or any DNS server that supports IPv6. By default, the DNS server service, blocks name resolution for the name ISATAP through the DNS Global Query Block List. If you are using ISATAP on your intranet, you must remove the ISATAP name from the Query Block List. For more information, see Remove ISATAP from the DNS Global Query Block List (https://go.microsoft.com/fwlink/?LinkId=168593).

You must then manually create an address (A) record for the name ISATAP in the appropriate DNS. For example, for the domain.contoso.com domain, create an A record for isatap.domain.contoso.com, with the internal IPv4 address of the Forefront UAG DirectAccess server. When Forefront UAG DirectAccess is configured in an NLB array, add each array member's internal IPv4 DIP to the ISATAP DNS server record. It is recommended that you make the additions to the ISATAP DNS server record, in the planning stages of the array.

DNS servers that do not perform DNS dynamic update

When performing corporate connectivity detection, a DirectAccess client checks for an entry of the NCSI probe host on a DNS server. If you have DNS servers that do not support dynamic updates, add an AAAA record for the NCSI probe host. If you did not modify the default settings in the configuration export script, the AAAA record is UAGDirectAccess-corpConnectivityHost ::1.

If ISATAP is deployed in your organization, you must manually add an AAAA record for each server that has an ISATAP generated address, so that it will be reachable by a DirectAccess client.

If ISATAP is not deployed in your organization, but NAT64 and DNS64 are, you can use NAT64 and DNS64 to generate IPv6 addresses for your servers, and make them reachable by DirectAccess clients. This is because when the only response the DNS64 receives from the corporate DNS server contains an A record, DNS64 automatically generates an IPv6 address for the server.

A NAT64 and DNS64 solution can also be used when you do not wish to manually add AAAA records for each server with an ISATAP generated IPv6 address. There is however performance degradation when using NAT64 and DNS64.

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 the DNS suffixes page of the Forefront UAG DirectAccess Configuration Wizard, you configure the local name resolution behavior based on the types of responses received from intranet DNS servers. The following options are available:

  • Only use local name resolution if the name does not exist in DNS—This option is the most secure because the DirectAccess client only performs 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 are resolved. If the intranet DNS servers cannot be reached, or if there are other types of DNS errors, the intranet server names are not leaked to the subnet through local name resolution.

  • Fall back to local name resolution if the name does not exist in DNS or the DNS servers are unreachable when the client computer is on a private network (recommended)—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.

  • Fall back to local name resolution for any kind of DNS resolution error (least secure)—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 the DNS suffixes page of the Forefront UAG DirectAccess Configuration 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 wizard automatically creates two rules for DirectAccess clients:

  • A DNS suffix rule for the domain name of the Forefront UAG DirectAccess server, and the IPv6 addresses corresponding to the intranet DNS servers configured on the Forefront UAG DirectAccess server. For example, if the Forefront UAG DirectAccess server is a member of the corp.contoso.com domain, the Forefront UAG DirectAccess Configuration Wizard creates a 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 Forefront UAG DirectAccess Configuration Wizard creates an exemption rule for the FQDN nls.corp.contoso.com.

You might need to configure additional NRPT rules in DNS suffixes page of the Forefront UAG DirectAccess Configuration Wizard in the following cases:

  • You need to add more 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 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 uses 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 uses 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. Thus, 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 are routed to the intranet Web proxy server over the IPv4 Internet.

    Note

    The maximum number of rules in the NRPT is 1000.

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 the Web browser, Windows constructs the name paycheck.corp.contoso.com as the FQDN.

Note

You can use the Computer Configuration/Administrative Templates/Network/DNS Client/ DNS Suffix Search List Group Policy setting, to add DNS suffixes to the DNS suffix search lists of domain-joined client computers.

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.

If multiple domains and WINS are deployed in your organization and you are connecting remotely, single-names can be resolved by:

  1. Deploying a WINS forward lookup zone in the DNS—When trying to resolve computername.dns.zone1.corp.contoso.com, the request is directed to the WINS server that is only using computername. The client thinks it is issuing a regular DNS A RR request but it is actually a NetBIOS request. For more information see Managing a Forward Lookup Zone (https://go.microsoft.com/fwlink/?LinkId=169418).

  2. Adding a DNS suffix, for example dns.zone1.corp.contoso.com, to the default domain policy GPO.

External DNS

The Forefront UAG DirectAccess Configuration 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 IP-HTTPS server (the IP-HTTPS State setting), the Forefront UAG DirectAccess Configuration Wizard configures https://SubjectName:443/IPHTTPS, where SubjectName is the Subject Name property of the HTTPS certificate that you specify in the Authentication Options page of the Forefront UAG DirectAccess Configuration Wizard. If the Subject Name property 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 FQDN for your Internet-accessible certificate revocation list (CRL) distribution points are resolvable using Internet DNS servers. For example, if URL https://crl.contoso.com/crld/corp-DC1-CA.crl is in the CRL Distribution Points field of the IP-HTTPS certificate of the Forefront UAG DirectAccess server, you must ensure that the FQDN crld.contoso.com is resolvable using Internet DNS servers.