Joe Abley včera informoval komunitu, že se změnily plány podpisu kořenové zóny. Poslední fáze, která obsahuje publikaci kořenové zóny podepsané reálným klíčem, byla posunuta z 1. července 2010 na 15. červenec 2010. Tyto dva týdny budou využity na další studium publikování DURZ (viz úvod) podepsané kořenové zóny.

Dalším naplánovaným krokem k podpisu kořenové zóny bude první ceremonie podpisu klíčů, která proběhne 16. června 2010 v USA ve městě Culpeper. Pro ty z vás, kdo stejně jako já netušíte, kde takový Culpeper leží, tak je to kousek od Washingtonu DC.

Ondřej Surý

Na tomto blogu vás pravidelně informujeme o postupu podpisu kořenové zóny (Už jen jeden!, Více než polovina, první, a úvod). Dnes došlo k podepsání posledního kořenového serveru: J.root-servers.net od dnešního dne nese kořenovou zónu podepsanou pomocí DNSSECu.

Kořenová zóna je stále podepsána klíčem a podpisy, které nelze validovat (tzv. DURZ). Ale i tak je podpis posledním krůčkem potřebným pro finální podepsání kořenové zóny validním klíčem, které má proběhnout 1. 7. 2010. Postupné nasazení DURZ – podepsané kořenové zóny na jednotlivé nameservery, bylo zapotřebí pro ověření, že zvětšení DNS zpráv nezpůsobí žádné velké operační problémy. Až na lehké zvýšení TCP provozu na kořenové nameservery po podepsání dvanácti nameserverů ze třinácti to zatím nevypadá, že by nějaké problémy měly nastat. Ale to ukáží následující hodiny.

Takže velké díky týmu, který pracoval na podpisu kořenové zóny a další velký úkol na ně čeká na začátku prázdnin.

Ondřej Surý

Nedávno jsem referoval, že více než polovina kořenových serverů poskytuje onu pseudopodepsanou zónu. Včera došlo k další významné změně. Už jsou „podepsány“ všechny kořenové servery s výjimkou posledního, označovaného písmenem J. Tento stav bude pro rozhodnutí o skutečném podpisu kořenové zóny klíčovým. Systém DNS je navržen velice robustně a pro jeho správnou funkci stačí dostupnost alespoň jednoho kořenového serveru. Pokud tedy nějaký systém obsahuje špatnou implementaci DNS resolveru, která zahazuje DNSSEC podepsané odpovědi, bude pro tento systém těch 12 podepsaných kořenových serverů jakoby nedostupných. Takže jako jediný dostupný se bude jevit právě server J a takové systémy budou koncentrovat své dotazy právě na něj. Pokud tedy výrazně stoupne zatížení tohoto serveru, dá se předpokládat, že existuje větší množství klientů, které by podpis všech serverů „odstřihl“ od Internetu. Možná proto si správci kořenových serverů na podpis toho posledního třináctého nechávají čas a plánují jej na 5. května. Mají pár dnů na to, zanalyzovat, zda-li se nějaký podobný jev nevyskytuje.

Každopádně vlak jménem DNSSEC@ROOT postupuje dle grafikonu. Další zastávka bude na začátku května.

Ondřej Filip

Jak už před časem referoval kolega Surý, v současnosti probíhá proces, jehož vyústěním bude plný platný podpis kořenové zóny. Tato událost zastřeší všechny současné aktivity týkající se podepisování domén nejvyšší úrovně a hlavně zjednoduší život správcům rekurzivních DNS serverů; pak už totiž bude stačit pouze sledovat změny klíčů jedné (té nejvyšší) zóny.

Minulý týden ve středu došlo k překonání dalšího virtuálního milníku. K podpisu totiž nedochází naráz, ale jednotlivé kořenové zóny se „podepisují“ neověřitelnými „falešnými“ klíči postupně. A právě 24. března byly tyto klíče publikovány dalšími třemi servery. Celkový počet „podepsaných“ serverů se v tuto chvíli zastavil na čísle sedm, což je už více než 50 % z celkových 13. Další várka zavádění těchto podpisů se očekává 14. dubna, kdy bude podepsáno dalších pět serverů. Poslední server bude přidán 5. května.

Správný a validní podpis by měl začít platit od prvního prázdninového dne – 1. července. Zatím tedy proces běží zcela podle plánu a nemá žádné zpoždění, což je velice dobrá zpráva pro bezpečnost systému DNS.

Ondřej Filip

