Výsledky testování podpisu kořenové zóny

Americký úřad NTIA (obdoba našeho ČTÚ), podobně jako minulý rok při rozhodování zda-li podepsat či nepodepsat kořenovou zónu, vyzval veřejnost, aby komentovali finální zprávu o testování podpisu kořenové zóny.

Tato zpráva byla připravena organizací ICANN a společností VeriSign, tedy hlavními autory současného systému podpisu kořenové zóny, který byl testován. Dokument shrnuje závěry z testování a konstatuje, že při testování nebyly identifikovány žádné škodlivé jevy, které by bránily nasazení systému do produkce. Na základě toho doporučuje pokračovat v implementaci a žádá úřad NTIA o autorizaci.

Rád bych uvedl pár zajímavostí ze zprávy, především v bodech, kde nebyl nahlášen úplný úspěch:

  • Kořenové nameservery sbíraly data z tzv. priming dotazů. Toho sběru dat se nezúčastnil server B.
  • V určitých časových okamžicích probíhal sběr veškerého provozu na kořenové nameservery. Plný sběr dat ze všech nameserverů se povedl pouze u posledních dvou časových oken.
  • Proces testování SKR (Signed Key Response – ruční schvalování klíčů) pověřenou osobou z NTIA nebyl dokončen. V průběhu implementace došlo k zesílení bezpečnosti a pověřená osoba bude SKR autorizovat přihlášením přes certifikát na kartě. Tento proces byl pouze vyzkoušen technickým týmem Verisignu.
  • Nebylo otestováno porušení tzv. tamper pojistky v HSM (Hardware Security Module). Panuje dostatečná důvěra, že tyto testy byly provedeny při certifikaci FIPS 140. Porušením tamper pojistky dochází ke znehodnocení materiálu uvnitř HSM, případně celého HSM.
  • V době publikace této zprávy nebylo dokončeno testování změny DS záznamů. Panuje však shoda, že změna DS záznamů není odlišná od změny jiných záznamů v kořenové zóně a tudíž bude testování úspěšné.

Rád bych na tomto místě a tomto blogu zdůraznil, že celý tým, který měl na starosti odvedl výbornou práci a rád bych tímto poděkoval následujícím lidem:

Joe Abley (ICANN), Mehmet Akcin (ICANN), David Blacka (VeriSign), David Conrad (ICANN), Richard Lamb (ICANN/IANA), Matt Larson (VeriSign), Fredrik Ljunggren (Kirei AB), Dave Knight (ICANN), Tomofumi Okubo (Verisign), Jakob Schlyter (Kirei AB), Duane Wessels (Verisign)

V tuto chvíli zbývá ke spuštění podpisu kořenové zóny už jen pár krůčků. Jedním z nich je vygenerování KSK klíčů, které proběhne příští týden ve středu 16. června 2010 na východním pobřeží (Culpeper, VA). Druhá KSK ceremonie se bude konat 12. července 2010 na západním pobřeží (El Segundo, CA). Následně musí proběhnout oficiální předání DS klíčů mezi TLD operátory a ICANN/IANA. Tento krok bude zatím neviditelný, ale bude zapotřebí, aby ve chvíli spuštění podepsané kořenové zóny do ostrého provozu již kořenová zóna již tyto DS záznamy obsahovala.

Posledním nejdůležitějším krokem bude publikace validních klíčů a správných podpisů, tedy ostré spuštění do produkčního provozu. Tento krok by se měl stát 15. července 2010. A i když mám plnou důvěru k tomu, že vše klapne naprosto hladce, tak stejně držte palce. Jedná se o nejdůležitější změnu v historii v systému DNS od jeho vzniku.

Ondřej Surý

P.S.: Dovolím si na závěr ještě jedno upozornění. Kořenová zóna bude používat algoritmus RSA-SHA256, který je podporován pouze v novějších verzích DNS serveru Bind. Konkrétně 9.6.2-P1 nebo vyšší (nicméně doporučuji nejnovější 9.6-ESV-R1), nebo 9.7.0-P2 (nebo vyšší, v tuto chvíli je již dostupná verze 9.7.1rc1 – tedy kandidát na vydání).

Další ocenění pro CZ.NIC

Snad mi laskaví čtenáři toho blogu odpustí, když si dovolím nás trochu pochválit. Po nedávném vyznamenání za projekt BIRD jsme totiž byli oceněni i za naši práci v oblasti DNSSEC. Než se ale dostanu k věci, dovolte mi trochu teorie. Nedávno proběhl finální výběr kandidátů pro funkci TCR (Trusted Community Representatives). Tito důvěryhodní zástupci komunity budou jednak dohlížet nad procesem podpisu kořenové zóny a jednak budou mít v držení kousky klíče, které bude možné použít pro obnovení provozu v případě kompletní havárie.

