Over the last few weeks, as mentioned before, my colleagues and I have been working to implement a proxy server solution. One of the more aggressive bugbears we’ve fought is the size and complexity of our network — we have dozens of different network segments, some of which have pre-existing proxies, many of which are out of my team’s control. Finding a solution that worked well, everywhere, was tricky. But we’ve made progress.

PAC files haven’t changed substantially in over twenty years. There’s no formal RFC or clear standard defining how they work. As near as I can tell, everyone is still working from this old chestnut, written by Netscape in March 1996. There’s no reliable way to get your own IP address, or to get your public IP address, for instance, which makes location awareness tricky. We needed a way to know if a user was on-site or off-site, and to potentially apply different proxy policies.

One of the side effects of our large and complex network is that we have so-called “split-horizon DNS,” where some DNS hostnames resolve to different values based on whether you’re on-site or off-site. While this won’t work for everyone, I figure most organizations large and complex enough to need a proxy, probably can also implement DNS servers. (ISC BIND, for instance, makes it relatively easy.)

We created two different DNS entries for our proxy, thus:

Internally: proxy.our.org resolves to 10.100.100.1
Externally: proxy.our.org resolves to 192.0.0.101

Then, early in our PAC file, we added a line like this:

if (dnsResolve('proxy.our.org') != '10.100.100.1') return 'DIRECT';

If a machine is on-site, DHCP will tell it to use our internal DNS servers, the proxy’s hostname will resolve to the internal IP, and the PAC file continues executing; you can then make your code as complex as you like. If the machine is off-site, the hostname will resolve to a different IP, and the PAC file will quickly stop executing.

You want the proxy’s external IP address to resolve to something (probably not your proxy, but maybe…). If the name doesn’t resolve externally, some ISPs will hijack the DNS non-response, which will slow things down a bit for off-site users.