🥇Една от функциите на Chromium създава огромно натоварване на кореновите DNS сървъри

Браузер Chromium, който активно се развива като open-source родител на Google Chrome и новия Microsoft Edge, привлече сериозно негативно внимание заради функция, създадена с добри намерения: тя проверява дали интернет доставчикът не "открадва" от потребителя неистински резултати от запитвания за домейни.

Intranet Redirect Detector, създавайки фалшиви запитвания към случайни "домейни", чието съществуване е статистически малко вероятно, отговаря за около половината от общия трафик, получаван от кореновите 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 сървър на доставчика, нито зададените в неговата конфигурация „сървъри за пренасочване“ имат кеширан отговор, запитването се изпраща директно до упълномощения домейн сървър по-горе който се опитвате да преобразувате. В случая domain.com това ще означава, че запитването се изпраща до упълномощените сървъри на самия домейн com, които се намират на адрес gtld-servers.net.

Система gtld-сървъри, на който бе подадена заявка, отговаря с списък на упълномощените имена сървъри за домейна domain.com, а също и с поне една свързваща записа, съдържаща IP адрес на един от тези сървъри. След това отговорите се предават по веригата — всеки сървър за пренасочване предава тези отговори надолу към сървъра, който ги е поискал, докато отговорът накрая не достигне до сървъра на местния доставчик и компютъра на потребителя. Всички те кешират този отговор, за да не се налага да безпокоят системите на по-високо ниво.

В повечето случаи записите на имената на сървърите за domain.com вече ще бъдат кеширани на един от тези сървъри за пренасочване, така че кореновите сървъри никой не безпокои. Въпреки това, когато говорим за познатия ни вид URL — този, който се преобразува в обикновен уебсайт. Запитванията на Chrome се отнасят до нивото по-горе на това, на стъпалото на самите клъстери root-servers.net.

Chromium и проверка на NXDomain подмамване

Проверки на Chromium „Този DNS сървър не ме подвежда ли?“ съставляват почти половината от целия трафик, достигащ клъстера на кореновите DNS сървъри Verisign.

Браузер Chromium, родителският проект на Google Chrome, новия Microsoft Edge и безброй по-малко известни браузъри, цели да предостави на потребителите простота при търсене в едно поле, понякога наричано „Omnibox“. С други думи, потребителят въвежда както реални URL адреси, така и запитвания към търсачката в едно и също текстово поле в горната част на прозореца на браузера. Правейки още една стъпка към опростяване, той също така не заставя потребителя да въвежда част от URL адреса с http:// или https://.

Колкото и удобно да е това, този подход изисква браузерът да разбере какво да счита за URL, а какво – за търсене. В повечето случаи това е доста очевидно – например, низ с интервали не може да бъде URL. Но всичко може да бъде по-сложно, ако се вземат предвид интранетите – частни мрежи, които също могат да използват частни домейни от високо ниво за резолиране на истински уеб сайтове.

Ако потребителят в интранета на компанията си въвежда „marketing“, а в интранета на компанията има вътрешен уеб сайт с такова име, то Chromium показва изскачащ прозорец, питащ потребителя дали иска да търси „marketing“, или да отиде на https://marketing. Това е поносимо, но много интернет доставчици и доставчици на общи Wi-Fi мрежи „открадват“ всеки въведен с грешка URL, пренасочвайки потребителя на някаква страница, пренаситена с реклами.

Случайна генерация

Разработчиците на Chromium не искали потребителите в обикновени мрежи да виждат изскачащ прозорец, питащ какво точно означават при всяко търсене на една дума, затова те реализирали тест: при стартиране на браузера или смяна на мрежата, Chromium извършва DNS търсения на три случайно генерирани „домейна“ на високо ниво с дължина от седем до петнадесет символа. Ако каквито и да е два от тези запитвания се връщат с един и същи IP адрес, то Chromium предполага, че локалната мрежа „открадва“ грешките NXDOMAIN, които той трябва да получава, затова браузерът до по-нататъшно уведомление счита всички въведени запитвания от една дума за опити за търсене.

За съжаление, в мрежи, които не открадват резултатите от DNS запитванията, тези три операции обикновено се повдигат до най-високо ниво, до самите коренови DNS сървъри: локалният сървър не знае как да преобразува qwajuixk, поради това прехвърля тази заявка на своя сървър за пренасочване, който прави същото, докато, най-накрая, a.root-servers.net или един от неговите «братя» не бъде принуден да каже «Извинете, но това не е домейн».

Тъй като съществуват приблизително 1,67*10^21 възможни фалшиви домейн имена с дължина между седем и петнадесет символа, най-често всяко от тези тестове, извършвани в «честна» мрежа, достига до кореновия сървър. Това съставлява до половината от общото натоварване на кореновите DNS, ако вярваме на статистиката от онези части на клъстера root-servers.net, които принадлежат на компанията Verisign.

Историята се повтаря

Не е първият случай, в който проект, създаден с най-добри намерения, е провалял или едва не е провалял обществен ресурс с ненужен трафик — това веднага ни напомни за дългата и тъжна история на D-Link и NTP сървъра (Network Time Protocol) на Поул-Хенинг Камп от средата на 2000-те.

През 2005 година разработчикът на FreeBSD Поул-Хенинг, притежаващ също единствения в Дания Stratum 1 NTP сървър, получил неочаквана и голяма фактура за пренесен трафик. В кратце, причината беше в това, че разработчиците на D-Link записали адресите на Stratum 1 NTP сървърите, включително и сървъра на Камп, в фърмуера на редица комутатори, рутери и точки за достъп на компанията. Това моментално увеличило трафика на сървъра на Камп деветократно, в резултат на което Danish Internet Exchange (точка за обмен на интернет трафик в Дания) промени тарифата му от «Безплатна» на «9000 долара на година».

Проблемът не беше в това, че рутерите на D-Link бяха твърде много, а в това, че те «нарушаваха субординацията». Почти както и DNS, NTP трябва да работи в йерархична форма — сървърите от ниво Stratum 0 предават информация на сървърите от Stratum 1, които предават информация на сървърите от Stratum 2 и така нататък, надолу по йерархията. Обикновен домашен рутер, комутатор или точка за достъп, подобни на онези, в които D-Link е записала адресите на NTP сървърите, трябваше да изпращат заявки до сървъра от Stratum 2 или Stratum 3.

Проектът Chromium, вероятно с най-добри намерения, повтори проблема с NTP в проблема с DNS, като натовари кореновите сървъри на интернет със заявки, които те никога не трябваше да обработват.

Има надежда за бързо решение

В проекта Chromium има отворен баг, което изисква за разрешаване на този проблем деактивиране по подразбиране на Intranet Redirect Detector. Трябва да се отдаде дължимото на проекта Chromium: бъгът беше открит преди това, когато Мат Томас от Verisign привлече огромно внимание към него със своя пост в блога APNIC. Бъгът беше отворен през юни, но остана незабелязан до поста на Томас; след поста той започна да бъде внимателно наблюдаван.

Има надежда, че проблемът скоро ще бъде решен и кореновите DNS сървъри вече няма да трябва ежедневно да отговарят на около 60 милиарда фалшиви запитвания.