DNSSEC algorithms for TLDs (and everyone else)

DNS Security Extensions (DNSSEC, RFC 4035) protect the integrity of DNS data in transit over the open Internet. DNSSEC protects validating clients from both on-path tampering and off-path spoofing of responses to DNS queries.

The root zone was signed in 2010, and now all generic Top-Level Domains (gTLDs) and the majority (144 out of 248) of country code Top-Level Domains (ccTLDs) are signed.

The number of signed ‘second level’ domains (also 3^rd and 4^th level when a TLD offers registration at nested subdomains, such as .co.uk, or .shibuya.tokyo.jp) has grown to approximately 18 million, or 5% of the global count of such delegations. The total is growing at over three million per year, and the pace of adoption is expected to pick up significantly this year.

DNSSEC tooling is improving, with automated signing policies in authoritative servers such as BIND, KnotDNS, NSD, and PowerDNS handling not only routine zone signing, but also key and algorithm rollovers.

One area that still needs improvement is selection of the algorithm (or key size) for zone signing keys (ZSKs). Default settings in tools and current practice have not kept up with best-practice, and most domains are still signed with keys that are no longer recommended. This post suggests practical improvements.

Change happens slowly in the DNS ecosystem. DNS is taken for granted by users, and operators are in the news only when things go wrong. The network is complex and constantly under attack. Under these circumstances, it is not surprising that the primary focus is on stability rather than on keeping up with the latest innovations.

Consequently, many Top-Level Domain (TLD) operators are still running with DNSSEC parameters that were standard practice circa 2010, when the root zone was signed:

Table 1 — TLD zone signing keys.

Even back in 2010, standard practice wasn’t ‘best practice’, as 1,024-bit RSA was already deprecated. Yet, sadly, 1,024-bit RSA still accounts for approximately 92% of RSA zone signing keys (ZSKs) (and 47% of all signed zones).

However, real progress is being made. 48 TLDs (as shown in Table 1), and close to 50% of ‘second level’ zones are signed with ECDSA P256 or P384 (algorithms 13 and 14). The deprecated RSA algorithms that employ SHA-1 signing (algorithms 5 and 7) have largely been decommissioned; these are down to approximately 7% of their peak deployment levels.

RSA factoring costs

With the emerging COVID pandemic dominating the news at the time, it was easy to miss the February 2020 announcement of the factorization of the RSA challenge with 250 decimal digits (829 bits).

The CPU (Intel Xeon 6130, 2.1GHz) ‘cost’ of the attack was 2,700 core years, or approximately 2⁶⁷ clock cycles, which is in reasonably close agreement with a theoretical upper bound cost estimate of approximately 2⁷².

The same theoretical estimates place the cost of factoring 1,024-bit RSA at 200 times higher, or around 0.54 million core years. This is high, but likely within reach of a well-funded adversary. Plus, this cost is an estimated upper bound; there may be more efficient methods available to the likes of nation-state security agencies.

Recommendations

RSA ZSKs should now have at least 1,280 bits, but this choice is a compromise. While longer keys give a better safety margin, when they are used with NSEC3, TCP fallback becomes more frequent. This is because with NSEC3 no such domain (denial of existence) DNS responses typically require four signatures (SOA + three NSEC3 records).

While 1,280-bit RSA is a somewhat modest step up (and still below NIST’s recommended 2,048-bit floor), it provides another factor of 450 in the estimated cost of key recovery, which takes us from 0.54 million to ~240 million core years. This cost should be beyond even nation-state adversaries, especially if ZSKs are rotated sufficiently often, making the cost/benefit of any attack prohibitive.

At 1,536 bits, RSA looks entirely out of reach of any classical brute-force attack. Hypothesized future quantum computers may someday be able to break all extant DNSSEC algorithms, but since DNSSEC is used only for data integrity, future attacks on present-day signing keys that will no longer be in use by then are of no concern. That said, 1,536-bit RSA keys are too large for zones signed with NSEC3, potentially causing UDP response truncation and TCP fallback for negative answers.

For zones signed with NSEC there are at most three signatures in negative responses, and RSA 1,536 also becomes practical as a ZSK choice. This is particularly sensible for small end-user zones that have just one or a handful of easily guessed names. Such zones have no names to hide, and NSEC offers better security and efficiency than NSEC3.

In summary, even 1,280-bit RSA ZSKs are a meaningful improvement on legacy 1,024-bit keys in zones that employ NSEC3, while 1,536-bit keys work well in combination with NSEC. Ideally, make the switch to ECDSA P256 (algorithm 13), or else rotate any remaining RSA ZSKs regularly, for example, every 90 days, and:

• Use 1,536-bit or 2,048-bit (but not larger) key signing keys (KSKs).
• Use NSEC not NSEC3 (especially when signing small zones with just a handful of easily guessed names).
• When using NSEC, use 1,536-bit RSA ZSKs (if not using ECDSA).
• When using NSEC3, use 1,280-bit RSA ZSKs (if not using ECDSA).

Viktor Dukhovni and Wes Hardaker co-authored RFC 7672, which uses DNSSEC to harden email transmission (SMTP) against active attacks, implemented the resulting protocol in Postfix and OpenSSL, and with help from Wes, designed and operates the DNSSEC/DANE survey.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.