DNSSEC na Microsoft DNS Serveru

Pozn.: Prakticky jsem zkoušel na Windows Server 2016 a 2019.

Hlavní popis DNSSECu se nachází v předchozím článku DNSSEC - Domain Name System Security Extensions.

Tento článek v první části popisuje specifické věci a principy pro Microsoft - Microsoft a DNSSEC. V druhé se nachází praktický popis podpisu zóny, zveřejnění DS záznamu u CZ.NIC a výměny klíčů - DNSSEC na autoritativním DNS serveru.

Microsoft a Domain Name System Security Extensions

Dokumentace

• Overview of DNSSEC

Podpora DNSSEC

Microsoft podporuje DNSSEC na DNS Server roli Windows serveru. Vypadá to, že od Windows Server 2012 R2 se moc nezměnilo. Dokonce v novější dokumentaci o něm není žádná zmínka. Při zapínání DNSSEC na Windows Server 2019 je uveden odkaz do dokumentace pro verzi 2012.

Podpora DNSSEC na DNS serveru přišla ve Windows Server 2008 R2, ale pouze s offline podepisováním. Rozšířeno bylo ve Windows Server 2012, kde se přidalo online podepisování dynamických zón, podpora NSEC3, RSA/SHA-2, RFC 5011. Podepisovací klíče se generují automaticky, je podporována automatická výměna klíčů (Key Rollover). Pro podpis zóny můžeme zadat parametry nebo použít nastavení jiné zóny. Když je zóna aktualizovaná, tak je automaticky pře-podepsaná. Pokud je zóna integrována do AD, tak se klíče automaticky replikují.

Pro plné fungování DNSSEC potřebujeme

• primární autoritativní DNS server musí podporovat podepisování zóny
• primární a sekundární autoritativní DNS server musí podporovat hostování podepsané zóny
• rekurzivní DNS server musí podporovat DNSSEC ověření DNS odpovědi

DNSSEC vyžaduje podporu rozšíření EDNS0, které podporuje velké UDP pakety v DNS odpovědi. Ty musí procházet celou sítí (nesmí je blokovat aktivní síťové prvky).

DNS klient ve Windows

• DNS Clients

Podpora na klientovi je od Windows 7. DNS klient (i v serverovém OS) je DNSSEC-aware, tedy podporuje DNSSEC, ale neprovádí validaci. Přesné označení je Non-Validating Security-Aware Stub Resolver. Může být nastaven, aby vyžadoval DNSSEC ověřování od svého DNS serveru. I klient, který DNSSEC nepodporuje, může být chráněn pomocí DNSSEC, pokud jeho DNS server provádí ověření (nepošle klientovi DNS odpověď, pokud ověření selhalo).

DNS klient ve Windows automaticky nepožaduje validaci DNS odpovědí. To se musí speciálně povolit pro určitý jmenný prostor (Namespace) pomocí Name Resolution Policy. V politice se dá nastavit vyžadování ověření pro určité DNS zóny (Namespace).

Popis The NRPT, Procedure: Review Name Resolution Policy Settings, Checklist: Deploy DNSSEC Policies to DNS Clients.

Pokud má DNS Server instalovaný Trust Anchor pro určitou zónu, a zapnuté DNSSEC ověřování, tak automaticky zkouší ověření DNS odpovědi. I když není požadováno v NRPT Policy. Takže i Non-Security-Aware Client je chráněn, protože nedostane odpověď na nevalidní záznam. Pokud zóna není podepsána (odpodepíše se), tak na DNS serverech pro ni nesmí být Trust Anchor, jinak vždy ověření selže.

Microsoft DNS Server

Microsoft používá následující termíny pro hlavní dva typy Name Serveru:

• Authoritative DNS Server - server, který spravuje (a podepisuje) záznamy pro zónu (doménu)
• DNSSEC-aware Recursive (nebo Forwarding) DNS Server - (občas také Non-Authoritative DNS Server) server, který když obdrží od DNS klienta dotaz pro podepsanou zónu, tak požaduje od Authoritative DNS Server také zaslání DNSSEC záznamů. Pak se pokusí provést ověření podpisu.
  • že zóna podporuje DNSSEC pozná podle existence DNSKEY (Trust Anchor) pro zónu
  • pokud ověření proběhlo úspěšně, tak poskytne odpověď
  • pokud ne, tak odpoví zprávou SERVFAIL
  • pokud je DNS klient DNSSEC-aware, tak může být nastaven, aby vyžadoval od DNS serveru provádění DNSSEC validace

Když je zóna podepsaná pomocí DNSSEC, tak DNS Server automaticky vytváří všechny DNSSEC záznamy, až na DS záznam. Ten musí být vytvořen v rodičovské zóně nebo v podřízené zóně a propagován do rodičovské. Automaticky se vytváří také NSEC nebo NSEC3 (nemohou být použity společně).

Microsoft DNS server nebo DNS zóna může být  

• Active Directory-integrated - server je v doméně, údaje jsou uloženy v AD DS
• File-backed - samostatný server, údaje jsou uloženy v souboru (DNS databáze)

Na autoritativním DNS serveru můžeme vytvořit doménu (zónu), které je

• veřejná, delegovaná 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
• lokální, interní (neveřejná) - dostupná pouze v interní síti, na lokálních DNS serverech provozujeme oddělený jmenný prostor (Private DNS zone), kde je kořenový DNS server

Když provozujeme Microsoft DNS Server v interní síti, tak často slouží jako rekurzivní pro DNS dotazy interních klientů (je nastaven jako jejich DNS server v TCP/IP nastavení síťového adaptéru), ale také jako autoritativní pro určitou interní nebo veřejnou doménu.

Aby náš DNS server ověřoval domény v internetu, tak musíme instalovat kořenový Root Trust Anchor (.) a povolit DNSSEC Validation. Jinak můžeme instalovat Trust Anchor pouze pro vybranou zónu.

Key Master

Key Master je DNS server, který je zodpovědný za generování a správu klíčů pro podepsanou zónu pomocí DNSSEC. Pouze jeden DNS server pro danou zónu může být Key Master, musí to být primární autoritativní server. Jeden server může být Key Master pro více zón. Funkci Key Master můžeme přesouvat na jiný DNS server (který splňuje podmínky).

RFC 5011

Microsoft podporuje RFC 5011 pro aktualizaci Trust Anchors v rámci definovaných Trust Points (když funguje jako rekurzivní DNS Server - Resolver) a také pro výměnu klíčů na podepsané zóně (kdy funguje jako autoritativní DNS Server). Popis tohoto RFC mi přijde dost mlhavý, ale pokusil jsem se vypsat nějaké hlavní body jak jsem pochopil.

Dokument popisuje prostředky pro automatizovanou, autentizovanou a autorizovanou aktualizaci DNSSEC Trust Anchors. Na základě důvěry vytvořené přítomností aktuálního Trust Anchor, mohou být na stejné místo v hierarchii přidány další Trust Anchors, a nakonec nahradí stávající.

Přidává nový příznak (Flag/bit) do DNSKEY záznamu REVOKE (bit 8). Takto označený klíč nesmí Resolver použít jako Trust Anchor (může se použít pouze pro ověření DNSKEY podpisu za účelem ověření odvolání). DNSKEY s nastaveným bitem REVOKE má jiný otisk (a tedy Key Tag) než klíč bez nastaveného bitu. To ovlivní shodu DNSKEY s DS záznamem v nadřazené zóně.

• (Remove) Hold-Down Time - přidává zdržení, kdy Resolver akceptuje nový (nebo odstraní starý) Trust Anchor až po uplynutí (standardně) 30 dní
• Active Refresh - Resolver, který je nastaven na automatickou aktualizaci klíčů z určitého Trust Point, se musí dotazovat (vyhledat sadu DNSKEY záznamů a jejich podpis) maximálně jednou za hodinu, minimálně jednou za 15 dní (nebo polovina TTL pro DNSKEY nebo polovina intervalu exspirace podpisu).

Zvážení zapnutí DNSSEC pro doménu

Veřejné DNS zóny, které jsou připojené k internetu (nejsou součástí AD DS) a musí být veřejně dostupné, jsou zvláště náchylné k útoku. Proto se u nich často vyplatí nasadit DNSSEC. Nutné je zvážit význam domény.

Interní DNS zóny, které jsou využity pro AD DS doménu, jsou obvykle méně zranitelné vůči útokům, protože nejsou vystaveny do internetu nebo jsou chráněny dalšími bezpečnostními mechanismy. Proto se nemusí vyplatit administrativní zátěž spojená s provozem DNSSEC.

Nasazení DNSSEC znamená přidání mnoha záznamů (zvětšení velikosti zóny) a vyžaduje šifrování a dešifrování záznamů. Má dopad na výkon DNS infrastruktury a zvyšuje administrativní zátěž. Délka kryptografických klíčů ovlivňuje schopnost být kompromitován pomocí Brute Force Attack versus větší dopad na výkon. Popis DNSSEC Performance Considerations.

Zapnutí DNSSEC na DNS Serveru

Zpočátku jsem myslel, že jde pouze o zapnutí DNSSEC ověřování na DNS serveru. Ale v praxi jsem zjistil, že je nastavení (aktivace) společné pro celé fungování DNSSEC. Pokud na DNS serveru není DNSSEC povolen, tak sice můžeme podepsat zónu, ale při dotazu server nevrací podpisy (DNSSEC záznamy).

Na Windows Server 2012 R2 se dalo nastavovat pomocí DNS Manager ve vlastnostech DNS serveru na záložce Advanced, položka Enable DNSSEC validation for remote responses. V novějších verzích musíme použít příkazovou řádku, buď PowerShell cmdlet nebo příkaz dnscmd.

Zjištění stavu, zda je DNSSEC povolen.

PS C:\> Get-DnsServerSetting | FL EnableDnsSec
EnableDnsSec : False

C:\>dnscmd /info /enablednssec
Query result:
Dword:  0 (00000000)
Command completed successfully.

Za určitých podmínek se DNSSEC povolí automaticky. Nebo můžeme provést aktivaci ručně (jednodušší je pomocí příkazu dnscmd).

$a = Get-DnsServerSetting -All
$a.EnableDnsSec = 1
$a | Set-DnsServerSetting

DnsCmd.exe /Config /enablednssec 1

