Podivné chování EURidu s DNSSEC

Člověk zhýčkaný komfortem české národní domény si často ani nedovede představit, jaké problémy na něj čekají u jiných top level domén. Tento zápisek bude o tom, jak se jedna banální změna nastavení .eu domény protáhla z několika minut na několik dní.

Po dlouhou dobu byla doména s anglickou verzi stránky Neběží.cz hostována přímo u registrátora, společnosti Gransy, s. r. o. Bylo to především z toho důvodu, že tehdy to byla jediná možnost, jak u .eu domény u registrátora získat DNSSEC. Dnes už ale jeho rozhraní nabízí vložení vlastního veřejného klíče a tak jsem se rozhodl doménu předelegovat na svůj server. Doménu jsem tedy zprovoznil a následně u registrátora v jednom kroku změnil delegaci na své servery a přidal veřejný klíč. Zároveň jsem vypnul DNS službu u registrátora s tím, že jsem počítal, že dojde nanejvýš ke krátkému výpadku domény. O to větší překvapení bylo, když ještě po 20 hodinách byla doména stále delegována na servery registrátora.

První podezření padlo na registrátora, že změnu ve skutečnosti neprovedl. Zkusil jsem tedy odstranit z domény DNSSEC klíč. V tu chvíli se delegace změnila. Přidal jsem klíč zpátky, ale v DNS se jeho otisk neobjevil. Zeptal jsem se na podpoře registrátora, která mě utvrdila, že všechno dělám správně. To jsem si ostatně mohl potvrdit i pomocí Whois dotazu, kde byly správně uvedeny jak DNS servery, tak i DNSSEC klíč. Nezbývalo, než se obrátit přímo na technickou podporu EURidu. Její odpověď byla pro mne poněkud překvapivá:

Which rules must be met to have a „non DNSSEC“ domain added to the EU zone?

At least one name server must have been provided to the registry system. No checks are done by EURid's system to verify if the domain zone file is correctly set on these name servers.

Which rules must be met to have a „DNSSEC“ domain added to the EU zone?

A DNSSEC enabled domain is checked by rules, if one of the rules does not match the check fails and the previous valid state is used.

• All name servers provided to the registration system by the registrar for that domain are found on the Web (e.g each query gives gives „NOERROR“).
• Each query (dig ns) done on each of these name servers for that domain gives all the same response.
• All Keys (ZSK, KSK) provided to the registration system for a given domain are found on each of the name servers provided.

What happens if a domain is added for the first time to the registry with keys and some information is invalid (name server incorrectly set, problem with keys,etc)?

This domain is NOT added to EU zone.

Recommendation: As a first step, it is recommended to the registrar that he removes the DNS keys to have at least the zone added. After a valid state, the registrar put back the keys and insure that DNSSEC rules are met.

Odpověď EURidu odhaluje poměrně zásadní rozdíl v přístupu k validaci uživatelských dat. Není-li do registru vložen KEYSET, EURid žádnou validaci neprovádí a zadané delegace okamžitě umístí do zónového souboru. Oproti tomu po vložení KEYSETu jé zóna velmi podrobně testována a do DNS vložena pouze za předpokladu, že testy splní. V případě, že testy z jakéhokoli důvodu nesplní, zůstává v DNS stará verze. A to je přesně důvod mnou pozorovaných potíží. Doména měla jakýsi banální problém v nedostupnosti jednoho ze tří DNS serverů, kvůli kterému technickými testy EURidu neprošla.

Čekali byste, že v takovém případě EURid využije mé kontaktní údaje z registru a informuje mě o problému s doménou a o způsobu nápravy? Nebo že aspoň ve Whois databázi zveřejní známou větičku The domain isn't generated in the zone? Já bych to tedy čekal. Nic takového se ale nestalo, jen se celý proces zasekl ve stavu, kdy Whois databáze tvrdila zcela něco jiného, než jaký byl obsah DNS.

Čekali byste, že výše citovaný text s poměrně zásadními informacemi je součástí nějakých FAQ přímo na stránkách EURidu? Tak to byste asi čekali také marně. I přes pokusy hledání konkrétních slovních obratů jsem jej nebyl schopen najít. Místo toho jsem našel jen několik marketingově orientovaných textů o DNSSEC a jedno PDF, které sice popisuje obecně DNSSEC, ale neobsahuje ani slovo o konkrétních pravidlech EURidu.

EURid chtěl zřejmě při implementaci DNSSEC zabránit nechtěným chybám v konfiguraci, které by mohly mít za cíl nefunkčnost domény. Způsob, jakým to udělal, mi ale připadá krajně nevhodný. Pro srovnání, podobné technické testy provádí RIPE NCC při zřizování reverzních delegací pro přidělené IP rozsahy. Zde je však změna Whois databáze podmíněna splněním technických testů, v opačném případě úprava databáze selže. Ale především je celý postup velmi přesně zdokumentován.