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, an
Re: dnsmasq integration improvement suggestion
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. > /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. It is possible to make generic query to dbus (or varlink?) which services provide some interface? 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? > best, > Thomas -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dnsmasq integration improvement suggestion
On Fri, 2022-05-27 at 15:30 +0200, Petr Menšík via networkmanager-list wrote: > Hi! > > I were thinking how could be Network Manager's integration with > dnsmasq > improved. > > Today it is running separate service in NetworkManager.service. I > thought about possible solution and think have found solution. > > Dnsmasq can include all files with matching pattern from a directory. > On > Fedora, it uses /etc/dnsmasq.d for normal service and > /etc/NetworkManager/dnsmasq.d for dnsmasq running from dns=dnsmasq > mode > in NM. > > What if default dnsmasq.service just included also > /run/dnsmasq.d/*.conf? That would allow starting real dnsmasq.service > from NM. But it could add additional configuration snippet into > /run/dnsmasq.d/NetworkManager.conf, for example enable-dbus. It would > then be able to also enable dnssec validation just for some > connections. > When NM would need to stop dnsmasq, it would make this file empty. > > What do you think about this integration? Would it be better than > bundling dnsmasq into NetworkManager.service? > > Cheers, > Petr > 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`? /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). best, Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
dnsmasq integration improvement suggestion
Hi! I were thinking how could be Network Manager's integration with dnsmasq improved. Today it is running separate service in NetworkManager.service. I thought about possible solution and think have found solution. Dnsmasq can include all files with matching pattern from a directory. On Fedora, it uses /etc/dnsmasq.d for normal service and /etc/NetworkManager/dnsmasq.d for dnsmasq running from dns=dnsmasq mode in NM. What if default dnsmasq.service just included also /run/dnsmasq.d/*.conf? That would allow starting real dnsmasq.service from NM. But it could add additional configuration snippet into /run/dnsmasq.d/NetworkManager.conf, for example enable-dbus. It would then be able to also enable dnssec validation just for some connections. When NM would need to stop dnsmasq, it would make this file empty. What do you think about this integration? Would it be better than bundling dnsmasq into NetworkManager.service? Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dnsmasq integration? (was: Re: NM trashing resolv.conf when a connection fails)
On Thu, 2011-01-06 at 17:37 -0500, Paul Smith wrote: > Hm. I'm looking through lots of NetworkManager pages/docs and the GIT > repositories, and I see that there has been something titled "Local > caching nameserver support using dnsmasq" added in 0.8.2. Unfortunately > that's just about all the information I've been able to come up with as > to what this means or does. > > Based on that small sentence and a _very_ quick browse of the code it > sounds a lot like what I've been playing with, although I was working > with a small inotify-based solution that would watch /etc/resolv.conf > and reconfigure dnsmasq appropriately. Unfortunately as one could > probably have guessed, applications that modify /etc/resolv.conf are > simply not well-behaved (including NetworkManager... see my issue in the > previous post) which makes this pretty difficult. > > > Is there any documentation on exactly how this dnsmasq integration in > NetworkManager works, and/or can anyone who is working with it give me a > quick overview? 'man NetworkManager.conf' has a short overview of the DNS plugins available. You can either use nothing (which works just like before) or you can use dnsmasq. There's a BIND plugin that but isn't working yet. Basically, the LCN support just runs dnsmasq in a LCN configuration, and when DNS changes, NM rewrites the dnsmasq config file and restarts dnsmasq for the changes. The config you'll get is like this: server=/redhat.com/10.7.142.20 server=/10.in-addr.arpa/10.7.142.20 server=/16.172.in-addr.arpa/10.7.142.20 server=4.2.2.1 server=4.2.2.2 where I've got a VPN connection to Red Hat, and queries for anything Red Hat related go to internal nameservers, and reverse-DNS queries for subnets served by the VPN *also* go to internal nameservers. Anything else goes upstream. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dnsmasq integration?
Message: 1 Date: Fri, 7 Jan 2011 17:52:27 -0500 From: Paul Smith To: Michael Biebl On Fri, 2011-01-07 at 22:37 +0100, Michael Biebl wrote: Am 07.01.2011 17:13, schrieb Uwe Geuder: On Ubuntu Lucid I solved the dnsmasq - nm integration as follows: I still just use the patch I posted here: https://bugzilla.gnome.org/show_bug.cgi?id=551747 My /etc/resolv.conf is fixed on 127.0.0.1 and I've chased down anything else that attempts to write to it. Constantly writing disk files so that some other process can re-read them is for the birds. Also using this patch for my systems using dhclient without NM: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2009q2/003009.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dnsmasq integration?
On Fri, 2011-01-07 at 22:37 +0100, Michael Biebl wrote: > Am 07.01.2011 17:13, schrieb Uwe Geuder: > > > > On Ubuntu Lucid I solved the dnsmasq - nm integration as follows: > > > > - dnsmasq is configured to read upstream DNS servers from /etc/resolv.conf1 > > > > - nm is patched to write to /etc/resolv.conf1 instead of /etc/resolv.conf > > (I'm willing to share the patch if anybody is interested. I haven't > > done so, because it's not 100% perfect, see below) > > > > - /etc/resolve.conf is manually edited to contain 127.0.0.1. It will never > > be changed (*) > > Or you can simply install resolvconf + dnsmasq without any patching. > > Should basically work the same way: /etc/resolv.conf contains 127.0.0.1 > and remains static. NM pushes DNS updates to resolvconf, which in turn > pushes those updates to dnsmasq. Sure... but the problem with resolvconf is it only works if ALL the facilities that manipulate /etc/resolv.conf are modified to use resolvconf instead. Sadly, this is not the case; not even all the NetworkManager components grok resolvconf (for example, openconnect doesn't work properly with resolvconf). And beyond that there's a whole suite of proprietary VPN solutions which certainly don't know to do anything except "overwrite /etc/resolv.conf". Plus, resolvconf is only available in Debian and derived distros like Ubuntu; there's no support in Red Hat/Fedora/etc. that I can find, which means that it will never (IMO) be a complete solution. In short, there's no really robust (in the face of all the different network utilities and their idiosyncracies) way to handle this today. What I attempted to do was write a script (Perl) that used inotify to watch /etc/resolv.conf and whenever it was changed my script would swoop in, figure out what changes were made, and rework my dnsmasq-based local proxy DNS server configuration to represent those changes, then write a new simplified /etc/resolv.conf. This works, actually... until it doesn't. It turns out that too many utilities are just too badly behaved to allow this to work automatically in a robust way. And yes, this includes NetworkManager (see my bug where, when an interface goes down, NetworkManager recreates the resolv.conf file completely from scratch based only on the interfaces it knows about... destroying any resolv.conf elements like search domains that were added by other tools such as proprietary VPN tools). I do think that resolvconf has absolutely the right CONCEPT, where it segregates individual resolv.conf-style files for each interface. The idea that each interface has its own search paths, nameservers, etc. is spot-on; I wish NetworkManager kept that kind of distinction internally. But the requirement that /etc/resolv.conf be a symlink is simply not workable in the face of proprietary tools that feel entitled to stomp resolv.conf as they like. We can say that we don't care about that kind of software... except that people wanting to switch to Linux almost never have any kind of say into the VPN solutions that their companies choose. If you want to REALLY know what I think, I think that the best solution is to rewrite libresolv so that instead of reading /etc/resolv.conf, it reads a list of files in /etc/resolv.d (for example), one for each interface, each of which was a resolv.conf-style formatted file. It could also read /etc/resolv.conf for backward-compatibility. Each of these would be maintained separately internally to the resolver, not combined into one big list, so that hostnames associated with a given search domain would be resolved only by the nameservers associated with the /etc/resolv.d file containing that domain, etc. There are still issues, of course, such as ordering of nameservers used for reverse lookups and what happens if search domains overlap, but these are solvable. This would remove the need for resolvconf, it would remove the need to run a local dnsmasq proxy server, etc. Even then, though, we'll need a method for handling legacy applications. But I think it could be done and if Linux could just get to one true, complete solution for this problem rather than a lot of different "kind of" solutions it would be a lot easier to get the proprietary vendors to help out. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dnsmasq integration?
Am 07.01.2011 17:13, schrieb Uwe Geuder: > > On Ubuntu Lucid I solved the dnsmasq - nm integration as follows: > > - dnsmasq is configured to read upstream DNS servers from /etc/resolv.conf1 > > - nm is patched to write to /etc/resolv.conf1 instead of /etc/resolv.conf > (I'm willing to share the patch if anybody is interested. I haven't > done so, because it's not 100% perfect, see below) > > - /etc/resolve.conf is manually edited to contain 127.0.0.1. It will never > be changed (*) Or you can simply install resolvconf + dnsmasq without any patching. Should basically work the same way: /etc/resolv.conf contains 127.0.0.1 and remains static. NM pushes DNS updates to resolvconf, which in turn pushes those updates to dnsmasq. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dnsmasq integration?
Hi! > Hm. I'm looking through lots of NetworkManager pages/docs and the GIT > repositories, and I see that there has been something titled "Local > caching nameserver support using dnsmasq" added in 0.8.2. Interesting. I'm using Ubuntu LTS so I'm not at the leading edge with nm, I guess it's 0.8. However, I have been running dnsmasq for a while (mainly to act as DHCP and DNS server for virtual machines I'm hosting on local network interface). On Ubuntu Lucid I solved the dnsmasq - nm integration as follows: - dnsmasq is configured to read upstream DNS servers from /etc/resolv.conf1 - nm is patched to write to /etc/resolv.conf1 instead of /etc/resolv.conf (I'm willing to share the patch if anybody is interested. I haven't done so, because it's not 100% perfect, see below) - /etc/resolve.conf is manually edited to contain 127.0.0.1. It will never be changed (*) (*) actually this is not true: pppd overwrites it every time. But this is an office machine and I use pppd only 1-2 times a year when the network is down, so I have not thought about fixing this. But it means that my solution is not suitable for people using dial-up regularly. On OpenSUSE 11.3 (I guess nm 0.8, too) this approach did not work, because network manager does not write /etc/resolv.conf. I'm not so familiar with OpenSUSE netconfig, but I have dnsmasq working together with nm without any patches. Maybe I needed a one time configuration change or netconfig did it for me, I don't recall. It works very reliably. It's actually a laptop and I use it regularly on very different networks (cable, WiFi and cellular), but dnsmasq - nm has never caused any trouble. In /etc/resolv.conf the first one is 127.0.0.1, i.e. dnsmasq, but dnsmasq knows to ignore that one. Additional ones are put there by nm / netconfig each time a new connection is established and dnsmasq uses them as upstream servers. Regards, Uwe ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
dnsmasq integration? (was: Re: NM trashing resolv.conf when a connection fails)
Hm. I'm looking through lots of NetworkManager pages/docs and the GIT repositories, and I see that there has been something titled "Local caching nameserver support using dnsmasq" added in 0.8.2. Unfortunately that's just about all the information I've been able to come up with as to what this means or does. Based on that small sentence and a _very_ quick browse of the code it sounds a lot like what I've been playing with, although I was working with a small inotify-based solution that would watch /etc/resolv.conf and reconfigure dnsmasq appropriately. Unfortunately as one could probably have guessed, applications that modify /etc/resolv.conf are simply not well-behaved (including NetworkManager... see my issue in the previous post) which makes this pretty difficult. Is there any documentation on exactly how this dnsmasq integration in NetworkManager works, and/or can anyone who is working with it give me a quick overview? ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
