default DNS caching name server on Fedora ?
dcbw at redhat.com
Wed Jun 20 23:09:36 UTC 2012
On Wed, 2012-06-20 at 10:19 -0600, Kevin Fenzi wrote:
> On Wed, 20 Jun 2012 12:05:57 -0400
> Simo Sorce <simo at redhat.com> 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
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
More information about the devel