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. 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@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
