On Wed, 2012-06-20 at 10:19 -0600, Kevin Fenzi wrote: > On Wed, 20 Jun 2012 12:05:57 -0400 > Simo Sorce <simo@xxxxxxxxxx> wrote: > > > Yes this is all good 'n' nice. > > > > The point is, can we/should we/want we make this the default ? > > (And work on integrating NM -> unbound automatic configuration ?) > > I'd be in favor of that. ;) > > I don't want to speak for the feature owner/unbound/dnssec maintainer > tho. I spent some time looking at this today. NM already has plugins for dnsmasq and a long-since-dead one for bind. We can certainly add a plugin for dnssec-trigger or even unbound itself as well. The mechanism by which dnssec-trigger currently interfaces with NM (dispatcher script) is not optimal for a DNS plugin, and it requires setting resolv.conf immutable which is a hack. NM also has a "priority" for these plugins, so one gets asked to set up DNS first, and if that fails for whatever reason, we go on to the second one. That's all done by editing NetworkManager.conf (see the manpage). The plugins attempt to be robust to failure, such that if dnsmasq quits or the configuration is invalid (which happened once when a new version of dnsmasq came out), NM will either respawn the plugin or fall back to writing resolv.conf to ensure that there is some network connectivity. You can envision a system where NM just sends out dbus signals that registered handlers like dnsmasq or dnssec-trigger would listen for, or a script-based system like the dispatcher scripts but specifically for DNS, but both these have some robustness concerns. The situation I do *not* want to get into at any point is where DNS is broken. That's what we currently run into with various hacks like openresolv/resolvconf, immutable /etc/resolv.conf, etc. That's why NM attempts to monitor these services and takes a very hands-on approach. The more processes we run, the more possibilities there are for things to get misconfigured or fall through cracks. Which is why I'm a bit concerned about the chain of NM -> dnssec-trigger -> unbound... (also, an aside: why the heck do resolvconf and dnssec-trigger require an interface name??? DNS information has nothing do with network interfaces, despite some DNS info coming from interface-specific sources like DHCP...) Dan -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
