LinuxQuestions.org - dhcpinform clogging my system.log

iam searching thru google and some how i just read the same problem and he explain why winxp broadcast continues:

WPAD, or Web Proxy AutoDetection, is a protocol that was designed to convey Netscape's PAC format (Proxy Auto Config file) to web browsers automatically - without the user ever having to type a button. It never became an RFC proposed standard, but rather died as an Internet-Draft. I can only wonder what politics led to its demise...but it's full of wonderful hints of terrible flamewars, including the admission that the option code, 252, was 'assigned by the DHC WG chair.' Maybe I need to point out: option codes are never assigned by WG chairs...they are assigned only by IANA after standards action. Meanwhile, 252 is in the "site-local" space - it is not available for allocation! Not by a WG chair, not even by IANA. The site-local options were intended for site administrators (your network's sysadmin) to allocate - not manufacturers.

But its failure to reach RFC did not stop it from becoming the Internet's de facto standard in configuring web proxies. Consequently, whenever your Windows box boots, it tries WPAD to find proxies in order to get Windows Updates...Automatic Updates does this a few minutes after a box reboots. The first thing to do in WPAD is to try DHCP, so you might see Windows boxes try DHCPINFORMs first requesting option 252. They'll try several times until they get 252, and if they never get it, they move on to DNS. They'll query 'wpad.foo.example.com' if foo.example.com were the configured domain name, then 'wpad.example.com', then they give up. They're looking for A records, although the WPAD standard also describes TXT and SRV records (it never tries these). WPAD also describes using SLP after DNS, but I sincerely doubt anyone bothers.

The DNS method is essentially garbage being flooded out on the global Internet. Some older implementations seem to seek right down to 'wpad.'. It seems this is tried in others if no domain name were specified. Your ISP has to deal with wpad.ispname.com being queried all the time, and the rest of the Internet has to cope if the system has some garbled domain name...the query gets passed all the way down to the roots and up.

Edit 2008-08-13: It's also a security problem! Dan Kaminsky has reminded us that it is still, even with all our protections (short of DNSSEC), quite possible to manipulate DNS data. A ne'er do well that creates a cache entry for 'wpad.etc' in front of a horde of WPAD-capable clients can become the man in the middle for all their web content. You can filter for WPAD DNS queries, but it's easier to just make them stop querying for it.

The way to stop all of these clients that implement WPAD from querying DNS at all is to give them a poison pill at DHCP time; or heck configure WPAD at DHCP time and start providing a caching proxy service. I'll show you how to do both below the cut.
In ISC DHCP's dhcpd.conf, enter:

# WPAD definition

option wpad code 252 = text;

# Suppress WPAD activity - no cache, no DNS.

option wpad "\n\000";

# Configure a valid WPAD cache. The \n is required for Windows.

# All config below this line is optional.

#option wpad "http://www.example.com/wpad.pac\n";

# Special config for Windows ("MSFT 5.0") systems.

# Note this does not catch Windows CE.

class "MSFT" {

match if substring(option vendor-class-identifier, 0, 4) = "MSFT";

# They put 252 on the DHCPINFORM's, but not on the DHCPREQUEST's

# PRL. So we over-ride the PRL to include 252 = 0xFC, which will also

# suppress the DHCPINFORMS!

option dhcp-parameter-request-list =

concat(option dhcp-parameter-request-list, fc);

}

Now if you want to use a real cache instead of just poisoning WPAD to keep it from trying DNS, use something like the 'real cache' example in the above config snippet (commented out). Replace www.example.com with your handy web server. You have to configure the server to serve the wpad.pac file, and to set the right MIME type for it.

So on your webserver, first in apache's httpd.conf, enter in a MIME type pairing:

AddType application/x-ns-proxy-autoconfig .pac

Note that it appears x-ns-proxy-autoconfig is a deprecated MIME type for PAC files, but Windows (as of XP) will not digest a PAC file of the 'standard' MIME type.

Then, create a wpad.pac file. I recommend you start simple, see that it works, and then move onwards;

function FindProxyForURL(url, host)

{

return "PROXY 192.168.0.1:3128 ; DIRECT";

}

Note that this is javascript. You can use any javascript function to do arbitrary things; you can return multiple PROXY lines, or return different PROXY lines for different conditions (a classic example is to distribute queries to an array of caches based on some consistent policy; to improve cache coherence on each cache...all a* names to cache 1, all b* names to cache 2, ...).

Finally, I've found that although 'Microsoft Industry Updater' (automatic updates) will use the above by default, IE out-of-the-box on Windows XP needs to be told to find caches automatically. I don't know if there's another way to coax it into this state of affairs (some vendor-encapsulated option?). It rather defeats the purpose of automatic discovery if it takes manual intervention to enable it tho. If you know of a solution here, please leave a comment.

Edit: It seems something called GPO can be used to push a group policy that sets the 'Detect proxy Automatically'

I follow the suggested solution and its stop? for now iam observing the fault pc i hope it work!