🥇Jedna z funkcí Chromium vytváří obrovskou zátěž na kořenové DNS servery

Prohlížeč Chromium, který se aktivně vyvíjí jako open-source rodič Google Chrome a nového Microsoft Edge, na sebe upozornil z důvodu funkce, jež byla původně zamýšlena s dobrými úmysly: kontroluje, zda poskytovatel neprovádí »krádež« neexistujících výsledků dotazů domén.

Detektor přesměrování intranetu, který vytváří falešné dotazy na náhodné „domény“, jejichž existence je statisticky velmi nepravděpodobná, je zodpovědný přibližně za polovinu celkového provozu, který získávají kořenové DNS servery po celém světě. Inženýr Verisign Matt Thomas napsal rozsáhlý příspěvek příspěvek na blogu APNIC, který popisuje problém a hodnotí jeho rozsah.

Jak obvykle probíhá DNS převod

Tyto servery jsou nejvyšší instancí, kterou je třeba kontaktovat pro rozlišení .com, .net a tak dále, aby vám sdělily, že frglxrtmpuf není doména nejvyšší úrovně (TLD).

DNS, nebo Domain Name System („systém doménových jmen“), je systém, který umožňuje počítačům přetvářet zapamatovatelná doménová jména jako arstechnica.com na mnohem méně pohodlné IP adresy, například 3.128.236.93. Bez DNS by internet nemohl existovat v uživatelsky přívětivé podobě, což znamená, že zbytečná zátěž na infrastruktuře vyšší úrovně je skutečným problémem.

Pro načtení jediné moderní webové stránky může být potřebné neuvěřitelné množství operací DNS vyhledávání. Například když jsme analyzovali domovskou stránku ESPN, napočítali jsme 93 různých doménových jmen, od a.espncdn.com po z.motads.com. Všechna jsou nezbytná pro úplné načtení stránky!

Aby takovou zátěž mohla zvládnout vyhledávací soustava, která musí obsluhovat celý svět, je DNS navržena jako víceúrovňová hierarchie. Na vrcholu této pyramidy se nacházejí kořenové servery — každá doména nejvyšší úrovně, například .com, má vlastní rodinu serverů, které jsou nejvyšší instancí pro každou doménu pod nimi. Jedním stupněm výše těchto serverů jsou samotné kořenové servery, od a.root-servers.net do m.root-servers.net.

Jak často se to stává?

Díky vícestupňové hierarchii ukládání do mezipaměti v infrastruktuře DNS dosahuje velmi malý procento světových DNS dotazů k root serverům. Většina lidí získává informace z DNS resolveru přímo od svého poskytovatele. Když zařízení uživatele potřebuje zjistit, jak se dostat na konkrétní web, dotaz je nejprve zaslán na DNS server spravovaný tímto místním poskytovatelem. Pokud místní DNS server nezná odpověď, přesměrovává dotaz na své „přesměrovací servery“ (pokud jsou uvedeny).

Pokud ani DNS server místního poskytovatele, ani servery uvedené v jeho konfiguraci „přesměrování“ nemají uloženou odpověď, dotaz se zvedá přímo k autoritativnímu serveru domény přístupu. té, kterou se pokoušíte převést. V případě domena.com to bude znamenat, že dotaz je zaslán na autoritativní servery samotné domény com, které se nachází na adrese gtld-servers.net.

Systém gtld-servers, na kterou byl dotaz, odpovídá seznamem autoritativních jmenných serverů pro doménu domena.com, a také minimálně jedním záznamem, který obsahuje IP adresu jednoho z těchto jmenných serverů. Odpovědi se dále posouvají po řetězci – každý přesměrovací server předává tyto odpovědi zpět tomu serveru, který je požadoval, dokud odpověď konečně nedorazí na server místního poskytovatele a počítač uživatele. Všichni přitom ukládají tuto odpověď do mezipaměti, aby se nemuseli zbytečně obracet na vyšší úrovně systému.

Ve většině případů budou záznamy jmenných serverů pro domena.com již uloženy v mezipaměti na jednom z těchto přesměrovacích serverů, takže root servery nikdo neobtěžuje. Nicméně zatím mluvíme o obvyklém formátu URL – tom, který se mění na běžnou webovou stránku. Dotazy v Chromu se vztahují k úrovni přístupu. toho, na úrovni samotných clusterů root-servers.net.

Chromium a kontrola únosu NXDomain

Kontroly Chromium „tenhle DNS server mě neklame?“ představují téměř polovinu veškerého provozu, který dorazí do clusteru root DNS serverů Verisign.

Prohlížeč Chromium, mateřský projekt Google Chrome, nového Microsoft Edge a nespočtu méně známých prohlížečů, chce uživatelům usnadnit vyhledávání v jednom poli, které se občas nazývá „Omnibox“. Jinými slovy, uživatel zadává jak skutečné URL, tak dotazy do vyhledávače do stejného textového pole v horní části okna prohlížeče. Ještě více usnadňuje, že uživatele nenutí zadávat část URL s http:// nebo https://.

