DirectAccess DNS Records Explained

After installing and configuring DirectAccess with Windows Server 2012 R2, several new host records appear automatically in the internal DNS (assuming dynamic DNS is supported, of course). One of them is directaccess-corpConnectivityHost and the other is directaccess-WebProbeHost. These DirectAccess DNS entries are used by Windows 8 and later clients for connectivity checks at various stages of DirectAccess connection establishment.

DirectAccess DNS Records Explained

Figure 1 – DirectAccess DNS records for IPv4-only network.

DirectAccess DNS Records Explained

Figure 2 – DirectAccess DNS records for dual-stack IPv4/IPv6 network.

Here is a detailed description for each of these DirectAccess DNS entries.

directaccess-corpConnectivityHost – This DNS host record includes both A and AAAA records when deployed on IPv4-only networks. Its A host record resolves to 127.0.0.1, which is the IPv4 loopback address. Its AAAA host record resolves to an IPv6 address that is a combination of the DirectAccess NAT64 IPv6 prefix and 7F00:1 (the hexadecimal equivalent of 127.0.0.1). When DirectAccess is configured on a network with native IPv6, the directaccess-corpConnectivityHost DNS record will only include a single AAAA record resolving to ::1.

This host record is used by the DirectAccess client to determine if name resolution for the corporate namespace is working after the IPv6 transition tunnel (6to4, Teredo, or IP-HTTPS) has been established. It does this by attempting to resolve the hostname directaccess-corpConnectivityHost.<corp_fqdn> (e.g. directaccess-corpConnectivityHost.corp.example.net) to an IPv6 address that it expects (the organization’s NAT64 prefix + 7F00:1 or ::1). If it does not resolve, or resolves to a different address, the client will assume that the transition tunnel was not established successfully and, if possible, fall back to another IPv6 transition protocol and repeat the process until it is successful.

Note: The DirectAccess client does not attempt to connect to the IP address resolved by directaccess-corpConnectivityHost. It simply compares the IP address returned by the query to the expected address (NAT64 prefix + 7F00:1 or ::1).

directaccess-WebProbeHost – This DNS host record includes only A records and resolves to the IPv4 address assigned to the internal network interface of the DirectAccess server. If load balancing is enabled, this host record will resolve to the virtual IP address (VIP) of the array. For multisite deployments there will be directaccess-WebProbeHost A host records for each entry point in the organization.

This host record is used by the DirectAccess client to verify end-to-end corporate network connectivity over the DirectAccess connection. The client will attempt to connect to the directaccess-WebProbeHost URL using HTTP. If successful, the DirectAccess connectivity status indicator will show Connected.

If any of these DirectAccess DNS records are missing or incorrect, a number of issues may arise. If the directaccess-corpConnectivityHost host record is missing or incorrect, DirectAccess IPv6 transition tunnel establishment may fail. If the directaccess-WebProbeHost record is missing or incorrect, the DirectAccess connectivity status indicator will perpetually show Connecting. This commonly occurs when an external load balancer is used and a virtual server isn’t created for the web probe host port (TCP 80). In addition, these DirectAccess DNS entries are not static and may be deleted if DNS scavenging of stale resource records is enabled on the DNS server.

Leave a comment

