Ačkoliv už pět správců domén nejvyšší úrovně (TLD) zavedlo technologii DNSSEC, stále nám chybí jakoby krok číslo 1, tedy podpis té úplně prvotní, neboli kořenové zóny. Pokud tedy chci v současné době plně validovat záznamy ve všech podepsaných zónách, musím si stáhnout klíče všech pěti organizací a starat se o jejich aktualizaci. To je pochopitelně poměrně nepraktické, každý správce domény má jiný způsob, jak klíče zveřejňuje. V praxi to tedy funguje tak, že každý ISP, který validaci provádí, si buď sleduje aktuálnost obvykle té pro něj nejzajímavější domény a ostatní ignoruje, nebo použije úložiště klíčů mechanismu DNSSEC Lookaside Validation – DLV. DLV je poměrně elegantní řešení, nicméně ne každý má důvěru v konkrétního provozovatele DLV. Navíc DLV není zcela obecně přijaté a standardizované řešení.

Vzhledem k tomu, že podepsání kořenové zóny z mnoha důvodů ještě nedošlo, rozhodla se organizace IANA, která se jinak o změny v kořenové zóně stará, jednat a vytvořila prozatímní řešení, do doby než se spory vyjasní a dojde k podpisu. Proto vytvořila tak zvaný ITAR – Interim Trust Anchor Repository. Toto řešení je technologické odlišné od DLV a je z hlediska typu použitého DNS resolveru zcela neutrální. Dalším plusem je, že jej spravuje důvěryhodná organizace, která se o změny v kořenové zóně stará a má tedy autentizační mechanismy pro komunikaci se správci TLD. Výhodou je poměrně přesná specifikace toho, za jakých podmínek je služba provozována, a toho, co se stane po podpisu zóny. Ještě je třeba dodat, že narozdíl od DLV slouží ITAR pouze pro TLD. Způsob, jak nastavit DNS resolver pro spolupráci s DLV nebo ITAR popisuje kolega Surý ve svém článku na serveru Root.

Ač se vznik ITAR nemusí jevit jako důležitý krok, ve skutečnosti jím je. Může totiž přesvědčit registry, kteří čekají s implementací DNSSEC na podpis kořene, k urychlení plánu. Teď totiž kořen vlastně máme.

Ondřej Filip

Konsorcium ISC nedávno vydalo novou verzi pravděpodobně nejpoužívanějšího DNS serveru Bind. Bind od verze 9.6 kromě pravidelných oprav chyb a vylepšení přináší také zlepšení podpory pro technologii DNSSEC.

Bind 9.6 konečně podporuje standard NSEC3, který přináší více soukromí do podepsaných zón. Tento standard byl vydán jako RFC5155 před necelým rokem a s novou verzí Bindu je konečně podporován všemi významnými open source DNS servery podporujícími DNSSEC (Bind, NSD, Unbound).

Další novinka by měla výrazně zjednodušit správu DNSSEC podepsaných domén. Bind 9.6 přináší automatické přepodepisování zónových souborů dynamických zón. Osobně jsem ještě neměl čas se podívat na to, jak to celé funguje, protože jsem se zabýval následujícím bodem, ale myslím si, že je to správný krok ke zjednodušení nasazení DNSSECu.

Onen další bod, který mě osobně zaměstnával posledních pár měsíců, je podpora PKCS#11 přímo v Bindu. Nová verze přináší nástroj dnssec-keyfromlabel, který umožňuje vytvořit DNSSEC klíč z dat uložených na kryptografickém zařízení (např. takové ty různé USB tokeny). Mělo by to fungovat s openssl a opencryptoki – tj. musíte mít funkční podporu PKCS#11 v openssl. Dnssec-keyfromlabel pak umí vytvořit dvojici souborů .key/.private ve speciálním formátu, který říká, na kterém zařízení najít soukromou část klíče. Zatím jsem neměl čas vyzkoušet tuto funkci na Linuxu, ale společně s Francisem DuPontem z ISC se nám před týdnem povedlo zprovoznit kartu SCA6000 pod Solarisem 10. Sice to zatím vyžaduje verzi z CVS, ale mám osobně slíbeno od ISC, že tato oprava, kterou je potřeba začlenit do hlavní vývojové větve, bude v další verzi řady 9.6 (tedy pravděpodobně v 9.6.1).