Výkonný ředitel ICANN Rod Beckstrom prohlásil včera na setkání GAC (poradního výboru vlád při ICANN), že: „Na systém DNS je veden útok a celý systém je nyní křehčí a zranitelnější než kdykoliv předtím a může se kdykoliv doslova zhroutit.“ Pokud by se něco takového stalo, mělo by to samozřejmě obrovské a dalekosáhlé důsledky, protože na fungování Internetu dnes závisí téměř vše. Dle jeho slov dospěl k tomuto tvrzení po konzultaci s více než 20ti řediteli největších doménových registrů a registrátorů, kteří jsou extrémně znepokojeni stejně jako on. Více v plném audio záznamu komentáře.

Zajímavý je už fakt, že co se týká národních domén (tzv. ccTLD), tak někteří ředitelé největších registrů, kteří byli na místě přítomni, o žádných takových konzultacích nevěděli. Tak jako tak prakticky všichni zástupci registrů národních domén toto tvrzení považovali za „nemístné“ a přehnané. Samozřejmě i DNS se stejně jako spousta dalších internetových služeb potýká s bezpečnostními problémy. Nicméně rozhodně žádný z nich neohrožuje funkčnost a stabilitu celého systému. Navíc zrovna v této oblasti internetová komunita pracuje velmi dobře – je si vědoma zásadní důležitosti systému DNS (proto pro něj buduje velmi robustní infrastrukturu), nalezené problémy řeší, vzdělává koncové uživatele atd. K tomuto se samozřejmě snažíme přispět i my (CZ.NIC) například tím, že se podílíme na provozu F a L kořenových serverů v České republice, že jsme jako jedni z prvních zavedli DNSSEC (máme nejvíce zabezpečených domén na světě) nebo že provozujeme bezpečnostní oddělení, které řeší např. zneužívání domén k šíření malware či phishingu.

Osobně si myslím, že představitel tak významné instituce by neměl vydávat takto silná prohlášení bez širší konzultace s institucemi, které se o provoz a stabilitu starají např. správce národních domén, operátory root serverů apod. Ostatně třeba organizace správců národních domén (ccNSO) připravuje vlastní vyjádření k těmto jeho výrokům.

Ondřej Filip

V poštovní konferenci pracovní skupiny DNSEXT, která se zabývá rozšiřováním protokolu DNS, aktuálně probíhá bouřlivá diskuze nad novým návrhem Client IP information in DNS requests (neboli Informace o klientské IP adrese v DNS dotazech). Tento návrh společně podaly společnosti Google a Neustar. Google před nedávnou dobou spustil svou službu Google Public DNS, a tudíž představuje zástupce provozovatele veřejného resolveru. Neustar stojí na opačném konci, kromě provozu několika TLD, provozují také autoritativní DNS servery, které získali akvizicí firmy UltraDNS. To jen tak na vysvětlenou, co mají tyto dvě firmy společného s DNS.

Tento návrh přidává do DNS zprávy volitelnou položku, která obsahuje IP adresu (resp. adresu sítě) klienta, který položil dotaz rekurzivnímu resolveru. Možná vás teď napadá otázka, k čemu je tato informace autoritativnímu DNS serveru dobrá? Obecně k ničemu. Tento návrh přinese užitek pouze malé skupině provozovatelů DNS serverů – hlavní využití by tento návrh měl při distribuci obsahu (CDN), kdy už v dnešní době dochází na základě IP adresy rekurzivního resolveru k přizpůsobení odpovědi, kterou poskytne autoritativní DNS server. Typickým příkladem je například právě Google.

Pokud se zeptám na adresu www.google.com ze svého pracovního počítače (tedy aktuálně s IP adresou přidělenou CZ.NICu), dostanu tuto odpověď:

www.google.com. IN CNAME www.l.google.com.
www.l.google.com. IN A 74.125.87.105
www.l.google.com. IN A 74.125.87.147
www.l.google.com. IN A 74.125.87.99
www.l.google.com. IN A 74.125.87.104
www.l.google.com. IN A 74.125.87.103


Pokud se zeptám z našeho DNS serveru v Londýnském LINXu, dostanu odpověď úplně jinou:

www.google.com. IN CNAME www.l.google.com.
www.l.google.com. IN CNAME www-tmmdi.l.google.com.
www-tmmdi.l.google.com. IN A 216.239.59.99
www-tmmdi.l.google.com. IN A 216.239.59.103
www-tmmdi.l.google.com. IN A 216.239.59.147
www-tmmdi.l.google.com. IN A 216.239.59.104


Náš DNS uzel v Kaliforni vidí opět jiné IP adresy:

www.google.com. IN CNAME www.l.google.com.
www.l.google.com. IN A 74.125.87.99
www.l.google.com. IN A 74.125.87.103
www.l.google.com. IN A 74.125.87.104
www.l.google.com. IN A 74.125.87.105
www.l.google.com. IN A 74.125.87.147


