You're making an apples-oranges comparison, as did Kaminsky. The threat models covered by Curve and SEC are totally different. That's the point I'm making.
Meanwhile: Kaminsky is stipulating that every endpoint is going to implement all of DNSSEC. So, furthermore: I don't think he gets to cite "overhead" as an issue with DNSCurve.
Er, DJB and I are both presuming endpoints will validate -- we're both end-to-end security people. And that's fine, it ain't 1983 anymore, and a device that can handle TLS can handle both DNSCurve and DNSSEC (remember, the crypto construct in Curve is only about 8x faster).
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.
The notion of "endpoint validation" has an entirely different meaning in DNSCurve than it does in DNSSEC.
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.
But most people will not deploy a local dns{sec|curve} cache daemon, and use their ISP/OpenDNS/Google DNS instead, and caching is possible at this level instead, isn't it?
If each client endpoint were using a dns cache for classic DNS, the increase in traffic would also be a "concern", no?
Neither DNSSEC or DNSCurve are interesting if they're securing just IP addresses. So we both need code on the client, to link into certificate validation stacks and the like.
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.
Meanwhile: Kaminsky is stipulating that every endpoint is going to implement all of DNSSEC. So, furthermore: I don't think he gets to cite "overhead" as an issue with DNSCurve.