On Mon, Jan 15, 2024 at 11:32 AM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Petr Menšík wrote: > > systemd-resolved is unfortunately known to broken. > [snip] > > Dnsmasq does not break DNSSEC, systemd-resolved does. > [snip] > > Unfortunately broken are clients having systemd-resolved enabled. > > How exactly is it broken? If you refer to: > https://github.com/systemd/systemd/issues/25676 > fixes for that are finally coming in now (as of 3 weeks ago). > > > I would recommend having systemd-resolved forwarded to dnsmasq, which can > > then be forwarded further. > > If you think dnsmasq should replace systemd-resolved by default, then please > propose that through the Changes process, which will also ensure the glibc > resolver, NetworkManager, and the like get configured properly for it. > Simply shipping dnsmasq with a default configuration that conflicts with > systemd-resolved is not a productive approach. > > If systemd-resolved is really broken, then it either needs to be fixed or > replaced. The former needs to be handled through systemd upstream, the > latter through the Fedora Changes process. > > > But this change should create conflict with systemd-resolved only in case > > it was improperly configured. > > But the default configuration you ship will conflict. > > > Anyway, dnsmasq will listen by default on 127.0.0.1, as every standard > > resolver does. You can use listen-address=127.0.0.53 if you like, but > > then it will conflict with systemd-resolved. > > You just wrote that you make it listen by default on all interfaces, and > then filter. This means it will conflict over the port 53. That said, > listening on the lo interface only will also conflict with systemd-resolved > or any other local resolver, so you are probably right that your change does > not change much for the default configuration, it just makes it harder (more > settings to change) to set up coexistence. 127.0.0.53 is unfortunately not > an independent interface, it is still the lo interface. > > > On 14. 01. 24 1:57, Kevin Kofler via devel wrote: > >> On a server I administer for work, I have dnsmasq serving the DNS for an > >> ocserv (OpenConnect) VPN, listening only on the VPN interface. Any > >> request for a host not within the VPN network (coming in from clients > >> with no or broken split DNS support, e.g., old GNU/Linux distros without > >> systemd- resolved, or Windows, where the OpenConnect client is still > >> unable to set up split DNS) is forwarded to systemd-resolved, which in > >> turn forwards it to the upstream DNS from the datacenter. Relying instead > >> on the filtering would not have worked exactly for the reason you > >> describe above. But that server is not running Fedora anyway. > > > > I would recommend to skip systemd-resolved stub and using > > resolv-file=/run/systemd/resolve/resolv.conf > > > > in such case. It would use servers configured by systemd-resolved, but > > without using broken port domain at address 127.0.0.53. Alternatively > > use server=127.0.0.54, which should not break incoming queries so much. > > Well, I do not see a good reason to disable systemd-resolved for the > server's own queries (which includes the forwarding queries from dnsmasq, if > the domain is not one it knows). It just works. > > > Consider using unbound as a cache for other VPN clients. dnsmasq is > > great for its integration with DHCP server, but is targeted to use > > minimal resources. Unfortunately at cost of some design issues. Unbound > > is a high quality cache, while still relatively small compared to bind's > > named.service. > > Using minimal resources is exactly what I want here. Which is why I do not > want to use dnsmasq for what systemd-resolved can do, nor unbound for what > dnsmasq can do. > > And sending the server's own queries through dnsmasq is not going to work > (not without a second instance, at least), because the VPN server is not a > VPN client, so I have the server's /etc/hosts resolve its own domain to > 127.0.0.1 (not the public IP, because services listen only on localhost and > the VPN, that is what the VPN is for), which is honored by systemd-resolved, > whereas my dnsmasq configuration overrides this to return the VPN IP to the > VPN clients querying that same domain. Sounds hackish, but works great. > Based on my reading of this thread, this change is going to break the default configuration and needs to be reverted immediately. Petr, please file a Change Proposal for Fedora *41*. You have missed the deadline for F40 System-Wide Changes (Dec. 26th) and this is absolutely NOT a self-contained Change. -- _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
