> and no signatures.

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.