DNS dotazy (a NRPT) pomocí PowerShellu

Pro DNS dotazy s DNSSEC nemůžeme využít nslookup, ale je k dispozici PowerShell cmdlet Resolve-DnsName s parametrem DnssecOk.

PS C:\> Resolve-DnsName -name www.seznam.cz -type A -Server 8.8.8.8 -DnssecOk 

Name                                           Type   TTL   Section    IPAddress                                
----                                           ----   ---   -------    ---------                                
www.seznam.cz                                  A      299   Answer     77.75.75.172                             
www.seznam.cz                                  A      299   Answer     77.75.74.172                             

Name        : www.seznam.cz
QueryType   : RRSIG
TTL         : 299
Section     : Answer
TypeCovered : A
Algorithm   : 13
LabelCount  : 3
OriginalTtl : 300
Expiration  : 25.01.2022 6:40:29
Signed      : 11.01.2022 5:10:29
Signer      : seznam.cz
Signature   : {156, 187, 169, 33...}
 
Name      : .
QueryType : OPT
TTL       : 32768
Section   : Additional
Data      : {}

V příkladu výše požaduje klient DNSSEC informace, ale ne ověření odpovědí, protože Name Resolution Policy Table (NRPT) není nastavena, aby jej vyžadovala.

Vypsat politiku můžeme následujícím příkazem, pokud není nastavena (pomocí Group Policy), tak je výsledek prázdný.

Get-DnsClientNrptPolicy

Pokud politika existuje, tak můžeme upravit hodnoty pro určitý NameSpace. Třeba vyžadovat ověřování (pokud je nastaveno, tak má DNS dotaz vždy nastaven DO bit, i když se nepoužije parametr DnssecOk)

(Get-DnsClientNrptPolicy -NameSpace secure.contoso.com).DnsSecValidationRequired

Trust Anchors a Trust Points

Microsoft hodně používá termín Trust Anchor, a na některých místech (dokonce záměně) termín Trust Point. Popisuje, že jde o veřejný kryptografický klíč pro podepsanou zónu (tedy získání důvěry podpisům v dané zóně). Může jít o DNSKEY Trust Anchor, veřejný klíč z DNSKEY záznamu (Keyset - DNSKEYset), nebo DS Trust Anchor, DSset hash veřejného klíče (tak je to v dokumentaci Microsoftu, správně jde o hash DNSKEY záznamu).

Trust Anchor se musí nastavit na každém neautoritativním (rekurzivním) DNS serveru, který se pokusí ověřit DNS data podepsané zóny. Díky řetězu důvěry (Chain of Trust) stačí kořenový Trust Anchor. Autoritativní DNS server (hostující danou zónu) jej pro ověření nepotřebuje, protože vlastním záznamům důvěřuje (svoje záznamy neověřuje).

Delegování je postoupení autority z jednoho DNS serveru na jiný DNS server pro určitý obor názvů. Delegování se běžně používá k přiřazení oprávnění pro podřízené zóny. Pro DNSSEC se využívá delegování pomocí DS záznamu a tím se vytváří řetěz důvěry.

Na autoritativním DNS serveru, kde podepisujeme zónu pomocí DNSSEC, a který je zároveň Key Master, se Trust Anchors automaticky ukládají do textového souboru dsset-<zone.name> a keyset-<zone.name> v %windir%\system32\dns\. Pokud jde o veřejnou doménu v internetu (nebo existuje nadřazená doména), tak musíme Trust Anchor (jako DS záznam) vložit do nadřazené zóny.

Trust Points pro ověřování

Trust Point chápu tak, že jde o konfigurované Trust Anchor pro ověřování určité zóny. Nebo jinak, kontejner pro doménu, který obsahuje Trust Anchor a provádí jejich automatizovanou obnovu. Nastavuje se na validujícím DNS serveru (DNSSEC-aware Recursive DNS Server, který má zapnuté DNSSEC ověřování). Ten pak pro všechny zóny, pro které má Trust Point, provádí ověřování podpisů. Pokud chceme ověřovat DNSSEC v internetu, tak musíme vytvořit Root Trust Point.

Trust Points můžeme, na DNS serveru se zapnutým DNSSEC ověřováním, spravovat pomocí DNS Manageru v kontejneru Trust Points. Pokud je DNS server integrovaný v AD DS (a běží na doménovém řadiči), tak jsou Trust Anchors uloženy v rámci lesa (Forest) a replikují se na všechny DNS servery běžící na DC. Na samostatném DNS serveru se ukládají do souboru %windir%\system32\dns\TrustAnchors.dns (lokální Trust Anchor Store).

Zobrazení Trust Points

Na DNS serveru, který má zapnuté DNSSEC ověřování, si můžeme zobrazit seznam Trust Points (vidíme, kdy byl naposledy obnoven).

Get-DnsServerTrustPoint

Zobrazení Trust Anchors

Pro každý Trust Points můžeme zobrazit jeho Trust Anchors.

Get-DnsServerTrustAnchor -Name firma.cz

Export Trust Anchors

Protože DSset a Keyset Trust Aanchors se automaticky ukládají do textového souboru, tak stačí zkopírovat soubory, které pak můžeme použít pro import do nadřazené zóny.

