Select a language to translate this page!
Powered by Microsoft® Translator
This post was written by Lingkai Kong, a Software Development Engineer on the Windows Home Server team in Shanghai, China. Lingkai has been with the team for over 3 years, and has contributed to every major Windows Home Server release. In this post, he describes an issue some customers have faced when their ISPs have adopted OpenDNS and similar services, and how we’ve worked to resolve those issues in Windows Home Server Power Pack 3.
Some users have reported that after their ISPs adopted OpenDNS for their home network they started having issues connecting to their Windows Home Server: the connector software cannot locate the server and it is impossible to join a new home computer to the home server!
The root cause behind this is the name resolution solution mechanism of OpenDNS does not work well with windows home server. When a home computer looks for resolving the IP address for a computer name (for example, your home server), it follows the steps below:
1. It looks up the HOSTS file in the system. If not found, going to step 2.
2. It consults the DNS server for the name. If not found, going to step 3.
3. It asks NETBIOS if there is a name exists in local network.
The home server connector software depends on step 3, because the Windows Home Server is located in the local network and shouldn’t be resolved by any DNS server. However it never has a chance to go to step 3 because OpenDNS will always respond ”yes” and point to an external IP in step 2. As a result, your connector software would try to connect to an external IP, which always results in failure.
In Windows Home Server Power Pack 3, the problem is addressed and resolved. The solution is simple: the connector service running on the home computer updates its HOSTS file, adding an entry for the Windows Home Server in the network. The IP address in the entry is what windows home server announces via UPnP broadcast. The workflow is as follows:
1. Connector software gets the home server IP from UPnP.
2. Connector software tries to resolve the home server’s name via DNS name resolution.
3. If the IP from UPnP matches the IP from DNS name resolution, it’s taken as the real IP address of the home server.
4. If they don’t match, connector software knows there is potentially an OpenDNS problem in the network. It will update the HOSTS file on the home computer by adding the home server entry (with the IP from UPnP) in this case.
Looking at the steps above, there is a question though: why doesn’t the client just connect to the server by the IP it gets from UPnP? In most cases this will work, but unfortunately in scenarios related with Windows Home Server’s certificate, it will not work because certificates are bound with computer names instead of IP addresses.
Power Pack 3 does take security consideration into the solution. You don’t need to worry about messing the HOSTS file being edited. Unless there is a problem, Windows Home Server will not touch HOSTS file. The origin HOSTS file is kept as backup. If you uninstall the connector software all the windows home server entries in the HOSTS file will be removed.
Now with Power Pack 3, everyone will have no problem using OpenDNS with their home server.
For further support and questions, you can visit the Windows Home Server forum: www.serverplayground.com
The problem described occurs because some DNS servers do not follow the DNS standard, choosing instead to redirect invalid domain requests to their own servers for ad revenue. This can break some applications which expect or check for an NXDOMAIN response, in this case WHS was affected.
The problem can also occur with many ISP's default DNS servers, including my own (I'll refrain from naming names). This problem is relatively easy to spot because you can put nonsense names into your web browser and you do NOT get a web browser error page indicating the domain was not found, but a search page served by your ISP or DNS server provider.
I think It's worth noting that Google Public DNS prides itself on following the DNS API and properly returning NXDOMAIN for non existent domains. Though I personally recommend staying up-to-date on Windows patches, switching to Google Public DNS would also fix this problem. I've switched over to GPDNS from OpenDNS since day 1 and haven't noticed any problems.
tdallmann: The HOSTS file lookup is a standard procedure before checking a DNS server for a domain. Whenever your app looks up a domain name... unless you've coded your own DNS client and craft and send a query to a specific DNS server yourself... the APIs you use first check HOSTS and then send the query if the name isn't found.
It's a good way to "override" domain name resolutions (it can be used as a partial ad blocking solution, there are many lists available ready to go) or to assign a hostname to a computer when the application you're using is not netbios-aware or the server system doesn't have support for netbios (ex: Wii homebrew).
When I first setup OpenDNS, I discovered that this issue exists wwhen trying to access ANY computer on your local network. The solution turned out to be simple, though somewhat buried in OpenDNS's knowledge base. The solution is to use the "Manage VPN Exceptions" feature of OpenDNS. By adding your network domain (found using IPConfig /all) OpenDNS will let NetBios take over as it should. This seems preferable to having the connector muck around with the HOSTS file.