I reviewed your pull request https://github.com/systemd/systemd/pull/21317. I know you are trying to move things forward, but at the same time, you're not really responding to feedback. Despite two versions being pushed in the meantime, my re-review was to a large part a repeat of what I posted in January. I said that the approach looks promising, but if you want the patches to be merged, they need to be adjusted to be acceptable for upstream. Zbyszek On Sat, Jun 04, 2022 at 04:07:09AM +0200, Petr Menšík wrote: > 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 _______________________________________________ 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
