Pochybností o pravosti klíče jsme se ale pořád ještě nezbavili. Potřebujeme ještě dosáhnout toho, aby klient mohl důvěřovat klíči KSK, jímž je podepsán záznam KEY. K tomu slouží budování řetězce důvěry. V podstatě spočívá v tom, že nadřazená doména dosvědčí platnost KSK své podřízené domény.
V našem případě by si klient platnost výše uvedeného KSK pro doménu kdesi.cz ověřil v doméně cz. K tomu slouží záznamy DS (Delegation Signer). Doména cz by tedy obsahovala DS záznam dokazující právoplatnost prvního z výše uvedených klíčů domény kdesi.cz, který slouží jako KSK. Tento záznam by byl pochopitelně podepsán ZSK domény cz, v níž se nachází.
Řetězec důvěry funguje následujícím způsobem:
- záznamu lze důvěřovat, pokud je podepsán ZSK dané domény
- ZSK lze důvěřovat, je-li podepsán KSK této domény
- KSK lze důvěřovat, pokud na něj ukazuje DS záznam nadřízené domény
- v nadřazené doméně se proces opakuje – DS záznamu lze důvěřovat, je-li podepsán zdejším ZSK, ten musí být podepsán zdejším KSK…
Celý proces se zarazí, když klient narazí na klíč, který již zná a důvěřuje mu. Teoreticky tedy klientovi stačí znalost jediného klíče (KSK pro kořenovou doménu), aby dokázal ověřit platnost libovolného záznamu v celém DNS stromě.
V našem konkrétním případě by ověřování A záznamů pro pc.kdesi.cz postupovalo následně:
- klient získá A záznamy a SIG záznam pro pc.kdesi.cz
- k jeho ověření potřebuje ZSK domény kdesi.cz (KEY záznam a jeho SIG)
- k jeho ověření potřebuje KSK domény kdesi.cz
- k jeho ověření potřebuje DS záznam pro kdesi.cz, který je uložen v doméně cz
- k jeho ověření potřebuje ZSK domény cz
- k jeho ověření potřebuje KSK domény cz
- k jeho ověření potřebuje DS záznam pro cz z kořenové domény
- pro jeho ověření potřebuje ZSK kořenové domény
- pro jeho ověření potřebuje KSK kořenové domény, který by se měl dozvědět jinou cestou (např. z konfiguračního souboru)
Vypadá to strašlivě komplikovaně, ale uvědomte si, že jakmile jednou klient ověří platnost klíče, může si jej zapamatovat a používat až do vypršení jeho životnosti. To znamená, že po prvním absolvování této anabáze bude mít k dispozici důvěryhodné ZSK pro domény kdesi.cz, cz a pro kořenovou doménu, takže příští ověřování již bude podstatně kratší. Například ověření čehokoli v doméně cz se zastaví na kroku 4, protože ZSK pro doménu cz již je k dispozici a DS záznam tudíž lze ověřit.
DS záznam obsahuje:
- značku klíče (opět pro rychlejší vyhledání)
- algoritmus, pro který se klíč používá
- typ digestu
- digest ověřující platnost klíče, ke kterému se vztahuje
Doména cz by tedy mohla obsahovat něco takového:
kdesi.cz. 999 IN DS 2539 1 1 239...1a9
Chybějící informace – záznam NXT
Prostřednictvím záznamů NXT si tazatel může ověřit, že jím požadovaná informace v DNS skutečně není uložena. Jméno je zkratkou z Next a naznačuje, že prostřednictvím těchto záznamů jsou jednotlivá jména v doméně propojena do řetězce.
Záznam NXT se přidává ke každému jménu v doméně a obsahuje:
- doménové jméno, které následuje za aktuálním (u posledního pak odkazuje na první)
- seznam typů záznamů definovaných pro aktuální jméno
Aby vše fungovalo, musí být jména v doméně uspořádána podle abecedy. Například naše pc.kdesi.cz by kromě záznamů A a SIG obsahovalo ještě
999 IN NXT pc2.kdesi.cz. A NXT SIG
999 SIG NXT 5 3 999 20030610114923 20030510114923 (
2539 kdesi.cz Oj3uW...7ik )
Dozvíte se z něj, že pro pc.kdesi.cz existují záznamy typu A, NXT a SIG a že za ním v doméně následuje pc2.kdesi.cz. NXT záznam je pochopitelně podepsán, aby se dala ověřit jeho správnost.
Při negativní odpovědi DNSSEC rozlišuje dvě významné situace:
- Jméno existuje, ale neexistuje požadovaný typ záznamu
-
V tom případě server pošle prázdnou odpověď, doprovázenou NXT záznamem pro dané jméno. Z něj je patrné, že pro toto jméno chybí požadovaný záznam. Například kdyby klient sháněl MX záznam pro pc.kdesi.cz, dostal by v odpovědi výše uvedený NXT záznam sdělující, že pro pc.kdesi.cz existují jen záznamy A, NXT a SIG.
- Jméno vůbec neexistuje
-
Pak je odpovědí zpráva o neexistující doméně, k níž server přiloží NXT záznam nejbližšího existujícího jména, které abecedně předchází požadovanému. Kdyby se například v doméně kdesi.cz bezprostředně před pc.kdesi.cz nacházel osel.kdesi.cz a klient požadoval informace o quido.kdesi.cz, dostal by v negativní odpovědi NXT záznam pro osel.kdesi.cz. V něm se dočte, že jeho následníkem je pc.kdesi.cz a že tedy quido opravdu není k dispozici.
Standardizace a implementace
Nejprve tu dobrou zprávu: DNSSEC je standardizováno, a to dokonce velmi dlouho. Definuje je RFC 2535 z roku 1999. Bohužel tato definice byla v praxi shledána jako nevyhovující, a proto se připravuje její změna. Současný stav DNSSEC je popsán v sadě návrhů:
draft-ietf-dnsext-dnssec-intro
draft-ietf-dnsext-dnssec-records
draft-ietf-dnsext-dnsse-protocol
Z nich vychází tento článek. Jedná se pochopitelně o návrhy s omezenou platností, nicméně o návrhy velmi zralé, jejichž RFCizace se očekává v nejbližší době. Do RFC s největší pravděpodobností nepronikne Opt-In (mechanismus, který umožňuje vynechávat nepodstatné věci z řetězce NXT, viz draft-ietf-dnsext-dnssec-opt-in), na kterém se zúčastnění nedokázali shodnout. Výsledná RFC se od stávajících návrhů budou lišit spíše formulačně než principiálně.
DNSSEC je implementován. Jeho oficiální podobu podle RFC 2535 najdete v BINDu verze 9.0 a 9.2, zatímco připravovaný BIND 9.3 drží krok s návrhy a implementuje novou podobu DNSSEC (najdete jej naftp://ftp.isc.org/isc/bind9/snapshots/). Máme si tedy s čím hrát.
Podepisování domén (které zahrnuje i abecední uspořádání a vytváření řetězců NXT záznamů) vypadá jako dost nudná práce. Naštěstí existují nástroje, které tuto dřinu udělají za vás. Velmi pěkný návod pro jejich praktické použití najdete na stránkách projektu DISI sponzorovaného právě organizací RIPE. Jedním z jeho výstupů je i dokument DNSSEC HOWTO, v němž se dočtete co a jak je třeba udělat, chcete-li mít své DNS bezpečné. Řeší se v něm i otázky zabezpečeného přenosu zón mezi primárním a sekundárním serverem, které přesahují rámec vlastního DNSSEC.
ČLÁNKY DO MAILU