Planning for DirectAccess clients and the network location server

Internal clients must be able to resolve the FQDN of the network location server so that they can determine that they are located on the internal network. Conversely, the FQDN of the network location servers should not be resolvable for DirectAccess clients located on the Internet. To ensure this does not happen, by default the FQDN of the network location server is added as an exemption rule to the NRPT, so that when DirectAccess client computers attempt to resolve the FQDN of the network location server, the request matches the exemption rule and the name is not resolved via the DirectAccess server.

Planning NRPT

When you run the DirectAccess Deployment Wizard, the following rules are created automaticallyIn 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:

1. 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.
   
   
2. 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 plan for additional NRPT rules in the following cases:

1. You need to add more DNS suffixes for your intranet namespace.
   
   
2. 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.
   
   
3. 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.
   
   
4. 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 uses the addresses of your Web proxy servers to permit the inbound requests. In this case, 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.
   
   

Planning for CRL revocation points

After setting up CAs and CRL distribution points, ensure that the FQDN for your Internet-accessible CRL distribution points are resolvable using Internet DNS servers. For example, if URL http://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.

Planning for IP-HTTPS and other transition technologies

Forefront UAG DirectAccess 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), Forefront UAG DirectAccess configures https://SubjectName:443/IPHTTPS, which is the subject name property of the HTTPS certificate used for IP-HTTPS. If the Subject Name property of the IP-HTTPS certificate is an FQDN, ensure that the FQDN is resolvable using Internet DNS servers. In addition, 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.

Planning ISATAP

The Forefront UAG DirectAccess server automatically configures itself as an ISATAP router. To use ISATAP, DNS servers must be configured to answer ISATAP queries. 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, and 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. For more information, see Remove ISATAP from the DNS Global Query Block List (http://go.microsoft.com/fwlink/?LinkId=168593).

Planning for DNS servers that do not perform DNS dynamic updates

When intranet servers initiate communications to a DirectAccess client on the Internet, the server must be able to determine the IP address of the remote client. This requires the DirectAccess client to register its FQDN and Ipv6 address in internal DNS server. The client can register its Ipv6 address dynamically if dynamic DNS updates are enabled, and the DNS server supports AAAA records.The host initiating the connection must be able to determine the IP address of the remote DirectAccess client. This means that the remote DirectAccess client must register its FQDN and IPv6 address in the internal DNS servers. When using ISATAP, 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. 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.

Planning for single label names

Single label names, such as http://paycheck, are sometimes used for intranet servers. If a single-label name is requested, a DNS suffix is appended to make an FQDN. By default the appended suffix is based on the DirectAccess client domain. If a DNS suffix search list is configured, those DNS suffixes will be appended to the name. For example, when a user on a computer that is a member of the corp.contoso.com domain types http://paycheck in the Web browser, Windows constructs the name paycheck.corp.contoso.com as the FQDN.

To ensure that 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:

• 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 (http://go.microsoft.com/fwlink/?LinkId=169418).
  
  
• Adding a DNS suffix, for example dns.zone1.corp.contoso.com, to the default domain policy GPO.
  
  

Planning for split brain DNS

• Split-brain DNS is the use of the same DNS domain for both Internet and intranet name resolution.
  
  Example
  
  For example, Contoso Corporation uses split brain DNS. Internet users type in http://www.contoso.com to access Contoso’s public Web site, and Contoso employees type in http://www.contoso.com to access Contoso’s intranet Web site.
  
  
  • A Contoso employee (using a non-DirectAccess laptop on the intranet, types in http://www.contoso.com and sees the intranet Contoso Web site.
    
    
  • The same employee types in the same URL when located on the Internet reaches the public Contoso Web site.
    
    
  When a DirectAccess client is on the Internet, the 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 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 a URL (such as http://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.