Hlavní navigace

Údržba DNSSEC klíčů

Ondřej Surý 26. 1. 2009

V minulém dílu našeho seriálu o bezpečnostní technologii DNSSEC jsme si ukázali, jak zapnout DNSSEC na autoritativním serveru, vygenerovat klíče pro podepsání zónového souboru a jak zónu podepsat. Dnes si ukážeme, jak vytvořit řetěz důvěry, jak jednotlivé klíče vyměnit, a proč je to zapotřebí dělat.

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.

Našli jste v článku chybu?

25. 7. 2011 14:15

Ondřej (neregistrovaný)

Při výměně KSK se snažím podepsat zónu dočasně starým i novým KSK, ale program dnssec-signzone vrací chybu:

dnssec-signzone: fatal: failed to find an SOA at the zone apex: NXRRSET

Uměl by někdo poradit o co jde? Při podpisu pouze jedním KSK proběhne vše v pořádku. Když uvedu oba, je to špatně.

Př.:

dnssec-signzone -s +-1800 -e 20120531120000 -o dnssec-test.cz -f dnssec-test.cz.signed -r /dev/urandom -a -k K.+007+07920.key K.+007+58839.key -N keep dnssec-test.cz K.+007+18725.key

29. 1. 2009 13:51

maker (neregistrovaný)
Pokud jsem to správně pochopil tak jediná výhoda dvou klíčů je, že při změně ZSK nemusím otravovat svého providera. Tudíž můžu použít kratší ZSK, který je potřeba častěji měnit ale na druhou stranu nezabere mi tolik času podepsat i velkou doménu.
Co když ale jsem v situaci, že mám doménu s několika málo záznamy a navíc je velice nepravděpodobné, že by se měnily? Byl by nějaký problém použít v pouze jeden klíč (aspoň 1024b) na podpis všech záznamů? Teoreticky to podle mě možné je. Jediné co mě ma…
DigiZone.cz: NG natáčí v Praze seriál o Einsteinovi

NG natáčí v Praze seriál o Einsteinovi

Podnikatel.cz: Udávání kvůli EET začalo

Udávání kvůli EET začalo

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Root.cz: Telegram spustil anonymní blog Telegraph

Telegram spustil anonymní blog Telegraph

DigiZone.cz: ČT má dalšího zástupce v EBU

ČT má dalšího zástupce v EBU

Lupa.cz: Teletext je „internetem hipsterů“

Teletext je „internetem hipsterů“

120na80.cz: Jak oddálit Alzheimera?

Jak oddálit Alzheimera?

DigiZone.cz: Sat novinky: Fransat UHD Demo

Sat novinky: Fransat UHD Demo

Lupa.cz: Kdo pochopí vtip, může jít do ČT vyvíjet weby

Kdo pochopí vtip, může jít do ČT vyvíjet weby

Lupa.cz: Proč firmy málo chrání data? Chovají se logicky

Proč firmy málo chrání data? Chovají se logicky

Vitalia.cz: Znáte „černý detox“? Ani to nezkoušejte

Znáte „černý detox“? Ani to nezkoušejte

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

Měšec.cz: mBank cenzuruje, zrušila mFórum

mBank cenzuruje, zrušila mFórum

Měšec.cz: Air Bank zruší TOP3 garanci a zdražuje kurzy

Air Bank zruší TOP3 garanci a zdražuje kurzy

Vitalia.cz: Mondelez stahuje rizikovou čokoládu Milka

Mondelez stahuje rizikovou čokoládu Milka

Měšec.cz: Golfové pojištění: kde si jej můžete sjednat?

Golfové pojištění: kde si jej můžete sjednat?

Podnikatel.cz: 1. den EET? Problémy s pokladnami

1. den EET? Problémy s pokladnami

Podnikatel.cz: Podnikatelům dorazí varování od BSA

Podnikatelům dorazí varování od BSA

Podnikatel.cz: Zavře krám u #EET Malá pokladna a Teeta?

Zavře krám u #EET Malá pokladna a Teeta?

Vitalia.cz: I církev dnes vyrábí potraviny

I církev dnes vyrábí potraviny