After the problems with network location ignorance the other week, and being an inquisitive type, I decided to dig a little deeper and see if I could identify why my sever was unsure about the type of network is was connected to. For some while I’ve had occasional issues with web browsing where page requests immediately throw up an error that a URL cannot be found, but refreshing the page in the browser works fine. And, of course, the odd Event Log message that “Name resolution for the name [some domain name] timed out after none of the configured DNS servers responded.”
I keep coming back to the conclusion that there is a DNS error somewhere in my network setup, but I’ve never been able to trace it. However, after some experimenting with nslookup I discovered that querying for a domain outside my network without adding a period (.) to the end of the domain name resulted in a response giving that domain name with my own FQDN domain appended to it, and it always resolved to the address 22.214.171.124. This seems wrong. For example, querying for “microsoft.com” returns “microsoft.com.[my-own-domain].com with the IP address 126.96.36.199, whereas it should return something like 188.8.131.52. But appending a period to the query (“microsoft.com.”) gives the correct result.
So I query the weird IP address and it resolves to “advancedsearch.virginmedia.com”. Which, if you query it as a DNS server (“nslookup microsoft.com advancedsearch.virginmedia.com”) just times out. It isn’t a DNS server. I use NTL Business Cable as one of my ISPs, and they are a branch of Virgin Media, so I can see where the IP address is coming from. I also have two valid Virgin Media DNS servers I can use, so I repeat the lookups specifying one of these to try and discover where the strange behavior is coming from.
It turns out that the Virgin Media DNS servers have a neat trick: if they receive a request for a domain they can’t find, they automatically return the IP address of the Virgin Advanced Web Search page. As the browser does a DNS lookup by appending the machine’s domain name if it can’t find the one requested (I assume this happens because the default network connection setting in the DNS tab of the Network Connections dialog is to append the primary suffixes to the domain name for resolution of unqualified names), the Virgin Media DNS server responds with the requested domain name plus the machine FQDN and the IP address of the advanced web search page.
My internal DNS servers have forwarders set up for resolution of external domain names, and I had added the two Virgin Media DNS servers to the list along with the DNS servers of my other ISP (British Telecom). Repeating the tests against the BT DNS servers shows that they don’t do any fancy tricks. Looking up a non-existent domain simply returns a “Non-existent domain” message. So I removed the Virgin Media DNS servers from the list of forwarders in my internal DNS and it stopped the weird “advanced search” behavior happening. And, so far, it also seems to have stopped the problems of failed lookups and “Name resolution timed out after none of the configured DNS servers responded” errors in the server’s event logs.
Removing the Virgin Media DNS servers from the list of forwarders also looks like it has stopped the occurrence of exessive non-TCP requests being sent out onto the net from my domain controllers. My ISA Server occassionally reported that they were opening more than the maximum configured number of non-TCP connections, and these turned out to be DNS lookups. but, of course, it could all just be a wild coincidence.
But I can’t help wondering why, for a business connection where you’d expect people to run their own DCs and DNS servers, they decided it’s a good idea to return the address of a web search page from a DNS lookup query. Perhaps they get paid a bonus for each click-though…
Footnote: If you are looking for alternative DNS servers to use, you might like to try the Google ones (see http://code.google.com/speed/public-dns/). I’m using these at the moment, with no problems detected so far.