On Mon, Sep 28, 2020 at 11:04 AM Lennart Poettering <mzerq...@0pointer.de> wrote:
> On Mo, 28.09.20 18:36, Florian Weimer (fwei...@redhat.com) 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
