Dns.GetHostEntry: No such host is known
We had a really weird scenario debugging a MacroView ADO.NET based package today. The package was running on a Windows Server 2003 machine connecting to a local MacroView Linux server. Typing in the IP address of the Linux server kept coming up with a “No such host is known” error when initiating the MacroView ADO.NET connection. The weird part was that other machines on the local network connected fine and running telnet with the relevant port number on the problem machine also connected successfully. My first thought was some sort of program specific firewall setting, but that turned out not to be the case.
To cut a long story short, the problem was related to a combination of migrating the MacroView ADO.NET code to Visual Studio 2005 and the behaviour of Dns.GetHostEntry when compared to Dns.Resolve. The ADO.NET provider was first developed using Visual Studio 2003 and .NET 1.1. At the time the Socket.Connect methods didn’t have an option to pass a host name as string to the connect call. The TcpClient class had this functionality, while the Socket class provided more control in other areas but would only take IPAddress objects in the Connect calls. The Dns.Resolve method was used to get an IPHostEntry which was then used to create an IPAddress to pass to the connect calls. This all worked fine.
When it came time to upgrade to Visual Studio 2005, the compiler complained that Dns.Resolve was obsolete and that Dns.GetHostEntry should be used. I made this change along with others to get the unit tests passing on .NET 2.0. The problem that was lurking under the covers was that when a numeric IP address was specified in the connection string, the Dns.GetHostEntry somehow figured out the actual destination machine name even though the machine in question could not resolve the host name if typed in explicitly. The Socket used this destination machine name and then failed the name to address resolution. I don’t know the exact details of what was going on under the covers, but the solution was simply to use the new .NET 2.0 Socket.Connect methods that take a string host name as a parameter.