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:


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 is configured to use the DNS64 service running on the DirectAccess server at 2002:62bd:d898:3333::1. Notice also that the host 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 would be sent to the DNS64 service on the DirectAccess server. A name resolution request for 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 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.

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>

Troubleshooting Name Resolution Issues on DirectAccess Clients

Leave a comment


  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)

    • 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.

      • 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:

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

    external FQDN DNS zone mycompany.commy

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

    our topology

  3. Ashish

     /  July 9, 2015

    Hello Richard,

    What happens if we have enabled force tunneling with NRTP exceptions? How ill the client try to access the site which are their in NRTP exceptions?

    • Force tunneling configures the NRTP to forward name resolution requests for ALL namespaces (not just the corporate namespace) to the DirectAccess DNS64 service. In this configuration there are no NRPT exemptions.

  4. DADemon

     /  September 11, 2015

    Richard, We recently implemented a production pilot of DA on Windows Server 2012 R2. We have a very large organization and are attempting to determine what may be causing all of our Window 7 client machines to be unable to resolve internet addresses when connected to DA. In the same environment, our Windows 8.1 and Windows 10 devices have no issues handling this. When I look at the local DNS resolver cache on the client after attempting to ping a random website (i.e. I see about 11 entries for IPv4 and IPv6 addresses for However the result returned to the command prompt is as follows: “Ping request could not find client Please check the name and try again.”

  5. matt

     /  January 13, 2016


    Thanks this has really cleared up a lot of questions on how DNS resolution is working with DirectAccess. However, I have followed your steps provided and when I try and run it against my DNS64 address I get the message:
    server 2002:6e6e:6e03:3333::1
    DNS request timed out.
    timeout was 2 seconds.
    Default Server: [2002:6e6e:6e03:3333::1]
    Address: 2002:6e6e:6e03:3333::1

    • Are you able to ping the DN64 address?

      • matt

         /  January 18, 2016

        Yes able to ping the dns64 address.

      • Do you have IPsec tunnels as well? Get-NetIpsecMainModeSA will tell you.

      • Adam

         /  February 9, 2016

        I have a similar problem; no DNS resolution. Can ping the DNS64 address but nslookup does not work. No IPsec tunnels showing after running Get-NetIpsecMainModeSA. Eternally grateful to anyone who can contribute to a resolution.

      • Drop me a note. I’ll see if I can shed some light on why things may not be working for you.🙂

      • Hello Richard,

        I have the same problem like Adam. No DNS Resolution. No-IPsec tunnels. But i can ping and RDP the DNS64 adress. This is driving me crazy. Can you help me?


      • I can help, but I’ll need additional information. Send me an email and I’ll let you know what I need.🙂

      • Ross

         /  May 25, 2016

        Hi Richard,
        Thanks for the excellent blog post. I’m in the same situation as these guys – ping DNS64 address but no name resolution. Name resolution works locally on the DA server. Single IP, NATed IP/HTTPS only set up.

      • If you can ping the DNS64 address and the DTEs, but can’t access internal resources, I would suspect that you also don’t have any IPsec tunnels either. If that’s the case, investigate why IPsec is failing (missing or incorrect certificates, computer account missing or disabled, etc.).

      • vaulti

         /  May 29, 2016

        Hi Ross,

        In my case it turned out that I had a trouble with my Firewall-GPO. Check if the Firewall is enabled and configured correctly on the Clients and Server


  6. ecartini

     /  March 31, 2016

    Hello All,

    One of the issues we are facing in our DA environment is the ability for our help desk technicians to use microsft SCCM to remote a machine that’s is corrected to DA. I have been doing all kinds of research and still can not get this feature to work correctly. Currently I am going do the path of isatap and DNS.

    Any help would be greatly appreciated.

    Thank you!

  7. Bruno Guerra

     /  April 25, 2016

    Great Article. We got a problem to access a website of company, that is hosted outside of organization. Configured for exception and it works successfully. Regards.

  1. Friday Five - January 17, 2014 - The Microsoft MVP Award Program Blog - Site Home - MSDN Blogs
  2. Git clone for Windows working with Direct Access - BlogoSfera

Leave a Reply

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

You are commenting using your 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


Get every new post delivered to your Inbox.

Join 149 other followers

%d bloggers like this: