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íř