Что произошло с DNS‑трафиком в августе 2026 года?

Я наткнулся на эту историю случайно, изучая статистику APNIC по DNS‑запросам к Cloudflare (1.1.1.1). Взгляд автоматически зацепился на заметный скачок в конце периода наблюдений и я почти машинально переключил график на последний год. Большую часть времени там ничего особенно интересного не происходило: линии жили примерно в одном диапазоне, но вот наступил август.

Доля запросов, которые APNIC относит к NXDOMAIN по неделегированному TLD, буквально за несколько дней резко ушла вверх. Не на какие‑то доли процента и не как обычный статистический шум. Из довольно спокойного многомесячного режима получился хорошо заметный импульс с максимумом в первой половине августа. И что ещё интереснее — после него график полностью к прежнему состоянию уже не вернулся.

Первой мыслью было — банально поискать объяснение в сети, ведь наверняка оно где‑то уже есть. Массовое обновление браузера, сбой DNS, очередная ботнет‑атака или какая‑нибудь известная кампания вредоносного ПО. Я полез искать — Cloudflare, APNIC, DNS‑операторов, исследовательские материалы. Но готового ответа в духе «вот почему в августе вырос NXDOMAIN» не нашёл. Тогда стало действительно интересно.

Потому что такой график легко может обмануть. Если одна категория запросов выросла или упала, её доля изменит вид всего графика, хотя с самим NXDOMAIN может вообще ничего не происходить. Поэтому прежде чем придумывать ботнеты и глобальные сбои, я решил проверить самое простое: а не врёт ли мне процентный график?

И вот тут история начала становиться заметно интереснее. Примерно в те же августовские дни в открытой статистике корневых DNS‑серверов обнаружился вполне реальный всплеск абсолютного количества NXDOMAIN‑ответов. То есть передо мной была уже не просто аномалия на дашборде Cloudflare.

Что‑то действительно произошло с DNS‑трафиком — и, судя по данным корневых DNS‑серверов, дело было уже не только в Cloudflare.

Проверяем август на другом уровне: root‑серверы

На этом месте мне хотелось понять главное: аномалия живёт только внутри Cloudflare или её видно выше по DNS‑цепочке?

Для этого я пошёл к статистике корневых DNS‑серверов. Здесь есть довольно удобный открытый источник — RSSAC002: стандартизированные суточные счётчики, которые публикуют операторы root‑сервисов A‑M.

В агрегированной статистике августовский всплеск был хорошо заметен и здесь. Но поскольку процент уже однажды заставил меня насторожиться, дальше я смотрел именно абсолютные значения. Для сравнения оставил девять root‑сервисов с полными и сопоставимыми данными.

И картина оказалась вполне однозначной.

В согласованной группе из девяти root‑сервисов средний уровень NXDOMAIN перед событием составлял около 49,5 млрд ответов в сутки. 10 августа — уже 153,9 млрд. То есть в 3 раза больше.

Одновременно вырос и сам входящий DNS‑трафик: примерно с 95,2 до 201,3 млрд запросов в сутки, то есть чуть больше чем вдвое. А вот NOERROR почти не изменился — около 42,3 млрд до события и 40,5 млрд на пике.

То есть процентный график Cloudflare меня не обманул в главном. В начале августа действительно появился дополнительный DNS‑поток, и почти весь его эффект пришёлся именно на отрицательные ответы. Причём событие оказалось довольно коротким. Основной рост начинается примерно 4–5 августа, максимум приходится на 9–10-е, а уже к 11–12 августа нагрузка резко идёт вниз. После этого NXDOMAIN в той же группе root‑сервисов возвращается почти к исходному уровню: около 50,0 млрд в сутки против 49,5 млрд до события.

Вот здесь, правда, пришлось немного притормозить.

Когда я начал сравнивать разные root‑сервисы между собой, выяснилось, что публичные счётчики не везде можно просто взять и сложить. У части операторов в стандартный экспорт не попадали отдельные DoT/DoQ‑поля, у нескольких рядов были пропуски, а у E‑ и F‑root обнаружились большие расхождения между rcode-volume и traffic-volume. Поэтому вместо того чтобы брать максимальные красивые цифры, я оставил постоянную группу A, B, D, H, I, J, K, L и M, где данные за нужный период можно было сопоставлять корректно; для B и H отдельно учёл опубликованный зашифрованный DNS‑трафик.

