DNSSEC - Domain Name System Security Extensions -> SAMURAJ-cz.com

NÚKIB vydal veřejnou vyhlášku s ochranným opatřením na zabezpečení elektronické pošty. Pro subjekty pod ZKB je zavedení povinné, ale pro ostatní je doporučené. Zveřejněno 11.10.2021 na úřední desce včetně FAQ a metodiky. Je zde také bod, že všechny DNS záznamy, související s elektronickou poštou, musí být chráněny pomocí DNSSEC. A hraniční SMTP servery validují záznamy pomocí DNSSEC.

Co je to DNSSEC

Dokumentace

V článku se nachází různé odkazy na RFC dokumenty a speciální popisy. Zde jsou nějaké obecnější informace:

Dále různé online nástroje:

Stručně, jak DNSSEC funguje

DNSSEC je rozšíření systému doménových jmen (DNS) specifikované v celé řadě IETF RFC (primární jsou RFC4033, RFC4034 a RFC4035, doplněné řadou dalších, jako RFC6781). Využívá asymetrickou kryptografii, která pracuje s veřejným a soukromým klíčem (párem klíčů), pro digitální podpis dat. Trocha obecných informací o kryptografii je uvedena v článku Obecný úvod do šifrování dat.

Hodně zjednodušeně držitel domény vygeneruje pár klíčů. Soukromým klíčem podepisuje data (záznamy) v doméně (zóně). Veřejný klíč slouží k ověření podpisů, je publikován ve speciálním záznamu (DNSKEY) v doméně. Pro získání důvěry je jeho hash publikován (DS záznam) u dané domény u nadřízené autority (třeba CZ.NIC). Pokud nemůže být publikován, tak musí být zadán jako Trust Anchor (pevné body důvěry) na všech Resolverech, keré mají ověřovat doménu.

Cílem je získat jistotu, že vrácený záznam pochází od jeho vlastníka (autoritativního jmenného serveru) a nebyl podvržen nebo cestou změněn (útoky Man in the Middle, DNS cache poisoning and answer forgery, které vedou k přesměrování provozu (hijack traffic) na útočníkův server).

Pomocí DNSSEC podepisujeme zónu (sign a zone with DNSSEC). To znamená, že všechny záznamy v zóně (doméně) se podepíší soukromým klíčem. Podpis se ukládá do speciálního DNS záznamu (RRSIG). Podepisování provádí (automaticky) autoritativní DNS server (Name Server). Při aktivaci DNSSEC se nemění základní fungování DNS dotazů a odpovědí.

Klient, podporující DNSSEC, může sám provádět ověření nebo využít Resolver (typicky DNS server) a důvěřovat jeho odpovědi, že byl záznam ověřen. Při DNS dotazu dostává zpět požadovaný záznam a také jeho podpis. Nejprve ověří validitu klíče a následně pomocí něj vlastní podpis.

Jde tedy o to, že určitá doména, kde překládáme doménové jméno na IP adresu (obecně hledáme určitý záznam), musí být podepsaná. V internetu je podepsaná pouze část domén, ani řada velkých firem DNSSEC nepoužívá (třeba www.google.com, www.microsoft.com). Druhá část je, že náš klient musí využít DNSSEC ověření, a pokud není podpis v pořádku, tak adresu nepoužít. Domény, které nejsou podepsané, se neověřují. V praxi mohou různé chyby způsobit, že ověření záznamu selže, takže validující klienti ignorují záznamy, které jsou jinak v pořádku.

Zprovoznění DNSSEC

Zapnout a použít DNSSEC můžeme na dvou stranách, zobecněně a zjednodušeně na serveru (podepisování, při odpovědi) nebo na klientovi (ověřování, při dotazu) (podle toho, co chceme použít, kdo jsme)

Authoritative Name Server - pokud jsme správce DNS serveru, kde je určitá doména (zóna), tak podepíšeme zónu a tím mohou být naše záznamy ověřeny, jsme poskytovatel dat z domény
Klient (Recursive Name Server) - pokud jsme správce ve firmě nebo uživatel, tak chceme ověřovat DNS odpovědi, pokud jsou podepsané (DNSSEC validace), musíme aktivovat DNSSEC ověřování na klientech, případně také zprovoznit ověřování na Recursive Name Server

Aby DNSSEC prakticky fungoval, tak musí být použit na obou stranách.

