<div dir="ltr"><div>Short version:</div><div><br></div><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>We will be changing the behavior of GetHostByName to be a raw mapping to the underlying Unix gethostinfo information, and removing some of the special behavior we added in 2005 to try to mimic the Windows DNS API.</div><div><br></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>This will break applications that depended on this idiom to work:</div><div><br></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>Dns.GetHostByName (Dns.GetHostName ())</div><div><br></div><div>To return the list of publicly visible names/IP addresses associated with the host.   </div><div><br></div><div>Fix: Use System.Net.NetworkInformation APIs instead.</div><div><br></div></blockquote></div><div>On Friday we were debugging a curious issue with HttpListener that fixes an old bug.</div><div><br></div><div>In the past, HttpListener would start a listening socket on all interfaces, regardless of a hostname being specified.  For example ("localhost:8080") would listen on both the 127.0.0.1 interface as well as your public IP address on port 8080.</div><div><br></div><div>This was changed to require "*" to have this behavior, and altered so that you would need to explicitly list all the IP addresses or hostnames that you wanted to listen to manually.   So if you did "localhost:8080", this would only listen on the lo interface, and if you did "<a href="http://MyPublic.host.name.com">MyPublic.host.name.com</a>", it would only listen on the interface that had that name/ip address on the host.<br></div><div><br></div><div>But back in 2005, we implemented a behavior to track the Windows behavior on the Dns class:</div><div><br></div><div><a href="https://bugzilla.novell.com/show_bug.cgi?id=MONO63265">https://bugzilla.novell.com/show_bug.cgi?id=MONO63265</a><br></div><div><br></div><div>It has the following side effect: when the name of the host passed to GetHostByName matches the DNS hostname (which we implement with a call to gethostname), instead of returning the actual IP address for the device, we adopted the Windows behavior that would list all-non-localhost addresses, *excluding* the localhost address.</div><div><br></div><div>It boils down to an attempt to make this idiom:</div><div><br></div><div>GetHostByName (Dns.GetHostName ())</div><div><br></div><div>Return a list of interfaces associated with the host.</div><div><br></div><div>This is only a problem when your hostname is set to "localhost", and while not very common, it happens in the wild. </div><div><br></div><div>There was at least one bug that claimed that a feature of Remoting depended on this:</div><div><div><br></div><div><a href="https://bugzilla.novell.com/show_bug.cgi?id=MONO54234">https://bugzilla.novell.com/show_bug.cgi?id=MONO54234</a><br></div><div><br></div><div>Our plan right now is to remove the special behavior, which means that code that expected the above idiom to return the list of host interfaces from the current hostname will not work anymore.</div></div><div><br></div><div>That should have never worked in the first place, it just happened to be mostly correct on Windows.    The proper way of retrieving the list of network interfaces on .NET is not to use the DNS lookup system, but to use the System.Net.NetworkInformation APIs.</div><div><br></div><div>Miguel.</div><div class="gmail_extra"><br></div></div>