This question comes up with almost every DirectAccess deployment, as people tend to notice when new, goofy looking DNS records show up inside your primary DNS zone and you didn’t put them there. Let’s take a minute to explain what these two records are, how they are used, and whether or not they are actually important. Both of these records are self-generated by the DirectAccess configuration wizards, but often they are later scavenged by DNS which can cause some unexpected behavior.
This record is used by the DirectAccess client computers for verification of transition tunnel creation. As a DirectAccess client makes its initial connection, it will attempt to connect via three different IPv6 transition protocols – 6to4, Teredo, and IP-HTTPS. The validation of the directaccess-corpConnectivityHost record is part of the process that clients use in order to select which of those three transition technologies it is going to use in order to connect.
What does it look like?
The answer here is different depending on whether your internal network is IPv4-only (like most), or has IPv6 natively in your network as well.
IPv6 network – There will be only one DNS record created for directaccess-corpConnectivityHost, and that record will be ::1.
IPv4 network – This one applies to almost everybody. In a corp network that is IPv4-only, you will see two directaccess-corpConnectivityHost records. An A record that is pointed to 127.0.0.1, and a AAAA record that is pointed to an IPv6 address. This IPv6 address will begin with your DirectAccess server’s NAT64 prefix, and will end with ::7F00:1, which is hex for 127.0.0.1.
Is this record important?
Not usually. I have seen many DirectAccess customers running perfectly well with no directaccess-corpConnectivityHost records in place whatsoever. The wizard always attempts to create these DNS records, but sometimes permissions in DNS don’t allow that self-generation of records, or other times DNS scavenges them away later. The reason this one is becoming less and less important is that more and more DirectAccess implementations are going the way of “IP-HTTPS only”. Anytime that you sit your DA server behind a NAT, you limit yourself to only the IP-HTTPS protocol for DirectAccess tunneling. 6to4 and Teredo will never work behind a NAT. So, in those cases it really doesn’t matter whether or not you have directaccess-corpConnectivityHost records. Additionally, I will say that I have seen plenty of customers who do indeed have Teredo running, and still do not have this DNS record present in their environment, and they do have clients who connect successfully via both Teredo and IP-HTTPS. Ultimately, what I usually recommend is that folks who are pushing to have Teredo be available go ahead and make sure this DNS record exists, but in practice it really doesn’t matter very much.
Here’s an annoying one. This is the record that usually generates a support call following a successful DirectAccess implementation. Do you remember when you walked through the DirectAccess configuration wizards and had to specify a “probe” inside Step 1? You created either a PING probe and specified a server inside your network, or an HTTP probe and specified a website inside your environment.
Now most of the time, you wouldn’t have any reason to go back inside Step 1 and take another look at this screen, right? Well, go ahead and do that now. If you take another look at the Network Connectivity Assistant (NCA) screen inside Step 1, you will now notice that there is a second probe entry here, an HTTP that is pointed at directaccess-WebProbeHost. But wait, you didn’t put that there, did you? Of course not. The wizard was “kind” enough to do it for you. It auto-inserts that probe inside Step 1, and then the wizard also creates the directaccess-WebProbeHost record inside DNS as well.
What does it look like?
directaccess-WebProbeHost is generated as an A record that points to the internal IP address of your DirectAccess server. In NLB arrays, it will be pointed toward the VIP that is shared by that array. In Multi-Site deployments, there will be multiple WebProbeHost records, one for each DirectAccess entry point.
Is this record important?
Yes and no. It is important that you do SOMETHING with it. When the NCA tool on your Windows 8 and Windows 10 client computers checks its connectivity status in order to tell you either “Connecting” or “Connected”, it is a very simple check that is looking to the probes defined inside Step 1 of the DirectAccess wizards. If it can see the probes (all of them), it says “Connected” – yay! But if it fails to see even one of those probes, it will remain in a continually “Connecting…” state forever and ever. This can certainly confuse users, because it is very possible that DirectAccess is actually working just fine, but since one of the probes isn’t available their NCA tool never switches to say “Connected”. This is the call I often receive. After setting up DirectAccess, the wizard auto-inserts directaccess-WebProbeHost into the NCA settings, and creates that DNS record. However, as we already established sometimes DNS doesn’t allow that record to be created, and other times it works for a while but then chooses to scavenge the record. This suddenly results in ALL of your DA client computers saying “Connecting…” all the time. It will certainly generate some helpdesk phone calls.
So what can you do? You can either manually create the directaccess-WebProbeHost record and point it at the internal IPv4 address of the DirectAccess server, or what I usually do is simply edit Step 1 inside the DA configuration, and DELETE the WebProbeHost record. This change will then “stick”, and it won’t automatically re-appear. This way you can probe against the probe that you initially defined in the settings, like you originally intended it to do, and not have the potential of this self-generated probe getting in your way.
Security Engineer | IVO Networks