Nebo můžeme použít PowerShell cmdlet (první je export DNSKEY a druhý DS).

Export-DnsServerDnsSecPublicKey -ComputerName DC2.firma.cz -ZoneName sec.firma.cz -Path \\Myshare\keys
Export-DnsServerDnsSecPublicKey -ComputerName DC2.firma.cz -ZoneName sec.firma.cz -Path \\Myshare\keys -DigestType sha256

Import nebo vytvoření Trust Points (Trust Anchors)

• Procedure: Import a Trust Point

Na validující DNS server můžeme importovat Trust Point pomocí DNS Manager:

• klikneme pravým tlačítkem na kontejner Trust Points
• pod Import volíme DNSKEY nebo DS
• vybereme soubor

Podobně můžeme vytvořit záznam ručně:

• klikneme pravým tlačítkem na kontejner Trust Points
• pod Add volíme DNSKEY nebo DS
• zadáme hodnoty

Nebo můžeme použít PowerShell cmdlet.

Import-DnsServerTrustAnchor -KeySetFile \\File1\DNSKeys\keyset-sec.firma.cz
Import-DnsServerTrustAnchor -DSSetFile \\File1\DNSKeys\dsset-sec.firma.cz

Import DS záznamu (Trust Anchor)

DS záznam se na nadřazeném DNS serveru nevytvoří automaticky. Můžeme ho přidat ručně nebo importovat vytvořený soubor s DS sadou záznamů (DSset).

Import-DnsServerResourceRecordDS -ZoneName firma.cz -DSSetFile "c:\windows\system32\dns\dsset-firma.cz" 

Nasazení Root Trust Point

• Procedure: Deploy a Root Trust Point, Updating of DNS Validating Resolvers with the Latest Trust Anchor

Pokud chceme, aby náš DNS server ověřoval DNSSEC pro internet, tak musíme přidat Trust Point pro kořenovou zónu (.), tedy IANA Root Trust Anchor. Tuto metodu nepoužijeme, pokud chceme ověřovat DNSSEC pouze v naší síti, kde je lokální DNS server kořenovým serverem.

Pro nasazení se používá IANA URL nastavené v parametrech DNS serveru. Zkontrolovat nastavení můžeme

PS C:\> Get-DnsServerSetting -All | Select RootTrustAnchorsURL
RootTrustAnchorsURL
-------------------
https://data.iana.org/root-anchors/root-anchors.xml

Přidání Root Trust Point. Po jeho vytvoření se automaticky stáhne aktuální DNSKEY záznam a aktualizuje Trust Anchor. Podporuje RFC 5011 pro automatickou aktualizaci Trust Anchors, kdy se může použít stávající Trust Anchors pro ověření nového.

Add-DnsServerTrustAnchor -Root

DNSSEC na autoritativním DNS serveru

Podíváme se na situaci, kdy jsme držitelem veřejné domény v internetu, a provozujeme vlastní DNS server, který běží na Microsoft DNS serveru. Když chceme tuto doménu zabezpečit pomocí DNSSEC, tak musíme

• podepsat zónu (doména firma.cz)
• zveřejnit DS záznam u nadřízené autority (do TLD domény, CZ.NIC)
• když dojde ke změně KSK klíče, tak obměnit DS záznam

Podepsání zóny

• DNS Zone - Zone Signing Wizard

Podepisování záznamů můžeme aktivovat pro určitou zónu (doménové jméno - doménu). Když podepisujeme zónu na Microsoft DNS serveru, tak musíme nejprve nastavit řadu parametrů. Základ je vygenerování párů klíčů ZSK a KSK. Můžeme u nich nastavit automatickou výměnu klíčů (Key Rollover), takže se po zadaném počtu dní vygenerují nové klíče a vymění. Po aktivaci se vytvoří potřebné DNSSEC záznamy (DNSKEY, NSEC3, NSEC3PARAM, RRSIG) a všechny existující záznamy se podepíší (vytvoří se pro ně RRSIG záznam). Při vytvoření nového záznamu se rovnou podepíše. Při automatické výměně ZSK se nově podepíší všechny záznamy.

Zónu můžeme podepsat pomocí PowerShell cmdletů nebo průvodce v DNS Manager, na který se zaměříme. Můžeme také zobrazovat a upravovat nastavené parametry a odpodepsat zónu. DNS Manager ukazuje podepsanou zónu se zámečkem. V seznamu je stav podepsáno a ukazuje se, kdo je Key Master.

• v DNS Manager console využijme Zone Signing Wizard
• klikneme pravým tlačítkem na vybranou zónu a zvolíme DNSSEC - Sign the Zone

Průvodce obsahuje kroky

• Signing options - volíme Customize zone signing parameters
• Key Master - volíme The DNS server … is the Key Master
• Key Signing Key (KSK) - přidáme nový klíč
• Zone Signing Key (ZSK) - přidáme nový klíč
• Next Secure (NSEC) - volíme Use NSEC3
• Trust Anchors (TAs)
• Signing and Polling Parameters
• zobrazí se shrnutí nastavených parametrů
• dokončíme a provede se podepsání celé zóny

Některé kroky si popíšeme trochu více.

Signing options

Pro určení hodnot DNSSEC parametrů můžeme využít

