Ve čtvrtek jsem z oznámeného počtu žadatelů spekuloval, kolik by mohlo být vlastně žádostí o nové domény. A netrvalo to dlouho a ICANN tuto otázku zodpověděl. V pátek totiž oznámil, že je jich 2091 a k tomu je ještě 214 žádostí, u kterých nebyl zaplacen poplatek za slot, což je 5 000 USD. Vzhledem k tomu, jak čas pokročil, už ovšem není příliš pravděpodobné, že by z těch 214 bylo mnoho oživeno. ICANN dále oznámil, že má díky tomuto procesu na kontě zhruba 350 milionů dolarů, což je rozhodně velmi zajímavá částka už s ohledem na to, že roční rozpočet této organizace je mírně přes 60 milionů USD. Vzhledem k tomu, že za jednu žádost by měl žadatel uhradit 185 000 USD, vypadá to, že drtivá většina žádostí (zhruba 90 % nebo 1 900) již byla dokončena a uhrazena.
Takto vysoký počet žádostí znamená, že posuzování bude rozděleno do nejméně čtyřech dávek. Jak jsem již vysvětloval v článku na Lupě, ICANN totiž již dříve avizoval, že dokáže posuzovat nejvíce 500 žádostí v jednom okamžiku. Délka úvodní části posuzování žádosti byla odhadnuta na přibližně pět měsíců. Tedy jenom úvodní fáze posuzování nebude pro některé domény hotova dříve než v půlce roku 2014.
V této souvislosti si stále kladu otázku, proč bylo tak nutné zastavit proces pouhých 12 hodin před ukončením řádné lhůty. ICANN ohlásil, že důvodem byl únik informací. Ale s ohledem na to, že se všechny žádosti mají stejně brzy zveřejnit, v tom až tak velký problém nevidím. Ano, někdo mohl v systému zjistit, jakou doménu chystá jeho konkurence, ale zjistit to 12 hodin před uzavřením podávání žádostí by mu už nijak nepomohlo – žádost by už stejně nestihl podat. Velice podezřele působí i fakt, že systém je odstaven již téměř měsíc. Teď naopak lidé, kteří nějaké informace nelegálně získali, mají čas s nimi pracovat. Takže mi to připadá velmi podezřelé. No těším se, až budu moci na meetingu v Praze položit zástupcům ICANNu několik otázek.
Ondřej Filip
OpenFlow s otazníky
Abych řekl pravdu, dosud jsem si myslel, že OpenFlow je záležitost povýtce akademická a nemá valného praktického významu. Přispěla k tomu jistě i prezentace „Software Defined Networking“ na IETF 82, která ve mně i řadě dalších posluchačů zanechala dojem ryzího slidewaru.
Krátká přednáška Todda Underwooda (Google) na nedávném RIPE 64 mě ale přivedla k úvahám, zda bych neměl svůj postoj k OpenFlow a SDN přehodnotit. Google totiž používá OpenFlow switche ve dvou svých produkčních páteřních sítích, které propojují lokality na třech kontinentech. OpenFlow jim umožňuje pojímat tyto sítě jako systém pro transport dat a ne pouze jako soubor jednotlivých switchů a linek.
OpenFlow je postaven na myšlence oddělení forwardovací logiky (data plane) od směrovacích, filtrovacích a jiných algoritmů (control plane). Zatímco data plane zůstává „zadrátovaná“ ve switchi, control plane se přesouvá na samostatný počítač (controller), který může řídit jeden nebo více switchů. Jádrem OpenFlow je protokol a API umožňující kontroléru konfigurovat zacházení s pakety ve switchi.
OpenFlow předpokládá, že data plane je ve switchi implementována ve formě tabulky toků s využitím hardwarové asociativní paměti (TCAM). V tom ovšem vidím jistý problém: špičkové TCAM čipy mají kapacitu jednotek až desítek tisíc položek, takže se do nich rozhodně nevejde kompletní směrovací tabulka BGP. Mohli bychom sice zvolit alternativní strategii – plnit tabulku na základě toků, které switch skutečně přenáší – ale ani s tou se moc daleko nedostaneme, protože typické počty aktivních toků v páteřních internetových směrovačích kapacitu TCAM rovněž vysoko překračují. Zdá se tedy, že kombinace OpenFlow switche a směrovacího démona není v roli obecného BGP routeru příliš použitelná.
Myslím si ale, že i tak bychom se v Laboratořích CZ.NIC mohli OpenFlow trochu podívat na zoubek. Minimálně by stálo za to demonstrovat, že OpenFlow switch může fungovat i s BIRDem v pozici kontroléru (Google používá Quaggu). Je docela možné, že takový hardwarově akcelerovaný směrovač by se mohl v některých situacích dobře uplatnit.
Za pozornost stojí také standard OF-CONFIG 1.0, který se zabývá konfigurací a správou „provozního kontextu“ OpenFlow switche, tedy de facto všeho kromě tabulky toků. Standard pro tento účel používá protokol NETCONF a datové modely zapsané v jazyku YANG. Jde zřejmě o dosud největší otevřeně dostupnou aplikaci technologií NETCONF/YANG.
Ladislav Lhotka
Žadatelů o nové domény je téměř 1300 (a musí čekat)
Nedávno jsem v článku na Lupě popisoval problémy systému, který slouží pro příjem žádostí o nové domény. Systém byl odstaven a ICANN tehdy naznačoval, že jej opět uvede do provozu do 20. dubna. No a máme květen a systém pořad ještě neběží. Doba odstávky je už hodně dlouhá a zřejmě i ICANN přestalo bavit posílat téměř každý den v podstatě identické oznámení o tom, že na odstranění závady se intenzivně pracuje. Proto ve včerejší zprávičce přidal alespoň nějakou novinku. V systému TAS je registrováno 1268 uživatelů, což je značný nárůst od předchozího známého čísla z 25. března, kdy oznámil 839. Je vidět, že na poslední chvíli ještě hodně uživatelů přibylo. Toto číslo je již konečné, protože už není možné registrovat nové uživatele. Každý uživatel má (tedy měl a po odstávce ještě bude mít) právo požádat o 0-50 domén. Je třeba podotknout, že uživatel měl dopředu zaplatit 5000 USD za každou žádost, kterou měl v plánu podat. ICANN bohužel nezveřejnil, kolik takových „slotů“ bylo zaplaceno.
Dále se ICANN ve své zprávičce věnuje hlavnímu důvodu, proč byl systém odstaven. Někteří uživatelé mohli částečně vidět data jiných uživatelů. Konkrétně u cca 100 z nich mohl někdo cizí vidět uživatelská jména a jména souborů. Ve zprávičce bohužel chybí to hlavní, a to datum znovuspuštění TASu. Tak doufejme, že to již bude brzy a celý proces vzniku nových domén se opět rozběhne.
Každopádně jako předseda pracovní skupiny pro přípravu ccNSO meetingu v ICANNu jsem požádal zaměstnance ICANNu o prezentaci k tomuto tématu. Takže pokud budete mít zájem zúčastnit se pražského ICANN meetingu, můžete se o tomto problému dozvědět více.
Ondřej Filip
Aktualizace Ubuntu a IPv6
Po dvou letech nám vyšla další LTS verze Ubuntu, tentokrát 12.04 „Precizní pásovec“. Nastal tedy čas aktualizací a jako první přišla na řadu naše IPv6 laboratoř. Na serverech, které tuto laboratoř obsluhují, máme jak Ubuntu 10.04 LTS tak i 11.10, abychom mohli zkoušet vše potřebné. Samotný postup upgrade bude jistě popsán na mnoha jiných stránkách a proto zde zmíním jen dva základní příklady. Pro upgrade na novou verzi se použije příkaz
do-release-upgrade
případně pro přechod z předchozí LTS verze doplněn o přepínač -d
do-release-upgrade -d
Po jejich zadání se dozvíme,… že žádné nové verze nejsou k dispozici. Jak je to ale možné? Při bližším zkoumání komunikace zjistíme, že tento nástroj se snaží komunikovat na adresu http://changelogs.ubuntu.com/, která má ale bohužel pouze IPv4 překlad. Na tento problém již téměř rok existuje bug report, který je bohužel stále otevřený, i když by vše spravila drobná oprava v DNS. Řešení tohoto problému jsou v podstatě dvě (pokud zanedbáme reinstalaci, ale komu by se chtělo vše znova nastavovat). Je možné použít NAT-64, pokud ho máme nasazený, nebo dočasně pustit do sítě „zastaralou“ IPv4.
Poté, co jste systém přesvědčili o existence nové verze, stále nemáme vyhráno. Standardní mirror eu.archive.ubuntu.com má opět pouze IPv4 adresy. Situace je trochu lepší u národního archivu cz.archive.ubuntu.com, který má IPv4 i IPv6 adresy. U bezpečnostních oprav je situace obdobná, hlavní server security.ubuntu.com není dostupný po IPv6 a proto je nutno upravit seznam zdrojů. Jedna z možností je popsána například v tomo blogu, kde se řeší oba problémy.
Na všechny výše uvedené problémy jsou vytvořeny bugreporty, a tak nezbývá než doufat, že se jich někdo ujme a vyřeší je. Do té doby bude potřeba alespoň pro upgrade verze zajistit připojení po IPv4.
Petr Černohouz
Aktualizace 3.5.2012: Zaktualizován stav eu.archive.ubuntu.com a cz.archive.ubuntu.com.
Šest let stará „0-day“ zranitelnost v OpenSSL
Nedávno se ve full-disclosure mailing-listu objevila zpráva o heap-overflow zranitelnosti v parsování ASN.1 v OpenSSL. Zranitelnost je složena ze dvou částí:
- Při konverzi long -> int na x86_64 architektuře dochází k ořezání nejvyšších 32 bitů, výsledek se uloží do 32-bit integeru se znaménkem. Použitím DER-enkódovaného certifikátu, který má nějaký length-field s bitem 32 nastaveným, dojde k přetečení do záporných čísel.
- Funkce realloc() podle C99. standardu musí umět jak paměť alokovaného bloku zvětšit, tak zmenšit. Problém spočívá v tom, že obdobná funkce CRYPTO_realloc_clean() v OpenSSL nepodporuje zmenšení bloku. Pokud je nová délka alokovaného bloku menší než původní délka, část paměti za alokovaným bufferem se přepíše bajty navíc z původního bloku.
Kombinací obou chyb lze část paměti přepsat „speciálně formovaným“ certifikátem. Chybu je poměrně těžké zneužít, ale rozhodně to není nemožné. Týká se funkcí pojmenovaných d2i_*_bio a d2i_*_fp (a pár dalších pracujících s CMS a S/MIME).
Zatím probíhá šetření, který software používající OpenSSL je chybou ovlivněn. V tuto chvíli jsou chyby s největší pravděpodobností vyloučeny u:
- OpenSSH – používá vlastní kód pro parsování ASN.1
- Tor – používá in-memory d2i_* a PEM_* funkce, žádné z napadnutelných
- DNSSEC Validator – ASN.1 parsování se vůbec nepoužívá
- dslib – openssl se vůbec nepoužívá, ASN.1 parsování dělá pyasn1
- datovka – potenciálně zranitelná funkce OpenSSL.crypto.load_pkcs12 se nachází jen u načtení vašeho certifikátu z disku (tudíž dokud ho někdo nezmění, nic se nestane; navíc používá se jenom při přihlašovaní certifikátem)
- Knot DNS 1.0.3 – žádná zranitelná funkce se nevolá
- Firefox 11, Thunderbird 11.0.1 (komponenty NSS, NSPR a XulRunner) – Firefox i Thunderbird mají ale spoustu závislostí; je teoreticky možné, že jsem něco přehlédnul
- Apache 2.4.2, nginx 1.0.15 a 1.1.19, lighttpd 1.4.30 – používají některé ze zranitelných funkcí, ale jenom při čtení certifikátů z disku
Další pár očí pro kontrolu samozřejmě neuškodí. Statickou analýzou kódu jsem vytvořil call-graph a regexp, kterým lze ověřit, jestli nějaký kód volající funkce openssl používá potenciálně zranitelné funkce. Bugy jsou opraveny ve verzích openssl 1.0.1a, 1.0.0i or 0.9.8v. Jeden způsob, jak zmírnit dopad chyby v openssl (i budoucí), je použití stunnel v jail-u, ale má to některé další nevýhody jako těžší zpracování logů.
Další zajímavý fakt je, že tato konkrétní chyba (bez části o realloc()) byla publikována v roce 2006 v knize The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities. Zde je fotografie stránek se zmíněnou chybou (konverze long -> int). Nicméně to není první ani poslední „znovuobjevený“ bug v softwaru.
Ondrej Mikle
Jak by měla vypadat podpora IPv6
Před několika dny vyšel v IETF soupis požadavků pro podporu IPv6 v zařízeních (BCP 177 známé také jako RFC 6540). Cílem tohoto soupisu je vyřešit problém slepice nebo vejce pokud možno přirozenou cestou. Jak je zmíněno v první části, IPv6 je tu s námi už celkem dlouho, ale většina výrobců síťových zařízeních ho stále bere spíše jako volitelnou součást, než jako základní funkcionalitu. Tento přístup je nejvíce patrný v segmentu zařízení určených pro domácnosti. Zde se výměna hardware řeší až v okamžiku, kdy ten současný doslouží (tady nelze očekávat hromadný nákup nových modemů a routerů jen pro IPv6). Samotný dokument obsahuje pět doporučení, kterými by se měli výrobci řídit:
- nové implementace IP musí obsahovat podporu pro IPv6
- aktualizace stávajících implementací by měly podporovat IPv6
- podpora IPv6 musí být srovnatelná nebo lepší, než podpora IPv4
- nové a aktualizované implementace by měly podporovat souběh IPv4 a IPv6 (dualstack) a nesmí mít IPv4 jako podmínku pro svůj běh
- implementátorům se doporučuje aktualizovat software a hardware pro podporu IPv6, pokud je to možné.
Hlavně třetí bod je v současné době zanedbáván. I když se zařízení chlubí podporou IPv6, může nastat situace, kdy je například firewall funkční pouze pro IPv4 a pro IPv6 jsou k dispozici jen dvě záložky nastavení základních parametrů. Zajímavé bude také sledovat, jak se výrobci vypořádají s bodem čtyři, který znamená možnost běhu v IPv6 only síti (pokud máte pocit, že to vaše zařízení zvládne, můžete navštívit naši IPv6 laboratoř a vyzkoušet to v praxi). Ačkoliv poslední bod by nám měl dávat naději na lepší stav IPv6, uvidíme, jak to bude vypadat v praxi a zda výrobci vydají aktualizace s podporou IPv6 k již existujícím zařízením.
Zbývá jen doufat, že tyto doporučení vezmou výrobci za svá a na trhu se objeví dostatek domácích routerů a modemů s podporou IPv6. Odstranila by se tak jedna z překážek pro zavedení IPv6, případně by byla odstraněna v rámci přirozené výměny dosluhujících zařízení.
Petr Černohouz
Ohlédnutí za IETF 83
Jelikož jsem v předchozích dvou blogpostech o OpenID a WHOISu nalákal čtenáře na IETF 83, sluší se přinést nějaký report o tom, jak tato konference splnila očekávání. Dá se říct, že více než dostatečně.
Jak už je na IETF zvykem, je neděle věnovaná tutoriálům. Mezi ně byl trochu narychlo zařazen i tříhodinový tutoriál na OpenID Connect. To ještě více umocnilo fakt, že tato konference byla problémům digitálních identit věnovaná víc než jsem sám čekal. V zajímavé souhrnné prezentaci bylo zmíněno i probíhající vzájemné testování existujících implementací. Zájemcům o OpenID Connect bych určitě doporučil blogy jeho autorů, zejména články OpenID Connect in a nutshell a Designing a Single Sign-on system using OAuth 2.0. A pokud někdo stále nerozumí rozdílům mezi OpenID a OAuth, existuje i Dummy’s guide. Na závěr byl prezentován i projekt AccountChooser jako nástroj pro poskytovatele služeb, kteří chtějí implementovat jednotné přihlášení napříč technologiemi. Jak udělat správně uživatelské prostředí na straně poskytovatele služeb je zjevně oříšek a nikdo není spokojen s tím co se nazývá NASCAR UI – desítky barevných tlačítek s různými poskytovateli, mezi kterými si uživatel musí nalézt toho svého.
Z pondělních pracovních skupin zaujala NETMOD, jejíž cíl je vydefinovat univerzální datové modely pro vzdálenou konfiguraci různých prvků pomocí protokolu NETCONF. Na datovém modelu pro konfiguraci routingu totiž pracuje Láďa Lhotka z našich laboratoří. Odpolední technické „plenary“ začalo připomenutím druhého dne IPv6, na který se připravujeme i my. Potom už byly hlavními tématy TLS, problémy certifikačních autorit a zabezpečení webu obecně, které se lehce vyhrotilo při kritice tvůrců prohlížečů spočívající v tvrzení, že napadené nebo pochybné certifikační autority neodstraňují z prohlížečů flexibilně.
Avizovaná panelová diskuze o OpenID a OAuth pořádaná organizací ISOC v úterý před polednem byla pro auditorium, ve kterém seděli zástupci různých (číselných i doménových) registrů, spíše seznamovací. Její obsah nejspíš jen vyvolal v posluchačích otázky, které jsme si my položili již dříve a odpověděli na ně v podobě služby MojeID. V navazující pracovní skupině KITTEN, o které jsem se zmiňoval dříve v souvislosti s použití OpenID pro zabezpečení dalších internetových protokolů, se pouze probral stav existujících dokumentů bez nějakého zásadního posunu. To na WEIRDS se očekávala bouřlivá diskuze o podobě nového WHOIS protokolu. Překvapivě se ozvali pouze jednotlivci, kteří mají obavy o zbytečně vynaložené úsilí. Navržený „charter“ pro připravovanou pracovní skupinu tedy bude poslán ke schválení příslušným orgánům IETF. V podvečer ještě zasedla pracovní skupina DNSEXT. Na ní Ondra Surý z našich laboratoří prezentoval navrhovanou úpravu protokolu IXFR. Tato pracovní skupina se pravděpodobně setkala naposledy; její odsouhlasené rozpuštění již čeká pouze na administrativní proceduru.
Středeční program nabídl mimo jiné pracovní skupinu TLS. Ta probírala rozšíření mechanismů pro získání certifikátů při navazování TLS spojení, např. z DNS, jak bylo schváleno v rámci pracovní skupiny DANE. Tato pracovní skupina již všechny svoje dokumenty dokončila a jsou v procesu schvalování, takže pro ni nebyl důvod se tentokrát scházet.
A opět ty identity. Na čtvrteční ráno byl naplánován BOF týkající se protokolu SCIM (Simple Cloud Identity Management). Velcí poskytovatelé cloudových služeb by si rádi standardním způsobem synchronizovali data o uživatelích. Navrhli tedy protokol, který má standardizovány operace pro založení, zobrazení, změnu a zrušení (CRUD) vzdáleného kontaktu spolu s univerzální datovou strukturou v XML a JSONu. Jestli vám to připomíná EPP, které používáme v našem doménovém registru, tak mně také. To jen ukazuje, že staré nápady jsou neustále recyklovány a možná není daleko doba, kdy místo EPP protokolu budeme také používat nějaký REST protokol nad HTTP. Následovala druhá panelová diskuze týkající se OpenID, OAuth a tentokrát i BrowserID. Je více než zřejmé, že BrowserID nemůže OpenID aktuálně plnohodnotně nahradit. Pracovní skupina OAUTH poté řešila hlavně tzv.“rechartering“, tzn. změnu svých cílů. Pro OpenID Connect bude důležité, jestli si pracovní skupina vezme za své některé osiřelé specifikace, na kterých je závislý jako např. Simple Web Discovery. Proti tomu se zvedl částečný odpor, neboť se opět jedná o alternativní přístup k něčemu, na co již existují v IETF jiné standardy host-meta a webfinger.
Závěrečnou tečku za konferencí udělala v pátek pracovní skupina DNSOP. Hlavním tématem bylo TTL a jeho snižování nebo zvyšování. Inženýři z Verisign navrhují jeho výrazné zvýšení jako ochranný mechanismu proti případné nedostupnosti autoritativních serverů. Jejich japonští kolegové naopak doporučují výrazné snížení jako ochranný mechanismus z důvodu rychlého zotavení z případné chyby např. v souvislosti s technologií DNSSEC. K tomu se samozřejmě ještě přidává zákaznický pohled, neboť uživatelé samozřejmě chtějí vidět svoje požadované změny okamžitě. Jednoznačná odpověď asi neexistuje.
Jaromír Talíř
Třeba nás čtou i na školách (ne snad povinně) – AKTUALIZOVÁNO
V rámci našich osvětových aktivit se snažíme objíždět české střední školy s prezentacemi o internetu a doménách, o DNS a DNSSEC, o mojeID, IDN nebo třeba IPv6. Před několika lety jsme v této souvislosti začali spolupracovat i s Jednotou školskych informatiků, z čehož se po čase zrodila možnost uspořádat takové školení i pro samotné kantory (dostali jsme na něj i akreditaci od MŠMT). První a druhý běh tohoto kurzu se uskutečnil před dvěma lety a na obou dohromady se sešlo ke 40 zájemců, tedy poměrně dost. A tak jsme ho letos oprášili a ve spolupráci s JSI vypsali jeho pokračování. Přeci jen, za dva roky se toho v mnohém dost změnilo.
Jednodenní vzdělávací (čti informativní) kurz pro učitele IT předmětů na gymnáziích, středních a vyšších odborných školách se uskuteční v naší akademii 14. června. Pásmo se bude skládat z přednášek o tom, jak funguje internet, jak je to s doménami a s přechodem na IPv6, co je DNS, DNSSEC, IDN nebo mojeID. Chybět nebude ani část o projektech, které v CZ.NIC pro školy a jejich návštěvníky připravujeme, nebo diskuse na závěr o tom, co by od nás pedagogové uvítali.
Tento kurz je pro pedagogy, a to zdarma. Doporučujeme proto přihlásit se co nejdříve, aby bylo ještě místo. V případě, že se utrhne lavina zájmu a my budeme zahlceni přihláškami (na to se v duchu těšíme :)), vypíšeme samozřejmě náhradní termín. Jestli nás tedy čtete i na školách a tato nabídka vám přijde zajímavá, neváhejte a přihlaste se. Čas máte do 14. května včetně. Pokud máte kolem sebe kolegy, které by to všechno kolem internetu mohlo zajímat, dejte jim vědět nebo je rovnou přihlaste.
A pro vás ostatním, kterým jsou už školní lavice malé. Měli byste o takové jednodenní posezení zájem? Dejte nám vědět v komentářích, jestli se máme myšlence zařadit takový kurz do naší nabídky dále věnovat. Přeci jen, do akademie jsou zvyklí chodit spíše odborníci s praxí. V tomto případě jde jednoznačně o kurz méně odborný.
Aktualizováno 12. dubna 2012:
Protože se tato nabídka setkala s dobrou odezvou, otevřeli jsme ještě jeden běh tohoto kurzu; ten je od dnešního dne vypsaný na 31. května. Pokud mě ale dosud někdo nepředběhl, na 14. června jsou ještě dvě nebo tři místa volná. Zájem účastníků nás velice těší.
Vilém Sládek
UnoDNS – začátek konce jednotného internetu?
Také jste byli naštvaní, když vám některá webová služba odmítla přístup s tím, že nejste ze „správného“ geografického regionu? Takovýto pohled nepotěší asi nikoho…
Zkoušeli jste různé proxy či VPN a zjistili, že reálně se nedají používat, protože jsou pomalé? Nedávno se objevila nová služba UnoDNS, která o sobě tvrdí, že problémy s proxy či VPN vyřešila a že Hulu, Netflix a další streamované služby či kanály vám poběží bez problémů. Dokonce i recenze služby to potvrzují.
Je tu ale jeden háček. Musíte si změnit nastavení DNS a začít používat servery UnoDNS. Ty filtrují dotazy do DNS pro domény podporovaných služeb a mění odpovědi. Běžná odpověď pro www.netflix.com:
www.netflix.com is an alias for wwwservice--frontend-373494752.eu-west-1.elb.amazonaws.com.
wwwservice--frontend-373494752.eu-west-1.elb.amazonaws.com has address 176.34.185.102
wwwservice--frontend-373494752.eu-west-1.elb.amazonaws.com has address 176.34.186.229
wwwservice--frontend-373494752.eu-west-1.elb.amazonaws.com has address 176.34.187.142
wwwservice--frontend-373494752.eu-west-1.elb.amazonaws.com has address 176.34.188.229
wwwservice--frontend-373494752.eu-west-1.elb.amazonaws.com has address 176.34.184.243
wwwservice--frontend-373494752.eu-west-1.elb.amazonaws.com has address 176.34.185.50
A stejná odpověď při použití UnoDNS:
www.netflix.com is an alias for wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com.
wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com has address 107.21.96.127
wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com has address 50.19.99.64
wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com has address 107.20.232.200
wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com has address 50.19.103.125
wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com has address 107.20.137.117
wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com has address 50.19.119.154
A právě tady je jádro možného problému. Co když nebudou filtrovány jen záznamy služeb pro streaming videa, ale i něco jiného? Ani bychom to nezjistili, protože kdo z nás si po několika týdnech vzpomene, že jsme změnili nastavení DNS kvůli poslední epizodě seriálu, kterou jsme chtěli vidět. Nejsme zde dokonce svědky konce doposud běžné praxe používání DNS našich ISP a začátku fragmentace na používání různých DNS poskytovaných někým jiným? Pokud ano, zřejmě nás čeká situace, kdy každý z nás uvidí „jiný Internet“ právě podle toho, jaké DNS servery používáme. Případně si budeme mezi těmito „různými Internety“ přepínat podle uvážení. Žádná lákavá představa ani v jednom případě …
PT
FREDovo dopoledne na ICANN 43
V souvislosti s posledním setkáním ICANN bychom chtěli ještě v krátkosti zmínit události, které v Kostarice potkaly náš registrační systém FRED.
Správci národních domén jsou v rámci ICANN seskupeni v organizaci ccNSO, a to proto, aby při prosazování svých zájmů mluvili pokud možno jedním hlasem. První den celé konference má tradičně tato organizace svůj „TechDay„, na kterém reprezentanti jednotlivých registrů ukazují produkty ze svých „kuchyní“; tady bychom mohli s trochou nadsázky říct, že první polovina dne patřila FREDovi. Shodou okolností totiž po sobě prezentovali technická řešení svých registrů nejprve Estonci, potom Kostaričani a nakonec zástupci Faerských ostrovů. Příjemné pro nás bylo zjištění, že nám FRED neudělal ani v jednom případě ostudu.
V průběhu týdne jsem měl ještě možnost prodiskutovat náš systém s ředitelem registru Rwandy. FREDa mají nasazeného v testovacím provozu a čekají na převedení domény .rw do jejich správy. Kolegové ze zmíněných registrů udělali FREDovi skutečně dobrou reklamu. Krátce po skončení konference se mi totiž ozval správce domény ostrovů Komoro (.km), že zvažují využití systému pro jejich technické řešení.
I s ohledem na tyto události zvažujeme uspořádat v rámci červnového setkání ICANN v Praze specializovaný workshop, kde by bylo možné seznámit potenciální zájemce o tento náš produkt podrobněji. To by FREDovi mohlo pomoci rozšířit se i do dalších destinací, které na automatizovanou správu domény teprve přecházejí.
Jaromír Talíř