WireBudgetDNS message laboratory

Algorithms / 02

Read algorithm 18 without overclaiming.

Seeing a signature is the start of an investigation, not the end of validation.

Reviewed October 15, 2026

The dimensions

AlgorithmNumberPublic key bytesSignature bytes
ECDSA P-256136464
Ed25519153264
ML-DSA-441813122420

These are cryptographic byte lengths, not complete resource-record lengths. DNSKEY adds fields before the public key; RRSIG adds fields and a signer name before the signature. Each record also has an owner name and envelope. IANA’s algorithm registry lists ML-DSA-44 as 18. Its referenced DNSSEC mapping remains an Internet-Draft in the source reviewed here.

Three layers of evidence

  1. Record observed. A supplied RRSIG says algorithm 18. WireBudget reads that field and counts its signature bytes. A correctly sized arbitrary byte string will also pass this length check.
  2. Resolver assertion observed. An AD bit is set in the supplied response. That is an assertion represented by a flag; the local reader does not authenticate the response source.
  3. Validation established. A validator verifies signatures and constructs a trustworthy chain under its policy. This tool does not perform that operation.

Our real truncated UDP sample has AD set and no RRSIG in its answer section. That is a useful counterexample to treating “AD set” and “signature present in this packet” as interchangeable.

Coexistence is not a complete PQ chain

The ML-DSA DNSSEC draft discusses downgrade behavior when conventional and post-quantum paths coexist. A validator accepting a conventional path is not thereby demonstrating a post-quantum path. The complete delegation chain and validator policy matter; a leaf signature alone cannot establish them.

Use dnstest.dev for its dedicated resolver-behavior tests. Use WireBudget when you already have a message and need to understand its size and fields. Neither a byte diagram nor our zero-filled synthetic fixtures should be described as a security certification.

Try the controlled comparison

Load the synthetic 64-byte and 2,420-byte signature examples in the inspector. They have the same name, question, answer and metadata shape. Their lengths are 163 and 2519 bytes: a difference of 2356, exactly the signature-length difference. Both contain deliberately invalid signatures. Their purpose is to isolate the byte cost, not to convert one cryptographic algorithm into another.

Size references: RFC 6605 and RFC 8080.

Return to the packet inspector →Methods & sources