Кратко

  • draft-ietf-dnsop-ns-revalidation-14 позволяет предпочесть авторитетный набор NS на вершине дочерней зоны, но требует вовремя вернуться к родителю. Иначе прежняя дочерняя зона сможет собственными ответами бесконечно обновлять уже отозванное полномочие.
  • Надёжная квитанция связывает referral родителя, пересечение NS и DS, кратчайший из трёх поддерживающих TTL, аннулирование потомков кэша и новое разрешение имени. Успех одного шага не заменяет цепочку.

Старые серверы не отказали

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

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

Редакция 14 draft-ietf-dnsop-ns-revalidation от 2 сентября 2026 года предлагает необязательный алгоритм для этого разрыва. Это действующий Internet-Draft рабочей группы DNSOP с предполагаемым статусом Proposed Standard; Datatracker отмечает ожидание разрешения председателей и состояние IESG I-D Exists. Документ не является RFC и не доказывает внедрение на конкретном резолвере.

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

Два набора NS по разные стороны границы

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

По правилам RFC 2181 дочерний набор имеет более высокий ранг: он авторитетен, тогда как NS из родительского referral неавторитетен. Это полезно. Оператор дочерней зоны знает свою инфраструктуру и может задать короткий TTL для быстрой смены серверов, даже если родитель допускает только длинный фиксированный TTL.

Поэтому редакция 14 рекомендует при обнаружении новой границы явно запросить NS вершины дочерней зоны и предпочесть его в кэше. Адреса A и AAAA, полученные как glue или дополнительные данные низшего ранга, следует по возможности запросить заново. Для защищённого делегирования запрос NS можно отправить вместе с DNSKEY.

Но повышение достоверности отвечает лишь на вопрос, какие серверы называет сама дочерняя зона. Оно не доказывает, что родитель продолжает её выбирать. Иначе прежний оператор обновлял бы собственную легитимность каждым новым TTL.

Три срока для одного полномочия

Повторная проверка должна начаться не позднее истечения самого короткого TTL среди делегирующего NS родителя, родительского DS при его наличии и NS вершины дочерней зоны.

Каждый срок ограничивает отдельное отношение. TTL NS родителя ограничивает доверие к маршруту делегирования. TTL DS ограничивает связь с делегированным подписантом. TTL NS дочерней зоны ограничивает свежесть объявленного ею набора серверов. Минимум не позволяет одной длинной записи продлить власть другой стороны.

Проект советует применять разумный нижний предел TTL, чтобы зона с предельно короткими значениями не навязала постоянную вычислительную нагрузку. Это локальная защита от DoS, а не доказательство неизменности делегирования в добавленный интервал.

В журнале нужны все три исходных значения, локальный предел, время получения и фактический дедлайн. Одно поле «кэш действителен до» скрывает, какая именно связь истекла.

Непрерывность проверяется пересечением

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

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

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

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

Изменение наверху лишает опоры данные внизу

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

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

Поэтому эффективнее идти от корня вниз. Верхнее изменение может сделать нижние проверки бессмысленными. RFC 8020 показывает, как NXDOMAIN охватывает имена ниже точки. Здесь видна обратная зависимость: когда верхняя опора меняется, нижние байты могут оставаться в памяти, но прежнее право использовать их исчезает.

Наличие в памяти — факт хранения. Допустимость использования — факт полномочия и времени.

Строгий режим усиливает и проверку, и отказ

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

Без возврата к данным более низкого ранга отказ смягчить нечем. Ошибка в NS дочерней зоны или неправильная обработка явного запроса NS может привести к жёсткому сбою. Поэтому редакция 14 советует ограничить строгий режим корнем и зонами, делегированными непосредственно от него.

В opportunistic-режиме ответ может уйти до завершения проверки, а резолвер — вернуться к родительскому referral. Если дочерний сервер неверно обрабатывает NS-запрос, алгоритм для этой зоны следует прекратить. Доступность выше, защита слабее.

Индикатор «revalidation включена» не раскрывает этот выбор. Нужно знать, ждал ли ответ доказательства, вышел ли раньше, применялся ли fallback, произошёл ли hard failure и когда реально сменилось поколение кэша.

DNSSEC не подписывает всю инфраструктурную дорогу

NS в referral, glue и дополнительные A/AAAA обычно не имеют подписей DNSSEC. Подмена неподписанного адреса может направить резолвер к враждебному серверу, а тот — повлиять на неподписанные referrals ниже.

RFC 5452 усиливает сопоставление транзакций и энтропию, уменьшая шанс принять подделку. Повторная проверка отвечает на другой вопрос: сохраняют ли после транзакции инфраструктура и её поддержка родителем необходимую достоверность?

Даже корректная подпись DNSSEC — ограниченное доказательство. Она не подтверждает своевременный возврат к родителю, применение результата, аннулирование всех потомков или достижение приложением нужного сервиса.

Диагностика не переносит делегирование

Проект просит IANA выделить код Extended DNS Error для несовпадения NS в referral. RFC 8914 позволяет точнее сообщить причину отказа от пути. Но код не изменяет родителя, не исправляет дочернюю зону, не синхронизирует чужие кэши и не подтверждает восстановление.

Полезная запись связывает EDE с конкретным ответом родителя, сравненными наборами, версией и режимом резолвера, TTL, операцией аннулирования и последующим разрешением. Без этих связей это лишь ярлык.

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

Сведения о реализации не равны переписи

Приложение редакции 14 сообщает, что Unbound поддерживает opportunistic revalidation через отключённый по умолчанию harden-referral-path, а логику раздела 7 — с версии 1.4.17. Knot Resolver повторно проверяет priming-ответ корня с версии 1.5.1. Строгий режим за пределами прототипов и инструментов авторов документу неизвестен.

Это история работающего кода, но не доказательство настройки конкретного экземпляра, текущих defaults дистрибутива, распространённости, успешности или совместимости. Возможность подтверждается документацией; работа — наблюдением бинарного файла, конфигурации, таймеров, запросов и смены кэша.

Квитанция текущего делегирования

Надёжная запись включает сборку и активную конфигурацию резолвера; строгий или opportunistic-режим; исходный referral родителя с NS, DS, glue и временем; NS вершины дочерней зоны; заново полученные адреса; три TTL и локальный предел; цепочку от корня; свежий ответ родителя; расчёт пересечения NS и DS; переход DS между пустым и непустым состояниями; поколение и область аннулированного кэша; fallback, ошибку или EDE; выбранный новый сервер; независимое наблюдение сервиса.

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

Источники