Post-Quantum Authoritative DNS

The short version

How it fits together

The hidden signer holds each zone's unsigned source and its DNSSEC private keys. It signs every change, adds a ZONEMD digest of the whole zone (RFC 8976), and sends each public server a NOTIFY. It runs as its own system user with its own key store, so a compromise of the public server that shares its host cannot read the keys, and it appears in no NS record: there is no address a resolver could ask it at.

The public servers hold only signed copies. Each transfer to a server on another host goes over DNS over QUIC and is authenticated twice: by a TSIG key belonging to that server alone, and by both ends' certificates, which must be issued by our own transfer CA and name the server they belong to, so one server's certificate does not pass as another's. The signer's transfer port is open in the firewall to those servers' addresses alone. Before serving a transfer, a server checks the zone digest and validates every signature, and refuses a zone that fails either. Each also polls the signer on a short interval, so a NOTIFY that is lost delays a change by minutes, not by the SOA refresh.

In the last seven days the signer served 27 transfers (9 over TCP and 18 over QUIC), 39.1 kB in all, after signing 10 times and sending 27 NOTIFYs, 8 of them in QUIC 0-RTT data.

Source: pqcrypta-dns-stats, from the signer's log · 23 Oct 2026, 20:31 UTC

Transports

Every address answers the same zones over every transport below. The availability and times are the health check's, asked from outside the servers' own loopback every five minutes; the query counts are the servers' own.

Source: pqcrypta-dns-health (availability and times since 18 Oct 2026, 21:32 UTC, 1,434 runs; key exchange in the latest run), pqcrypta-dns-stats (queries; DNS over HTTPS: requests to the gateway) · 23 Oct 2026, 20:31 UTC

Per server

Median time to an answer, and the share of checks answered, both addresses of each server together.

DNS over HTTPS and discovery

Knot has no HTTP server, so DNS over HTTPS (RFC 8484) is served by the PQ Crypta Proxy on each host, over HTTP/1.1, HTTP/2 and HTTP/3, with the proxy's post-quantum key exchange, ECH and rate limits. Its gateway listens on loopback only and asks the name server on its own host over TCP, so an answer of any size arrives whole. It forwards standard queries and answers anything else, a zone transfer included, with REFUSED and Extended DNS Error 21 (Not Supported); it pads answers to a multiple of 468 octets when the query asks (RFC 8467) and sets the HTTP cache lifetime from the answer's TTLs. Its path is /dns-query and it gives the name server 3,000 ms to answer.

Each server says which encrypted transports it serves in an SVCB record at _dns.<its name> (RFC 9461), so a resolver can find them without probing:

_dns.ns1.pqcrypta.com. SVCB 1 ns1.pqcrypta.com. alpn=dot,doq,h2,h3 dohpath=/dns-query{?dns}
_dns.ns2.pqcrypta.com. SVCB 1 ns2.pqcrypta.com. alpn=dot,doq,h2,h3 dohpath=/dns-query{?dns}
_dns.ns3.pqcrypta.com. SVCB 1 ns3.pqcrypta.com. alpn=dot,doq,h2,h3 dohpath=/dns-query{?dns}

In the last 24 hours the gateways answered 449 requests: 397 over HTTP/2 and 52 over HTTP/3; 0 from clients other than our own monitors.

