Смена корневого DNSSEC-ключа в 2026 году: что владельцу домена проверить заранее

ICANN объявила план смены корневого KSK: новый ключ должен начать подписывать корневую зону в октябре 2026 года, а старый будет выведен в январе 2027 года. Для обычного сайта это не означает замену домена или сертификата. Практический вопрос — умеют ли используемые резолверы обновлять trust anchor.

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

Смена проходит по плану с периодом, когда действуют текущий и новый ключ. Это позволяет операторам подготовить trust anchor. Не путайте событие с изменением NS-записей вашего домена.

A-запись, CNAME, MX и сертификат остаются вашими настройками. Проверить нужно не значение домена, а путь, по которому резолвер получает и проверяет ответ.

Большинство владельцев сайта зависит от DNS-провайдера и интернет-провайдера. Если они обслуживают цепочку корректно, дополнительных ручных действий обычно не требуется. Повышенное внимание нужно тем, кто управляет собственным резолвером или DNSSEC.

Уточните у DNS-провайдера, поддерживается ли автоматическое обновление trust anchor. Сохраните контакты и инструкцию аварийного реагирования, но не меняйте DNSSEC без причины.

Проверьте версию программного обеспечения, источник ключей и процедуру обновления. Тестируйте в отдельной среде до даты rollover. Инженерная проверка важнее совета «отключить DNSSEC».

Проверьте домен через сервисы анализа DNSSEC или командой, которую использует ваш администратор. Сравните результат через домашний и корпоративный резолвер.

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

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

Задайте конкретные вопросы: как обновляется trust anchor, кто отвечает за мониторинг и какой канал уведомлений используется. Для корпоративной сети уточните, не перехватывает ли DNS локальный фильтр.

Наличие DNSSEC в тарифе ещё не отвечает на вопрос об обновлении корневого ключа. Попросите ссылку на документацию и дату последней проверки.

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

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

Сначала соберите диагностические данные и проверьте официальные объявления провайдера. Если домен коммерческий, привлеките администратора DNS.

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