Post-Quantum DNSSEC Verification in systemd-resolved

My contribution adding ML-DSA-44 support for DNSSEC verification was merged into systemd and now systemd-resolved can verify DNS records signed with this post-quantum algorithm.

DNSSEC protects against forged DNS answers but a sufficiently powerful quantum computer could break the RSA and ECDSA signatures used today. Preserving that protection requires new signature algorithms and resolvers that can verify them.

This post covers the implementation, the deployment tradeoffs and a practical test using systemd.

Why DNSSEC matters

A forged DNS answer can redirect an application to an attacker’s server. DNSSEC protects signed zones by verifying record signatures through a chain of trust to a configured trust anchor. It also authenticates answers proving that a name does not exist. See RFC 3833 and RFC 4033 for the threats and guarantees.

With DNSSEC enabled, systemd-resolved performs this validation locally for applications, rather than relying only on the upstream resolver’s verdict.

DNSSEC does not encrypt DNS traffic, authenticate records from unsigned zones or stop attackers from blocking replies. It also does not replace TLS certificate validation for HTTPS.

ML-DSA and the new DNSSEC draft

ML-DSA is a post-quantum signature algorithm standardized by NIST in FIPS 204. The DNSSEC draft defines how to use its ML-DSA-44 variant to sign DNS records.

Larger signatures change the transport requirements

ML-DSA-44 signatures are much larger than ECDSA P-256 signatures:

DNSSEC algorithm	Algorithm number	Public key	Signature
ECDSA P-256 / SHA-256	13	64 bytes	64 bytes
ML-DSA-44	18	1312 bytes	2420 bytes

These figures cover the key and signature only. DNS metadata and packet headers add more bytes. ECDSA’s encoding is defined in RFC 6605.

That is about 38 times the signature size and 20 times the public-key size.

DNS queries commonly start over UDP. Many resolvers limit UDP DNS replies to 1232 bytes to reduce the risk of IP fragmentation, where one packet is split into smaller pieces that can be dropped along the network path. This is a chosen limit, not UDP’s maximum capacity.

An ML-DSA-44 signature alone is 2420 bytes, so a signed answer cannot fit within that limit. The server returns a reply marked as truncated, telling the resolver to ask again over TCP which can carry the full answer across multiple packets and retransmit lost data. Simply allowing larger UDP replies can bring back the fragmentation problems described in RFC 9715.

In practice, DNS servers and firewalls must allow DNS over TCP (port 53) for these retries to succeed. On embedded devices, test the lookup latency, network traffic, memory use and signature verification time on the actual hardware.

What I added to systemd-resolved

systemd-resolved now verifies ML-DSA-44 signatures through OpenSSL. It checks the key and signature lengths, imports the DNSKEY public key and verifies the signed data in DNSSEC canonical form.

I also added tests using the reproducible test vector from section 6 of the draft.

One distinction matters: an invalid signature must not be confused with an unsupported algorithm. The resolver reports ML-DSA-44 as unsupported when it is unavailable from OpenSSL. Once support is available, key-import and verification failures must remain failures rather than being misclassified as missing support.

Dual signing and the downgrade risks

During migration, a zone can publish both classical and post-quantum signatures to preserve validation for older resolvers. However, RFC 6840, section 5.11 recommends accepting any single valid validation path.

Once an attacker can break the classical algorithm, they could strip the ML-DSA signatures and forge a classical signature that the resolver still accepts. ML-DSA support alone would not prevent that downgrade.

The draft discusses this in section 7.2. Cloudflare’s 1.1.1.1 implementation requires a valid post-quantum path when the authenticated DS record set advertises a supported post-quantum algorithm. That downgrade-prevention policy is separate from the verification support added by my PR.

The same concern applies higher in the chain. Signing a zone with ML-DSA is not enough if an attacker can forge a classical signature in a parent zone. The parent zones and the trust anchor need post-quantum protection too.

Testing with systemd-resolved

