Direct Access Monitoring - DNS Server Error


  • I have implemented DirectAccess but cannot get connectivity.  I've followed MSFT documentation throughout the implementation and believe everything to be done correctly. 

    I assume my issue is related to a message within the DirectAccess Monitoring console pertaining to the DNS Servers.  The message is:  "None of the internal DNS servers <IPv6 address> that DIrectAccess client computers use for name resolution is responding.  This prevents DirectAccess clients from resolving names in the internal namespace and connecting to the internal network.  Make sure the DNS servers are online and responding to name resolution requests."

    The error persists despite installing DNS on the DirectAccess server itselve and configuring all internal zones as secondaries on it.  It should be able to connect to itself for DNS right?

    Wednesday, April 21, 2010 6:50 PM

All replies

  • Start with what works. 


    What works in these steps:


    Move client back to local LAN and test things.


    Report back what does work.

    Wednesday, April 21, 2010 6:56 PM
  • Also post a little bit about your environment.  form of internal dns/external dns.  Are you using raw IPV6 or ISATAP?
    Wednesday, April 21, 2010 6:58 PM
  • Hi Don,  


    Thanks for the response.  I have seen this article.  (http://technet.microsoft.com/en-us/library/ee624058(WS.10).aspx) From home over the internet I can get to step 6.  When connected to the DMZ network at my office I can get to step 10.  We do not have IPv6 deployed internally and are using ISATAP.  As part of troubleshooting I assigned an IPv6 address to our internal DNS servers (Windows 2008 SP2 Domain Controllers) and was able to ping those address from one another but the Direct Access server could not ping those addresses and the Domain Controllers could not ping the DirectAccess IPv6 address either.  The DirectAccess server CAN ping its own IPv6 address and I was able to successfully make the DirectAccess server a DNS server but still get the DNS error in the Direct Access Monitoring console when it is trying to communicate with itself over IPv6.  I validated the DNS server installation is listening on the IPv6 address.  

    I have tried with and without a gateway and DNS servers assigned to the Internet NIC.  This doesn't seem to make a difference but I do get a popup about multiple default gateways when saving a gateway on the internet adapter.  I verified the Internet adapter does not identify itself as being part of the domain profile.  

    Wednesday, April 21, 2010 8:01 PM
  • You should first figure out what tunnel technology you are using.

    Home and Work are behind NAT firewalls correct?  Does the work network have a domain controller that is not related to your corporate network.  If behind a NAT firewall you will attempt to connect with Teredo. IF DA detects a DC behind that NAT it will not connect by default.  (This is to prevent the Teredo client from traversing organization network firewalls)  So then it attempts with IPHTTPS.

    That could be the difference between home and DMZ attempts.

    Set the gateway on the internet NIC.  That is a requirement of DA.  Do not set a gateway on the intranet NIC.  Use a static route. 

    Have you run through the Step by step?  It does work very well?



    Wednesday, April 21, 2010 8:26 PM
  • On the work test where I was able to ping the DA IPv6 address I was plugged into a Router/Firewall which does perform NAT and which was also plugged into the DMZ switch where the DS server Internet adapter is connected.  

    On the home test where I could not ping the DA server IPv6 address I was also connected to a Router/Firewall which was doing NAT and which was connected to my ISP's uplink. 

    In neither case is there a Domain Controller on the local network.

    I did follow step-by-step documentation during setup but don't remember any mention of the need to configure a static route on the internal adapter.  Which article are you referring to?  I have modified the adapter gateway settings accordingly but it hasn't had an impact on the DNS server error I am seeing within the DA console.  



    Wednesday, April 21, 2010 11:05 PM
  • Page 8 of the step by step mentions a note.  It refers to the design guide.


    Thursday, April 22, 2010 12:10 AM
  • Thanks.  I added the static routes and configured the gateway settings on the two adapters correctly per the link you sent.  This doesn't seem to have had any effect on the DNS server error I am seeing in the monitoring console.  Initial searching brought me to this post - http://social.technet.microsoft.com/Forums/en/windowsserver2008r2networking/thread/7ef1f068-a6b8-43a6-aeec-6faa013a1d38 although that was being attempted on an RC version of 2008 R2.  I have verified policy inheritance is enabled on the OU containing the Direct Access server.  

    Not sure if this could have anything to do with the AAAA record.  I checked DNS and see this record named directaccess-corpConnectivityHost which just points to ::1.

    When I disable the Internet adapter and re-enable it I do not see the DNS error in the monitoring console go away.  


    Thursday, April 22, 2010 3:01 PM
  • This thread also refers to others having the same problem but doesn't provide any clear solution - http://social.technet.microsoft.com/Forums/fi-FI/windowsserver2008r2networking/thread/4ae72bee-0590-4f56-beed-ea6265329f74 


    Thursday, April 22, 2010 3:10 PM
  • This article (http://social.technet.microsoft.com/Forums/en/windowsserver2008r2networking/thread/f9a267a0-ebab-4cbb-8920-f3a99713f789) points at the need for all DNS servers used by DA to be 2008 SP2 or later and to have the dnscmd /config /globalqueryblocklist wpad command run on them.  I have done this but continue to see the error.  


    Thursday, April 22, 2010 4:40 PM
  • Disabling the public profile of the firewall on the DA server seems to make the DNS error in monitoring go away.  I'm still unable to connect however.  I have an output from the DirectAccess Connectivity Assistance that I can provide.  
    Friday, April 23, 2010 8:41 PM