In order for all browsers in an organization to be supplied the same proxy policy, without configuring each browser manually, both the below technologies are required: The WPAD standard defines two alternative methods the system administrator can use to publish the location of the proxy configuration file, using the Dynamic Host Configuration Protocol (DHCP) or the Domain Name System (DNS): Before fetching its first page, a web browser implementing this method sends a DHCPINFORM query to the local DHCP server, and uses the URL from the WPAD option in the server's reply.
If, for example, the network name of the user's computer is pc.department.branch.example.com, the browser will try the following URLs in turn until it finds a proxy configuration file within the domain of the client: (Note: These are examples and are not "live" URLs due to them employing the reserved domain name of "example.com".)
Additionally on Windows if the DNS query is unsuccessful then Link-Local Multicast Name Resolution (LLMNR) and/or NetBIOS will be used.
Then, it "moves up" in the hierarchy by removing more parts of the domain name, until it finds a WPAD PAC file or leaves the current organisation.
[7] In order for WPAD to work, a few requirements have to be met: While greatly simplifying configuration of one organisation's web browsers, the WPAD protocol has to be used with care: simple mistakes can open doors for attackers to change what appears on a user's browser: Through the WPAD file, the attacker can point users' browsers to their own proxies and intercept and modify the WWW traffic of everyone connected to the network.
A presentation at Kiwicon showed that the rest of the world was still critically vulnerable to this security hole, with a sample domain registered in New Zealand for testing purposes receiving proxy requests from all over the country at the rate of several a second.