[dns-operations] which breakage is this? FreeBSD.org / systemd-resolved

[Phil Pennock]

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