Troubleshooting Name Resolution Issues on DirectAccess Clients

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:

Get-DnsClientNrptPolicy

Troubleshooting Name Resolution Issues on DirectAccess Clients

You can view the NRPT on a Windows 7 DirectAccess client by issuing the following netsh command:

netsh namespace show policy

Troubleshooting Name Resolution Issues on DirectAccess Clients

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.

NSlookup

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.

Troubleshooting Name Resolution Issues on DirectAccess Clients

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

Troubleshooting Name Resolution Issues on DirectAccess Clients

Practical IPv6 for Windows Administrators

With the rapid depletion of the global IPv4 address pool, the adoption of IPv6 is growing significantly. The total exhaustion of public IPv4 addresses is inevitable, making IPv6 knowledge an important and essential skill that network engineers and systems administrators will need to have to be successful. While there are some excellent IPv6 references available today, until now there has been a serious lack of practical, real-world implementation guidance for IPv6. Until now!

Practical IPv6 for Windows AdministratorsRecently my good friend Ed Horley released a book entitled Practical IPv6 for Windows Administrators. As one of the technical reviewers of this title, along with Jason Jones, I had the privilege of reading this book in advance and providing feedback as it was being developed. This new book provides detailed information for network engineers and systems administrators looking to deploy IPv6. It contains prescriptive guidance for implementing IPv6 with a focus on how the protocol affects applications and services common on many of today’s corporate networks. Topics like IPv6 address assignment and name resolution are covered in detail, along with operation and support for IPv6 with services like Exchange, SQL, SharePoint, Hyper-V, and more. In addition, PowerShell is featured prominently throughout the book.

IPv4 is a dying breed. IPv6 is the way of the future, without question. Understanding IPv6 now is critical, and it is vital that you begin obtaining knowledge and experience with the IPv6 protocol today to ensure that you won’t be left out in the cold. Start building your IPv6 skills today. Order Practical IPv6 for Windows Administrators now! Once you’ve finished reading this book, you’ll be well on your way.

Disabling Unused IPv6 Transition Technologies for DirectAccess Clients

From a client perspective, DirectAccess is an IPv6-only solution and requires IPv6 connectivity end to end. To enable the solution to work on IPv4-only networks, DirectAccess makes use of one of several IPv6 transition technologies – 6to4, Teredo, or IP-HTTPS. By leveraging these IPv6 transition technologies, a DirectAccess client can communicate with the DirectAccess server when they are both connected to the public IPv4 Internet, which is the most common deployment scenario today.

The first two IPv6 transition technologies, 6to4 and Teredo, both require that the DirectAccess server be directly connected to the public Internet. Beginning with Windows Server 2012, placing the DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is now supported. However, in this deployment model only the IP-HTTPS IPv6 transition protocol can be utilized. In this scenario, it is recommended to disable the unused IPv6 transition protocols to prevent potential connectivity issues. You can disable them on a per-host basis using PowerShell, which is fine for individual client testing purposes, or globally using Active Directory Group Policy Objects (GPOs), which is recommend for enterprise-wide production deployment.

To disable unused IPv6 transition protocols on a per-host basis on Windows 8 clients using PowerShell, open an elevated PowerShell prompt and execute the following commands:

Set-Net6to4Configuration –State disabled
Set-NetTeredoConfiguration –Type disabled
Set-NetIsatapConfiguration –State disabled

To disable unused IPv6 transition protocols on a per-host basis on Windows 7 client using netsh, open an elevated command prompt and execute the following commands:

netsh interface 6to4 set state disabled
netsh interface teredo set state disabled
netsh interface isatap set state disabled

To disable unused IPv6 transition protocols using Active Directory GPO, open the Group Policy Management Console (GPMC) and create a new GPO. Edit the GPO by navigating to Computer Configuration / Policies / Administrative Templates / Network / TCP/IP Settings / IPv6 Transition. Double-click Set 6to4 State and enable the policy, then select Disabled State from the list of states. Repeat these steps for Teredo and ISATAP.

Disable DirectAccess IPv6 Transition Protocol using GPO

Change the security filtering for the GPO and specify the security group for your DirectAccess clients. Once complete, link the new GPO to the domain.

Disable DirectAccess IPv6 Transition Protocol using GPO

As a reminder, the steps above are for disabling unused IPv6 transition protocols in a deployment scenario where the DirectAccess server is running Windows Server 2012/R2 and is deployed behind a NAT device. If your DirectAccess server is connected directly to the public Internet, disabling these IPv6 transition protocols is not required.