On Thu, Oct 23, 2014 at 7:29 PM, Paul Wouters <[email protected]> wrote: > On Thu, 24 Oct 2014, D. J. Bernstein wrote: > >> I've never proposed "eliminating recursives" (caches). What I propose is >> complete _decentralization_ of the caches: you run your own trusted DNS >> cache on your own laptop/smartphone/etc., talking directly to the >> authoritative DNS servers---preferably with end-to-end encryption such >> as DNSCurve, but there are several advantages even without encryption. > > > With a modern browser, these two are pretty much the same thing due to > in-application caching. So for the discussion on feasability of > infrastructure, the argument is moot. > > Decentralising caches could actually be worse for dns privacy, as > your query no longer stops in the big ISP pool to gain some anonymity, > but instead links straight to you with specific TTLs on your personal > cache expiry/re-fetch timers.
What's the threat model here? Is it that someone could be watching the network above the ISP but not the link to the ISP from the local machine? > > > Of course, you can get the best of both worlds by using "centralised" > (read ISP) caches for your own caching (validating) server on > localhost. Thanks to DNSSEC, we can rely on untrusted "centralised" > caches. Of course that doesn't work for DNScurve because DNScurve only > solves one little aspect of DNS security (transport encryption) and at the > cost of not being able to use any non-local caches and pushing the crypto > load of transport security completely onto the authoritative servers > opening those up to CPU DOS attacks easier then quertying for ANY isc.org. So the DNS server is now revealing queries to an attacker, and the ISP cache is not? I fail to see why one is more trusted then the other. Furthermore, every person connecting to vanguard.com is forcing the vanguard.com web servers to carry out an RSA 2048 decryption. Forcing the vanguard.com DNS server to do a single Curve25519 operation per visitor doesn't increase the potential for a CPU DOS attack: they already have to solve that problem on their webservers, and in fact are vastly more vulnerable. (One could ask about root nameservers. But there isn't really a difference between root nameservers and other DNS servers: they both need to be adequately sized to deal with hoards of malicious traffic) > >> I'm also surprised at how little common-sense perspective appears in >> most discussions of DNS > > > I was surprised similarly, listening remotely to a CCC talk a few years > ago :) I validated DJB's claims about the amplification potential of DNSSEC: he gave a dig command, and sure enough, the response is many times bigger than the query. The claims about performance are misleadingly slow: at the cost of a 48 byte key, performance can be doubled on commodity hardware. By contrast, claims that CPU load on DNS servers will increase prohibitively with DNSCurve performance have been made consistently over 8 years, with no evidence that they have been updated or marked to market with increasingly fast CPU speeds. Sincerely, Watson Ladd > > Paul > > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