51 Comments

  1. Stefaan Pouseele

     /  July 6, 2015

    Hi Richard

    As far as I know, the requirement that the directaccess-corpConnectivityHost should resolve to the NAT64 prefix + 7F00:1 is only valid in an IPv4-only Intranet environment. In an IPv4+IPv6, or IPv6-only Intranet environment, I think that only a AAAA record should be created with the loopback IP address ::1.

    Best Regards,
    Stefaan

    Reply
    • You are absolutely right, Stefaan. Thanks for brining that to my attention! I’ll get this post updated to reflect that soon. 🙂

      Reply
  2. Hi!

    How to repair missing DNS entries? I checked our DirectAccess environment and there is only one directaccess-corpConnectivityHost in DNS. Is it possible to repair the missing entries and set them static?

    Thanks,
    Dietmar

    Reply
    • Hi Dietmar,

      Yes, you can manually recreate the entries statically to prevent them from being scavenged, if necessary.

      Reply
  3. Fred

     /  August 13, 2015

    Hi Richard,

    I think that IPSEC tunnels must work also to success this DNS check.

    Fred

    Reply
  4. James

     /  August 20, 2015

    Hi Richard,

    We’ve configured several independent DirectAccess deployments within a single domain. Currently 6 DA servers, each with its own configuration, policies, etc. I’ve managed to share NLS, and directAccess-WebProbeHost with no difficulty as you mentioned previously. However I’ve noticed the only DNS record for directaccess-CorpConnectivityHost is 127.0.0.1. Since we have multiple deployments with varying IPv6 prefixes how do we create the AAAA records so the DA clients/Servers don’t get confused if they resolve the wrong name for their IPv6 prefix?

    -James

    Reply
    • James

       /  August 20, 2015

      Forgot to mention, all these deployments are IPv4 IP-HTTPs configurations.

      Reply
    • I think you should be fine with a single directaccess-CorpConnectivityHost DNS record. The DNS64 service will return a AAAA record with the correct prefix for each deployment, so clients should not be confused.

      Reply
      • James

         /  August 24, 2015

        Currently I only have the 127.0.0.1 A record for directaccess-CorpConnectivityHost, how will it return a AAAA record when there isn’t one?

      • The DNS64 service will create one. 🙂

  5. Hi! Can you please explain how to get the NAT64 IPv6 prefix? Thanks!

    Reply
    • You can find the NAT64 prefix in the registry on the DirectAccess server at HKLM:\SYSTEM\CurrentControlSet\Services\RaMgmtSvc\Config\Parameters\Nat64Prefix. If you’ve configured DirectAccess for multisite you can also find it in the Remote Access management console when you select Configuration/DirectAccess and VPN and highlight the individual entry point.

      Reply
  6. Craig

     /  October 6, 2015

    Richard,

    I’ve currently got a 2012 R2 single site IPv4 setup going with only Win 7 clients. It is configured for 6to4, Teredo and IPHTTPS. I have FOUR AAA directaccess-corpConnectivityHost records. That doesn’t seem correct?

    They are:
    fdc2:a1c5:de93:7777::7f00:1
    fd60:4f94:88fb:7777::7f00:1
    fde8:8a2a:5a43:7777::7f00:1
    fd7e:3fb3:5637:7777::7f00:1

    Reply
    • That’s unusual. The only thing I can think of is that you have installed and then uninstalled DirectAccess a few times and that these are stale records. Each time you install DirectAccess a new ULA IPv6 prefix is created which would explain the multiple records.

      Reply
  7. Craig

     /  October 7, 2015

    I’ve only installed DA once. If there are 4 records that’s going to be an issue for any Win8+ clients I assume?

    I’ve checked the registry and the NAT64Prefix is fde8:8a2a:5a43:7777::/96 so should I just delete the others?

    Reply
    • It shouldn’t cause a problem, but if you decide to remove those other entries be sure you don’t delete the one that matches your NAT64 prefix. 🙂

      Reply
  8. Matthew Squires

     /  April 18, 2016

    Hi Richard,

    You have some wonderful guides. Thank you for your help thus far. I’d like to know if you have any thoughts on how to get DA clients or VPN clients to register their IP addresses in AD. I’ve followed your guides, and have my DA and VPN on the same host (this is a POC). They are configured behind a NAT device with 2 network adapters. Everything seems to work fine with the exception of DNS registration.

    Reply
    • I’ve never run in to this issue, but fundamentally it works the same via DirectAccess as it does on the LAN. If you use the same problem resolution techniques as you would with a LAN client it should resolve the issue for DirectAccess clients.

      Reply
  9. Jason Hall

     /  May 16, 2016

    If we’re hosting a website for NLS & NCA on external HA servers; would DirectAccess still be using these WebProbeHost DNS records? Or would they be using the records configured for our NCA & NLS (DirectAccess-NCA.blah & DirectAccess-NLS.blah)?

    We’ve recently switched from external load balanced configuration to single servers & having issues with one entry point (we have 2 entry points). I can see the WebProbeHost record still have our old Load Balanced addresses; but not sure this is an issue since 1 entry point is working…

    Reply
    • The WebProbeHost is created and used by default by DirectAccess. If you’ve changed it to something else using the Remote Access Management console, then there would be no need for those DNS records to exist.

      Reply
      • Jason Hall

         /  May 17, 2016

        Ok cool. Yep, we’re manually setting NCA & NLS addresses in the config,

        I think I’ve narrowed down our problem a little more… On Step 3 of the configuration (Infrastructure Servers) when validating the DNS Server Address our ‘broken’ server fails this check saying “The specified DNS server is not responding. Ensure that the DNS Server role is installed and running on the server.”
        The address specified is the IPv6 address on the internal NIC (same IPv6 address on both servers); although when you edit the suffix entry it shows as the IPv4 address instead (different depending on which server you run the console on).

        Might be time to open a support case with Microsoft…

  10. Jason Hall

     /  May 17, 2016

    Fixed out problem… As part of removing the load balancers, we had also migrated the 2 entry points onto a subnet stretched across both locations. Turns out DA doesn’t like this & a fix is listed here: https://technet.microsoft.com/en-us/library/hh831664(v=ws.11).aspx

    Reply
  11. Thorsten Frohberg

     /  June 20, 2016

    Hello Richard,
    we have 3 different and singe DA Server in one Environment. Can i share the first created directAccess-webprobehost with the other DA servers ? Or how i can use one directAccess-webprobehost with more as one DA Server ? In DNS i can only create one directAccess-webprobehost Host Entry.

    Reply
    • You can share the single URL, but if that server is offline, Windows 8.x/10 clients connected to the other DirectAccess servers will show “connecting” for their connection status. Here, a better alternative is to use another internal web server for the web probe host. It can be any internal web server that uses HTTP (not HTTPS) and it can’t be the NLS.

      Reply
  12. mike

     /  July 8, 2016

    Hi Richard,
    Setting up dual multi-site with two entry points in the same physical location. The multi-site wizard assigned the same IPv6 address to both of the servers, is this expected behavior? IPv4 IP-HTTPS setup. The first DA server seems to work fine, but on the second one clients don’t seem to find a DC after connecting through the tunnel.

    Reply
    • Depending on your network configuration and chosen topology, yes, this can happen. Are your DirectAccess server’s edge facing with public IPv4 addresses?

      Reply
      • mike

         /  July 12, 2016

        Thanks for the reply! Yes, they are. I had noticed IP conflict errors while the second DA entry point would not work, but I found this on a TechNet and it seemed to resolve the problem: “Set-NetIPInterface –InterfaceAlias –AddressFamily IPv6 –DadTransmits 0”. They both seem to be working now using the same ipv6 address.

      • Excellent. Glad you were able to get things sorted. 🙂

  13. verukins@hotmail.com

     /  September 1, 2016

    Hi Richard,
    Thanks for this post. One thing I am trouble finding the answer on is if multiple web-probe hosts are configured in “step 1” of the DA wizard…. are those hosts treated as an “and” or an “or” ?

    I.e. if I leave the default web-probehost configured and add another one, do both need to be available? or only one or the other ?

    if this is in the doco and I have missed it, my apologies, but I couldn’t find it.

    Reply
    • It’s “and”. If you have multiple entries defined for the connectivity status indicator, all must pass for the client to show “connected”. If one fails, the client will report “connecting”. That’s why I recommend using just one web probe host URL. 🙂

      Reply
  14. Aaron Hutchinson

     /  November 8, 2016

    Just going to throw this out there. There is a powershell cmdlet to help get the IPv6 prefix mapping, “get-netnattransitionconfiguration” when run from the DA server.

    Reply
  15. Brad

     /  January 27, 2017

    Your blog has been an invaluable resource to me in getting DA working and troubleshooting over the years. Thank you! I’m getting a very strange warning regarding the web probe URL (which hasn’t changed). We are in the process of retiring a DC so we wanted to update the list of DCs in DA (refresh management servers). The warning is:

    Warning: One or more IP addresses of management server dc1.example.com cannot be added because they are associated with the web probe URL used to verify DirectAccess client connectivity. The server will be added without the conflicting IP addresses. Ensure that IP addresses associated with the probe URL are not configured on any management servers.

    Obviously the IP (internal interface of the DA machine) that the web probe URL points to is different then the IP addresses of any of the 3 dc’s. They are, however, on the subnet. Is this warning benign?

    Reply
    • That’s certainly a strange one. I’ve never seen this message before so I can’t really say it is benign. However, if everything is working ok and you have no other warning or error messages otherwise, perhaps it can be ignored. Keep me posted though!

      Reply
  16. David Willetts-Smith

     /  March 27, 2017

    Hi Richard, your posts have been most useful in setting up my DirectAccess 2012 R2 Server, I have an issue though, I’m seeing the URL availability error next to Network Location Server but my clients connect fine to DirectAccess and I can access resources on my corp LAN fine?? And secondly when I connect the client directly to the corp LAN they think they’re on a Private Network rather than the Domain and as such I can’t see any servers by name – (I can though by IP) The NLS Web Server (my DA Server) is online and accessible and I have my self cert trusted in Trusted Roots on the client – Could you think of a cause? Thanks David

    Reply
    • NLS reachability would have no affect on DirectAccess clients outside of the network. However, the symptoms you describe indicate that the NLS does have a problem for internal clients. If internal clients can’t successfully connect to the NLS, they will behave exactly as you describe. They will think they are outside the network and won’t be able to access resources by name. Try connecting to the NLS from a client that is not configured for DirectAccess. You should be able to connect without any issues at all. I suspect there’s either a hostanme mismatch or the certificate isn’t trusted. Either way the browser should tell you what the problem is. 🙂

      Reply
      • David Willetts-Smith

         /  March 29, 2017

        Thanks for the speedy reply Richard. I trouble-shooted the NLS inc cert, and hostnames (using split DNS & 3rd party Wildcard cert) for the website that was also living on the DA Server that the wizard created but still no luck. Yes the non configured DA clients were able to connect to the DA Server with no problem and didn’t give me any reason for why the DA Clients couldn’t see the website. I then built a new Web Server to use as the NLS, pointed DA Server to use it and now this has resolved in the console and DA Clients are working perfectly – Thanks again for your advice.

  17. Kalaivanan Raju

     /  December 6, 2017

    HI Richard,

    We have a multi-site configuration in our environment(2 sites)and had this client saying “connecting” issues and client had issues connecting to the DA server on both the site.So we created “directaccess-corpConnectivityHost” record and issue got resolved.But again after 2 months we are getting the same issue in only one site.Users are getting issue connecting to one site and getting redirected and connect to the other site.Can you assist me with where the problem would be?

    Reply
    • There could be any number of reasons why this is happening, but understand that being connected via DirectAccess and the client showing “connected” are two different things. It is possible that the client is indeed connected, but if it can’t resolve and connect to the corp connectivity host URL (directaccess-WebProbeHost by default) it will show “connecting”. If clients aren’t being moved to another entry point, then I would have to suspect a connectivity issue that resulted in the client believing its entry point was unavailable.

      Reply
  18. No matter how much I’ve re-read all this string and other comments. Just to be sure that I understood what you wrote as well as everyone else regarding the A address that are in the DNS server entry. Is the webprobehost address is supposed to be the same as the Direct Access server since in my case, after doing a lot of investigating I noticed that the server address is different from the webprobehost address?

    Thank you in advance.
    Ty

    Reply
    • It depends. 😉 Technically speaking the web probe host URL can be any web server that responds on TCP port 80. In fact, you don’t have to use the “directaccess-WebProbeHost” DNS record at all. It could easily be “foo”. As the administrator, you define the web probe host URL. It’s just that when you first install/configure DirectAccess it automatically populates DNS with the A resource record “directaccess-WebProbeHost”. It’s simply convenient to continue using it. The important thing is to ensure that the URL resolves properly and that the server is listening on TCP port 80. Also, obviously, it should be reachable by DirectAccess clients. 🙂

      Reply
  19. Justin

     /  October 23, 2018

    Having an issue with clients registering their IPv6 to the AD DNS. They keep getting 8018 error events saying the DNS server rejected their request. I can’t seem to narrow down the issue. All works fine internally and if I change the DNS server over to unsecured updates then it works fine. If the clients can access the domain from the outside, browse network, run login scripts, get GP…why would the DNS server deny them as unsecured? Any ideas on how to trouble shoot this? Thanks!

    Reply
    • Not sure what’s up there. Can’t imagine why it would work internally and not over the VPN connection. You might need to get Microsoft involved to assist in troubleshooting. Have to believe something is going on with authentication for remote clients though. :/

      Reply
  20. John Friel III

     /  November 14, 2018

    Richard, picked up your 2016 book because I’m having problems with Server 2016 and the DA setup. We were running on Server 2012R2 for many years and it had mostly worked fine, but when I switched to the new cluster with S2D on 2016, my old 2012R2 server would not migrate. Fine, I’ll just build a new one with 2016! I had it up and running but still have a couple issues that I can’t find reference to in the book, but your blog is helping.
    1. Our internal network is both IPv4 and IPv6 with our internal being fd18:b44f:9055:7200:: and our DHCP hands out both v4 and v6. Our internal domain is corp.companyname.com and external just companyname.com. The server is a VM with two external IPs and one internal. It correctly picked up the external first IP and the internal IPv6 for the adapters. When everything is said and done, it comes up and I get the warning on the corporate network route publish. Not sure what else I need.
    2. The directaccess-WebProbeHost does create the A record for the internal v4 address, but the clients always stick in a “connecting” state, but I think that is because DA is running strictly v6 and this DNS entry doesn’t has an AAAA record? Is this possible?

    Reply
    • John Friel III

       /  November 14, 2018

      Update, I ran the DA Client Troubleshooter and the client says it successfully reached the HTTP probe at http://directaccess-WebProbeHost.corp.companyname.com yet DA is still stuck “Connecting”. The only caution I received was for the the certificate does not contain the EKU Client Authentication, but DA is up and running.

      Still have the caution on the server for the Corporate network route publish.

      Reply
      • You won’t be able to establish a DirectAccess connection without a certificate that has the client authentication EKU. The tool could be reporting erroneously (it often does!) but I’d look at that closely. You can verify the establishment of DirectAccess IPsec tunnels using the Get-NetIPsecMainModeSA PowerShell command. If you have a certificate and network connectivity internally (see my previous reply) then you should have security associations (SAs) established.

    • Although DirectAccess uses IPv6 for remote client to gateway communication exclusively, deploying DirectAccess with native IPv6 presents some unique challenges (as you have already found out!). First, you’ll need to ensure that you publish the DirectAccess client IPv6 prefix to the internal network so that DirectAccess client traffic is routed by to the DirectAccess server, not your network’s default gateway. The route publishing error is common when deploying DirectAccess with IPv6 on the internal network. You’ll need to run the following PowerShell commands on your DirectAccess server to resolve that issue.

      $Prefix = Get-RemoteAccess | Select-Object -ExpandProperty InternalIPv6Prefix
      $IfAlias = Get-RemoteAccess | Select-Object -ExpandProperty InternalInterface
      New-NetRoute -DestinationPrefix $Prefix -InterfaceAlias $IfAlias -AddressFamily IPv6 -Publish Yes

      As for the webprobehost issue, I’m guessing that’s not working because you don’t actually have an end-to-end connection established yet. Once you’ve verified connectivity to internal resources, then you can come back to troubleshooting webprobehost failures.

      Reply
  1. Server 2012 — DirectAccess — часть 1 (клиенты Windows 8) | Dzuba.WindowsFAQ.ru
  2. DirectAccess NRPT Configuration with Split DNS | Richard M. Hicks Consulting, Inc.

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 )

Google+ photo

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

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: