.blog

V několika článcích na lupě [1] [2] jsem popisoval problémy, které provází proces vzniku nových domén. Věc, která mi na celém procesu přišla mimořádně podivná, byla tak zvaná digitální lukostřelba, tedy způsob, který měl rozřadit posuzování žádostí o nové domény do jednotlivých dávek po 500. Princip měl být takový, že žadatel si v systému určil nějaký čas v budoucnosti a pak se snažil přesně v tento zvolený okamžik stisknout tlačítko. Rozdíl mezi zvoleným časem a skutečným časem “kliknutí” se měl změřit a žádosti žadatelů s menším rozdílem mezi těmito časy měly být posuzovány v dřívějších dávkách. Vzhledem k tomu, že časový rozdíl mezi první a čtvrtou dávkou bude nejméně 15 měsíců a ohledem na objem financí, o který se v nových doménách bojuje, je samozřejmě důležité, aby byl proces zcela transparentní a spravedlivý. Stále více lidí mělo ke zvolenému řešení, tedy digitální lukostřelbě, výhrady. Hlavním problémem bylo podivné technické řešení, které tak jak tak nahrávalo bitvě automatů a dalším problémem byl fakt, že nikdo, krom správců systému nebyl schopen ověřit, jestli je změřený výsledek správný. Navíc se bohužel celý systém choval velice podivně a nespolehlivě. Tyto a další problémy zvoleného řešení vedly k tomu, že se představenstvo ICANNu na zasedání v Praze rozhodlo celý proces zrušit. S tímto také bylo rozhodnuto, že se všechny žádosti začnou posuzovat ve stejný okamžik a dávkování bylo úplně zrušeno. To je poněkud překvapivé, když ICANN tvrdil, že má kapacitu pouze na 500 žádostí. Není úplně jasné, zda-li to platí pouze pro úvodní posuzovací fázi nebo i pro veškeré posuzování a jestli to znamená, že všechny žádosti budou finálně schváleny až ve stejný okamžik. Představenstvo každopádně hodlá o problému ještě dále přemýšlet a diskutovat s komunitou. To ovšem znamená, že posuzování žádostí určitě nabere nějaký skluz a všichni žadatelé budou čekat zase o něco déle než počítali, což je jistě bude stát nemalé zdroje. Bohužel tedy problémy startu nových generických domén pokračují nadále, což je velmi mrzuté u procesu, který byl nazván největší revolucí Internetu od jeho vzniku.

Ondřej Filip

Dnešní představení nového ředitele organizace ICANN bylo pro většinu zúčastněných obrovským překvapením. Fadi Chehadé je totiž člověk, který se v komunitě kolem ICANN nikdy nepohyboval a téměř nikdo jej nezná. Bohužel to tedy znamená, že by potřeboval nějaký čas, aby se s tímto velice specifickým prostředím seznámil. Času ale příliš mít nebude, protože vstupuje do ICANNu v období, kdy je v plném běhu jeho historicky největší projekt, tedy vznik nových domén nejvyšší úrovně. I když za jiných okolností bych kritizoval, že ICANN opět zvolil ředitele z anglicky mluvící země, v tomto případě to neudělám, protože Fadi rozhodně není typickým Američanem. Narodil se v Libanonu egyptským rodičům působil v severní Africe i na Středním východu, má tři občanství a plynně hovoří Anglicky, Francouzsky, Arabsky a Italsky. S jeho životopisem by mohl být velmi přijatelný právě pro arabské představitele.

Tedy přeji novému řediteli vše nejlepší. Ať pod ním již proces vzniku nových domén běží bez problémů, ať se rychle seznámí s celým zvláštním ekosystémem toho odvětví.

Ondřej Filip

Při příležitosti nedávné prezentace Knot DNS na Tech26 (CENTR Jamboree) jsme aktualizovali metodiku měření a chtěli bychom se podělit o nové výsledky.

Testování nyní proběhlo na syntetické zóně se zastoupením podporovaných RR typů na testovaných serverech (Knot DNS, BIND 9, NSD 3 a YADIFA[*]). Zóna obsahuje 1 324 899 záznamů, velikost zónového souboru je 76MB. Zároveň byly aktualizované testovací sady dotazů, které se nyní skládají z dotazů jak na existující, tak neexistující jména v poměru 1:1. Důvodem bylo prověřit výkon datových struktur serveru i při vyhledávání neexistujících jmen. Existující jména byla vybrána náhodným způsobem z tohoto zónového souboru. Konfigurace, zónový soubor, testovací sada pro program dnsperf (1 000 000 dotazů, 18MB) i syntetický provoz ve formátu pcap (50 000 dotazů, 4,2MB) jsou včetně dalších nástrojů volně ke stažení v Git repozitáři.

Prvním testem je škálovatelnost, kdy se měří závislost výkonu serveru na počtu spuštěných vláken/procesů. Výkon serveru je měřen programem dnsperf od společnosti Nominum. Tento test je specificky navržen pro měření výkonnosti autoritativních DNS serverů a mezi jeho přednosti patří regulace rychlosti dotazování, čímž poměrně věrně simuluje reálný síťový provoz. Jak je z grafu pro Linux patrné, podařilo se nám oproti verzi 1.0.3 vyřešit problém s plánováním vláken a nyní téměř dosahujeme naměřené propustnosti sítě. Ta byla změřena utilitou trafgen s malými UDP pakety (payload 60B) a zanesena do grafu. V případě tohoto testu nebylo možné určit u serveru Yadifa zadaný počet vláken, proto běží stále ve výchozím nastavení.

K testu škálovatelnosti nám přibyl nový test, který měří závislost podílu zodpovězených dotazů na rychlosti odesílaných odpovědí. Tento test byl dříve použit např. pro měření výkonnosti serveru NSD nebo nově Yadifa. V tomto testu figurují všechny tři stroje, kdy na prvním běží testovaný server, druhý pouze generuje provoz zadanou rychlostí a třetí zachytává odpovědi ze serveru. Pro testování byly využity standardní nástroje tcpreplay a tcpdump. Ze získaných dat se vypočte procento zodpovězených dotazů pro danou rychlost. Každý test je třikrát opakován a jako výsledek se počítá průměrná hodnota. Z grafu je patrné, že Knot DNS 1.0.6rc1 i na Linuxu zodpověděl téměř všechny všechny dotazy zaslané maximální dosažitelnou rychlostí.

Samotné testování probíhalo na třech shodných strojích osazených procesorem Intel Xeon X3430 a 2GB RAM, propojených 1Gb ethernet linkou se síťovými kartami Broadcom BCM5723. První stroj slouží k běhu serveru, druhý ke generování dotazů a třetí k zachytávání odpovědí. Testy byly prováděny na 64bit OS Linux 3.0.0 a FreeBSD-8.2. V současné době je výkon omezen dosaženou propustností sítě, nicméně chystáme testování s rychlejší síťovou kartou a věříme, že je ještě prostor pro další zlepšení.

Marek Vavruša

* – Yadifa bohužel podporuje jen omezenou sadu RR typů, nicméně pro tento druh testování to nevadí

Už tuto sobotu začnou v pražském hotelu Hilton první setkání v rámci 44. mítinku organizace ICANN. Již o den dříve ale oznámí předseda představenstva Steve Crocker společně s provozním ředitelem Akramem Atallahem, kdo bude novým výkonným ředitelem celosvětového správce sítě Internet. Současnému výkonnému řediteli Rodu Beckstromovi totiž končí jeho funkční období a rozhodl se už dále ve svém působení v rámci ICANNu nepokračovat. Pražské setkání pro něj tedy bude posledním v jeho současné roli. U příležitosti představení nového výkonného ředitele chystá ICANN v Praze tiskovou konferenci, na níž zve jak zástupce českých médií, tak další členy české internetové komunity. Toto setkání začíná v hotelu Hilton ve čtyři hodiny odpoledne našeho času. Pro zahraniční novináře, ale i pro všechny ostatní, kteří se nemohou zúčastnit a chtěli by znát jméno nové hlavní tváře ICANNu mezi prvními bude připraven online přenos.

Vilém Sládek

O tom, že Internet jako otevřená platforma, která překračuje prostor i čas, se úplně nepotkává s oficiální politikou autoritativních režimů (a nejen jich), netřeba dlouze diskutovat. O velkém čínském firewallu, blokování Twitteru v čase íránské zelené revoluce, vypnutí Internetu v Egyptě po protestech po volbách v roce 2011 a dalších toho bylo napsáno dost mimo náš blog, ale vždy se jedná či jednalo o jednotlivosti, které z technického pohledu narušují normální chování sítě.

Internetový draft DNS Extension for Autonomous Internet(AIP), který jako individuální podání poslali do IETF pánové Diao, Diao a Liao, ovšem tento systém „výpadků“ chce změnit. Nový návrh by počítal s tím, že by vedle stávajícího DNS stromu „zasadili“ další „autonomní“ DNS strom (či stromy), který by dle zvážení jeho správce obsahoval pouze některé top-level domény. Takových nezávislých stromů by mohlo být v Internetu více a přístup mezi nimi by byl zajištěn pomocí translačních bodů, které by odpovídaly dotazy ležící v uměle vytvořeném podstromu. Na stránky CZ.NIC by se z takové země pak dalo přistupovat jen pouze dotazem například na “www.nic.cz.资本主义的怪物”. Takový dotaz by byl předán příslušnému (pravděpodobně vládnímu) DNS serveru obsluhující doménu .资本主义的怪物, který by z dotazu odstranil příponu, předal jej například do DNS stromu, který je spravovaný ICANNem, a zpátky přeposlal odpověď (nebo také ne).

Osobně vnímám takovou iniciativu za velmi škodlivou otevřenému Internetu a domnívám se, že by IETF v žádném případě nemělo legitimizovat cenzuru tohoto druhu a zasadíme se o to, aby tento návrh v IETF neprošel.

Ondřej Surý

Nedávno jsme vydali další verzi naší služby mojeID s níž spatřilo světlo světa také pár zajímavých a užitečných novinek.

První z nich se týká především těch uživatelů, kteří se rozhodnou založit si své mojeID až teď. Při vybírání identifikátoru teď budou mít díky kontrole “as you type check” možnost zjistit, jestli je jimi vybraný identifikátor ještě volný nebo ho už získal někdo před nimi. Jedná se o poměrně drobné vylepšení, které ale, jak pevně věříme, povede ke zvýšení komfortu pro nově registrující se .

Druhá novinka je mnohem výraznější a týká se těch, kteří už mojeID účet mají a jsou zároveň držiteli domén .CZ. Pro tyto uživatele je tu teď možnost požádat si o skrytí jejich údajů v registru domén. Tato změna souvisí s úpravami v Pravidlech registrace, o nichž na tomto blogu psala před nedávnem kolegyně Zuzana. Důležité je podotknout, že uživatelé, kteří projeví o tuto možnost zájem, musí mít své mojeID validované.

Jak jsem uvedl na začátku, jedná se skutečně o pár změn. Kdybyste ale měli zájem vidět, jak vypadají v praxi, ještě než se sami pustíte do jejich využívání, doporučuju vám podívat se na náš další release log. Kolega Jaromír Talíř v něm mimo jiné mluví i o hlavním směru, kterým se bude naše služba v budoucnu ubírat.

Vilém Sládek

I přes problémy s aktualizací popsané v minulém zápisku se nakonec vše zdařilo, a byla možnost zjišťovat, co funguje a hlavně co fungovat přestalo. Při přihlašování na servery pomocí SSH jsem si všiml, že adresa posledního přihlášení se nejen mění, ale má i jiný tvar, než typická adresa získaná autokonfigurací. Přesněji v ní chyběl řetězec FF:FE, kterým se MAC adresa rozšiřuje na potřebných 64 bitů. Prefix sítě byl správný, jen druhá polovina adresy “neseděla”. Pro jistotu jsem se podíval ještě na svou IPv6 adresu a odpověď se ukázala sama (adresy mají pozměněný  prefix)

ip -6 a show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2001:db8:1234:abcd:758d:6a1e:9854:be4/64 scope global temporary dynamic
valid_lft 591274sec preferred_lft 72274sec
inet6 2001:db8:1234:abcd:1aa9:5ff:fef6:7230/64 scope global dynamic
valid_lft 2591970sec preferred_lft 604770sec
inet6 fe80::1aa9:5ff:fef6:7230/64 scope link
valid_lft forever preferred_lft forever

Důležitá je právě položka temporary u první adresy, označující dočasnou náhodnou adresu.

Ve jménu ochrany soukromí

Dočasné náhodné adresy jsou mechanizmem pro ochranu soukromí a přesněji jsou popsány v RFC4941. Důvodem pro zavedení je rozdíl mezi IPv4 a IPv6 adresou. IPv4 adresa je vždy unikátní a celá se získá od poskytovatele. V případě IPv6, při použití autokonfigurace, tvoří adresu sám koncový počítač. K získanému prefixu připojí svůj identifikátor, typicky ve formě modifikovaného EUI-64, který obsahuje MAC adresu použitého síťového rozhraní. Při přecházení mezi jednotlivými sítěmi tak dochází pouze ke změně prefixu sítě, ale druhá polovina adresy zůstává stejná. Vzniká tak možnost sledování uživatele ze strany poskytovatelů služeb jen na základě IPv6 adresy. Ze své podstaty se toto nebezpečí nevztahuje jen na webové služby, ale veškerý síťový provoz. Dočasné adresy možnost sledování konkrétního zařízení znemožňují a v nové síti generují nové identifikátory rozhraní nezávislé na MAC adrese. Adresy se krom přechodů mezi sítěmi přegenerovávájí v pravidelných intervalech i pokud se nacházíte stále v jedné síti.

Náhodně generované adresy se používají ve výchozím nastavení například ve Windows 7, nově však je generování a používání adres nastaveno jako výchozí i v Ubuntu a to právě od verze 12.04. Nastavení najdete v Ubuntu v souboru

/etc/sysctl.d/10-ipv6-privacy.conf

a jedná se o volby

net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2

Dvojka signalizuje generování a preferování náhodných adres, pro vypnutí postačí změnit hodnotu na nulu. Pokud naopak chcete například v starším systému ochranu soukromí zapnout, stačí nastavit tyto hodnoty právě na dvojku.

Momentálně se pracuje na vylepšené verzi, která by nabízela různé identifikátory v jednotlivých sítích, ale v rámci jedné sítě by zůstával identifikátor stejný. Tento přístup by mohl nastavit rovnováhu mezi ochranou soukromí uživatelů a kontrolou nad sítí z pohledu administrátorů.

Petr Černohouz

Jak jsme již informovali v této novince, v pátek 1.června se v sídle sdružení CZ.NIC uskutečnilo setkání v jehož rámci došlo k předání zkušenosti s provozováním národního CSIRT týmu zástupcům týmu CERT-RO (ten je stejně jako my akreditován u úřadu Trusted Introducer). Organizátorem akce byla Evropská agentura pro síťovou a informační bezpečnost (ENISA), jejímž primárním cílem je dosažení vysokého stupně informační a síťové bezpečnosti mezi členskými státy EU.

Na začátku setkání zazněly informace o historii budování CSIRT.CZ a jeho cestě do pozice Národního CSIRT České republiky, o organizační struktuře týmu, ale také sdružení CZ.NIC samotného, o práci Laboratoří CZ.NIC, které se ve svých projektech bezpečností také intenzivně zabývají, Akademii CZ.NIC a jejích vzdělávacích projektech atd. Kolegové z CERT-RO také ocenili informace o pracovní skupině CSIRT.CZ,  jejímiž členy jsou zástupci významných provozovatelů sítí, poskytovatelů obsahu, rizikových služeb, bezpečnostních složek České republiky, Českého telekomunikačního úřadu, sdružení CZ.NIC i NIX.CZ a akademického sektoru. Tato pracovní skupina umožňuje setkávání bezpečnostních expertů z uvedených organizací a také vzájemné předávání informací a zkušeností souvisejících s počítačovou bezpečností.

Během setkání jsme zástupce týmu CERT-RO informovali také o nástrojích, které používáme při řešení incidentů, ať už ticketovacího systému OTRS, různých linuxových utilit, rozšíření pro Firefox, či různých nástrojů dostupných on-line. Nejvíce však členy národního CSIRT týmu Rumunska zaujala aplikace, kterou vyvinuly naše laboratoře  a jako open source nabídli k používání i dalším registrům. Je to aplikace MDM, o níž jsme již psali zde  a jejíž nasazení pomohlo také k lepšímu postavení České republiky v různých statistikách phishingových stránek.

Kolegy z CERT-RO také zaujala prezentace životního cyklu incidentu od jeho vzniku až po jeho vyřešení. Během této přednášky jsme poreferovali o některých zajímavých, či zásadních incidentech, které jsme za poslední rok řešili. Hojně diskutovanou se stala také otázka proaktivního přístupu a úzké spolupráce na úrovni národních CSIRT týmů.

Setkání se zúčastnil také zástupce týmu CESNET-CERTS, který provozuje sdružení CESNET pro dohled nad sítí národního výzkumu a vzdělávání. Oba české bezpečnostní týmy spojuje dlouhodobá a velice úzká spolupráce na poli internetové bezpečnosti v této zemi. Zástupce CESNET-CERTS na tomto setkání prezentoval systém pro efektivní sdílení informací o bezpečnostních událostech. Jeho nasazení je ve spolupráci s CSIRT.CZ plánováno i na národní úrovni.

Dlužno říci, že i náš tým získal zajímavé nové informace. V Rumunsku je existence Národního týmu  zakotvena v zákoně a na jeho provozu se podílejí například i kmenoví zaměstnanci bezpečnostních sil. Rumunský národní CERT tým se také momentálně ve spolupráci s vládním sektorem pokouší o spuštění vlastního rozsáhlého IDS systému. Také je zajímavé, že registr rumunské národní domény .RO nezobrazuje a ani nepředává žádné údaje o držitelích domén, pokud jsou tito fyzickými osobami. Z pohledu práce CSIRT týmů je toto jasná nevýhoda při řešení incidentů. A zajímavost na závěr – pokud by někdo z vás toužil pracovat v Národním CSIRT týmu Rumunska, pak vězte, že minimálním požadavkem pro práci v tomto týmu je úspěšné složení certifikace Certified Ethical Hacker (CEH).

Pavel Bašta

Malware s digitálním podpisem už není žádná novinka, i když naštěstí pořád rarita – viděli jsme to u ukradených certifikátů (Stuxnet) a certifikátů se slabými faktorizovatelnými klíči. A teď ještě přibyl případ, kde se malware tvářil, jako by byl podepsán přímo od Microsoftu.

Všechny detaily ještě nejsou známé, občas se mlží, ale základní princip je už z některých zveřejněných řetězců certifikátů celkem jasný – Microsoft udělal “sub-CA” ze všech zákazníků jednoho produktu (enterprise verze Terminal Services), takže mohli podepisovat jakýkoli kód libovolným jménem. Certifikáty Microsoftu umožňující tento podpis jsou již revokovány, původní security advisory je v následujících článcích:

• Microsoft Security Advisory (2718704)
• Unauthorized digital certificates could allow spoofing
• Microsoft certification authority signing certificates added to the Untrusted Certificate Store

CrySys zveřejnil ukázku řetězce certifikátů, na které lze vidět jak celý “trik” funguje:

1. sub-CA “Microsoft Enforced Licensing Registration Authority CA” se řetězí přes “Microsoft Enforced Licensing Intermediate PCA”, která je podřízená sub-CA pod “Microsoft Root Authority” CA
2. “Microsoft Root Authority” je kořenová autorita, jejíž certifikát je přítomen v systémovém úložišti certifikátů Windows
3. podle OID v X509v3 rozšíření Extended Key Usage je použití certifikátů pro: Code Signing, Key Pack Licenses (szOID_LICENSES), License Server Verification (szOID_LICENSE_SERVER)
4. certifikáty neobsahují žádné omezení týkající se jmen (rozšíření Name Constraints není přítomné)
5. tudíž jakýkoli podpis kódu ověřený přes tento řetězec se ukáže jako správný

V ukázce od CrySys je certifikát na čtvrté úrovni (Level 4) zřejmě certifikátem sub-CA, který zákazníci mohli použít pro podpis koncového certifikátu kódu. Znamená to, že k němu měli privátní klíč nebo fungovali jako registrační autorita (RA) – tj. nadřazená CA jim poskytovala “orákulum”, které podepsalo cokoliv (z popisu to není úplně jasné, variantě o RA by odpovídala i zkratka LSRA).

Hlavním problémem zde není ani použití PKI per se, ale spíše drobný “detail”, díky němuž se celý řetězec certifikátů řetězil ke kořenovému certifikátu v systémovém úložišti (je označen jako důvěryhodný). Jedna spekulace říká, že si vývojáři nebo architekt chtěli ulehčit život a místo separátní CA použili právě tu existující (ta ale měla vedlejší efekty).

V KB Microsoftu byly ještě zmatené zmínky o MD5 kolizích, ale žádné páry kolizních certifikátů nebyly k dispozici. Až nedávno se na MSDN objevil článek Flame malware collision attack explained, který sice ty kolizní certifikáty taky nemá, ale z analýzy certifikátu je vidět, že certifikát je “podivně” pozměněn – chybí některé X.509v3 extensions. Při zkoumání se v certifikátu objevilo podivné pole Issuer Unique Identification (v praxi se téměř nepoužívá). To vzniklo právě kolizí a právě bity kolize způsobily, že se tělo pole natáhlo přes zbytek struktury ASN.1 – tudíž se “nepříjemná” Hydra extension (OID 1.3.6.1.4.1.311.18, označená navíc jako “critical”) stala tělem nějakého řetězce – ten se neparsuje jako extension, tudíž už nepředstavuje problém.

Využití MD5 kolize je založeno na stejném triku, jaký jsem kdysi použil pro demonstraci já nebo mnoho jiných – “binární bordel” je potřeba nastrkat do nějaké “vaty” v datové struktuře (tak, že se neovlivní zásadně sémantika změněných dat). Je ale potřeba trochu experimentovat, než člověk trefí správné bity a správné délky. Ty kolizní certifikáty zřejmě podepisovalo “podepisovací orákulum” někde u Microsoftu; toto orákulum ale nechtělo podepsat libovolný certifikát. Tak si útočníci pomohli s kolizí, při níž jim navíc hrál do karet fakt, že sériové čísla certifikátů a pár dalších polí byly lehce predikovatelné. Musím říct, že je to dost chytrý a elegantní útok. Nečekal jsem, že bych ho po tolika letech viděl “v divočině”.

Stevens a de Weger (autoři proof-of-concept certifikátů s MD5 kolizemi) tvrdí, že MD5 chosen-prefix-collision útok ve Flame je nový oproti jejich útoku. Nicméně myšlenka zůstává stejná – mít možnost zostrojit kolizi pro libovolné IV (odtud chosen-prefix – útočník si může vybrat libovolný kus dat délky násobku bloku před kolizí). Tím pádem novost spočívá pravděpodobně v rychlosti vytvoření kolize nebo menší počet CSR požadavků, než se útočník strefil do očekávaného sériového čísla a času, aby získal pár kolizních certifikátů.

Na závěr trocha odlehčení – CrySys poslal výzvu autorům Duqu, ať zveřejní kód, protože podléhá GPL.

Ondrej Mikle

Na konci dubna vydal CZ.NIC tiskovou zprávu zmiňující mimo jiné to, že je Česká republika světovým lídrem v zavádění IPv6, alespoň co se obsahové stránky internetu týče. Vzhledem k tomu, že IPv6 Observatory, z které jsme statistiky přebírali, je aktualizována každý den, zajímalo mě, jak se „Den šestek“ (6. 6. 2012) na těchto statistikách projeví a zda si naše země své prvenství udrží.

