On Mon, Sep 28, 2020 at 11:04 AM Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:
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.
Indeed, the problem you're trying to solve is hard.
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.
Then perhaps you should have a libsystemdresolvedclient and start convincing programs that want this behavior to use it.
_______________________________________________ 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