В итоге главный результат от этой чистки не исчез — наоборот, стал надёжнее:

августовский NXDOMAIN‑всплеск виден не только на Cloudflare. Он вполне реально присутствует и на уровне корневой DNS‑инфраструктуры.

И вот после этого возник уже следующий вопрос.

Если трафика стало примерно вдвое больше, а NXDOMAIN — втрое, что именно за запросы внезапно начали приходить на root‑серверы?

Что именно изменилось в трафике

Здесь особенно пригодился H‑root. Его оператор — U.S. Army DEVCOM Army Research Lab — публикует не только обычные RSSAC002-счётчики, но и дополнительные метрики — в частности, распределение запросов по количеству DNS‑меток и размерам сообщений. То есть можно было посмотреть на всплеск уже не просто как на число NXDOMAIN‑ответов, а немного заглянуть внутрь его структуры.

И первое, что бросается в глаза, — почти идеальное совпадение прироста общего трафика с приростом NXDOMAIN.

Перед событием H‑root получал в среднем около 9,27 млрд запросов в сутки. На пике 9 августа — уже 29,41 млрд, то есть примерно на 20,14 млрд больше. За тот же интервал NXDOMAIN вырос с 5,54 до 25,84 млрд — прирост составил 20,30 млрд. Если взять не один пиковый день, а всё окно 4–11 августа, получится ещё нагляднее: сверх обычного уровня пришло примерно 101,88 млрд дополнительных запросов, а дополнительный NXDOMAIN составил около 101,82 млрд.

Иными словами, практически весь дополнительный поток, появившийся в эти дни на H‑root, отражается именно в NXDOMAIN. Это уже заметно сужает пространство вариантов: перед нами не общий рост DNS‑активности, где всё увеличилось понемногу, а довольно специфический отрицательный поток.

Дальше стало ещё интереснее.

H‑root считает, сколько меток было в имени, которое пришло в запросе. Если сильно упростить, example — это одна метка, host.example — две, www.host.example — три.

До события запросы с одной меткой составляли около 2,52 млрд в сутки, а с двумя — около 2,65 млрд. На пике получилось уже 11,07 и 14,76 млрд соответственно. Рост — примерно в 4,4 и 5,6 раза. А вот запросы с тремя и более метками не выросли — наоборот, немного снизились. В результате доля одно‑ и двухметочных имён поднялась примерно с 56% до 88% всего классифицированного потока.

То есть дополнительный трафик имел вполне определённую форму: короткие по иерархии имена, одна‑две DNS‑метки.

Но тут есть важная оговорка. Одна метка на root-сервере ещё не означает, что клиент запросил одноуровневое имя: recursive resolver может использовать QNAME minimisation и отправлять наверх только нужную часть имени. Поэтому label-count хорошо описывает форму трафика на входе H-root, но по нему нельзя восстановить исходные QNAME на пользовательских устройствах.

Зато появился ещё один независимый признак — размер DNS‑сообщений.

В обычном режиме запросы размером 48–63 байта составляли около 30% UDP‑трафика H‑root. 9 августа их доля выросла уже до 54%, а абсолютное количество — примерно с 2,54 до 10,41 млрд в сутки. Только этот размерный диапазон дал около 73% чистого прироста UDP‑запросов. Похожая концентрация наблюдалась и в DNS‑over‑TLS.

Это не позволяет просто восстановить конкретный домен или программу — на размер DNS‑сообщения влияют не только символы имени, но и служебные поля, тип запроса, EDNS и другие вещи. Но как fingerprint это уже интересно: вместе с количеством меток меняется ещё и распределение размеров пакетов.

И ещё одна деталь, которая не очень хорошо укладывается в простую картинку типа «кто‑то просто залил root UDP‑мусором».

