How to test post-quantum DNSSEC transport

DNSSEC authenticates DNS data with public keys and signatures. Post-quantum signatures change the size and processing cost of that evidence. The smallest standardized ML-DSA signature is 2,420 bytes before DNS record and message overhead, already larger than the 1,232-byte DNS-over-UDP payload target used to reduce fragmentation risk. A verifier that accepts the signature in a unit test has not yet proved that a real resolver can retrieve it reliably.

Treat the trial as a path test across the cryptographic inventory: signer, HSM, authoritative server, anycast edge, firewall, recursive resolver, validating cache and monitoring system. Attach every result to the exact draft revision, algorithm parameters and software build. That keeps experimental evidence separate from a production post-quantum migration decision.

Start with the wire budget

The 1,232-byte target comes from the IPv6 minimum MTU of 1,280 bytes minus 48 bytes for IPv6 and UDP headers. It is not a universal path MTU and does not promise that every path will deliver a packet of that size. It is a conservative operating target. RFC 9715 recommends avoiding IP fragmentation, while RFC 9210 requires DNS clients and servers to support TCP so a client can retry a truncated UDP response.

Build a response corpus before benchmarking

• DNSKEY responses for each planned key role and parameter set, including the parent-facing DS path.
• Common positive answers with RRSIG records, including the largest RRsets the zone serves.
• NXDOMAIN and NODATA answers using the zone's actual NSEC or NSEC3 policy.
• Delegation and referral responses, because unsigned delegation data still shares the transport path.
• Algorithm and key rollovers with old and new keys or signatures present together.
• Dynamic or online-signed answers if the service creates records at query time.

Generate the corpus from a copy of a representative zone, not a toy zone containing one A record. Keep the exact zone file, signer configuration and response bytes as test artifacts. Hash them so a later software or draft revision can be compared against the same inputs. The PQC migration roadmap can then treat DNSSEC as a measured workstream with an owner and acceptance gate.

Verify truncation and TCP retry end to end

• Send UDP queries with an advertised EDNS payload of 1,232 bytes and capture both IPv4 and IPv6 traffic.
• For every oversized response, require a UDP reply with the TC bit set and no IP fragments.
• Require the resolver to retry over TCP and receive the complete response with the same DNS result.
• Repeat through the real firewall, load balancer, anycast and network-address-translation paths.
• Test connection reuse and concurrency instead of measuring only a single cold TCP exchange.
• Record timeout, retry, SERVFAIL and validation-failure rates separately so one failure mode cannot mask another.

RFC 9210 makes TCP support a DNS requirement, but an architecture diagram is not evidence that every production path permits it. Middleboxes may apply shorter idle timers, smaller state tables or different access rules to TCP port 53. An implementation audit should verify those controls and the resolver behavior that triggers them rather than accepting a configuration claim.

Also test loss. Drop the truncated UDP reply, delay the TCP handshake and interrupt a reused TCP connection. The service should recover within its resolution budget without accepting unsigned data or disabling validation. A transport failure and a cryptographic failure need distinct telemetry because their remediation is different.

Measure the load created by fallback

Moving an answer from UDP to TCP changes state and work on both sides. Measure accepted connections per second, concurrent connections, memory per connection, handshake latency, response latency, cache hit rate and retry volume at the authoritative service and recursive layer. Include abusive query patterns and rate controls. RFC 9210 warns that stream reassembly and connection tracking need resource limits, so capacity testing belongs beside correctness testing.

Signing cost needs its own trace. For offline-signed zones, measure batch duration, zone size, transfer size and publication lag. For online signing, measure tail latency and HSM utilization under the real query distribution. A conformance test can check signature behavior, but it does not prove that the surrounding DNS service remains available under fallback and signing load.

Evaluate MTL as an experiment, not a shortcut

The current ML-DSA-MTL draft amortizes an ML-DSA signature across a Merkle Tree Ladder and carries an authentication path with each covered DNS response. Revision 03 adds a client optimization: cache a validated signed ladder so later responses can avoid repeated full verification and duplicate storage. The same draft notes that online signing may limit amortization to data returned in one query.

Those properties create useful experiments. Compare full response size, verification time, cache memory, cache invalidation, batch latency and behavior after a ladder update. Run the comparison with a cold cache and a warm cache. A design that looks efficient only after state has accumulated needs an explicit cold-start and eviction budget.

Set a release gate that can fail

• Every corpus response validates through the intended resolver set using the pinned experimental profile.
• No tested UDP path depends on IP fragmentation; oversized responses truncate and complete over TCP.
• Fallback latency and failure rates stay inside the service objective under expected and abusive load.
• The authoritative and recursive tiers have measured TCP capacity, connection limits and alert thresholds.
• Rollover overlap, cache eviction and cold-start behavior pass the same transport and validation checks.
• Rollback returns to an approved DNSSEC state without publishing unsigned data or silently disabling validation.

Keep the release gate in the crypto-agility implementation plan. DNSSEC algorithm identifiers, signer policy, resolver support and transport capacity must change together. If a draft revision changes its wire format or code points, the trial should fail closed until fixtures and interoperability evidence are regenerated.

This method does not establish that ML-DSA-MTL will become an RFC, that a particular post-quantum DNSSEC algorithm will be selected, or that one lab path represents the public Internet. It establishes a narrower claim: the tested DNS stack handled large authenticated responses, fallback and load in a known configuration. That is the evidence an operator can use while standards work continues.

References

• draft-kaizer-dnsop-ml-dsa-mtl-dnssec-03. Work in progress defining an ML-DSA-44 Merkle Tree Ladder format for DNSSEC and its implementation considerations.
• draft-sheth-pqc-dnssec-strategy-02. Individual Internet-Draft proposing conservative fallback and low-impact algorithm roles for post-quantum DNSSEC.
• RFC 9715: IP Fragmentation Avoidance in DNS over UDP. Conservative UDP payload guidance, truncation and retry considerations.
• RFC 9210: DNS Transport over TCP, Operational Requirements. Requirement for DNS clients and servers to support UDP and TCP, plus operational capacity considerations.
• NIST FIPS 204. Standardized ML-DSA parameter sets, key sizes and signature sizes.
• RFC 8900: IP Fragmentation Considered Fragile. Operational and security problems created by IP fragmentation.