On Wed, 2012-06-20 at 19:45 -0400, Paul Wouters wrote: > 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. Yeah, that's basically what we should be doing. NM's connectivity detection should figure out whether we're on a hotspot and handle the sandboxing/login, since we need to start parsing stuff like WISPR here. We'd be sandboxed until we know we're logged in an get a unintercepted response from the upstream DNS servers. Dan > > 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
