Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mo, 28.09.20 18:36, Florian Weimer (fweimer@xxxxxxxxxx) wrote:

> * Andrew Lutomirski:
>
> > Paul may well have been mixing different things here, but I don't
> > think you answered the one that seems like the most severe problem:
> > systemd-resolved removed perfectly valid DNSSEC records that were
> > supplied by the upstream server.  One might reasonably debate whether
> > Fedora's default DNS resolver configuration should validate DNSSEC,
> > but I think it should honor the DO bit in client requests and return
> > DNSSEC data.
>
> FWIW, this is <https://bugzilla.redhat.com/show_bug.cgi?id=1879028>.

It's on the TODO list. But this creates probems of its
own. Propagating DO stuff as is cannot work for LLMNR, mDNS,
company-scope DNS and so on, i.e. anything that isn't the official
Internet DNS.

systemd-resolved is not a traditional DNS server after all. It is a
client to classic DNS, MulticastDNS, LLMNR, local definitions from
/etc/hosts, synthetic records such as _gateway, localhost and the
local hostname and similar, and then exposes the combination to
clients. It also is capable of (limited) merging of DNS zones from
different sources (think: you have a VPN connection with some zones
the official internet doesn't have). Only one of these backends has a
concept of DNSSEC + DO: classic DNS talking to upstream Internet DNS
servers. Thus exposing DO to clients is a bit weird, it suggests
clients could validate whatever we return with DNSSEC, but that isn't
doable, stuff that doesn't come from classic Internet DNS cannot
possibly be DNSSEC validated. So we'd have to have a weird split: for
some domains we could propagate DO stuff, but for others we simply
have to block out, because the requests simply doesn't make sense for
it. What's worse, resolved would start having a split personality: for
DO replies we'd propagate the 1:1 upstream responses, while for
everything else we'd return our own stuff, from our own synthesis,
sourcing and and son. A local DNS client talking to resolved would see
a feature set that would be very different depending if you ask with
or without DO, because if you ask with DO you effectively just talk to
one of the upstream servers, while without you will speak to
systemd-resolved. I can tell you from implementing much of
systemd-resolved: dealing with a server that in some conditions acts
like X and in other conditions like Y is super annoying. Many many
home routers act like that: they synthesize records for the admin UI,
which work very differently protocol-wise then talking to proper
public Internet.

systemd-resolved is not supposed to be a real DNS *server*. It's
supposed to be a good, combined client for the popular name resolution
protocols, and the fact that we also listen on a port 53 is mostly to
provide compat with local app code that doesn't go through glibc NSS
for its name resolution needs. If you expect a full blown DNS server
on port 53 then it's not what systemd-resolved is or strives to be.

So far we side-step the DO issue by returning a clean error when
clients set DO: "not implemented", plus a log message in syslog with
more info. I'd argue that for the vast majority of users this is
perfectly enough. Because IRL client-side DNSSEC doesn't really exist
outside of some very specific circles of DNS nerds, I guess. Yes, I
dare to suggest that for your typical GNOME/Fedora Workstation it
really doesn't matter.

I understand that some people want DNSSEC/DO stuff work client side
just like that, and as mentioned we'll add that, but let's not pretend
this was "obvious" and without pitfalls of its own. I understand some
loud people here consider Internet DNS the true gospel, and mDNS and
LLMNR and all kinds of other forms of popular name resolution, local
and remote heresy, but I think we just have to agree to disagree here:
i am interested in a *client* solution that speaks the big protocols
deployed today, that supports talking to company-scope DNS servers,
and that's not just DNS but also Microsoft-style LLMNR and Apple-style
mDNS.

Until we implement the DO-bypass stuff, there's an easy way to bypass
systemd-resolved for your DNSSEC resolver needs: just symlink
/run/systemd/resolve/resolv.conf to /etc/resolv.conf (i.e. instead of
/run/systemd/resolve/stub-resolv.conf). If you do that all local DNS
clients will use the upstream DNS servers resolved picked up directly,
bypassing resolved. But of course, if you do that then you also lose
LLMNR, mdns, all local synthetic records, merging of VPN zones and so
on. If you do things like this, then resolved will work like a
re-implementation of the "resolvconf" tool that Debian and FreeBSD
have, not more (it does provide a command line compatible binary for
that btw). I have the strong suspicion that the same people who are
able to deploy working DNSSEC client side and are educated enough in
DNSSEC to know what that even means are also capable of replacing that
one symlink in /etc.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux