Bug#1017128: systemd: systemd-resolved split breaks existing setup

[andu232]

On Sunday, August 14th, 2022 at 8:50 PM, Michael Biebl biebl at debian.org wrote:

> How does this setup look like? Appears quite exotic so it helps if you
> could explain it in more details how your system is configured.

Before explaining how does it look like, I think it would be better to
make clear the reason for having another resolver.

DNS over TLS and DNSSEC can be a good friend to someone who wants enhances
privacy and security, and always use DoT first, only falling back on failure
should be an ideal option, that systemd-resolved is not adequate for.

If one would like to have DoT, DNSSEC, and fallback works with systemd-resolved,
he might want to append DoT upstreams to systemd-resolved with DHCP DNS
untouched, then switch on DNSSEC. Unfortunately, this won't work as expected,
the reasons are listed below.

First, systemd-resolved always uses DHCP advertised DNS servers first and
renders DoT useless, since queries are sent to DHCP advertised servers anyway,
which usually does not come with DoT capabilities.

Secondly, systemd-resolved tries to stick to a server when it works and will
switch to the next on failure,[1][2] this policy does not work well under this
setup.
DoT may fail temporarily under some circumstances, such as time not being
synced yet, or simply a package loss that fails TLS handshake.
systemd-resolved will just get rid of DoT upstreams after this happened once,
this also invalidates DoT.

And the third one, since upstream may not support DNSSEC, one might want to set
DNSSEC=allow-downgrade to allow systemd-resolved to make its own decisions.
However, systemd-resolved will fail to resolve names, due to bugs.[3][4][5]

So it is necessary to have another resolver doing DoT and DNSSEC properly.
But this also has its shortcomings. If DoT fails because port 853 was blocked,
or local time has not been synced yet, the only way of getting the network
working is to fall back to normal DNS queries. Thus, it is also necessary to
have a fallback server, which is supposed to support using DHCP DNS list and
make sure it just works, what systemd-resolved is good at.

Then let me explain how it works.

Unbound is used for querying from DoT upstreams, validating DNSSEC signatures,
and systemd-resolved for querying from DHCP DNS servers with neither DoT nor
DNSSEC enabled.
resolv.conf can be modified easily by inserting 'lo.unbound' to the beginning of
/etc/resolvconf/interface-order, a file provided by resolvconf.

This is what a generated /etc/resolv.conf looks like:

nameserver 127.0.0.1
nameserver 127.0.0.53
options edns0 trust-ad

DNS queries are sent to unbound first, try to get DNSSEC signed answers from
DoT upstreams. If it fails, then let systemd-resolved do its job.

> I don't think we want to do that.
>
> What we could do though, is create the symlink in postinst as a one-time
> only measure. The local admin could then override it afterwards.

I dug a little bit and found this change is meant to resolve #939904.

In my humble opinion, making a separate package to install symlink should be
sufficient, making systemd-resolved itself conflicts with resolvconf hardly
provides additional benefits and breaks existing setups.
Maybe keep systemd-resolved separated and ship another package called
something like systemd-resolvconf which installs symlink, and is recommended by
systemd-resolved can keep the changes and make sure the existing system works.

[1] https://github.com/systemd/systemd/issues/21174#issuecomment-957424959
[2] optinally, begin every transaction with first DNS server in list instead of last working one
    https://github.com/systemd/systemd/issues/5755
[3] systemd-resolved fails to fall back to non-DNSSEC style requests in allow-downgrade mode.
    https://github.com/systemd/systemd/issues/21107
[4] systemd-resolved: SERVFAIL instead of NXDOMAIN when DNSSEC=allow-downgrade
    https://github.com/systemd/systemd/issues/19472
[5] First DNSSEC failure passed on even with allow-downgrade
    https://github.com/systemd/systemd/issues/10579