Evaluating post-quantum cryptography in DNSSEC signing for top-level domain operators

This blog post is based on a peer-reviewed article, which was published and presented at the Network Traffic Measurement and Analysis Conference TMA2025.

Why is post-quantum cryptography relevant?

When quantum computers are sufficiently developed, which may take many more years, they will be able to break the forms of cryptography currently in use. That includes the cryptography deployed in DNS, specifically in DNSSEC. Therefore, it is necessary to investigate how DNSSEC can be transitioned to use post-quantum cryptography (PQC), which is cryptography designed with quantum computers’ capabilities in mind. PQC algorithms have different characteristics compared with algorithms used in DNSSEC today (such as RSA or ECDSA), for instance in terms of signature size and verification time. Therefore, DNSSEC’s transition to PQC will have an operational impact. We considered the background to PQC’s relevance to SIDN in an earlier blog post.

In the remainder of this blog post, we discuss our research evaluating PQC for use in DNSSEC signing by top-level domain (TLD) operators.

What do we want to know?

As the operator of .nl, we are interested in the effects of using post-quantum cryptography on our operations. To measure the impact of PQC, we have analysed the properties and performance of cryptographic algorithms in DNSSEC by signing and verifying zone files. For a TLD operator, signing and verifying a zone file are common operations. Even if, practically, only zone file deltas are signed every half hour, signing the full zone is a good metric for comparing algorithms with each other. We also measured the zone file size, providing us with information about the public key size and signature size of the algorithms.

For DNSSEC signing options, we considered three types of non-existence: NSEC, NSEC3, NSEC3 Opt-Out. For more information on those modes, see RFC 7129.

We tested RSA-1280 (DNSSEC algorithm 8), ECDSA-P256 (DNSSEC algorithm 13), Falcon-512 and MAYO-2. RSA and ECDSA are both algorithms that must be implemented for DNSSEC signing and validation. Both algorithms have a significant share of usage across all TLDs, with ECDSA gaining popularity over RSA. Falcon, a post-quantum algorithm, has been selected for standardisation by NIST. Finally, MAYO is a promising candidate algorithm that is one of the competitors in the NIST process for selecting new post-quantum signature schemes.

We used three zone files as input for our analysis: the .nl, .se and.nu zone files, which we classify as large, medium and small, respectively. The zone files of both .se and .nu are publicly accessible, but the zone file for .nl is not.

Finally, we accounted for hardware acceleration based on CPU features by means of the feature levels of x86-64 architecture. We differentiated between x86-64-v2 and x86-64-v3, which includes AVX and AVX2, two feature flags that we know are used by PQC algorithms.

We then conducted 16 runs, covering all possible combinations of variables.

Acceptable impact on DNSSEC signing

We found that the impact of PQC algorithms on the DNSSEC signing operations for TLD operators is limited. Let’s highlight a few results for the .nl zone file.

When it comes to signing the entire zone file, we present the results relative to the baseline ECDSA-P256 algorithm (algorithm 13). The results are shown in Figure 1. A ratio of “2.0x” indicates that the tested algorithm is twice as slow as the baseline. We observe that both Falcon and MAYO significantly benefit from hardware acceleration. In terms of hardware-accelerated results, Falcon’s performance is roughly comparable to RSA, while MAYO’s performance is roughly similar to ECDSA-P256.

Figure 1: Increase in signing time for .nl zone compared with the baseline algorithm (algorithm 13, ECDSA-P256). Without (left) and with (right) hardware acceleration.

Figure 2: Increase in validation time for .nl zone compared with the baseline algorithm (algorithm 13, ECDSA-P256). Without (left) and with (right) hardware acceleration.

When we validate the entire zone file, we find that MAYO benefits the most from hardware acceleration. For hardware-accelerated results, the performance of Falcon is comparable to ECDSA-P256 (algorithm 13), while the performance of MAYO is comparable to RSA (algorithm 8). This indicates that the performance of the tested PQC algorithms during zone file validation is comparable to that of currently deployed algorithms.

Figure 3: The size of the .nl zone file when the zone is unsigned, signed with traditional algorithms, and signed with PQC algorithms. Note that the y-axis is logarithmic.

Finally, the zone size shows a relatively large increase for both PQC algorithms, due to their larger signature and public key sizes. Particularly Falcon has larger signatures of 666 bytes, compared with 64 for algorithm 13. This impacts TLD operators, not just in terms of the disk space needed for their authoritative servers, but also in terms of memory consumption (loading the entire zone in memory) and bandwidth.

The results demonstrate that the performance impact on both signing and validation is minimal. That is because the performance of both PQC algorithms is comparable to that of the algorithms currently most widely deployed, provided that hardware acceleration is utilised (x86-64-v3).

Next steps in our research

Since carrying out the study described here, we have started working on measuring the impact of PQC DNSSEC on DNS resolvers. We will use anonymised traffic traces from a real-world resolver and replay the flow on our testbed. That will allow us to study the impact of PQC DNSSEC on the resolver. For instance, in some cases, DNS messages are too large for a single UDP packet, so DNS falls back on TCP. We want to analyse the impact of resolvers switching to TCP on the experience of the end-user, as well as on the authoritative servers.

You can read the full research paper for a more detailed analysis.

We would love to hear your feedback or comments.