Když chceme zprovoznit DNSSEC na doméně, tedy podepsat svoji zónu, tak může jít o dvě praktické varianty (tak to alespoň vidím já, většina dokumentace se věnuje pouze té první, případně zase jen druhé).

veřejná doména v internetu - patří tedy do jmenného prostoru internetu, který začíná kořenovou zónou (.), důvěra se řeší v rámci DNS stromu
privátní nebo interní (neveřejná) doména - na interních DNS serverech provozujeme oddělený jmenný prostor (Private DNS zone), musíme použít Trust Anchor

DNS dotaz s DNSSEC

Pokud posíláme dotaz na záznam v podepsané zóně, tak nastavujeme EDNS DNSSEC OK (DO) bit. DNS server pak do odpovědi přidá další DNSSEC záznamy (ty mohou být delší, než je standardní velikost DNS zprávy, proto je také třeba EDNS). Zjednodušeně řečeno, když se ptáme na Host Address, tak dostaneme A záznam a zároveň RRSIG záznam.

DNSSEC validace na klientovi

Pro testování (provádění) DNSSEC dotazů můžeme využít Linuxový nástroj dig (v dotazu použijeme +dnssec). Pokud pracujeme ve Windows, tak můžeme použít online verzi, například Dig web interface. Pro vyhledávání některých DNSSEC typů záznamů můžeme použít MXToolBox SuperTool. Také lze použít PowerShell cmdlet Resolve-DnsName (s přepínačem -DnssecOk).

Pokud chceme využívat DNSSEC ověřování ve Windows, tak máme dvě možnosti. Můžeme použít plugin do webového prohlížeče, který sám validaci provádí a zobrazuje výsledek v prohlížeči. Druhá možnost je použít validující DNS Server (Security-Aware Recursive Name Server) a nastavit, aby při selhání ověření (obecně, aby prováděl ověření) nevrátil výsledek (vrací SERVFAIL). Pro nastavení musíme použít Name Resolution Policy Table (NRPT), která se konfiguruje pomocí Group Policy.

Určité možnosti popisuje CZ.NIC Otevřené DNSSEC Validující Resolvery.

Standardní průběh DNS vyhledání z klienta

Zjednodušený popis, jak probíhá proces DNS dotazu (query) a odpovědi (response) s DNSSEC. Předpokládáme, že klient je Non-Validating Security-Aware Stub Resolver. Pro dotaz využívá (Validating) Security-Aware Recursive Name Server (svůj DNS server). Žádná data nejsou kešovaná a všechny zóny jsou podepsané pomocí DNSSEC. Jednodušeji řečeno všichni v příkladu podporují a používají DNSSEC, ověření podpisů provádí DNS server.

Stub Resolver (DNS klient) pošle DNS dotaz na svůj DNS Server (Security-Aware Recursive Name Server), v dotazu nastaví DO bit na 1
Recursive DNS Server pošle dotaz na Root a TLD DNS servery, nastaví DO bit, získá adresu Authoritative DNS serveru pro zónu
autoritativní DNS server pro nadřazenou zónu indikuje, že je podřízená zóna podepsaná, a pošle DS záznam
rekurzivní DNS server pošle dotaz na autoritativní DNS server, nastaví DO bit (případně také CD bit, protože bude sám provádět validaci), v odpovědi získá data hledaného záznamu spolu s RRSIG záznamem (podpisem)
rekurzivní DNS server vrátí odpověď DNS klientovi a poskytne data záznamu
pokud je zóna podepsaná a rekurzivní DNS server ověřil vracené záznamy, tak nastaví v odpovědi AD bit
pokud ověření selhalo, tak vrací chybu SERVFAIL
pokud chceme získat odpověď, i když neprošlo ověření, tak v dotazu nastavíme CD bit
pokud DNS server není validující, tak nenastaví AD bit (ani neprovede ověření) a vrací odpověď s daty (pokud podporuje DNSSEC, tak včetně RRSIG záznamu)

Pozn.: Microsoft uvádí, pokud se klient ptá přímo autoritativního DNS serveru (tedy jeho DNS server spravuje zónu, do které je dotaz), tak server v odpovědí nastaví AA bit (Authoritative Answer). Již neprovádí ověření a nenastaví AD bit, protože by bylo redundantní, aby ověřoval svou vlastní odpověď. Klient akceptuje takovou odpověď.

