Resolver 1.1.1.1 ověřuje postkvantové podpisy DNSSEC dlouhé 2 420 bajtů

Cloudflare oznámil 10. září 2026, že jeho veřejný DNS resolver 1.1.1.1 ověřuje podpisy DNSSEC vytvořené algoritmem ML-DSA-44. Je to první krok k tomu, aby se podepisování DNS obešlo bez matematiky, kterou by budoucí kvantový počítač uměl rozlousknout.

DNSSEC je podpis nad odpověďmi z DNS. Bez něj server odpovídá nepodepsaně a útočník, který dokáže odpověď podvrhnout, pošle uživatele na adresu podle svého. Ověřující resolver jde místo toho po řetězu podpisů od kořene DNS až k hledané doméně a kontroluje, že odpověď nikdo cestou nepřepsal.

Algoritmy, kterými se dnes ty podpisy vytvářejí, jsou skoro bez výjimky RSA a ECDSA. Oba stojí na úlohách, které klasický počítač nespočítá, kvantový ale ano. Takový stroj zatím neexistuje a Cloudflare o něm mluví jako o možnosti pro rok 2030.

Podpis, který se nevejde do jednoho paketu

ML-DSA-44 je jedna z variant algoritmu, který americký úřad NIST vydal jako normu FIPS 204 13. srpna 2024. Jeho podpis má 2 420 bajtů a veřejný klíč 1 312 bajtů. Podpis ECDSA nad křivkou P-256 má 64 bajtů, takže postkvantová varianta je skoro osmatřicetkrát delší.

To by byl v jiném protokolu detail. V DNS je to potíž, protože dotazy a odpovědi se tradičně vejdou do jediného paketu UDP. Původní omezení bylo 512 bajtů, rozšíření EDNS(0) je posunulo výš, ale řada implementací drží opatrných 1 232 bajtů, aby se odpověď vešla do nejmenší povolené velikosti rámce v IPv6. RFC 9715 z ledna 2025 doporučuje jako strop 1 400 bajtů. Samotný podpis ML-DSA-44 je nad tím obojím, a to ještě než se k němu připočte vlastní odpověď, jména a hlavičky.

Nejvíc to bolí u dotazu na DNSKEY, tedy na klíče zóny. Tam se k podpisu o 2 420 bajtech přidá ještě klíč o 1 312 bajtech. A protože zóny budou ještě roky publikovat i staré podpisy pro resolvery, které ML-DSA-44 neumějí, bude v takové odpovědi obojí naráz. Rozdrobit ji na fragmenty UDP je nespolehlivé, takže autoritativní server má vrátit odpověď useknutou a nechat resolver, ať se zeptá znovu přes TCP.

Zkusit si to jde: dotaz na valid.mldsa44.dnstest.dev přes 1.1.1.1 vrátí adresy 188.114.96.0 a 188.114.97.0, a v ukázce, kterou Cloudflare zveřejnil, u toho stojí varování o useknuté odpovědi z UDP a opakování přes TCP.

Provozně to Cloudflare nepřekvapí. Podle jeho vlastních čísel přijde na 1.1.1.1 zhruba 85 procent dotazů přes UDP; přes všechny služby, které běží na stejné platformě, je to asi 60 procent a zbytek už dnes chodí přes TCP, DNS over TLS a DNS over HTTPS.

Dva algoritmy vedle sebe otevírají cestu zpátky

Vyměnit algoritmus naráz nejde. Kdyby zóna publikovala jen ML-DSA-44, starší resolvery by ji neověřily vůbec. Praktický postup je proto publikovat staré i nové klíče a podpisy současně.

Jenže tím se postkvantové bezpečnosti nedosáhne. RFC 6840 říká v oddílu 5.11, že ověřovatel „SHOULD accept any single valid path“, tedy že mu má stačit jedna platná cesta. Dokud jsou obě bezpečné, je to rozumné. Ve chvíli, kdy ECDSA padne, je to díra: útočník podstrčí odpověď podepsanou jen starým algoritmem a resolver ji přijme, přestože by uměl ověřit i tu novou.

Cloudflare to řeší tím, že se ptá rodičovské zóny. Pokud ověřený záznam DS obsahuje položku pro podporovaný postkvantový algoritmus, 1.1.1.1 na sebe uvalí přísnější pravidlo: musí projít aspoň jedna postkvantová cesta a stará sama o sobě nestačí. Když žádný podpis ML-DSA-44 neprojde, ověření selže. Není to obvyklé chování DNSSEC, ale RFC 4035 nechává na místní politice resolveru, které podpisy navíc chce kontrolovat.

Ochrana platí jen potud, pokud postkvantové podpisy a tenhle signál sahají od kotvy důvěry přes všechna předání až dolů. Každé patro bez nich je místo, kde se dá spadnout zpátky. Častější výměna klíče zóny to nespraví, protože útočníkovi stačí zaútočit na kterýkoli slabý klíč výš v řetězu a podvrhnout všechno pod ním.

Co ještě chybí

Potřebné formality ML-DSA-44 splnil. NIST ho vydal jako normu, kryptografické knihovny ho umějí a IANA mu 10. srpna 2026 přidělila v registru algoritmů DNSSEC číslo 18 se zkratkou MLDSA44. Zapsala ho ale se stupněm MAY jak pro podepisování, tak pro ověřování, tedy jako možnost, ne doporučení, a jako odkaz vede u toho záznamu návrh draft-westerbaan-dnssec-mldsa. Ten je zatím individuální podání, ne dokument pracovní skupiny IETF; poslední revize je z 11. srpna 2026 a platnost jí vyprší v únoru 2027.

Chybí i zbytek řetězu. Autoritativní servery musí zóny postkvantově podepisovat, registrátoři přijímat příslušné záznamy DS a registry je publikovat v nadřazených zónách. A především to musí dojít až ke kořeni DNS a jeho postkvantový klíč se musí stát kotvou důvěry pro ověřující resolvery. Cloudflare píše, že dalším krokem je podepisování v jeho autoritativním DNS a podpora záznamů DS v jeho registrátorovi, obojí bez příplatku.

Že se s tím začíná u resolveru, dává smysl: podepisovat zónu algoritmem, který nikdo neověřuje, je práce bez odběratele. Podobně postupuje i zbytek oboru, byť každý protokol svým tempem, nedávno třeba IETF u SSH.

Pro uživatele 1.1.1.1 se nemění nic. Zóny, které postkvantové záznamy nemají, se ověřují jako dosud; ty, které je mají, projdou novou kontrolou samy od sebe.

Zdroje

• Cloudflare: 1.1.1.1 now supports post-quantum DNSSEC, all 2,420 bytes of it (10. 9. 2026)
• IANA: Domain Name System Security (DNSSEC) Algorithm Numbers
• IETF: Module-Lattice Digital Signature Algorithm for DNSSEC
• NIST: FIPS 204, Module-Lattice-Based Digital Signature Standard
• RFC 9715: IP Fragmentation Avoidance in DNS over UDP
• RFC 6840: Clarifications and Implementation Notes for DNS Security