Přestože je téma digitální identity (a souvisejících distribuovaných „single sign-on“ přihlašovacích mechanismů) staré možná jako internet sám, troufám si tvrdit, že jeho největší okamžiky teprve přijdou. Po úspěších centrální správy identit, které v současnosti ukazují veřejné služby jako Facebook, nebo Google+, přirozeně pokukují propagátoři různých forem e-governmentu. V něm mohou některé mechanismy fungovat na podobných principech, přičemž přidaná hodnota je určitě validita údajů identit, které veřejné služby mohou jen těžko dosáhnout. Nesmělé náznaky v podobě elektronických občanek u nás, připravované rozhraní k datovým schránkám, ale i aktivity vlád v celém světě (německý projekt de-ident, americká strategie pro důvěryhodné identity v kyberprostoru NSTIC, nebo projekt evropské identity STORK) naznačují, že tato oblast v blízké době zažije velké změny. Bylo by jistě užitečné, kdyby jednotlivé implementace místo proprietárních řešení vycházely z konsensuálních standardů, které i v této oblasti existují a není jich málo.
Jednou z platforem, na které kooperují autoři těchto standardů, je například Internet Identity Workshop. V rámci pravidelných konferencí této platformy, které se konají dvakrát ročně si zástupci nejrůznějších standardizačních organizací vyměňují informace o novinkách ve svých produktech. Na následujících řádcích bych rád shrnul nejvýznamnější standardy na tomto poli a upozornil na nejnovější aktivitu, která se objevila v průběhu minulého roku.
Asi nejstarším zástupcem protokolů této kategorie je SAML. Jeho první verze pochází z roku 2002 a zatím poslední verze z roku 2005. Za tento, na jazyku XML založený, protokol nese odpovědnost standardizační organizace OASIS, známá svými dalšími „XML aktivitami“ jako Docbook nebo DITA. SAML se poměrně pevně usadil v akademickém světě. Například u nás je to protokol, na kterém funguje Česká akademická federace identit známá pod zkratkou EduID, provozovaná sdružením CESNET. Takže pokud máte účet v systému své vysoké školy, s velkou pravděpodobností můžete používat SAML pro přihlašování u systémů poskytovatelů služeb, které jej podporují. Těch bohužel není mnoho a zejména jsou to opět akademické instituce. Jedním z těchto poskytovatelů služeb by, alespoň podle dokumentace, měly být i GoogleApps.
V roce 2005 se na poli standardů objevil protokol OpenID. Jeho jádro prošlo vývojem a ustálilo se na verzi 2.0 z konce roku 2007. V průběhu dalších zhruba tří let si získal velkou popularitu a podporovali ho i velcí hráči jako Google nebo Microsoft. Za účelem rozvoje tohoto standardu vznikla organizace OpenID Foundation, která sdružuje jak zástupce poskytovatelů identit, tak poskytovatelů služeb. U nás byl dlouho jediným větším průkopníkem této technologie Seznam.cz. Předloni jsme si OpenID jako komunikační protokol zvolili i my s naší službou ověřených identit mojeID. Důležitou vlastností tohoto protokolu je možnost standardizované výměny atributů identity.
Při práci na implementaci OpenID do služby Twitter vznikla další významná technologie pojmenovaná OAuth. Na rozdíl od OpenID má tato technologie jako cíl umožnit poskytovatelům služeb zabezpečený přístup k nějaké obecně libovolné sadě funkcí, kterou jiná služba nabízí. První draft byl publikován v roce 2007 a jeho vývoj se v průběhu roku 2010 přesunul na půdu asi nejvýznamnější internetové standardizační organizace IETF. V této době probíhá práce na dokončení verze 2.0 standardu, jehož finální vydání ve formě RFC je „snad“ otázkou příštích několika týdnů. Po Twitteru přijal tuto technologii za vlastní také Facebook a nakonec ji do repertoáru svých autentizačních mechanismů přidal i Google.
Co se týká srovnáni OAuth a OpenID tak OAuth sice nabízí asi jen polovinu vlastností které má OpenID, ale na druhou stranu to dělá mnohem lépe. Vzhledem k tomu vzniklo v průběhu posledních dvou let několik pokusů, jak zkombinovat to nejlepší z nich do ideálního výsledku. Těchto několik pokusů se nakonec spojilo dohromady a v polovině roku 2011 byl prezentován výsledek v podobě specifikace nazvané OpenID Connect. Toto řešení ve své „spodní“ části využívá OAuth 2.0 a obaluje ho vlastnostmi specifickými pro OpenID. Zajímavou změnou je i následování trendu a nahrazení jazyka XML na příslučných místech jazykem JSON. Od prosince je návrh standardu v připomínkovém řízení a pokud vše půjde hladce, mohli bychom se už letos dočkat jeho finální verze. Za touto specifikací stojí všichni velcí hráči jako Facebook, Google i Microsoft což jí dává poměrně dobré vyhlídky na její budoucí rozšíření.
Jak je vidět, ve světě digitálních identit je hodně živo a my věříme, že minimálně u nás nechá služba mojeID v této diskuzi viditelný otisk. Rodina použitelných specifikací je široká a rozhodně neumírá. Nové generace těží ze zkušeností svých předchůdců a většinou přidávají nové pohledy a nové myšlenky. Z pohledu mojeID samozřejmě nepřestáváme sledovat aktuální vývoj. Charakter této služby nijak nebrání tomu použít několik přístupových technologií paralelně a tím nabídnout poskytovatelům služeb větší výběr možností implementace. Pokud zjistíme vzrůstající poptávku po některém ze zmiňovaných protokolů, pokusíme se této poptávce vyhovět.
Jaromír Talíř
Aktuálně o FREDovi
Minulý týden k nám zavítala čtyřčlenná delegace z estonského registru. Jak jsme již psali dříve, Estonci pro správu domény používají náš registrační systém FRED. Důvodem jejich návštěvy byl hlavně zájem o naše zkušenosti se zaváděním technologie DNSSEC a potom samozřejmě také prohloubení spolupráce na vývoji registračního systému. Postupně nás seznámili se změnami, které oni sami implementovali do systému a zjišťovali, co jsme od jimi použité verze implementovali na naší straně. Jejich nejvýraznějším rozšířením je autorizace významných operací podepsanou žádostí v digitální formě připojenou k požadavku registrátora. Estonci také např. plně implementovali IDN a do budoucnosti připravují ještě další omezení do EPP protokolu pro své registrátory. Bohužel to zároveň ukazuje, jak specifické jsou požadavky jednotlivých registrů a jak bude udržení jedné společné báze problematické.
Prakticky ve stejnou dobu jsme se dozvěděli, že v Albánii místní správce domény zveřejnil výběrové řízení na implementaci nového registračního systému pro doménu .al. V definici podmínek výběrového řízení zjevně vycházel z našeho registračního systému, neboť vzápětí se ozvalo několik firem s žádostí o spolupráci nebo s prosbou o školení práce s FREDem. Dost možná, že se tak Albánie brzy stane sedmou zemí používající náš registrační systém.
Jaromír Talíř
K IPv6 pomocí technologie Teredo
Nový protokol IPv6 je žhavým tématem snad všech diskuzí o současném internetu. Ale řekněme si na rovinu – kdo z vás ho má? Poskytovatelů připojení k internetu, kteří by ho nabízeli, je jako šafránu. Pro mnoho internetových uživatelů je tak tento protokol spíše předmětem teoretických spekulací než praktických zkušeností. Naštěstí existuje řada možností jak toto pomalé zavádění obejít. Převážně jsou založena na mechanismu tunelování. Koncový počítač připojený do internetu pomocí dosluhující IPv4 je možné jednoduše nakonfigurovat tak, aby se tvářil, že je připojen i do nového IPv6 internetu. Odcházející IPv6 zprávy jsou ale okamžitě zabaleny do IPv4 zpráv a přeposlány na místo, kde dojde k jejich vybalení a ze kterého již je možné tuto zprávu protokolem IPv6 doručit bez komplikací.
Dvě nejznámější technologie, které se k tomuto účelu používají, jsou 6to4 a Teredo. Jejich výhoda je ve velice dobré podpoře v operačních systémech a jednoduché konfiguraci ze strany uživatele. Technologie 6to4 je rozšířenější a rychlejší, ale vyžaduje mít veřejnou IPv4 adresu, což vůbec není samozřejmost. Oproti tomu Teredo je univerzálnější, bude fungovat i tam kam 6to4 nedosáhne, i když trochu na úkor rychlosti. Obě tyto technologie využívají veřejné sítě překladových serverů, které se starají o balení a vybalování do/z IPv4 zpráv. Pro českého uživatele byly obě technologie dlouhou dobu nepřijatelné už z toho důvodu, že nejbližší překladové servery ležely v Německu nebo ve Francii. V průběhu loňského roku sdružení CZ.NIC spustilo v rámci propagace IPv6 první český překladový server (relay) pro technologii 6to4. Nyní se naše sdružení rozhodlo navázat na tento počin a spustilo servery zlepšující podporu i technologie Teredo. Více informací a návodů najdete na této adrese.
Jaromír Talíř
DNSSEC v poslední nezabezpečené poddoméně .ARPA
Před necelým rokem na konferenci RIPE 60 v Praze prezentoval Dave Knight z ICANN časový plán pro zabezpečení všech poddomén v doméně ARPA. Doména nejvyšší úrovně ARPA (Address and Routing Parameter Area) slouží k uchovávání informací pro fungování infrastruktury internetu. Nejznámější poddomény jsou IN-ADDR.ARPA, IP6.ARPA (pro mapování internetových adres na doménová jména – reverzní DNS) a E164.ARPA (pro technologii ENUM). Seznam všech poddomén v ARPA, spolu s odkazem na dokumenty ospravedlňující jejich existenci je k dispozici na stránkách organizace IANA.
K zabezpečení většiny poddomén došlo podle zmíněného harmonogramu již na podzim minulého roku. Nejdéle vzdorovala asi nejpoužívanější doména IN-ADDR.ARPA, pravděpodobně také proto, že na přelomu roku došlo k převodu správy této domény z amerického regionálního registru ARIN přímo na centrální organizaci ICANN. Tento převod byl dokončen letos v únoru a posledním krokem bylo publikování DS záznamů IN-ADDR.ARPA v nadřazené doméně ARPA, které proběhlo v polovině března. Dokončení tohoto procesu spolu s již komentovaným zavedením DNSSEC v doméně .com jsou jistě největší události na poli DNSSEC za poslední měsíc a jen ukazují vzrůstající zájem o tuto technologii i v okolním světě.
Jaromír Talíř
Nasazení registračního systému FRED v roce 2010
Nový rok 2011 se už sice rozjel naplno, ale přesto tu je ještě prostor na jednu rekapitulační souhrnnou zprávičku, která se týká různých nasazení našeho registračního sytému FRED v průběhu minulého roku. O nasazení na Faerských ostrovech jsem již informoval v dřívějším článku. Kromě domény .fo si ale FRED loni do popisu práce přibral ještě řízení chodu dalších dvou národních domén. Jsou to domény .cr v středoamerické Kostarice a také .ee pobaltského Estonska. Zejména nasazení v Estonsku (pochází odtud Skype a první elektronické volby) se dá jednoznačně považovat za úspěch.
Estonci víceméně převzali FRED tak jak je, ale přidali k němu několik pro ně podstatných rozšíření. Tou největší změnou je rozšíření parametrů některých operací EPP protokolu. V rámci operací týkajících se registrace domény, změny držitele, zrušení domény a opravy údajů kontaktu musí registrátor přidat elektronický dokument obsahující žádost podepsanou držitelem nebo administračním kontaktem. Estonskou národní doménu spravuje společnost Eesti Internet. V současné době mají přes 50 000 zaregistrovaných domén a 38 akreditovaných registrátorů. Jejich plány se nyní orientují na rozjetí IDN a tedy zavedení speciálních znaků õ, ä, ö, ü, š a ž v doménových jménech.
S kostarickým registrem jsme byli v kontaktu již poměrně dlouhou dobu a tak jsme jejich přechod do produkce v druhé polovině loňského roku málem propásli. Jejich řešení ale ukazuje, jakou flexibilitu modulární systém FRED nabízí. Správci domény .cr použili náš registr jako interní systém, který obalili vlastním webovým rozhraním. Toto webové rozhraní umožňuje rozšířené funkce jako schvalování předregistrovaných domén a teprve po schválení se doména EPP rozhraním dostane do FREDa. Toto je možné, jelikož jsou zároveň registr i registrátor. V Kostarice tímto způsobem spravují kromě domény .cr také sedm poddomén třetí úrovně (co.cr, or.cr, fi.cr, ac.cr, go.cr, ed.cr, sa.cr). Celkem mají v registru kolem 13 000 domén.
V produkčním provozu je tedy nyní FRED již v pěti zemích světa. V Angole, Tanzánii, Faerských ostrovech, Kostarice a Estonsku. V Albánii asi stále ještě nezlomili nutnou administrativní liberalizaci celého registračního procesu. Podle různých zdrojů se snad o nasazení zajímají ve Rwandě a Kongu. Ale jak říká klasik: „nemusí pršet, jen když kape“.
Jaromír Talíř
Připravte se včas na střídání stráží
V návaznosti na podepsáním kořenové zóny nás všechny čeká jedna velká změna – výměna DNSSEC klíčů a přechod na NSEC3. Psal jsem o ni na tomto blogu už dříve a tak, protože se blíží její čas (započne již příští týden v úterý), rád bych na ni upozornil ještě jednou.
Tento přechod se nastartuje už v úterý 3. srpna. Z pohledu CZ.NIC to znamená, že v tento den zavedeme pro naší zónu nový klíč (rozhodli jsme se nakonec, že klíč nebude typu RSASHA256, ale ještě silnějšího typu RSASHA512) a ze všech zdrojů (ITAR, DLV, internetové stránky) stáhneme klíč, který jsme používali dosud. Následně na to, ještě v tento den, také pošleme IANA žádost o výměnu klíčů v kořenové zóně. Co všechno souvisí s touto změnou, jsme popsal ve výše zmíněném článku.
Jak se říká: Co můžeš udělat dnes, neodkládej na zítřek. Tato slova v tomto případě určitě platí a to hlavně pro provozovatele rekurzivních DNS serverů, kteří provádějí validaci pomocí DNSSEC. Připravte se včas, do 3. srpna zbývá už jen jeden týden! Doporučujeme vám především:
- přejít na validaci DNSSEC přes klíč kořenové zóny (další informace najdete na stránkách věnovaných DNSSEC)
- upgradovat na nejnovější verzi DNS serveru.
Jaromír Talíř
FRED se zabydlel na Faerských ostrovech
Náš registrační systém FRED, který jsme pro naší doménu spustili v roce 2007, se dočkal dalšího nasazení. Nejnověji jej využívá národní registr na Faerských ostrovech – po České republice jde o druhou evropskou zemi, která se rozhodla na FRED přejít.
V případě této země s pouhými 50 tisíci obyvateli a zhruba třemi tisíci doménami s koncovkou .fo bylo FRED potřeba modifikovat, aby vyhovoval tamější registrační politice. Vzhledem k tomu, že roli registrátorů na sebe přebírá sám správce domény, byl systém doplněn o externí databázi, která slouží k provozu registračního webového rozhraní, umožňuje platby kreditními kartami apod.
Podstatnými změnami prošla také struktura ukládaných kontaktů. Faerský správce národní domény má o něco přísnější podmínky registrace, pokud jde o možnost identifikace držitele domény, proto mezi registrační údaje patří i datum narození a národnost (v případě zahraničních zájemců o doménu je to číslo pasu, sken pasu a národnost). Potřebné kontakty pro registraci tak jsou: Holder (držitel domény), Billing contact (kontakt pro platbu, z původní struktury FREDa nahrazuje Admin) a Technical contact (technický kontakt).
Faerská verze FREDu se musela přizpůsobit také dvěma používaným typům žádostí o registraci. Typ A představují žádosti, které jsou vyřízeny okamžitě, přičemž žadatel musí doložit, že má na danou doménu právo (například kopií z registru značek). Typ B jsou žádosti, které mají 30denní lhůtu na vyřízení, během níž se o doménu mohou přihlásit i další subjekty, které by k jejímu držení mohli mít právo. Během této lhůty jsou žádosti spravovány v externí databázi, po jejím uplynutí se doménové jméno uloží v databázi FREDu.
Pevně věříme, že tato evropská vlaštovka nezůstane dlouho sama, a že se k ní časem přidají další doménové registry starého kontinentu.
Jaromír Talíř
Podpis kořenové zóny, ITAR a NSEC3
Zatímco se celý DNS svět připravuje na podepsání kořenové zóny, které proběhne už za necelých 14 dní, my se připravujeme hned na tři podstatné změny, které budou po tomto podepsání následovat a souvisejí s přechodem zóny CZ na variantu technologie DNSSEC označovanou jako NSEC3. Tyto změny jsou samozřejmě zajímavé pouze pro provozovatele rekurzivních DNS serverů, kteří provádějí validaci pomocí DNSSEC. Běžný uživatel tyto změny pravděpodobně ani nezaznamená.
První velkou změnou je zrušení podpory repositáře klíčů ITAR. Již nyní jsou naše záznamy z ITARu vloženy v kořenové zóně a v okamžiku, kdy bude kořenová zóna podepsaná, bude možné validovat zónu CZ právě pomocí klíčů kořenové zóny. Doporučujeme tedy co nejrychleji přejít na tento způsob validace změnou konfigurace rekurzivních DNS serverů. Klíče kořenové zóny budou k dispozici v den jejího podpisu, tedy 15. července.
S výše uvedeným souvisí také historicky první rollover (výměna klíčů) v zóně CZ. Nový klíč, který v rámci této operace zveřejníme, bude silnější a umožní nám přechod na NSEC3. Tento klíč již ale nebudeme vkládat do repositáře ITAR, abychom podpořili přechod na validaci přes kořenovou zónu. Podle harmonogramu, který jsme zveřejnili, provedeme tuto operaci 3. srpna. V tento den také zašleme do IANA žádost o vložení otisku nového klíče do kořenové zóny a žádost o vyřazení otisku klíčů z repositáře ITAR. Přestože bude tato žádost zpracovaná zhruba do 14 dnů ode dne podání, od 3. srpna již nebudeme ITAR podporovat a je tedy nutné mít v konfiguracích správně klíče kořenové zóny! Toto se netýká pouze DNS serverů využívající ITAR, ale i těch, které mají klíč pro zónu CZ nakonfigurován ručně. Nový klíč již nebudeme zveřejňovat na našich stránkách a pokud někdo tuto konfiguraci používá, musí změnit klíč pro zónu CZ na klíč pro kořenovou zónu. Stejným způsobem také odebereme klíče z posledního místa, kde je možné je nalézt, a to z ISC DLV.
Nový klíč bude vytvořen silnějším typem algoritmu RSASHA512 (opraveno 2. srpna 2010) než je stávající RSASHA1. Podstatné je, že tento nový algoritmus je podporovaný až v novějších verzích softwaru používaného pro rekurzivní DNS servery. Nejjednodušší způsob, jak tuto podporu otestovat, je vyzkoušet si validaci ENUM zóny 0.2.4.e164.arpa, která již tento algoritmus používá. DNS server Bind podporuje tento algoritmus od verze 9.6.2. DNS server Unbound od verze 1.4.0.
Posledním krokem celé akce je vlastní přechodu na NSEC3. V zóně ENUM proběhla tato změna podle plánu. V zóně CZ jsme bohužel termínově vázáni na propagaci nových klíčů v nadřazené zóně, což není v naší moci ovlivnit, ale zatím vždy byly požadované změny provedeny do 14 dnů. I z pohledu provozovatelů rekurzivních DNS serverů bude ale tato poslední změna neviditelná a tedy nebude nutné do konfigurace DNS serverů zasahovat.
Na závěr drobné shrnutí očekávaných událostí „horkého“ léta:
- 15. 7. 2010 proběhne podpis kořenové zóny a publikace podpisových klíčů
- 3. 8. 2010 provádíme v zóně CZ přidání nového RSASHA512 (opraveno 2. srpna 2010) klíče a stahujeme existující klíče ze všech zdrojů, kde jsme je publikovali (ITAR, DLV, webové stránky); zároveň posíláme do IANA žádost o zařazení otisku klíče v kořenové zóně
- 24. 8. 2010 odebereme staré RSASHA1 klíče a provádíme podepsání zóny CZ pomocí technologie NSEC3.
Jaromír Talíř
FRED v zemi orlů
Albánci svoji zemi ve svém jazyce nazývají Shqipëria, což znamená „země orlů“. Svůj původ odvozují od velkého národa Ilyrů z období římské říše a rozhodně to v historii neměli lehké. Po dlouhém období pod nadvládou Osmanské říše následovaném dvěma válkami museli při stanovování hranic států sledovat, jak si okolní země rozebraly velká území obývaná převážně Albánci, která oni sami považovali za historickou součást Albánie. Díky tomu tak oficiálně v Albánii žije asi 3.7 milionu Albánců a jenom v okolních státech Řecku, Makedonii a Srbsku (s Kosovem) dalších skoro 6 milionů.
Zhruba v polovině loňského roku se s námi Albánci spojili a požádali nás o pomoc s nasazením našeho registru FRED do jejich systému správy domény. Dohodli jsme se s nimi, že u nich v září 2009 uspořádáme jednotýdenní školení vlastností a provozu systému spolu s jeho nasazením na servery přímo v sídle jejich doménového registru v Tiraně s tím, že oni uhradí související cestovní náklady.
Doména .al má také zajímavou historii. Nejprve patřila americkému státu Alabama a do Albánie se přesunula částečně přes Itálii, kde dlouhou dobu sídlila správa primárního nameserveru. V Albánii byla správa domény .al dána do agendy státnímu Úřadu pro poštovní a elektronickou komunikaci (AKEP), což je obdoba našeho ČTÚ (má také na starost celou oblast telekomunikací). AKEP působí jako registr a zároveň jediný registrátor. Dlouho byla také doména .al dostupná jen pro firmy a teprve v první polovině roku 2008 došlo k liberalizaci a k zajištění plné dostupnosti i pro fyzické osoby (ale jen rezidenty). Aktuální cena registrace je 75 $ na dva roky, tedy v přepočtu kolem 700 Kč/rok. Nejedná se vlastně o jednu doménu, podobně jako na mnoha jiných registrech spravuje AKEP také com.al, net.al, org.al, gov.al, edu.al a mil.al. Celkově je ale doména .al poměrně malá – obsahuje dohromady asi 2 000 domén. Z administrativního pohledu je proces registrace poměrně náročný. Je třeba vyplnit papírový formulář, který je nutné odeslat e-mailem nebo odnést osobně na úřad. Tam proběhne kontrola s tím, že každou registraci musí nakonec podepsat sám ředitel úřadu. Po schválení a zaplacení je doména zavedena do excelového souboru a ručně přidána do zónového souboru.
Plán kolegů z Albánie je přímočarý – nejprve zavést registrační systém a po nějakém čase přejít na systém několika registrátorů. Pro první krok si, k naší radosti, vybrali právě FREDa. Instalace byla jednoduchá, servery již měli připravené a jelikož používají podobně jako my Ubuntu, bylo možné využít našich archivů s balíčky. Podařilo se rozběhnout všechna rozhraní a generování zónového souboru. Co zbylo je migrace starých dat do FREDa. Toto je obvykle nejnáročnější pasáž celého projektu a nese si s sebou spoustu drobných zádrhelů jako např. vyčištění primárních dat nebo jejich struktura pro případné automatické zpracování. Podle posledních zpráv na tom stále pracují. Pevně věřím, že se jim to povede a Albánie se tak stane po Angole a Tanzánii třetí zemí mimo ČR, kde FRED zapustí svoje kořeny.
Jaromír Talíř
Švédské „vypnutí“ internetu
Před třemi týdny se našim kolegům ze švédského doménového registru přihodilo to, co bych bez nadsázky nazval noční můrou doménových správců – vystavení poškozeného zónového souboru. Tento soubor je klíčovým prvkem pro fungování systému doménových jmen DNS. Jsou v něm uložené všechny domény druhé úrovně pod doménou „.se“ spolu s odkazy kam směrovat dotazy na tyto domény. Zmiňovaná chyba tak způsobila, že odhadem minimálně na hodinu přestaly být dosažitelné všechny adresy s koncovkou „.se“. Pojďme si postupně projít co se vlastně stalo a zejména jakým způsobem je provoz našeho vlastního registru zabezpečen proti tomu aby se něco podobného přihodilo i nám.
Správci švédské domény .se si v našem oboru drží dlouhodobě poměrně vysoké renomé. Jako první zavedli DNSSEC a na odborných konferencích často vystupují s novinkami, které implementovali do svých systémů. V pondělí 12. října měli naplánovanou rutinní odstávku systému spojenou s nasazením nové verze. Přestože, podle zveřejněných informací, i jejich vývojový cyklus obsahuje sadu testů, které musí nová verze splňovat, ze zatím nezjištěných příčin prošel přes tuto fázi kód, který obsahoval chybu. Ta spočívala v chybějící tečce na konci doménových jmen ve vytvořeném zónovém souboru – místo „.se.“ zde bylo uvedeno pouze „.se“. Nameserver načítající tento zónový soubor tím pádem pokládal všechna doménová jména jako relativní a připojil ke každému ještě jednou „.se.“. Takto poškozený zónový soubor se začal propagovat ve 21:39. Ve 21:50 monitorovací systémy začali hlásit, že v publikované zóně je chyba. Administrátoři na to zareagovali tak, že vzali poslední správně vytvořený zónový soubor a po zvýšení sériového čísla ho ve 22:35 publikovali. Vzhledem k tomu, že celá zóna .se je podepsaná pomocí DNSSEC a že sériové číslo je součástí SOA záznamu, došlo jeho změnou k invalidaci podpisu tohoto záznamu a pro DNSSEC validující resolvery tedy byla tato zóna stále nedostupná. Tento krok ale zabezpečil dostupnost domény pro většinu uživatelů. Finální, nově podepsaná zóna byla publikována v 0:35. Ponechme nyní stranou Švédy a podívejme se jakým způsobem se podobnému nedopatření snažíme vyvarovat my. V zásadě se jedná o dva doplňující se procesy a to testování nových verzí před nasazením a monitoring produkčního prostředí.
Již v průběhu vývoje programátoři používají širokou sadu automatizovaných testů, s jejichž pomocí kontrolují zda nové změny nezanesly chybu do dříve fungujících částí systému. Po dokončení všech kontrol provedou vývojáři označení nové verze v systému pro správu verzí SVN a spolu s postupem upgradu předají tuto verzi administrátorům. Ti s pomocí vlastního nástroje zajistí zabalíčkování nových verzí změněných komponent pro všechny platformy na kterých systém provozujeme. Kompletní konfigurace systému včetně verzí balíčků je uchovávána v centrálním repositáři a pomocí nástroje Puppet jsou veškeré změny distribuovány na patřičná místa. Abychom zajistili bezproblémový upgrade, vytvořili jsme pomocí technologie virtualizace KVM kompletní kopii produkčního prostředí jedné lokality, čítající v tuto chvíli pět propojených serverů. Administrátoři zanesou postup upgradu do Puppetu a s jeho pomocí tento postup aplikují na testovací lokalitě. Poté spolu s vývojáři otestují výsledek buď manuálně nebo opět sadou automatizovaných testů. Teprve pokud nenastane žádný problém, je možné novou verzi pomocí otestovaného postupu nasadit na skutečné produkční prostředí.
Běžící systém je monitorován obrovskou sadou periodických testů, které zkoumají všechny možné aspekty jeho chování od stavu síťových zařízení, přes různé zkoušení registrací na registrátorském rozhraní až po testy zda se odesílají správně faktury. Všechny tyto kontroly jsou implementovány jako moduly do monitorovacího nástroje Nagios. Výstupy těchto kontrol jsou klasifikovány podle důležitosti a reportovány pomocí e-mailů nebo SMS zpráv administrátorům. Celý systém je podporován vizuální a hlasovou signalizací umístěnou v prostorách našeho klienského centra. Operátoři pracující v tomto prostoru 24 hodin denně a 7 dní v týdnu neprodleně administrátorům volají pokud signalizace hlásí nějaký problém. Vraťme se ale k publikování zónového souboru. K tomu dochází automaticky jednou za půl hodiny a i tento proces obsahuje několik kontrol. Vedle kontroly integrity souboru je hlavní kontrolou test na počet změn v tomto souboru. Pokud počet změn přesáhl určitou hranici je proces zastaven a administrátoři musejí provést ruční kontrolu těchto změn. Pokud kontrola zjistí, že se opravdu jedná jen o velký počet změn v delegacích je zóna publikována a automatický mechanismu obnoven.
Bylo by krásné na tomto místě napsat – nám se nic takového stát nemůže, ale nebyla by to pravda. Všechny systémy jsou nakonec nějakým způsobem závislé na lidech. Jak se zdá, i ve Švédském případě mají podobné procesy, ale pravděpodobně někdo neotestoval to co měl a ještě navíc někdo neposoudil nějakou signalizaci monitoringu jako kritickou a vypnul jí. Tomu je možné předejít pouze výběrem zodpovědných pracovníků a jejich častým školením a tréninkem. Věřím, že v tomto ohledu jsou naši zaměstnanci muži (a ženy) na správném místě.
Jaromír Talíř