CertaDNS
Skip to lesson

How a Zone Is Signed · lesson 2 of 3

Which algorithm

After this lesson you can

Choose a signing algorithm for a new zone, and name what to migrate off.

Assumes you have read One key or two.

DNSSEC defines more algorithms than anyone should consider. RFC 8624 sorts them into must-implement, recommended and do-not-use, and in practice the choice is between two numbers.

The two that matter

NumberAlgorithmVerdict
13ECDSA P-256 with SHA-256The default choice for a new zone. Small keys, small signatures, universally validated.
8RSA with SHA-256Still fine cryptographically. Larger keys and signatures, so larger responses.
15Ed25519Excellent, and validator support is not yet universal.
5, 7, 10RSA with SHA-1Do not use. SHA-1 is broken for this purpose.
1, 3, 6, 12Various legacyDo not use.

Live, on two zones checked the same day:

$ dig +short DS certadns.com nasa.gov @1.1.1.1
29357 13 2 6F68DA43155EDAF9F929BD97C7820...
59470 8 2 ...
Checked 2026-09-15. Algorithm 13 and algorithm 8, both in production.

Why the small one wins

  • Response size. A signed answer carries its signature, and RSA signatures are several times larger. Bigger responses mean more truncation, more TCP fallback, and more exposure to amplification abuse.
  • Zone size. Every RRset carries an RRSIG. On a large zone the difference between algorithms is measured in hundreds of megabytes.
  • Validation cost. Elliptic-curve verification is cheaper, which matters to resolvers rather than to you, and they are the ones deciding whether DNSSEC is worth doing.

Migrating algorithm

Changing algorithm is not a key rollover. Both algorithms must be fully present and signing before the old one is withdrawn, because a validator that sees a DS naming an algorithm with no corresponding signatures treats the zone as bogus.

1. Add the new-algorithm key. Sign every RRset with BOTH.
2. Wait out the TTL. Every cached RRset now has both signatures.
3. Add the new DS at the parent, alongside the old.
4. Wait out the parent's DS TTL.
5. Remove the old DS.
6. Wait again, then stop signing with the old key and remove it.

Steps 2 and 4 are where this goes wrong

Removing the old DS while resolvers still hold RRsets signed only by the old key produces validation failures that look random and resolve on their own — which is the worst kind, because by the time anyone investigates it has stopped. Every wait in that sequence is a TTL somebody has to actually observe.

Try it on a real domain

Free, no account, public DNS only.

Last reviewed