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

Leave a comment

5 Comments

  1. Hi guys let me know something when DA (EDGE server) is behind a firewall it will only use ipv4, right? so the NRPT table will still be used to resolve ipv6 names ? Regards,
    wn7client [FW] [FW] corpnet (AD , APP, IIS)

    Reply
    • IPv6 is always used between the DirectAccess client and server, regardless of network configuration. What changes when DirectAccess is behind a NAT is the IPv6 transition protocol. For edge deployments, the client can choose between 6to4, Teredo, and IP-HTTPS. For NAT deployments, only IP-HTTPS is supported. The NRPT still functions the same way in either configuration.

      Reply
      • Hi , we solve it disabling the the teredo, 6to4 interface in the external client, but in the lab we used ip-https passing through a router not a firewall to make it simple.

  2. Hi Richard talking about NRPT and we have a situation here where

    the internal FQDN: corp.company.com

    additional forward dns zone: mycompany.com (all the applications web, SharePoint, answers at app1.mycompany.com (internaly)

    external FQDN DNS zone mycompany.commy

    all Windows 7 and 8 are working normally but when we try to resolve app1.mycompany.com (published only internal it doesn’t work. How can I set it up at NRPT to solve it?

    our topology

    http://social.technet.microsoft.com/Forums/getfile/465114

    Reply
  1. Friday Five - January 17, 2014 - The Microsoft MVP Award Program Blog - Site Home - MSDN Blogs

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 48 other followers

%d bloggers like this: