On Do, 16.04.20 12:49, Florian Weimer (fweimer(a)redhat.com) wrote:
As explained elsewhere, NetworkManager-openvpn extracts the search
list
from OpenVPN parameters, passes that to NetworkManager, which I expect
will pass ito to systemd-resolved in the future.
>> Ugh. That will have to be fixed, otherwise it will break DANE/TLSA
>> and
>> other DNSSEC-mandatory functionality on upgrades: the system used to
>> have a DNSSEC-clean path to the outside world, and after the switch to
>> systemd-resolved, it won't.
>
> I think that, if you need DNSSEC, you will just need to enable it
> manually. I think >99% of users won't need to do this, and it's a
> one-line config file change for power users who do need it, just edit
> /etc/systemd/resolved.conf and then restart systemd-resolved
> service. Problem is that DNSSEC is just not safe to enable by
> default. :(
See my message to Lennart about separate DO/CD query caching.
My point is that these users *have* enabled DNSSEC in their
infrastructure, and we break what they have during an update (assuming
that DNSSEC=off means that systemd-resolved turns DNSSEC-unware, rather
than just disabling validation).
Maybe a safer bet might be to leave resolved off during upgrades on
the server edition?
I don't think we can reliably determine whether people have deployed
things in a way that relies on /etc/resolv.conf only listing a fully
blown DNS server or who are fine with it being a more restricted stub
like systemd-resolved.
I'd claim it's reasonably safe to declare that on workstations having
a restrictive stub between local clients and a real DNS server is OK,
but maybe for servers we don't want to make such a claim, dunno, and
just enable this for newly deployed stuff but not on upgraded stuff.
Lennart
--
Lennart Poettering, Berlin