default local DNS caching name server

[Dan Williams]

On Sat, 2014-04-12 at 03:35 +0800, P J P wrote:
>    Hello Dan,
> 
> > On Saturday, 12 April 2014 12:51 AM, Dan Williams wrote:
> > NM has had local caching nameserver capability built-in since Fedora 12
> > or something like that.  Set 'dns=dnsmasq' in the [main] section
> > of /etc/NetworkManager/NetworkManager.conf and NM will spawn dnsmasq in
> > a local caching nameserver configuration and write 127.0.0.1 to
> > resolv.conf.  NM will update that dnsmasq instance whenever your network
> > configuration chagnes to ensure that dnsmasq has the latest nameservers.
> > 
> > It seems that 'unbound' is getting more love these days though, due to
> > it's DNSSEC capabilities, and there is not yet a NetworkManager DNS
> > plugin for unbound/dnssec-trigger.  I know some people are working on
> > that though (Thomas Hozza and Pavel Simerda) and I'd expect that to show
> > up in the near future.
> > 
> > Note that hotspot detection is an important part of this, since hotspots
> > will clearly break any kind of DNSSEC validation that happens, and
> > that's something that's being worked out between dnssec-trigger and
> > NetworkManager right now too.
> >
> > NM in F20+ already has a "dns=none" option that prevents NM from
> > touching resolv.conf, but obviously if NM isn't touching it, the DNS
> > information that NM gets from upstream or your local configuration needs
> > to get to the local caching nameserver somehow.  Which is what the
> > existing NM DNS plugins are for, like the dnsmasq one. 
> 
>   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.

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?

Dan