Резервные NS и Secondary DNS: как подготовиться к сбою

Резерв должен отвечать до аварии

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

В зрелой схеме есть primary DNS, secondary DNS, понятная синхронизация зоны, контроль SOA serial и регулярная проверка критичных записей. Это продолжение темы отказоустойчивого DNS для VPN-сайта, но с фокусом на то, как именно резервные NS держат актуальную копию зоны.

Primary, secondary и SOA serial

Secondary DNS обычно получает зону от primary через zone transfer или другой механизм синхронизации. SOA serial показывает версию зоны. Если serial на primary и secondary различается, один из серверов может отдавать устаревшие записи. Это опаснее, чем полный отказ: часть пользователей получает правильный ответ, часть — старый.

При проверке нельзя смотреть только основной домен. Нужно сверять A, AAAA, CNAME, MX, TXT, NS, SOA и критичные поддомены: кабинет, API, help, status. Если проект использует DNSSEC, резервная схема должна учитывать подписи и DS. Иначе валидирующие резолверы могут отвергать часть ответов.

Когда резервный NS создаёт ложную уверенность

Самая частая ошибка — добавить второй провайдер, но не настроить синхронизацию. В панели всё выглядит надёжно: NS несколько, провайдеры разные. На практике secondary держит старую версию зоны или не знает о новых поддоменах. При сбое primary пользователи начинают получать ответы из прошлого состояния.

Вторая ошибка — не проверять secondary напрямую. Если мониторинг спрашивает только домен через обычный резолвер, он может не заметить, что один авторитетный сервер отстаёт. Поэтому мониторинг должен периодически опрашивать каждый NS отдельно. Для постоянного контроля полезно связать эту тему с мониторингом DNS, SSL и uptime.

Как готовить резерв

Практический порядок:

1. выбрать провайдера, который поддерживает secondary DNS или экспорт зоны;

2. настроить передачу зоны и проверить SOA serial;

3. сверить критичные записи на каждом NS;

4. проверить DNSSEC, если он включён;

5. добавить резервные NS в делегацию только после теста;

6. включить мониторинг каждого авторитетного сервера;

7. описать, кто имеет право менять primary.

Если используется Anycast-провайдер, это не отменяет secondary DNS. Anycast повышает устойчивость внутри одного сервиса, а secondary снижает зависимость от одного провайдера. Разница между ними разобрана в статье про Anycast DNS.

Кейс: резерв отдавал старый кабинет

У проекта были primary и secondary NS. Во время проверки оказалось, что один secondary не получил последнюю версию зоны: в нём отсутствовал поддомен кабинета, добавленный месяц назад. Обычный пользовательский тест не ловил проблему, потому что большинство запросов попадало на primary.

После проверки каждого NS отдельно нашли расхождение SOA serial. Настроили передачу зоны, добавили уведомление о несовпадении serial и включили отдельный контроль для кабинета и API. Резерв стал рабочим только после того, как его начали проверять как самостоятельный источник ответов.

Контроль резервной зоны

secondary DNS получает актуальную зону;
SOA serial совпадает на primary и secondary;
каждый NS отвечает одинаково по критичным записям;
DNSSEC не ломается при резервной схеме;
мониторинг спрашивает авторитетные серверы отдельно;
есть понятный владелец primary-зоны.

Как часто проверять резерв

Резервные NS стоит проверять не только после крупных релизов. Новая запись для API, изменение MX, выпуск DKIM, добавление TXT-подтверждения или включение DNSSEC — любое из этих действий должно дойти до secondary. Если проверка делается раз в год, резерв почти наверняка устареет. Практичный вариант — мониторить SOA serial и несколько критичных записей автоматически, а после важных изменений вручную сверять primary и secondary.

Отдельно стоит описать, кто имеет право менять primary-зону. Если разные люди вносят правки в обход регламента, secondary может получать неполный набор данных или конфликтующие версии. Резерв DNS — это не только техника, но и дисциплина владения зоной.

Что происходит при рассинхронизации

Рассинхронизация primary и secondary редко выглядит как полный обвал. Чаще появляется странная выборочность: один пользователь видит новый IP, другой старый, почта у части отправителей проходит, а отдельный поддомен иногда исчезает. Такие симптомы легко принять за кэш, хотя один из авторитетных серверов просто живёт в прошлой версии зоны. Поэтому при расследовании смотрят не только резолверы, но и каждый NS отдельно. Если ответы отличаются, ожидание TTL не решит проблему: нужно чинить передачу зоны и serial.

Как подготовить резервные NS без ложного чувства отказоустойчивости

Независимость операторов

Домен VPN и поддомены VPN должны иметь актуальную зону на резервной стороне. Домен для VPN сервера проверяют отдельно. DNS для VPN не становится отказоустойчивым только от добавления второго имени NS: важны независимые площадки и синхронные записи.

Резервные компоненты

Адрес VPN сервера должен оставаться доступным при отказе одного DNS-оператора. Хостинг для VPN и VPN на VPS проверяют на готовность узла. Сертификат для VPN должен продлеваться по понятной процедуре и на резервном пути.

Пользовательская конфигурация

VPN подписка и профиль VPN не должны зависеть от единственного недоступного имени. Ссылка VPN хранится защищённо. VPN для нескольких устройств проверяют после восстановления выдачи, не создавая новые регистрации всем пользователям.

Проверка отказа

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

В этой схеме серверная часть — vpn сервер; рядом разобраны vpn подписка и клиентские шаги для vpn для android и vpn для телефона и vpn для путешествий.

FAQ о резервных NS

Secondary DNS нужен любому сайту?

Не любому. Он важнее для проектов, где DNS-сбой ломает кабинет, оплату, API, поддержку или инструкции.

Что такое SOA serial?

Это версия DNS-зоны. По нему удобно понять, получил ли secondary свежие изменения.

Можно ли добавить резерв после сбоя?

Технически можно, но это не даст мгновенного эффекта из-за делегации, TTL и кэша. Резерв готовят заранее.

Что проверять на резервном NS?

Не только основной домен. Сверяют сайт, почту, API, кабинет, TXT-политики, SOA и DNSSEC.

Что должен хранить резервный DNS для VPN, чтобы он действительно помог?

Актуальную зону с нужными адресами и служебными записями, а не только копию главной A-записи. Проверьте обновление вторичного сервера и согласованность ответов. Если обе точки зависят от одного недоступного управления или канала, формальное наличие второго NS ещё не даёт нужной устойчивости.

Резервный DNS для VPN поможет при падении самого сервера?

Он может сохранить разрешение имён, но не восстановит неработающий сервис. Разделите DNS для VPN и доступность узла. Если мониторинг сообщает об ошибке, сначала нужно проверить VPN соединение на конкретном этапе, а затем решать, переключать DNS, восстанавливать приложение или исправлять сертификат.

Источники

---