В H‑root заметная часть трафика шла через DNS‑over‑TLS. По агрегированным счётчикам для 10 августа можно получить консервативную нижнюю границу: не менее 4,96 млрд NXDOMAIN‑ответов в тот день должны приходиться на TLS‑составляющую. Это расчёт по суммарным данным, а не прямой срез RCODE × transport, поэтому воспринимать его нужно именно как нижнюю границу. Но сам факт важен: весь всплеск нельзя свести только к потоку поддельных UDP‑пакетов.

К этому моменту картина уже заметно отличалась от исходной, когда на графике был замечен просто рост NXDOMAIN на Cloudflare. Это всё ещё не говорит, кто его сгенерировал. Но уже довольно хорошо показывает, как он выглядел.

И вот после этого особенно интересным стал следующий вопрос: почему на root‑серверах этот поток почти исчез после 11–12 августа, а на графиках Cloudflare структура DNS‑ответов полностью к прежнему режиму так и не вернулась?

Почему Cloudflare и root после пика ведут себя по‑разному

Первой мыслью было: может быть, Cloudflare просто научился его фильтровать. Но здесь выяснилась важная архитектурная деталь.

Данные APNIC, с которых началась эта история, — это pre‑cache queries к 1.1.1.1. Иными словами, APNIC видит запросы, которые клиенты принесли в Cloudflare, ещё до того, как recursive resolver решил, что с ними делать. Это совсем не то же самое, что запросы, которые Cloudflare затем отправляет дальше к authoritative‑ или root‑серверам. (APNIC Blog)

А между этими двумя точками стоит довольно умная система.

1.1.1.1 использует DNS‑кэш, negative caching, QNAME minimisation и дедупликацию одновременно пришедших одинаковых запросов. Но самое интересное — Cloudflare держит локальные копии root zone. То есть для того, чтобы узнать, существует ли вообще такой TLD, ему не обязательно каждый раз спрашивать публичные A‑M root‑серверы. (Cloudflare Docs)

Получается примерно так:

клиент   ↓
1.1.1.1     ← APNIC видит запрос здесь   ↓
cache / local root / minimisation / deduplication   ↓
public root ← RSSAC002 видит уже здесь

И один и тот же исходный поток на этих двух точках может выглядеть совершенно по‑разному.

Допустим, клиенты продолжают спрашивать foo.some-weird-tld, bar.another-weird-tld и тысячи других имён. Для APNIC это всё ещё реальные новые запросы к 1.1.1.1 — они продолжают попадать в статистику. Но Cloudflare уже локально знает содержимое root zone и способен определить, что такого TLD нет, вообще не выходя во внешний root.

Поэтому повышенный NXDOMAIN на стороне Cloudflare и успокоившиеся root‑серверы не противоречат друг другу. Более того, для этого даже не обязательно предполагать, что Cloudflare срочно включил какую‑то специальную защиту именно 11 августа. Такая развязка уже заложена в самой архитектуре recursive resolver.

Но дальше картина стала ещё страннее.

Я посмотрел статистику Cloudflare по регионам. И если бы перед нами был какой‑то один равномерно распределённый глобальный процесс, я ожидал бы увидеть более‑менее похожую форму везде. Ничего подобного.

В Южной Америке доля NXDOMAIN выросла примерно с 7% до 27%, в Африке — с 6–7% до 21%. Европа тоже реагирует, но значительно слабее — примерно 13% → 18%. В Северной Америке изменение ещё скромнее. А в Азии выраженного августовского всплеска я практически не увидел.

Причём менялся не только NXDOMAIN.

В Южной Америке и Африке примерно одновременно заметно выросла доля ответов со статусом DNSSEC Secure в панели DNSSEC validation status . А если посмотреть на долю непустых ответов среди NOERROR (A & AAAA QTYPE), картина идёт в другую сторону: worldwide она снижается примерно с 87% до 77%, в Южной Америке — примерно с 79% до 63%.

То есть августовское изменение уже плохо описывается фразой: «стало больше запросов к несуществующим доменам».

Это может быть одна и та же новая категория трафика. Например, отрицательный ответ вполне может быть корректно подтверждён DNSSEC — NXDOMAIN не означает ошибку DNSSEC. Более того, NOERROR тоже не обязательно означает, что сервер вернул нужную запись: имя может существовать, а записи запрошенного типа у него не быть — так называемый NODATA.

