The "wrapping" and "unwrapping" in DNSCurve is done by a forwarder, a separate server. People have written such forwarders many years ago. No DNS software needs to be rewritten.
Yes, I know. I was contrasting their use of crypto and the degree to which they fit traditional name server architectures.
> The "wrapping" and "unwrapping" in DNSCurve is done by a forwarder, a separate server
Whether the wrapping is done on a [reverse] forwarder or integrated into the authoritative name server is entirely irrelevant. (Perhaps you were thinking of the querier, which would be even more irrelevant from the perspective of root and TLD servers.)
I like DNSCurve. But I was contesting the point that DNSCurve was effectively zero cost. It definitely is not zero cost, neither in terms of CPU nor operationally. The cost may be de minimis in most contexts, but root and TLD zones are certainly the exception.
Has anyone, e.g., at Verisign, ever debated this computational/operational cost of using DNSCurve at a large TLD.
Contrast that with DNSSEC, where you can sign zones offline. Not only is this more secure as hacking the server doesn't expose your private key, but you can also keep serving the same immutable data. It really doesn't matter how fast Curve25519 and Salsa20 are, they're significantly more work than just spitting out the same answer to everybody.
These benefits are easy to dismiss for leaf zones, but mean everything when you're serving the root or top-level zones in an increasingly hostile environment.