Set up your own PQC testbed for DNSSEC with the PATAD open-source software

Recap: post-quantum cryptography and the DNS

Our work revolves around the intersection of 2 technologies: post-quantum cryptography (PQC) and DNSSEC, the secure version of the Domain Name System (DNS).

PQC is cryptography that runs on traditional computers but is designed with a quantum computer's abilities in mind. It is important because it protects our digital infrastructure from future powerful quantum computers breaking current cryptographic algorithms. Whether such a quantum computer can be built at all is still unknown, but many experts consider it increasingly likely.

DNSSEC is a protocol that provides authentication and integrity for the DNS using cryptographic algorithms such those as based on Elliptic-Curve Cryptography (ECC). However, the “traditional” cryptography that we rely on for DNSSEC and many other applications might be broken by a powerful enough quantum computer. Therefore, we need to replace current DNSSEC algorithms with PQC algorithms. We need to work on the replacements now because we know that it takes several years to deploy new DNSSEC algorithms.

The problem: lack of insight into the impact of PQC on DNSSEC

The problem is that we do not yet sufficiently understand the impact of PQC on DNSSEC. For example, we lack insight into what kind of engineering and standardisation it takes to include PQC algorithms in DNSSEC. Also, we do not yet know what the impact of such algorithms will be on DNSSEC’s performance and scalability, for example, in terms the sizes of signatures and keys.

Solving that problem is an active area of research, as we illustrated with others in our Research Agenda for a Post-Quantum DNSSEC. That is why we developed a testbed to address the problem empirically. The testbed is part of our research project Post-quantum Algorithm Testing and Analysis for the DNS (PATAD).

Overview of the PATAD testbed

The purpose of the PATAD testbed is to enable researchers and DNS operators to programmatically emulate distributed DNS topologies to evaluate PQC-enabled DNSSEC. A typical topology would have several authoritative DNS servers with various DNSSEC-signed zones, such as a root zone, 1 or more top-level domains (TLDs) and second-level domains. Such a topology would also contain 1 or more DNSSEC-validating resolvers and a couple of clients (stub resolvers).

Conceptually, the PATAD testbed consists of 2 key parts: (1) DNS(SEC) software with support for post-quantum algorithms, and (2) infrastructure that allows us to easily configure topologies. Let's have a closer look at each of those parts.

Part 1: DNS(SEC) software with support for post-quantum algorithms

First of all, we need software that can both sign zone files and validate DNSSEC signatures. For our testbed, we decided to use the PowerDNS software, since PowerDNS fulfils both tasks using a single code base. This means that, by adding support for PQC algorithms in PowerDNS, we have support for those algorithms in all the components necessary to run a DNS infrastructure that can be used to evaluate the algorithms.

So far, we have integrated 3 PQC algorithms into PowerDNS: Falcon (the 512-bit variant), MAYO (parameter set 2) and SQISign (parameter set NIST-I). They are part of the evaluation and standardization program on PQC algorithms by the National Institute of Standards and Technology (NIST). Falcon has already been selected for standardisation. That means that the Falcon algorithm has withstood close scrutiny from NIST and cryptographers, and that there is sufficient confidence about its security. On the other hand, MAYO and SQISign are still in Round 1 of the Additional Digital Signature Schemes competition. That means that those algorithms have just entered the "competition", have not been under as much scrutiny, and there is currently limited confidence in their security.

We have integrated algorithms once they met the stringent requirements of DNSSEC. For example, Falcon has fast validation performance, the non-standardised MAYO has small signatures and good performance, and the non-standardised SQISign has small signatures and small public key sizes.

Part 2: infrastructure to programmatically build topologies

Changes to DNS(SEC) software to support post-quantum algorithms are essential for testing post-quantum DNSSEC, but are not the only requirement. In addition, we need an infrastructure that makes it straightforward to configure the DNS components and build various topologies in a reproducible way. For that, we are using a container-based approach. This means that each experiment on our testbed consists of a topology of containers, each resembling real-world authoritative name servers and recursive name servers.

