Ověřování a zabezpečení odpovědí DNS pomocí DNSSEC

Záznamy prostředků DNSSEC slouží k ověřování a zabezpečení odpovědí DNS. Zóny DNS jsou zabezpečené pomocí DNSSEC prostřednictvím podepisování zón. Podepisování zóny přidává podporu ověřování beze změny základního mechanismu dotazu a odpovědi DNS. Úvod služby DNSSEC pro server DNS ve Windows Serveru najdete v tématu Přehled služby DNSSEC.

Digitální podpisy jsou součástí odpovědí DNS za účelem ověření. Tyto digitální podpisy jsou obsaženy v záznamech prostředků souvisejících se službou DNSSEC, které se generují a přidají do zóny během podepisování zóny.

Rekurzivní DNS

Když rekurzivní nebo předávací server DNS s podporou DNSSEC přijme dotaz z klienta DNS pro zónu podepsanou službou DNSSEC, požádá autoritativní server DNS o odeslání záznamů DNSSEC k ověření odpovědi DNS. Rekurzivní nebo předávací server DNS rozpozná, že zóna podporuje DNSSEC, pokud má DNSKEY, označovanou také jako kotva důvěryhodnosti pro danou zónu.

Important

Neautoritativní server DNS může k překladu dotazu DNS použít rekurz nebo přeposílání. Toto téma se týká neautoritativního serveru jako rekurzivního serveru DNS; pokud server používá předávání, proces použitý k ověření DNSSEC odpovědí DNS je stejný.

DNSKEY

Rekurzivní server DNS používá záznam prostředku DNSKEY k ověření odpovědí z autoritativního serveru DNS. Aby bylo možné ověřit odpovědi, server DNS dešifruje digitální podpisy obsažené v záznamech prostředků souvisejících se službou DNSSEC a porovná hodnoty hash. Pokud jsou hodnoty hash identické, poskytne DNS klientovi odpověď s požadovanými daty DNS, například záznam prostředku hostitele (A). Pokud hodnoty hash neodpovídají, odpoví zprávou SERVFAIL . Tímto způsobem řešící DNS server podporující DNSSEC s nainstalovanou platnou důvěryhodnou kotvou chrání před útoky na falšování DNS, ať už jsou DNS klienti obeznámeni s DNSSEC nebo ne.

Pokud váš klient podporuje DNSSEC, je možné ho nakonfigurovat tak, aby server DNS vyžadoval provedení ověření DNSSEC.

Následující obrázek znázorňuje proces ověření.

DNSKEY se používají k výpočtu hodnot hash a dešifrování záznamů RRSIG. Na obrázku se nezobrazují všechny provedené ověřovací procesy. Provede se také další ověření, aby byly záznamy DNSKEY platné a že také DS záznamy jsou platné, pokud existují (nezobrazují se na snímku obrazovky).

Proces dotazů a odpovědí DNS

Jednoduchý příklad ukazuje, jak můžete začlenit DNSSEC do procesu dotazu a odpovědi DNS za účelem zajištění ověření.

V následujícím příkladu klientský počítač DNS dotazuje rekurzivní server DNS (ukládání do mezipaměti), který pak před vrácením odpovědi dotazuje autoritativní servery DNS. Tento příklad předpokládá, že data DNS ještě nejsou uložená v mezipaměti na klientovi nebo serveru. Data DNSSEC ověřují odpovědi DNS jako originální pouze v případě, že je zóna podepsaná a používáte servery a klienty podporující DNSSEC.

Následující obrázek znázorňuje rekurzivní proces dotazu DNS.

Následující tabulka ukazuje kroky v dotazu a odpovědi DNS s volitelnými daty DNSSEC.

