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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
