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