Figure 1 shows an example of an experiment. In this experiment, the emulated root zone is signed with SQISign, while the .nl domain and the second-level domain example.nl are signed with MAYO. Each of these PATAD components runs in its own container, potentially on a different server.

Figure 1: example of an experiment. All components are connected using a virtual network. The topology contains PQC-enabled recursive resolvers (on the left) and authoritative name servers (on the right), as well as a node that can run experiments.

The container-based approach meets our requirements because it allows us to specify and experiment with topologies using configuration files only, as illustrated in Figure 2. This allows users to quickly deploy their own testbed, tailored to their experiments. Containers also make it possible to reproduce experiments consistently. For example, users can easily share the configuration of a certain topology, allowing others to perform the same experiments. Furthermore, by choosing this scriptable approach, we are not building the testbed just for ourselves on a piece of hardware only accessible to us. Rather, we are allowing others to easily set up a PQC-enabled DNSSEC testbed, running either in a data centre or on their own machines.

Figure 2: a schematic overview of how we build containers for the PATAD testbed using config files and a build container.

Running a multisite testbed with SURF

To validate our approach, we worked with SURF to build a joint testbed. We used the PATAD testbed components to set up a topology distributed over the networks of SIDN Labs and SURF. At SIDN Labs, we run authoritative name servers for the root and TLD zones, while SURF runs a resolver and an authoritative name server for the second-level zones. The set-up matches the DNS services currently offered by the 2 organisations (except that SIDN does not run a root server).

The purpose of the SIDN Labs-SURF set-up is to serve as a realistic infrastructure on which we can run experiments using production-like zones and query loads. In such experiments, we can use different (post-quantum) cryptographic algorithms and compare how they would perform and what their impact would be on the systems. Our use of containers enables us to easily update and reproduce our experiments in this multi-domain setup.

Next steps

Our next step in the coming months is to carry out measurements with the MAYO PQC algorithm, both on our local PATAD testbed at SIDN Labs, and on a multisite basis, in collaboration with SURF. We will share our results through tech reports or papers that we'll publish on this site. The idea is that our measurements can answer some of the questions we and our partners posed in our Research Agenda for a Post-Quantum DNSSEC.

Secondly, we will be looking into ways to switch between generic and hardware-specific implementations of the same PQC algorithm. Such optimised implementations take advantage of specific CPU instructions (such as AVX2), resulting in better performance.

Finally, we plan to collaborate with universities and have students use our testbed to perform their own measurements.

Get the code and set up your own testbed

The source code of PATAD is now available on GitHub.

The software part is in this repository. It includes our PowerDNS modifications to support the Falcon, MAYO and SQISign PQC algorithms. They are licensed under the same licence as PowerDNS, which is the GNU General Public License, version 2.

Our infrastructure tools are distributed over 3 repositories:

• pqc-auth-powerdns: to build a Docker container that contains PowerDNS Authoritative with support for the Falcon, MAYO and SQISign PQC algorithms.

• pqc-resolver-powerdns: to build a Docker container that contains PowerDNS Recursor with support for the same 3 PQC algorithms.

• pqc-dnssec-testbed: contains scripts and other files to easily set up an example topology.

Furthermore, we publish pre-build Docker images for the PowerDNS authoritative and PowerDNS recursor.

The work in the above repositories is licensed under the permissive BSD-3 license.

We welcome use and contributions by others, including you!

Join PATAD!

We would love you to use our testbed and run your own measurements (acknowledgements are appreciated). Contributions are welcome, and if you are aware of other PQC-enabled DNS implementations (or you maintain one yourself) consider making it available as a component for the PATAD testbed. We will be happy to help you out!

If you have any questions or want to showcase your use of our testbed, please contact us at sidnlabs@sidn.nl.