Podle zmíněného průzkumu stojí za připomenutí, že 28. března, kdy IPv6 Observatory publikovala první měření, se Česká republika umístila na špičce žebříčku s 8,6 % reprezentujících v absolutních číslech 43 nejvýznamnějších českých webů. V této souvislosti stojí za připomenutí, že na rozdíl od statistik laboratoří CZ.NIC sledující AAAA záznamy v doméně .cz, vychází evropský projekt „IPv6 Observatory“ z 500 nejnavštěvovanějších stránek dle serveru Alexa.com, která mezi české (resp. spíše bychom měli mluvit o „z České republiky navštěvované“) stránky zahrnuje např. LinkedIn, PayPal YouTube, ale i The Pirate Bay či mail.ru, Yandex.ru apod. Na druhou stranu podobné „odchylky“ se vyskytují u všech států a výsledky IPv6 Observatory je tak možné považovat za „spravedlivé“.

Výsledky z prvního červnového dne stále potvrzovaly vedení ČR s 9,4%, druhou příčku pak obhájilo Lucembursko (5,6 %) a třetí v těsném závěsu Slovinsko (5,4 %). Den po World IPv6 Launch Česká republika stále vede a jako první (a jediná ) se přehoupla přes 10 % (přesně 10,4), druhé Slovinsko pak, řečeno sportovní terminologií, ztrácí 18 bodů (stránek), tedy celých 3,8 %. Nárůstu stránek v našich národních barvách pomohla především podpora Seznamu, ale také například Centra Holdings a jejich služeb.

Statistika IPv6 Observatory pak ukázala, že jedinou zemí v průzkumu, ve které se šestkový den neprojevil, je Čína. Vzhledem k tomu, že IPv6 Observatory zobrazuje pouze aktuální výsledky, přichystali jsme pro vás srovnávací graf ukazující nárůst počtu stránek s podporou IPv6. Bez zajímavosti pak není ani to, že zatímco na konci března činil průměr všech zemí zahrnutých v průzkumu 2,4 %, po 6. 6. počet stránek narostl o více než dvě třetiny a nyní hodnota „indexu“ dosahuje 3,7 %.

Podobný nárůst jako IPv6 Observatory zaznamenaly i statistiky našich laboratoří, podle nichž počet webů se šestkou stoupl téměř o tři procenta na 13,28 % a kdy stojíme již jen krůček, respektive 0,42 %, od hranice, kdy bude IPv6 podporovat již polovina DNS serverů. Zde je třeba dodat, že za nárůstem u webů stojí především krok registrátora ACTIVE 24, který včera na konferenci oznámil zpřístupnění IPv6 více než 38 tisíc „svých“ domén, z toho 28 tisíc .cz. Nezanedbatelnou práci ale odvedla i řada drobných hráčů včetně veřejné správy. Z vládních institucí se k World IPv6 Day připojilo Ministerstvo školství, mládeže a tělovýchovy a Úřad průmyslového vlastnictví, k jejichž zapojení pomohl rovněž dopis, který na základě našeho průzkumu rozeslalo všem orgánům bez podpory IPv6 (a tím porušujících Usnesení vlády) Ministerstvo průmyslu a obchodu. Vedle státní správy našel včerejší den ohlas i u samosprávy a ke zpřístupnění obsahu přes šestku se připojilo i 12 českých měst (Aš, Frenštát pod Radhoštěm, Hodonín, Jihlava, Kladno, Milevsko, Neratovice, Přelouč, Valašské Klobouky, Votice, Vsetín a Vyškov), jejichž weby spravuje společnost Webhouse. Zde stojí za zmínku, že z 205 měst s tzv. rozšířenou působností jich šestku podporuje jen 15, což je cca. polovina národního průměru dle našich laboratoří.

Zdá se, že IPv6 Day tak přinesl své ovoce a podpora šestky přestává být, alespoň na straně obsahu, polem neoraným. Doufejme, že podobné nárůsty budeme moci brzo zaznamenat i u providerů či výrobců domácích routerů. Pokud chcete zjistit, zda právě vaše domácí krabička již má podporu nové verze IP protokolu, není niž snazšího, než se podívat do našeho katru!

Jiří Průša