Кратко

  • С 29 июня 2026 года операторы корневой DNS-системы наблюдали примерно вдвое больше обычных запросов: около 3,2 млн в секунду против базового уровня примерно в 1,6 млн.
  • Представитель связанной автономной системы подтвердил, что трафик исходил из её сетей и появился после недавнего обновления рекурсивного ПО резолвера. В отчёте это названо непреднамеренным результатом; измеримого влияния на корневой сервис не выявили, а сеть, поставщик, версия и точный механизм не раскрыты.

Около 12:00 UTC 29 июня изменился профиль нагрузки на корневую DNS-инфраструктуру. Root Server Operators (RSO) сообщили, что средняя скорость запросов в системе выросла примерно с 1,6 до 3,2 млн в секунду. Увеличение наблюдалось у всех идентификаторов корневых серверов и в нескольких городских зонах, особенно на восточном побережье США и в Европе. По отдельным идентификаторам картина различалась.

Это не был поток некорректных пакетов. Операторы увидели правильно сформированные запросы с минимизацией имени, поступавшие с десятков тысяч IP-адресов и в основном касавшиеся .com, .net, .org, .info и .uk. Первичный анализ указал на несколько связанных автономных систем. После нескольких попыток связаться с источником представитель одной AS 3 июля подтвердил, что запросы пришли из её собственных сетей, а не с подменённых адресов. По его словам, недавнее обновление рекурсивного ПО резолвера непреднамеренно вызвало всплеск.

Краткий спад не означал завершения инцидента. 3 июля трафик снижался примерно на два часа, а затем снова вырос. После дальнейшего контакта 6 июля нормализация началась 7 июля. В публичном отчёте не сказано, остановил ли оператор развёртывание, изменил настройку, откатил версию или применил другой способ исправления. Связь с обновлением названа, но конкретное изменение не раскрыто.

Запрос, дошедший до корня, не равен одному пользовательскому поиску. DNS-резолверы кэшируют ответы; в FAQ операторов говорится, что для новой связи с корнем обычно требуется лишь небольшая доля запросов. Поэтому изменение в крупной рекурсивной сети способно изменить нагрузку, которую видят корневые операторы, без пропорционального роста пользовательского спроса. Отчёт не устанавливает, заметили ли что-либо пользователи, и не оценивает расходы в сетях-источниках.

Вывод о сервисе сформулирован уже: ни у одного оператора не зафиксировали измеримого влияния на доступность или производительность. Операторы не считали трафик преднамеренной атакой или опасностью для своей работы и не применяли меры смягчения. Это свидетельство устойчивости при наблюдавшемся событии, но не гарантия безвредности любого роста. В отчёте приведено ожидание RSSAC001: каждый оператор должен прилагать разумные усилия, чтобы инфраструктура выдерживала значительные колебания нагрузки.

Границы доказательств важны не меньше вывода. «Все идентификаторы» описывает охват наблюдений отчёта и не доказывает одинаковую нагрузку на каждом anycast-экземпляре. Объяснение через обновление рекурсивного ПО подтвердил представитель одной AS, но не названы сама AS, поставщик, версия, изменённая конфигурация или точный механизм генерации запросов. В отчёте упомянуты минимизированные имена, но не сказано, что именно эта техника вызвала рост. RFC 9156 объясняет, как кэш и структура имени могут менять число запросов; это контекст, а не причина данного эпизода.

Верная оценка — ни «атака», ни «ничего не случилось». Распределённое обновление изменило профиль запросов к вышестоящей инфраструктуре; корневые операторы это заметили, а разговор с исходной сетью предшествовал нормализации. Руководителям важно понять, можно ли в следующий раз быстро связать подобный сигнал с конкретным развёртыванием и тем самым отличить непреднамеренное изменение поведения от вредоносного трафика или нехватки мощности.

Источники