GNOME.org
 

Re: dnsmasq integration improvement suggestion

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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]