OK so which is more likely to play nice with constantly changing wireless connections? DNS-over-TLS, DNS-over-HTTPS, or DNSSEC? I notice that out of the box, Windows and macOS and Fedora all just defer to the DNS servers that are assigned by DHCP, which come from the local AP. So I'm pretty much stuck, out of the box, with AP specific DNS policy.
> OK so which is more likely to play nice with constantly changing wireless connections?
If you use a public resolver that supports it (such as Cloudflare's 1.1.1.1), I think you'd probably be best served by DNS-over-HTTPS as it uses 443/TCP.
DNS-over-TLS (supported by 1.1.1.1 and 9.9.9.9) would be my next choice, but since it uses 853/TCP, you might run into issues if/when you encounter a wireless network that blocks outbound access to this port.
DNSSEC, if you ran your own validating resolver on your laptop, should work regardless of the network you are connected to (as it just uses 53/UDP), but with the caveat that DNSSEC does not provide privacy (just "response integrity", as noted by the RFC).
> ... out of the box, Windows and macOS and Fedora all just defer to the DNS servers that are assigned by DHCP ... So I'm pretty much stuck, ...
Even when using DHCP, you should still be able to manually configure the DNS servers you want to use. AFAIK, this is still possible on any OS (but I haven't used Windows for years, nor OS X for quite a while). For example, on my laptop (which also hops between wireless networks), I run my own resolver (unbound, which points to a recursive resolver on the Internet that I control) and use DNS-over-TLS (on 853/TCP).
For more information, see the DNS Privacy Project's web site (wiki) [0].
If you run and fully control your own recursive resolver, it's also possible (but non standard) to run DNS-over-TLS on port 443. The general steps are to install stunnel for a TLS proxy on the DNS server, set it up with the appropriate public/private keys, and then have stunnel forward traffic to localhost:53 on the same machine.
DNS over HTTPS (DoH) is available now in Firefox Nightly; the beauty is Firefox can use (for example) Cloudflare’s DoH servers regardless of what the system’s DNS settings are—even on macOS: https://facebookexperimental.github.io/doh-proxy/tutorials/f...
I've been using dnscrypt-proxy to access 1.1.1.1 using DNS-over-HTTPS for over a week. Absolutely no problems so far switching between wireless connections; writing this sat in a pub, tethered to my iPhone.
Not sure how I'll go with captive portals that rely on DNS hijacking, but worst case I just switch to using their DNS servers for a brief period.
For a decade or more I always ran all my traffic through a VPN, and ran into problems with captive portals. The way I solved it was that I would let DHCP update my resolv.conf file, and then my VPN "up" script would overwrite resolv.conf to use localhost as the name server. Sometimes I would have to open a browser and go to an IP address in the URL bar to get the redirect. This all worked out pretty well, only maybe once a quarter did I have to go in and manually resolve some captive portal issues.
DNS over TLS uses a new port. If you're on an enterprise network, its firewall probably blocks that port.
DNS over HTTPS is being discussed to resolve that problem. The downside is it doesn't really exist yet.
DNSSEC doesn't do anything for query privacy (in other words: most of the reasons you'd use DNS-over-TLS aren't addressed by DNSSEC). DNSSEC is a bad standard whose primary impact on the Internet would be to replace the LetsEncrypt CA system with a PKI run by world governments. That sounds like something InfoWars would say, but I promise you, DNSSEC is weirder than InfoWars.
What is the point of "query privacy" when browsers send host addresses in plaintext (SNI) and destination IPs are still visible to the internet provider?
Layering DNS over TLS (or anything else) is meaningless, it increases RTT (and thus response time) without any benefit for most users.
It's mostly for preventing DNS response integrity I'd say.
Using DNS over HTTPS or over TLS to hide traffic from your ISP is utterly meaningless. I don't know why people are advocating it for 'privacy' from your ISP.
For privacy, one would just use a VPN for all their traffic and using DNS over HTTPS matters much less, given that the DNS resolver is also being routed over the VPN connection (if it does at all).
The only use I see is that if you're visiting a HTTPS website, and it doesn't have HSTS (or if you're visiting a website with HSTS for the first time), it prevents phishing (for less tech-savvy since one would notice that it won't be TLS) people.
This use is further diminished if Firefox and other browsers start implementing the HSTS preloading[1] feature like Chrome, and people actually start submitting their domains for inclusion. Which I don't see happening soon, so it has some use case.
None of the above. Captive authentication portals are common in most "constantly changing" wireless client scenarios. Many use a DNS MITM approach that requires you to have working DNS service to the resolver you were provided by DHCP, and few today permit HTTPS service to DNS servers at any address, especially 1.1.1.1. Enforcing DNS-over-TLS, -HTTPS, or DNSSEC on your wireless client will not be a viable configuration in these real-world instances.
DNS over QUIC has a concept of an IP address independent session id, which maintains the crypto state and session state across multiple IP bindings. i suspect you're heading to a space where DNS on QUIC is better for you than DNS on TLS.
DNSSEC is for authoritative signing of domains, not TLS1.2 level security for an individual client (stub resolver) requesting a record from a recursive resolver.
DNS-over-TLS and DNS-over-HTTPS accomplish the latter.
jlgaddis' answer addresses it quite well. One note to add, if you're on a wifi network where you know that the DHCP server assigns IPs in a certain range (such as from 10.100.100.80 to 10.100.100.250) and you have the correct WPA2-AES key, you can totally associate to the wifi, disable DHCP and manually assign yourself the static IP of 10.100.100.70 or whatever, the correct default gateway, and manually chosen DNS servers.
> I'm pretty much stuck, out of the box, with AP specific DNS policy.
It certainly isn't "out of the box", but on the off chance it's useful to you -- you can change dhclient (/etc/dhcp/dhclient.conf) to specify your own DNS servers. This is what I do, pointing at a bind instance I run, and it provides plenty of warm feels. Or, heck, you could run a full resolver locally.
