Jak funguje DNSSEC?

Dnes již klasickým způsobem, jak ověřit pravost informací, je digitální podpis. Každý z nás se s digitálním podpisem v nějaké formě na internetu již setkal, ať už se jednalo o přístup na zabezpečené stránky přes HTTPS, digitální podpis v emailu přes X.509 certifikáty nebo OpenPGP. DNSSEC přináší digitální podpis do světa DNS. Důležité je si uvědomit, že rozšíření DNSSEC bylo navrhováno s ohledem na maximální zpětnou kompatibilitu.

DNSSEC klíč

Základním RR typem, o který DNSSEC rozšířil protokol DNS, je DNSKEY. Záznam DNSKEY může vypadat například takto:

dnssec.cz.      600 IN DNSKEY 257 3 5 (
                AwEAAc4x/KbNECb+dpDDBSvyxfTlvUxXyC3EAqCnXDp4
                +IxjfmwCm1QfB/VIMfqQ2bSsEu51BPk/38dBG01COvE5
                tYit/Ux8gIuDgZiJx+ldZ9OAJ3Lnm7v/q5+gy2LSzW46
                p6U45WHmGnDZ4c3uhzcfooXmQsW4UmIw+zDc2ePADy3M
                bkr3Srll3XDny1OHoW6Ch4o8qC+ezzRDSEnhrtpon+r9
                4sqXF50k6OLaqCRB3q9iaGUgviTVfZWJIlvZOwvxxpbH
                SDd6QThM/CZBzcx/8JHAwP7MJcUQYS8XvBwRdaAfVDuE
                FjUj6IF+vgn8PI1ipQUrF8L0OAHf1dHBou1XjuE=
                ) ; key id = 17398

RDATA záznamu DNSKEY obsahují příznaky klíče (257), typ protokolu (3 = DNSSEC), použitý algoritmus (5 = RSASHA1) a data veřejné části klíče (AwEA…juE=). Z DNSKEY klíče se dá získat ještě jeden údaj, který je spíše jen informativní a tím je keytag (nebo také id) klíče – 16-bitové číslo používané pro rychlou identifikaci. Obecné doporučení (nikoli však nutnost) je používat dva druhy klíčů – ZSK (Zone Signing Key) a KSK (Key Signing Key). Z názvů těchto klíčů vyplývá, že první typ bude použit pro podpis samotného obsahu zóny a druhý typ se bude používat pouze pro podepisování klíčů. Toto rozdělení je čistě praktické – výměna klíčů není triviální operace a proto byla i v rámci klíčů zavedena jedné zóny hierarchie.

KSK je klíč, který může být silnější (má větší počet bitů), výsledný podpis je větší, podepisování tímto klíčem je výpočetně náročnější a také validace podpisů vytvořených tímto klíčem je výpočetně náročnější. Proto je tento klíč použit pouze pro vytvoření jediného podpisu v celé zóně a to podpisu všech DNSKEY záznamů. Díky větší síle tohoto klíče může být v zóně publikován a používán delší dobu bez ohrožení bezpečnosti. KSK se od ZSK liší pouze jedním bitem v příznacích klíče (257 je KSK a 256 je ZSK).

ZSK je pak klíč, který je slabší, a používá se pro podpis všech záznamů v zóně (včetně DNSKEY). Protože je klíč slabší, musí být měněn častěji, ale díky hierarchii mezi KSK a ZSK, neznamená výměna ZSK žádnou interakci s dalšími subjekty. V jednom z dalších dílů seriálu si ukážeme, jak a proč je potřeba klíče měnit.

DNSSEC podpis

Nyní si ukážeme další nový RR typ, který je potřeba pro vlastní digitální podpis pomocí DNSSEC – typ záznamu RRSIG. Pokud si ještě vzpomenete na první díl našeho seriálu o technologii DNSSEC, tak jsme hned na začátku mluvili o RRSetech, což jsou všechny takové RR záznamy, které mají všechny údaje kromě RDATA stejné. Termín RRSet je pro DNSSEC důležitý, protože digitální podpis se vytváří pro RRSet a nikoli pro jednotlivé RR záznamy. DNS odpověď s DNSSEC může vypadat například takto:

$ dig +norec +multi +dnssec www.dnssec.cz @b.ns.nic.cz

; <<>> DiG 9.5.0-P2 <<>> +norec +multi +dnssec www.dnssec.cz @b.ns.nic.cz
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19348
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.dnssec.cz.     IN A

;; ANSWER SECTION:
www.dnssec.cz.      600 IN A 217.31.205.50
www.dnssec.cz.      600 IN RRSIG A 5 3 600 20090127010003 (
                20081228010003 58773 dnssec.cz.
                rkrCtJFuRt+jCuUEnMB8eKO90DEsYXCE8QP5vn1zc1E8
                r+NS+KVUgicJ4QFdGlb8qoQYCDFE0yVdYYEc2nybn9gQ
                /cx4rKGRCZ3SAGGFLgjOnip60qI6ESlWDqGu5kvgJPGo
                wpmXsWqBd1mApd8N9DQGLiRt7U6RsRCshBnbKA4= )

