I was at a customer today who was in the process of moving their AD from Windows Server 2003 to Windows Server 2008 x64 platform. In the process at some point he changed the DHCP servers to use the new Windows Server 2008 based DC/DNS servers for name resolution. He then said he was having issues with name resolution and said the problem disappeared when he used the Windows Server 2003 based DC/DNS.
I wasn't sure whether I could believe him 🙂 I did some tests using nslookup and dcdiag and then assumed it was a non existent issue. However, he reproduced the issue. I was absolutely amazed at the time as the same query done on W2K3 worked but it didn't on W2K8. This was for a record that was in an AD integrated zone and so I didn't want to assume a corrupt zone. Netmon traces clearly showed the record as non existent despite visible in dnsmgmt.msc and dnscmd.
Then I did what I should have done first. I checked the event log :-). In there was an event about "global query block list". The record that they could not resolve was an important record. I.e. it was the wpad record for proxy settings. In this case the customer had literally typed wpad into the proxy server settings (instead of the proxy server name) along with the relevant port. wpad resolution is typically only required if "Auto detect settings" checkbox is selected to detect the proxy settings. As they were literally using the name "wpad" in the proxy settings dialogs box, they couldn't access the Internet.
With the mystery solved I proceeded to advise them of the behaviour and point them at Technet resources for more details. The recommendation was to change the proxy settings to use a more meaningful name such as the real proxy server name as they were not reliant on auto proxy settings discovery. Please see Managing the Global Query Block List for details.