It's a pity that you link to a page that compares DNSCurve to plain DNS.

DNSSEC has the feature that it works even in the presence of caching (recursive) resolvers.

DNSSEC only solves half of the problems. That's why you use DNS-over-TLS (or DNS-over-HTTPS) for the other half.

This doesn't really answer the argument that the parent comment made. You can say DNSSEC "works" in the presence of a caching resolver the same way you can say the TLS Heartbeat extension "works"; sure, it's there, and it's doing stuff that the RFC says it should do, but that begs the question: why is it there? There are really no meaningful use cases left for DNSSEC.

DNS-over-TLS is only intended for stub resolver - recursive resolver traffic (check the introduction sections of the relevant RFCs). We're still lacking a protocol to provide confidentiality between the recursive resolver and authoritative servers. DNSCurve would offer that.

Which makes sense, because there is (in general) not much point in protecting traffic between recursive and auth. servers if you don't protect the stub resolver.

At the same time traffic between stub resolver and recursive resolver is much more privacy sensitive.

So it makes sense to first get TLS between stub and recursive up and running. And that proves already hard enough.

Technically stub resolvers and recursive resolvers are the same thing (one is an inherent part of the other). So all is needed is recursive resolvers to communicate securely with authoritative servers. Tunnels to third party recursive resolvers do nothing but leak private data to them.

But traffic to a recursive resolver can already be protected by other means, e.g. a tunnel to one that you control. There are zero options for contacting the authoritative ones.