Co to je AKM a jak funguje

Systém AKM, neboli Automated Keyset Management, je nástroj, pomocí něhož technický správce DNS prostřednictvím vystavení CDNSKEY záznamů na DNS může spravovat sadu klíčů u domény. Držitel/správce domény vystaví v DNS záznam CDNSKEY u domény a úkolem registru, resp. jeho subsystému AKM, je pravidelně skenovat existenci takového záznamu a při splnění definovaných podmínek takový záznam akceptovat, tj. v registru domén vytvořit a k doméně přiřadit, modifikovat nebo smazat stávající automaticky spravovaný keyset u domény.

Pokud jde o nezabezpečenou doménu, skenuje AKM po dobu minimálně osmi dnů (podrobnější pravidla dále) všechny nameservery nastavené u domény a hledá vystavené CDNSKEY záznamy. Pokud jsou ze všech IP adres všech nameserverů vráceny totožné CDNSKEY záznamy, AKM takový požadavek akceptuje a propaguje do registru domén .CZ (podrobnější pravidla dále).

U zabezpečené domény dojde k akceptování již při prvním naskenování platného CDNSKEY záznamu.

AKM v .CZ

Systém AKM jsme pro domény v zóně .CZ spustili v roce 2017, abychom umožnili zavádění DNSSECu u domén bez aktivní účasti registrátora. Z následujícího grafu je vidět, že podíl domén zabezpečených prostřednictvím AKM, resp. CDNSKEY záznamů, od té doby pěkně stoupl a že jde o využívanou možnost správy keysetů. A nás samozřejmě těší, že vynaložené úsilí nebylo zbytečné.

 

Kdo chce zavzpomínat na zahájení provozu AKM, najde související články na našem blogu Učiňme DNS opět velkým! a Druhá fáze automatizované správy DNSSEC klíčů.

Proč nová verze

Po sedmi letech provozu AKM v zóně .CZ jsme připravili novou verzi, kde jsme se zaměřili na zvýšení robustnosti celého řešení a zjednodušení systému pro uživatele. Nejde tedy jen o technologickou přestavbu, ale i o odolnější vyhodnocovací algoritmus a změny v komunikaci registru (resp. AKM) směrem k uživatelům.

Zvýšení robustnosti běhu aplikace

Pro AKM jsme vyhradili dedikované aplikační servery, aby jeho běh byl co nejméně ovlivněn jinými, nesouvisejícími, technologickými odstávkami. Velká změna je v samotné architektuře SW řešení, kde došlo k rozdělení na více samostatných služeb s definovaným API. Tím se vyčlenil samostatný funkcionální celek nezávislý na specifické implementaci FRED, který se kompletně stará o celou agendu sběru CDNSKEY záznamů. Seznam domén resp. nameserverů k oskenování je řídicí částí rozdělen a probíhá v definovaných dávkách, abychom minimalizovali nutnost opakování většího balíku skenů v případě servisní odstávky nebo výpadku služby. Skenovací worker zpracovává požadavky od řídicí části prostřednictvím perzistentní RabbitMQ fronty. Jádro systému si nově uchovává stavová data v PostgreSQL databázi namísto původní verze, která používá SQLite.

Zvýšení odolnosti vyhodnocení věrohodného CDNSKEY záznamu

Algoritmus vyhodnocení používá rozsah odstupu dvou následujících skenů, který musí být méně než 48 hodin. Pokud při pokusu o skenování některé domény jsou všechny její nameservery v danou chvíli nedostupné nebo neposkytují odpovědi, neresetujeme algoritmus vyhodnocování, ale pokusíme se ověřit existenci CDNSKEY záznamu do 48 hodin od posledního úspěšného skenu. Pokud se to nepovede, pak samozřejmě skenovací lhůty resetujeme a při dalším naskenování CDNSKEY záznamů začne celý proces skenování od začátku.

Zlepšení směrem k uživatelům (držitel domény, technický správce nssetu)

