On 2020-10-30 at 06:22 +0100, Vladimír Čunát wrote: > On 10/29/20 8:31 PM, Phil Pennock wrote: > > the alternatives for a roaming laptop are even buggier (in the > > resolver management, rather than in the actual resolver). > > Can you expand a bit on what you mean by this? I think people here are > more likely to affect some of the alternatives rather than systemd-resolved.
Sure. (Mostly I was asking in case I'd missed something I could sanely fix on my side; but sometimes auth domain hosters can change their behavior to not tickle systemd-resolved's bugs, so if this could be identified as something freebsd.org is doing and could fix, that would help). For DNS resolution, kresd and unbound work great. Where the resolver configuration is static, such as in servers, I use those. So I install Unbound on VMs in AWS, for instance, configured to handle .internal separately, validate what it can, etc etc. That's not a problem. On a laptop, you discover when roaming that suddenly you're on a network where the only DNS upstreams are doing 464XLAT and all DNSSEC verification breaks, so you need to be able to handle that _sometimes_ DNSSEC is just not viable. You don't have IPv4 connectivity to the real public IPv4 addresses, so using different upstreams won't help. You just have to accept that on such a network, MitM on DNS is required for connectivity, so DNSSEC is broken and you need to limit what actions you take across a network. Then if you're using WiFi in coffee-shops you'll not have connectivity until you use a captive portal, and the captive portal will tamper with DNS. So you need to be able to _temporarily_ disable DNSSEC, for just long enough to login at the portal, then flush all caches from that period and re-enable DNSSEC (possibly using DoT or DoH to use upstream resolvers elsewhere); until you do this, you don't have network connectivity (except in some old setups which mostly died out with the introduction of 8.8.8.8: security-by-obscurity doesn't work when the obscure becomes commonly known). Both of those modes are ones which directly affect me. Google Fi is using 464XLAT. So the important part for a laptop, or a portable device, is not really the resolver itself, but the _resolver management_ (and any features the resolver offers to the resolver management to make integration easier). The only software I have experience with for this, beyond the systemd/networkmanager integration, is "dnssec-trigger"; I've had great success with it in the past on macOS, with the system tray integration etc. Alas, when I tried dnssec-trigger on Ubuntu, my logbook records that things failed but I didn't record the nature of the failures; I tried this on 2020-02-20. I remember repeated segfaults in dnssec-trigger and that I tried various things (including building current source, etc), but I don't have a record of the different things. I did record a URL: https://www.redpill-linpro.com/techblog/2019/08/27/evaluating-local-dnssec-validators.html and looking again now, that looks like it's a worthwhile read for anyone here. So: I'm currently stuck with systemd-resolved on my laptop because of a lack of good options for managing the lifecycle of a DNS resolver on a laptop, which integrate reliably with both NetworkManager and the resolver, in the above scenarios. (And I currently have enough other commitments that I can't write a fix myself.) -Phil _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