Kryptografické algoritmy

Protože základem DNSSEC je asymetrická kryptografie, tak je důležité, jaké algoritmy můžeme použít. Seznam nalezneme v příloze RFC4034, ale asi nás budou zajímat novější SHA-2 a eliptické křivky, které jsou definované v dalších RFC5702, RFC6605, RFC8624. Eliptické křivky (ECDSA) mají řadu výhod oproti RSA, jako menší velikost a rychlejší podepsání (ale pomalejší ověření podpisu). Algoritmy jsou označovány čísly, například

8 je RSASHA256
13 je ECDSAP256SHA256
14 je ECDSAP384SHA384
15 je ED25519
16 je ED448

DNS (Domain Name System)

Okolo DNS je řada termínů, některé důležitější (potřebné pro DNSSEC) si velmi stručně popíšeme. Trochu se liší termíny a popisy, které jsou uvedeny v RFC (třeba RFC1034) a například v popisech u Microsoftu. Základy DNS jsem popisoval ve velmi starém článku DNS (Domain Name System) zaměřeno na Microsoft.

Rekurzivní a nerekurzivní dotaz

DNS dotaz může být

nerekurzivní (Non-Recursive Query) - server odpovídá pouze lokálními informacemi
rekurzivní (Recursive Query) - server provede řadu dotazů (prochází DNS strom), aby se dostal k cílové informaci (teoreticky projde přes kořenový DNS a TLD DNS až k autoritativnímu DNS), může využít kešování a odpovědět daty v paměti

Trochu speciálnější možností je využití opakování (iteration), kdy se vrací odkaz na další DNS server, případně přeposílání (forwarding).

Name Server vs. Resolver

Základní komponenty DNS (nebo role DNS serveru) jsou

Name Server (jmenný server) - často se používá termín DNS server, je server, na kterém jsou uloženy kompletní záznamy pro doménu, odpovídá na dotazy pro svou zónu (podmnožinu doménového prostoru), může ukládat do mezipaměti strukturu libovolné části doménového stromu, zjednodušeně Name Server poskytuje DNS záznamy
Resolver - je program, který získává informace z Name Server jako odpověď na dotaz klienta, musí mít přístup alespoň k jednomu jmennému serveru a použije informace k přímé odpovědi na dotaz nebo provádí dotaz pomocí odkazů na jiné jmenné servery, zjednodušeně Resolver se dotazuje (hledá) DNS záznamy, u Microsoftu se také využívá označení DNS server

DNS server ve firmě slouží často jako Name Server (Authoritative Name Server) i jako Resolver (Recursive Name Server). Je na něm hostována jedna nebo více domén a zároveň jej klienti používají pro překlad adres v internetu. Pokud přijde dotaz na doménu, kterou server spravuje, tak odpoví lokálními údaji. Pokud má platný záznam v mezipaměti (Cache), tak použije ten. V ostatních případech provede rekurzivní dotazy (běžně začne pomocí Root Hints) a nalezne odpověď.

Pozn.: Poslední, z hlavních komponent DNS, je Domain Name Space a Resource Record.

Stub Resolver vs. Recursive Resolver

Resolver může být

Stub Resolver - minimální DNS Resolver, který využívá rekurzivní dotazovací mód, posílá jeden rekurzivní dotaz na Recursive Name Server, který za něj provede celé vyhledání a vrátí výsledek, operační systém (jako Microsoft Windows) většinou využívá Stub Resolver (DNS Client)
Recursive Resolver - provádí sadu dotazů procházením DNS stromu, aby získal odpověď na dotaz (od autoritativního DNS), pokud je veřejně dostupný z internetu (Open Recursive Resolver), tak může jít o bezpečnostní riziko a dá se zneužít k útokům

Name Server (DNS Server)

Name Server může být několika typů (záleží na úhlu pohledu, první dvě varianty můžeme řadit mezi Authoritative Name Server)

