Name resolution and proper DNS server configuration is vital to the functionality of DirectAccess. When performing initial configuration of DirectAccess, or making changes to the DNS server configuration after initial configuration, you may notice the operations status for DNS indicates Critical, and that the operations state shows Server responsiveness.
Highlighting the DNS server on the Operations Status page and viewing the details shows that DNS is not working properly with the following error message:
None of the enterprise DNS servers <IPv6_address> used by DirectAccess
clients for name resolution are responding. This might affect DirectAccess
client connectivity to corporate resources.
There are a number of things that can contribute to this problem, but a common cause is an error made when assigning a DNS server to a specific DNS suffix. An inexperienced DirectAccess administrator might specify the IPv4 address of an internal corporate DNS server, which is incorrect. The DNS server IPv4 address should be the address assigned to the DirectAccess server’s internal network interface.
The best way to ensure that the DNS server is configured correctly for DirectAccess is to delete the existing entry and then click Detect.
An IPv6 address will be added automatically. This is the IPv6 address of the DNS64 service running on the DirectAccess server, which is how the DNS server should be configured for proper DirectAccess operation.
Once the changes have been saved and applied, the DNS server should once again respond and the status should return to Working.
Posted by Richard M. Hicks on September 22, 2015
When troubleshooting name resolution issues on a Windows client, NSlookup is an essential tool. However, it is important to understand that using NSlookup on a DirectAccess client might not always work as you expect. Although using NSlookup on a DirectAccess client will work normally when the client is on the corporate network, it will not provide the correct results to queries for internal hostnames when the DirectAccess client is outside of the corporate network without taking additional steps. This is because when a DirectAccess client is outside the corporate network, the Name Resolution Policy Table (NRPT) is enabled. The NRPT provides policy-based name resolution routing for DirectAccess clients, sending name resolution requests for certain namespaces to specific DNS servers. You can view the NRPT on a Windows 8.x DirectAccess client by issuing the following PowerShell command:
You can view the NRPT on a Windows 7 DirectAccess client by issuing the following netsh command:
netsh namespace show policy
Here you’ll notice that the namespace .lab.richardhicks.net is configured to use the DNS64 service running on the DirectAccess server at 2002:62bd:d898:3333::1. Notice also that the host nls.lab.richardhicks.net is not configured to use a DNS server. This effectively exempts this host from the NRPT, forcing name resolution requests for this Fully-Qualified Domain Name (FQDN) to be delivered to the DNS servers configured on the network adapter.
A Working Example
With the NRPT enabled, which occurs whenever the DirectAccess client is outside of the corporate network, a name resolution request for app1.lab.richardhicks.net would be sent to the DNS64 service on the DirectAccess server. A name resolution request for technet.microsoft.com would be sent to the DNS servers assigned to the network adapter because the NRPT contains no entry for this namespace. And even though the host nls.lab.richardhicks.net is a part of the internal namespace, a name resolution request for this host would also be sent to the DNS servers assigned to the network adapter because it has been specifically exempted from the NRPT.
The NSlookup utility is unaware of the NRPT. Whenever you use NSlookup it will, by default, automatically send queries directly to the DNS servers configured on the network adapter, regardless of the NRPT. If you wish to use NSlookup to test name resolution for external hostnames, use it as you normally would. However, if you wish to use NSlookup to resolve internal hostnames over the DirectAccess connection, you will need to tell NSlookup to use the DNS64 service running on the DirectAccess server. You can do this by running NSlookup interactively and using the server command to point it to the IPv6 address of the DNS64 service, which you can find in the NRPT.
This also applies to the PowerShell cmdlet Resolve-DNSname. Here you’ll use the -Server switch to specify the DNS64 server’s IPv6 address.
Resolve-DNSName –Server <DNS64_IPv6_Address> app1.lab.richardhicks.net
Posted by Richard M. Hicks on January 13, 2014