Yes, but not more then DNSSEC, which is a published, widely implemented, and tested system.

I disagree. DNSSEC isn't widely implemented, and the widest test had numerous problems.

DNSCurve is 100% compatible with DNS. There's nothing a firewall could do that would be compatible with DNS that is incompatible with DNSCurve.

DNSSEC is not.

DNSCurve trades off more compute resources and the need to have the signing key on the public DNS server to get encrypted DNS, while DNSSEC has a lower server compute load and can store the signing keys off the server, but communicates in the clear.

DNSCurve protects against denial of service attacks. It requires far less compute-power than DNSSEC.

It's hard to make a case for the need to protect the DNS traffic from sniffing, the threat is modification, not sniffing.

Rubbish. Even an amateur cryptographer would tell you that the more you know about the message, the easier it is to break it. Confidentiality protections reduce the amount of knowledge, and thus protect against attacks that are yet unknown.

I would like to see elliptic curve crypto standardized and used in DNSSEC as it will significantly save on the traffic needed, but that is something that can be easily changed later. DNSSEC is very extensible and designed with the future in mind.

I don't think you know what you're talking about.

1. Have you looked at BIND's implementation of DNSSEC? It's thousands of lines of code alone.
2. See #1.
3. RFC4033: DNSSEC (deliberately) doesn't provide confidentiality; RFC 4033: DNSSEC does not protect against denial of service attacks.
4. The bind people claim that BIND9 was written by "a whole new set of people" but at least thirteen of the developers have been identified to work on both.
5. I'm leaving this one alone.
6. CA certificates were planned for an earlier incarnation of DNSSEC
7. I don't think this requires clarification, but this pdf indicates that the IETF started DNSSEC in 1993.

Do you actually check? Or do you just call people trolls who you don't agree with?

Actually, there are a lot more than two major holdups:

1. DNSSEC is slow. It makes your nameservers vulnerable to denial-of-service attacks
2. DNSSEC is incompatible with many firewalls; publishing DNSSEC will make you invisible to some sites
3. DNSSEC is very complicated. It's very hard for nameservers that aren't based on BIND to implement it. I should point out that the nameservers that aren't based on BIND have actually been practically immune to the recent DNS attacks...
4. DNSSEC requires administrators change their behavior significantly. This means retraining and reimplementation of many processes
5. DNSSEC requires cooperation from all the parents, not just the roots.
6. DNSSEC requires that clients reject unsigned data

The list goes on. There is another way, but because the BIND company controls a root server and has voting powers, and "because we've already invested so much in DNSSEC", it's unlikely the deadlock will be broken: DNSSEC will continue to suck so badly that nobody will want to use it, and other systems will be blacklisted because they're not DNSSEC.

Hesitant? Hesitant!?

Look, this isn't a bunch of ninnies holding back progress. DNSSEC is a replacement for DNS. It always has been, and for some god awful reason it's taken its architects over a decade to get nowhere. Deploying DNSSEC gains you nothing and costs you a lot: You have install costs, heavier hardware, changes to your internal infrastructure- those are the obvious ones-then you've also got the fact that the DNSSEC tokens will get your DNS packets stripped by some firewalls which means you disappear from the Internet- and this is my favorite, DNSSEC actually reduces security by making it easier to launch denial of service attacks on you.

Meanwhile, competing systems are rebuffed as "we've already invested all this time into DNSSEC".

If so, inventing some other more secure upgrade to DNS really is a waste of time (unless it's somehow easier to adopt than DNSSEC).

Like for example, dnscurve, which requires very little effort to set up, is actually backwards compatible with DNS, protects against some denial of service attacks (instead of creating them), and oh yeah doesn't require the cooperation of the parent zone.

DNSSEC is a joke. A bad bad joke. Replacing DNS with something not-DNS isn't any better an idea than replacing the Internet with something not-Internet. It's 2008 and there are still sites without MX records. You simply cannot "replace" all of the Internets all at once. It just doesn't work. Someone needs to take away the ISC's talking privileges until they stop fucking things up.

I don't disagree. I'd like to start implementing DNSCurve immediately.

DNSSec protects against a kind of attack that doesn't exist and never happens, by making attacks that do happen (like denial-of-service) easier to mount.

DNSCurve, a younger, competing protocol protects against most of the attacks DNSSec is designed to, and even protects against some denial-of-service attacks.

However, the other part of your question, about is SSL sufficient, the answer is no . It demonstrates nicely why a security extension needs to be one we can roll out quickly so that we can start blocking invalid requests, instead of just complaining about them.

DNSSec provides no benefit until some magic date in the future where we stop using DNS and start using DNSSec. Meanwhile, DNSCurve provides some benefit as soon as the root servers offer it.

As an ISP, I'd happily implement a secure DNS protocol if there were one - right now the closest thing is DNSCurve, but it seems that the asshats that created the problem- are prone to continue promoting a "solution" that requires more powerful hardware, puts servers and clients at a greater risk for denial-of-service attacks, and frankly doesn't work.

DNSCurve seems very attractive, but would require cooperation from the root servers- some of which have a vested interest in promoting the unworkable and broken-by-design DNSSec protocols.

Meanwhile, DNSSec, in addition to requiring cooperation from the root servers, also requires that every firewall; every dns client and server, and every dns-inspecting or dns-aware device get rewritten- or potentially rewritten because DNSSec is incompatible with DNS.

The people dragging their heels here are the BIND group. They want to promote a buggy and broken solution just like they always do simply because it's their solution.