После смены DNS сайт работает не у всех: как старый DS ломает DNSSEC

Администратор скопировал все A, MX и TXT-записи, поменял серверы имен у регистратора и увидел сайт с телефона. У части посетителей домен при этом перестал открываться, почта начала возвращать ошибки, а проверка через другой резолвер показала SERVFAIL. Если до переноса был включен DNSSEC, искать нужно не только в содержимом зоны, но и в цепочке доверия.

Зачем регистратору DS

DNSSEC добавляет криптографические подписи к DNS-ответам. В родительской зоне публикуется DS - отпечаток ключа подписания дочерней зоны. Валидирующий резолвер получает DS сверху и ожидает увидеть в домене соответствующую цепочку DNSKEY и подписей.

У нового DNS-провайдера обычно другие ключи. Если у регистратора остается DS старого провайдера, обычные записи могут быть правильными, но криптографическая проверка не сходится. Резолвер, проверяющий DNSSEC, считает ответ недостоверным и возвращает ошибку. Резолвер без проверки способен показать сайт, поэтому авария выглядит выборочной.

Cloudflare в документации формулирует два основных пути: отключить DNSSEC перед миграцией и включить заново у нового провайдера либо провести согласованную multi-signer миграцию. Просто сохранить прежний DS при новых ключах нельзя.

Простой путь с временным отключением

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

После исчезновения DS меняют NS, проверяют сайт, почту и служебные записи из нескольких сетей. Затем включают DNSSEC у нового провайдера, получают новый DS и передают его регистратору. В конце проверяют всю цепочку доверия.

Недостаток метода - период, когда зона не защищена DNSSEC. Зато он не требует обмена ключами между провайдерами и обычно подходит небольшим проектам. Нельзя включать новую DS-запись раньше, чем новый провайдер стабильно отдает соответствующие DNSKEY и подписи.

Перенос без разрыва защиты

Multi-signer позволяет двум провайдерам временно обслуживать подписанную зону так, чтобы ответы обоих проходили проверку. Для этого стороны обмениваются нужными открытыми ключами, а у родителя публикуются корректные DS. После периода совместной работы старый провайдер удаляется в определенной последовательности.

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

Такой способ оправдан для критичных зон, где даже временное отключение DNSSEC нежелательно. Без опыта его сначала испытывают на тестовом домене: ошибка порядка ключей и DS как раз создает ту аварию, которой миграция должна избежать.

Что проверить до смены NS

• Все A, AAAA, CNAME, MX, TXT, SRV и CAA перенесены.
• Уменьшенный заранее TTL действительно вступил в силу.
• Понятно, активен ли DS у регистратора.
• Выбран один из двух планов DNSSEC, а не смесь шагов.
• Старый провайдер не удалит зону сразу после изменения делегации.
• Есть способ проверить ответы через несколько валидирующих резолверов.

Особое внимание нужно почте. Даже если веб-сайт показывается из кэша или через CDN, ошибка разрешения MX и TXT нарушит прием писем, SPF, DKIM и подтверждения сторонних сервисов.

Как отличить DNSSEC-сбой

Сравните обычный запрос к авторитетному серверу с запросом через валидирующий публичный резолвер. Посмотрите DS у родителя, DNSKEY у новых NS и результат проверки подписей. Если прямой авторитетный ответ существует, но валидатор дает SERVFAIL, несовпадение цепочки является одним из главных подозреваемых.

Удаление случайных записей из зоны не исправит старый DS. Менять нужно согласованные элементы доверия у DNS-провайдера и в родительской зоне через регистратора. После исправления часть пользователей может видеть ошибку до истечения кэша.

DNSSEC делает подмену ответов сложнее, но требует аккуратности при смене инфраструктуры. Безопасный перенос начинается с инвентаризации ключей и DS, продолжается ожиданием TTL на каждом критичном шаге и заканчивается проверкой через независимые валидаторы.