default DNS caching name server on Fedora ?

[Paul Wouters]

On Wed, 20 Jun 2012, Dan Williams wrote:

> 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.

It is. Which is something I would like to address. Let me explain a
little of why the resolv hackery. The goals are to 1) provide the user
with DNSSEC security and have them decided when to disable it, and 2) to
try and use the DHCP obtained forwards where-ever possible as to not to
destroy the DNS caching hierarchy on the internet.

Sometimes we need to allow forged DNS to get past hotspots. We do not
want any of these answers to get cached. So we take the unbound cache
"offline". Depending on circumstances, resolv.conf will either be filled
in with the DHCP obtained DNS entries (as obtained from nm) which we call
"insecure mode" or it will point it to 127.0.0.1 where unbound listens.
If we cannot do DNSSEC and the user has opted not to go insecure,
then unbound forwards to 127.0.0.127 (while resolv.conf still points to
127.0.0.1) causing new DNS to die (but cached DNS to work, plus it uses
pre-fetching so there is still a good chance lots of dns works properly).

> 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.

Ideally, I would like NM to trigger the hotspot and dns detection before
any application is aware we are on a new network. If we detect a hotspot,
fire up a sandboxed browser login to get passed the hotspot, this might
require some of our DNS magic (dnssec-trigger hotspot mode). Then when
we detected we're no longer sandboxed, reprobe the dns situation, then
let the applications know we have a new network. A lot of this logic is
now in dnssec-trigger, and might be better elsewhere. One of the reasons
this is a daemon is that it keeps probing DNS/HTTP when in hotspot/insecure
mode to see if it can switch back to secure mode.

> The situation I do *not* want to get into at any point is where DNS is
> broken.

While I agree, my goal goes further. I want my DNS to work, with DNSSEC
security, and only go insecure when given permission to do so, without
getting locked out by wrong DNS or various hotspot technologies.

> 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...

I'd love a better integration, I was just not yet aware of plans for
hotspot detection in NM. The hotspot and DNS issues are very entwined.
This was a relative easy way to get a decent proof of concept going. The
reason I voted against making this setup the default was exactly the
lack of integration with NM.

As a first step, we could get rid of the hook and NM could just call
dnssec-trigger-control submit <ips> while it keeps a connection open
to dnssec-trigger-control results to get informed of probing updates
from dnssec-triggerd. And we could add an option to dnssec-triggerd to
not rewrite resolv.conf and let NM handle that part based on its
interpretation of the "results".

> (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...)

Speaking for dnssec-trigger it does not care as far as I know. It only
uses nmcli to get the list of DHCP obtainted DNS servers from NM, and
I have noticed the syntax seems broken on some versions of NM (eg F16).
I'd be happy to hear the best way of obtaining the DHCP DNS servers from
NM on various fedora/rhel versions.

Paul