Как аномальный NXDOMAIN-трафик привёл к росту счетов в Cloud DNS, а поддержка не помогла вовремя

Использовали Cloud DNS, всё работало штатно.

В марте 2026 года мы столкнулись с неприятной ситуацией: в облачном DNS, который использовался для одной из наших публичных зон, начался резкий всплеск публичных авторитетных DNS-запросов, причём основную массу составляли ответы NXDOMAIN.

На практике это привело сразу к двум проблемам:

• резко выросла DNS-нагрузка, которую мы не считали легитимной;

• начали расти расходы на DNS-сервис.

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

В этой статье разберу:

• как мы заметили проблему;

• что показывали метрики;

• почему сочли трафик аномальным;

• как устроен экспорт зоны из облачного DNS;

• как мы готовили миграцию DNS на другой хостинг;

• и какие выводы из этого сделали.

---

Исходные вводные

У нас была публичная DNS-зона одного из наших доменов.

Это была обычная рабочая зона с типовым набором записей:

• A

• CNAME

• MX

• TXT

• NS

• служебные записи для почты, DKIM, DMARC, ACME challenge и инфраструктурных сервисов

На первый взгляд ничего необычного.

Через CLI зона определялась штатно, например так:

yc dns zone list

Среди результатов была нужная публичная зона:

<zone-id>  example-zone  example-company.ru.  PUBLIC

---

Как началась проблема

Первый тревожный сигнал был ещё в начале марта — примерно с 7 по 10 марта 2026 года. Тогда мы тоже наблюдали всплеск DNS-трафика, который выглядел нелегитимно, но на тот момент отдельное обращение в поддержку не создавали: природа происходящего ещё не была до конца понятна.

Основной и уже совсем явный инцидент произошёл позже — в период с 24 марта по 31 марта 2026 года.

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

Например, 22 марта 2026 года по метрикам было что-то близкое к обычному фону:

• A noerror — 9.38 запр./с

• A nxdomain — 0.57 запр./с

• сумма — 9.96 запр./с

А уже 25 марта 2026 года мы увидели совсем другие цифры:

• A nxdomain — 2 720.29 запр./с

• A noerror — 231.14 запр./с

• сумма — 2 951.43 запр./с

То есть основная масса запросов внезапно стала приходиться именно на NXDOMAIN.

---

Почему мы сочли этот трафик нелегитимным

Я специальноне хочу делать бездоказательных утверждений уровня «это точно была такая‑то атака» или «это точно проблема провайдера».

Корректнее сказать так: по профилю метрик этот трафик выглядел аномальным и нелегитимным для нашего реального сценария использования зоны.

Почему мы так считали:

• у нас не было событий, которые могли бы естественно объяснить такой рост запросов к несуществующим именам;

• основную массу составляли именно ответы NXDOMAIN;

• наблюдался повторный эпизод в этом же месяце;

• на стороне поддержки мы не получили внятного технического объяснения происходящего.

То есть с нашей точки зрения это было не «нормальное потребле»ние DNS, а аномальная активность, которая неожиданно легла в тарификацию.

Что ответила поддержка

Когда стало ясно, что ситуация не разовая и влияет на деньги, мы обратились в поддержку.

Сначала ожидали, что нам помогут хотя бы базово:

• объяснят природу всплеска;

• подскажут, как локализовать источник;

• предложат временные меры;

• дадут понятный технический комментарий.

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

На одно из наших жёстких сообщений о том, что из-за отсутствия реакции мы теряем деньги и вынуждены переносить DNS, был получен ответ примерно следующего содержания:

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

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

---

Почему это стало именно финансовой проблемой

Когда сталкиваешься с подобной историей впервые, кажется, что DNS — это просто инфраструктурный сервис, который «где‑то работает».

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

В нашем случае особенно неприятным оказался тот факт, что значительная доля аномального трафика приходилась на NXDOMAIN.

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

На этом этапе стало очевидно, что дальше просто ждать нельзя:

• нужно фиксировать претензию по начислениям;

• параллельно готовить выезд с площадки.

---

Принятое решение: перенос DNS на другую площадку

После нескольких дней без содержательного комментария мы приняли решение переносить зону на другую площадку.

В качестве целевого варианта выбрали более привычный внешний DNS-хостинг с импортом зоны через zone file.

Задача была несложной по логике, но неприятной по исполнению:

1. выгрузить записи зоны из облачного DNS;

2. привести их к формату, который можно импортировать на новой стороне;

3. проверить служебные записи;

4. не утащить лишние NS от старого провайдера;

5. отдельно внимательно посмотреть на TXT, MX, DKIM, DMARC, ACME challenge и инфраструктурные CNAME.

---

Экспорт зоны из облачного DNS

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

yc dns zone list-records

получим ошибку:

ERROR: either --id, --name or positional arg are required

То есть нужен либо id, либо name, либо positional argument.

После этого рабочая команда для зоны была такой:

yc dns zone list-records example-zone --format json > zone-records.json

Либо по id:

yc dns zone list-records <zone-id> --format json > zone-records.json

В JSON мы получили структуру такого вида:

{
  "record_sets": [
    {
      "name": "*.service.example-company.ru.",
      "type": "A",
      "ttl": "300",
      "data": [
        "203.0.113.10"
      ]
    },
    {
      "name": "_dmarc.example-company.ru.",
      "type": "TXT",
      "ttl": "300",
      "data": [
        ""v=DMARC1; p=none; sp=none; rua=mailto:dmarc@example-company.ru""
      ]
    }
  ]
}

