skip to content

How does signing a DNSSEC zone with RSA-2048, ECDSA P-256 or Ed25519 change response sizes, and why does that matter for DNS over UDP?

level: seniorimportance: should knowfreq 16%

answer

  1. signature length follows the modulus
  2. count the signatures in one answer
  3. every RRset, every algorithm
  4. an unsupported algorithm means insecure

basics

~20 s

An RSA-2048 DNSSEC signature is 256 octets; ECDSA P-256 and Ed25519 signatures are 64, with public keys of 64 and 32 octets. Smaller keys and signatures keep signed answers within UDP sizes, avoiding fragmentation and TCP retries.

solid answer

~50 s

Signed answers carry one `RRSIG` per RRset per algorithm, and `DNSKEY` answers carry the keys themselves. For RSASHA256 (algorithm 8) the signature is as long as the modulus - 256 octets at 2048 bits (RFC 5702) - and the key a little more. ECDSAP256SHA256 (13) has a 64-octet key and a 64-octet signature (RFC 6605); ED25519 (15) a 32-octet key and a 64-octet signature (RFC 8080). A name-error answer with three signatures carries 768 octets of signature under RSA-2048 against 192 under either curve. Over UDP that decides whether a response fits the advertised EDNS0 size or gets fragmented or truncated and retried over TCP. Two traps: every RRset must be signed by every algorithm in the `DNSKEY` RRset, so an ECDSA ZSK under an RSA KSK shrinks nothing; and a validator lacking the algorithm treats the zone as insecure.

go deeper

for a junior

Remember that signed answers carry extra signature data, and that elliptic-curve signatures are much smaller than RSA ones.

for a middle

Quote the sizes: 256-octet RSA-2048 signatures against 64-octet ECDSA P-256 and Ed25519 ones, and how many signatures one answer carries.

for a senior

Tie algorithm choice to fragmentation and TCP fallback, and know the every-algorithm signing rule and the insecure fallback for unsupported algorithms.

for a principal

Balance response size, signing and validation CPU, and validator support across the resolver population, and plan the algorithm rollover a change would need.

## Where DNSSEC bytes come from DNSSEC makes DNS responses larger in two ways. Every signed RRset in an answer travels with its `RRSIG` - one per signing algorithm, and sometimes one per key. Queries for the apex `DNSKEY` RRset also return the public keys themselves. The **algorithm** chosen for the zone sets the size of both. The algorithm numbers that matter today (IANA registry, which RFC 9904 made the canonical source of guidance): - **8, RSASHA256** - RSA with SHA-256 (RFC 5702). - **13, ECDSAP256SHA256** - ECDSA on curve P-256 (RFC 6605). - **15, ED25519** - EdDSA on Ed25519 (RFC 8080). ## Key and signature sizes | Algorithm | Public key in DNSKEY | Signature in RRSIG | Source | |---|---|---|---| | RSASHA256, 2048-bit | the 256-octet modulus plus a short exponent field | 256 octets (signature length equals modulus length) | RFC 5702 §3 | | ECDSAP256SHA256 | 64 octets (point x and y, 32 each) | 64 octets (r and s, 32 each) | RFC 6605 §4 | | ED25519 | 32 octets | 64 octets | RFC 8080 §3-4 | RFC 6605 adds that P-256 is estimated at roughly the strength of 3072-bit RSA, so ECDSA P-256 is both smaller and, by that estimate, stronger than RSA-2048, which RFC 6781 §3.4.2 puts at about 112 bits of symmetric strength. ## Counting a few answers Counting only key and signature bytes, before names, headers and other fields: 1. **A `DNSKEY` answer with a KSK and a ZSK and one KSK signature.** RSA-2048: about 2 x 260 + 256, roughly 776 octets. ECDSA P-256: 2 x 64 + 64 = 192. Ed25519: 2 x 32 + 64 = 128. 2. **A name-error answer.** RFC 4035 Appendix B.2 shows the shape: the `SOA` and two `NSEC` records in the authority section, each with its `RRSIG` - three signatures. RSA-2048: 3 x 256 = 768 octets of signature; either curve: 3 x 64 = 192. 3. **During a key change**, extra keys and signatures sit in the set at once, so the RSA figures grow fastest exactly when the zone is most fragile. ## Why size matters on UDP RFC 4035 §3 requires a security-aware name server to support EDNS0 and a message size of at least 1220 octets, and recommends 4000; a validating resolver advertises what it can take in the OPT record's UDP payload size. A response above the path MTU is fragmented at the IP layer, and some networks drop fragments; a response above the advertised size is truncated, and the resolver retries over TCP. The mechanics belong to DNS transport, but the trigger is often the signing algorithm: small elliptic-curve signatures keep most signed answers well inside a single unfragmented datagram. ## Constraints on the choice - **No mixing for size.** RFC 4035 §2.2, restated in RFC 6840 §5.11: the zone "MUST also be signed with each algorithm (though not each key) present in the DNSKEY RRset". An ECDSA ZSK beside an RSA KSK means every RRset still needs an RSA signature, so answers grow rather than shrink. Switching algorithm is a whole-zone algorithm rollover, a separate procedure. - **Validator support.** If a validator implements none of the algorithms in the parent's DS RRset, RFC 4035 §5.2 says to treat the delegation as having no DS: the zone becomes **insecure**, answered unvalidated rather than failed. In the IANA registry columns RFC 9904 set up, algorithms 8 and 13 are MUST implement for validation and 15 is RECOMMENDED. - **Deprecated algorithms.** RFC 9905 says RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7) MUST NOT be used to create DNSKEY or RRSIG records. - **CPU.** RFC 6605 reports ECDSA signing over 20 times faster than RSA in some implementations, and RSA verification about 5 times faster than ECDSA - relevant for online signers and busy validators respectively. The usual conclusion for a new zone is ECDSA P-256: small, mandatory to validate, cheap to sign. Ed25519 is smaller still in keys, with validator support RECOMMENDED rather than mandatory.

  • Why does a DNSKEY response hit size limits before ordinary answers do?
    It carries public keys as well as a signature. With RSA-2048 each key is about 260 octets, so a KSK, a ZSK and one signature are near 776 octets before names and headers, and any extra key during a key change adds roughly 260 more. Ordinary answers carry signatures only. Elliptic-curve keys of 64 or 32 octets keep the DNSKEY response small.
  • A zone is signed only with Ed25519; what does a validator without Ed25519 support do?
    It finds no supported algorithm in the authenticated DS RRset, so RFC 4035 §5.2 tells it to act as if no DS existed: the zone is insecure and its answers are returned unvalidated, without the AD bit. Users are not broken, but they are not protected either, which is why validator support is part of the algorithm decision.

saying these in an interview costs you the question

  • ECDSA signatures are larger than RSA ones because curves need more data.
  • An ECDSA zone-signing key under an RSA key-signing key gives ECDSA's sizes.
  • A validator that lacks the zone's algorithm answers SERVFAIL for it.
  • Signature size is irrelevant because DNSSEC answers always travel over TCP.
  • RSASHA1 is still an acceptable algorithm for signing a new zone.
  • ECDSA is faster than RSA for both signing and verification.