Root Name Server - 13 základních kořenových jmenných serverů, které obsluhují DNS Root Zone (.), jejich adresy se zadávají do Root Hints, Root Servers
TLD Name Server - jmenný server pro domény nejvyšší úrovně (Top Level Domain - TLD), jako je .cz a .com
Authoritative Name Server - důvěryhodný jmenný server, který je zodpovědný za danou zónu (doménu) nižší (druhé) úrovně, spravuje a drží záznamy, třeba firma.cz, odpovídá na dotazy své zóny (pomocí vlastního Zone File), většinou máme více serverů pro doménu, jeden je primární (na něm se editují záznamy, také provádí DNSSEC podepisování) a další jsou sekundární (informace jsou replikovány z primárného pomocí Zone Transfer)
Non-Authoritative Name Server (častěji se označuje jako Recursive Name Server, případně Caching Name Server) - server, jde o Recursive Resolver, odpovídá na rekurzivní DNS dotaz klienta buď nalezeným záznamem (který hledá na jmenných serverech) nebo chybou (nenalezeno)

Security-Aware klient nebo server

Když pracujeme s DNSSEC, tak k Resolver i Name Server přibývají vlastnosti

Security-Aware nebo DNSSEC-Aware - rozumí (umí pracovat s) rozšířením zabezpečení DNS (DNSSEC)
Validating - sám provádí ověření podpisu (DNSSEC)
Non-Validating - neprovádí ověření, ale může důvěřovat přátelskému jmennému serveru s podporou DNSSEC, který provede ověření

Máme třeba Non-Validating Security-Aware Stub Resolver. Tedy DNS klient, který důvěřuje určitému Security-Aware Recursive Name Server, ten provede DNS dotaz a DNSSEC ověření a bezpečně předá výsledek klientovi. V odpovědi se využívá Authenticated Data (AD) bit. Klient rozumí výsledku ověření. Je potřeba, aby komunikace s DNS serverem byla zabezpečená (DNS over TLS) a nemohl proběhnout Man in the Middle útok.

Nebo Validating Security-Aware Stub Resolver, který posílá dotaz v rekurzivním módu, ale ověření podpisu provádí sám (nespoléhá na odpověď od Security-Aware Recursive Name Server, kterému posílá DNS dotaz).

DNS klient ve Windows od verze Windows 7 a Windows Server 2008 R2 je Non-Validating Security-Aware Stub Resolver.

DNS záznamy a nové typy pro DNSSEC

DNS zdrojový záznam - Resource Record (RR)

Záznam je popsán v RFC1034. Doménové jméno (doména) identifikuje uzel ve stromové struktuře prostoru doménových jmen (Domain Name Space). DNS záznam (Resource Record) se skládá ze jména domény a souboru informací o zdrojích. Jeho struktura je

Owner Name (jméno) - doménové jméno záznamu
TTL - Time to Live, jak dlouho může být záznam kešován (ve vteřinách)
Class (třída) - identifikuje protokol IN (Internet system)
Type (typ) - typ záznamu, například A (Host Address), CNAME (Canonical Name of an Alias), NS (Authoritative Name Server)
RDATA - data podle typu záznamu, například pro A záznam jde o IP adresu

Sada záznamů - Resource Record Set (RRset)

DNSSEC podepisuje vždy sadu záznamů (ne jednotlivý záznam, ale v sadě může být pouze jeden záznam, což často je). Resource Record Set (RRset) je skupina DNS záznamů v zóně, které mají stejné jméno a typ. Například máme dva A záznamy pro adresu www.firma.cz, s dvěma IP adresami, kde je web dostupný. Ověřujeme pak najednou celou skupinu, musíme tedy získat všechny záznamy daného RRsetu.

Nové typy DNS záznamů pro DNSSEC

Záznamy jsou popsány v RFC4034, RFC5155, RFC7344. Nový typ vždy obsahuje standardní položky jméno, TTL, třída a typ a další údaje se nachází v části RDATA.

RRSIG (Resource Record Signature)

Obsahuje podpis sady záznamů (Record Set). Položky

typ podepisovaného záznamu
algoritmus podpisu
Labels (používá se pro wildcard)
originální TTL (podepisovaného záznamu)
interval platnosti (do data Expiration od Inception)
Key Tag (pro určení DNSKEY záznamu s veřejným klíčem, popsáno níže)
Signers Name (jméno podepisující zóny, kde je DNSKEY)
vlastní podpis (Base64 encoded)

DNSKEY (DNS Public Key)

Obsahuje veřejný klíč (ZSK nebo KSK), který se použije pro ověření podpisu v RRSIG záznamech. Položky