• Customize zone signing parameters - zadání vlastních parametrů
• Sign the zone with parameters of an existing zone - použití parametrů existující zóny
• Use default settings to sign the zone - využití výchozích parametrů

Key Signing Key (KSK)

Musíme použít alespoň jeden KSK a ZSK. Pokud zapneme automatickou výměnu klíčů (Key Rollover), tak se vygeneruje další podepisovací klíč ke každému ZSK a KSK. Pro KSK je podporována metoda dvojitého podpisu (double signature rollover method), pro ZSK předpublikace (pre-publish rollover method).

KSK slouží k podepisování klíčů (DNSKEY záznamy).

• DNSKEY RRSET signature validity period - délka platnosti podpisů pomocí KSK (tedy DNSKEY sady záznamů), default 168 hodin (dokumentace uvádí 72)
• Key Rollover - automatická výměna klíčů, zadáváme frekvenci, default 755 dní (doporučuje se kratší)

Zone Signing Key (ZSK)

ZSK podepisuje data v zóně. Častěji se mění a může mít kratší délku klíče než KSK.

• nastavujeme delku platnosti podpisů pro určité typy záznamů
  • DNSKEY signature validity period (168 hodin)
  • DS signature validity period (168 hodin)
  • Zone record validity period (240 hodin) - jaká je platnost podpisů záznamů v zóně, zde 10 dní (v praxi se používá třeba 14 dní)
• Key Rollover - automatická výměna klíčů, zadáváme frekvenci, default 90 dní (doporučuje se kratší)

Trust Anchors (TAs)

• Enable the distribution of trust anchors for this zone

Pokud zapneme, a DNS server je doménový řadič, tak se Trust Anchor distribuují na všechny DNS servery běžící na DC ve stejném lese (Forest). Pokud není DC, tak se uloží do lokálního Trust Anchor Store %windir%\system32\dns\TrustAnchors.dns. Trust Anchors nejsou potřeba pro DNS servery, které jsou autoritativní pro zónu. V rámci AD lesa bychom měli povolit pouze v případě, pokud další DNS servery (běžící na DC) budou poskytovat neautoritativní odpovědi pro zónu s DNSSEC.

• Enable automatic update of trust anchors on key rollover (RFC 5011)

Při zapnutí se při výměně klíčů postupuje podle RFC 5011 (popisujeme na konci článku). V PowerShellu se jmenuje EnableRfc5011KeyRollover. Probíhá (automatická) aktualizace (distribuce) Trust Anchors. Podle zmínky v dokumentaci je konfigurace uložena v %windir%\system32\dns\RFC5011.csv, ale takový soubor jsem nikde neviděl.

Z pozorování v praxi. Pokud se nezatrhne, tak se při podepsání zóny vytvoří pouze jeden KSK klíč. Výměna klíčů probíhá rychle během jedné hodiny (přidá se nový klíč, podepíše záznamy, odstraní).

Signing and Polling Parameters

Při podpisu zóny (výměně klíčů) se automaticky vytváří soubor s DS sadou záznamů (DSset) a Keyset (DNSKEY sada záznamů). Pro jejich vytvoření se použijí hodnoty:

• DS record generation algorithm
• DS record TTL
• DNSKEY record TTL

Další nastavované parametry:

• Secure delegation polling period - jak často se nadřazená zóna dotazuje na DNSSEC podřízené (odhadoval bych, že jde o interval, jak často se dotazuje na DS záznam v nadřazené zóně při výměně KSK, ale pořádný popis jsem nenalezl)
• Signature inception - o kolik hodin dříve je platný vytvořený podpis

Dokončení podpisu zóny

Zobrazí se nám shrnutí zadaných parametrů (které si můžeme zkopírovat) a tlačítkem Finish dokončíme průvodce. Okamžitě dojde k podpisu zóny. Abychom viděli výsledek, tak může být potřeba provést obnovení (Refresh) v DNS Manageru.

Vytvoří se dva klíče KSK a dva ZSK, pro každý se vytvoří DNSKEY záznam (tedy celkem 4). Celá sada DNSKEY záznamů se podepíše soukromým klíčem aktivního KSK. Microsoft DNS server podepíše sadu DNSKEY záznamů také soukromým klíčem aktivního ZSK. Z mého pochopení DNSSEC bych myslel, že to se dít nemá. Ale možná informace, že všechny sady záznamů v zóně se podepisují pomocí ZSK, znamená i DNSKEY. Naopak bych čekal, že bude DNSKEY podepsáno i pomocí záložního KSK. Když se pro výměnu klíčů má použít metoda dvojitého podpisu.

Zkoušel jsem dotazy na různé podepsané domény v internetu. Většina z nich má zveřejněn jeden KSK a jeden ZSK, a pouze jeden podpis DNSKEY setu pomocí KSK. Některé domény mají podepsáno i pomocí ZSK.

Informace o DNSSEC nastavení zóny si můžeme vypsat také pomocí PowerShellu.

Get-DnsServerDnsSecZoneSetting -ZoneName firma.cz 

Zveřejnění DS záznamů v registru domény .cz

