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]

 



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

[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