Использовали 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-зонами как с сервисом, лучше заранее:

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

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

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

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