Hacker News Reader

Comment by jchw | Hacker News Reader

I’ve been gleefully watching DNS over HTTPS break all kinds of things that are terrible practices, including ISPs that hijack NXDOMAIN responses for SPAM search pages even when using other DNS providers.

Here’s to hoping someone comes up with better solutions for captive portal redirects, though.

View on HN

It's almost like the purpose of an ISP is to transmit internet traffic to the internet for you--not to filter traffic, block certain ports, lie about DNS responses, or otherwise have anything to do with the actual content of your communications. Imagine if the telephone company listened to you calls to block prohibited topics, replaced the other person's responses with ads, and opposed people who tried to talk in code.

It's definitely a Good Thing that technical measures are rendering this garbage unworkable.

I believe there's been a better solution to captive portal redirects for quite some time now, via the medium of DHCP and/or RAs - https://tools.ietf.org/html/rfc7710.

Unsure why we've not yet seen much adoption.

I've seen almost universal adoption of it (at hotels, airports, etc). Since around 2 years ago nearly all the networks I connect anounce their portals through DHCP.

Interesting to hear! Do you mind sharing your rough location?

I live in Brazil, on those last years I've also traveled to Mexico and Cabo Verde, visiting airports also on Panama and Portugal.

I've notice the DHCP announcements on all those places.

My workaround for using captive portals with DoH is to authenticate on my phone first, then disable WiFI on the phone, then basically run this script to switch my laptop to my phone's MAC addr.

```

sudo systemctl stop NetworkManager wpa_supplicant avahi-daemon

sudo ifconfig <your_interface_name> down

sudo macchanger <your_interface_name> --mac="$1"

sudo systemctl start NetworkManager wpa_supplicant avahi-daemon

sudo ifconfig <your_interface_name> up

```

It's stupid and hacky, but it works perfectly 99% of the time.

Should be easy to work around in the short term. The browser just needs to request a well-known "test" domain (like example.com) and detect if it gets a redirect. Keeps portals working without compromising the privacy of real DNS lookups.

The problem is that if you're using something like stubby[1] then there's no easy way to temporarily tell it to use another DNS server to resolve the name you need to get to the captive portal. At least as far as I can tell, it doesn't offer that feature. You would need to be able to resolve whatever domain the captive portal is using as well, so you couldn't just hardcode it into `/etc/hosts` either.

https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+...

My go to: captive.apple.com

Similar, but another option is neverssl.com

Reply on news.ycombinator.com