Step	Query-response	Volitelná data DNSSEC
1	Klient DNS odešle dotaz DNS na rekurzivní server DNS.	Klient DNS může indikovat, že podporuje DNSSEC (DO=1).
2	Rekurzivní server DNS odešle dotaz DNS na kořenové servery DNS a servery TLD (Top-Level Domain).	Rekurzivní server DNS může indikovat, že podporuje DNSSEC (DO=1).
3	Kořenové servery a servery TLD vrátí odpověď DNS na rekurzivní server DNS poskytující IP adresu autoritativního serveru DNS pro zónu.	Autoritativní servery nadřazené zóny mohou indikovat, že podřízená zóna je podepsaná pomocí DNSSEC a obsahuje zabezpečenou delegaci (DS záznam).
4	Rekurzivní server DNS odešle dotaz DNS autoritativnímu serveru DNS pro zónu.	Rekurzivní server DNS může naznačit, že rozumí DNSSEC (DO=1) a je schopen ověřovat podepsané záznamy prostředků (CD=1), které mají být odeslané v odpovědi.
5	Autoritativní server DNS vrátí odpověď DNS rekurzivnímu serveru DNS, poskytujícímu data záznamu prostředku.	Autoritativní server DNS může obsahovat podpisy DNSSEC ve formě záznamů RRSIG v odpovědi DNS pro použití při ověřování.
6	Rekurzivní server DNS vrátí odpověď DNS klientovi, poskytující data záznamu prostředku.	Rekurzivní server DNS může označit, jestli byla odpověď DNS ověřena (AD=1) pomocí služby DNSSEC.

Zahrnutí dat DNSSEC

Příznaky (bity) související s DNSSEC se používají v dotazu DNS a odpovědi k určení, jestli jsou zahrnutá data DNSSEC, a ověření bylo provedeno. Tyto příznaky jsou nastaveny zapnutím nebo vypnutím rozšířených datových bitů v hlavičce paketu DNS. Když jsou tyto příznaky zapnuté, říká se, že je bit "nastaven" (hodnota je nastavena na 1). Vypnutí příznaku se označuje jako "vymazání" bitu (hodnota je nastavená na 0).

• DO: Bit DO je součástí dotazu DNS a je zkratkou pro DNSSEC OK. Pokud je bit DO nastavený (DO=1), klient je si vědom DNSSEC a je bezpečné, aby server DNS v odpovědi vrátil data DNSSEC. Pokud bit DO není nastavený (DO=0), klient nebude znát dnsSEC a server DNS nemůže do odpovědi DNS zahrnout žádná data DNSSEC. Klienti DNS můžou být stále chráněni pomocí DNSSEC, i když si nejsou vědomi DNSSEC. V tomto kontextu je klient DNS libovolný počítač, který odesílá dotaz DNS. Když rekurzivní server DNS odešle dotaz na autoritativní server DNS, musí dát najevo, že podporuje DNSSEC, aby autoritativní server DNS poslal data DNSSEC v odpovědi.
• AD: Bit AD je součástí odpovědi DNS a je zkratkou pro "ověřená data". Pokud je bit AD nastavený (AD=1), znamená to, že odpověď DNS je autentická, protože byla ověřena pomocí DNSSEC. Nevalidující počítač s podporou DNSSEC, například počítač se systémem Windows 8, neprovádí ověřování DNSSEC, ale může být nakonfigurován tak, aby vyžadovalo, aby odpovědi DNS byly autentické. Pokud není bit AD nastavený (AD=0), odpověď DNS se neověřila. Bit AD nemusí být nastavený, protože se nepokoušelo ověření nebo kvůli selhání ověření.
• CD: Bit CD je součástí dotazu DNS a je zkratkou pro "kontrola zakázána". Pokud je bit CD nastavený (CD=1) v dotazu, znamená to, že by měla být odeslána odpověď DNS bez ohledu na to, jestli bylo úspěšně provedeno ověření. Pokud není bit CD nastavený (CD=0), odpověď DNS se neodesílá, pokud bylo požadováno ověření a to selhalo. Pokud je bit CD jasný (CD=0), znamená to "povolena kontrola" a může dojít k ověření DNSSEC. Bit CD může být nastavený (CD=1) v dotazu, protože hostitel může provádět ověřování DNSSEC a nevyžaduje upstreamové ověření, například rekurzivní server DNS se systémem Windows Server 2012 nebo novějším. Nevalidující stub resolver, například počítač s klientem DNS systému Windows, vydává dotazy s bitem CD vypnutým CD=0. Další informace najdete v RFC4035 oddílu 3.2.2.

