Jistě jste si všimli, že vás, naše čtenáře, pravidelně informujeme o dění okolo podpisu kořenové zóny (naposledy zde). Máme za sebou úspěšně první i druhou KSK ceremonii a poslední krok, který dle harmonogramu zbývá, je zveřejnění pravého KSK klíče (až doposud byla kořenová zóna podepsaná pomocí mechanismu DURZ).
A dnešního dne bude celý tento proces, který trval několik měsíců, završen publikováním pravého KSK klíče (teď si na pozadí představte bouchání šampaňského a jásot :)).
Pravý klíč pro kořenovou zónu má následující hash:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkw9t5sACgkQoZmhm3FA9yZfkwCeOo3dGa5Nr1ux4WmDpRIrKjoM
iREAoKtYh03ZK+k5brhikmb+9u5iqOZU
=ZfNp
-----END PGP SIGNATURE-----
Tento DS záznam byl získán z dokumentu, který byl vytisknut na první KSK ceremonii:
DS záznam KSK klíče pro kořenovou zónu je podepsán GPG klíčem CZ.NICu 7140F726, který by měl být podepsán mým osobním klíčem a klíčem CSIRT CZ.NIC. Tento klíč můžete získat například ze server pgp.mit.edu:
gpg --keyserver pgp.mit.edu --recv-key 7140F726
Následující sekce bude platná až po publikaci tohoto klíče do kořenové zóny, která proběhne dnes 15. července 2010 mezi 21.30 – 01.30 středoevropského letního času.
Pokud budete chtít začít validovat pomocí klíče kořenové zóny, tak toto provedete změnou konfigurace vašeho rekurzivního DNS serveru (připomínám, že je zapotřebí rekurzivní server Unbound nebo Bind minimálně ve verzi 9.6-ESV nebo libovolné vyšší).
Přesný popis zveřejnění klíčů naleznete v dokumentu DNSSEC Trust Anchor Publication for the Root Zone. Důležité informace jsou tyto:
- Klíč bude zveřejněn ve dvou formátech:
- v XML obsahující hash DNSKEY klíče ve formátu DS záznamu
- v CSR (Certificate Signing Request) ve formátu PKCS#10
- URL XML souboru bude: https://data.iana.org/root-anchors/root-anchors.xml
- Podpisy souboru trust-anchors budou uloženy v:
Konfiguraci serveru Unbound provedete pomocí direktivy trust-anchor:
trust-anchor: ". IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5"
Druhou variantou je uložení DS záznamu do souboru např. /etc/unbound/root.ds a nastavení directivy trust-anchor-file: (nebo auto-trust-anchor-file:)
trust-anchor-file: "/etc/unbound/root.ds"
Konfiguraci serveru Bind9 je podobná, jen formát záznamu je odlišný. Nepoužívá se přímo DNS záznam, ale rovnou DNSKEY.
Do konfigurace Bind 9.6 vložíte následující blok s konfigurací:
trusted-keys {
"." 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=";
};
Konfigurace pro Bind 9.7 je obdobná, ale použije se konfigurační direktiva managed-keys:, která automatickou aktualizaci klíče v případě, že bude DNSSEC klíč změněn mechanismem popsaným v RFC5011:
managed-keys {
"." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=";
};
Po provedení změn musíte znovu načíst konfiguraci a měli byste mít zapnutu validaci pomocí kořenové zóny. Podotýkám, že bych zatím nevypínal validaci pomocí služby ITAR, která v současnosti obsahuje 26 pevných bodů důvěry. Oproti tomu kořenová zóna v čase psaní tohoto blogpostu obsahuje pouhých sedm bezpečných delegací:
# dig @xfr.lax.dns.icann.org . axfr | awk '/^[a-zA-Z0-9-]+\.[[:space:]]/ { print $1, $4; }' | grep DS | sort -u
bg. DS
br. DS
cat. DS
cz. DS
na. DS
tm. DS
uk. DS
Ověření validace můžete například provést takto:
# dig +adflag IN NS . @adresa_vašeho_resolveru
Nyní vypadá výsledek přibližně takto:
$ dig +adflag IN NS . @127.0.0.1
; <<>> DiG 9.7.0-P1 <<>> +adflag IN NS . @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7104
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
[...seznam NS záznamů...]
;; ADDITIONAL SECTION:
[...seznam IP adres nameserverů...]
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 14 15:45:11 2010
;; MSG SIZE rcvd: 492
Po podpisu kořenové zóny do hlavičky přibude příznak AD:
$ dig +adflag IN NS . @127.0.0.1
; <<>> DiG 9.7.0-P1 <<>> +adflag IN NS . @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7104
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15
[...]
Aktualizováno: Přidána konfigurace pro Bind 9.7.
Ondřej Surý
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ý
Všechno, co jste kdy chtěli vědět o doménách (ale báli jste se zeptat)
Na základě informací uvedených v registru domén lze vygenerovat spoustu zajímavých dat nejen o doménách samotných, jejich držitelích apod. Je možné poohlédnout se po tom, jaký obsah je na webových stránkách v příslušných doménách, kolik domén je připraveno na přechod na nový protokol IPv6 či jaké jsou tržní podíly serverového software. Tržní podíly webových serverů poskytujících domény .cz následují jako malá ochutnávka tzv. Domain Reportu, který jsme se rozhodli pravidelně připravovat.
Celý Domain Report s mnoha dalšími statistikami za minulý rok 2009 si můžete stáhnout ve formátu PDF: DOMAIN REPORT 2009 CZ [836 kB].
PT
Publikace podepsané kořenové zóny posunuta
Joe Abley včera informoval komunitu, že se změnily plány podpisu kořenové zóny. Poslední fáze, která obsahuje publikaci kořenové zóny podepsané reálným klíčem, byla posunuta z 1. července 2010 na 15. červenec 2010. Tyto dva týdny budou využity na další studium publikování DURZ (viz úvod) podepsané kořenové zóny.
Dalším naplánovaným krokem k podpisu kořenové zóny bude první ceremonie podpisu klíčů, která proběhne 16. června 2010 v USA ve městě Culpeper. Pro ty z vás, kdo stejně jako já netušíte, kde takový Culpeper leží, tak je to kousek od Washingtonu DC.
Ondřej Surý
První tři dotIDN domény živé
Dnešní den je pro kořenovou zónu velice významný. Nejenom že došlo k dokončení falešného podepisování zóny, ale zároveň byly přidány tři IDN domény nejvyšší úrovně. Shodou okolností jsou všechny tři arabské, jde o Egypt, Saudskou Arábii a Spojené Arabské Emiráty. Zvláštní je, že do zóny zatím nebyla zařazena doména Ruské Federace. Byla totiž původně ve stejné várce jako tyto tři. Každopádně dnešním dnem končí definitivně výlučná vláda latinky v doménovém systému! Nyní už například Egypťan bude moci napsat adresu svých webových stránek bez toho, aby musel přepínat klávesnici na latinku. Zkuste třeba kliknou na následující odkaz – http://وزارة-الأتصالات.مصر/
Ondřej Filip
Tak jsme se dočkali! Podepsáno jest.
Na tomto blogu vás pravidelně informujeme o postupu podpisu kořenové zóny (Už jen jeden!, Více než polovina, první, a úvod). Dnes došlo k podepsání posledního kořenového serveru: J.root-servers.net od dnešního dne nese kořenovou zónu podepsanou pomocí DNSSECu.
Kořenová zóna je stále podepsána klíčem a podpisy, které nelze validovat (tzv. DURZ). Ale i tak je podpis posledním krůčkem potřebným pro finální podepsání kořenové zóny validním klíčem, které má proběhnout 1. 7. 2010. Postupné nasazení DURZ – podepsané kořenové zóny na jednotlivé nameservery, bylo zapotřebí pro ověření, že zvětšení DNS zpráv nezpůsobí žádné velké operační problémy. Až na lehké zvýšení TCP provozu na kořenové nameservery po podepsání dvanácti nameserverů ze třinácti to zatím nevypadá, že by nějaké problémy měly nastat. Ale to ukáží následující hodiny.
Takže velké díky týmu, který pracoval na podpisu kořenové zóny a další velký úkol na ně čeká na začátku prázdnin.
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
Už jen jeden!
Nedávno jsem referoval, že více než polovina kořenových serverů poskytuje onu pseudopodepsanou zónu. Včera došlo k další významné změně. Už jsou „podepsány“ všechny kořenové servery s výjimkou posledního, označovaného písmenem J. Tento stav bude pro rozhodnutí o skutečném podpisu kořenové zóny klíčovým. Systém DNS je navržen velice robustně a pro jeho správnou funkci stačí dostupnost alespoň jednoho kořenového serveru. Pokud tedy nějaký systém obsahuje špatnou implementaci DNS resolveru, která zahazuje DNSSEC podepsané odpovědi, bude pro tento systém těch 12 podepsaných kořenových serverů jakoby nedostupných. Takže jako jediný dostupný se bude jevit právě server J a takové systémy budou koncentrovat své dotazy právě na něj. Pokud tedy výrazně stoupne zatížení tohoto serveru, dá se předpokládat, že existuje větší množství klientů, které by podpis všech serverů „odstřihl“ od Internetu. Možná proto si správci kořenových serverů na podpis toho posledního třináctého nechávají čas a plánují jej na 5. května. Mají pár dnů na to, zanalyzovat, zda-li se nějaký podobný jev nevyskytuje.
Každopádně vlak jménem DNSSEC@ROOT postupuje dle grafikonu. Další zastávka bude na začátku května.
Ondřej Filip
Už více než polovina kořenových serverů s DNSSEC
Jak už před časem referoval kolega Surý, v současnosti probíhá proces, jehož vyústěním bude plný platný podpis kořenové zóny. Tato událost zastřeší všechny současné aktivity týkající se podepisování domén nejvyšší úrovně a hlavně zjednoduší život správcům rekurzivních DNS serverů; pak už totiž bude stačit pouze sledovat změny klíčů jedné (té nejvyšší) zóny.
Minulý týden ve středu došlo k překonání dalšího virtuálního milníku. K podpisu totiž nedochází naráz, ale jednotlivé kořenové zóny se „podepisují“ neověřitelnými „falešnými“ klíči postupně. A právě 24. března byly tyto klíče publikovány dalšími třemi servery. Celkový počet „podepsaných“ serverů se v tuto chvíli zastavil na čísle sedm, což je už více než 50 % z celkových 13. Další várka zavádění těchto podpisů se očekává 14. dubna, kdy bude podepsáno dalších pět serverů. Poslední server bude přidán 5. května.
Správný a validní podpis by měl začít platit od prvního prázdninového dne – 1. července. Zatím tedy proces běží zcela podle plánu a nemá žádné zpoždění, což je velice dobrá zpráva pro bezpečnost systému DNS.
Ondřej Filip
DNS před zhroucením? Ani náhodou!
Výkonný ředitel ICANN Rod Beckstrom prohlásil včera na setkání GAC (poradního výboru vlád při ICANN), že: „Na systém DNS je veden útok a celý systém je nyní křehčí a zranitelnější než kdykoliv předtím a může se kdykoliv doslova zhroutit.“ Pokud by se něco takového stalo, mělo by to samozřejmě obrovské a dalekosáhlé důsledky, protože na fungování Internetu dnes závisí téměř vše. Dle jeho slov dospěl k tomuto tvrzení po konzultaci s více než 20ti řediteli největších doménových registrů a registrátorů, kteří jsou extrémně znepokojeni stejně jako on. Více v plném audio záznamu komentáře.
Zajímavý je už fakt, že co se týká národních domén (tzv. ccTLD), tak někteří ředitelé největších registrů, kteří byli na místě přítomni, o žádných takových konzultacích nevěděli. Tak jako tak prakticky všichni zástupci registrů národních domén toto tvrzení považovali za „nemístné“ a přehnané. Samozřejmě i DNS se stejně jako spousta dalších internetových služeb potýká s bezpečnostními problémy. Nicméně rozhodně žádný z nich neohrožuje funkčnost a stabilitu celého systému. Navíc zrovna v této oblasti internetová komunita pracuje velmi dobře – je si vědoma zásadní důležitosti systému DNS (proto pro něj buduje velmi robustní infrastrukturu), nalezené problémy řeší, vzdělává koncové uživatele atd. K tomuto se samozřejmě snažíme přispět i my (CZ.NIC) například tím, že se podílíme na provozu F a L kořenových serverů v České republice, že jsme jako jedni z prvních zavedli DNSSEC (máme nejvíce zabezpečených domén na světě) nebo že provozujeme bezpečnostní oddělení, které řeší např. zneužívání domén k šíření malware či phishingu.
Osobně si myslím, že představitel tak významné instituce by neměl vydávat takto silná prohlášení bez širší konzultace s institucemi, které se o provoz a stabilitu starají např. správce národních domén, operátory root serverů apod. Ostatně třeba organizace správců národních domén (ccNSO) připravuje vlastní vyjádření k těmto jeho výrokům.
Ondřej Filip