;; AUTHORITY SECTION:
dnssec.cz.      600 IN NS b.ns.nic.cz.
dnssec.cz.      600 IN NS a.ns.nic.cz.
dnssec.cz.      600 IN RRSIG NS 5 2 600 20090127010003 (
                20081228010003 58773 dnssec.cz.
                ZY4WqF4SkEWUaA0Wqgu517q4yy9tZgnJe4r3DATI6ecT
                cXKIMXUjDl6Gc3jZqtw55DWVDEH5lb2jnSglLUMsBRBQ
                dm45b4r+r45x1OyP2Obtg5LjXkmVdQVTqOBmfL3hzUqt
                uoSafDmYVN0HFwqTNVfkaRotaSpvXBNXU43Z1cE= )

;; Query time: 18 msec
;; SERVER: 2001:1488:dada:184::188#53(2001:1488:dada:184::188)
;; WHEN: Sun Dec 28 18:18:21 2008
;; MSG SIZE  rcvd: 435

V sekci Odpověď vidíme samotný A záznam a k němu příslušný RRSIG záznam, sekce Autorita obsahuje příslušné DNS servery pro doménu dnssec.cz a podpis tohoto RRSetu. Pokud se podíváme na obsah RDATA v RRSIG záznamu, tak objevíme tyto položky:

Klientská strana tedy dostala o jeden RR záznam navíc a k čemu je tento záznam dobrý? Pokud máte správně nakonfigurovaný rekurzivní DNS server, aby prováděl validaci DNSSEC podpisů (dále také validující resolver), může tento ověřit, že data nebyla v průběhu transportu změněna nebo kompletně podvržena. Toto je poměrně důležitá informace – validace podpisů se vždy provádí na straně klienta a podpis je vždy předpočítán dopředu, takže samotný DNSSEC nezatěžuje autoritativní DNS servery. Z uživatelského hlediska je obsah záznamu RRSIG nezajímavý – pokud hledáme chybu, tak můžeme zkontrolovat údaje jako jsou datum počátku a konce platnosti, keytag klíče a vlastníka klíče. Ověření platnosti samotného digitálního podpisu není v silách normálních smrtelníků.

V příkladu výše jsme se ptali přímo autoritativního serveru, který neprovádí validaci. Pokud stejný dotaz položíme nakonfigurovanému validujícímu resolveru, bude vypadat malinko jinak:

$ dig +multi +dnssec www.dnssec.cz @localhost

; <<>> DiG 9.5.0-P2 <<>> +multi +dnssec www.dnssec.cz @localhost
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61066
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.dnssec.cz.     IN A

;; ANSWER SECTION:
www.dnssec.cz.      600 IN A 217.31.205.50
www.dnssec.cz.      600 IN RRSIG A 5 3 600 20090127010003 (
                20081228010003 58773 dnssec.cz.
                rkrCtJFuRt+jCuUEnMB8eKO90DEsYXCE8QP5vn1zc1E8
                r+NS+KVUgicJ4QFdGlb8qoQYCDFE0yVdYYEc2nybn9gQ
                /cx4rKGRCZ3SAGGFLgjOnip60qI6ESlWDqGu5kvgJPGo
                wpmXsWqBd1mApd8N9DQGLiRt7U6RsRCshBnbKA4= )

;; AUTHORITY SECTION:
dnssec.cz.      600 IN NS a.ns.nic.cz.
dnssec.cz.      600 IN NS b.ns.nic.cz.
dnssec.cz.      600 IN RRSIG NS 5 2 600 20090127010003 (
                20081228010003 58773 dnssec.cz.
                ZY4WqF4SkEWUaA0Wqgu517q4yy9tZgnJe4r3DATI6ecT
                cXKIMXUjDl6Gc3jZqtw55DWVDEH5lb2jnSglLUMsBRBQ
                dm45b4r+r45x1OyP2Obtg5LjXkmVdQVTqOBmfL3hzUqt
                uoSafDmYVN0HFwqTNVfkaRotaSpvXBNXU43Z1cE= )

;; Query time: 396 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 28 18:41:23 2008
;; MSG SIZE  rcvd: 435

V příznacích DNS zprávy ubyl příznak AA (Authoritative Answer), protože odpověď již není autoritativní, a přibyl příznak AD (Authenticated Data). Tento příznak indikuje, že validující resolver ověřil platnost DNSSEC podpisu a data v DNS odpovědi jsou správná a nebyla pozměněna. Tento příznak ovšem dostaneme pouze pokud použijeme volbu +dnssec na příkazové řádce nástroje dig, která v DNS dotazu nastaví příznak DO (DNSSEC OK). Pokud bychom tento příznak nenastavili, tak v DNS odpovědi nepoznáme, že RR záznamy byly validovány. Takto je zajištěna zpětná kompatibilita s klienty, kteří DNSSEC neznají. Možná vás v tuto chvíli napadlo – a jak tedy klient pozná, pokud byla data podvržena a digitální podpis nesouhlasí? V takovém případě se DNS odpověď vrátí s chybovým příznakem (RCode) SERVFAIL a špatná odpověď se ke klientovi vůbec nedostane. Návratový kód SERVFAIL bude nastaven i v případě, že „jen“ vyprší časová platnost podpisu. I v takovém případě již není RRSIG podpis platný a nebude validován. Proto je potřeba podpisy v zónovém souboru pravidelně obnovovat.

