default local DNS caching name server

Chuck Anderson cra at WPI.EDU
Sat Apr 12 13:26:28 UTC 2014


On Fri, Apr 11, 2014 at 10:44:31PM -0400, Paul Wouters wrote:
> On Fri, 11 Apr 2014, Simo Sorce wrote:
> 
> >>I hope the NM integration will show up at some point. It's really a
> >>pretty nice setup.
> >
> >I am using it too successfully. Only occasionally unbound seem to get
> >confused, not clear when, it doesn't happen more than twice a month and
> >systemctl restart unbound.service fixes it.
> 
> Next time please run sudo unbound-control list_forwards and cat
> /etc/resolv.conf and see if that locates the problem?
> 
> The one issue I have is that sometimes I NM fails to write resolv.conf
> in insecure mode, and I end up with no resolvers. The other issue is that
> in insecure mode (which you are not meant to run in other than signon or
> with very broken captive portals)) the VPN forward is added to unbound,
> but unbound is bypassed during secure mode, so internal resources are
> not available.

I'm proposing that /etc/resolv.conf is never re-written under any
circumstances.  A local caching resolver should ALWAYS be used and
resolv.conf should ALWAYS say:

nameserver 127.0.0.1

so that the applications/services don't hang when ONE external server
goes down or becomes unreachable.

All the "magic" for secure/insecure modes during NTP bootstrapping or
captive portals has to happen inside unbound (or whatever caching
resolver/forwarder is eventually chosen) and it should never be
bypassed.  That way the forwarder can switch to a second, third,
etc. upstream resolver without applications noticing that the first
one failed.  Or if it is a full iterative resolver, it will internally
handle failed authoritative nameservers without applications noticing.

Maybe we should set the file to be immutable after setting it to 127.0.0.1:

chattr +i /etc/resolv.conf


More information about the devel mailing list