You are not logged in.
I'm using iwd and systemd-resolved with DNS over TLS enabled. The only time this is an issue is when connecting to public wifi because it won't let me access the captive portal.
Currently my workaround is to:
- disable DNS over TLS by commenting out the line in a drop in file in /etc/systemd/resolved.conf.d/
- restart systemd-resolved.service
- navigate to neverssl.com (which takes me to the captive portal)
- connect to the wifi
- reenable DoT (repeat the first two steps)
My question: is it possible to whitelist (blacklist?) neverssl.com so it won't use DoT but everything else does?
I know I can tell specific networks to use a certain DNS and settings with files in /etc/systemd/network/ but I'm not sure how I can apply rules to only specific websites or if it's even possible.
My best guess would be a file in /etc/systemd/network/ with:
[Match]
Name=*
[Network]
Domains=~neverssl.com
DNSoverTLS=false
I would appreciate some insight before telling me to test it myself because it'll be extremely tedious to troubleshoot with my only way of testing being to connect to random public wifi.
Thanks!
Offline
If you specify an IP address for neverssl.com in /etc/hosts no DNS lookup of any kind will be done for that domain, so no other changes should then be needed.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Online
Thanks! I'll give this a try tomorrow and report back.
Offline
It didn't work, but I think it's because DoT is getting in the way of the redirect to the captive portal and/or fully connecting to neverssl.com.
I used
getent ahosts neverssl.com
to get the IP address and put it in /etc/hosts as
<IP address> neverssl.com
. I still couldn't connect actually connect to neverssl.com, probably because I wasn't fully connected to the internet yet via the captive portal.
I can't think of way to allow all captive portal redirect attempts to bypass DoT without setting DNSoverTLS to opportunistic which I don't want to do.
If anyone knows of way to do this I would appreciate it. Do captive portals use a standard routing protocol that I could take advantage of? Or has anyone else found some workaround for this situation? For public wifi I regularly use, I might be able to use some utility to see what connections it's attempting and add those to /etc/hosts, but I don't know how to do that and it seems like it would be very tedious. Otherwise, I'll probably try to write a script that will toggle DoT for me so I don't have to do it manually with the steps I described in my first post.
Offline
Do captive portals use a standard routing protocol
Sadly no. There may be some patterns, such as all startbucks' networks using a similar set up, but the bagel shop across the street could use an entirely different approach.
Captive portals suck. Always. The use of captive portals has actually become a significant factor in whether I'd frequent a business like a cafe or other place where I might bring a computer. (Note, this is a general statement that I assume applies also to DoT issues; but again, I've not actually used DoT myself).
Last edited by Trilby (2024-10-02 12:54:57)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Online
I recommend captive-browser for situations like this. It'll setup a socks proxy that sends all DNS requests to the specified resolver _instead_ of sending them to your system's DNS resolver.
Offline
In Firefox on site which is not encrypted by default you can click on padlock in address bar and select "Temporary disable" to "automatically switch site to secured connection".
Then in address bar remove 's' from 'https' and reload page.
You can also go to "Settings > Privacy & Security" and on the bottom disable "server DNS over HTTPS". It works instant, so you don't have to restart browser, just reload page.
Last edited by xerxes_ (2024-10-02 16:47:14)
Offline
I recommend captive-browser for situations like this. It'll setup a socks proxy that sends all DNS requests to the specified resolver _instead_ of sending them to your system's DNS resolver.
This seems like this would probably do I what I want. However, it does not appear to be maintained (I suppose maybe it's 'complete') and requires that I download Chrome which I'd rather avoid.
I might try to set it up for Firefox as described here. I'm leaning more towards trying to learn the required skills and create the tool from scratch myself. I've always been horrible at networking related things, so I've been trying to learn regardless.
For my case, would it be as simple as setting up a proxy with DoT disabled and a Firefox profiles to use this proxy? Maybe it's even as simple as setting up a Firefox profile with DoH enabled in settings instead of system DNS. I don't really need it to do anything fancy or be completely automatic since Firefox handles things just fine when DoT is disabled. I could just create an alias that would open the Firefox profiles and navigate to neverssl.com. Firefox does all the things captive-browser seems to do (like detecting the captive portal) given that DoT is not enforced. Would there potentially be anything insecure about this method that captive-browser addresses or that I would need to account for?
Appreciate the help!
Offline
You can also go to "Settings > Privacy & Security" and on the bottom disable "server DNS over HTTPS". It works instant, so you don't have to restart browser, just reload page.
That's easier than what I currently do, and I definitely should have thought of that but it doesn't really do much in the way of automating the process. I'd prefer to not have to do extra work after connecting to the network and have to remember to reenable my DNS config after using the captive portal.
Offline
Did you tried add captive portal site(s) by "Exceptions" button (or something like that - I don't have en locale) which is near options related to "server DNS over HTTPS"?
Last edited by xerxes_ (2024-10-03 09:41:17)
Offline
In Firefox, I have my DNS set to be managed by my system and not by Firefox so that wouldn't really work. Setting exceptions is essentially what I was trying to do but locally instead of through Firefox, but as I discovered, it's more difficult than expected to set an exception for one--let alone all--captive portals because of they all work in different ways.
Offline