I’m trying to run an DoH, etc. DNS setup on my laptop for better privacy, but every time I need to use it in a hotel, I can’t get Hotspot sig-in etc. to work at all, and then I can’t nixos-rebuild switch my way out of it, so I’m stuck which is frustrating.
Does anyone happen to figured it out alrady and have a working config?
nixos-rebuild switch --offline should take care of that. Switching your system configuration to use a different DNS server seems silly to me, though.
If you use NetworkManager, you can use nmcli to temporarily switch off a DNS server for a specific connection, though this requires you to set up NetworkManager to manage DNS in general, and in turn means you need to configure each connection to use a specific DNS server individually, which is a bit of a PITA.
IMO a nice generic solution to various DNS configuration problems is to use a local “stub” dns resolver, e.g. unbound, which just forwards your queries to whatever you configure it to, and usually locally caches resolved domains, which is a nice side-effect (in fact, why isn’t this set up by default more?). These usually have fully-fledged DNS server features, so you if you configure them as your nameserver, you can in turn use normal DNS server configuration to make it do just about anything.
Unbound specifically has a cli tool which you can use to update its settings at runtime, and you can use that to update the forward-zone to point at whatever the network you just connected to uses as its DNS server, which will let you resolve whatever login page you need to access, after which you can just use the cli tool to switch back to your chosen DNS server. I’d personally write some scripts to do that.
I’ve not made the switch to secure DNS yet, but here’s my config to set up unbound with the basics to make unbound-control work: dotfiles/nixos-config/networking/default.nix at f95801fef3c6017d901de0fef252878ef37e90e0 · TLATER/dotfiles · GitHub
Its configuration is a lil’ confusing if you haven’t worked much with DNS before, though, and it’ll take a bit of scripting. Do please share if you try this, I’d quite like to set this up as well, just haven’t gotten around to doing so yet 
You can do some really neat stuff in general with this, I for example use unbound to automatically resolve server domain names through a wireguard network after NetworkManager brings it up, so that I can whitelist my IP address without having to set that to an address that may or may not be static (and controlled by an ISP), as well as to redirect hostnames on a local zone to a qemu bridge, which lets me test servers deployed into VMs with real host names - quite handy when you use reverse proxies to create subdomains.
I do actually use unbound, with nextdns DoH config, but I can’t connect to hotspots. I went through couple of iterations of the config using different underlying things, and I always hit problems when I travel, revert to plain-default-like setups which seems to fix the issue.
I’m just tired of it, and I don’t really have a good way to test when I’m not traveling.
Fundamentally I’d like my DNS queries to go through DoH or whatever else that makes them more private, but not have to struggle when traveling.
Yes, that’s exactly what I’m describing a solution for. You need to switch from your DNS servers to whatever DNS server the captive portal’s IP is available on so that you can get through the captive portal (or I guess sometimes switch DoH off completely in the scenario in which it is most likely to help you ;p).
To be able to query the IP of their captive portal you’ll need to use their DNS server. To do that, you need to temporarily switch from unbound to resolving requests through the DNS server their wireless network told you to use via DHCP.
If you want to achieve that without switching your build-time configuration and having nix rebuild your entire system just to change a simple setting, you can write a script that does something like this:
#!/bin/sh
dhcp_dns="$(grep nameserver /run/NetworkManager/resolv.conf | cut -d ' ' -f 2)"
unbound-control forward ${dhcp_dns} # deliberately unquoted
That’ll - with any luck - make unbound forward DNS requests trough the local DNS server.
After you’ve gone through the captive portal, you can just undo that and reset from your configuration:
unbound-control reload
… and you’ll actually be using DoH in the one scenario in which you’re actually likely to benefit from the privacy/security it offers.
I haven’t actually tested this, but my entire point is that if you use a DNS resolver that you can instruct to do things at runtime, you can sidestep the whole configuration rebuilding thing because now you can change DNS configuration at runtime
Thank you. I was not aware of unbound-control, and I think I understand everything else going on here. This script might work just fine for me.
BTW. Do you have any good sources w.r.t state of art architecture of DNS system in Linux / NixOS? Your response reminded me that every time I’m dealing with it, it’s a maze of overlapping solutions (e.g. systemd resolved, unbound, Network Manager, DHCP client), etc. which I’m navigating puzzling pieces together. How it is set up in NixOS makes sense and I can tell that people behind it put a lot of thought in it, but it’s not easy to understand in its entirety.
Nope, sorry. It’s just the general state of networking on desktop Linux, a mix of lots of antique things and a few newer components that are slowly finding their way into modern distros.
NixOS puts you in charge of configuring them, so the sorry state the world is in is a bit more obvious.
I think for similar issues there was dnssec-trigger, but I don’t really know what’s a good automatic way here. Captive portals are quite a pain in multiple respects. DNSSEC validation using Unbound and DNSSEC-Trigger | Cybersecurity | SIDN
Oh, yes, dnssec-trigger looks almost perfect; it even gives you a notification if it suspects you’re behind a captive portal. AFAICT it’s automatic as long as you’re using NetworkManager.
My only small gripe is:
DNSSEC-Trigger first tries to use the (caching) resolvers supplied by DHCP. When doing so, DNSSEC-Trigger does not rely on the AD flags sent with the DNS responses, but validates the responses and associated signatures itself. As a result, you have end-to-end validation, but you also have the benefit of a shared external cache.
Still gives good security, but not privacy. unbound does support NODATA, so at least you shouldn’t be vulnerable to hotspots hijacking real domains when using this; I’ll have to look upstream if they support disabling this part of the functionality so other features still work.
ETA: Sadly the project looks pretty dead.
GitHub - FiloSottile/captive-browser: A dedicated Chrome instance to log into captive portals without messing with DNS settings. is packaged in nixpkgs.