Při změnách zabezpečení domény šla doposud e-mailová komunikace držiteli domény, který v případě běžného vlastníka nic neinicioval. Typicky má u domény defaultní nameserver registrátora a tedy CDNSKEY záznamy publikuje registrátor resp. technický správce nssetu. Držitel domény problematice zabezpečení domény často nerozumí a naopak má strach, že mu někdo chce s jeho doménou něco nekalého provést. V případě, že algoritmus musel resetovat vyhodnocovací lhůtu, např. při změně publikovaného CDNSKEY záznamu, šla další a další komunikace držiteli domény, který nechápal a hledal informace na podpoře.

Vedle toho technický správce neměl možnost v průběhu skenovací lhůty sledovat, co registr (systém AKM) právě skenuje a výsledky případně chyby zjistil až se zpožděním. Až když nedošlo k očekávané změně v registru v předpokládané lhůtě, začal technický správce řešit kde je problém. Ovšem podrobnosti o skenování, tj. stav skenování jaký vidí AKM systém nebyl propagován do veřejného rozhraní a bylo nutné tyto případy řešit přes podporu CZ.NIC.

Z těchto dvou důvodů jsme nahradili e-mailovou komunikaci systému AKM informačním výpisem u domény na webu whois.nic.cz. Pod výpisem parametrů domény je odkaz na „Výsledky skenů“ (resp. přímá URL je „https://www.nic.cz/whois/domain/example.cz/scan-results“), podobně jako odkaz na stažení ověřeného výpisu, kde je jedenáctidenní historie skenů.

Jak jsem uvedl, většina držitelů domén nerozumí problematice zabezpečení do takové míry, aby sami konfigurovali nssety a keysety, což za ně dělá někdo jiný – jejich administrátor a nebo správce nameserveru, typicky registrátor. A jelikož v takových případech blokovalo hromadné automatizované zavedení CDNSKEY zvýšené zabezpečení domén (atribut serverUpdateProhibited), upravili jsme na žádost těchto velkých správců v nové verzi blokační podmínky pro výměnu, přiřazení nebo odpojení keysetu spravovaného AKM. A to tak, že těmto automatickým změnám nově nebrání stav serverUpdateProhibited nastavený u zabezpečované domény. Odpojení keysetu se provede vystavením CDNSKEY záznamu se specifickymi hodnotami (CDNSKEY 0 3 0 AA==) a vždy když jej AKM naskenuje, odebere KEYSET u automaticky i manuálně zabezpečené domény.

Detaily nové verze

Architektura a součásti

Ze schématu architektury původního a nového AKM je vidět větší modularita a otevřenost nového řešení, a také oddělení části specifické pro registr domén FRED od univerzálního funkčního celku pro zpracování CDNSKEY záznamů.

Jednotlivé části nového řešení

• cdnskey-scanner – provádí skenování nameserverů, tj. zjišťuje existenci záznamů CDNSKEY pro konkrétní doménu na sadě nameserverů. Použili jsme stávající řešení.
• cdnskey-processor-worker – zjišťuje existenci záznamů CDNSKEY u množiny domén zadané řídicí částí. Vlastní sken záznamů probíhá pomocí nástroje cdnskey-scanner.
• cdnskey-processor-master – řídicí část obecného řešení cdnskey-processor. Master rozdělí množinu domén z registru k oskenování na menší části a prostřednictvím RabbitMQ je zadá workeru ke zpracování.
• cdnskey-processor-api – gRPC služby, které tvoří otevřené aplikační rozhraní pro možnost začlenit systém cdnskey-processor do libovolného řešení. Základní funkce jsou import úloh do řídicí části (seznam domén a jejich nameserverů ke zpracování) a zpět export klíčů splňujících pravidla CDNSKEY záznamů.
• fred-akm-ng (resp. AKM-NG) – specifický modul, který zajišťuje rozhraní registru FRED pro komunikaci s cdnskey-processor. Získaný seznam CDNSKEY záznamů aplikuje AKM-NG na objekty v registru s respektováním jejich aktuálního stavu.
• výpis skenů ve web whois – jde o výpis surových skenů z cdnskey-processor dostupný v detailu domény.

Podrobnosti k řešení je možné najít ve veřejné dokumentaci FRED https://fred.nic.cz/documentation/html/Concepts/AKM.html

Algoritmus vyhodnocování

Pravidla pro zabezpečenou (secure) doménu

• CDNSKEY záznam musí mít validní atributy algorithm, flags a protocol, a jejich hodnoty musí být z množiny povolených hodnot v konfiguraci registru.
• Atribut public_key musí být validní base64 kódovaný klíč.
• Doména nesmí mít blokující stavy (deleteCandidate – v procesu mazání, serverBlocked – administrativní blokace), nově serverUpdateProhibited u domény neblokuje změnu prováděnou AKM-NG na základě vystaveného CDNSKEY záznamu.

Pravidla pro nezabezpečenou (insecure) doménu

• CDNSKEY záznam musí mít validní atributy algorithm, flags a protocol, a jejich hodnoty musí být z množiny povolených hodnot v konfiguraci registru.
• Atribut public_key musí být validní base64 kódovaný klíč.
• Doména nesmí mít blokující stavy (deleteCandidate – v procesu mazání, serverBlocked – administrativní blokace), nově serverUpdateProhibited u domény neblokuje změnu prováděnou AKM-NG na základě vystaveného CDNSKEY záznamu.
• Skeny musí vracet konzistentní odpověď po celou dobu skenování a napříč všemi nameservery (na všech IP adresách všech nameserverů).
• Pokud skener nalezne jinou odpověď, tj. jiný klíč, jiný jeden z vystavených klíčů nebo pokud na nameserveru nebude během jednoho skenu ze sady ověřovacích skenů vystaven žádný klíč, je taková skenovací perioda přerušena a je nutné skenovat od začátku.
• Ve speciálních případech, kdy dojde k síťové nedostupnosti nameserverů domény, AKM-NG chybné stavy skenování ignoruje. Ovšem musí dojít k validním naskenování původních odpovědí tak, aby mezi dvěma validními sousedními skeny bylo méně než 48 hodin.

Po prvním naskenování vystaveného CDNSKEY záznamu se tento sken opakuje po dobu dalších sedmi dní, takže typicky je minimální doba skenování osm po sobě následujících dní. V důsledku nestandardních stavů skenování resp. dostupnosti nameserverů se může celková lhůta skenování CDNSKEY záznamů prodloužit až na 10 dnů. Jelikož se počítá ve vyhodnoceních přesný čas, nejde při posuzování lhůty o kalendářní dny, ale skutečně o 24 hodin ve významu “24:00:00”.

Přepnutí na novou verzi AKM

Hlavní viditelnou změnou s přechodem na novou verzi AKM bude zrušení e-mail notifikací souvisejících se zahájením, dokončením a nebo zastavením skenovacího procesu. Nově budou mít zájemci k dispozici výpis skenů pro kontrolu průběhu skenování jejich zájmové domény. Výpis skenů bude dostupný v prostředí aplikace web whois (whois.nic.cz).

Dosavadní produkční a nová nasazovaná verze AKM (v naší terminologii AKM a AKM-NG) běží již řadu dní paralelně v produkčním prostředí, oba systémy nezávisle na sobě skenují a vyhodnocují výsledky, jen do registru domén zasahuje pouze dosavadní AKM. Přepnutí na novou verzi proto očekáváme ve většině případů bezvýpadkově, což znamená, že AKM-NG plynule naváže na dosavadní vyhodnocování. Ke změně dojde v případě domén, které mají nastavený atribut serverUpdateProhibited, neboť dosavadní verze takové domény nezmění, kdežto nová verze je zpracuje. Další případné odchylky ve zpracování CDNSKEY záznamů v prvních dnech po přepnutí z jednoho systému na druhý mohou být způsobeny právě nezávislým skenováním obou verzí AKM systému, konkrétně časem, kdy který systém konkrétní doménu skenoval a tím pádem závisí na dostupnosti CDNSKEY záznamu nikoli pouze pro konkrétní datum, ale pro konkrétní okamžik skenování. V těchto případech je nejlépe zkontrolovat výpis skenů v rozhraní web whois aplikace.

Update 4. 11. 2024: Od 28. 11. 2024 jsme ještě podle provozních metrik optimalizovali konfiguraci produkční instance nového AKM a proto jsme finální přepnutí na novou verzi provedli až ve večerních hodinách 3. 12. 2024.

A kdo se chce podívat AKM více pod kapotu, tomu doporučuji chystanou přednášku kolegy Zdeňka Brůny v lednu 2025 na komunitním setkání CSNOG 2025.

FRED tým

Autor: Aleš Jarolímek