Lennart Poettering 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. It can work in company-scope if the company has competent network admins. My local DNS server at home resolves local hostnames to private IPv4 addresses in the 192.168/16 block. Clients on the Internet see another view. Both views are DNSsec-signed, and validation works fine. There's no reason why this setup wouldn't work on a corporate network. The key is to use a domain that is actually registered to the company, not some made-up TLD like "internal" or whatever the incompetent network admins come up with. >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. It would make more sense to select the "personality" based on what interface the client uses, than based on a DO flag in the query: Present actual standards-compliant DNS and nothing else on UDP and TCP port 53, and return your own synthesized stuff to programs that call getaddrinfo (and through the D-Bus interface I suppose). Nobody connects to port 53 expecting to get entries from /etc/hosts or LLMNR. Programs that do this expect only DNS – and they're likely to expect advanced DNS features to work, because they would have just called getaddrinfo if they weren't interested in advanced features. It could even be argued that returning non-DNS data through the DNS protocol is wrong, but if you can do it without violating DNS standards, then I don't think it will hurt. >systemd-resolved is not supposed to be a real DNS *server*. A real DNS server is however what existing programs expect to find in /etc/resolv.conf. >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. When I'm speaking the DNS protocol, then I don't mind "losing" LLMNR, MDNS and synthetic records, which never existed in DNS to begin with. It would however be good to have the split DNS feature, and I see no reason why that wouldn't work with DNSsec. Of course, whether a DO query gets a useful response depends on how good the respective upstream DNS servers are. Björn Persson
Attachment:
pgpAtqBFrl0gN.pgp
Description: OpenPGP digital signatur
_______________________________________________ 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