Za další z nových nástrojů pravděpodobně můžu já – dnssec-dsfromkey umí z klíče vytvořit DS záznamy bez toho, aby bylo potřeba podepsat zónový soubor. Nápad na tento nástroj vznikl na základě mé diskuze s inženýry z ISC, že v některých specifických případech trvá podepsání zóny i několik (desítek) minut – a je to dost neefektivní muset podepsat zónu, aby byl soubor s DS záznamy vytvořen.

Poslední věc, která stojí za zmínku je zahrnutí sady nástrojů ZKT do distribučního souboru Bindu (hledejte v adresáři contrib). ZKT obsahuje sadu nástrojů, která umí usnadnit práci s DNSSEC klíči a automatizaci podepisování zónových souborů. Používám jej na automatizaci podepisování našich zón. A také připravuji jeho zabalíčkování do distribuce Debian (a tím pádem časem propadne i do distribucí odvozených), nicméně v současnosti je build systém trochu nevhodný na balíčkování, takže to bude chtít ještě trochu společné práce s autorem na ZKT. A času se nikdy není dost.

Ondřej Surý

Minulý týden jsem měl docela pěknou, plodnou debatu s Ondřejem Filipem, Danem Kaminskym a Paulem Wouterem o tom, jak usnadnit použití DNSSECu pro běžné uživatele. Dan je v tom poněkud radikální a vymýšlí systém, kdy by stačilo „nasadit novou verzi“ a všechny spravované domény by byly podepsané, tj. koncový uživatel by nemusel dělat nic. Osobně si myslím, že je to zatím příliš odvážné, a že je zatím potřeba postupovat po menších kouscích. Celé to totiž začíná být složitější ve chvíli, kdy každý doménový registr má vlastní verzi registračního systému a hierarchii dat uvnitř registru.

Nicméně s Paulem jsme pak rozebírali modely toho, jak to zjednodušit a zároveň respektovat různé registrační systémy. Je jasné, že první krok, který je potřeba udělat, bude vždycky muset být ruční – jedná se o vytvoření důvěry mezi doménovým registrem a prvotním DNSSEC klíčem. V případě naší národní domény bude zachovaný proces, kdy držitel doménového jména kontaktuje existujícím komunikačním kanálem svého registrátora a ten pošle zabezpečeným kanálem přes EPP protokol přidání (nebo změnu) DNSSEC klíče do centrálního registru.

Další krok už lze automatizovat. Pokud použijeme specifikaci RFC5011, která říká, jakým způsobem lze měnit DNSSEC kořeny důvěry, tak existuje možnost, že by DNS server podepsané domény mohl poslat speciální UPDATE zprávu (podepsanou stávajícím DNSSEC klíčem) o tom, že dochází ke změně DNSSEC klíče. Specializovaný DNS server by tuto zprávu zaznamenal, ověřil změnu a vygeneroval DS záznam pro nový klíč. Celý tento proces by mohl proběhnout bez lidského zásahu.

Na konci jsme se s Paulem dohodli, že tento koncept rozpracujeme ve formě Internetového Draftu a pokusíme se jej standardizovat na půdě IETF.

Docela by mě zajímalo, co si o tomto nápadu myslíte? Své připomínky můžete psát do diskuze níže.

Ondřej Surý

Nedávnou jsem se zhruba touto větou pokoušel být vtipný v jedné diskusi k mému rozhovoru o DNSSEC. Čas se ani tak moc neposunul a vypadá to, že jsem nebyl příliš daleko od pravdy. Díky objevení Kaminského útoku se ledy skutečně hnuly. Poslední dobou se technologii DNSSEC začala věnovat i americká administrativa. Nejdříve Kancelář pro plánování a rozpočet vydala nařízení, že musí dojít k podpisu domény .gov a všech jejích poddomén a nedávno i NTIA rozeslala žádost o komentování mechanismu podpisu kořenové zóny. U toho jsme pochopitelně nemohli chybět a i my jsme vyjádřili náš názor. Z pohledu českých uživatelů je asi nejdůležitější, aby k podpisu došlo rychle, aby nedošlo k nějaké závažné změně v mechanismu správy kořenové zóny a aby se o podepisování starala důvěryhodná a spolehlivá mezinárodní organizace. To je taky důvod, proč jsme podpořili návrh ICANN. Tak uvidíme, jak NTIA komentáře vyhodnotí.