Получается довольно многомерная картина:

NXDOMAIN ↑
DNSSEC Secure ↑
часть непустых NOERROR ↓
региональный эффект сильно различается

И вот география заставила меня серьёзно пересмотреть первоначальную модель.

До этого можно было представить август как один большой импульс, который прошёл через DNS‑инфраструктуру и постепенно погас. Теперь всё больше похоже, что произошло что‑то сложнее: разные клиентские и resolver‑популяции изменили своё поведение неодинаково, а разные слои DNS‑системы увидели разные проекции одного или нескольких процессов.

Очень похоже, что в августе изменилась не только амплитуда DNS‑трафика. В это время изменилась сама его структура.

И вот на этом фоне особенно интересно выглядело ещё одно совпадение. Практически ровно в те же дни APNIC проводил очень большой DNS‑эксперимент — причём как раз связанный с NXDOMAIN и поведением recursive resolvers.

APNIC: слишком хорошо совпавшие даты — но не готовая разгадка

5–11 августа 2026 года APNIC Labs проводил большой эксперимент с отрицательными DNS‑ответами. Для доставки теста использовалась рекламная сеть Google: в рекламное объявление встраивался небольшой скрипт, который запускался в браузере пользователя и инициировал обращение к специально сформированному DNS‑имени. Ничего устанавливать на устройство не требовалось — браузер получал URL и дальше работал обычный DNS‑стек пользователя. За неделю таким способом APNIC собрал около 115,8 млн измерительных endpoint'ов. (APNIC Blog)

Сам тест выглядел довольно просто. Для каждого запуска генерировалось случайное несуществующее имя в домене, которым управлял APNIC. Имя было уникальным, поэтому готового ответа в кеше быть не могло: recursive resolver должен был действительно выполнить разрешение и в итоге получить от экспериментального authoritative‑сервера NXDOMAIN.

Но дальше случилось как раз то, что заинтересовало самих исследователей.

Если учесть обычные запросы A, AAAA и HTTPS, примерно 116 млн тестов должны были породить около 218 млн DNS‑запросов, если каждый нужный тип запрашивался бы только один раз. Но фактически APNIC увидел 509,4 млн. Около 291,9 млн, то есть 57% всего потока, оказались повторными запросами. А для той части тестов, где повторы вообще начинались, средняя повторная активность доходила примерно до 6 повторных запросов на тест.

Сам руководитель исследования Geoff Huston в итоге задаёт примерно тот же вопрос, который возник у меня: почему DNS так неохотно принимает окончательный ответ «такого имени нет»? Где рождаются эти повторы — в stub resolver, recursive resolver или в более сложных конструкциях из front‑end и нескольких backend resolver engines?

И тут я снова посмотрел на наши даты.

Основной рост NXDOMAIN на root‑серверах начинается 4–5 августа. Пик приходится на 9–10-е. 11 августа поток резко идёт вниз, а 12-го уже почти возвращается к прежнему уровню.

Эксперимент APNIC:

5 августа → 11 августа.

Совпадение, мягко говоря, красивое.

Особенно с учётом того, что это был не тест на нескольких машинах в лаборатории, а массовое воздействие на реальный DNS resolver ecosystem через десятки миллионов браузерных endpoint'ов. И эксперимент как раз показал, что один исходный stimulus внутри DNS способен породить заметно больше запросов, чем можно было ожидать по простой схеме «один запрос — один ответ».

На этом месте очень легко сказать: ну вот и нашли причину.

Но дальше начинаются несостыковки.

Первая — уровень DNS, на котором проводился эксперимент.

APNIC генерировал случайные несуществующие имена внутри доменов, которыми сам управлял. То есть условно речь шла о чём‑то вроде:

random-string.experiment.example.net

Здесь .net существует и нормально делегирован. Поэтому такой запрос сам по себе не должен превращаться в NXDOMAIN на root‑сервере: root знает .net и просто направит resolver дальше по дереву. Отрицательный ответ возникает уже ниже — на экспериментальном authoritative‑сервере APNIC. (APNIC Blog)

А наш августовский root‑импульс — это как раз большое количество NXDOMAIN, которое видят корневые DNS‑сервисы.