Flags (vlajky/příznaky určující klíč, bit 7 určuje Zone Key, bit 15 Secure Entry Point, standardně 256 znamená ZSK a 257 KSK)
protokol (pevná hodnota 3)
algoritmus veřejného klíče
veřejný klíč (Base64 encoded)

DS (Delegation Signer)

Odkazuje na DNSKEY záznam v podřízené zóně (příklad DS záznam v zóně firma.cz odkazuje na DNSKEY v zóně sub.firma.cz, ale oba záznamy mají stejné jméno sub.firma.cz). Obsahuje hash DNSKEY záznamu s veřejným klíčem KSK. Položky

Key Tag (pro určení DNSKEY záznamu s veřejným klíčem)
algoritmus veřejného klíče
algoritmus pro vytvoření hashe (Digest Type)
hash DNSKEY záznamu (digest in hexadecimal)

NSEC (Next Secure Record)

Používá se pro ověření, že určitý záznam skutečně neexistuje. Záznamy v zóně jsou seřazeny v canonical order. Pro každý záznam (owner name) je vytvořen NSEC, který obsahuje informaci o dalším autoritativním jméně v pořadí. Pokud je dotaz na neexistující záznam, tak místo prázdné odpovědi vrátí NSEC pro další záznam v pořadí. Položky

další autoritativní doménové jméno
Type Bit Maps (obsahuje seznam existujících typů záznamů pro dané doménové jméno)

NSEC3 (Next Secure Record Version 3) je nová verze, která chrání proti vyčítání zón (Zone Walking). Jméno (owner name) je uloženo pomocí hash funkce. Ale ani toto řešení není úplně bezpečné.

NSEC3PARAM (Next Secure Record Version 3 Parameters) používají autoritativní DNS servery pro určení, který NSEC3 záznam použít při odpovědi.

CDNSKEY a CDS se používá pro podřízenou zónu vyžadující aktualizaci DS záznamů v nadřazené zóně.

U záznamů RRSIG a DS se používá Key Tag. Je to něco jako ID, které identifikuje použitý DNSKEY záznam. Není to unikátní identifikátor. Pro určení DNSKEY se využívá kombinace Key Tag, Owner name a algoritmus. Key Tag není uložen v DNSKEY záznamu, ale vypočítává se definovaným způsobem.

Obrázek níže ukazuje příklad dvou DNSKEY záznamů a jednoho RRSIG (podepsaného pomocí uvedeného ZSK). Každý záznam je zobrazen dvakrát (zobrazení je trochu oříznuté) pomocí jiného formátování (nástroje).

DNS doplňující informace

Entity související s doménou a její registrací

V souvislosti s DNS a DNSSEC vystupuje řada entit. Musíme se v nich orientovat, když chceme podepsat vlastní doménu.

registr - registr doménových jmen je databáze, která obsahuje informace o subdoménách, máme registr pro domény nejvyšší úrovně (TLD - Top-Level Domains, například .cz), kde jsou informace o doménách druhé úrovně, obsahuje seznam názvů registrovaných domén a identifikaci jejich autoritativních jmenných serverech (Name Servers)
správce registru - pro doménu .cz je to zájmové sdružení CZ.NIC (NIC - Network Information Center)
registrátor - smluvní partner správce registru, který provádí registraci jmen domén (komunikuje se správce registru, držitel domény komunikuje s registrátorem)
provozovatel DNS - jmenné servery pro danou doménu, může provozovat registrátor, jiná organizace nebo držitel domény
držitel doménového jména - kdo registroval (na koho je registrováno) dané doménové jméno

EDNS

Podmínkou pro využití DNSSEC je podpora Extension Mechanisms for DNS (EDNS0, RFC2671), specifikace rozšíření velikosti parametrů DNS.

DNS Flags

DNS zprávy využívají Flags (vlajky / příznaky), určité bity ve zprávě. Pro DNSSEC vznikly tři nové:

Authenticated Data (AD) - v DNS Message Header, používá se v odpovědi, nastaví Name Server pokud ověřil všechny vracené záznamy pomocí DNSSEC
Checking Disabled (CD) - v DNS Message Header, používá se v dotazu, odpověď má být odeslána bez ohledu na to, zda byla validace úspěšně provedena (normálně Name Server záznamy, kde požadované ověření selhalo, nevrací)
DNSSEC OK (DO) - v EDNS části položky Opt RR TTL, používá se v dotazu, znamená, že Resolver podporuje DNSSEC a chce získat DNSSEC data v odpovědi

