Hi,
This would break split DNS for applications that read /etc/resolv.conf
directly. For desktop systems, that's generally way more important than
DNSSEC. For split DNS to work, /etc/resolv.conf needs to be managed by
either systemd-resolved or dnsmasq. We would go back to dark ages DNS
where requests go to the wrong VPN connection and where local network
devices like printers don't work as expected. (I understand that your
proposal would have no impact on applications that use glibc for name
resolution, but inconsistency in results when using glibc vs.
/etc/resolv.conf would be a pretty dissatisfying default.) In contrast,
DNSSEC is unlikely to be useful for most desktops unless adoption
improves dramatically, which seems unlikely. Accordingly, I do not
support your proposal.
For servers, the opposite is generally true: DNSSEC is generally way
more important than split DNS. Of course, there will be exceptions --
e.g. you're familiar with cases where DNSSEC is needed on desktops, and
servers on some complex networks apparently really do require split DNS
-- but it's true as a generalization. So if we are forced to choose
between working split DNS vs. working DNSSEC, I would pick the split
DNS for desktop editions, and DNSSEC for server editions. (On servers,
the main benefit of systemd-resolved is the DNS cache.)
Of course, it's best if we can do both well. I remember previously
watching systemd-resolved DNSSEC issues that you considered to be
important in:
https://bugzilla.redhat.com/show_bug.cgi?id=1879028
which were, eventually, mostly resolved. Based on your comment #28 in
that issue, I had understood that you were more or less satisfied. But
I see you've been discovering more bugs:
https://github.com/systemd/systemd/issues/created_by/pemensik
Perhaps it could help the systemd-resolved developers if you could
create a list/tracker with issues in order of priority/importance?
Having a tracker doesn't mean they'll be fixed, but it might help
attract attention to the bugs.
Michael
_______________________________________________
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