Čtvrtým důležitým příznakem (bit), který může být v hlavičce paketu DNS, je bit AA. Tento příznak není u DNSSEC nový, ale dá se použít při nasazení DNSSEC:

• AA: Bit AA je součástí odpovědi DNS a je zkratkou pro "autoritativní odpověď". Pokud je bit AA nastavený, znamená to, že odpověď DNS je autentická, protože pochází přímo z autoritativního serveru DNS. Klient, který vyžaduje ověření DNSSEC (AD=1) místo toho přijímá bit AA (AA=1, AD=0). Pokud klient přímo dotazuje autoritativní server, protože autoritativní odpovědi nemusí být ověřeny. Bylo by zbytečné, aby autoritativní server ověřoval svou vlastní odpověď.

Příklady dotazů DNS

Následující příklady zobrazují výsledky dotazu DNS prováděné z klientského počítače DNS se systémem Windows 8.1 pomocí rutiny Resolve-DnsName . Rutina Resolve-DnsName byla zavedena ve Windows Serveru 2012 a Windows 8 a dá se použít k zobrazení dotazů DNS, které obsahují data DNSSEC.

Important

K otestování podpory DNSSEC pro zónu nepoužívejte nástroj příkazového nslookup.exe řádku. Nástroj nslookup.exe používá interního klienta DNS, který není s podporou DNSSEC.

Příklad 1: V následujícím příkladu se dotaz odešle na rekurzivní server DNS pro záznam adresy (A) v podepsané zóně secure.contoso.com s DO=0.

Resolve-DnsName finance.secure.contoso.com –type A -server dns1.contoso.com

Name Type TTL Section IPAddress

---- ---- --- ------- ---------

finance.secure.contoso.com A 2848 Answer 192.168.0.200

Bit DO není nastavený, protože parametr dnssecok nebyl zahrnut.

Příklad 2: V následujícím příkladu DO=1 je příznak nastaven přidáním parametru dnssecok .

Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com -dnssecok

Name Type TTL Section IPAddress

---- ---- --- ------- ---------

finance.secure.contoso.com A 2848 Answer 192.168.0.200

Name : finance.secure.contoso.com

QueryType : RRSIG

TTL : 2848

Section : Answer

TypeCovered : A

Algorithm : 8

LabelCount : 4

OriginalTtl : 3600

Expiration : 10/18/2013 8:23:41 PM

Signed : 10/8/2013 7:23:41 PM

Signer : secure.contoso.com

Signature : {86, 229, 217, 39...}

Name : .

QueryType : OPT

TTL : 32768

Section : Additional

Data : {}

Pokud DO=0, server DNS v odpovědi DNS neodesílá data DNSSEC. Když DO=1klient indikuje, že může přijímat data DNSSEC, pokud je k dispozici. Vzhledem k tomu, že zóna secure.contoso.com je podepsaná, je záznam RRSIG zahrnut do odpovědi DNS v okamžiku, když DO=1.

V obou příkladech 1 i 2 se pro zónu secure.contoso.com nevyžaduje ověření, protože tabulka zásad překladu jmen (NRPT) není nakonfigurovaná tak, aby vyžadovala ověření.

K zobrazení aktuálních pravidel NRPT můžete použít rutinu Get-DnsClientNrptPolicy . Další informace naleznete v tématu Get-DnsClientNrptPolicy.

Příklad 3: V následujícím příkladu se zobrazí pravidlo NRPT pro secure.contoso.com.

Get-DnsClientNrptPolicy