То есть прямой путь:

эксперимент APNIC → те же запросы → root NXDOMAIN

не складывается.

Если связь между событиями действительно была, где‑то между ними должен существовать ещё один связанный механизм:

APNIC stimulus → поведение клиентов / resolver'ов → другие запросы → root NXDOMAIN

И вот это звено мы пока не видим.

Есть и вторая проблема.

APNIC отдельно пишет, что зона их NXDOMAIN‑теста не была подписана DNSSEC. Это было сделано специально, чтобы в эксперимент не вмешивались NSEC/NSEC3 и DNSSEC validation.

А в данных Cloudflare в ряде регионов примерно одновременно с NXDOMAIN заметно росла и доля ответов со статусом DNSSEC Secure.

Это ещё один аргумент против слишком простой версии «мы просто видим последствия именно этого теста». Прямой NXDOMAIN‑поток APNIC сам по себе не должен создавать такой DNSSEC‑профиль.

Есть и масштаб. APNIC увидел около 509 млн запросов за всю неделю. В нашем root‑анализе избыточный поток измеряется уже десятками и сотнями миллиардов сообщений. Поэтому даже с учётом повторов нельзя просто сказать, что эти 509 млн запросов и есть тот самый всплеск, который потом появился на root.

И всё же полностью выкинуть APNIC из картины я тоже не могу.

Слишком близко совпадает временное окно. Эксперимент реально воздействовал на огромную популяцию пользователей. Он специально создавал cache‑bypass DNS‑resolution events. И сам APNIC обнаружил, что resolver ecosystem умеет довольно активно размножать такие запросы.

Поэтому для меня это осталось не разгадкой, а очень интересным совпадающим событием.

Возможно, связи вообще нет, и рядом просто произошёл другой массовый rollout, сбой или автоматизированная активность, о которой пока никто публично не написал.

А возможно, связь есть, но она гораздо сложнее, чем на первый взгляд.

Похоже, в августе DNS вошёл в другой статистический режим

К концу расследования стало понятно, что август плохо описывается одной фразой «стало больше NXDOMAIN». Разные уровни DNS-инфраструктуры и разные регионы показывали заметно отличающуюся динамику.

В итоге наиболее аккуратная формулировка, к которой я пришёл, звучит так:

в августе 2026 года в нескольких разных точках наблюдения появились признаки структурного изменения DNS‑трафика, и пока ни одна из найденных моделей не объясняет их все одновременно.

Вполне возможно, что мы видим наложение нескольких процессов: изменение поведения клиентов или recursive resolvers, автоматизированную генерацию запросов, регионально неодинаковый rollout какого‑то ПО, экспериментальную активность и особенности обработки отрицательных ответов внутри крупных DNS‑платформ.

А возможно, у всего этого действительно есть один общий триггер — просто мы пока не видим недостающее звено.

Мне кажется, здесь как раз важно вовремя остановиться, потому что на уровне открытых данных мы уже подошли к границе. Дальше для нормальной атрибуции нужны сами QNAME, распределения по источникам, ASN, типам запросов и более подробная операторская телеметрия.

Поэтому я бы пока оставил эту историю открытой.

Самое интересное теперь — что покажет сентябрь.

Если показатели Cloudflare вернутся к старому baseline, август можно будет считать большим, но всё‑таки переходным событием.

Если новый уровень сохранится, это уже будет куда интереснее: тогда август действительно может оказаться точкой перехода к новому устойчивому режиму DNS‑трафика.

А если региональные профили продолжат расходиться, значит, искать один глобальный источник было бы неправильно.

На момент написания статьи готового ответа у меня нет.

Но, пожалуй, это как раз тот случай, когда отсутствие финальной разгадки не делает исследование бесполезным.

Наоборот: удалось хотя бы довольно точно зафиксировать что именно изменилось и где это было видно.

А дальше остаётся наблюдать.

Материал отражает мнение автора. Анализ выполнен на основе открытых источников и общедоступных данных; выводы и интерпретации принадлежат автору.

НЛО прилетело и оставило здесь промокод для читателей нашего блога:
-15% на заказ нового VDS — HABRFIRSTVDS.