default local DNS caching name server

Dan Williams dcbw at redhat.com
Fri Apr 11 19:27:05 UTC 2014


On Fri, 2014-04-11 at 14:21 -0500, Dan Williams wrote:
> On Sat, 2014-04-12 at 02:33 +0800, P J P wrote:
> >   Hello,
> > 
> > > On Thursday, 10 April 2014 11:39 PM, P J P wrote:
> > > I plan to file a feature/change request for this one. I got caught up with other 
> > > work this past week so could not do it. Will start with it right away. 
> > 
> >   Please see -> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
> > 
> > It's a System Wide Change Proposal request up for review. 
> > 
> > I have set the target release as F22, because the proposal deadline for F21 was 08 Apr 2014 [1]. Besides, this change would require significant work on the related packages like NetworkManager etc. So F22 seems safer.
> > 
> > In case if you spot any discrepancies or have additional inputs or links to relevant documents etc. please feel free to update the wiki page or let me know and I'll add it there.
> 
> NM has had local caching nameserver capability built-in since Fedora 12
> or something like that.  Set 'dns=dnsmasq' in the [main] section
> of /etc/NetworkManager/NetworkManager.conf and NM will spawn dnsmasq in
> a local caching nameserver configuration and write 127.0.0.1 to
> resolv.conf.  NM will update that dnsmasq instance whenever your network
> configuration chagnes to ensure that dnsmasq has the latest nameservers.
> 
> It seems that 'unbound' is getting more love these days though, due to
> it's DNSSEC capabilities, and there is not yet a NetworkManager DNS
> plugin for unbound/dnssec-trigger.  I know some people are working on
> that though (Thomas Hozza and Pavel Simerda) and I'd expect that to show
> up in the near future.
> 
> Note that hotspot detection is an important part of this, since hotspots
> will clearly break any kind of DNSSEC validation that happens, and
> that's something that's being worked out between dnssec-trigger and
> NetworkManager right now too.
> 
> NM in F20+ already has a "dns=none" option that prevents NM from
> touching resolv.conf, but obviously if NM isn't touching it, the DNS
> information that NM gets from upstream or your local configuration needs
> to get to the local caching nameserver somehow.  Which is what the
> existing NM DNS plugins are for, like the dnsmasq one.

" Add domain specific name server entries into local name server's
configuration file and ensure that applications are able to resolve
internal(company wide) domain names too. (try connecting to company
mail/IRC server)"

We want to make sure that any local caching nameserver that we do use
doesn't rely exclusively on file-based configuration, or if it does,
it's able to re-read that configuration file using SIGHUP or some
seamless reload functionality.  It *must* also be able to load new
configuration without dropping in-process DNS queries on the floor,
otherwise users will experience hung DNS a non-trivial amount of the
time.

The better way is to add/remove zones + servers from dnsmasq over D-Bus,
which NM does not yet do since the patches are not yet upstream, or to
use some other socket-based protocol like unbound does with
dnssec-trigger.

Dan



More information about the devel mailing list