Těmito DNS triky se dá geograficky rozložit zátěž mezi různé lokality. S příchodem veřejných otevřených rekurzivních resolverů (provozovaných jako služba) ovšem nastává problém. Jak budou vypadat stejné dotazy ze stejných lokalit, když začnu používat například servery OpenDNS.

Z Čech:

www.google.com. IN CNAME google.navigation.opendns.com.
google.navigation.opendns.com. IN A 208.69.34.230
google.navigation.opendns.com. IN A 208.69.34.231


Z Kalifornie:

www.google.com. IN CNAME google.navigation.opendns.com.
google.navigation.opendns.com. IN A 208.67.219.230
google.navigation.opendns.com. IN A 208.67.219.231


Přesměrováním na vlastní server OpenDNS řeší problém, který představuje neschopnost předat informaci o lokaci DNS klienta autoritativnímu serveru, k přesměrování dochází teprve na úrovni HTTP protokolu. Mimochodem všimněte si, jak OpenDNS bez zeptání vstupuje do vašeho DNS provozu. O důvod více, proč používat DNSSEC a nepoužívat OpenDNS.

Google se svou službou Google Public DNS řeší stejný problém. Sám pro sebe by tento protokol nepotřeboval, protože informaci o klientovi má, nicméně dalším třetím stranám ji není schopný předat.

Návrh, o kterém se aktuálně diskutuje v pracovní skupině DNSEXT, tento problém řeší přidáním volitelné (EDNS0 option) informace o klientské IP adrese, jak v DNS dotazu, tak v DNS odpovědi. Bez hlubšího zamyšlení se může tento nápad jevit jako dobrý. Nicméně pokud se zamyslíme nad dalšími souvislostmi, tak objevíme několik důvodů, proč by tento návrh neměl projít.

Důvod první: Myslím si, že změny důležitých protokolů jako je DNS, by neměly probíhat kvůli zájmům malé skupiny uživatelů tohoto protokolu. Celý návrh je šitý na míru několika málo poskytovatelům veřejných DNS resolverů, které se ptají autoritativních DNS serverů, které používají (dle některých špinavé) triky pro distribuci různého obsahu. Vnímám tento návrh jako nekoncepční, protože se snaží dolepit do DNS protokolu funkci, na kterou nebyl tento protokol postaven.

Důvod druhý: Lokalizace obsahu dle IP adresy není příliš spolehlivá. Pravděpodobně funguje ve většině případů, ale například nerozumím tomu, proč mě stránka google.com tvrdošíjně přesměrovává na www.google.cz a mluví na mne česky i přesto, že mám v nastavení prohlížeče nastaveno, že chci zobrazovat stránky v jazyce anglickém. Při cestě do zahraničí mají některé stránky (nejen google.com) tendenci na mne mluvit jazykem země, ve které se aktuálně nacházím. A mnohdy bývá problematické z této lokalizační pasti uniknout a dostat se alespoň na anglickou verzi stránek.

Důvod třetí: Celý návrh je postavený jako opt-out. Pokud si klient nepřeje, aby resolver předával informaci o jeho IP adrese, může stejnou cestou předat speciální IP adresu 0.0.0.0/0, kterou by měl resolver ctít a předat ji v této formě dále. Bohužel to ovšem znamená, že pokud nechcete, aby se autoritativní server dozvěděl vaši IP adresu, musíte mít podporu pro tuto volbu implementovanou ve vašem operačním systému. Osobně tento důvod vnímám jako nejzávažnější, protože mění stávající stav a nutí všechny uživatele k aktualizaci, která ani nemusí být dostupná.

Důvod čtvrtý: Kolegyně Zuzana v předchozím příspěvku o Dni ochrany osobních údajů psala o tom, jak se soukromý prostor postupně mění v prostor veřejný. Tento návrh ubírá další kousíček soukromí, tedy předává informaci, kterou v tuto chvíli měl pouze resolver dalším třetím stranám (provozovatelům autoritativních DNS). Navíc o tom, zda-li dochází k tomuto předávání vaší IP adresy, se nemáte nikterak šanci dozvědět, alespoň současná verze návrhu žádné takové rozšíření neobsahuje.

Jak to bude vypadat dále? Pracovní skupiny v IETF pracují na principu konsenzu. Pokud už se musí hlasovat, tak se hlasuje hučením. Google je sice silný hráč, ale do pracovní skupiny IETF se může zapojit kdokoli a každý hlas má stejnou váhu. Ze stávající diskuze vyplývá, že návrh má více odpůrců než zastánců, a domnívám se tedy, že minimálně v této podobě schválen nebude.

Ondřej Surý