Starší DNS Flag, který se používá i s DNSSEC, pokud je AA, tak se neprovádí kontrola a nenastavuje AD:

Authoritative Answer (AA) - v DNS Message Header, používá se v odpovědi, znamená, že odpovídající server je autoritativní pro doménové jméno v dotazu

Práce s podpisovými klíči

Klíče a podepisování

Zóna podepisuje (spočítá hash danou funkcí a ten zašifruje soukromým klíčem) své autoritativní záznamy (přesněji sady záznamů) pomocí soukromého klíče. Pro každý záznam v zóně se podpis ukládá do RRSIG záznamu. Odpovídající veřejný klíč je uložen v DNSKEY záznamu v zóně. DNS Resolver (překladač / DNS server) může použít veřejný klíč k ověření podpisu záznamů v zóně (rozšifruje hash a porovná s vypočteným) a tím záznamy autentizovat.

Obecně se pro ověřený veřejný klíč (uložený v DNSKEY záznamu), který používáme pro validaci podpisů, používá termín Authentication Key.

DNSSEC pracuje s dvěma páry klíčů (dva typy podpisových klíčů, každý klíč má veřejnou a soukromou část):

Zone Signing Key (ZSK) - klíč podepisující zóny, používá se k podpisu záznamů v zóně (v mé doméně), je kratší a častěji se mění
Key Signing Key (KSK) - klíč podepisující klíče, používá se k podpisu klíče podepisujícího zóny (ZSK), je delší a není nutné jej tak často měnit

Oba typy klíčů (ZSK i KSK) jsou uloženy v zóně, každý v samostatném DNSKEY záznamu. Standardně se rozlišují pomocí příznaku 256 a 257. V zóně může být uloženo i více verzí (ZSK nebo KSK) klíče.

Výměna klíčů (Key Rollover)

Klíče je doporučeno pravidelně měnit, i když nemají datum exspirace (může dojít k jejich prolomení a tím se DNSSEC ochrana ztrácí). Určité informace obsahuje RFC 4986. Podpisy jednotlivých záznamů v zóně mají datum exspirace. Před jeho koncem je potřeba záznamy nově podepsat. Nastavujeme dobu platnosti (životnost) podpisu, například 7 dní. Již starší informace doporučují ZSK měnit každé 3 měsíce, KSK každý rok (ale záleží na různých okolnostech, algoritmu, apod).

Určitou dobu musíme mít paralelně starý a nový klíč (a případně podpis). Protože záznamy (RRSIG i DNSKEY) mají TTL a po tu dobu mohou být kešovány. Až když čas vyprší, tak můžeme smazat staré klíče.

Výměnu klíčů (Rollover) můžeme prakticky provádět dvěma způsoby:

před-publikovaní klíčů - přidáme nový klíč (DNSKEY záznam), počkáme, aby se záznam rozdistribuoval, nově podepíšeme záznamy novým privátním klíčem, počkáme, smažeme starý klíč
dvojitý podpis - přidáme nový klíč (DNSKEY záznam), podepíšeme zónu oběma klíči (máme vždy dva RRSIG), počkáme, smažeme starý klíč, podepíšeme novým klíčem/odstraníme staré podpisy

Před-publikování klíčů může fungovat ještě trochu jiným způsobem. Tak to provádí Microsoft DNS. Na začátku vytvoříme dva klíče, jeden aktivní (Active key) a druhý záložní (Standby key). Když je potřeba, tak podepíšeme záznamy záložním klíčem. Klíče vyměníme a vygenerujeme nový záložní.

Zveřejnění DS záznamů

Záznamy v doméně ověřujeme pomocí veřejného klíče, který je zveřejněn v dané doméně. Potřebujeme tedy získat důvěru tomuto klíči. K tomu slouží DS záznam v zóně vyšší úrovně. Ten se označuje jako Secure Entry Point (SEP), tedy bezpečný vstup do zóny (DS ověřující DNSKEY). SEP je také bit v DNSKEY záznamu (určující KSK).

Střídavá sekvence sady záznamů DNSKEY a DS tvoří řetězec podepsaných dat, označovaný jako Authentication Chain, kdy každý článek ručí za další.

