On Thu, May 30, 2013 at 08:51:09AM -0700, Nicholas Weaver wrote:
> Although I disagree about the cache local. The VALIDATION should
> be local, but it should still use the ISP-level recursive resolver
> cache, as that IS a huge win in practical performance and, thanks
> to DNSSEC in general, you don't have to trust that lying, MitMing
> SOB.
A local cache should typically forward all requests to the ISP,
and validate the result locally. There is no need to saddle
applications with DNSSEC validating code and library dependency
DLL hell. DNSSEC via IPC to "unbound" or similar is much cleaner.
I'm not suggesting side-stepping the ISP cache, just placing a
local cache between that and the application. For example, there
should I believe be a DNSSEC validating cache on Android phones,
to complement the DNSSEC validation on 8.8.8.8. That way the MITM
at a Starbucks Wifi hotspot can't tamper with 8.8.8.8 DNS replies.
> > Our experiments suggest that a _large_ percentage of clients cannot
> > see DNSSEC records at all.
>
> This is the bigger problem, and I agree. We should have some
> detailed data soon from Netalyzr, the tests that have been running
> for a while are:
IMHO a DNSSEC-aware local resolver that can't see DNSSEC RRs through
its DHCP discovered forwarder should have a fallback strategy that
either uses the root servers directly, or uses 8.8.8.8 or similar
services that are publically accessible and don't fail to support
DNSSEC. This would give Google more intel on DNS lookup traffic,
so I doubt they would mind.
It would be nice to have a DNSSEC-aware local cache on my Android phone.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
