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. Kevin Kofler -- _______________________________________________ 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
