It is time to move beyond the theoretical “quantum threat” and into the actual gears of the internet. If we want a future where DNS remains the trust anchor of the web, we have to start breaking things today to see how they’ll hold up tomorrow.
Our team, Timeless Innovators, took this literally. Using the AIORI infrastructure, we built a fully functional Post-Quantum DNSSEC (PQ-DNSSEC) testbed under a delegated .iem.lab domain. We didn’t just read the drafts; we implemented Dilithium3, Falcon-512, and SPHINCS+ to see what happens to a DNS packet when it’s carrying a signature designed to withstand a quantum computer.
1. The Blueprint: Topology of a Quantum-Safe Zone
Modern DNSSEC assumes signatures are small. Quantum-safe signatures are… not. To test this fairly, we architected a three-tier system on a Proxmox hypervisor that separates the heavy lifting of PQC verification from the standard recursive resolution.
The Network Stack
- Tier 1 (Client): Custom dashboards and dig scripts firing concurrent queries.
- Tier 2 (Resolver/Middleware): The “Brain.” An Unbound resolver paired with our custom Python Middleware (using dnslib + liboqs). This middleware handles the PQC heavy lifting that standard resolvers can’t yet digest.
- Tier 3 (Authoritative): A multi-instance PowerDNS setup. Each algorithm (Falcon, Dilithium, SPHINCS) lives in its own isolated zone with a dedicated MySQL backend.
2. The Contenders: A Tale of Three Algorithms
We didn’t just want “security”; we wanted to measure the cost of that security. Here is how the NIST finalists performed in the specialized arena of DNS:
| Algorithm | Signature Size | Verdict |
|---|---|---|
| Falcon-512 | ~666 bytes | The Goldilocks Choice. Fits comfortably in EDNS0 buffers; lowest latency. |
| Dilithium3 | ~3.3 KB | The Heavyweight. Requires careful UDP fragmentation handling or TCP fallback. |
| SPHINCS+ | ~7.8 KB+ | The Mammoth. Stable, but pushes the limits of traditional DNS transport. |
3. Implementation Deep-Dive
Building this wasn’t as simple as flipping a switch. We had to bridge the gap between high-level crypto libraries and low-level DNS protocols.
The Middleware Logic
Since standard resolvers like Unbound don’t natively “speak” Dilithium yet, our middleware acts as a high-speed translator.
- It intercepts the response from the PQC-signed zone.
- It extracts the RRSIG and DNSKEY records.
- Using liboqs bindings, it validates the signature.
- If valid, it asserts the AD (Authenticated Data) flag and passes it back to the client.
Concurrent Performance
We pushed the system with varying loads (1, 5, and 10 concurrent queries). Interestingly, Falcon-512 showed almost no degradation, maintaining a solid 260 QPS even at higher concurrency. SPHINCS+, despite its massive packet size, remained stable, proving that while the “pipes” get full, the crypto itself is remarkably resilient.
4. Key Takeaways for the IETF & Beyond
Our sprints lead to a few “hard truths” for the future of PQ-DNSSEC:
- Fragmentation is the New Normal: If we move to Dilithium or SPHINCS, we must optimize for TCP fallback and large UDP buffers.
- Falcon is the Frontrunner: For general-purpose DNS, Falcon’s signature size makes it the most “drop-in” ready candidate.
- Middleware is a Viable Bridge: We don’t need to rewrite every resolver on day one. Proxy-based PQC verification can secure the path while standards mature.
5. Open Source & Future Sprints
We believe in “show, don’t just tell.” All our C boilerplates for key generation, our Python middleware, and our performance datasets are being polished for the community.
What’s next?
We’re looking toward Hybrid Signatures—combining classical ECDSA with PQC to ensure that even if one algorithm fails, the chain of trust remains unbroken.
