This topic provides information about planning DNS requirements in your Forefront Unified Access Gateway (UAG) DirectAccess deployment.
Forefront UAG DirectAccess requires DNS for the following:
- DirecAccess client requests—DNS is
used to resolve requests from DirectAccess client computers that
are not located on the internal network. DirectAccess clients
attempt to connect to the DirectAccess network location server in
order to determine whether they are located on the Internet, or on
the corporate network: If the connection is successful, then
clients are determined to be on the intranet and DirectAccess is
not used, and client requests are resolved using the DNS server
configured on the network adapter of the client computer. If the
connection does not succeed, clients are assumed to be on the
Internet. DirectAccess clients will use the name resolution policy
table (NRPT) to determine which DNS server to use when resolving
name requests. You can specify that clients should use DirectAccess
DNS64 to resolve names, or an alternative internal DNS server.
When performing name resolution, the NRPT table is used by DirectAccess clients to identify how to handle a request. Clients request an FQDN or single-label name such as http://internal. If a single-label name is requests, a DNS suffix is appended to make an FQDN. If the DNS query matches an entry in the NRPT, and DNS4 or an intranet DNS server is specified for the entry, then the query is sent for name resolution using the specified server. If there’s a match but no DNS server is specified, then this indicates an exemption rule and normal name resolution I applied. For more information, see NRPT.
- DNS for infrastructure servers—DNS
intranet A records are used for the following:
- The network location
server—DirectAccess clients attempt to reach the network
location server in order to determine whether they are on the
internal network. Clients on the internal network must be able to
resolve the name of the network location server
- The IP-HTTPS server—IP-HTTPS is a
transition technology used by DirectAccess clients connecting over
IPv4. It is used a fallback method by clients who cannot connect to
the Forefront UAG DirectAccess server using any other method, or if
force tunneling is configured. The Forefront UAG DirectAccess
server acts as an IP-HTTPS Web server and uses its server
certificate to authenticate to IP-HTTPS clients. DirectAccess
clients must be able to resolve the DNS name of the server.
- CRL revocation checking—DirectAccess
uses certificate revocation checking for the IP-HTTPS connection
between DirectAccess clients and the DirectAccess server, and for
the HTTPS-based connection between the DirectAccess client and the
network location server. In both case DirectAccess clients must be
able to resolve and access the CRL distribution point location.
- ISATAP—Intrasite Automatic Tunnel
Addressing Protocol (ISATAP) uses tunneling to enable DirectAccess
clients to connect to the Forefront UAG DirectAccess server over
the IPv4 Internet, encapsulating IPv6 packets within an IPv4
header. It is used by Forefront UAG DirectAccess to provide IPv6
connectivity to ISATAP hosts across an intranet. In a non-native
Ipv6 network environment, the Forefront UAG DirectAccess server
configures itself automatically as an ISATAP router. Resolution
support for the ISATAP name is required.
- The network location server—DirectAccess clients attempt to reach the network location server in order to determine whether they are on the internal network. Clients on the internal network must be able to resolve the name of the network location server
DNS deployment requirements include the following:
- 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.
- We recommend that you use a DNS server that supports dynamic
updates. You can use DNS servers that do not support dynamic
updates, but entries must be manually updated.
- The FQDN for your Internet-accessible CRL distribution points
must be 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.
There are no specific limitations for DNS deployment.
Planning steps are summarized in the following table.
|Planning stage||Planning steps|
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.
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:
You might need to plan for additional NRPT rules in the following cases:
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.
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:
Planning for split brain DNS