On Thu, Oct 8, 2020 at 1:28 pm, Paul Wouters <paul(a)nohats.ca> wrote:
I agree for two reasons. One, the FESCO decision to postpone making
systemd-resolvd the default resolver. I would like to ensure this
change happens properly and securely for f34.
Well it's too late, since we are now in final freeze. FESCo reaffirmed
the systemd-resolved change just last week, so it's clearly not going
to be postponed. I agree that this DNSSEC problem with systemd-resolved
is unfortunate, and I'm sure the systemd developers would appreciate
help fixing it. Anyway, the best time to deal with this would have been
six months ago, when the change was proposed....
I am still trying to
use this setup on my f33 with DNSSEC enabled for systemd-resolved,
and do still seem to have issues that I'm going through to see if
these are related to DNS or not. I feel we should have this working
solidly first, before we are adding more options and features into
the mix.
That's why we did this in two parts. F33: systemd-resolved. F34: DoT.
We could have done them both at once.
Second, we really need any DNS-over-TLS to not break DNSSEC. If we
are
going to outsource validation to a remote endpoint via DNS-over-TLS,
instead of using the local resolver or the local ISP resolver, then
data authenticity becomes eveb more important. And DNS-over-TLS only
provides transport security, not data origin authenticity.
Look, I really don't understand, sorry. How is this in any way related
to DNSSEC? I think this has zero relation to DNSSEC. Are you assuming
that we're going to ignore DHCP-provided DNS and hardcode 1.1.1.1 or
8.8.8.8? The change page says we will not do that.
Michael