Source: pqcrypta-dns-stats (the proxies' access logs and [doh] configuration), pqcrypta-dns-health (discovery records as the signer publishes them) · 23 Oct 2026, 20:31 UTC

Post-quantum TLS, and the build that provides it

Stock Knot cannot negotiate a post-quantum key exchange: its TLS groups are written into the code as classical curves, and the GnuTLS that Linux distributions ship has no ML-KEM. So the servers run a build of Knot against GnuTLS built with leancrypto, which provides ML-KEM (FIPS 203). The build writes a manifest of what went into it, and the collector checks the manifest against the knotd installed on each host and the one actually running.

Every server runs the same knotd, SHA-256 5ada269312a2187e….

The patches

Built 23 Oct 2026, 18:37 UTC from Knot DNS 3.6.1, GnuTLS 3.8.13, leancrypto 1.9.1 and Nettle 3.10.2, with 7 patches:

gnutls-hybrid-group-selection.patch gnutls · SHA-256 bb2edc47a3b7…

GnuTLS 3.8.13, as a server, never chose a hybrid group once the client also offered an elliptic curve: a "not offered" value of -1 won a MIN(), so no hybrid-capable client ever got one. Fixed, a server picks the hybrid group the client offers first.

gnutls-stek-retired-master.patch gnutls · SHA-256 e49f204cc680…

A server may pass a retired session-ticket master key after the current one. The retired key only decrypts tickets it issued and never encrypts a new one, so the key can be replaced, and the old one erased, without dropping every resumption.

gnutls-anti-replay-window.patch gnutls · SHA-256 55f6e9345222…

GnuTLS restarted its record of ClientHellos every anti-replay window, which rejected early data for every ticket issued before the restart: with steady traffic only tickets a few seconds old could use 0-RTT. The record now runs from start-up, bounded by its own expiry.

knot-pq-groups.patch knot · SHA-256 da0d5abb52f5…

Knot's TLS groups were hard-coded classical. Hybrid post-quantum groups come first and, as a server, are preferred; as a client Knot sends key shares for its top two groups; and kdig's DNS over HTTPS uses the same priority as its DNS over TLS.

knot-early-data.patch knot · SHA-256 9ff255d68d6b…

0-RTT done safely, as a server and a client. Every ClientHello carrying early data is recorded for the anti-replay window, so a replay has its early data rejected (Knot's store recorded nothing). The ticket master key is replaced every ticket lifetime and erased one lifetime later, so a key taken from the process cannot decrypt old early data. An OPCODE other than QUERY or NOTIFY in early data is refused with Extended DNS Error 26, Too Early (RFC 9250 section 4.5).

knot-doq-conformance.patch knot · SHA-256 79797b66ff76…

Defects the HTTP/3 scanner's DNS over QUIC checks found in Knot, run against these servers: a NEW_TOKEN token taken for a Retry token (every resumption failed connection-ID authentication); RFC 9250 4.3.3's protocol errors answered instead of closing with DOQ_PROTOCOL_ERROR; random message IDs on Knot's own requests over QUIC where 4.2.1 requires 0; a STREAM FIN in a frame of its own failing the connection; an answer queued on a stream the client had stopped, silencing the connection; no RESET_STREAM back on a client's (4.3.1); truncated, empty or overlong streams dropped silently; and a client's first connection ID not routed, which lost 0-RTT sent in a datagram of its own (RFC 9000 5.2).

knot-retry-scid.patch knot · SHA-256 2dc915c25114…

After a Retry, Knot named its own newly chosen connection ID as retry_source_connection_id, where RFC 9000 7.3 requires the Retry's Source Connection ID, which every client checks: each connection after a Retry failed. ngtcp2 asks for a Retry whenever a ClientHello's later datagram arrives before its first, and a post-quantum ClientHello spans several, so a share of DoQ connections and of the transfers between our servers failed. Found from a capture of both ends; the HTTP/3 scanner's reordered-ClientHello check reproduces it against any DoQ server.

The build stops unless these pass, against the libraries it has just built: GnuTLS resume-with-retired-stek, GnuTLS tls13-early-data-window, GnuTLS tls13-early-data, GnuTLS tls13-early-data-neg, GnuTLS tls13-early-data-neg2, GnuTLS resume-with-previous-stek, GnuTLS resume-with-stek-expiration, GnuTLS session-tickets-ok and Knot test_tls_early_data.

Source: pqcrypta-dns-stats (each host's /opt/pqdns, its build manifest and the knotd process) · 23 Oct 2026, 20:31 UTC

What a client gets

The group a client gets depends on what it offers: the scanner's client offers ML-KEM on its own as well as the hybrids, and the proxy in front of DNS over HTTPS prefers the strongest post-quantum group offered, so the two can differ from the health check's, whose client offers only hybrids.

Source: the HTTP/3 scanner's latest scan of pqcrypta.com, probe 2026.10.23.2 · 23 Oct 2026, 20:28 UTC

DNS over QUIC and DNS over HTTPS, held to their RFCs

The HTTP/3 scanner puts every name server it meets through its conformance checks, each citing the requirement it tests: up to 71 on a server that answers every transport, 33 of them on DNS over QUIC and 14 on DNS over HTTPS. Its catalogues map RFC 9250's 47 requirements and RFC 8484's 28 to the checks that cover them, to the rule its own client follows, or to why it cannot be seen from outside a server. These servers are where every check was tried first, and where the defects in Knot they found were fixed (the knot-doq-conformance.patch above).

Of RFC 9250's requirements, 27 are tested against a server, 11 are rules the scanner's own client follows, and 9 cannot be observed from outside a server. Of RFC 8484's, 13, 11 and 4.

0-RTT, and how fast

A returning client can send its query in the first flight, before the handshake completes (0-RTT). RFC 9250 section 4.5 allows that for a query, since a replayed query only repeats an answer, and nothing that changes state. A QUERY in 0-RTT data: Accepted a QUERY in 0-RTT data and answered in 3 ms, against 4 ms with a full handshake. Section 4.5 permits it for QUERY, but early data can be replayed within the anti-replay window, letting an observer of a resolver's onward traffic confirm which name was asked (7.1): for zones whose lookups are sensitive, turning 0-RTT off on the name server removes that. Holds back an UPDATE sent in 0-RTT: Rejected this connection's 0-RTT data: the UPDATE waited for the handshake like the rest. Session tickets last long enough: Tickets last 6 h, at least the 6 hours section 5.5.3 suggests.

Medians from the scanner's single vantage point (US East (Virginia)), so they include the network path to each server.

Source: the HTTP/3 scanner's latest scan of pqcrypta.com (run it on any domain) · 23 Oct 2026, 20:28 UTC

DNSSEC

Every zone is signed with ECDSA P-256 with SHA-256 (algorithm 13). There is no post-quantum DNSSEC algorithm with an IANA number that validators implement yet, so the zones use one every validator must support. Denial of existence is NSEC3 with no extra iterations and no salt, as RFC 9276 recommends: it does not hand out the zone's names, and extra iterations would only cost every validator CPU. Signatures are valid for 30 days and refreshed 10 days before they expire, so a signer outage leaves that long before any signature lapses. Zone-signing keys roll every 90 days with no one involved; key-signing keys change only with the DS record at the parent. The signer confirms a KSK's submission itself, asking a validating resolver with no cache every 1 hour whether the parent serves a matching DS, and waits 1 day after seeing it before the next step of a rollover. Every version of every zone also carries a ZONEMD digest (SHA384).

"Signatures valid": the shortest time left on any SOA or DNSKEY signature any server serves. "Chain from the root": validated from the root's trust anchor through each parent's DS.

Source: pqcrypta-dns-health (chains, DS, serials, signatures), pqcrypta-dns-stats (the signer's keys and policy, and its log) · 23 Oct 2026, 20:31 UTC

Zone transfers and integrity

A public server takes a zone only from the signer, and only after checking it: ZONEMD verification is on and DNSSEC validation of every transfer is on. Each polls the signer at least every 10 minutes whatever the SOA says, and retries a failed refresh within 2 minutes.

Source: pqcrypta-dns-stats, from each server's log (counting since 23 Oct 2026, 18:04 UTC) · 23 Oct 2026, 20:31 UTC

What they answer

The servers count what they answer, by transport, operation, response code and query type, and the EDNS options and flags queries carry. Counts only: no name and no address is recorded. Our own health check and scanner are among the clients.

Source: pqcrypta-dns-stats: Knot's mod-stats counters on every public server, and the proxies' logs for DNS over HTTPS (counting since 23 Oct 2026, 18:04 UTC) · 23 Oct 2026, 20:31 UTC

Abuse resistance and hardening

An authoritative server must answer whoever asks, so its defences are about what it will not do. These servers never recurse: they answer for their own zones and nothing else. They do not reveal their software or version (version.bind and id.server go unanswered); they accept no zone transfer from anyone, the signer's transfers going the other way; and they cap UDP answers at 1,232 octets, the size that avoids IP fragmentation on the paths that matter (DNS Flag Day 2020). Response rate limiting runs as 2 instances: one limits each source's UDP answers and truncates the rest, which a real resolver retries over TCP and a forged source never does; the other limits the time one source may take over TCP, TLS and QUIC, with our own 6 server addresses exempt so the monitors cannot trip it. DNS Cookies (RFC 7873) let a returning resolver prove its address.

Measured: the scanner sent 200 queries at once from one address; 119 were answered in full and 81 truncated.

Source: the HTTP/3 scanner, ns1.pqcrypta.com · 23 Oct 2026, 20:28 UTC

Source: pqcrypta-dns-stats (counters and logs) · 23 Oct 2026, 20:31 UTC

The processes

Every knotd runs under systemd with a sandbox: its own user, a read-only system, no new privileges, no kernel tunables, modules or logs, a system-call filter, and only the address families a DNS server needs. The settings in force now:

Source: pqcrypta-dns-stats (systemd's view of each unit) · 23 Oct 2026, 20:31 UTC

How it is watched

Every five minutes a health check asks every address over every transport from outside the servers' own loopback, and requires a publicly trusted certificate for the server's name and a post-quantum key exchange on each encrypted one. It checks that every server serves the signer's serial and DNSKEY set, that no signature has less than a safe margin left, that the answers validate through each server against the zone's key, and at each parent, where the zone is delegated and whether the DS matches. It mails an alert when its verdict changes, and System Telemetry's DNS tab shows each run.

Source: pqcrypta-dns-health history · 23 Oct 2026, 20:31 UTC

Among the name servers the scanner has measured

Every scan on the HTTP/3 analyzer asks the scanned domain's name servers over the same transports. Leaving ours out, it has measured 1,480 name-server hosts: 24 answer DNS over TLS, 7 DNS over QUIC and 2 DNS over HTTPS (of 7 asked over it); 16 negotiated a post-quantum key exchange and 0 publish an RFC 9461 discovery record. Ours, 3 hosts: 3 DNS over TLS, 3 DNS over QUIC, 3 DNS over HTTPS, 3 post-quantum, 3 with a discovery record.

Operators whose name servers answer at least one encrypted transport, by the name servers' domain. From one vantage point: a server that filters it reads as not answering.

Source: the HTTP/3 scanner's corpus (corpus_encrypted_dns), measured since 19 Oct 2026, 00:27 UTC

Where it falls short

• One network. All 3 name servers are in AS8560 (IONOS SE). They are separate machines in separate locations, but an outage of that network, or an attack on it, would take every zone off line at once. RFC 2182 section 3.1 asks for name servers in different networks; a server elsewhere is the fix.
• Reverse name of 209.46.123.222. It reads mail.fated.org, the host's own name, not ns3.pqcrypta.com: the address belongs to a host with another role, whose reverse name must stay the name it is known by there. It resolves back to the address, so it is valid (RFC 1912 section 2.1).
• Reverse name of 2607:f1c0:f0b4:4400::1. It reads mail.fated.org, the host's own name, not ns3.pqcrypta.com: the address belongs to a host with another role, whose reverse name must stay the name it is known by there. It resolves back to the address, so it is valid (RFC 1912 section 2.1).
• DNSSEC is classical. Until a post-quantum signature algorithm is standardised for DNSSEC and implemented by validators, the signatures are only as strong as their curve; the transports, not the signatures, are what is post-quantum today.

SOA timers

Source: the HTTP/3 scanner's latest scan of pqcrypta.com · 23 Oct 2026, 20:28 UTC

Recent events

• 23 Oct 2026, 19:29 UTC ns3 a client was rate limited (udp, UDP, by rate)
• 23 Oct 2026, 19:29 UTC ns2 a client was rate limited (udp, UDP, by rate)
• 23 Oct 2026, 19:29 UTC ns1 a client was rate limited (udp, UDP, by rate)
• 23 Oct 2026, 18:40 UTC signer knotd started
• 23 Oct 2026, 18:40 UTC ns1 knotd started
• 23 Oct 2026, 18:39 UTC ns3 knotd started
• 23 Oct 2026, 18:39 UTC ns3 statistics not read: ssh: exit 255: ssh: connect to host <address> port 22: Connection timed out
• 23 Oct 2026, 18:37 UTC ns2 knotd started
• 23 Oct 2026, 18:03 UTC signer pqpdf.com: the parent's DS confirmed the KSK submission
• 23 Oct 2026, 18:03 UTC signer pqpdf.com: DS check at the parent: positive
• 23 Oct 2026, 18:03 UTC signer fated.org: the parent's DS confirmed the KSK submission
• 23 Oct 2026, 18:03 UTC signer fated.org: DS check at the parent: positive
• 23 Oct 2026, 18:03 UTC signer stlweb.dev: the parent's DS confirmed the KSK submission
• 23 Oct 2026, 18:03 UTC signer stlweb.dev: DS check at the parent: positive
• 23 Oct 2026, 18:03 UTC signer pqcrypta.com: the parent's DS confirmed the KSK submission
• 23 Oct 2026, 18:03 UTC signer pqcrypta.com: DS check at the parent: positive
• 23 Oct 2026, 18:03 UTC signer philibertsecurity.com: the parent's DS confirmed the KSK submission
• 23 Oct 2026, 18:03 UTC signer philibertsecurity.com: DS check at the parent: positive

Source: pqcrypta-dns-stats, from the servers' logs: failures, restarts, rate limiting and DNSSEC key events; addresses and key names removed · 23 Oct 2026, 20:31 UTC

Ask them yourself

With kdig (Knot DNS 3.3 or later for DNS over QUIC). Add +tls-ca to check the certificate against the system's roots; kdig prints the key exchange it negotiated.

# DNS over QUIC
kdig @ns1.pqcrypta.com +quic +tls-ca fated.org SOA

# DNS over TLS
kdig @ns1.pqcrypta.com +tls +tls-ca fated.org SOA

# DNS over HTTPS (HTTP/2)
kdig @ns1.pqcrypta.com +https=/dns-query +tls-ca fated.org SOA

# The server's discovery record (RFC 9461)
kdig @ns1.pqcrypta.com _dns.ns1.pqcrypta.com SVCB

# DNSSEC, validated
delv @ns1.pqcrypta.com fated.org SOA

# The zone digest
kdig @ns1.pqcrypta.com fated.org ZONEMD +dnssec

Frequently asked questions