On Mon, 2022-05-30 at 12:49 +0200, Petr Menšík wrote: > On 5/28/22 22:22, Thomas Haller wrote: > > As you say, NetworkManager can run dnsmasq as DNS plugin by > > configuring > > `[main].dns=dnsmasq` in `man NetworkManager.conf`. > > > > In that mode, NetworkManager will spawn the dnsmasq process. > > Doing that is undesirable, for several reasons. > > > > I agree, it would be much better, if dnsmasq could run as a > > separate > > service. In the best case, dnsmasq could be D-Bus activated, then > > it > > doesn't even have to be a systemd service (altough, on systemd > > systems, > > of course systemd would start the dnsmasq service). > > > > When would dnsmasq reload those files? Usually, we would prefer > > that > > everything can be configured via D-Bus. Of course, if dnsmasq by > > default runs without D-Bus, then that wouldn't work. What would > > those > > configuration snippes contain beside `enable-dbus`? > I thought it could contain dnssec for selected networks. However that > is > not possible to set via dbus (or alternatives). It requires restart, > because some structures are initialized different way. Just pure > reconfiguration by re-reading config file is not enough. It would > require no small changes in dnsmasq to allow enabling validation > runtime.
If we had a system wide dnsmasq instance (that NetworkManager talks to), then I think it would be up to the admin (or the distro default) to set dnssec. Likewise for enable-dbus. Just as the admin has to set `dns=dnsmasq2` in NetworkManager.conf, they would also have to make sure that D-Bus is enabled. IMO, D-Bus is just a useful and basic IPC mechanism, it's not a cumbersome dependency that users need to avoid. So, I'd be fine if that dnsmasq service is shipped with "enable-dbus" on by default. And if not, it's up to the admin to change that. What NetworkManager provides is per-interface configuration, nameservers, DNS searches, and maybe some nameserver specific dnssec settings. But not the basic dnssec/enable-dbus settings. Then, NetworkManager would not need to drop conf snippets and not restart the service. If you compare with wpa_supplicant.service, it also is D-Bus activatable and has D-Bus enabled... at least on distros where users expect to use NetworkManager with wpa_supplicant. See `systemctl cat wpa_supplicant.service`. > > /etc/NetworkManager/dnsmasq.d is a semidocumented thing, where > > users > > could hack the setup by dropping snippets. I wonder how bad it > > would be > > to move away from the way how we do it currently. Maybe we could > > symlink all files there from /run. Or maybe we would need to add a > > separate dns=dnsmasq2 plugin for the new way. > > > > > > I would prefer the notion that dnsmasq is just running as a stand- > > alone > > service, and NetworkManager can push interface-specific DNS > > configuration to it (basically, like with systemd-resolved) and > > also > > with the notion that there could be other services that configure > > their > > part. For example, WireGuard's wg-quick could configure the DNS > > server > > on the WireGuard interface (though, currently I think that would > > call > > /usr/sbin/resolvconf -- unless systemd-resolved is detected). > > There is a problem that no generic interface good for reconfiguration > of > running services exist. resolvconf can configure something and > openresolv package attempts to do such thing. /usr/sbin/resolvconf would be such a generic API. It doesn't have to be openresolv. For example, Fedora has no openresolv package. However there is a resolvconf compat binary which directly talks to systemd- resolved. NetworkManager itself can be configured to call resolvconf and talk to systemd-resolved's native API. But NetworkManager won't ever be a provider of an resolvconf API. That is because NetworkManager is a service that can configure your local caching DNS service, but it does not pretend to be that service itself. If you currently use `dns=dnsmasq` in NetworkManager, then you'll get a split-DNS setup, but that is not extendable/accessible to to be configured by other tools. Which can be a very fine thing for certain uses!! But we won't extend that. What we could do, is that dnsmasq itself becomes a central service that NetworkManager talks to ("dns=dnsmasq2"). If dnsmasq would want to fill the space of systemd-resolved, it either needs a resolvconf backend, or provide a general API that independent services can cooprerate on. NetworkManager won't need to talk resolvconf however, it can directly implement dnsmasq's native API (as it does today). For NetworkManager this API also doesn't need to be "very general" either. That then just means, it would be less likely that other services would also use it. Btw, dnsmasq is a very fine and useful tool that can already do many things. It's not clear to me, that it also needs to become an alternative for systemd-resolved. dnsmasq supports many use-cases that systemd-resolved never will, and the opposite is fine as well ("do one thing, well"). What is the actual problem you'd like to solve? > It is possible to make > generic query to dbus (or varlink?) which services provide some > interface? Programs/services can provide a well-known D-Bus name, that others can introspect. Run `d-feet` and see what is on your system-bus. > Then VPN could send required configuration to all interested > providers. I am not working with dbus often. What would be the best > way > for other services to provide unified API? > > I doubt we want each VPN provider to implement all possible DNS > caches. > Can generic api be used instead? yes, that's a problem. Either - /usr/sbin/resolvconf, either by integrating in openresolv (which isn't currently in Fedora) or by providing an alternative implementation like systemd-resolved does. (I don't like resolvconf very much). - Make the API similar or even identical to systemd-resolved's API. For example, ConsoleKit2 provides a very similar API as logind. That can make implementation for users simpler. - invent a new one generic API :) - have a dnsmasq specifc API - any combination of the above. best, Thomas _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list