V návaznosti na podepsáním kořenové zóny nás všechny čeká jedna velká změna – výměna DNSSEC klíčů a přechod na NSEC3. Psal jsem o ni na tomto blogu už dříve a tak, protože se blíží její čas (započne již příští týden v úterý), rád bych na ni upozornil ještě jednou.
Tento přechod se nastartuje už v úterý 3. srpna. Z pohledu CZ.NIC to znamená, že v tento den zavedeme pro naší zónu nový klíč (rozhodli jsme se nakonec, že klíč nebude typu RSASHA256, ale ještě silnějšího typu RSASHA512) a ze všech zdrojů (ITAR, DLV, internetové stránky) stáhneme klíč, který jsme používali dosud. Následně na to, ještě v tento den, také pošleme IANA žádost o výměnu klíčů v kořenové zóně. Co všechno souvisí s touto změnou, jsme popsal ve výše zmíněném článku.
Jak se říká: Co můžeš udělat dnes, neodkládej na zítřek. Tato slova v tomto případě určitě platí a to hlavně pro provozovatele rekurzivních DNS serverů, kteří provádějí validaci pomocí DNSSEC. Připravte se včas, do 3. srpna zbývá už jen jeden týden! Doporučujeme vám především:
- přejít na validaci DNSSEC přes klíč kořenové zóny (další informace najdete na stránkách věnovaných DNSSEC)
- upgradovat na nejnovější verzi DNS serveru.
Jaromír Talíř
FRED se zabydlel na Faerských ostrovech
Náš registrační systém FRED, který jsme pro naší doménu spustili v roce 2007, se dočkal dalšího nasazení. Nejnověji jej využívá národní registr na Faerských ostrovech – po České republice jde o druhou evropskou zemi, která se rozhodla na FRED přejít.
V případě této země s pouhými 50 tisíci obyvateli a zhruba třemi tisíci doménami s koncovkou .fo bylo FRED potřeba modifikovat, aby vyhovoval tamější registrační politice. Vzhledem k tomu, že roli registrátorů na sebe přebírá sám správce domény, byl systém doplněn o externí databázi, která slouží k provozu registračního webového rozhraní, umožňuje platby kreditními kartami apod.
Podstatnými změnami prošla také struktura ukládaných kontaktů. Faerský správce národní domény má o něco přísnější podmínky registrace, pokud jde o možnost identifikace držitele domény, proto mezi registrační údaje patří i datum narození a národnost (v případě zahraničních zájemců o doménu je to číslo pasu, sken pasu a národnost). Potřebné kontakty pro registraci tak jsou: Holder (držitel domény), Billing contact (kontakt pro platbu, z původní struktury FREDa nahrazuje Admin) a Technical contact (technický kontakt).
Faerská verze FREDu se musela přizpůsobit také dvěma používaným typům žádostí o registraci. Typ A představují žádosti, které jsou vyřízeny okamžitě, přičemž žadatel musí doložit, že má na danou doménu právo (například kopií z registru značek). Typ B jsou žádosti, které mají 30denní lhůtu na vyřízení, během níž se o doménu mohou přihlásit i další subjekty, které by k jejímu držení mohli mít právo. Během této lhůty jsou žádosti spravovány v externí databázi, po jejím uplynutí se doménové jméno uloží v databázi FREDu.
Pevně věříme, že tato evropská vlaštovka nezůstane dlouho sama, a že se k ní časem přidají další doménové registry starého kontinentu.
Jaromír Talíř
DNSSEC klíč v kořenové zóně
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ý
Tak už méně než rok
Ačkoliv dnes napínavě očekáváme trochu jinou událost, tedy podpis kořenové zóny, dovolte mi se dnes zaměřit na trochu jiný, ale neméně zajímavý fakt. Známé počitadlo spotřeby IPv4 adres dle předpovědi Geoffa Hustona ukazuje, že tyto adresy dojdou v nejvyšším registru IANA za méně než rok! Dnešní odhad ukazuje na 10. červen 2011.
To je zjevný posun, ještě nedávno jsem například glosoval, že lidé z IANA, kteří se věnují přidělování IPv4 budou bez práce až ke konci prázdnin příštího roku. Takhle to spíše napovídá, že si příští prázdniny užijí celé. Vzhledem k tomu, že konec je už relativně blízko, je každý posun poměrně významný. Pojďme se podívat, čím by tak mohl být způsobený. Za prvních 14 dnů prázdnin bylo alokováno cca 13 miliónů adres, což je zhruba stejně jako za celý červen. Pokud by toto tempo v červenci vydrželo, byl by to rozhodně rekordní výkon tohoto a loňského roku.
Pravidelného čtenáře našeho blogu možná napadne, že by to mohlo být způsobené nedávnou změnou RIPE politiky a že evropské LIRy podaly na konci června hodně žádostí o alokace, aby ještě stihly alokovat za starších výhodnějších podmínek a tyto alokace byly postupně vyřizovány v červenci. To se jistě mohlo stát, ale pohled na následující koláčový graf napoví, že Evropané v červencových alokací rozhodně nehrají prim.
Alokace dle regionů za prvních 14 dnů července 2010
Hlavní konzumentem IP prostoru byl region Asie-Pacific s 8,8 miliónem adres následovaný Latinskou Amerikou s 2,1 milióny adres. Evropané paběrkovali jen s 1.6 miliónem. V dnešní době už asi nikoho nepřekvapí, že z pohledu zemí putovala největší porce IP prostoru do Číny. Říše středu zatím za prvních 14 dní července potřebovala na svůj rozvoj 6,5 miliónu adres, tedy zhruba tolik, co celý zbytek světa. Mimochodem, v regionu Asie-Pacific se stále ještě alokuje na 12 měsíců dopředu.
Bude velice zajímavé sledovat, jak se bude situace vyvíjet dále. Následující dva měsíce by totiž tak jako v minulých obdobích měly být spíše podprůměrné kvůli vlivu prázdnin. Ale je možné, že prolomení psychologické hranice jednoho roku přeci jenom přiměje jednotlivé LIRy/ISP trochu alokace uspíšit.
Ondřej Filip
Podpis kořenové zóny, ITAR a NSEC3
Zatímco se celý DNS svět připravuje na podepsání kořenové zóny, které proběhne už za necelých 14 dní, my se připravujeme hned na tři podstatné změny, které budou po tomto podepsání následovat a souvisejí s přechodem zóny CZ na variantu technologie DNSSEC označovanou jako NSEC3. Tyto změny jsou samozřejmě zajímavé pouze pro provozovatele rekurzivních DNS serverů, kteří provádějí validaci pomocí DNSSEC. Běžný uživatel tyto změny pravděpodobně ani nezaznamená.
První velkou změnou je zrušení podpory repositáře klíčů ITAR. Již nyní jsou naše záznamy z ITARu vloženy v kořenové zóně a v okamžiku, kdy bude kořenová zóna podepsaná, bude možné validovat zónu CZ právě pomocí klíčů kořenové zóny. Doporučujeme tedy co nejrychleji přejít na tento způsob validace změnou konfigurace rekurzivních DNS serverů. Klíče kořenové zóny budou k dispozici v den jejího podpisu, tedy 15. července.
S výše uvedeným souvisí také historicky první rollover (výměna klíčů) v zóně CZ. Nový klíč, který v rámci této operace zveřejníme, bude silnější a umožní nám přechod na NSEC3. Tento klíč již ale nebudeme vkládat do repositáře ITAR, abychom podpořili přechod na validaci přes kořenovou zónu. Podle harmonogramu, který jsme zveřejnili, provedeme tuto operaci 3. srpna. V tento den také zašleme do IANA žádost o vložení otisku nového klíče do kořenové zóny a žádost o vyřazení otisku klíčů z repositáře ITAR. Přestože bude tato žádost zpracovaná zhruba do 14 dnů ode dne podání, od 3. srpna již nebudeme ITAR podporovat a je tedy nutné mít v konfiguracích správně klíče kořenové zóny! Toto se netýká pouze DNS serverů využívající ITAR, ale i těch, které mají klíč pro zónu CZ nakonfigurován ručně. Nový klíč již nebudeme zveřejňovat na našich stránkách a pokud někdo tuto konfiguraci používá, musí změnit klíč pro zónu CZ na klíč pro kořenovou zónu. Stejným způsobem také odebereme klíče z posledního místa, kde je možné je nalézt, a to z ISC DLV.
Nový klíč bude vytvořen silnějším typem algoritmu RSASHA512 (opraveno 2. srpna 2010) než je stávající RSASHA1. Podstatné je, že tento nový algoritmus je podporovaný až v novějších verzích softwaru používaného pro rekurzivní DNS servery. Nejjednodušší způsob, jak tuto podporu otestovat, je vyzkoušet si validaci ENUM zóny 0.2.4.e164.arpa, která již tento algoritmus používá. DNS server Bind podporuje tento algoritmus od verze 9.6.2. DNS server Unbound od verze 1.4.0.
Posledním krokem celé akce je vlastní přechodu na NSEC3. V zóně ENUM proběhla tato změna podle plánu. V zóně CZ jsme bohužel termínově vázáni na propagaci nových klíčů v nadřazené zóně, což není v naší moci ovlivnit, ale zatím vždy byly požadované změny provedeny do 14 dnů. I z pohledu provozovatelů rekurzivních DNS serverů bude ale tato poslední změna neviditelná a tedy nebude nutné do konfigurace DNS serverů zasahovat.
Na závěr drobné shrnutí očekávaných událostí „horkého“ léta:
- 15. 7. 2010 proběhne podpis kořenové zóny a publikace podpisových klíčů
- 3. 8. 2010 provádíme v zóně CZ přidání nového RSASHA512 (opraveno 2. srpna 2010) klíče a stahujeme existující klíče ze všech zdrojů, kde jsme je publikovali (ITAR, DLV, webové stránky); zároveň posíláme do IANA žádost o zařazení otisku klíče v kořenové zóně
- 24. 8. 2010 odebereme staré RSASHA1 klíče a provádíme podepsání zóny CZ pomocí technologie NSEC3.
Jaromír Talíř
RIPE utahuje kohoutky
Ačkoliv běžný uživatel Internetu žádné zásadní změny nepociťuje, odborníci už vědí, že „se něco děje“. IPv4 adresy rychle ubývají a není příliš daleko doba, kdy nám počitadlo ukáže, že v registru adres IANA nebudou ani na rok. Nebo chcete-li někdy v průběhu příštích prázdnin bude IP prostor registru IANA prázdný. Pak ještě budou nějaké volné adresy u pěti regionálních registrů a těm by, dle dnešních odhadů, měly dojít někdy v dubnu 2012. Nicméně to je průměr přes všechny registry; je možné, že v některém dojdou adresy dříve. Pak ještě nějaký čas budou adresy u lokálních registrů (LIR), kteří přidělují (assignment) adresy koncovým uživatelům, což ale případně mohou být oni sami. Regionální registry a tedy i náš Evropský RIPE tato situace pochopitelně nenechává v klidu. Proto postupně zpřísňují své podmínky, za kterých přidělují IP adresy jednotlivým LIRům nebo-li poskytovatelům připojení či služeb. Jedno z těchto omezení vstoupilo v platnost právě dnes. Až do teď RIPE NCC alokovalo (allocation) IP adresy LIRů s výhledem na 12 měsíců. Stejně tak LIRy byly povinny přidělovat adresy koncovým uživatelům tak, aby jim toto přidělení vystačilo zhruba na 12 měsíců. Jinými slovy, pokud by došly IP adresy, někteří koncoví uživatelé by měli IP adresy ještě na cca 24 měsíců a někteří by měli okamžitě smůlu. Aby byla odstraněna tato nespravedlnost, byl vytvořen a následně přijat tento návrh, který obě lhůty postupně zkracuje. Od dnešního dne bude RIPE NCC alokovat adresy pouze na 9 měsíců a na stejnou dobu mají LIRy přidělovat rozsahy svým koncovým uživatelům. K dalším zkrácení těchto lhůt dojde 1. ledna příštího roku, od kdy tyto lhůty budou jen 6 měsíční a přesně za rok budou zkráceny na 3 měsíce. Jinými slovy, získat adresy dopředu bude složitější, konec se prostě nezadržitelně blíží.
Ondřej Filip
Další nelatinkové domény v kořenové zóně
Jak jsme vás již informovali, byl doménový prostor rozšířen nejprve o arabské písmo a následně i o azbuku. Domény Egypta (.مصر), Saudské Arábie (.السعودية), Spojených arabských emirátů (.امارات) a Ruska (.рф) jsou již plně funkční v kořenové zóně. Minulý pátek došlo ke schválení dalších dvou písem, konkrétně byly schváleny domény nejvyšší úrovně (TLD) v tradiční a zjednodušené čínštině.
Situace je nejjednodušší v Hongkongu, kde je zápis stejný v tradiční i zjednodušené čínštině – .香港. Tato doménu byla přidělena organizaci Hong Kong Internet Registration Corporation Limited, která dnes spravuje doménu .hk.
Taiwan Network Information Center, správce domény .tw, dostal dvě domény pro Taiwan – .台灣 v tradiční čínštině a .台湾 ve zjednodušené čínštině.
A konečně CNNICu, správci domény .cn, byly přiděleny dvě domény pro Čínu – .中國 v tradiční a .中国 ve zjednodušené čínštině.
Bude zajímavé sledovat, jak se tyto země poperou se situací, kdy lze zapsat stejné slovo dvěma různými písmy. V rámci pracovní skupiny dnsext IETF je ve hře několik návrhů (BNAME, CNAME+DNAME a DNS Shadow), jak celou situaci řešit na technické úrovni, a zatím není rozhodnuto, který z návrhů bude schválen. Zatím to vypadá, že minimálně CNNIC bude generovat zóny se stejným obsahem pro obě varianty písma, resp. dle současných pravidel registrace domény používajících čínské písmo mají vždy 2 – 3 varianty – tradiční, zjednodušenou a volitelně může obsahovat tvar používající obě písma současně.
Ondřej Surý
P.S.: Provedl jsem aktualizaci taiwanských domén na správné tvary. Díky Janu Zahornadskému za podnětnou připomínku.
V druhé půlce července nezapomeňte…
Pro českou národní doménu došlo včera k další významné události související s uzavřením řetězce důvěry pomocí technologie DNSSEC. IANA dokončila proces vložení DS záznamu do kořenové zóny. DS záznam je jakýsi otisk DNSSECového klíče příslušné domény a vždy jej předává správce podřazené domény správci nadřazené domény. Technicky jde o analogický proces, jako když nám do zóny .cz vloží pomocí svého registrátora obdobné informace držitel. Nicméně v případě kořenové zóny panují úplně jiná pravidla, proces zdaleka není automatizovaný, naopak je spíše ruční. Obvykle trvá několik dní a zahrnuje mnoho akcí více institucí. Pokud si na ty zmiňované DS záznamy chcete „sáhnout“, napište třeba následující příkaz.
dig +short DS cz. @a.root-servers.net
Co to tedy znamená? Jakmile dojde k podpisu kořenové zóny nemusí člověk provozující validující rekurzivní nameservery (obvykle ISP nebo správce firemní sítě) ukládat do konfigurace speciální klíče pro každou podepsanou doménu nejvyšší úrovně (TLD), ale vystačí si pouze s jedním klíčem kořenové zóny. A co to bude znamenat pro CZ.NIC? Především volnost v tzv. rotování klíčů. Všechny klíče použité v DNSSECu je nutné čas od času obměnit. Rychlost záleží na jejich typu (KSK či ZSK). ZSK lze měnit automaticky a to také CZ.NIC pravidelně dělá, ale právě KSK jsme ještě od spuštění DNSSECu neměnili. Tuto operaci tedy bude možné provést až po podpisu kořenové zóny. Krom běžné výměny klíčů plánujeme i zavedení modernějších podepisovacího systému NSEC3, který neumožňuje vylistování domén ze zóny, tzv. zonewalking. Nedávno jsme zveřejnili harmonogram tohoto postupu a už jsme v podstatě v polovině, zatím jsme NSEC3 zavedli pro ENUM doménu (0.2.4.e164.arpa). Mohli jsme si to dovolit, protože to není TLD; tato doména je podřízena e164.arpa a tedy její klíče by pro validaci nikdo používat neměl.
Harmonogram také říká, že k přechodu na NSEC3 v .cz by mělo dojít 3. srpna. Nicméně jsou tu dva důležité faktory, které mohou toto datum posunout. Prvním faktorem je přirozeně datum podpisu kořenové zóny, zatím však vše nasvědčuje tomu, že to bude dle plánu 15.7.2010. Druhou věcí, která by nás mohla donutit k změně, by bylo zjištění, že nějaké významné DNS resolvery ještě stále používají „natvrdo“ nastavený klíč pro .cz. To se bohužel dá jen velmi obtížně zjistit, jedinou možností je se prostě zeptat správce. Proto budeme tuto věc ověřovat pouze u velkých ISP, o kterých je nám známo, že validaci DNSSEC používají. Pokud tedy nějaký takový validující resolver spravujete, poznačte si do kalendáře, že mezi 15. červencem 2010 a 3. srpnem 2010 musíte v konfiguraci udělat změnu nastavení, jinak Vám validace české domény přestane fungovat.
Udělejte to určitě, rádi bychom „jeli na čas“! :-)
Ondřej Filip
Další významná doména podepsána
Zprávy týkající se DNSSECu se v poslední době objevují jako houby po dešti. S tím, jak se blíží podpis kořenové zóny, zvyšují mnohé TLD registry svou aktivitu v této oblasti. Proto jsem si vybral zprávu, která se dotýká mnoha uživatelů v České republice. Dalším registrem, který podepsal svou doménu a spustil registrace pro koncové uživatele, se stalo sdružení EURid. Pro podpis už pochopitelně použilo novější technologii NSEC3 a to s mechanismem opt-out, který zmenšuje velikost zónového souboru.
Je příjemné, že došlo k určité synergii s naší doménou .cz. Jeden v DNSSEC oblasti z nejaktivnějších registrátorů – Web4U, se rozhodl automaticky pro své zákazníky podepsat i všechny .eu domény, které hostuje na svých nameserverech. Tím dostala .eu doména do startu DNSSECu hned několik tisíc podpisů. Doufejme, že si to vezmou za příklad i další registrátoři a DNSSEC se ještě více rozšíří.
Ještě poměrně zajímavé je, že se EURid nerozhodl nijak publikovat svůj veřejný klíč. Není dokonce ani v ITARu. Předpokládám, že důvodem je, že nechtějí, aby uživatelé jejich doménu validovali pomocí jejich klíče, ale chtějí, aby validace probíhala až pomocí podepsané kořenové zóny. To je poměrně správný přístup, nemá smysl kvůli jednomu měsíci validace něco speciálního nastavovat.
Takže gratuluji EURidu a je příjemné, že další doména je připravena před tím hlavním milníkem – podpisem kořenové zóny.
Ondřej Filip
Trocha archeologie aneb celý prehistorický internet na USB klíči
Pokud patříte k pamětníkům internetové prehistorie, pamatujete si či jste dokonce používali službu Gopher. Pro vás ostatní to byl jakýsi předchůdce webu – představte si ho zhruba tak, jako byste měli webovou stránku, na které je pouze text a hierarchická struktura dokumentů, jež můžete procházet, prohledávat a příslušné dokumenty si stáhnout. Pokud používáte prohlížeč Mozilla Firefox (s ostatními prohlížeči máte bohužel smůlu), můžete si jej dokonce přímo vyzkoušet, protože stále ještě funguje. Zkuste třeba napsat do řádku adresy gopher://gopher.floodgap.com/
Pokud byste se chtěli do této archeologie ponořit ještě více, můžete si stáhnout a prozkoumat archiv celé služby Gopher na celém světě tak, jak vypadala v roce 2007. Samozřejmě tehdy už byla dávno za svým zenitem, ale dle autora archivu počet gopher serverů dále rapidně klesal, takže dnes je doslova ohrožena „vyhynutím“. Každopádně archiv má cca 40GB (ke stažení je pomocí torrent) a kompresovaný má jen 15GB, což se dnes pohodlně vejde na onen zmiňovaný USB klíč. Stejná věc s dnešním internetem půjde udělat asi těžko, protože jeho velikost se odhaduje na stovky exabytů (podle Cisco i podle Google)… i když vlastně vzpomeňme na „640 k ought to be enough for anyone“ (přestože to zřejmě nikdy nebylo vyřčeno).
PT