Браузърът Chromium, процъфтяващият родител с отворен код на Google Chrome и новия Microsoft Edge, получи значително отрицателно внимание за функция, която е предназначена с добри намерения: той проверява дали ISP на потребителя „краде“ резултати от несъществуващи домейни. .
, който създава фалшиви заявки за произволни „домейни“, които е статистически малко вероятно да съществуват, е отговорен за приблизително половината от общия трафик, получен от основните 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 до m.root-servers.net.
Колко често се случва това?
Благодарение на многостепенната кешираща йерархия на DNS инфраструктурата, много малък процент от световните DNS заявки достигат до основните сървъри. Повечето хора получават информацията за своя DNS резолвер директно от своя интернет доставчик. Когато устройството на потребител трябва да знае как да стигне до определен уебсайт, първо се изпраща заявка до DNS сървър, управляван от този местен доставчик. Ако локалният DNS сървър не знае отговора, той препраща заявката към собствените си „препращачи“ (ако са посочени).
Ако нито DNS сървърът на локалния доставчик, нито „сървърите за пренасочване“, посочени в неговата конфигурация, имат кеширан отговор, заявката се повдига директно към авторитетния сървър на домейн горе този, който се опитвате да конвертирате. Кога домен.com това ще означава, че заявката се изпраща до авторитетните сървъри на самия домейн com, които се намират на gtld-servers.net.
Система gtld-servers, към който е направена заявката, отговаря със списък от авторитетни сървъри за имена за домейна domain.com, както и поне един запис на връзка, съдържащ IP адреса на един такъв сървър за имена. След това отговорите се придвижват надолу по веригата - всеки препращач предава тези отговори на сървъра, който ги е поискал, докато отговорът най-накрая достигне сървъра на локалния доставчик и компютъра на потребителя. Всички те кешират този отговор, за да не смущават ненужно системите от по-високо ниво.
В повечето случаи записите на сървъра за имена за домейн.com вече ще бъде кеширан на един от тези препращащи устройства, така че основните сървъри няма да бъдат обезпокоени. Засега обаче говорим за типа URL адрес, с който сме запознати – този, който се преобразува в обикновен уебсайт. Заявките за Chrome са на ниво горе това, на стъпалото на самите клъстери root-servers.net.
Проверка за кражба на Chromium и NXDomain
Chromium проверява „този DNS сървър заблуждава ли ме?“ представляват почти половината от целия трафик, достигащ до клъстера от главни DNS сървъри на Verisign.
Браузърът Chromium, основният проект на Google Chrome, новия Microsoft Edge и безброй по-малко известни браузъри, иска да предостави на потребителите лесното търсене в едно поле, понякога наричано „Поле за всичко“. С други думи, потребителят въвежда както реални URL адреси, така и заявки за търсачката в едно и също текстово поле в горната част на прозореца на браузъра. Предприемайки още една стъпка към опростяване, той също така не принуждава потребителя да въвежда част от URL адреса с http:// или https://.
Колкото и да е удобно, този подход изисква браузърът да разбере какво трябва да се счита за URL адрес и какво трябва да се счита за заявка за търсене. В повечето случаи това е доста очевидно - например низ с интервали не може да бъде URL. Но нещата могат да станат по-сложни, когато вземете предвид интранет - частни мрежи, които също могат да използват частни домейни от първо ниво за разрешаване на истински уебсайтове.
Ако потребител в интранета на своята компания въведе „маркетинг“ и интранетът на компанията има вътрешен уебсайт със същото име, тогава Chromium показва поле с информация, питайки потребителя дали иска да търси „маркетинг“ или да отиде на https://marketing. Това може да не е така, но много интернет доставчици и публични Wi-Fi доставчици „отвличат“ всеки грешно изписан URL адрес, пренасочвайки потребителя към някоя страница, пълна с банери.
Случайно генериране
Разработчиците на Chromium не искаха потребителите в обикновените мрежи да виждат информационно поле, питащо какво имат предвид всеки път, когато търсят една дума, така че внедриха тест: когато стартират браузър или променят мрежи, Chromium извършва DNS търсения на три произволно генерирани "домейни" от най-високо ниво, дълги от седем до петнадесет знака. Ако две от тези заявки се върнат с един и същ IP адрес, Chromium приема, че локалната мрежа „отвлича“ грешките NXDOMAIN, които трябва да получи, така че браузърът счита всички въведени заявки с една дума за опити за търсене до второ нареждане.
За съжаление, в мрежите, които не крадат резултатите от DNS заявки, тези три операции обикновено се издигат до самия връх, чак до самите основни сървъри за имена: локалният сървър не знае как да разреши qwajuixk, така че препраща тази заявка към своя препращач, който прави същото, докато накрая a.root-servers.net или някой от неговите „братя“ няма да бъде принуден да каже „Съжалявам, но това не е домейн“.
Тъй като има приблизително 1,67*10^21 възможни фалшиви имена на домейни с дължина от седем до петнадесет знака, най-често срещаните всеки от тези тестове, извършени в „честната“ мрежа, той стига до основния сървър. Това възлиза на толкова наполовина от общото натоварване на главния DNS, според статистиката от тази част от клъстерите root-servers.net, които са собственост на Verisign.
Историята се повтаря
Това не е първият случай, когато проект е създаден с най-добри намерения или почти наводни публичен ресурс с ненужен трафик - това веднага ни напомни за дългата и тъжна история на NTP (Network Time Protocol) сървъра на D-Link и Poul-Henning Kamp в средата на 2000-те.
През 2005 г. разработчикът на FreeBSD Poul-Henning, който притежаваше и единствения в Дания сървър на Stratum 1 Network Time Protocol, получи неочаквана и голяма сметка за пренесен трафик. Накратко, причината беше, че разработчиците на D-Link записаха адресите на Stratum 1 NTP сървъри, включително сървъра Kampa, във фърмуера на линията от суичове, рутери и точки за достъп на компанията. Това незабавно увеличи трафика на сървъра на Kampa девет пъти, което накара Danish Internet Exchange (точка за интернет обмен на Дания) да промени тарифата си от „Безплатна“ на „9$ на година“.
Проблемът не беше, че имаше твърде много рутери на D-Link, а че бяха „извън линията“. Подобно на DNS, NTP трябва да работи в йерархична форма - сървърите от слой 0 предават информация на сървъри от слой 1, които предават информация на сървъри от слой 2 и така нататък надолу по йерархията. Типичен домашен рутер, комутатор или точка за достъп като тази, която D-Link програмира с NTP сървърни адреси, ще изпрати заявки до сървъра Stratum 2 или Stratum 3.
Проектът Chromium, вероятно с най-добри намерения, повтори проблема с NTP в проблема с DNS, зареждайки основните сървъри на Интернет със заявки, които те никога не са били предназначени да обработват.
Има надежда за бързо решение
Проектът Chromium има отворен код , което изисква деактивиране на Intranet Redirect Detector по подразбиране, за да разреши този проблем. Трябва да отдадем заслуженото на проекта Chromium: грешката беше открита преди товакак Мат Томас от Verisign му привлече много внимание със своя в блога на APNIC. Грешката беше открита през юни, но остана забравена до публикацията на Томас; След като постеше, той започна да бъде под строго наблюдение.
Надяваме се, че проблемът скоро ще бъде разрешен и главните DNS сървъри вече няма да трябва да отговарят на приблизително 60 милиарда фалшиви заявки всеки ден.
Относно правата на рекламата
Епични сървъри - или Linux с мощни процесори от семейството AMD EPYC и много бързи Intel NVMe устройства. Побързайте да поръчате!
Източник: www.habr.com