Do we have any list of significant applications, which use
/etc/resolv.conf only? It is used by most of DNS related tools I manage.
dig and host use dns only. Sure, they would not be able to report
split-DNS required hosts correctly. But browsers tend to use
getaddrinfo() glibc calls AFAIK. Can you name some important?
On 04. 06. 22 2:56, Michael Catanzaro wrote:
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.)
I admit dnsmasq, which I maintain, has existing integration with NM,
which can provide required functionality. It has its own set of problems
however, therefore I am not pushing it as a replacement in general.
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.
There is no real chance of DNSSEC increased adoption if default
configuration does not allow its use. I know there are more networks
where it is not working. But current setup prevents it use always, on
all networks. Even on those where it worked fine on f32.
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.)
Sure, I admit servers need DNSSEC more and are actually able to use it
already. Also tend to use more often more advanced DNS caches.
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.
Well, I had not reopened that bug only because it were slight
improvement. But I wanted it working in default configuration, which is
requested explicitly:
https://bugzilla.redhat.com/show_bug.cgi?id=1945309
You and I have exchanged few comments, but maintainers never wrote a
single line. What I would have a tracker for, when those bugs don't
receive a single comment after 6 months? I don't keep bitting by
resolved only because I always disable it ASAP on my machines. I report
every issue I find, but very little of them have any progress.
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
I can set severity in bugzilla, but they tend to be ignored. I don't
know how to express severity on github issues, which at least receive
some feedback.
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
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
