Blog: WPAD

I had needed to make a change to a customer’s WPAD file to add a direct access  location. I made my changes and tested it only to find out that it didn’t work. I decided that I would check and make sure the client could access the WPAD file, so I tested access to HTTP:// SERVERNAME/ WPAD.dat. I was able to see the changes I had saved in the file.  However, the client still didn’t seem to be following the rules. I tried changing the  Automatic Settings in Internet Explorer Proxy settings to use HTTP:// SERVERNAME/ WPAD.dat specifically as the proxy script to use.  As long as I had the Automatic Settings unchecked and the path to the WPAD file defined in the script box, it worked. However, I needed to make sure it would work with Automatic Settings instead. [more]

What I found out was that a client gets it’s instructions about the location of the WPAD file to use through DHCP option 252. Upon checking the settings of this option, I found that it was using HTTP://WPAD/WPAD.dat instead of SERVERNAME. The DNS entry for WPAD was an alias that pointed to SERVERNAME. I went back to the web browser and went to HTTP://WPAD/WPAD.dat.  I discovered that it did not have the changes that I had made even though HTTP://SERVERNAME/WPAD.dat was correct.  On the WPAD server, I restarted IIS and checked it again.  This time, both WPAD.dat files had my changes and the Automatic Settings began working successfully.

It appeared to me what happened was that IIS was serving a cached version of the WPAD.dat file when browsers tried to connect to the DNS alias while the actual server name was not cached. 


I was recently configuring an ISA server for a network support customer including automatic configuration using WPAD.  The customer had a 2008 SBS server and a 2003 ISA server (running ISA 2006).  I added a "wpad" alias (CNAME) to the DNS server on the SBS box to allow clients to automatically detect the new ISA server.  However, when I tried to resolve the entry on the SBS server as well as other hosts on the network, it never would resolve.  I tried other CNAME entries on the server, and they all worked fine.  I tried removing the entry and reading it, but got the same behavior.  I decided to let it sit overnight to see if it was a timing issue.  The next day, I still couldn’t resolve "wpad" or "wpad.bofc.local".  I started digging and found that the DNS service on Windows Server 2008 has a built-in "block list" for some potentially dangerous DNS names.  The default list includes "wpad" and "isatap".  Gotcha!  Since I wasn’t concerned with blocking any DNS names, I decided to turn off the "block list".  I used the following dnscmd command: [more]

dnscmd /config /enableglobalqueryblocklist 0

Other helpful commands when dealing with this include (from

To check whether the global query block is enabled, type the following:
dnscmd /info /enableglobalqueryblocklist

To display the host names in the current block list, type the following:
dnscmd /info /globalqueryblocklist

To disable the block list and ensure that the DNS Server service does not ignore queries for names in the block list, type the following:
dnscmd /config /enableglobalqueryblocklist 0

To enable the block list and ensure that the DNS Server service ignores queries for names in the block list, type the following:
dnscmd /config /enableglobalqueryblocklist 0

To remove all names from the block list, type the following:
dnscmd /config /globalqueryblocklist

To replace the current block list with a list of the names that you specify, type the following:
dnscmd /config /globalqueryblocklist name [name]…