Petr Menšík writes: Search the archives of the users list for systemd-resolved complaints. I've done my share. Perhaps a bunch of them coming from @redhat.com will result in some changes, but I doubt it.

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: 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. 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. 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. 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. 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

On Sat, Jun 4 2022 at 12:09:00 PM +0200, Peter Boy <pboy(a)uni-bremen.de&gt; wrote: Does running dnsmasq alongside systemd-resolved have many advantages over just switching to dnsmasq altogether? I would consider that instead. It's actually the opposite: how you have configured /etc/resolv.conf tells NetworkManager how you want to manage DNS, if you have no manual NetworkManager configuration specified. But you can edit NetworkManager configuration to choose whatever behavior you want. You want dns=dnsmasq: https://wiki.gnome.org/Projects/NetworkManager/DNS Michael

On 04. 06. 22 12:09, Peter Boy wrote: The problem with dnsmasq is it has just single upstream maintainer. Adding new features takes time and they are also not well tested. But as its maintainer I think it works much better than resolved. But admit it has much worse runtime reconfiguration interface, but capable to do what is required. Depends. Servers often produce much more queries, which would have higher impact if cache were poisoned. DNSSEC protects against that. Unlike weird networks laptop can be connected to, which does not pass required DNSSEC records, data centers usually provide perfect service including fully working DNSSEC. There should not be often reason to turn it off. I have just started discussion about this topic in our internal tech-list. I think there should be common interface for services, which provide any kind of network with dynamic dns to integrate subdomain into main host cache. Whether you use dnsmasq, unbound, systemd-resolved or knot-resolver, it should not matter how well itegrated they can be. If the server has runtime reconfiguration ability, there should be common way how it would allow subdomain redirection. If you use both podman and libvirt, they should be able to access each other via names. But that would be for entirely different thread. I have filled attempt to improve situation with /etc/resolv.conf ownership in PR [1], but it were not accepted well. I think resolved takes over /etc/resolv.conf even in case where it should not. If you disable systemd-resolved, it leaves your system without working resolution. Even reboot would not fix it automatically. It is fine to have /etc/resolv.conf missing in some cases, but that is not supported by resolved. 1. https://github.com/systemd/systemd/pull/21317 -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

On Sat, Jun 4 2022 at 04:07:09 AM +0200, Petr Menšík <pemensik(a)redhat.com&gt; wrote: No, I have no clue. But I'm pretty sure applications that do choose to use /etc/resolv.conf still deserve to receive correct results. On Sat, Jun 4 2022 at 04:07:09 AM +0200, Petr Menšík <pemensik(a)redhat.com&gt; wrote: I see Lennart responded in the upstream bug: https://github.com/systemd/systemd/issues/19227 although it's still waiting on him after a long time. This is an upstream issue, not a downstream issue, so I wouldn't expect much interaction in the downstream bug report. Michael

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(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

On Thu, Jun 09, 2022 at 08:53:01PM +0200, Petr Menšík wrote: Pull requests occasionally get forgotten. A comment with a ping usually helps. Zbyszek

On Sat, 2022-06-04 at 00:45 +0200, Petr Menšík wrote: An assertion like this ought to be backed with evidence. For the record, here are all the issues pemensik has filed against systemd upstream: https://github.com/systemd/systemd/issues?q=is%3Aissue+author%3Apemensik+ and downstream: https://bugzilla.redhat.com/buglist.cgi?component=systemd&email1=peme... so folks can read them and draw their own conclusions about the responses. There seem to be some which were addressed and closed, and some which have extensive discussion from various points of view. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net