DNSSEC is the 15+ year effort by the IETF to add security to DNS by adding new resource records that allow cryptographic signatures to DNS data.
DNSCurve is Daniel J. Bernstein's response to the cache poisoning flaw published in 2007, to which his own popular djbdns server was not vulnerable. Unlike DNSSEC, DNSCurve doesn't change the schema used for DNS data, but instead simply allows a DNS client to securely ask a question of a DNS server without allowing that question to be read or tampered with.
In a DNSSEC world, an attacker who broke into a cache server might (with many very important caveats) not be able to inject fake DNS data directly into RAM, even with control of the machine itself. DNSCurve does not provide this protection.
In a DNSCurve world, an attacker with control over the network would not be able to tamper with or even read the DNS queries sent from your desktop machine to a DNS server. DNSSEC, in its commonly proposed configuration --- the one overwhelmingly likely to form the basis of any DNSSEC adoption to occur† --- does not provide this protection.
Kaminsky favors DNSSEC; Bernstein in fact calls him "the marketing department for DNSSEC".
† I'm bearish on DNSSEC for reasons beyond its security issues, which I think --- at least at the protocol level --- are marginal.
Are there any simple diagrams which illustrate these types of problems from an information perspective? What I mean is, there are various mechanisms available, such as chain-of-authority, shared secrets, etc., and sometimes I get a whiff that something new, like DNSSEC, is, from an information theory (is that the correct term?) perspective, very similar to what's already in existence, for instance TLS, when the particulars of the protocols are stripped away.
DNSSEC is the 15+ year effort by the IETF to add security to DNS by adding new resource records that allow cryptographic signatures to DNS data.
DNSCurve is Daniel J. Bernstein's response to the cache poisoning flaw published in 2007, to which his own popular djbdns server was not vulnerable. Unlike DNSSEC, DNSCurve doesn't change the schema used for DNS data, but instead simply allows a DNS client to securely ask a question of a DNS server without allowing that question to be read or tampered with.
In a DNSSEC world, an attacker who broke into a cache server might (with many very important caveats) not be able to inject fake DNS data directly into RAM, even with control of the machine itself. DNSCurve does not provide this protection.
In a DNSCurve world, an attacker with control over the network would not be able to tamper with or even read the DNS queries sent from your desktop machine to a DNS server. DNSSEC, in its commonly proposed configuration --- the one overwhelmingly likely to form the basis of any DNSSEC adoption to occur† --- does not provide this protection.
Kaminsky favors DNSSEC; Bernstein in fact calls him "the marketing department for DNSSEC".
† I'm bearish on DNSSEC for reasons beyond its security issues, which I think --- at least at the protocol level --- are marginal.