Nové doporučení IETF pro automatický DNSSEC: registr .cz jeden ze dvou záznamů nepřijímá

V červenci vyšel dokument RFC 10026, který dostal označení BCP 246, tedy nejlepší současná praxe. Napsali ho Steve Sheng a Peter Thomassen, u kterého hlavička dokumentu uvádí německou firmu deSEC, prošel pracovní skupinou DNSOP a řeší jedinou věc: co má dělat registr nebo registrátor ve chvíli, kdy si správce domény sám ohlásí, že mění podpisový klíč. Zní to jako administrativní detail. Je to ale postup, který je podle autorů náchylný k chybám.

Otisk klíče drží někdo jiný než jeho majitel

DNSSEC podepisuje odpovědi z DNS, aby se poznalo, že cestou nikdo nic nezaměnil. Důvěra se předává shora dolů: nadřazená zóna drží u delegace záznam DS, což je otisk podpisového klíče té podřízené. Klíč má v ruce provozovatel DNS pro doménu, otisk ale nikoli. Ten je zapsaný o patro výš, u registru.

Když se klíč vymění a otisk zůstane starý, ověřující resolvery po celém světě přestanou doménu považovat za platnou a vrátí chybu. Doména přitom funguje dál, jen se nedá dokázat, že je pravá. Jak to dopadá v praxi, bylo vidět 5. května u německého registru DENIC, kde po výměně klíčů začaly vznikat neplatné podpisy a dotazy na .de selhávaly až do 23:15 světového času; psali jsme o tom v přehledu přerušení internetu za druhé čtvrtletí.

Záznamy CDS a CDNSKEY, popsané v RFC 7344 a 8078, jsou právě proti tomuhle. Správce domény je vystaví ve své zóně, nadřazená strana si je přečte a otisk si přepíše sama. Vydaný dokument neřeší tenhle mechanismus, ale rozhodnutí, která u něj musí udělat právě ta nadřazená strana.

Sedm procent zabezpečených delegací

Proč to někoho zajímá, popsali Barbara Jantzen a Peter Thomassen v únorovém textu na blogu APNIC. Postupy při výměně klíčů jsou podle nich ruční, složité kvůli více poskytovatelům, náchylné k chybám a náročné na podporu (přeloženo z angličtiny). Tentýž text uvádí, že míra ověřování DNSSEC dosáhla v roce 2025 36 procent a podíl zabezpečených delegací 7 procent.

Sedm procent je číslo, které se dá číst dvěma způsoby. Buď je DNSSEC příliš složitý, nebo je riziko rozbití větší než užitek z podepsání. Autoři doporučení sázejí na to, že když se výměna klíčů zautomatizuje, ubude obojího.

Co se po registrech chce

Dokument je psaný jako seznam požadavků na nadřazenou stranu. Než otisk přepíše, musí ověřit shodu mezi záznamy CDS a CDNSKEY a napříč všemi autoritativními jmennými servery delegace, a musí ověřit, že výsledná sada záznamů DS umožní ověřování dál. Když kterákoli kontrola neprojde, změna se ruší.

Nová sada záznamů DS má mít podle doporučení dočasně sníženou dobu platnosti v mezipaměti na 5 až 15 minut, aby šlo změnu vzít zpátky. Po uplynutí té původní se hodnota vrací na běžnou.

Dvě věci jsou napsané tvrději. Automatická údržba se nesmí zastavit jen proto, že je doména zamčená proti změnám u registrátora nebo u registru. Podle nás to dává smysl: zámek chrání před cizím zásahem, kdežto tady mění záznam sám držitel klíče. A ruční cesta musí zůstat otevřená, protože ji je potřeba tam, kde provozovatel DNS automatiku neumí nebo odmítá spolupracovat.

Vlastní kapitolu má i to, komu se má chyba hlásit. Nejdřív provozovateli DNS a technickému kontaktu domény. Držitele domény doporučení upozorňovat nechce, dokud potíž netrvá delší dobu; jako příklad uvádí tři dny.

Dvakrát totéž, a autoři to vědí

Nejméně elegantní bod je třetí v pořadí: provozovatelé DNS musí publikovat záznamy CDNSKEY i CDS, pokud neznají preferenci nadřazené strany. Důvod je prostý – neexistuje způsob, jak se tu preferenci strojově zeptat, takže se pro jistotu vystaví obojí. Dokument si to nijak nezastírá a píše rovnou, že publikovat tutéž informaci ve dvou různých formátech není ideální (přeloženo z angličtiny). Nadřazené straně pak ukládá ověřit, že si oba záznamy odpovídají.

Jak je na tom .cz

Registr .cz běží na systému FRED, který vyvíjí sdružení CZ.NIC, a automatickou správu klíčů má pod zkratkou AKM. Dokumentace FRED se odvolává na RFC 7344 a 8078 a k formátům je v ní jedna věta bez prostoru k výkladu: FRED záznamy CDS nepodporuje. Pracuje výhradně s CDNSKEY.

Popsaný mechanismus se s částí požadavků doporučení kryje. Doména do systému vstupuje sama ve chvíli, kdy na jmenných serverech vystaví platné záznamy CDNSKEY. U dosud nezabezpečené domény musí klíče projít přejímací lhůtou a po celou dobu zůstat platné a nezměněné na všech serverech ze sady; u zabezpečené se změna provede rovnou, protože nové klíče se dají ověřit starými. Mezi dvěma platnými sousedními kontrolami musí být méně než 48 hodin a služba, která záznamy sbírá, běží každých deset minut.

Rozpor s doporučením to není. Výjimka „pokud neznají preferenci nadřazené strany“ míří přesně na tenhle případ – preference .cz je zdokumentovaná, takže tam CDS nikdo vystavovat nemusí. Cena za to je, že správce domén ve více doménách nejvyšší úrovně stejně vystaví oba záznamy všude tam, kde preference nadřazené strany známá není.

Seznam, na kterém velké domény chybí

Kolik registrů automatiku vůbec má, se z jednoho místa zjistit nedá. Nejblíž je komunitní seznam v repozitáři cds-updates: devět domén nejvyšší úrovně (.ch, .cr, .cz, .fo, .li, .nu, .se, .sk a .uz), dvě jihoafrické domény druhé úrovně a obrácený překlad u RIPE NCC. Je to seznam vedený dobrovolně, takže nemusí být úplný. Jedna věc z něj ale plyne: mezi doménami nejvyšší úrovně jsou samé národní, převážně evropské.

Text na blogu APNIC vedle toho připomíná, že samotná .com má 159,4 milionu domén, tedy 42 procent všech na světě. Žádná z velkých generických domén v komunitním seznamu není.

Náš názor: dokument je užitečný přesně v tom, v čem bývají doporučení k provozu nejužitečnější – sepisuje rozhodnutí, která by jinak každý registr dělal po svém a špatně. Na sedmiprocentní podíl zabezpečených delegací ale sám o sobě nesáhne. BCP nikoho nezavazuje a registr, který automatiku nemá, ji kvůli němu ze dne na den nezavede.

Zdroje: RFC 10026 na serveru RFC Editor, záznam dokumentu v IETF Datatrackeru, text Barbary Jantzen a Petera Thomassena na blogu APNIC, dokumentace systému FRED k automatické správě klíčů a komunitní přehled cds-updates.