> (Fully encrypted DNS can only fail in even more ways than dnssec.)
The main reasons DNSSEC fails frequently are:
* pre-computed signatures, rather than online signing
* a demented, overly complex protocol
* signatures that expire rapidly
Maybe tptacek can name some others.
The only DNS encryption people are currently using (DNSCurve/DNSCrypt) does per-packet encryption, with a very simple protocol involving only a single ciphersuite designed by djb, and no signatures. This makes all the difference in the world.
If encryption were so bad then people wouldn't be using TLS, SSH, etc. It's the terrible design of DNSSEC that has poisoned efforts in DNS security.
It's probably time to retire unauthenticated encryption as useless.
Now, if what you meant is that it uses AEAD, that amounts to the same thing as a signature. It has all the same failure modes, namely failure to authenticate.
DNSSEC is a clusterfuck, but if somebody can't put the right public key in the right place, I'm not convinced they'll be able to put the right public key in the right record with DNSCurve either. The exact same thing will happen, and then the solution will be "click here to disable dnscurve".
DNSCurve and DNSCrypt use authenticated encryption.
DNSCrypt is not stuck to "a single ciphersuite designed by djb". The ciphersuite is negotiated (using DNS queries + signed responses in DNSCrypt v2, and TLS in DNSCrypt v3).
Over TCP, it's not limited to "per-packet encryption" either.
The first of those is actually a very important feature. In an age where many organizations outsource their DNS hosting, it's more important than ever to sign your resource records offline.
It's pretty useless to invent a new scheme that gives Amazon and Cloudflare access to your cryptographic keys, so your favorite three letter agency could just go via them instead.
Only you can sign your data, and no one else. That is a feature we cannot compromise on if we face the sort of adversaries mentioned here.
The rapidly expiring signatures is actually a feature too. It serves to avoid the trainwreck that is TLS certificate revocation. But that is a technical problem that may have other solutions. Feel free to suggest one.
And yet, when HBO screwed up their dnssec config and Comcast blocked the site, how did users react? By demanding Comcast stop verifying!
(Fully encrypted DNS can only fail in even more ways than dnssec.)