Браузер Chromium, активно развивающийся open-source-родитель Google Chrome и нового Microsoft Edge, привлёк серьёзное негативное внимание из-за функции, которая была задумана с благими намерениями: она проверяет, не «похищает» ли провайдер у пользователя несуществующие результаты запросов доменов.
, создающий поддельные запросы случайных «доменов», существование которых статистически маловероятно, ответственен примерно за половину общего трафика, получаемого корневыми DNS-серверами по всему миру. Инженер Verisign Мэтт Томас написал пространный в блоге APNIC с описанием проблемы и оценкой её масштаба.
Как обычно выполняется DNS-преобразование
Эти сервера являются высшей инстанцией, к которой следует обращаться для резолвинга .com, .net и так далее, чтобы они сообщили вам, что frglxrtmpuf — это не домен верхнего уровня (TLD).
DNS, или Domain Name System («система доменных имён») — это система, благодаря которой компьютеры могут преобразовывать запоминающиеся доменные имена наподобие arstechnica.com в гораздо менее удобные IP-адреса, например 3.128.236.93. Без DNS Интернет не мог бы существовать в пригодном для людей виде, а значит, ненужная нагрузка на инфраструктуру верхнего уровня является реальной проблемой.
Для загрузки единственной современной веб-страницы может потребоваться невообразимое количество операций DNS-поиска. Например, когда мы анализировали главную страницу ESPN, то насчитали 93 отдельных доменных имени, от a.espncdn.com до z.motads.com. Все они необходимы для полной загрузки страницы!
Чтобы такую нагрузку могла выдерживать система поиска, которой необходимо обслуживать весь мир, DNS спроектирована как многоуровневая иерархия. На вершине этой пирамиды находятся корневые серверы — каждый домен верхнего уровня, например, .com, имеет собственное семейство серверов, являющихся высшей инстанцией для каждого домена ниже них. Одной ступенькой выше этих серверов находятся сами корневые сервера, от a.root-servers.net do m.root-servers.net.
Как часто это происходит?
Zahvaljujući višeslojnoj hijerarhiji keširanja DNS infrastrukture, vrlo mali postotak svetskih DNS zahteva dostiže korenske servere. Većina ljudi dobija informacije od DNS rezolvatora direktno od svog provajdera. Kada korisničkom uređaju zatreba informacija o tome kako da dođe do određenog sajta, zahtev se prvo šalje DNS serveru koji upravlja lokalni provajder. Ako lokalni DNS server ne zna odgovor, on preusmerava zahtev svojim "serverima preusmeravanja" (ukoliko su navedeni).
Ako ni lokalni DNS server provajdera, ni "serveri preusmeravanja" navedeni u njegovoj konfiguraciji nemaju keširani odgovor, zahtev se upućuje direktno punomoćnom serveru domena выше onog koji pokušavate da konvertujete. U slučaju domen.com to će značiti da se zahtev šalje punomoćnim serverima samog domena com, koji se nalaze na adresi gtld-servers.net.
Sistem gtld-servers, na koji je upućen zahtev, odgovara sa listom punomoćnih servera imena za domen domen.com, kao i sa najmanje jednim vezom koja sadrži IP adresu jednog takvog servera imena. Zatim se odgovori spuštaju po lancu — svaki server preusmeravanja prenosi ove odgovore serveru koji ih je tražio, sve dok odgovor konačno ne stigne do lokalnog provajdera i korisničkog računara. Svi oni pri tom keširaju ovaj odgovor, kako ne bi opterećivali sisteme višeg nivoa.
U većini slučajeva, zapisi servera imena za domen.com već će biti keširani na jednom od ovih servera preusmeravanja, tako da korenske servere niko ne uznemirava. Međutim, dok govorimo o uobičajenom obliku URL-a — onom koji se konvertuje u standardni veb sajt. Zahtevi Chrome-a se odnose na nivo выше ovoga, na stepen samih klastera root-servers.net.
Chromium i provera NXDomain prevare
Provere Chromium-a "da li me ovaj DNS server obmanjuje?" čine skoro polovinu celokupnog saobraćaja koji dostiže klaster korenskih DNS servera Verisign.
Brskalnik Chromium, starševski projekt Google Chrome, novega Microsoft Edge in številnih manj znanih brskalnikov, želi uporabnikom olajšati iskanje na enem polju, ki se včasih imenuje "Omnibox". Z drugimi besedami, uporabnik v isto besedilno polje na vrhu okna brskalnika vnese tako prave URL-je kot tudi poizvedbe iskalnika. Da bi še dodatno poenostavil, uporabniku ni treba vnesti dela URL-ja z http:// ili https://.
Ne glede na to, kako priročno je to, ta pristop zahteva, da brskalnik razume, kaj naj šteje za URL, in kaj za iskalno poizvedbo. V večini primerov je to precej očitno — na primer, niz s presledki ne more biti URL. Vendar pa je lahko stvar bolj zapletena, če upoštevamo intranete — zasebna omrežja, ki lahko uporabljajo tudi zasebne vrhnje domene za reševanje dejanskih spletnih mest.
Če uporabnik v intranetu svojega podjetja vnese "marketing", in v intranetu podjetja obstaja notranja spletna stran s tem imenom, potem Chromium prikaže pojavna okna, ki sprašujejo uporabnika, ali želi iskati "marketing", ali preiti na https://marketing. To je že nekoliko bolje, a mnogi ponudniki interneta in ponudniki javnih Wi-Fi omrežij "ukradejo" vsak vnesen napačen URL, preusmerjajoč uporabnika na kakšno stran, polno oglasnih pasic.
Naključna generacija
Razvijalci Chromuim niso želeli, da bi uporabniki v javnih omrežjih ob vsakem iskanju ene same besede videli pojavna okna, ki jih sprašujejo, kaj mislijo, zato so izvedli test: ob zagonu brskalnika ali spremembi omrežja Chromium izvede DNS iskanje treh naključno generiranih "domenskih" vrhnjih nivojev dolžine od sedem do petnajst znakov. Če se kateri koli dve od teh iskanj vrneta z enakim IP-naslovom, Chromium domneva, da lokalno omrežje "ukrade" napake NXDOMAIN, ki jih mora prejemati, zato brskalnik do nadaljnjega obvestila šteje vse vnešene poizvedbe iz ene besede za poskuse iskanja.
Na žalost v omrežjih, ki ne ukradejo rezultate DNS poizvedb, ti trije postopki običajno pridejo na vrh, do samih korenskih strežnikov imen: lokalni strežnik ne ve, kako pretvoriti qwajuixk, therefore it forwards this request to its forwarding server, which does the same until finally, a.root-servers.net either one of its 'brothers' is forced to say 'Sorry, but this is not a domain'.
Since there are approximately 1.67*10^21 possible fake domain names ranging from seven to fifteen characters long, most often each of these tests, conducted in a 'fair' network, reaches the root server. This amounts to as much as half of the total load on root DNS, according to statistics from that part of the clusters root-servers.net, which belong to Verisign.
History repeats itself
This is not the first case where a project created with the best intentions or nearly crashed a public resource with unnecessary traffic — it immediately reminded us of the long and sad history of D-Link and the NTP server (Network Time Protocol) by Poul-Henning Kamp in the mid-2000s.
In 2005, FreeBSD developer Poul-Henning, who also owned the only Stratum 1 Network Time Protocol server in Denmark, received an unexpected and high bill for traffic transmitted. In short, the reason was that D-Link developers had hardcoded Stratum 1 NTP server addresses, including Kamp's server, into the firmware of their switches, routers, and access points. This instantly increased Kamp's server traffic ninefold, causing the Danish Internet Exchange to change its rate from 'Free' to '9,000 dollars a year'.
The problem was not that there were too many D-Link routers, but that they 'disobeyed the hierarchy'. Just like DNS, NTP must operate in a hierarchical manner — Stratum 0 servers pass information to Stratum 1 servers, which pass information to Stratum 2 servers, and so on, down the hierarchy. A regular home router, switch, or access point, like those that D-Link hardcoded NTP server addresses into, should have been sending requests to a Stratum 2 or Stratum 3 server.
The Chromium project, likely with the best intentions, repeated the NTP problem in the DNS issue, flooding the root servers of the Internet with requests they were never meant to handle.
There is hope for a timely solution
The Chromium project is open , ki zahteva, da se privzeto onemogoči Intranet Redirect Detector. Treba je pohvaliti projekt Chromium: napaka je bila odkrita pred tem, ko je Matt Thomas iz Verisigna pritegnil veliko pozornosti s svojim v blogu APNIC. Napaka je bila odprta junija, a je ostala v pozabi do Thomasove objave; po objavi je začela biti pod natančnim nadzorom.
Obstaja upanje, da bo težava kmalu rešena in da korenskim DNS strežnikom ne bo več treba vsakodnevno odgovarjati na približno 60 milijard lažnih poizvedb.
V okviru oglaševanja
Epicni strežniki — to je ali Linux z zmogljivimi procesorji družine AMD EPYC in zelo hitrimi NVMe diski Intel. Pohitite z naročilom!
Izvor: habr.com