Pozn.: Pro DNSSEC se vytvářelo řešení, aby se dal zprovoznit, pokud jej nadřazená (TLD) zóna nepodporuje (kdyby třeba zóna .cz nebyla podepsaná). Jde o DLV (Domain Lookaside Validation) registr, kde se vytváří DLV záznamy. Nevím, zda toto řešení funguje, diskuse uvádí, že dlv.isc.org přestalo existovat.

Zjednodušené popisy uvádí, že veřejný klíč publikujeme u nadřazené autority (pro doménu .cz u CZ.NIC). Tím se vytváří řetěz důvěry v hierarchii DNS (podrobnější popis je dále). Není to ovšem přesné. Veřejný klíč ZSK i KSK, které používáme pro podpisy v naší zóně (firma.cz), ukládáme do DNSKEY záznamů v této zóně. V nadřazené zóně (.cz) musíme vytvořit DS záznam, který obsahuje určení našeho veřejného KSK klíče a jeho ověření pomocí hashe DNSKEY záznamu (hash je menší, takže šetří prostředky DNS serveru, kde je mnoho zón). Tento záznam je opět podepsán ZSK klíčem rodiče.

Do registru domény .cz můžeme ukládat data pouze pomocí našeho registrátora. Proto výměna klíčů není jednoduchý proces. CZ.NIC uvádí následující informace o zveřejnění DS záznamu (Zveřejnění DS záznamů):

V registru pro doménu CZ se DS záznamy generují automaticky z údajů o podpisovém klíči. Proto je nutné vytvořit takzvaný KEYSET a do něj vložit kompletní údaje DNSKEY záznamu ze zónového souboru. Tento KEYSET je pak třeba připojit k Vaší doméně. Toto vše udělejte pomocí systému registrátora příslušné domény.

Automatická delegace (vytvoření DS záznamu)

Narazil jsem na článek, že CZ.NIC podporuje automatickou správu DNSSEC delegace, kdy můžeme vyměnit klíč bez nutnosti komunikace s registrátorem. Doména .CZ spouští jako první automatickou správu DNSSEC klíčů. Na tyto informace jsem v popisu DNSSECu na CZ.NIC nenarazil, až pomocí Google jsem našel Automatizovaná správa keysetů. (Také vám přijde dokumentace na CZ.NIC tak hrozně nepřehledná, a ne moc kvalitní?)

V popisu se dozvíme, že je možno využít speciální typ DNS záznamu CDNSKEY. CZ.NIC každý den prochází domény a hledá tento záznam. Je tu ovšem problém, jaké DNS servery podporují CDNSKEY. DNS Server role na Windows Server tento záznam nepodporuje.

Trust Anchor (pevné body důvěry)

Trust Anchor je výchozí bod pro vytvoření autentizačního řetězce (Authentication Chain) na podepsanou DNS odpověď, který používá Validating Resolver. Jde o konfigurovaný DNSKEY nebo DS záznam, tedy veřejný klíč nebo hash. Validující Resolver musí získat výchozí hodnoty Trust Anchor nějakým bezpečným kanálem mimo protokol DNS. Přítomnost Trust Anchor také znamená, že zóna, kam ukazuje, je podepsaná.

DNSSEC důvěra v internetu začíná u podepsané kořenové zóny a tedy (teoreticky) stačí pouze jeden Trust Anchor, který se označuje jako Root Trust Anchor. Jde o Root KSK, který se musí nastavit v každém překladači podporujícím DNSSEC (Validating DNSSEC-aware Resolvers). Oficiální zdroj IANA Trust Anchors and Keys.

Pokud chceme ověřovat zónu, která není napojena na autentizační řetězec od kořene, nebo je tento řetězec přerušen (některý článek nepodporuje DNSSEC, nemají podepsánu nadřazenou zónu), musíme v Resolveru manuálně nastavit jejich Trust Anchor.

Jak probíhá ověření - nastavení důvěry v internetu

Důvěra uvnitř naší zóny

Veřejný klíč Zone Signing Key (ZSK) se ukládá do DNSKEY záznamu v doméně a soukromý používá pro podpis záznamů. Podpisy se ukládají do RRSIG záznamů. Pokud důvěřujeme ZSK, tak důvěřujeme všem záznamům, které podepsal.

