I když v procesu incident handlingu vystupují obvykle národní CSIRT týmy spíše jako jakýsi „institut poslední záchrany“, rozhodně by měly dle svých možností a v rámci svého pole působnosti také aktivně upozorňovat na existující i potencionální bezpečnostní incidenty. I my se v rámci našeho týmu CSIRT.CZ snažíme nejen co nejefektivněji řešit reportované incidenty, ale pokud máme příležitost, chceme být proaktivní také v přístupu k bezpečnosti českého internetového prostředí. Jak může tato proaktivita vypadat v reálu si ukážeme na vybraných příkladech z poslední doby.
Před několika dny jsme kontrolovali jednu internetovou stránku kvůli podezření na šíření virové nákazy; jednalo se o web, který se přímo zabývá hackingem. Na něm jsme narazili na článek informující o možných zranitelnostech některých internetových stránek státní správy. Šlo o chyby v rozsahu od XSS, přes SQL injection, až po možnost procházet obsah adresářů.
Uvedené zranitelnosti mohou vést k různým způsobům zneužití – získání neoprávněného přístupu k informacím, změny obsahu stránek, či útoku na uživatele takovéhoto webu. Z těchto důvodů jsme riziko vyhodnotili jako vysoké a rozhodli jsme se informaci o zveřejnění těchto bezpečnostních problémů zaslat správcům jednotlivých stránek.
Dle dlouhodobé zkušenosti našeho týmu velká část správců na incidenty reaguje opravením reportovaného problému, avšak na naši původní zprávu již většinou neodpoví. Stejně tomu bylo i v tomto případě. V současné chvíli většina z problematických nastavení na stránkách již není, reakci ale máme pouze od jednoho ze správců. Pro nás je však nejdůležitější, že se nám i tímto krokem podařilo přispět k větší bezpečnosti uživatelů internetu a také ukázat, že národní bezpečnostní tým nespoléhá pouze na nahlášené incidenty.
Příkladem jiného druhu proaktivity může být i nedávná akce CSIRT.CZ – rozeslání informačních dopisů správcům DNS serverů, u kterých existuje vysoké riziko možného útoku pomocí DNS cache poisoningu. S pomocí Laboratoří CZ.NIC jsme při této akci oslovili více jak 1400 firem a institucí v rámci celé republiky. Zatím nemáme přesná data o úspěšnosti celé akce, avšak při první vlně, kdy jsme zkušebně odeslali prvních 100 dopisů, byla úspěšnost, tedy změna konfigurace DNS serveru směrem k lepšímu zabezpečení, okolo 13 procent.
Dalším aktuálně provozovaným proaktivním prvkem v rámci CSIRT.CZ je například detekce útoků pocházejících z počítačových sítí v České republice za pomoci intrusion detection system (IDS), který je provozován ve spolupráci se sdružením CESNET. Tento systém po zachycení pokusu o útok automaticky informuje správce příslušné sítě, který tak má možnost ihned reagovat na vzniklý incident a zamezit případnému průniku do dalších systému nebo šíření virové nákazy.
Osobně doufám, že počet proaktivních prvků v rámci provozu národního CSIRT týmu bude narůstat a že vás tak v budoucnosti budeme moci informovat o dalších úspěšně zrealizovaných akcích CSIRT.CZ směřujících k větší bezpečnosti „sítě sítí“.
Pavel Bašta, CSIRT.CZ a CZ.NIC-CSIRT
Biorytmy v DNS provozu
Ať chceme nebo nechceme, celý náš život je řízen rytmy okolního prostředí. Některé vycházejí z fyzikální podstaty našeho světa, jako střídání noci a dne při otáčení naší planety kolem její osy, či cyklus ročních období při její rotaci kolem slunce. Jiné, jako měsíce či týdny, jsme si vytvořili uměle (možnost souvislosti délky týdne s dobou potřebnou ke stvořením světa nechám na kritickém posouzení laskavého čtenáře), ale jejich vliv na nás není o mnoho menší. Koneckonců kdo z nás nikdy netrpělivě nečekal, až se mu účtu konečně opět po měsíci objeví výplata…
I přesto, že počítače jsou věci (zatím) neživé, biorytmy, které řídí život člověka se přenášejí i na ně. V případě CZ.NIC můžeme tyto sledovat na provozu našich DNS serverů a právě tomuto tématu bych rád věnoval dnešní krátký příspěvek.
Na následujícím obrázku se můžete podívat na ukázku toho, jak vypadá například běžný měsíční provoz na našich DNS serverech.
Na první pohled je tu patrné střídání dne a noci a hned na ten druhý také týdenní cyklus s výrazně nižším provozem o víkendu.
Denní cyklus si můžeme blíže prohlédnout na následujícím obrázku.
Na něm je zobrazena průměrná středa v našem DNS provozu za posledních cca 20 měsíců. Protože jsou data zprůměrována přes relativně dlouhou dobu, vyhladily se případné výkyvy v provozu. Z grafu můžeme vyčíst například fakt, že minimální provoz je cca kolem 4. hodiny ráno a přibližně mezi 5. a 10. hodinou se provoz zdvojnásobí s tím, jak lidé přijíždějí do práce, zapínají počítače a začínají brouzdat. Kolem 12. hodiny je malý ale patrný útlum, kdy lidé postupně odcházejí na oběd, aby se posíleni opět vrhli do práce a způsobili tak maximum aktivity mezi 14. a 15. hodinou. Poté aktivita mírně klesá a po posledním záchvěvu, který najdeme kolem 20:00, rychle upadá k nočním hodnotám.
Na dalším grafu najdeme podobně vytvořený průběh průměrného týdne.
Ten nám kromě zhuštěného náhledu na typický pracovní den s jeho přestávkou na oběd a večerním krátkým vzrůstem aktivity ukazuje, jak se vyvíjí provoz od pondělí do neděle. Zatímco první čtyři pracovní dny jsou téměř totožné, v pátečním průběhu je již zřetelně vidět pracovní únava a v odpoledních hodinách naplnění touhy po brzkém odchodu domů, které se projeví výrazně rychlejším a větším poklesem aktivity.
Víkendový provoz je pak o poznání slabší, se zvýšenou aktivitou v neděli večer, která je srovnatelná s páteční.
Pokud si po přečtení předchozích řádků říkáte s Cimrmanem, „To ani nemusel psát. To každý ví.“, mám pro vás ještě jeden graf. Ten sice také nepřekvapí, ale alespoň je v něm nějaká věda.
Jedná se o výsledek analýzy periodicity DNS provozu získaný Fourierovou transformací vstupních dat (pro přehlednost je uveden jen výřez grafu). Kromě silné denní periodicity je zde vidět i závislost týdenní. Za zmínku pak stojí také slabší zastoupení period kolem 0,5 a 3,5 dne. První z nich je způsobená výše zmíněným poklesem provozu kolem poledne, zastoupení druhé pak souvisí s náhlými změnami mezi pracovními a víkendovými dny.
Doufám, že pro vás byla pozorování z tohoto článku zajímavá a že vás třeba, podobně jako mě při psaní, přivedou k zamyšlení nad tím, jak moc jsme rytmy okolního prostředí ovlivňováni a kam vlastně až tento vliv sahá.
Bedřich Košata, Laboratoře CZ.NIC
Ospalé evropské září
I když v srpnu zmizelo 8,5 miliónu IPv4 adres, přesto se datum vyčerpání adres v dalším RIRu oddálilo. Jak je to možné? Je to způsobeno tím, že Evropané, kteří jsou konci IPv4 aktuálně nejblíže, si tak trochu prodloužili prázdniny a alokovali v podobném tempu jako v srpnu. Skončili tak na třetím místě. Nejméně si vyžádali Afričané, kteří při pouhých jedenácti schválených žádostech alokovali dokonce ještě méně než „vyprázdněný“ region Asie-Pacifik. První skončili překvapivě obyvatelé Latinské Ameriky, kteří spotřebovali téměř polovinu všech adres. Situaci ilustruje následující graf.
Dlužno podotknout, že na prvenství Latinské Ameriky se podepsaly především dvě velké alokace. Global Village Telecom alokoval v Brazílii 2 milióny adres a polovinu této sumy si vyžádal Telecom Argentina. Každopádně běžné tempo v tomto regionu bývá nízké, a tak se konec IPv4 zde příliš nepřiblížil.
Z pohledu jednotlivých zemí lze konstatovat, že i přes tyto velké alokace nebyla Brazílie ani Argentina největším konzumentem IPv4 adres. Nejvíce jich tentokrát alokovaly Spojené státy, na které obvykle připadne většina spotřeby severoamerického regionu. Rozdělení alokací podle států ukazuje následující graf.
Ani situace kolem IPv6 alokací nebyla nijak zásadně významná, bylo alokováno 146 IPv6 prefixů, z toho jeden směřoval i do České Republiky. Tímto se počet tuzemských IPv6 zvedl na ve dvojkové soustavě číslo 128.
Druhý slabší měsíc již pohnul se předpovědmi konce IPv4 v Evropě, což je jistě příjemná zpráva. Aktuálně to vypadá, že bychom mohli mít IPv4 adresy ještě na začátku léta. Je dost dobře možné, že jde již o přímý důsledek restriktivní politiky RIPE. Uvidíme, jestli to potvrdí i příští měsíc. Vzhledem k tomu, že tento příspěvek je psán poněkud později a máme téměř jednu třetinu října za sebou, mohu prozradit, že alokační tempo se zatím nezrychlilo.
Ondřej Filip
Kouzlo standardizovaného řešení
Je tomu přibližně čtvrt roku, co do datových schránek přibyla možnost rozšířit autentizaci přihlašovacím jménem a heslem o hesla jednorázová (OTP – One Time Password). Toto rozšíření umožňuje výrazně zvýšit zabezpečení datové schránky před prolomením či odcizením hesla.
Jednorázová hesla v datových schránkách si může uživatel buď generovat na mobilním zařízení a nebo nechat zasílat pomocí SMS. Vzhledem k tomu, že druhá možnost je placená, upne se asi většina zájemců o tuto funkci k variantě první. Díky tomu, že se programátoři datových schránek rozhodli v tomto případě použít standardní algoritmus pro jednorázová hesla (RFC 4226), je možné pro jejich generování využít aplikace třetích stran.
Datové schránky oficiálně podporují tři různé aplikace pro platformy iOS, Android a Java ME. Použití standardizovaného OTP algoritmu by však mělo umožnit využít i další podobné programy a dát tak uživatelům větší možnost volby. Jednou z aplikací tohoto druhu je Google Authenticator.
Google zavedl jednorázová hesla jako volitelnou možnost při přihlašování k účtu v únoru toho roku. Způsob jakým se jednorázová hesla u Google aktivují a používají je z pohledu uživatele trochu odlišný, ale základní myšlenka doplnit standardní hesla o další autentizační prvek je stejná. Google by však jako jedna z největších IT firem současnosti asi jen těžko přenesl přes srdce použití aplikace třetích stran pro potřeby vlastních uživatelů a vznikl tak již zmiňovaný Google Authenticator. Ten implementuje stejný standardní algoritmus generování OTP a podporuje platformy iOS, Android a Blackberry (a pro potřeby serveru obsahuje také PAM modul).
Protože OTP používám jak pro datové schránky, tak pro svůj Google účet a protože jako zaměstnanec CZ.NIC LABs musím být od přírody zvědavý, zajímalo mě, jestli půjde Google Authenticator použít i pro datové schránky.
Ukázalo se, že to opravdu jde a jediná komplikace je ve formátu v jakém se předává vstupní tajný klíč mezi serverem datových schránek a mobilní aplikací při prvotní aktivaci OTP. Zatímco datové schránky a jimi doporučované aplikace používají hexadecimální (tedy Base16) formát, Google Authenticator používá Base32. Celý problém použití Google Authenticatoru pro datové schránky se tedy redukuje na triviální úkol převodu mezi těmito dvěma kódováními.
Aby to však nebylo příliš jednoduché, trochu jsem si úlohu zkomplikoval. Google Authenticator totiž oproti ostatním aplikacím nabízí jednu vlastnost, kterou každý, kdo musel přepisovat 40 znaků v hexadecimálním zápisu z mobilu do počítače, určitě ocení – synchronizaci tajného hesla mezi serverem a mobilním zařízením pomocí QR kódu.
Abych již dále neprotahoval již tak dlouhý příspěvek, výsledkem je mini „aplikace“ v čistém JavaScriptu, kterou najdete na konci příspěvku. Ta umožňuje vygenerovat si na straně uživatele v prohlížeči tajný klíč, který poté pouze zkopíruje do systému datových schránek a zároveň jej přes QR kód nahraje do Google Authenticatoru na svém mobilu. Není tedy potřeba nic přepisovat a kontrolovat a pokud už Google Authenticator používáte, ani instalovat kvůli datovým schránkám další aplikaci.
Na závěr tedy nezbývá než pochválit tvůrce datových schránek za to, že si na rozdíl od některých dřívějších rozhodnutí tentokrát vybrali standardizované řešení. Usnadnilo to práci jim i uživatelům a dalo nám to možnost větší volby.
Poznámka: Protože celý proces generování tajného kódu i odpovídajícího QR kódu probíhá ve vašem prohlížeči, nemusíte se bát uniku informací a jejich potenciálního zneužití.
Bedřich Košata, Laboratoře CZ.NIC
P.S.- pokud nad tímto textem nevidíte QR kód, váš prohlížeč pravděpodobně neumí HTML canvas (např. IE), který je nutný pro generování QR kódu na straně klienta.
Aktuálně o FREDovi
Minulý týden k nám zavítala čtyřčlenná delegace z estonského registru. Jak jsme již psali dříve, Estonci pro správu domény používají náš registrační systém FRED. Důvodem jejich návštěvy byl hlavně zájem o naše zkušenosti se zaváděním technologie DNSSEC a potom samozřejmě také prohloubení spolupráce na vývoji registračního systému. Postupně nás seznámili se změnami, které oni sami implementovali do systému a zjišťovali, co jsme od jimi použité verze implementovali na naší straně. Jejich nejvýraznějším rozšířením je autorizace významných operací podepsanou žádostí v digitální formě připojenou k požadavku registrátora. Estonci také např. plně implementovali IDN a do budoucnosti připravují ještě další omezení do EPP protokolu pro své registrátory. Bohužel to zároveň ukazuje, jak specifické jsou požadavky jednotlivých registrů a jak bude udržení jedné společné báze problematické.
Prakticky ve stejnou dobu jsme se dozvěděli, že v Albánii místní správce domény zveřejnil výběrové řízení na implementaci nového registračního systému pro doménu .al. V definici podmínek výběrového řízení zjevně vycházel z našeho registračního systému, neboť vzápětí se ozvalo několik firem s žádostí o spolupráci nebo s prosbou o školení práce s FREDem. Dost možná, že se tak Albánie brzy stane sedmou zemí používající náš registrační systém.
Jaromír Talíř
Je potřeba zveřejňovat údaje držitelů domén v databázi whois?
Čas od času se na nás obracejí držitelé domén s dotazem, proč se jejich údaje zobrazují v prohledávání údajů na webových stránkách sdružení. Právě této otázce se bude věnovat tento příspěvek.
Ustanovení o zpřístupnění údajů držitele domény ve veřejné části registříku domén (whois) je součástí pravidel registrace již více než 12 let a za tu dobu prošlo několika proměnami. Poslední, a to poměrně výrazná změna, se datuje na podzim r. 2007, kdy se upravovala pravidla registrace v souvislosti s přechodem sdružení CZ.NIC z outsourcovaného systému správy domény na systém vlastní.
Na začátek opět něco málo teorie – na nakládání s osobními údaji pamatuje český právní řád, a to především v zákoně č. 101/2000 Sb., o ochraně osobních údajů, který nabyl účinnosti již před více než 10 lety (a jak je u nás dobrý zvykem, byl za tu dobu již mnohokrát novelizován…). Tento zákon zahrnuje mezinárodní principy ochrany osobních údajů a jeho účelem je zajištění ochrany osobních údajů, způsob jejich zpracovávání (a to včetně předávání do zahraničí) a upravit vztahy, které v této souvislosti vznikají. Na zákonnou úpravu pochopitelně pamatovala a pamatují pravidla registrace doménových jmen, která s ní nemohou být v rozporu. CZ.NIC, jako správce osobních údajů, musí splňovat zákonné podmínky, na druhou stranu má vůči subjektům osobních údajů určitá práva – např. vyžadovat, aby údaje uvedené v centrálním registru byly správné, protože s odkazem na ustanovení § 5 odst. 1 zákona je povinen zpracovat pouze přesné osobní údaje.
Pokud se vrátíme k pravidlům registrace, která vstoupila v platnost v říjnu 2007, pak z hlediska ochrany údajů tato pravidla poprvé přinesla nejen držitelům domén, ale vůbec všem kontaktům, které se v databázi domény objevují v různých rolích, možnost označit určité údaje jako skryté – takto označené údaje se pak nezobrazují ve veřejné části prohledávání (namísto nich je uveden text „neveřejný údaj“) a jsou k dispozici pouze pro interní potřeby sdružení a registrátorů jako jeho smluvních partnerů. V kontaktu mohou být skryty e-mailová adresa, e-mail pro oznámení, telefonní a faxové číslo, DIČ nebo jiná číselná identifikace (např. datum narození, číslo pasu, OP, IČ…). Přístup do veřejné části whois je navíc chráněn proti automatickým dotazům použitím technologie captcha, kdy uživatel musí rozeznat a zadat bezpečnostní kombinaci znaků.
Mezi údaje, které v kontaktu naopak skrýt nelze, patří jméno a poštovní adresa. Tato skutečnost má své opodstatnění – nejen užíváním domény, ale i její pouhou registrací může dojít i zásahu do práv třetích osob. Takový zásah může mít podobu nejen v tuto chvíli např. všeobecně známé registrace domény s názvem, který má chráněn někdo jiný jako ochrannou známku, ale čím dál častější je i šíření nevyžádané pošty či škodlivého obsahu (malware), publikace obsahu, který je v rozporu se zákonem (propagace a prodej neschválených léčiv, šíření dětské pornografie a podobně). V takových případech toto nezbytné minimum údajů umožňuje poškozeným subjektům, případně příslušným státním orgánům, obrátit se přímo na držitele domény či jiný kontakt v doméně uvedený nebo rovnou zahájit potřebné právní kroky.
Podobně tyto údaje umožňují držitelům domén okamžitě zkontrolovat, že na ně určitá doména skutečně je registrována – to má význam například při odkupu domény a vazbě úhrady kupní ceny na realizaci převodu.
Je tedy zřejmé, že uvádění jména a poštovní adresy držitele domény (nebo také administrativního nebo technického kontaktu) má své opodstatnění. Podobně k uvádění některých údajů ve veřejné části prohledávání přistupují i jiné evropské registry; zmíním například Německo (i zde je možné, stejně jako u nás, skrýt telefonní a faxové číslo nebo e-mailovou adresu), Slovensko nebo Belgii (zde registr skrývá osobní údaje držitelů – fyzických osob a vydává je pouze na „oprávněnou“, resp. „opodstatněnou“ žádost – na tomto místě vyvstává otázka, která žádost je a která není dostatečně opodstatněná, neboť kritéria nejsou v pravidlech belgického registru stanovena).
Zuzana Durajová
Srpnové zpomalení
Na rozdíl od poměrně překvapivě alokačně silného července nás v srpnu žádné překvapení nečekalo. IPv4 adresy ubývaly skutečně prázdninovým tempem a díky tomu byl předpokládaný konec IPv4 v Evropě přeci jenom o pár dnů odložen. Ale pojďme se na věc podívat popořádku:
Pomyslný závod regionů vyhrála po diskvalifikaci Asie-Pacifiku opět Evropa. Evropané spotřebovali téměř 60 % všech v srpnu přidělených adres. Nečekané je druhé místo obvykle slabšího regionu Latinské Ameriky. Afričané nedokázali ani předběhnout Asii-Pacific, kde se alokuje už pouze v nouzovém režimu. To může mít hodně vysvětlení, ale zatím se jeví, že k transferu IPv4 adres z afrického regionu nedochází. Celou situaci ilustruje následující graf.
V žebříčku jednotlivých zemí se mezi prvními deseti objevily státy, které na tomto místě nejsme příliš zvyklí vídat. Šlo například o Peru, Chile, Spojené Arabské Emiráty či Katar. Podotýkám, že dva posledně jmenované státy patří do evropského regionu. První příčku obsadila jako již tradičně země ze stejného regionu, tentokrát to bylo Rusko. Celou situaci můžete vidět na následujícím grafu.
IPv6 alokace si naštěstí udržely slušné tempo. Proti červenci dokonce přidaly. V srpnu přibylo 172 nových alokací, z toho 84 v Evropě a po 28 v Asii-Pacifiku a Severní Americe.
Jak už jsem v úvodu zmiňoval, slabší tempo nám trochu oddálilo problém s docházením IPv4 v Evropě, nicméně pořád se bavíme o březnu 2012, což je již proklatě brzy. Uvidíme, zdali konec prázdnin povzbudí firmy k větší alokační aktivitě.
Ondřej Filip
Zabezpečení českých DNS resolverů
CZ.NIC se už po několik let účastní projektu DITL (A Day in the Life of the Internet), tedy volným překladem „Den života Internetu“, který je zastřešen organizacemi CAIDA a OARC. Účelem projektu je shromáždit datový provoz kořenových jmenných serverů a TLD autoritativních jmenných serverů z co nejvíce zdrojů a poskytnout tak možnost výzkumníkům zkoumat různé aspekty chování Internetu.
V letošním roce proběhl sběr dat v dubnu a trval dva dny. Využili jsme tedy nasbíraných dat a provedli analýzu českých resolverů na úroveň jejich zabezpečení z pohledu útoku typu otráveni „cache“ paměti DNS resolveru. Přesněji jsme zkoumali, jaké zdrojové porty daný DNS resolver používá u dotazů na autoritativní jmenné servery české domény .CZ. Pokud by resolver používal pořád stejný port (statický) či porty z posloupnosti (sekvenční), byl by velice snadno náchylný na Kaminského verzi DNS útoku na otrávení paměti DNS resolveru. Tím „snadno“ je myšleno útok v rámci sekund či minut bez potřeby náročného HW či velkokapacitního pásma pro připojení k Internetu. Raději ještě připomeneme, že pod pojmem otrávení paměti DNS resolveru si čtenář může představit situaci, kdy namísto své oblíbené webové stránky může být přesměrován na falešnou stránku útočníka a to změnou IP adresy k doméně v paměti jim používaného DNS resolveru.
A konečně se dostáváme k číslům. Z celkového počtu 32 408 českých DNS resolverů je snadno napadnutelných 6 519 serverů, což je 20.12 %. S ohledem na fakt, že už pěknou řádku let jsou k dispozici verze DNS serverů s pseudonáhodně generovanými zdrojovými porty, by mnozí z nás čekali toto číslo o něco nižší. Z výše uvedeného počtu napadnutelných serverů používá statické porty 4 017 serverů (12.40 %) a sekvenční porty 2 502 (7.72 %) serverů.
Dalším zajímavým údajem je procentuální zastoupení těchto snadno napadnutelných resolverů v celkovém provozu českých DNS serverů na .CZ domény a to je 12.15 %. Z něhož 10.76 % jsou resolvery používající statické a 1.39 % sekvenční porty. Dvanáct procent není zanedbatelných a proto už nyní CZ.NIC připravuje určité kroky pro zvýšení bezpečnosti uživatelů těchto DNS resolverů.
Výše uvedené statistiky napomáhají mapovat situaci zabezpečení DNS v České republice a proto budou ke konci roku 2011 doplněné ještě o analýzu DNSSEC; informace jsou pravidelně uveřejňovány na stránkách labs.nic.cz.
Emanuel Petr, Laboratoře CZ.NIC
Dodatek: Své DNS servery můžete otestovat webovým testem Web-based DNS Randomness Test nebo z příkazového řádku porttest.dns-oarc.net.
Registrátorské „prázdniny“ pokračují
Když jsme na konci července připravovali článek o letní aktivitě registrátorů domén, naznačil kolega v jeho závěru, že to možná není vše, co nás z jejich strany v blízké době potká. A nespletl se. V ZONERu a Active24 probíhalo toto léto asi trochu jinak než u většiny z nás.
Vezmu to chronologicky. Hned na začátku srpna oznámil registrátor ZONER automatické zavedení DNSSECu pro všechny u něj nově zaregistrované domény .CZ. DNSSEC samozřejmě není povinností. Zákazník si může podepsání DNS záznamů u domény kdykoliv zrušit. Ukažte mi ale zodpovědného držitele domény, který by to dobrovolně udělal :). Možnost nechat si zdarma zavést DNSSEC ale neplatí jen pro nové domény. Tuto funkci si mohou zapnout i ti stávající.
Druhý letní projekt spatřil světlo světa právě dnes. Active24 totiž právě oznámil spuštění aplikace sloužící registraci a obsluze domén .CZ. Jednu takovou jsem tu už před časem recenzoval, jednalo se o aplikaci určenou pro majitele zařízení iPhone. Tentokrát se jedná o aplikaci pro majitele mobilů s operačním systémem Android. Kromě registrace domén umožňuje tento program také nastavovat nameservery a u domén .CZ potom i ID držitele, administrativní kontakt a KEYSET.
Martin Peterka
Ředitel ICANNu ohlásil svůj odchod
Celkem nedávno jsem glosoval, že v organizaci ICANN došlo ke změně na postu předsedy představenstva. Jako jeden z nejbližších úkolů pro Steva Crockera jsem zmínil i revizi kontraktu stávajícího ředitele Roda Beckstroma. Jak se zdá, tento úkol je už splněn, protože Rod ohlásil, že po skončení svého tříletého období nebude ve funkci pokračovat. Tento okamžik nastane zhruba za rok, 1. července 2012. Bylo v podstatě veřejným tajemstvím, že mezi těmito dvěma muži nepanuje absolutní harmonie. A jak už jsem na stránkách tohoto blogu naznačoval, Rod nebyl v komunitě přijat jednoznačně kladně, a proto se tento krok dal očekávat. Tímto ovšem stojí před Stevem a jeho kolegy z představenstva úkol nový a to výběr nového ředitele. Vzhledem k tomu, že Rod byl člověk z ryze komerční sféry, troufnu si tvrdit, že tentokrát budou podmínky výběrového řízení na nového ředitele více přát lidem ze současné komunity kolem ICANNu a že novým ředitelem bude nějaká známá tvář z tohoto prostředí. Každopádně přeji představenstvu šťastnou ruku při volbě.
Ondřej Filip