Hacker News new | past | comments | ask | show | jobs | submit login

DNSCurve requires online decryption as the authoritative server needs to be able to unwrap incoming queries using its private key. Similarly, the server has to generate a whole response from scratch every query, whereas DNS was originally designed so that you can just echo the query header and tack on a cached answer.

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.




DNSCurve is something different from DNSSEC. People like to argue for one or the other but there is no rule that both cannot be used at the same time. They each do different things.

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.


> DNSCurve is something different from DNSSEC.

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.


I misread your comment. Sorry. Thank you for clarifying.

Has anyone, e.g., at Verisign, ever debated this computational/operational cost of using DNSCurve at a large TLD.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: