Základní stavební kameny správy registru naší národní domény se ve svém okolí snažím popisovat poměrně často. Přesto (nebo právě proto) je stále „tečka cézet“ vnímáno jako něco, co prostě funguje. Obdobně jako když ráno sednete do auta a odvezete děti do školy. Počítáte s tím, že vám cesta zabere obvyklých 10 minut (nebo 15 pokud potřebujete doplnit palivo) a nebudete muset řešit žádné trable. I když víte, že je třeba pravidelně měnit olej, kontrolovat a měnit opotřebovávané součástky nebo opravovat závady vzniklé provozem, většina z vás tahle „vykolejení ze stavu funguje“ nechává na odborníky v servisu nebo aspoň na šikovného souseda a vyvaruje se mytí rukou od kolomazi nebo potřeby znát jaký typ brzdových destiček potřebuje. Moderní vozy vás dokáží o nutnosti zásahu informovat a vy potřebujete jen znát správné telefonní číslo. Přesto, že člověku na druhé straně úplně nerozumíte, protože máte základní povědomí o fungování auta, dokážete ho pochopit.
Proto se pokusím dnešní pokus o popsání jednoho méně obvyklého a přitom významného zásahu do infrastruktury .CZ domény, který naší „servisáci“ provedli minulý týden, srovnat právě se servisním zásahem na automobilu. Jistě se shodneme, že jednou ze základních podmínek jízdy automobilem je mít ve voze palivo. Palivo, které se dostane z nádrže do válce motoru, kde se jeho spálením přenes energie přes píst a klikovou hřídel až k tažné nápravě vozidla a díky tomu jedeme. A jak je to u registru domén? Řekněme, že palivem pro něj je obsah zóny, který pro plynulý a bezvadný provoz (DNS a tedy i Internetu) potřebujeme přenášet z databáze registru do jednotlivých instancí DNS anycastu. Těch se běžný uživatel internetu (respektive jeho internetový prohlížeč) ptá na to, co potřebuje vědět. Tedy na to, kde najde obsah pro doménu, který chce právě uživatel zobrazit na svém počítači. Obdobně jako palivo proudí z nádrže do motoru nepřetržitě, tak i zóna putuje od registru k DNS serverům bez přerušení (v případě .CZ domény dochází k updatu jednou za 30 minut), protože její obsah se velmi dynamicky mění. Až sem je srovnání sice poněkud přitažené za vlasy, ale jisté podobnosti si mezi systémem registru nebo automobilu dokážeme představit. Když ale přistoupíme k tomu, že budeme provádět výměnu důležité součástky palivového systému nebo systému distribuce zóny, začne moje srovnání kulhat minimálně na jednu nohu. V případě potřeby výměny palivového čerpadla s čističem paliva se totiž zcela jistě smíříte s tím, že minimálně pár hodin, ale někdy i dní, nebudete jezdit. Automobil zavezete do servisu a v lepším případě budete jezdit náhradním, v horším přesedláte na jiný prostředek. Váš opravovaný automobil ale po dobu zásahu nejede. V případě potřeby výměny generátoru zóny a systému na její podepisování ale čekáte, že systém jako celek bude fungovat bez viditelné změny. Jak rozdílná je práce servismana v autoservisu a v CZ.NICu! :)
Ano, v minulém týdnu jsme provedli (přesněji řečeno dokončili) výměnu systému pro generování zóny a její podepisování pomocí technologie DNSSEC a až na pár zasvěcených si této zásadní změny nikdo nevšiml. Ano, našim administrátorům tak asi z běžných uživatelů nikdo nepoděkuje a obdivné „wow“ uslyší jen od svých kolegů, šéfů nebo hrstky odborníků, kteří dokáží jejich práci ocenit. Jak je znám, jsou za tento „průběh oslav“ mnohem raději, než kdyby jim před jejich home-office stepovali redaktoři ve snaze zjistit, kde se stala při zásahu chyba, protože „to nefunguje“. Rizika rozbití systému u takovýchto zásahů totiž obvykle převažují nad pochopitelnými přínosy. Následující řádky případně přeskočte, pokusím se velmi stručně popsat základní prvky změny, včetně zvoleného postupu a přínosů.
Generování a podepisování zóny provádíme na tzv. hidden master (HM) serveru. Po velmi dlouhou dobu jsme generování prováděli pomocí DNS démona BIND a podepisování (protože to tehdy, když jsme s DNSSECem začínali nešlo jinak) pomocí námi odladěných skriptů. Co funguje, na to se nesahá, tohle heslo zná každý. Jenomže, když máte v „domě“ vývojáře DNS démona Knot, nakonec neodoláte touze vyzkoušet si i pro tuto část DNS infrastruktury jejich dítě. Tím spíš, pokud je to dítě „nejrychlejší ze třídy“, máte s ním výborné zkušenosti z DNS serverů anycastu a také dokáže nahradit poněkud zaprášené podepisovací skripty (díky Mariane!) dobře zdokumentovaným a udržovaným kódem. Důvěřuj, ale prověřuj platí u takovéto akce několikanásobně. Proto naši administrátoři nejprve provedli simulaci změny HM v testovacím prostředí a změnu v produkčním prostředí rozfázovali do několika etap, kdy do systému nového HM posílali postupně testovací domény, následně naše produkční domény druhého řádu podle jejich důležitosti, poté doménu ENUM a až naposledy doménu .CZ. Protože máme, stejně jako zbytek infrastruktury registru, všechny jeho servery ve třech geograficky odlehlých lokalitách, mohli jsme zařídit, aby část provozu fungovala přes původní HM, určená pak přes nové. Toho jsme při přechodu na Knot DNS vrchovatě využili. Díky testování jsme zjistili, že instancím DNS anycastu, které běží s DNS démonem NSD, trvá delší dobu, než po změně HM začnou přijímat změny v zóně z nového umístění. Knot DNS a BIND reagují v tomto ohledu bez prodlení. Rychlejší akceptaci změny lze vynutit restartování NSD démona, ale tak dojde k výpadku funkce DNS v řádu jednotek minut.
Bylo tedy nutné na těchto lokalitách v průběhu přechodu odstavit propagaci našich prefixů (tj. zneviditelnit je pro uživatele), provést nejprve restart, počkat na stažení zóny z nového umístění a poté je opět zpřístupnit lokalitu zvenku. Pokud bychom toto neudělali, došlo by k tomu, že na různých místech světa by jednotlivé nody DNS anycastu odpovídaly na stejné dotazy různě a to rozhodně není žádoucí. Součástí přechodu na nové HM byla i simulace komunikace externího uživatele s nodem anycastu, kde již byla generována zóna pomocí nového HM. Provedli jsme to tak, že jsme jednu lokalitu DNS anycastu odpojili od Internetu, v této lokalitě provozujeme DNS resolver a nastavili jsme jej tak, aby se dotazoval právě tohoto odstaveného anycast nodu. Dále jsme zařídili, aby tento anycast nod dostával update zóny z nového HM a následně jsme zkoušeli, zda se správně překládají DNS dotazy směřované přes místní resolver na odstavený DNS nod s novou zónou. Tím jsme například ověřili, že se správně validuje DNSSEC. Dále proběhla celá řada kontrol (například zda je .cz zóna správně podepsána, zda se daří distribuovat novou zónu v krátkých časech do všech anycast lokalit, …). Podrobně zpracovaný plán přechodu na nové HM obsahoval také část, která naštěstí nebyla využita, tj. plán pro návrat do původního stavu, pokud by nás nějaký z kroků nedostal tam, kam jsme čekali. Ve svém výtahu změn pomíjím mnohé „detaily“, jako třeba fakt, že jsme pro DNSSEC ponechali funkční systém dvojího podepisování (podepisování jednotlivých zón pomocí ZSK a podepisování DNSKEY záznamů pomocí KSK, které pro nás i nadále zajišťuje CSIRT tým – viz například tento článek). Tedy ponechali, i u nich došlo k přechodu na Knot DNS, aby byla změna ještě komplexnější. K testování, zda celá akce proběhla korektně, posloužily administrátorům notoricky známé nástroje jako https://dnsviz.net, https://dnssec-analyzer.verisignlabs.com (pro ověření a vizualizaci správně nastaveného DNSSECu, jaké jsou zrovna využívané KSK a ZSK klíče) nebo obyčejný dig.
Systém generování a podepisování registru .CZ máme tak od minulého týdne postaven na kompletně novém jádře, které je výkonnější a bezpečnější. A protože je jeho základem námi vyvíjený Knot DNS, můžeme počítat s tím, že další jeho rozvoj bude odpovídat našim potřebám.
Tak co, máte chuť, stejně jako já, vyseknout servisákům veřejnou pochvalu a „strčit jim něco navíc“? Budete příště o práci servisáka, hlavně toho našeho CZ.NICařského, přemýšlet trošku jinak? Pokud aspoň někdo z vás odpovídá „ano“ článek splnil svůj účel. Ať vám vaše DNS i auta dobře jedou i nadále!