> However, DNSSEC is a crappy standard. It doesn't do encryption so a surveillant can still collect metadata; To be fair, on-the-wire encryption is a problem o

> However, DNSSEC is a crappy standard. It doesn't do encryption so a surveillant can still collect metadata; To be fair, on-the-wire encryption is a problem orthogonal to that which DNSSEC is attempting to solve, which is integrity. > it has unsolved issues that facilitate amplification attacks, it's overly complex and has slow adoption. In fact, before DANE arrived on the scene, there was hardly a good reason to deploy it. Yup, DANE is essentially its killer app. Any chance you could outline how you think it could be improved? > If we adopt DNSSEC now we'll be stuck with it (including its lack of privacy) pretty much forever. Instead, I suggest we work on more promising initiatives such as DNSCurve (https://en.wikipedia.org/wiki/DNSCurve https://en.wikipedia.org/wiki/DNSCurve) I don't think the case. As I wrote, DNSSEC aims to solve the issue of integrity, not privacy. DNSCurve, or something like it, should be deployed alongside DNSSEC, with the former giving you privacy, and the latter ensuring the integrity of the records. That way, even if the authoritative DNS server itself is compromised, you can know whether the data you're getting from it are OK or not. After all, it doesn't matter how good the pipe is if you're getting sludge rather than the clean water you expect through it. The big problem is that people, whether they're DNSSEC or DNSCurve advocates, incorrectly put DNSSEC and DNSCurve in competition with each other, but this isn't even remotely the case. We ought to be using both.