WPAD ideas and considerations

What can we keep and what do we need to get rid of in WPAD?
Please add to this list

WPAD currently has two well-known methods:

1) DHCP assignment

Pros:
 - DHCP ID code already available and well-known
 - simple URI for PAC file works well for those using DHCP on the network.


Cons:
 - ID code limited to URI of PAC file for legacy implementations
 - fixed information. Requires another DHCP allocation to change (or
client to poll the DHCP server)

Things I'd like to see in an upgraded version:
 - ability to avoid PAC and simply point at one proxy FQDN:port the
client is to use.
 People with DHCP should be able use the DHCP server config to send each
network range at proxies relevant to that client range without needing a
PAC to duplicate the information.


2) DNS search

Pros:
 - does not require DHCP
 - can be supported by a wider range of clients more easily than DHCP
 - DNS TTL can be specified to cause refresh of the PAC information at
network admins choice of timing.

Cons:
 - current implementations use a scan of DNS label names for wpad.*
 - several different client algorithms used to scan DNS. At least one of
which is seriously broken.


Things I'd like to see in an upgraded version:

- drop the scan algorithms.
- use of SRV. I propose using _http._pac.local as the FQDN for proxy
identification since _http._tcp should be left for local origin servers.
  This *._pac.local also allows for _ftp.* _https.* or any other
protocols that want to auto-configure a proxy to share the SRV structure.
 => I realise there is the multicast responder problem to work around in
.local. Anyone have a good idea that avoids scanning DNS, mandatory TLS,
or complicated N-way authentications?


Amos

Received on Friday, 14 March 2014 04:47:29 UTC