Abychom důvěřovali ZSK, tak je ZSK podepsán pomocí Key Signing Key (KSK). Podpis je opět uložen v RRSIG záznamu. Veřejný klíč KSK je uložen v dalším DNSKEY záznamu. Oba DNSKEY záznamy tvoří sadu záznamů (RRset), která je podepsána pomocí soukromého klíče KSK. Pomocí veřejného klíče KSK tedy ověříme veřejný klíč ZSK (a také vlastní KSK).

Důvěra mezi zónami

Takto jsme vytvořili důvěru uvnitř naší zóny. Ale potřebujeme důvěřovat celé hierarchické struktuře DNS. A také důvěřovat KSK, který je podepsán sám sebou. Pro vytvoření důvěry mezi nadřazenou zónou (Parent Zone) a podřízenou zónou (Child Zone) se využívá DS záznam. Vypočítá se hash pro DNSKEY záznam obsahující veřejný klíč KSK a ten se uloží do DS záznamu v nadřazené zóně. DS záznam je podepsán soukromým ZSK klíčem nadřazené domény.

Pokaždé, když je Resolver odkázán na podřízenou zónu, nadřazená zóna také poskytuje DS záznam. Resolver se tak dozví, že podřízená zóna má povolen DNSSEC, a ověří veřejný klíč KSK. Tak se vytváří řetěz důvěry (Chain of Trust). Při výměně KSK se musí změnit DS záznam v nadřazené zóně. Při výměně musíme nejprve přidat nový DS, počkat po dobu TTL, aby vypršel původní záznam, pak jej teprve smazat. Nebo mít dopředu zveřejněny dva DS záznamy. Pokud se něco provede špatně, tak rozbijeme naši DNS zónu (DNSSEC ověřování).

Důvěra kořenové zóně

Důvěra DS záznamu je nastavena tím, že je tento záznam také podepsán (má svůj RRSIG). Takto provádíme ověření v hierarchii nahoru (procházíme řetěz důvěry), až se dostaneme na kořenovou zónu (Root DNS Zone.). Ta obsahuje autoritativní informace pro dotazy na Top-Level Domains (TLD) jako je .cz a .com.

Podpis veřejného klíče kořenové DNS zóny (tedy vytvoření RRSIG pro DNSKEY, kde je KSK a ZSK kořenové zóny) je prováděn veřejnou, auditovanou a zabezpečenou procedurou zvanou Root Signing Ceremony. Privátní klíč, který se použije, je klíč k celému internetu chráněnému DNSSECem. Tak se kořenové DNS Name Servers stávají důvěryhodnou kotvou (Root Trust Anchor). Důvěra není odvozena z nadřazené zóny, ale díky procesům důvěřujeme těmto údajům (uvedené údaje na oficiálních serverech se berou jako validní). Root Trust Anchor bezpečně získáme od IANA Trust Anchors and Keys.

Řetěz důvěry - Chain of Trust

Ověřování probíhá v hierarchii DNS pomocí řetězu důvěry, který nesmí být porušen. Stručný popis s příkladem:

záznamy v doméně (třeba A záznam pro www.firma.cz) ověřujeme díky jejich podpisu v RRSIG záznamu, pro ověření použijeme veřejný klíč ZSK (zóny druhé úrovně) v DNSKEY záznamu (zóna firma.cz)
ZSK ověříme tak, že sada záznamů DNSKEY je podepsána (RRSIG), pro ověření použijeme veřejný klíč KSK (zóny druhé úrovně) v dalším DNSKEY záznamu (zóna firma.cz)
KSK ověříme pomocí DS záznamu v nadřazené zóně (zóna .cz), kde je hash veřejného klíče KSK, tedy ověřujeme DNSKEY záznam
DS záznam je podepsán v RRSIG záznamu (zóna .cz), ověříme ho pomocí ZSK (TLD)
ZSK ověříme pomocí KSK (TLD) v DNSKEY záznamu (zóna .cz)
KSK ověříme pomocí DS záznamu v nadřazené zóně (kořenová zóna .)
DS záznam je podepsán v RRSIG záznamu (zóna .), ověříme ho pomocí ZSK (.)
ZSK ověříme pomocí KSK (.) v DNSKEY záznamu (zóna .)
KSK bereme jako důvěryhodný (Root DNS Trust Anchor)

www.SAMURAJ-cz.com

Kategorie článků

Nástroje

Hledání

Články