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