Re: default DNS caching name server on Fedora ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux