I’m responsible for a bunch of IoT hardware, and every firmware spec I write includes a note on not using the DNS servers provided via DHCP. While sure there are companies explicitly doing this to avoid filtering, at least in my case it’s because a significant proportion of DHCP servers are configured to send DNS to your ISP, and ISP provided DNS is almost universally terrible. They’ll ignore TTLs, rewrite NXDOMAIN r…
> and ISP provided DNS is almost universally terrible. They’ll ignore TTLs, rewrite NXDOMAIN responses into the IP address of their ad-laced web search, and occasionally just highjack every single query to send you to a page saying you’re approaching your bandwidth quota Universally? Perhaps in the US? But IoT devices are sold worldwide. While I do run my own recursive resolver I checked my ISP's and they're behaving…
I was troubleshooting an issue where a company's client computers which connected to the company VPN wouldn't have internet access post-connection.
The problem turned out to be that instead of sending a NXDOMAIN they'd return their ad server and then _always_ send back some JS to show ads.
The company network used PAC files (these are a piece of JS with a single FindProxyForURL() function) via an internal-only URI to steer most requests to our proxies, while keeping some internal.
The problem came about when clients would first start up the OS would attempt to access the internal-only URI before the VPN client finished connecting. In a normal network it'd get nothing and life would carry on. With this problematic ISP they'd get something that /should/ have been a PAC file, but because it was some other piece of JS without FindProxyForURL() it wouldn't work as a PAC file and thus the client wouldn't go to the proxy.
The expiration on this piece of JS was set to some absurd amount of time, so when the client would eventually try hitting our PAC file server again (happens every 20 minutes on Windows) it wouldn't get our file because it thought the garbage one from the ISP was newer. And the ISP updated their hijacking JS more frequently than we updated our PAC file.
There were two possible solutions to this. One, routinely touch the PAC file so it's date was newer than whatever the ISP put out. Or two, set up an external A record for the internal PAC server name to keep the hijacking from working. We went with the second.