DNSSEC is a complicated topic, and making things even more confusing is the availability of several standard security algorithms for signing DNS records, defined by IANA. Algorithm 13 is a variant of the Elliptic Curve Digital Signing Algorithm (ECDSA). While currently used by less than 0.01% of domains, we’d like to argue that ECDSA helped us eliminate the final two barriers for widespread DNSSEC adoption: zone enumeration and DDoS amplification.
Zone enumeration is prevented by live signing, and this is only computationally efficient with the fast signature generation of ECDSA. Elliptic curves also produce significantly smaller keys and signatures than their RSA counterparts, which means responses to DNS queries are smaller. This greatly reduces the amplification factor of DNS-based DDoS attacks.
Cloudflare is the largest managed DNS provider in the world. What we really don’t want is to turn our DNSSEC servers into an amplification vector for distributed denial-of-service (DDoS) attacks. Every time you request a record from a DNSSEC server, it also returns the signature associated with that record, as well as the public key used to verify that signature. That’s potentially a lot of information.
Making the response size for DNSSEC queries as small as possible is an important requirement to prevent abuse of our DNS infrastructure by would-be attackers. The small size of ECDSA keys and signatures goes a long way towards that end.
Achieving 128-bit security with ECDSA requires a 256-bit key, while a comparable RSA key would be 3072 bits. That’s a 12x amplification factor just from the keys. You can read more about why cryptographic keys are different sizes in this blog post.
But, most RSA keys are not 3072 bits, so a 12x amplification factor may not be the most realistic figure. Let’s take a look at a worst-case real-world scenario for DDoS amplification, which is a negative response (NSEC record). For a domain behind Cloudflare (which uses ECDSA signatures and DNSSEC white lies), a typical DNSSEC response is 377 bytes. Compare this to 1075 bytes for a domain not using ECDSA or DNSSEC white lies.
When you consider the fact that every other large-scale DNSSEC implementation relies on RSA signatures, it’s unappealing for an attacker to leverage our DNSSEC infrastructure as a DDoS vector.
ECDSA is not without its trade-offs. According to Roland van Rijswijk-Deij et al., only 80% of resolvers support ECDSA validation. This number is growing, but it means that if we switched the entire DNSSEC Internet onto ECDSA right now, DNSSEC validation would fail for millions of Internet users everyday and fall back to returning unverified DNS records.
Furthermore, while ECDSA signature creation is faster than RSA, signature validation is actually much slower. Roland van Rijswijk-Deij et al. showed that, even with the ECDSA optimizations that we contributed to OpenSSL, ECDSA is still 6.6 times slower than 1024-bit RSA (which is the most common algorithm used for zone-signing keys). This is a serious problem, because overloading DNS resolvers could potentially slow down the entire Internet.
There’s one very important caveat to all this Algorithm 13 discussion: only 1.5% of web properties support DNSSEC in any capacity. Not all registrars support DNSSEC, and adding support is not trivial. They need to allow their users to upload DS records, which, in turn, need to be uploaded to the registry by the registrar. We’re working to make this an automated process so the registrant doesn’t even need to upload the DS record, but it still requires intervention by the registrar.
The good news is, we’re trending in the right direction. Over the last 12 months, DNSSEC in general has seen a decent amount of growth. And, in the three weeks between our public DNSSEC beta and our Universal DNSSEC announcement, Hover, OVH, Metaname, Internet.bs, and the .NZ registry have added support for Algorithm 13.
We believe that DNSSEC is an essential technology for the modern web and that ECDSA makes global DNSSEC adoption a real possibility. Hopefully, we’ll continue seeing support for Algorithm 13 from registrars and registries, big and small.
Set up a domain in less than 5 minutes. Keep your hosting provider. No code changes required.