Namespace : .secure.contoso.com

QueryPolicy :

SecureNameQueryFallback :

DirectAccessIPsecCARestriction :

DirectAccessProxyName :

DirectAccessDnsServers :

DirectAccessEnabled :

DirectAccessProxyType : NoProxy

DirectAccessQueryIPsecEncryption :

DirectAccessQueryIPsecRequired : False

NameServers :

DnsSecIPsecCARestriction :

DnsSecQueryIPsecEncryption :

DnsSecQueryIPsecRequired : False

DnsSecValidationRequired : False

NameEncoding : Utf8WithoutMapping

V tomto příkladu je hodnota DnsSecValidationRequiredfalse. Pokud je hodnota false, ověření DNSSEC se nevyžaduje.

Příklad 4: S povoleným secure.contoso.comověřováním DNSSEC zobrazí NRPT hodnotu True pro DnsSecValidationRequired. Tento příklad zobrazuje pouze obor názvů secure.contoso.com a parametr DnsSecValidationRequired.

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

True

Pokud je hodnota DnsSecValidationRequiredtrue , klientské počítače pracující s DNSSEC vždy odesílají dotazy, DO=1i když parametr dnssecok není zahrnutý.

Příklad 5: Pokud se v tabulce zásad překladu ip adres (NRPT) vyžaduje ověření DNSSEC, je bit DNSSEC OK automaticky nastaven (DO=1) pro klienty pracující s protokolem DNSSEC.

Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com

Name Type TTL Section IPAddress

---- ---- --- ------- ---------

finance.secure.contoso.com A 2848 Answer 192.168.0.200

Name : finance.secure.contoso.com

QueryType : RRSIG

TTL : 2848

Section : Answer

TypeCovered : A

Algorithm : 8

LabelCount : 4

OriginalTtl : 3600

Expiration : 10/18/2013 8:23:41 PM

Signed : 10/8/2013 7:23:41 PM

Signer : secure.contoso.com

Signature : {86, 229, 217, 39...}

Name : .

QueryType : OPT

TTL : 32768

Section : Additional

Data : {}

V tomto příkladu se odešle záznam RRSIG v odpovědi DNS, aby splnil požadavky na ověření pro secure.contoso.com. Platné ukotvení důvěryhodnosti je také nakonfigurováno na rekurzivním serveru dns1.contoso.comDNS .

Pokud klient není DNSSEC-aware, pravidlo NRPT se nepoužije a dotazy jsou zasílány s DO=0, i když existuje pravidlo NRPT, které vyžaduje ověření DNSSEC.

Příklad 6: V následujícím příkladu se stejný dotaz provádí jako v příkladu 5, ale bez platného ukotvení důvěryhodnosti nakonfigurovaného na dns1.contoso.com.

Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.com

Resolve-DnsName : finance.secure.contoso.com : Unsecured DNS packet

At line:1 char:1

+ Resolve-DnsName -name finance.secure.contoso.com -type A -server dns1.contoso.co ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : ResourceUnavailable: (finance.secure.contoso.com:String) [Resolve-DnsName], Win32Excepti

on

+ FullyQualifiedErrorId : DNS\_ERROR\_UNSECURE\_PACKET,Microsoft.DnsClient.Commands.ResolveDnsName

V tomto příkladu rozlišení DNS selže s hlášením DNS_ERROR_UNSECURE_PACKET. Ověření neproběhne, protože je vyžadováno v NRPT, ale nelze jej provést kvůli nedostatku platného důvěryhodného kotevního bodu pro zónu secure.contoso.com. Rutina Resolve-DnsName hlásí podrobné výsledky pro typ chyby, ke které došlo. Pokud se klient DNS pokusí přeložit finance.secure.contoso.com aby se mohl připojit k tomuto hostu, selže.

Scénáře DNSSEC

DNSSEC je možné nasadit v mnoha různých prostředích s jedinečným nastavením serveru a klienta. Je důležité pochopit, jak jsou ovlivněné dotazy a odpovědi DNS.

