Vytvoření řetězu důvěry
Nyní máme svou zónu podepsanou, ale nikdo o tom, že jsme zónu podepsali, neví a validující resolvery nemají informaci o tom, jaký je správný klíč k této zóně. Krok, který je zapotřebí udělat jako další, spočívá v tom, že dáte všem stranám, kterým chcete, aby vaši zónu validovaly, informaci o vašem novém klíči. Existují tři způsoby, jak to udělat:
Klíč jim přímo nějakým způsobem předáte. E-mailem, poštou, telefonicky. Tato metoda není příliš flexibilní, a v podstatě ji má smysl používat jen ve speciálních případech, jako jsou například doménové registry.
Druhý způsob je možný pouze v případě, že nadřazená zóna podporuje DNSSEC. Při podpisu zóny vznikne na disku soubor s názvem dsset-<zona> a keyset-<zona>. V souboru dsset-<zona> jsou vypsány DS záznamy, které je zapotřebí umístit do nadřazené zóny. V souboru keyset-<zona> jsou pak vypsány KSK klíče, které byly použity pro podpis zóny. Obecně se dá říct, že jsou tyto dva soubory ekvivalentní. DS záznamy se vypočítávají z klíče a názvu zóny, a výsledný hash je umístěn do nadřazené zóny. Pro domény v zóně .cz je možné DS záznamy umístit do zóny .cz tak, že se obrátíte na svého registrátora, který musí podporovat DNSSEC, a zašlete mu KSK klíče. Systém si pak již ke každé doméně, která je takovýmto klíčem podepsána, spočítá DS záznamy a vygeneruje je do zóny .cz.
Třetí způsob je možný pro domény, jejichž nadřazená zóna DNSSEC nepodporuje. Jako dočasné řešení vznikl mechanismus, který se jmenuje Domain Lookaside Validation – DLV. Obecně funguje tak, že místo DS záznamu se do doménového stromu umisťuje DLV záznam, který se skládá z názvu domény a názvu DLV registru, a validující resolver pak tento záznam může použít v případě neexistujícího DS záznamu v nadřazené zóně. Mechanismu DLV bych se věnoval v jednom z následujících článků.
Údržba podepsané zóny
Údržba podepsané zóny se skládá ze údržby RRSIG podpisů a údržby klíčů.
Údržba podpisů
Pokud si vzpomenete na záznam RRSIG, tak si možná uvědomíte, že tento záznam v sobě obsahuje dobu platnosti, od a do kdy je podpis platný. To implikuje dvě věci: Jednak je zapotřebí, aby čas na rekurzivních i autoritativních serverech byl v pořádku a vygenerované podpisy měly platné datum, a na druhé straně pak nedocházelo k chybám ve validaci, a jednak, že je zapotřebí podpisy pravidelně obnovovat a to minimálně před dobou konce platnosti mínus největší TTL RRSIG záznamu v zóně.
Údržba klíčů
DNSSEC klíče jsou veřejně dostupné ve formě DNSKEY záznamů a zároveň jsou dostupná data vygenerovaná při podpisu RR záznamů. Je to v podstatě analogická situace k webovým certifikátům. Pokud jste někdy s certifikáty přišli do styku, tak víte, že certifikát má nějakou platnost a je zapotřebí ho pravidelně měnit. Není za tím jen ekonomický zájem certifikačních autorit, ale čím déle je certifikát veřejně dostupný, tím větší je riziko, že jej někdo rozlouskne. Podobně je to i u DNSSEC klíčů s jediným rozdílem. Žádná položka ve veřejné části certifikátu neříká, jakou má klíč platnost, technicky vás tedy nic nenutí klíče měnit. Nicméně je dobré klíč čas od času vyměnit.
Proč ‚čas od času‘? Protože konkrétní čas není pevně daný, ale měl by reflektovat důležitost podepsaných dat. Je jasné, že klíče k soukromé doméně, kde provozujete blog pro své kamarády, nebude zapotřebí měnit tak často, jako klíče od zpravodajského portálu, televize, burzy, banky nebo jiné externí autority, kde je důvěryhodnost informací, které proudí ze služeb provozovaných na konkrétním doménovém jméně a které koncoví uživatelé zasílají, velmi důležitá. A to ze dvou důvodů. Jednak klíče k nedůležité doméně asi nikdo prolamovat nebude, bylo by to plýtvání prostředky, a jednak v případě prolomení klíče nebude napáchaná škoda, tak velká. Důležité si je také uvědomit, že prolomení nebo zcizení klíče ještě automaticky neznamená, že útočník může podvrhovat DNS odpovědi. Technicky se tímto pouze dostane do situace před nasazením technologie DNSSEC – ještě stále musí nějakým způsobem podvrhnout DNS zprávu s podepsanými RR záznamy.
Výměna klíčů v zóně (rollover)
RRSIG záznamy a DNSKEY záznamy mohou být (a budou) ve vyrovnávací paměti uloženy nezávisle na sobě. Proto je zapotřebí dbát na to, abychom se nedostali do situace, kdy ve vyrovnávací paměti resolveru bude RRSIG záznam, ke kterému už neexistuje DNSKEY v zóně na autoritativním serveru. Stejně tak naopak je zapotřebí zajistit, aby ve vyrovnávací paměti resolveru „nezbyl“ RRset DNSKEY záznamů, a v zóně na autoritativním serveru už budou RRSIG záznamy nového klíče. Pokud by došlo k jedné z těchto situací, došlo by k přerušení řetězu důvěry a podpisy by nebyly validní – resolver by místo odpovědí, které byly validovány, začal vracet DNS odpovědi s chybovým kódem SERVFAIL.
Teorii máme za sebou pojďme k samotnému mechanismu výměny klíčů. Způsoby výměny DNSSEC klíčů jsou dvě – před-publikace a dvojitý podpis. Jak jsme si řekli výše, oba dva způsoby musí zajistit, aby nedošlo k přerušení řetězu důvěry. Obě dvě metody se dají použít pro výměnu KSK i ZSK klíčů, ale z praktických důvodů se metoda před-publikace používá pro výměnu ZSK klíčů a metoda dvojitého podpisu pro výměnu KSK klíčů.
Před-publikovaní klíčů
Samotný název metody naznačuje způsob, jakým bude výměna klíčů probíhat. Nový DNSSEC klíč je přidaný do zóny nějakou dobu předtím, než bude použit pro podepisování zóny, a teprve po uběhnutí této lhůty dojde k tomu, že jej bude možné začít použít pro podepisování. Tato metoda do zóny nepřidává žádné nové podpisy. Dojde pouze k přidání jednoho RR záznamu DNSKEY.
Krok po kroku bude výměna vypadat následovně:
1. vygenerujeme nový ZSK klíč:
dnssec-keygen -a RSASHA1 -b 512 -r /dev/urandom dnssec.cz Kdnssec.cz.+005+02271
2. nově vygenerovaný klíč přidáme do zónového souboru:
cat >> dnssec.cz << EOF ;; KSK klice $INCLUDE Kdnssec.cz.+005+42307.key ;; ZSK klice $INCLUDE Kdnssec.cz.+005+02271.key $INCLUDE Kdnssec.cz.+005+40965.key EOF
3. podepíšeme zónu s explicitním uvedením klíčů, které chceme použít (42307 a 40965 jsou klíče z minulého článku):
dnssec-signzone -r /dev/urandom -k Kdnssec.cz.+005+42307.key \ -N increment dnssec.cz Kdnssec.cz.+005+40965.key
4. po podepsání zónového souboru je zapotřebí počkat, až se zóna rozdistribuuje na všechny nameservery a následně počkat dobu, která je rovná nebo vyšší TTL záznamů DNSKEY (a jejich podpisů).
5. nyní máme jistotu, že o novém ZSK klíči budou vědět všechny validující resolvery, a můžeme zónu podepsat novým klíčem:
dnssec-signzone -r /dev/urandom -k Kdnssec.cz.+005+42307.key \ -N increment dnssec.cz Kdnssec.cz.+005+02271.key
6. v této fázi musíme opět počkat. Doba čekání musí být zdola omezená maximálním TTL v celé zóně a shora omezená minimální dobou platnosti ze všech RRSIG záznamů v zóně.
7. po uplynutí této doby můžete ze zónového souboru odstranit odkaz na starý ZSK:
cat >> dnssec.cz << EOF ;; KSK klice $INCLUDE Kdnssec.cz.+005+42307.key ;; ZSK klice $INCLUDE Kdnssec.cz.+005+02271.key EOF
8. a zónu znovu přepodepsat:
dnssec-signzone -r /dev/urandom -k Kdnssec.cz.+005+42307.key \ -N increment dnssec.cz Kdnssec.cz.+005+02271.key
Drobná varianta této metody spočívá v tom, že máme v zóně umístěné vždy dva klíče – aktivní a pasivní, tedy až po bod 4. jsme vše již provedli na začátku. Vygenerování nového ZSK klíče a jeho přidání do zóny, pak proběhne na konci celého cyklu místo na jeho začátku.
Dvojitý podpis
Tato metoda se od před-publikování liší v tom, že budeme pro podpis zónového souboru používat oba dva klíče – starý i nově vygenerovaný. Název „dvojitý“ podpis je poněkud zavádějící, protože klíčů může být i více, ale pro jednoduchost zůstaneme u tohoto názvu a budeme si předvádět použití této metody pouze na dvou klíčích. Tato metoda je časově rychlejší, ale pokud bychom ji používali pro výměnu ZSK, neúměrně by nafoukla zónový soubor. Proto je vhodná pro výměnu KSK klíčů, kdy dochází jen k dvojitému podpisu RR záznamu nesoucího informaci o používaných klíčích – DNSKEY. Pro výměnu KSK lze použít také metodu před-publikování, ale z důvodů jednoduchosti a rychlosti je vhodnější metoda dvojitého podpisu.
Jak tedy postupovat při výměně KSK:
1. vygenerujeme nový KSK:
dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -f KSK dnssec.cz Kdnssec.cz.+005+60787
2. nově vygenerovaný klíč přidáme do zónového souboru:
cat >> dnssec.cz << EOF ;; KSK klice $INCLUDE Kdnssec.cz.+005+42307.key $INCLUDE Kdnssec.cz.+005+60787.key ;; ZSK klice $INCLUDE Kdnssec.cz.+005+40965.key EOF
3. podepíšeme zónu s explicitním uvedením obou KSK klíčů – nového i starého, které chceme použít (42307 a 40965 jsou klíče z minulého článku):
dnssec-signzone -r /dev/urandom -k Kdnssec.cz.+005+42307.key \ -Kdnssec.cz.+005+60787.key -N increment dnssec.cz \ Kdnssec.cz.+005+40965.key
4. nyní nastává důležitá fáze. Nyní je zapotřebí počkat, až se zóna rozdistribuuje na všechny podřízené nameservery plus doba TTL RR záznamu DNSKEY. Souběžně s tím je zapotřebí poslat nový KSK klíč do nadřazené zóny, a to stejným postupem, jakým jste do nadřazené zóny umístili původní KSK klíč – obrátit se na správce nadřazené zóny. V případě domény ze zóny .cz, je zapotřebí se obrátit na svého registrátora. Po té, co je klíč v nadřazené zóně ve formě DS záznamu umístěn, je zapotřebí počkat, až vyprší TTL tohoto DS záznamu.
5. ve chvíli, kdy už všechny validující resolvery mají ve vyrovnávací paměti nové DS i DNSKEY záznamy, můžeme odstranit původní KSK klíč:
cat >> dnssec.cz << EOF ;; KSK klice $INCLUDE Kdnssec.cz.+005+60787.key ;; ZSK klice $INCLUDE Kdnssec.cz.+005+40965.key EOF
6. a zónový soubor podepsat pouze novým KSK klíčem:
dnssec-signzone -r /dev/urandom \ -Kdnssec.cz.+005+60787.key -N increment dnssec.cz \ Kdnssec.cz.+005+40965.key
V tomto díle seriálu jsme si ukázali jednu důležitou věc – je zapotřebí se o svoje domény starat. A to ostatně platí i v případě domén, které nemají s technologií DNSSEC nic společného. V příštím díle seriálu si ukážeme, jak hledat chyby pomocí dostupných nástrojů.
Autor je technickým ředitelem sdružení CZ.NIC.
