DNSCurve provides actual encryption to DNS packets, albeit only on a hop-by-hop basis, and specifically on the hop between the recursive server and the authoritative server.
When used on that path it can provide authentication of the zone data. However any client further downstream cannot benefit from this authentication because the security is only "hop-by-hop". A malicious resolver sat in the middle of the resolution path can still provide false data.
DNSSEC on the other hand provides an end-to-end verifiable cryptographic signature that proves that the data received is the same as that on the authoritative server. DNSSEC uses cryptographic techniques, but does not actually encrypt any DNS traffic.
DNSCurve's use of elliptic curve encryption algorithms permits much smaller keys to be used than with RSA to achieve the same level of cryptographic strength. However there are proposals to include similar algorithms in the list supposed by DNSSEC.
DNSSEC is standardised by the IETF (RFC 4034 and RFC 4035, updated by RFC 5155) and implemented in several very popular name server implementations, including BIND (of course) and NSD/Unbound. PowerDNS will have DNSSEC support very soon.
DNSSEC is admittedly complicated but efforts are ongoing to simplify this (see e.g. http://opendnssec.org/) and deployment is increasing all of the time. Various TLDs (.se, .br, .org, .gov, etc) are already signed with DNSSEC and it has been announced that the root zone will be DNSSEC signed by the end of the year.
DNSCurve is quite interesting, but due to the independent way in which it has been developed it has very little chance of seeing any significant deployment. IMHO it has zero chance of ever being deployed on the root servers.
BTW your assertion about DNSSEC using "breakable encryption" appears to be completely unfounded. On what basis do you say that?
Zone signing keys are usually (but not necessarily) 1024 bits long. These keys are typically rolled every month or so, and current best estimates are that it would take at least a couple of years to brute force a 1024 bit key.
At this point in time a brute-force attack against 1024-bit RSA
would require about two years on a few million compute cores with many tens of gigabytes
of memory per processor or mainboard
which isn't exactly your typical botnet. From the same paper:
Next considering special purpose hardware, the most optimistic approach suggests that sieving
for a 1024-bit RSA modulus can be done in a year for about US $10,000,000, plus a one-time
development cost of about US $20,000,000, and with a comparable time and cost for the
matrix. In our opinion, (common) skepticism met by such designs is beside the point.
Such figures should not be interpreted as upper bounds, i.e., “Be careful, 1024-bit RSA can
be broken in two years for about twenty million bucks (assuming free development),” but as
lower bounds, i.e., “No reason to worry too much: even under very favorable attack conditions, factoring a 1024-bit RSA modulus still requires enormous resources.” The estimates should thus not be read as threatening but as confidence-inspiring.
Or from a one year old PCPro article:
To put that into perspective, to crack an RSA 1,024-bit key Kaspersky estimates it would take something like 15 million computers running flat out for a year to succeed
Frankly, no-one's going to put that amount of effort into cracking one domain's ZSK!
Besides, the real security is in the key signing keys, and those are usually at least 2048 bits and often longer (4096 bits). The amount of time it takes to crack an RSA key rises exponentially with the key length, not linearly.