První funkce byla pojmenována Crypto Officer (CO); těch je sedm pro každou lokalitu, tedy celkem 14. Tito Crypto Officers (minimálně dva) se budou účastnit aktivace HSM (Hardware Security Module), ve kterém je uložena soukromá část KSK klíče. Každý Crypto Officer bude mít v držení klíč k trezoru, kde jsou uloženy přístupové údaje k HSM. Počáteční funkce CO bude pouze dočasná pro první inicializaci HSM modulu. Pokud se dotyčný ve funkci osvědčí, bude s velkou pravděpodobností zvolen pro celý další rok.

Druhá funkce byla nazvána Recovery Key Share Holders; těchto RKSH je přesně sedm. Tito lidé budou mít v držení část klíče, pomocí kterého bude možné obnovit zálohu HSM modulu v případě havárie. Každý RKSH dostane Smart Card – kartu, kterou uloží na bezpečné místo. V případě kompletní havárie HSM se budou muset sejít tito držitelé (pět ze sedmi) a společně obnovit chod HSM zařízení ze zálohy.

No a v čem je to ocenění pro nás? Jedním z těchto důvěryhodných zástupců komunity (konkrétně Recovery Key Share Holder) se stal Ondřej Surý, vedoucí laboratoří CZ.NIC. To je rozhodně skvělá zpráva a právě ono ocenění CZ.NICu i osobně Ondřeje za usilovnou práci na projektech spojených s DNSSECem.

Nyní už jen zbývá doufat, aby trochu opožděný podpis kořenové zóny dopadl dle plánu. Zástupce CZ.NICu bude rozhodně u toho.

Ondřej Filip

DNSSEC nechutná firewallu ESET Smart Security

Kolegové z provozního oddělení mě upozornili, že narazili na zajímavý problém. V případě, že je v programu ESET Smart Security zapnutý osobní firewall, nefunguje náš doplněk do prohlížeče Mozilla Firefox – DNSSEC Validátor. ESET Smart Security kontroluje obsah DNS zpráv a v případě podezřelého obsahu je taková DNS zpráva zablokována. Bohužel v tomto případě je firewall naprogramován příliš restriktivně a blokuje i naprosto korektní DNS zprávy, které obsahují DNSSEC informace.

Nicméně je velmi pozitivní, a chtěl bych to zdůraznit, že výrobce ESET Smart Security přistoupil k problému velmi zodpovědně a proaktivně; nechal si zaslat blokující komunikaci a v některé z dalších verzí bude tato chyba odstraněna. Kéž by se takto chovali všichni výrobci zařízení, která pracují s DNS.

Mezitím než bude blokování DNSSECu opraveno, můžete jako prozatímní opatření vložit IP adresy DNS serverů do konfigurační volby „Adresy vyloučené z aktivní ochrany IDS“ v editoru pravidel a zón.

Na závěr bych dodal, že při implementaci striktních kontrol libovolného protokolu je zapotřebí sledovat nejen nejběžnější chování tohoto protokolu, ale aktivně vyhledávat informace o možnostech protokolu a také sledovat aktuální vývoj (v případě protokolu DNS to znamená pracovní skupinu dnsext a dnsop organizace IETF).

Ondřej Surý

Jaký DNS server používáte pro DNSSEC?

V souvislosti s podpisem kořenové zóny, který bude používat novější algoritmy klíče (RSA-SHA256), o kterém jsem referoval já (zde) i kolega Ondřej Filip (tady a tady), a také především chybnou nebo neexistující podporou záznamů NSEC3 v nižších verzích serveru Bind, bychom se vás rádi zeptali, jaký DNS server a jakou verzi DNS serveru používáte pro poskytování DNSSECu na straně autoritativního serveru, a jakou verzi DNS serveru používáte pro validaci DNSSEC záznamů.

V anketě můžete zatrhnout i více voleb.

Jaký DNS server používáte pro DNSSEC?

  • Bind 9.6.x (33%, 23 Votes)
  • Bind 9.5.x (26%, 18 Votes)
  • Bind 9.7.x (13%, 9 Votes)
  • Unbound 1.4.x (12%, 8 Votes)
  • Bind 9.3.x (12%, 8 Votes)
  • Bind 9.4.x (9%, 6 Votes)
  • NSD 3.2.x (9%, 6 Votes)
  • Microsoft DNS (7%, 5 Votes)
  • Unbound 1.2.x (1%, 1 Votes)
  • NSD 3.0.x (1%, 1 Votes)
  • Jiný (prosíme napište do komentářů jaký) (0%, 0 Votes)
  • CNS (0%, 0 Votes)
  • ANS (0%, 0 Votes)
  • NSD 3.1.x (0%, 0 Votes)
  • Unbound 1.3.x (0%, 0 Votes)
  • Unbound 1.1.x (0%, 0 Votes)
  • Unbound 1.0.x (0%, 0 Votes)

Total Voters: 81

Nahrávání ... Nahrávání ...