Hacker News Reader

I noticed an issue with several public WiFi hotspots after setting 1.1.1.1 as my primary DNS:

The login/"landing" page when connecting to these hotspots would not load. Changing back to 8.8.8.8 fixed the problem.

That means they're intercepting requests to 8.8.8.8 (even if only before login), probably because of its popularity. It's a shame we still have to use these hacks to login; there's a solution for that in RFC7710 (which sends the captive portal information in DHCP), but who knows if and when it'll be adopted by most hotspots.

https://tools.ietf.org/html/rfc7710

I thought the way these Wifi hotspots worked was that they intercepted all DNS traffic? How else would they work with legacy systems?

Modern OSes detect these login pages by making a DNS lookup of a known domain, eg. macOS/iOS lookup "captive.apple.com", and if the answer is not in the 17.0.0.0/8 subnet they know someone is intercepting DNS and show the Wifi login window.

A lot of captive portals use HTTP interception/redirection, returning a 30X status instead of the expected 204 status.

> That means they're intercepting requests to 8.8.8.8

No, it means their hotspot uses 1.1.1.1 as internal IP. I've seen this in a bunch of places.

Cisco gear is probably the biggest culprit in my experience.

Reply on news.ycombinator.com