Protokol DNS, primárně používaný na převod doménových jmen (jako je například aisa.fi.muni.cz) na IP adresy, se v Internetu používá už od osmdesátých let minulého století. Jako takový je aspoň ve své základní podobě poměrně stabilní jak z hlediska protokolu, tak co se týče klientských i serverových implementací. Zkušenost provozovatelů DNS serverů „jednou jsem to nastavil a od té doby jsem na to nemusel sahat“ je poměrně obvyklá. Pokud DNS nastavíte, tak funguje, a pokud měníte konfiguraci, tak případná nefunkčnost se projeví ve velké většině případů ihned. Ne tak ovšem při použití DNSSECu.
Úvod do DNSSECu
DNSSEC reaguje na bezpečnostní požadavky současného Internetu, kdy se lze setkat s podvrženými packety, odposloucháváním provozu, otrávením cache DNS serverů a podobně. Původní protokol DNS běží z větší části nad UDP a jeho data nejsou nijak zabezpečena. DNSSEC zavádí správu klíčů pro jednotlivé domény a podepisování a ověřování vrácených záznamů. Vzniklo několik nových typů záznamů, které mají za cíl toto zabezpečení realizovat:
- DNSKEY
- Informace o podepisovacím klíči pro danou doménu. Je podporováno více algoritmů (dnes nejčastěji RSA+SHA256 nebo ECDSA-P256+SHA256). Klíčů pro danou doménu může být víc a můžou se navzájem podepisovat a řetězit. Původní záměr je mít v každé doméně minimálně dva klíče: Key Signing Key (KSK) dlouhé platnosti, uložený nejlépe na hardwarovém modulu, a krátkodobý Zone Signing Key (ZSK) pro podepisování samotných DNS záznamů.
- DS
- Tímto záznamem nadřazená zóna říká, že i její podřízená zóna používá DNSSEC, a s jakým konkrétně klíčem. DS záznam uvádí jen otisk klíče, a typicky ukazuje na KSK subdomény.
- RRSIG
- V tomto záznamu jsou uloženy samotné podpisy. Podpis je zvlášť pro každou dvojici (doménové jméno, typ záznamu), takže například pro (
www.fi.muni.cz, AAAA) bude jeden RRSIG záznam (pro všechny AAAA dohromady), ale pro (www.fi.muni.cz, MX) je jiný RRSIG. Podpisy mají časově omezenou platnost, aby útočník odchycením podepsané DNS odpovědi nemohl někdy v budoucnu podvrhovat stará data.
- NSEC
- Kromě podpisu faktu, že v doméně existuje nějaké jméno (a pro ně nějaký typ záznamu), je také třeba podpisem zabezpečit negativní odpovědi. Když se zeptám na
bflmpsvz.fi.muni.cz, musím dostat podepsanou odpověď, že toto neexistuje. Ovšem DNS server předem neví, na jaká jména se ho někdo zeptá. A přístupová práva k podpisovému klíči mít nemusí, takže generovat podpisy negativních odpovědí „za běhu“ také není možné. NSEC funguje tak, že nameserver abecedně uspořádá všechna jména a záznamy v doméně, a pak se záznamem typu NSEC podepisuje fakt, že mezi dvěma sousedními jmény (z pohledu tohoto uspořádání) žádné další jméno není. Na dotaz na výše uvedené bflmpsvz.fi.muni.cz bychom tak mohli dostat odpověď v podobě NSEC záznamu sdělujícího, že mezi banan.fi.muni.cz a bonsai.fi.muni.cz nic dalšího není.
- NSEC3
- Problémem NSEC záznamů je, že přeskakováním po NSEC záznamech lze vlastně vypsat postupně celou doménu, i když nameservery nemají povolený zone transfer. Proto byl zavedený záznam NSEC3, který nejprve jména v doméně převede jednocestnou klíčovanou hashovací funkcí na nějaký otisk, a pak se podepisuje fakt, že mezi určitými dvěma otisky nic dalšího není. Tohle je teoreticky lepší, na druhé straně je třeba si uvědomit, že entropie DNS jmen není příliš velká, a tak i dobrou hashovací funkci lze s těmito daty s relativně dobrou úspěšností invertovat. Vizte též nástroj nsec3walker.
Problémy DNSSECu
Protokol DNSSEC se mi jeví jako něco, co si navrhli provozovatelé velkých domén pro sebe: už jen oddělení ZSK a KSK, kdy po dlouhá léta se sice teoreticky uvažovalo o dvou typech klíčů, ale reálně všechny příklady a best practices předpokládaly umístění obou typů klíčů přímo na DNS serveru v tom stejném adresáři, dokonce přístupných procesům DNS serveru.
Dalším problematickým místem jsou časové závislosti: když například chcete podepsat doménu, nelze jen tak zavést záznam DNSKEY, vygenerovat podpisy, a kontaktovat nadřazenou doménu s tím, ať pro vás zavede odpovídající DS záznam. To by vaše doména přestala být vidět z těch klientů, kteří ještě mají v cache informaci o tom, že vaše doména žádný DNSKEY záznam nemá, ale od nadřazené domény dostanou aktuálnější informaci o existenci záznamu DS. Při podepisování domény je tak třeba mezi jednotlivými kroky nechat uplynout určitý čas, který se odvíjí od platnosti (TTL) záznamů, které vaše doména uvádí.
Největší potenciál generovat výpadky má ovšem ona časově omezená platnost podpisů. Dojde totiž k tomu, že pokud se někde pokazí obnovování podpisů, není vidět problém hned, ale až poté, co existujícím podpisům vyprší platnost, což může být podle nastavení týden, měsíc, ale také třeba rok. Pamatuji si situaci, kdy jsem v sobotu měl odjíždět na dovolenou, a v pátek večer nadřazené zóně vypršely DNSSEC podpisy, a naše doména přestala být validujícím resolverům (včetně nás samých) viditelná.
Komunikace subdomény s nadřazenou doménou. Donedávna neexistoval standardní způsob, jak nadřazené doméně říct, ať pro naši doménu publikuje záznam typu DS. Obvykle se to dělalo přes webová rozhraní doménových registrátorů. A pak docházelo k situaci, kdy top-level doména jako taková sice podporovala DNSSEC, ale ne přes každého registrátora bylo možné nechat publikovat DS záznam. Někde se to ještě lišilo v tom, jestli DNS servery provozoval registrátor, anebo uživatel sám.
A aby toho nebylo málo, tak případné problémy s DNSSECem si odskáčou zejména ti aktivní, kteří na svých resolverech DNSSEC podpisy validují. V jedné takové situaci se na nás začali obracet správci jednoho z celouniverzitních systémů spravovaného jinou částí Univerzity s tím, že asi máme problém v síti. Že na všech fakultách to funguje, jen z FI se do jejich systému nelze dostat. Až po čase jsme zjistili, že problém je v DNSSECu u nich, a jenom FI na rozdíl od zbytku Univerzity používá validující resolvery. Problémy tohoto typu se nevyhýbají ani velkým firmám, před cca třemi lety jsme zaznamenali takovéto vypršení platnosti podpisu i pro domény Microsoftu pro jejich Office 365. Základní doporučení pro DNSSEC tedy je: nejprve nakonfigurujte monitoring s hodně včasnou výstrahou, a až pak pouštějte DNSSEC do ostrého provozu.
Aktuální vývoj
Zdá se, že vývoj ohledně DNSSECu se přece jen posunuje. DNS servery začínají mít čím dál lepší podporu pro automatické podepisování v režii samotného DNS serveru (včetně zvyšování sériových čísel v záznamech SOA a ukládání podepsaných dat do vedlejšího souboru, takže původní zónový soubor zůstává nadále přehledný pro systémového administrátora). Přestali jsme si taky hrát na dva typy klíčů s různým stupněm zabezpečení: dnešní DNSSEC podporuje i typ klíče Combined signing key (CSK), který lze použít místo dvojice KSK+ZSK. S příchodem eliptických křivek jsou podpisy kratší a méně DNS dotazů vyžaduje opakování odpovědi nad TCP, protože se do UDP nevejdou.
A zlepšila se i situace ohledně komunikace subdomény s nadřazenou doménou – byly zavedeny dva nové typy záznamů: CDS a CDNSKEY. Tyto říkají nadřazené doméně, jaký DS nebo DNSKEY záznam si podřízená doména přeje publikovat. Tímto jde pak udělat key rollover, tedy výměnu klíče, bez manuální komunikace s nadřazenou doménou nebo jejím registrátorem. Problémem samozřejmě zůstává, jak dostat aspoň poprvé DNSSEC klíč bezpečnou cestou do nadřazené domény, než tato může začít věřit podepsaným CDS záznamům. Toto dělají různé domény různě. Pro top-level doménu .cz to CZ.NIC má udělané tak, že pokud detekuje na DNS serveru subdomény CDS záznam, tak informuje mailem technické správce domény, a pak po dobu sedmi dní sleduje, jestli tento záznam je pořád stejný a jestli je publikovaný na všech autoritativních DNS serverech. Po sedmi dnech pak automaticky zavedou příslušný DS záznam do domény .cz. Takto lze zabezpečit doménu druhé úrovně DNSSECem, aniž by bylo třeba komunikovat s registrátorem.
DNS server BIND od verze 9.16 si umí sám hlídat TTL v dané zóně, a ve správných časových intervalech dělat jednotlivé kroky případného key rollover, publikovat se zpožděním CDS záznamy a podobně. V zásadě stačí k příslušné doméně napsat direktivu dnssec-policy default.
DNSSEC v síti FI
O nasazení DNSSECu jsme uvažovali již dlouho, dokonce jsme na několika méně používaných doménách měli vygenerované klíče a podpisy. Monitoring své i nadřazených domén máme zapnutý již od prvního výpadku nadřazené domény, a od té doby v této doméně odhalil několik problémů dřív, než o nich věděli správci samotní. A validující rekurzivní DNS servery používáme s přestávkami také již delší dobu.
Až teprve se zavedením CDS a dalšími novinkami, popsanými výše, jsme se rozhodli, že už je tento systém dostatečně vyvinutý, a nasadíme DNSSEC i na naše domény. V několika postupných krocích jsme převedli nejprve dříve podepsané domény z dvojice KSK+ZSK na CSK s eliptickou křivkou, a pak jsme podepisovali nové domény a postupně jim nechali zavádět DS záznamy do nadřazených domén. V současnosti máme podepsané všechny námi spravované domény včetně reverzních zón, snad jen s výjimkou reverzních zón pro privátní adresy, kde z principu nejde mít ověřený řetězec podpisů od kořenové domény. Při nasazování podpisů jsme jen mimochodem vyvolali podepsání některých dalších sousedních i nadřazených zón a opravu jednoho problému s podpisy, na který dosud nikdo nenarazil.
Dalšími kroky může být zavedení dalších typů DNS záznamů zejména do domény fi.muni.cz tak, aby bylo možno využít toho, že data z DNS lze nyní získat důvěryhodnou cestou. Týká se to zejména otisků veřejných SSH klíčů (záznam SSHFP) a případně ještě odkazů na veřejné klíče nebo certifikační autority pro TLS (záznam TLSA pro DANE). Ani jedno z toho ale není implicitně zapnuté na klientech, a tak je použitelnost prozatím omezená.
Užitečným pomocníkem při nasazování DNSSECu nám byla a je také síťová služba DNSViz. Zde je možné vidět platnosti klíčů, jejich typy, případné rozdíly v konfiguraci mezi jednotlivými autoritativními nameservery, atd.
