Браузер 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 до m.root-servers.net.
Как часто это происходит?
Благодаря многоуровневой иерархии кэширования инфраструктуры DNS, корневых серверов достигает очень малый процент мировых DNS-запросов. Большинство людей получает информацию DNS-резолвера непосредственно от своего провайдера. Когда устройству пользователя нужно узнать, как попасть на определённый сайт, запрос сначала отправляется DNS-серверу, управляемому этим локальным провайдером. Если локальный DNS-сервер не знает ответа, он перенаправляет запрос собственным «серверам пересылки» (в случае, если они указаны).
Если ни у DNS-сервера локального провайдера, ни у заданных в его конфигурации «серверов пересылки» нет кэшированного ответа, запрос поднимается непосредственно к полномочному серверу домена выше того, который вы пытаетесь преобразовать. В случае домен.com это будет означать, что запрос отправляется к полномочным серверам самого домена com, которые находятся по адресу gtld-servers.net.
Система gtld-servers, к которой был запрос, отвечает на него списком полномочных серверов имён для домена домен.com, а также как минимум одной связующей записью, содержащей IP-адрес одного такого сервера имён. Далее ответы спускаются по цепочке — каждый сервер пересылки передаёт эти ответы вниз тому серверу, который их запрашивал, пока ответ наконец не достигнет сервера локального провайдера и компьютера пользователя. Все они при этом кэшируют этот ответ, чтобы без необходимости не беспокоить системы более верхнего уровня.
В большинстве случаев записи серверов имён для домен.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-запросов, эти три операции обычно поднимаются на самый верх, до самих корневых серверов имён: локальный сервер не знает, как преобразовать qwajuixk, поэтому перебрасывает этот запрос своему серверу пересылки, который делает то же самое, пока, наконец, a.root-servers.net или один из его «братьев» не будет вынужден сказать «Простите, но это не домен».
Так как существует приблизительно 1,67*10^21 возможных фальшивых доменных имён длиной от семи до пятнадцати символов, чаще всего каждый из этих тестов, выполненных в «честной» сети, добирается до корневого сервера. Это составляет аж половину от общей нагрузки на корневые DNS, если верить статистике от той части кластеров root-servers.net, которые принадлежат компании Verisign.
История повторяется
Это не первый случай, когда созданный с самыми благими намерениями проект или едва не заваливал общественный ресурс необязательным трафиком — нам это сразу же напомнило долгую и печальную историю D-Link и NTP-сервера (Network Time Protocol) Поуля-Хеннинга Кампа середины 2000-х.
В 2005 году разработчик FreeBSD Поуль-Хеннинг, владевший также единственным в Дании сервером Network Time Protocol уровня Stratum 1, получил неожиданный и большой счёт за переданный трафик. Если вкратце, то причина заключалась в том, что разработчики D-Link прописали адреса NTP-серверов Stratum 1, в том числе и сервера Кампа, в прошивку линейки коммутаторов, маршрутизаторов и точек доступа компании. Это мгновенно повысило в девять раз трафик сервера Кампа, из-за чего Danish Internet Exchange (точка обмена Интернет-трафиком Дании) сменила его тариф с «Бесплатного» на «9 000 долларов в год».
Проблема заключалась не в том, что маршрутизаторов 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 миллиардов фиктивных запросов.
На правах рекламы
Эпичные серверы — это или Linux с мощными процессорами семейства AMD EPYC и очень быстрыми NVMe дисками Intel. Спешите заказать!
Источник: habr.com