Pro vytvoření DS záznamů v TLD doméně (registru) musíme využít svého registrátora. V registru pro doménu CZ se DS záznamy generují automaticky z údajů o podpisovém klíči. Je nutné vytvořit KEYSET (sadu klíčů), do něj vložit kompletní údaje DNSKEY záznamu, a připojit jej ke své doméně. Jak to funguje u registrátora Active24 popisují v DNS Security (DNSSEC).

Reálný průběh vytvoření DS záznamu

• na DNS serveru si otevřeme soubor %windir%\system32\dns\keyset-<zone.name> (třeba C:\Windows\System32\dns\keyset-firma.cz), kde máme všechny potřebné údaje (pro všechny klíče) pro vytvoření KEYSETu
• ve webovém systému registrátora (změny v registru) vytvoříme nový KEYSET pro .CZ doménu
• musíme zadat unikátní jméno (ID KEYSETu), technický kontakt, Flag 257 (KSK), algoritmus, protokol 3 (DNSSEC) a veřejný KSK klíč
• do jednoho KEYSETu můžeme zadat více klíčů (v případě Microsoft DNS zadáváme dva)
• po chvíli přijde mailem potvrzení z CZ.NIC, že byl KEYSET vytvořen
• ve webovém systému registrátora (změny v registru) zadáme změnu na doméně, kde přiřadíme KEYSET k doméně, operaci musí potvrdit držitel nebo admin (odkaz v emailu)
• po krátkém čase (15 minut) přijde potvrzení z CZ.NIC, že došlo ke změně na doméně
• když v registru vyhledáme doménu (https://www.nic.cz), tak bychom měli vidět, že je zabezpečena pomocí DNSSEC, a také přiřazenou sadu klíčů (a jejich údaje)

Automatická výměna klíčů (Automatic Key Rollover)

Výměna klíčů je důležitá a musí proběhnout správně, aby nám nepřestala doména fungovat. Provádět ji manuálně je značně náročné, proto je lepší využít Automatic Rollover. Bezpečnější je, automatickou výměnu KSK klíčů, provádět pomocí RFC 5011 (na to se zde zaměřujeme). Výměna ZSK probíhá plně automaticky, ale při výměně KSK musíme ručně upravit údaje u CZ.NIC.

Pokud zapneme automatickou výměnu klíčů s RFC 5011, tak se hned při podepsání zóny vygeneruje další podepisovací klíč ke každému ZSK a KSK. Máme pak vždy aktivní klíč (Active key). A u KSK máme ještě záložní klíč (Standby key), u ZSK vznikne následující klíč (Next key).

Pro KSK je podporována metoda dvojitého podpisu (double signature rollover method), pro ZSK předpublikace (pre-publish rollover method).

• Double Signature - budoucí klíč a podpisy, které jsou vygenerovány pomocí něj, jsou publikovány v DNS zóně před odstraněním existujícího klíče a jeho podpisů, v zóně se nachází vždy dvě sady klíčů a souvisejících podpisů, při výměně klíčů z něj uděláme aktivní, starý odstraníme včetně podpisů, přidáme nový záložní klíč a podpisy
• Pre-Publication - budoucí klíč je přidán pro budoucí použití a publikován v DNS zóně bez generování jakýchkoli podpisů, takže se jeho záznam rozdistribuuje, při výměně klíčů z něj uděláme aktivní a podepíšeme s ním záznamy v zóně, připravíme nový záložní klíč

Bohužel jsem nikde nenašel přesný popis, jak automatická výměna klíčů probíhá. Zkusil jsem to vypozorovat z praxe a níže popsat. Při zapnutém RFC 5011 by se měl využívat popis v RFC 5011 Key Roll-Over. Pro získání přehledu, jak výměna klíčů probíhá, nejvíce pomůže log událostí. Na konci článku jsou vypsané události při různých operacích.

Informace o výměně klíčů

Pomocí PowerShellu si můžeme vypsat seznam podepisovacích klíčů (nebo určitého klíče) pro určitou zónu. K tomu se zobrazují různé údaje, včetně stavu a dalších parametrů výměny klíčů.

Get-DnsServerSigningKey -ZoneName firma.cz
Get-DnsServerSigningKey -ZoneName firma.cz -KeyId d7a93f55-31b9-46a7-8057-f7cf3625f7de | FL *
Get-DnsServerSigningKey -ZoneName firma.cz | FT KeyType, CurrentState, CurrentRolloverStatus, NextRolloverAction, NextRolloverTime, LastRolloverTime, RolloverType

PS C:\> Get-DnsServerSigningKey -ZoneName firma.cz | FT KeyType, CurrentState, CurrentRolloverStatus, NextRolloverAction, NextRolloverTime, LastRolloverTime, RolloverType

KeyType        CurrentState CurrentRolloverStatus           NextRolloverAction NextRolloverTime    LastRolloverTime RolloverType
-------        ------------ ---------------------           ------------------ ----------------    ---------------- ------------
KeySigningKey  Active       WaitingForRFC5011RemoveHoldDown Normal             3/9/2022 5:21:32 PM                  DoubleSignature
ZoneSigningKey Active       Queued                          Normal             2/1/2022 7:55:30 AM                  PrePublish

Stav výměny

Důležitý je stav výměny klíče (CurrentRolloverStatus). Bohužel jsem opět nenašel žádné vysvětlivky, pouze seznam možných hodnot (a řekl bych asi s chybami).

• NotRolling
• Queued     
• RollStarted
• ZskWaitingForDnsKeyTtl
• ZskWaitingForMaxZoneTtl
• KskWaitingForDSUpdate
• KskWaitingForDSTtl
• KskWaitingForDnsKeyTtl
• WaitingForRFC5011RemoveHoldDown
• RollError

Než uplyne čas k výměně klíče, tak je stav NotRolling.

Když se obnovuje ZSK, tak DNS server čeká minimálně 1 hodinu (3600 vteřin), aby kešovaným záznamům umožnil vypršení platnosti. Pokud je DNSKEY TTL, nebo maximální TTL použité na jiném záznamu v zóně, delší než hodina, tak se čeká déle (ZskWaitingForDnsKeyTtl, ZskWaitingForMaxZoneTtl).

Když se obnovuje KSK, tak DNS server čeká na aktualizaci DS záznamu v nadřazené zóně (ten v pravidelném intervalu kontroluje). Stav se zobrazuje KskWaitingForDSUpdate. Můžeme ručně posunout do dalšího kroku (pokud třeba server nemůže ověřit DS záznam) pomocí cmdletu Step-DnsServerSigningKeyrollover. Pak se proces dostává do stavu WaitingForRFC5011RemoveHoldDown, podle RFC 5011 je to 30 dní.

Průběh výměny KSK klíčů (RFC 5011) a změna DS záznamů v registru domény .cz

• máme Active key a Standby key, když nastane čas výměny klíče (vidíme jako NextRolloverTime), tak se vygeneruje nový KSK jako Next key
• vytvoří jeho DNSKEY záznam, stav se přepne na RollStarted

• pak se čeká až bude v nadřazené zóně vytvořen odpovídající DS záznam pro nový klíč, stav KskWaitingForDSUpdate
• ve webovém systému registrátora (změny v registru) zadáme editaci KEYSETu pro .CZ doménu, kde přidáme nový klíč, který opět nalezneme v souboru %windir%\system32\dns\keyset-<zone.name>, změnu musíme potvrdit (odkaz v emailu)
• za pár minut přijde mailem potvrzení z CZ.NIC, že byl KEYSET změněn
• když DNS server ověří, že existuje správný záznam, tak se přepne do stavu KskWaitingForDSTtl
• po vypršení času (standardně 1 hodina) se přepne do WaitingForRFC5011RemoveHoldDown
• někdy v této době se vytvoří nový podpis sady DNSKEY záznamů pomocí záložního KSK (Standy key) a u DNSKEY záznamu s aktivním KSK (Active key) se změní příznak (z 257) na 385 (přidá se bit Revoke), tím se také změní jeho Key Tag

• nyní běží Hold-Down Time, původně aktivní klíč (Active key) je odvolaný (Revoke), záložní (Standy key) se stává aktivním, následující klíč (Next key) bude záložním po uplynutí času
• po uplynutí Hold-Down Time, standardně 30 dní, se odstraní nejstarší klíč (původně aktivní - Active key) a jeho DNSKEY záznam (a také podpis pomocí něj), záložní (Standy key) se stává aktivním (Active key), následující klíč (Next key) stává záložním (Standy key)
• odstraníme klíč z KEYSETu u CZ.NIC (tedy starý DS záznam)

Pozn.: Není mi jasné, jaký smysl má ponechat DS záznam pro starý klíč po dobu Hold-Down Time. Jelikož se na DNSKEY záznamu změnil příznak, tak již hash v DS záznamu neodpovídá tomuto DNSKEY.

Průběh výměny ZSK klíčů

• máme Active key a Next key, když nastane čas výměny klíčů (vidíme jako NextRolloverTime), tak se vygeneruje nový klíč
• z Active key se stane Standby key, z Next key se stane Active key, a jako Next key se nastaví nový klíč
• nově se podepíše sada DNSKEY záznamů pomocí Active key
• čeká se max Zone TTL
• vytvoří se DNSKEY záznam pro nový klíč (Next key) a odstraní se nejstarší DNSKEY záznam (Standby key)
• Standby key se smaže, takže máme opět Active key a Next key

Logované události při různých situacích

Zajímavé informace můžeme najít v logu událostí (Event Log) DNS Serveru. Ten nalezneme v Event Viewer - Applications and Services Logs - DNS Server. Opět jsem nenašel žádný popis, ani seznam možných události. Takže níže jsou zapsané události z praktických situací při testech.

Podepsání zóny

• 25.1. 7:55:30 7650 The DNS server has started signing the zone firma.cz.
• 25.1. 7:55:30 7675 The DNS server has started signing the scope Default of zone firma.cz.
• 25.1. 7:55:30 7676 The scope Default of zone firma.cz is signed with DNSSEC. The server will give DNSSEC compliant responses to DNSSEC queries for this scope.
• 25.1. 7:55:30 7646 The zone firma.cz is now signed with DNSSEC.

Odpodepsání zóny

• 20.1. 14:01:38 776 The DNS server has started to unsign the zone firma.cz on server dns1.
• 20.1. 14:01:38 7675 The DNS server has started signing the scope Default of zone firma.cz.
• 20.1. 14:01:38 7678 The scope Default of zone firma.cz is no longer signed with DNSSEC. The server will not provide DNSSEC compliant responses to DNSSEC queries for this scope.
• 20.1. 14:01:38 7647 The zone firma.cz is no longer signed with DNSSEC.

Výměna KSK klíčů s RFC 5011

• 31.1. 15:07:25 7667 Keys for the Signing Key Descriptor {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} in zone firma.cz will be rolled over in less than 1 day.
• 1.2. 7:55:29 784 The key signing key with GUID {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} of zone firma.cz has moved to stage DNS_SKD_STATUS_ROLL_STARTED of rollover.
• 1.2. 7:55:29 7669 Keys for the Signing Key Descriptor {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} in zone firma.cz are starting the rollover process.
• 1.2. 7:55:29 784 The key signing key with GUID {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} of zone firma.cz has moved to stage DNS_SKD_STATUS_KSK_WAITING_FOR_DS_UPDATE of rollover.
• každou minutu se loguje ta samá událost 784
• 7.2. 15:51 upraven KEYSET u CZ.NIC (vytvořen nový DS záznam)
• 7.2. 16:21:32 784 The key signing key with GUID {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} of zone firma.cz has moved to stage DNS_SKD_STATUS_KSK_WAITING_FOR_DS_TTL of rollover.
• 7.2. 17:21:32 784 The key signing key with GUID {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} of zone firma.cz has moved to stage DNS_SKD_STATUS_KSK_WAITING_FOR_5011_REMOVE_HOLD_DOWN of rollover.
• 9.3. 17:21:31 784 The key signing key with GUID {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} of zone firma.cz has moved to stage DNS_SKD_STATUS_ROLL_ERROR of rollover.
• 9.3. 17:21:31 7670 The rollover process for Signing Key Descriptor {D7A93F69-31B9-46A7-8057-F7CF3625F7DE} in zone firma.cz is complete.

Výměna KSK klíčů bez RFC 5011

• 22.2. 21:22:52 7667 Keys for the Signing Key Descriptor {FE806F2E-93CC-44F4-BA50-0B445582B7BB} in zone firma.cz will be rolled over in less than 1 day.
• 23.2. 14:10:59 784 The key signing key with GUID {FE806F2E-93CC-44F4-BA50-0B445582B7BB} of zone firma.cz has moved to stage DNS_SKD_STATUS_ROLL_STARTED of rollover.
• 23.2. 14:10:59 7669 Keys for the Signing Key Descriptor {FE806F2E-93CC-44F4-BA50-0B445582B7BB} in zone firma.cz are starting the rollover process.
• 23.2. 14:10:59 784 The key signing key with GUID {FE806F2E-93CC-44F4-BA50-0B445582B7BB} of zone firma.cz has moved to stage DNS_SKD_STATUS_KSK_WAITING_FOR_DS_UPDATE of rollover.
• 23.2. 14:11:59 784 The key signing key with GUID {FE806F2E-93CC-44F4-BA50-0B445582B7BB} of zone firma.cz has moved to stage DNS_SKD_STATUS_KSK_WAITING_FOR_DNSKEY_TTL of rollover.
• 23.2. 15:11:59 784 The key signing key with GUID {FE806F2E-93CC-44F4-BA50-0B445582B7BB} of zone firma.cz has moved to stage DNS_SKD_STATUS_ROLL_ERROR of rollover.
• 23.2. 15:11:59 7670 The rollover process for Signing Key Descriptor {FE806F2E-93CC-44F4-BA50-0B445582B7BB} in zone firma.cz is complete.

Výměna ZSK klíčů

• 18.2. 19:10:02 785 The zone signing key with GUID {A47164FC-8C89-4F92-9EBA-8F1A54050BC2} of zone firma.cz has moved to stage DNS_SKD_STATUS_QUEUED of rollover.
• 18.2. 19:10:02 785 The zone signing key with GUID {A47164FC-8C89-4F92-9EBA-8F1A54050BC2} of zone firma.cz has moved to stage DNS_SKD_STATUS_ROLL_STARTED of rollover.
• 18.2. 19:10:02 7669 Keys for the Signing Key Descriptor {A47164FC-8C89-4F92-9EBA-8F1A54050BC2} in zone firma.cz are starting the rollover process.
• 18.2. 19:10:02 785 The zone signing key with GUID {A47164FC-8C89-4F92-9EBA-8F1A54050BC2} of zone firma.cz has moved to stage DNS_SKD_STATUS_ZSK_WAITING_FOR_DNSKEY_TTL of rollover.
• 18.2. 19:10:02 785 The zone signing key with GUID {A47164FC-8C89-4F92-9EBA-8F1A54050BC2} of zone firma.cz has moved to stage DNS_SKD_STATUS_ZSK_WAITING_FOR_MAXZONE_TTL of rollover.
• 20.2. 20:10:01 785 The zone signing key with GUID {A47164FC-8C89-4F92-9EBA-8F1A54050BC2} of zone firma.cz has moved to stage DNS_SKD_STATUS_ROLL_ERROR of rollover.
• 20.2. 20:10:01 7670 The rollover process for Signing Key Descriptor {A47164FC-8C89-4F92-9EBA-8F1A54050BC2} in zone firma.cz is complete.