default local DNS caching name server

[Miloslav Trmač]

2014-04-11 21:55 GMT+02:00 Dan Williams <dcbw at redhat.com>:

> 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?


The goal is to have DNSSEC validation in a system-wide, dedicated code,
trusted for that purpose; i.e. unbound does DNSSEC validation for every
application, with a centralized configuration and cache, so no application
needs or should do this on its own; it can simply consult the AD bit in the
reply.

 Does it mean
> that Firefox can "trust" the local caching DNS server,


Yes, for the purposes of DNSSEC validation and making sure the AD bit is
set correctly..


> and if so, why
> would that server be any more "trustworthy" than the upstream nameserver
> delivered to you by DHCP?


The upstream nameserver is often not under the control of the owner of the
computer, so it can't be trusted to return the DNSSEC validation status in
the AD bit correctly, and the communication channel (e.g. ethernet or
unencrypted wifi) allows an attacker to spoof the reply from that upstream
nameserver anyway.  In the general case, DNSSEC validation needs to happen
on the same machine that relies on the results of the validation.


> If it
> does do something, does that something break hotspot or portal detection
> and login?
>

Not necessarily, and probably not.  The applications are still in control
of what to do if the AD bit is not set (e.g. because DNSSEC validation
fails because the hotspot has replied with an unvalidated redirection); so,
in this case, Firefox would probably not be willing to use the
hotspot-spoofed DNS response as an indication of the correct public key via
DANE, but it should still be perfectly willing to make a HTTP connection,
including HTTP connection to "google.com" that redirects it to
https://hotspot-owner.com .
     Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140411/d7412e69/attachment.html>