Vezměte v úvahu následující čtyři příkazy související se službou DNSSEC. Každý příkaz má vliv na fungování DNSSEC v daném scénáři:

• Záznam finance.secure.contoso.com prostředku je správně podepsaný pomocí DNSSEC.
• Rekurzivní server DNS dokáže ověřovat odpovědi na dotaz pro finance.secure.contoso.com.
• Klient DNS je s podporou DNSSEC.
• Klient DNS je nakonfigurovaný tak, aby vyžadoval ověření pro všechny dotazy v secure.contoso.com oboru názvů.

Pojďme se na každý z těchto čtyř tvrzení podívat podrobněji.

1. Stav podepisování DNSSEC: DNSSEC podepíše všechny záznamy v zóně, tato podmínka označuje stav secure.contoso.com zóny, nejen finance.secure.contoso.com záznam prostředku. Nemůžete podepsat některé záznamy a nepodepsat jiné. Proto stav DNSSEC finance.secure.contoso.com závisí na stavu DNSSEC secure.contoso.com.

   • Správně podepsáno: Zóna secure.contoso.com může být podepsána platným způsobem, což umožňuje finance.secure.contoso.com ověřit jako originální. Aby byla zóna platná, musí být podepsaná platnými, nevyexpirovanými klíči a musí existovat všechny požadované záznamy prostředků související se službou DNSSEC.

   • Není podepsáno: Zóna secure.contoso.com nemusí být podepsaná, v takovém případě neexistuje žádný záznam RRSIG přidružený finance.secure.contoso.coma odpovědi DNS na dotazy finance.secure.contoso.com nelze ověřit. Pokud klient vyžaduje ověření, dotaz DNS, který se odešle na rekurzivní server DNS, selže, protože klient DNS nepřijímá nedůvěryhodnou odpověď. Pokud klient přímo dotazuje autoritativní server, ověření se nezdaří, protože odpověď je již považována za autentickou.

   • Není správně podepsáno: Zóna secure.contoso.com může být podepsaná, ale není platná. Platnost jednoho nebo několika podpisových klíčů DNSSEC může například vypršena. Po počátečním podepsání zóny musí být zóna pravidelně znovu podepsána novými klíči před vypršením doby platnosti podpisového klíče, aby se zachoval zabezpečený provozní stav DNSSEC. Doba platnosti podpisových klíčů DNSSEC by měla být dostatečně krátká, aby se zachovalo zabezpečení, ale dostatečně dlouho, aby bylo možné snadnou správu. DNSSEC ve Windows Serveru 2012 a Windows Serveru 2012 R2 podporuje automatické převrácení klíčů, což zajišťuje zabezpečení a snadnou správu zón podepsaných dnsSEC.

2. Stav ověření: Rekurzivní server DNS s platným ukotvením důvěryhodnosti (veřejný kryptografický klíč) pro zónu secure.contoso.com může ověřit odpověď DNS pro finance.secure.contoso.com záznam prostředku. Rekurzivní server DNS musí také podporovat standardy a algoritmy DNSSEC, které se používají k podepsání zóny.

   • Může ověřit: Pokud rekurzivní server DNS podporuje všechny kryptografické algoritmy používané k podepsání secure.contoso.com zóny a má platnou kotvu důvěryhodnosti, kterou může použít k dešifrování podpisu DNSSEC přidruženého k podepsanému záznamu prostředku, může záznam prostředku ověřit finance.secure.contoso.com jako pravý.

   • Nelze ověřit: Server DNS, který nezná DNSSEC, není schopen ověření. Podobně server DNS, který momentálně nemá platnou kotvu důvěryhodnosti pro zónu secure.contoso.com, nemůže ověřit odpověď DNS pro finance.secure.contoso.com. Kotvy důvěry musí být aktualizovány při znovu podepsání zóny, například při změně klíče. DNSSEC ve Windows Serveru 2012 a Windows Serveru 2012 R2 podporuje automatickou aktualizaci důvěryhodných ukotvení při obnově klíče podle RFC 5011, "Automatizované aktualizace ukotvení zabezpečení DNS (DNSSEC)".

