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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