Ačkoli je tento přístup velmi pohodlný, vyžaduje, aby prohlížeč rozpoznal, co je třeba považovat za URL a co za vyhledávací dotaz. Ve většině případů je to docela zřejmé – například řetězec s mezerami nemůže být URL. Ale může to být složitější, když vezmeme v úvahu intranety – soukromé sítě, které také mohou používat soukromé domény nejvyššího řádu k převodu na skutečné webové stránky.

Pokud uživatel v intranetu své firmy zadá „marketing“ a v intranetu firmy existuje interní webová stránka se stejným názvem, Chromium zobrazí informační okno, které se ptá uživatele, zda chce hledat „marketing“, nebo přejít na https://marketing. To je celkem přijatelné, ale mnoho poskytovatelů internetu a poskytovatelů veřejných Wi-Fi sítí „ukradne“ každé chybné URL, přesměrováním uživatele na nějakou stránku plnou reklamních bannerů.

Náhodná generace

Vývojáři Chromium nechtěli, aby uživatelé na běžných sítích viděli při každém vyhledávání jednoho slova informační okno, které by se ptalo, co měli na mysli, proto implementovali test: při spuštění prohlížeče nebo změně sítě provádí Chromium DNS vyhledání u tří náhodně generovaných „domén“ nejvyššího řádu s délkou od sedmi do patnácti znaků. Pokud jakékoli dvě z těchto požadavků vrátí stejnou IP adresu, Chromium předpokládá, že lokální síť „ukradla“ chyby NXDOMAIN, které by měl získávat, a proto prohlížeč do dalšího upozornění považuje všechny zadané dotazy z jednoho slova za pokusy o hledání.

Bohužel, v sítích, které ne kradou výsledky DNS dotazů, tyto tři operace obvykle vyšplhají až k samotným kořenovým serverům jmen: lokální server neví, jak převést qwajuixk, proto přesměrovává tento dotaz na svůj přesměrovací server, který dělá totéž, dokud nakonec, a.root-servers.net nebo jeden z jeho „bratrů“ nebude nucen říct „Omlouváme se, ale tohle není doména“.

Jelikož existuje zhruba 1,67*10^21 možných falešných doménových jmen dlouhých od sedmi do patnácti znaků, častěji každý z těchto testů, provedených v „čestné“ síti, se dostane k kořenovému serveru. To představuje úctyhodných polovinu celkového zatížení na kořenové DNS, pokud máme věřit statistikám od té části clusterů root-servers.net, které patří společnosti Verisign.

Historie se opakuje

Není to poprvé, co projekt vytvořený s těmi nejlepšími úmysly zkolaboval nebo sotva nezkolaboval veřejný zdroj nepotřebným provozem – okamžitě nás to připomnělo dlouhou a smutnou historii D-Link a NTP serveru (Network Time Protocol) Poul-Henning Campa z poloviny 2000. let.

V roce 2005 vývojář FreeBSD Poul-Henning, který vlastnil také jediný v Dánsku server Network Time Protocol úrovně Stratum 1, obdržel nečekaně vysoký účet za přenesený provoz. Zjednodušeně řečeno, problém byl v tom, že vývojáři D-Link zapsali adresy NTP serverů Stratum 1, včetně serveru Campa, do firmwaru řady přepínačů, směrovačů a přístupových bodů společnosti. To bezprostředně zvýšilo devětkrát provoz serveru Campa, což vedlo k tomu, že Danish Internet Exchange (bod výměny internetového provozu v Dánsku) změnil jeho tarif z „Free“ na „9 000 dolarů ročně“.

Problém nespočíval v tom, že bylo příliš mnoho směrovačů D-Link, ale v tom, že porušovali hierarchii. Podobně jako DNS, i NTP by mělo fungovat v hierarchické podobě — servery úrovně Stratum 0 předávají informace serverům Stratum 1, které předávají informace serverům Stratum 2, a tak dále dolů v hierarchii. Běžný domácí směrovač, přepínač nebo přístupový bod, do kterého D-Link nahrál adresy NTP serverů, by měl posílat dotazy serveru Stratum 2 nebo Stratum 3.

Projekt Chromium, pravděpodobně s těmi nejlepšími úmysly, zopakoval problém s NTP v problému s DNS, zatěžující kořenové servery internetu dotazy, které nikdy neměly zpracovávat.

Naděje na brzké řešení existuje

V projektu Chromium je otevřený chyba, vyžadující pro odstranění tohoto problému vypnutí Intranet Redirect Detector jako výchozí. Je třeba vyzdvihnout projekt Chromium: chyba byla nalezena před tím, jak Matt Thomas z Verisign přitáhl k němu obrovskou pozornost svým příspěvkem v blogu APNIC. Chyba byla otevřena v červnu, ale zůstala zapomenuta až do příspěvku Thomase; po příspěvku byla pod pečlivým dohledem.

Existuje naděje, že problém bude brzy vyřešen, a kořenové DNS servery nebudou muset denně odpovídat na přibližně 60 miliard falešných dotazů.