Hacker News Reader

Comment by itake | Hacker News Reader

Does anyone have advice on how to use public wifi alongside DNS resolver?

Many public wifi network works need you to use their DNS, so they can redirect you to a gated "accept ToS" screen (and may even require re-approval every 30-60 minutes).

To resolve the issue is so frustrating:

1. realize the internet stopped working 2. ping google.com, wait for timeouts to show up. 3. try to guess if its a ISP issue, but then realize the wifi probably timed out. 4. Switch the dns. Flush DNS. 5. try to access a non-TLS domain 6. approve the gate 7. switch the DNS back

There has to be something that manages this

View on HN

On macOS, you might be able to use /etc/resolver to fix this:

  sudo sh -c 'echo "nameserver 192.168.1.1" > /etc/resolver/captive.apple.com'

I did this for an internal website at my university that could only be resolved using the network name server. It just occurred to me that it might also work for the URL macOS uses to detect captive portals. We'll have to see if it works the next time I'm at a café.

prefer this form:

    echo "nameserver 192.168.1.1" | sudo tee /etc/resolver/captive.apple.com

I think what may happen with this is:

Captive.apple.com resolves to captive portal domain

Captive portal domain fails to resolve because the portal is private and Google DNS doesn’t know about it.

Might work for captive portals that Google can resolve though?

For macOS and iOS, you can create a profile to configure which DNS server you want to use at all times (including across different Wi-Fi networks and mobile data). See:

https://doh.lvv.me/

That’s what I’ve been using for years and never had any issues with public hotspots.

I want the DNS to resolve the captive portal when it needs too.

I think if I force the dns this way, the public dns won’t resolve the captive portal.

When the internet is cut, it needs to use the network’s dns to resolve the captive portal domain (whatever that is)

I've seen some routers that will just silently redirect anything on port 53 to their own idea of the best dns server to use. That would probably "fix" this problem, but I always thought it was a little shady to redirect stuff like that. Makes troubleshooting problems difficult if you don't know it is happening.

Just put an IP address into your address bar. They're usually intercepting all port 80 traffic.

this only works if the captive portal's domain is also in the public dns.

Some captive portals are only accessible in the private network.

This is something your OS should handle as part of the OS's support for captive portals. I'd recommend contacting your OS's creator about this and filing a bug.

Reply on news.ycombinator.com