On Sat, 12 Apr 2014, Chuck Anderson wrote:
I'm proposing that /etc/resolv.conf is never re-written under
circumstances. A local caching resolver should ALWAYS be used and
resolv.conf should ALWAYS say:
Cheers. That's a goal I share with you, but...
All the "magic" for secure/insecure modes during NTP
captive portals has to happen inside unbound (or whatever caching
resolver/forwarder is eventually chosen) and it should never be
Currently, to prevent unbound from either rejecting DNS lies or get
polluted by accepting DNS lies, is "taken offline" by the system during
hotspot signon. resolv.conf is rewritten to use the DHCP supplied
nameservers to get past the portal. During this time, all applications
are exposed to DNS lies. Once the captive portal is done, resolv.conf
is changed back to 127.0.0.1 and unbound is "online" again protecting
all applications. If the network is so bad this cannot work, and the
user opts to remain "insecure", the vulnerable situation is continued.
If the user opts to go "cache only", than resolv.conf is written as
127.0.0.1 but unbound is configured with 127.0.0.127 as forwarder,
meaning no new DNS answers will ever come in.
As I said in previous posts, the ideal situation to not mess with
resolv.conf on the host is to have a disposable secure container
get the "new network" before any application gets network, do the
hotspot login, and throw away the container. In that case, resolv.conf
on the host (not container) never has to be modified.
Maybe we should set the file to be immutable after setting it to
chattr +i /etc/resolv.conf
That is the trick currently used by dnssec-triggerd to prevent other
applications from messing with that file.