What I'm saying is that mass adoption of DNSCurve eliminates the caching layer in DNS, and that will cause a major increase in traffic to the authoritatives, especially TLDs and the root.
What I'm saying is that mass adoption of DNSCurve eliminates the caching layer in DNS, and that will cause a major increase in traffic to the authoritatives, especially TLDs and the root.
In DNSSEC, all the security resides in the actual DNS records. End-to-end security means verifying each step in the DNS chain, from .org through "www". This is the only way DNSSEC provides any value.
Unlike DNSSEC (shockingly), DNSCurve protects the actual conversation between a name resolver and a name server, irrespective of the RR's configured for a zone. DNSCurve (for the most part) does not care about your RR's. When one speaks of "end-to-end DNSCurve", one is talking about a hypothetical universe in which the root servers all the way down are speaking DNSCurve.
That world is never going to happen.
The point of DNSCurve is that it provides a degree of security --- by my reckoning, the most important degree --- even if the roots don't adopt DNSCurve. And in that universe, caching works just fine: DNSCurve is only going to be used to connect endpoints to caches.
If each client endpoint were using a dns cache for classic DNS, the increase in traffic would also be a "concern", no?
The difference is, when DNSSEC has code on the client, it can still leverage the caching infrastructure. When DNSCurve has code on the client, it has to bypass it entirely.