| Type of security | DNSSEC | DNSCurve |
|---|
| Confidentiality against network sniffers |
RFC 4033:
"Due to a deliberate design choice, DNSSEC does not provide confidentiality." |
→ DNSCurve encrypts requests and responses, adding some confidentiality. |
| Confidentiality against active attackers |
DNSSEC reduces existing confidentiality
by publishing the complete list of "secured" DNS records.
This publication is integrated into the DNSSEC protocol;
it is independent of classic "zone transfers"
and cannot be disabled by administrators.
The "NSEC3" variant of DNSSEC attempts to reduce this exposure
but is almost always breakable.
|
→ DNSCurve does not publish lists of DNS records. |
| Integrity despite forged network packets |
DNSSEC uses public-key cryptography,
normally 1024-bit RSA, to detect forgeries.
1024-bit RSA is already breakable by large companies and botnets
but has not yet been broken by academic teams.
|
→ DNSCurve uses public-key cryptography,
specifically 255-bit elliptic-curve cryptography,
to detect forgeries.
255-bit elliptic-curve cryptography is billions of times harder to break
than 1024-bit RSA by current cryptanalytic algorithms.
|
| Integrity despite corruption of parent computers |
DNSSEC does not protect nytimes.com or google.com
against an attacker controlling the .com computers. |
DNSCurve does not protect nytimes.com or google.com
against an attacker controlling the .com computers. |
| Integrity despite corruption of one's own computers |
→ DNSSEC does protect nytimes.com DNS data
against an attacker controlling the nytimes.com DNS servers,
if the nytimes.com administrator
generates keys and signatures on a separate computer
that has not been compromised.
|
DNSCurve does not protect nytimes.com DNS data
against an attacker controlling the nytimes.com DNS servers.
|
| Availability |
RFC 4033:
"DNSSEC does not protect against denial of service attacks."
|
→ DNSCurve adds some protection against denial-of-service attacks.
|
| Component |
DNSSEC |
DNSCurve |
| DNS cache software (e.g., dnscache or PowerDNS Recursor or Unbound or BIND) |
Administrator upgrades to a cache that supports DNSSEC. |
Administrator upgrades to a cache that supports DNSCurve. |
| DNS server software (e.g., tinydns or PowerDNS Server or NSD or BIND) |
Administrator upgrades to a server that supports DNSSEC. |
Administrator upgrades to a server that supports DNSCurve,
or installs a DNSCurve forwarder alongside any existing DNS server. |
| DNS database software (often site-developed) |
Administrator upgrades to database software that supports DNSSEC records. |
→ No action required. |
| Public-key format |
Software generates a DNSKEY record that encodes a DNSSEC public key. |
Software generates a new server name that encodes a DNSCurve public key. |
| Public-key distribution by parent |
Parent extends web interface, database, registrar-registry protocol, etc.
to accept DNSKEY records. |
→ No action required. |
| Public-key distribution by child |
Administrator supplies new DNSKEY record to parent through new interface. |
Administrator supplies new server name through existing interface. |
| Initial signatures |
Administrator generates signatures on DNS records,
stores the signatures, and integrates the signatures into the DNS database.
|
→ No action required.
Cryptographic protection is applied automatically by the DNS server. |
| Subsequent signatures |
Administrator must generate new signatures every month
or else domain drops off Internet ("DNSSEC suicide").
|
→ No action required. |
| Signatures on updates |
Administrator generates new signatures after adding or changing DNS records.
|
→ No action required. |