My test system shows:

# systemctl --version
systemd 263 (263~devel)

Check whether your OpenSSL installation supports ML-DSA-44:

# openssl list -signature-algorithms -select ML-DSA-44
  { 2.16.840.1.101.3.4.3.17, id-ml-dsa-44, ML-DSA-44, MLDSA44 } @ default

For the live tests, I used Cloudflare’s 1.1.1.1 and the public test zones at dnstest.dev.

Configure the resolver

Create /etc/systemd/resolved.conf.d/90-mldsa-dnssec.conf, creating the directory if needed:

[Resolve]
DNS=1.1.1.1
Domains=~dnstest.dev
DNSSEC=yes
DNSOverTLS=no

The route-only domain ~dnstest.dev directs matching queries to the configured system DNS server, subject to any competing per-link routes. DNSSEC=yes enables local validation and DNSOverTLS=no uses unencrypted DNS transport for this test. DNSSEC authenticates the records independently of transport encryption.

These are global resolver settings: adding 1.1.1.1 can also affect queries outside the test domain and links can have their own DNSSEC settings. Use resolvectl status to check the effective configuration, especially when a VPN or network manager supplies DNS settings. The options are documented in resolved.conf.

Restart the resolver as root and check the settings:

# systemctl restart systemd-resolved
# resolvectl flush-caches
# resolvectl status

Make sure the system clock is correct: DNSSEC signatures have inception and expiration times. The network must also allow DNS over TCP for the larger replies.

Check an authenticated answer

First, query a valid ML-DSA-44-signed record:

# resolvectl query -t A valid.mldsa44.dnstest.dev
valid.mldsa44.dnstest.dev IN A 188.114.96.0                 -- link: enp0s1
valid.mldsa44.dnstest.dev IN A 188.114.97.0                 -- link: enp0s1

-- Information acquired via protocol DNS in 368.3ms.
-- Data is authenticated: yes; Data was acquired via local or encrypted transport: no
-- Data from: network

IP Addresses may change but the important part of the output is:

-- Data is authenticated: yes

Check invalid answers

Next, query records with deliberately invalid signatures:

# resolvectl query -t A invalid.mldsa44.dnstest.dev
# resolvectl query -t A expired.mldsa44.dnstest.dev
# resolvectl query -t A invalid-dnskey.mldsa44.dnstest.dev

Test	expected result
Valid ML-DSA-44 signature	Authenticated
Invalid answer signature	Rejected: `DNSSEC Bogus`
Expired answer signature	Rejected: `signature-expired`
Invalid DNSKEY signature	Rejected: `DNSSEC Bogus`

The valid answer was authenticated and all three invalid cases failed as expected. These are the results from my test run; exact error messages may vary.

The live tests exercise a path that also includes Cloudflare’s validating resolver. A rejected lookup alone does not establish which resolver rejected the data. The unit tests exercise systemd-resolved’s local verification code directly, while downgrade behavior with mixed algorithms requires separate testing.

After testing, remove the drop-in if it was created only for this experiment and restart systemd-resolved to restore the previous configuration.

Conclusion and future work

ML-DSA-44 verification is now integrated into systemd-resolved, bringing this capability to the local resolver used by many Linux distros.

The next implementation step is downgrade protection: when an authenticated DS record set advertises a supported post-quantum algorithm, require a valid post-quantum validation path. A classical signature alone must no longer be enough. This would prevent a future quantum attacker from exploiting classical fallback. Verification support is already integrated; enforcing this policy remains future work.

Broader deployment across servers, desktops and embedded devices also requires testing larger DNS replies on real networks, measuring latency and resource use, and extending post-quantum signing and downgrade protection throughout the DNS chain of trust.

References

Embetrix helps customers plan and implement the PQC transition, from crypto-agility assessments and hybrid OTA signing to TLS migration and validation on real embedded hardware. If your products need a practical path to post-quantum security please get in touch.