Ondřej Filip

Mít anycast DNS server je dobrá věc. A co je to vlastně ten anycast? Je to velmi jednoduchý způsob, jak mít více serverů se stejnou IP adresou. IP paket je směrovacím protokolem BGP poslát do nejbližší (myšleno síťově nejbližší, nikoli geograficky) lokality, kde server odpoví např. na DNS dotaz a pošle původnímu tazateli odpověď. Protože se směrovací informace můžou poměrně dynamicky měnit, je dobré používat anycast pouze pro protokoly, které fungují v krátkém časovém okně. Což DNS, které hlavně používá protokol UDP a komunikace probíhá v jednom paketu s dotazem do DNS a druhém s odpovědí, splňuje.

Anycast DNS servery mají několik výhod. Jednak se dá elegantně a jednoduše rozkládat zátěž, protože DNS klienti jsou rozloženi mezi více serverů, a jednak poskytují ochranu pro DoS útokům. V případě útoku na DNS server je většinou z provozu vyřazený jen jeden ze serverů a ostatní servery stále vyřizují požadavky klientů, kteří jsou v jiných sítích. Technicky pro provoz anycast DNS serverů potřebujete číslo autonomního systému a dedikovaný rozsah IP čísel (nejlepé IPv4 i IPv6).

CZ.NIC momentálně provozuje jeden anycast DNS server – d.ns.nic.cz. Jednotlivé servery jsou umístěny v Praze, Frankfurtu a San Francisku a obsluhují požadavky přes IPv4 i IPv6. Možná se zeptáte, proč CZ.NIC nemá více anycast DNS serverů, když je to tak dobrá věc. Bohužel v současné době to není možné, protože pravidla organizace RIPE, která má na starosti přidělování bloků IP adres, toto neumožňují. Přidělování IP adres je v současné době definováno v dokumentech ripe-424 pro IPv4 a ripe-421 pro IPv6. Oba dva dokumenty obsahují speciální klauzuli, která umožňuje operátorům ccTLD DNS serverů, získat přesně jeden adresní rozsah /24 v IPv4 a jeden adresní rozsah /48 v IPv6.

Protože se dlouhodobě snažíme zajistit, co nejlepší služby našim uživatelům, zahájili jsme proceduru na změnu těchto dokumentů. Prosazujeme změnu obou dokumentů tak, aby nelimitoval počet rozsahů, které může operátor TLD DNS serverů získat. Zároveň tak dojde k sladění těchto pravidel mezi ostatními regiony – ARIN, APNIC, LACNIC i AfriNIC umožňují získat více rozsahů pro přesně definované subjekty. A např. společnost Afilias, která provozuje např. doménu .org a další menší, získala od ARINu 6 /24 rozsahů v IPv4 a 6 /48 rozsahů v IPv6 pro každou doménu, kterou provozuje. Pokud se obáváte, že by toto mohlo urychlit vyčerpání IPv4 adres, tak je to obava zbytečná. Počet přidělených IPv4 adres je mnohem menší, než jaký rozsah dostává standardně nový LIR (ISP, poskytovatel obsahu, atp.), a počet subjektů, který může o tento speciální rozsah požádat je pevně definovaný.

Proces změny pravidel je zdlouhavý, ale doufám, že do příští konference RIPE, která proběhne v první polovině příštího roku, dojde internetová komunita ke shodě, jak přesně pravidla změnit, a bude možné požádat o další rozsahy určené pro anycast DNS servery. Již v tuto chvíli máme podporu dalších velkých ccTLD – .fr a .de, a pravděpodobně se další přidají, takže nepředpokládám, že by při prosazování změny, mělo dojít k velkým problémům. Navíc CZ.NIC už jednu změnu v pravidlech RIPE úspěšně prosadil, takže zatím máme 100% úspěšnost při prosazovaní změn ;), a doufejme, že to tak zůstane i nadále.

Ondřej Surý