default local DNS caching name server

[Paul Wouters]

On Fri, 11 Apr 2014, Dan Williams wrote:

>>   That's great. Thank you so much for sharing this information. I'll add it to the wiki page.
>>
>> About the wifi hotspots breakage, I'm still not in the clear. IIUC how they work is, all client traffic is blocked/redirected to a designated server till the time user authenticates/makes payment/accepts conditions etc. This blockage/redirection is probably done on the the gateway or some such entry/exit point, no?
>
> They almost always run DNS interceptors, so that the DHCP server on the
> captive side always returns the portal's login page for any request,
> even "www.google.com" or "www.fedoraproject.org" will redirect you to
> the login page.  Obviously that DNS reply will not be authenticated or
> secure in any way, because it clearly cannot be a trusted reply from
> google.com.  Thus they will break any kind of DNSSEC or any other kind
> of authentication that the local caching DNS server might do.

There are two captive technologies that need to be checked for. One is
port 80/443 interception and one is DNS interception. dnssec-triggerd
offers those but its integration with NM is poor because it was written
as a stand aline daemon+gnone applet.

On top of the captive portals, the solution needs to deal with VPN
situations and split-view DNS. Unbound handles this with libreswan,
vpnc and openvpn already. This also involves flushing the cache when the
VPN connection goes up/down. unbound supports all of this via runtime
unbound-control daemon reconfiguration and also supports shipped
exceptions via /etc/unbound/*.d/ directories.

I am not aware of dnsmasq offering these features at all. dnsmasq also
only very recently got beta suppor for dnssec, so I am uncomfortable
with using dnsmasq for these tasks.

> I think the big issue for me is the use of "trusted" in the proposal.
> What does that actually mean?  Who is doing the trusting?  Does it mean
> that Firefox can "trust" the local caching DNS server, and if so, why
> would that server be any more "trustworthy" than the upstream nameserver
> delivered to you by DHCP?  If that local nameserver *is* somehow more
> trustworthy, what specifically does it do to deserve that trust?  If it
> does do something, does that something break hotspot or portal detection
> and login?

The DNSSEC trust comes from a shipped root key that's local to your machine,
augmented by installed trust anchoes (eg in /etc/unbound.d/keys.d/).
This means all the validation happens on the host and cannot be mangled
in transit by an attacker. The alternative is to request a non-local DNS
server with DNSSEC support and looking at the answer's AD bit. But this
bit is not cryptographically protected, so it assumes a trust in the network.

What would be the most awesome solution, is if NM on finding a new
network connection, can bring up a secure container with resolv.conf
from the DHCP server, do the captive portal tests, allows the user to
login in a throw away browser context, and once accepted on the network,
and the mangling has stopped, to release the actual network to the rest
of the OS and destroy the used container.

Paul