---

Почему JSON пришлось конвертировать

На новой стороне импорт ожидал формат, близкий к обычному BIND zone file. Условно что-то такое:

$TTL 1d
example-company.ru. IN SOA ns1.provider.example. hostmaster.ns1.provider.example. (
        1
        14400
        3600
        604800
        10800
)

@       A       203.0.113.10
app     A       203.0.113.20
www     CNAME   infra.example-company.ru.

А облачный DNS отдавал данные в JSON-структуре record_sets.

Поэтому понадобился промежуточный конвертер из JSON в zone file.

Логика была такой:

• example-company.ru. превращаем в @

• www.example-company.ru. превращаем в www

• .service.example-company.ru. превращаем в .service

• TXT с несколькими значениями разворачиваем в несколько строк

• CNAME оставляем ссылками на каноническое имя

• NS от старого провайдера не переносим в целевую зону

• SOA не тащим

Итоговый импортируемый файл

После очистки мы подготовили вариант zone file без NS старого провайдера и без спорных записей.

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

На этом этапе уже было понятно, что технически сама миграция — не самая сложная часть истории. Намного неприятнее было то, что к ней пришлось переходить не по плану, а в аварийном режиме.

Что бы я рекомендовал всем, кто использует публичный DNS как сервис

После этой истории у меня появилось несколько очень практических выводов.

1. Мониторить NXDOMAIN отдельно

Если у провайдера есть метрики по кодам ответов, обязательно отслеживайте:

• noerror

• nxdomain

• пики

• общее число запросов за период

В обычной жизни DNS часто воспринимается как “фон”. Но когда на нём начинается мусорный трафик, становится уже не до теории.

---

2. Держать под рукой процедуру экспорта зоны

Пока всё работает — кажется, что экспорт всегда можно сделать “потом”.

Но когда нужно срочно переезжать, лучше уже заранее знать:

• где взять полный список записей;

• в каком виде он выгружается;

• как превратить это в zone file.

---

3. Не переносить зону без ревизии

Слепой перенос “всего подряд” — плохая идея.

Нужно отдельно смотреть:

• NS

• SOA

• private IP

• старые _acme-challenge

• устаревшие TXT

• инфраструктурные алиасы

---

Что оказалось важно при подготовке zone file

Когда мы собрали итоговый файл, всплыло несколько тонких моментов.

1. Нельзя бездумно переносить NS от старого провайдера

В zone file были строки вида:

@   60  IN  NS  ns1.old-provider.example.
@   60  IN  NS  ns2.old-provider.example.

Если импортировать это в новую DNS-площадку как есть, можно получить конфликт:

• либо импорт не примется;

• либо зона импортируется не так, как ожидаешь;

• либо потом будет путаница с авторитативными NS.

Поэтому NS старой площадки в файле мы удалили.

---

2. TXT и ACME challenge надо проверять особенно внимательно

Выгрузка содержала большое количество TXT-записей, в том числе для _acme-challenge.*.

Технически это валидно. Но подобные записи иногда:

• накапливаются от старых выпусков сертификатов;

• занимают много места;

• затрудняют импорт;

• создают визуальный шум.

Поэтому такие записи лучше отдельно ревизовать, а не переносить “на автомате всё подряд”.

---

3. Разделять технический тикет и финансовую претензию

Это тоже важный урок.

Если в одном обращении смешать:

• разбор инцидента,

• технические вопросы,

• претензию по деньгам,

то легко попасть в бесконечное “ожидаем информацию от коллег”.

Лучше сразу разделять:

• один тикет — технический разбор;

• второй — перерасчёт и оспаривание начислений.

---

5. Не ждать слишком долго без конкретики

Самая дорогая ошибка в таких историях — надеяться, что “вот-вот ответят”.

Если несколько дней нет предметного ответа, а ущерб продолжает расти, надо параллельно запускать аварийный план:

• экспорт;

• миграцию;

• фиксацию претензии;

• сбор доказательств.

---

Что осталось открытым

На момент подготовки этой статьи у нас оставались вопросы, на которые мы так и не получили полноценного ответа:

• какова была точная природа всплеска NXDOMAIN-трафика;

• можно ли было раньше локализовать источник;

• какие практические меры со стороны провайдера или поддержки могли бы снизить ущерб;

• будет ли перерасчёт за аномальный период;

• как оценят аналогичный эпизод в начале марта.

Если по этим вопросам позже появится официальный и содержательный ответ, эту историю можно будет дополнить второй частью.

---

Вывод

Вся эта ситуация ещё раз показала простую вещь: DNS — это не «что‑то фоновое», а вполне чувствительная часть инфраструктуры, которая в аномальном сценарии очень быстро превращается в финансовую проблему.

Когда у тебя внезапно:

• растут NXDOMAIN;

• растёт биллинг;

• поддержка не даёт ясности;

• а зона продолжает жить на проде,

перенос DNS надругую площадку из «когда‑нибудь потом» очень быстро превращается в задачу «сделать прямо сейчас».

Если вы работаете с публичными DNS-зонами как с сервисом, лучше заранее:

• мониторить аномалии;

• знать, как быстро выгрузить зону;

• иметь план ухода на другую площадку.

Потому что в день инцидента времени на теорию обычно уже нет.