upvote

points

by itake15 hours ago |
comments
upvoteby jer0me12 hours ago|
next
[-]
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é.
reply
upvoteby itake4 hours ago|
parent|
next
[-]
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?

reply
upvoteby gjvc11 hours ago|
parent|
prev|
[-]
prefer this form:

    echo "nameserver 192.168.1.1" | sudo tee /etc/resolver/captive.apple.com
reply
upvoteby boramalper13 hours ago|
prev|
next
[-]
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.

reply
upvoteby itake4 hours ago|
parent|
[-]
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)

reply
upvoteby microgpt7 hours ago|
prev|
next
[-]
Just put an IP address into your address bar. They're usually intercepting all port 80 traffic.
reply
upvoteby charcircuit13 hours ago|
prev|
[-]
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