3. Stav DNSSEC-ovědomí: Stav DNSSEC-ovědomého klienta DNS závisí na operačním systému, na němž je spuštěn. Služba Klienta DNS Windows ve Windows 7 nebo Windows Serveru 2008 R2 a novějších operačních systémech je zástupný překladač s podporou DNSSEC, který neprovádí validaci. Předchozí operační systémy Windows jsou bez DNSSEC. Klient DNS informuje server DNS, zda je při odesílání dotazu DNS obeznámen s DNSSEC nebo ne.

   • Klient i server jsou s podporou DNSSEC: Pokud klient i server používají dnsSEC, pak odpověď DNS ze serveru na klienta zahrnuje příznak DNSSEC ověřených dat (AD). Pokud se odpověď DNS ověří pomocí DNSSEC, odešle se AD=1. Pokud nebyla ověřena odpověď DNS, je pomocí AD=0 odesláno.

   • Server DNS nemá informace o službě DNSSEC: Pokud server DNS nezná dnsSEC, neprovádí se žádné ověření a příznak AD není nastavený (AD=0) bez ohledu na to, jestli je klient DNSSEC nebo ne.

   • Klient DNS nezná službu DNSSEC: Pokud klient DNS nezná službu DNSSEC, server DNS v odpovědi na klienta nenastaví příznak SLUŽBY AD, i když rozumí službě DNSSEC. Pokud je však server DNS s podporou DNSSEC a má pro zónu kotvu důvěryhodnosti, server se pokusí ověřit odpověď autoritativního serveru. Pokud se ověření nezdaří, vrátí klientovi DNS selhání serveru DNS. Pokud ověření proběhne úspěšně, vrátí klientovi výsledky dotazu. Tímto způsobem může rekurzivní server DNS, který podporuje DNSSEC, chránit klienty DNS, kteří nejsou obeznámeni s DNSSEC. Pokud v tomto scénáři není zóna podepsaná, nepokusí se žádné ověření a odpověď se klientovi vrátí normálně.

4. Požadavek na ověření: Toto nastavení určuje požadavek klienta DNSSEC pracujícího s DNSSEC pro data DNSSEC (příznak AD) v odpovědi ze serveru DNS. Aby klient DNS vyžadoval ověření, musí být kompatibilní s DNSSEC. Klienti DNS bez DNSSEC není možné vynutit, aby vyžadovali ověření DNSSEC. Pokud klient DNS přímo dotazuje autoritativní server DNS, odpověď se ověří, i když zóna není podepsaná. Důvodem je to, že autoritativní servery DNS vždy vrací autentické odpovědi.

   • Je vyžadováno ověření: Pokud je požadováno ověření, klient musí přijmout AD=1 (ověření bylo úspěšné) nebo odmítne odpověď DNS. Pokud bylo ověření neúspěšné nebo se o něj nepokusilo (AD=0), rozlišení DNS selže. To platí i tehdy, pokud zóna není podepsaná. To platí jenom pro dotazy na rekurzivní, neautoritativní server DNS.

   • Ověření není povinné: Pokud ověření není povinné, klient přijme odpověď z rekurzivního DNS serveru bez povědomí o DNSSEC. Pokud je ale rekurzivní server DNS s podporou DNSSEC a ověření selže, vrátí klientovi chybu serveru, i když klient nevyžaduje ověření.

Další kroky

Tady je několik článků, ve které najdete další informace o SLUŽBě DNSSEC pro server DNS.

• DNSSEC ve Windows Serveru
• DNSSEC v klientovi DNS systému Windows
• Podepsání zóny DNS
• Typy ukotvení důvěryhodnosti
• Představujeme tabulku zásad rozlišení názvů (NRPT)