Ondřej Filip

Částečnou odpovědí na výše zmíněnou otázku může být také fakt, že největší z registrátorů .CZ využívají služeb mateřských zahraničních firem, které akreditovány jsou a nepotřebují se akreditovat samy. Může to být ale způsobeno i tím, že získat akreditaci ICANN není zase tak jednoduché (už jen v samotné přihlášce je poměrně dost požadavků na podrobné informace o firmě) a není ani zadarmo. Jen roční poplatek dělá aktuálně 4000$. A s tím samozřejmě souvisí i otázka, kolik se vlastně u nás gTLD domén registruje a jestli se tedy registrátorům vůbec vyplatí se do akreditace pouštět… vždyť akreditace pro domény .EU také není zadarmo a přesto ji má celá řada českých subjektů.

Každopádně přeji Gransy hodně štěstí a spoustu nových domén – i když za mne asi hlavně těch s koncovkou .CZ

Martin Peterka

Ondřej Filip

Každopádně i tak můžeme říct, že ITAR se pomalu stává minulostí, už rozhodně nelze validovat jen s ním. Česká doména jej kvůli rotaci klíčů opustí brzy a dá se předpokládat, že obdobně se zachovají i ostatní registry. Naopak nové registry už budou vkládat své DS záznamy přímo do kořene. V mailinglistech věnovaných rozvoji DNSSEC byla už spuštěna debata o tom, kdy provoz ITARu definitivně ukončit. Zatím ještě žádné datum nepadlo.

Každopádně, pokud jste tak ještě neučinili, nastavte své resolvery, aby validovaly proti kořenové zóně. Jinak už o mnoho domén „přijdete“.

Ondřej Filip

Jak vyplývá z návrhu, ITMAC má nyní 18 panelistů, kteří by spory rozhodovali a je schopno nabídnout řešení sporů v mnoha jazycích, které jsou v Indii a okolních státech používány (tedy kromě angličtiny také hindština, tamilština, bengálština a další). Navržené poplatky jsou o něco vyšší než například u českého Rozhodčího soudu: spor o jednu doménu řešený třemi rozhodci vyjde v Čechách na 81 tis. Kč, v Indii na cca 89 tis. Kč (217 tis. rupií). Spory o česká doménová jména však nejsou řešeny podle pravidel UDRP, ale jde o rozhodčí řízení ve smyslu zákona č. 216/1994 Sb., o rozhodčím řízení a výkonu rozhodčích nálezů.

Zuzana Durajová

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íř

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íř

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

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:
  • S/MIME: https://data.iana.org/root-anchors/root-anchors.p7s
  • OpenPGP: https://data.iana.org/root-anchors/root-anchors.asc

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

;; 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

[...]


Aktualizováno: Přidána konfigurace pro Bind 9.7.

Ondřej Surý

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

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íř