Pro odlišení normální chyby serveru a chyby ve validaci DNSSEC podpisu byl zaveden speciální příznak CD (Checking Disabled), který nastavuje klient v dotazu na validující resolver. Tento příznak způsobí návrat dat v DNS odpovědi i v případě, že podpis není validní. Více o tom, jak tento příznak použít, si řekneme v některém z dalších dílů našeho seriálu, který bude věnován hledání chyb.

Podpis neexistujícího záznamu

V předchozím odstavci jsme si ukázali, jak vypadá podpis pomocí DNSSEC. Jistě jste si všimli, že podepsané jsou RR záznamy. Pokud si vzpomenete na předchozí díly seriálu, tak jsme si ukazovali, že v případě, že dotazovaný záznam neexistuje, je v DNS odpovědi nastaven návratový kód RCode na hodnotu NXDOMAIN. DNS odpověď, která v sobě neobsahuje žádná data, ovšem nemůže být podepsána. A v tuto chvíli nastupuje další typ RR záznamu – NSEC:

www.dnssec.cz.      600 IN NSEC dnssec.cz. A AAAA RRSIG NSEC
www.dnssec.cz.      600 IN RRSIG NSEC 5 3 7200 20090127010003 (
                20081228010003 58773 dnssec.cz.
                ZrZv9lLNNFkjnhJ+9gLl9kZUI9LHP9r+qNBqTyJq3gSo
                7DpnmCI4tNHdpJKM0cKYf7nuZ1vBebNtiBEMPpdv/Z3K
                MbnF7GWxSOBltvx3cHBa/OHov1ZhPyVyxvE17NvMANo2
                K0654YZu/o8YsfDeImcQkT/gngclIWEBwV3ly/Y= )

NSEC je RR záznam, který ve svých RDatech obsahuje informaci o následujícím záznamu v setřízené zóně a informaci o všech existujících typech pro vlastníka záznamu. Při dotazu na neexistující záznam vrací autoritativní DNS server takový NSEC záznam, který je před a za dotazovaným doménovým jménem v případě kompletní neexistence takového doménového jména, nebo přímo NSEC záznam se shodným vlastníkem v případě neexistence konkrétního typu RR záznamu.

V letošním roce bylo standardizováno rozšíření NSEC záznamu – NSEC3, které odstraňuje jednu kritizovaných vlastností NSEC záznamu: možnost jednoduché iterace celou zónou. O NSEC3 psal nedávno na Lupě Pavel Satrapa ve článku NSEC3 – DNSSEC, který nic nevyzradí.

Haló, já jsem podepsal!

Ve chvíli, kdy je zóna podepsána, musíte nějakým způsobem dát vědět svému okolí, že jste podepsali a pro podpis používáte ten a ten konkrétní KSK klíč. Mohli byste svůj klíč poslat všem subjektům, které by chtěly vaši zónu validovat, nebo použijete hierarchický systém DNS a použitý klíč publikujete do nadřazené zóny. Publikace v nadřazené zóně se děje pomocí posledního nového typu RR záznamu – záznamu o bezpečné delegaci DS (Delegation Signer):

dnssec.cz.      1800 IN DS 17398 5 1 (
                BBDDDD272C4D81EF941C722CEF79A848B543502D )
dnssec.cz.      1800 IN RRSIG DS 5 2 1800 20090105140535 (
                20081206140535 4092 cz.
                dN2nO7C3vKDqf1Q0e+Ulijsp8orlYWD95PpjyssHcUAK
                Tya8bkwDz4B86KSyapFO+j6N1dqXRzwxi3dE3IPDKxzO
                pVG+oTTnJZakqLgxEaRf4H69sqcWmImVMPoHEHM/Y/p/
                zXvUPZFZoSQH74ztQYf1XRQ3rP7liEdBO8TOu9o= )

DS záznam je hodně jednoduchý. Obsahuje keytag klíče (17398), algoritmus klíče (5 – RSASHA1) a hashovací algoritmus DS záznamu (1 – SHA1). Následuje hash vytvořený z vlastníka DS záznamu a DNSKEY RDATA. Tento záznam je publikován a podpsán v nadřazené zóně – v tomto případě bude tento záznam v zóně národní domény .cz.

DS záznamem končí dnešní část seriálu o DNSSEC. V dalších dílech se konečně přesuneme od teorie k praxi a naučíme se konfigurovat DNS servery Bind, Unbound a NSD.

Autor je technickým ředitelem sdružení CZ.NIC.