Кратко

  • CDS/CDNSKEY выражают желаемые параметры делегирования со стороны оператора дочерней DNS-зоны. Родительский агент должен аутентифицировать сигнал, опросить все адреса всех авторитетных серверов, сверить обе формы и доказать, что итоговый DS сохраняет хотя бы один рабочий путь DNSSEC-валидации.
  • NOTIFY(CDS) ускоряет обнаружение, но ничего не разрешает. Приёмка, публикация в родительской зоне, вытеснение старых значений из кэшей и наблюдение валидатором требуют собственных свидетельств.

Один адрес не согласился с остальными

Новый набор DNSKEY подписан, а CDS и CDNSKEY появились на основном сервере. Система подготовки данных показывает зелёный статус: ротация готова.

Родительский агент собирает все IPv4- и IPv6-адреса для каждого имени сервера из родительского делегирования. Большинство отвечает новым набором. Один адрес вторичного сервера продолжает отдавать прежний. Агент отменяет изменение и сохраняет существующий DS.

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

Сценарий также разделяет несколько значений слова «опубликовано»: записано в систему управления, доставлено на все авторитетные узлы, выпущено как DS в родительской зоне, увидено рекурсивными резолверами после истечения старого TTL. Один успешный ответ не доказывает всю цепочку.

Автоматизация не устраняет границу зон

Родитель публикует RRset DS, который указывает на DNSKEY дочерней зоны. Дочерняя зона публикует и подписывает собственный RRset DNSKEY. Независимый валидатор соединяет эти две административные поверхности в цепь доверия.

RFC 7344 определяет CDS как данные в формате DS, а CDNSKEY — как ключ, по которому родительская сторона может вычислить DS. Оба находятся на вершине дочерней зоны и сообщают желаемую конфигурацию. Они не дают удалённого права записи в родительскую зону.

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

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

Проверяется каждый адрес

RFC 9975 требует, чтобы родительский агент через валидирующий резолвер получил все IP-адреса каждого имени сервера из родительского делегирования, включая доступные glue-записи, и запросил каждый адрес.

Одно имя может иметь несколько A и AAAA, вести к разным anycast-узлам или системам публикации. При нескольких провайдерах различие ещё существеннее. Контрольная плоскость может считать развёртывание законченным, тогда как реально обслуживающий адрес остался на старом состоянии.

Согласованность нужна между всеми полученными ответами; NODATA тоже считается ответом. При расхождении операция прекращается без создания, изменения или удаления затронутых RRset. Голосования и угадывания по времени нет.

Недоступность — иной результат. Агент повторяет запрос позднее, желательно с экспоненциальной задержкой, и может использовать другую сеть, чтобы исключить локальную проблему маршрутизации. В журнале следует различать отсутствие ответа, противоречие и ошибку DNSSEC-проверки.

Два представления одной воли

CDS передаёт DS-форму, поэтому дочерняя сторона влияет на выбор digest. При CDNSKEY родитель вычисляет DS и применяет собственный выбор digest. Общего способа узнать предпочтение родителя нет, поэтому RFC 10026 требует публиковать обе формы, если оно неизвестно.

Избыточность повышает совместимость, но не позволяет сообщать две разные версии. CDS и CDNSKEY обязаны указывать на один набор ключей. При конфликте родитель отвергает запрос, а не выбирает удобную форму.

Криптографические рекомендации меняются. Реестры IANA для DNSSEC-алгоритмов и DS digest остаются текущим источником статуса. Воспроизводимое решение хранит входные данные, вычисленный DS и версию применённой политики.

Непрерывность — смысл приёмочной проверки

Даже полностью согласованный сигнал способен дать опасный DS. RFC 10026 требует убедиться, что результат сохранит DNSSEC-валидацию, и отменить изменение при неудаче.

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

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

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

Первичное включение не может заверить себя само

В уже защищённом делегировании существующая цепь аутентифицирует дальнейшие обновления CDS/CDNSKEY. При первом включении DS в родителе отсутствует. Подпись на вершине небезопасной дочерней зоны не может сама создать недостающее звено.

RFC 9615 использует подписанные сигнальные зоны DNS-оператора. Родительский агент валидирует их, находит относящиеся к дочерней зоне данные _dsboot и с их помощью аутентифицирует CDS/CDNSKEY пока ещё небезопасного делегирования.

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

RFC 8078 определяет явный сигнал удаления: CDS с алгоритмом 0, типом digest 0 и значением 00. Отсутствие CDS не означает просьбу отключить DNSSEC. Оно может быть задержкой публикации, поэтому молчание не должно запускать необратимое действие.

Уведомление звонит, но не открывает

Периодический опрос множества зон даёт задержку. RFC 9859 позволяет родителю опубликовать через DSYNC адрес службы уведомлений. Дочерний оператор отправляет NOTIFY(CDS) после изменения CDS/CDNSKEY.

Сообщение означает «проверь сейчас», но не «внеси изменение». Агент снова получает авторитетные данные, валидирует, сравнивает все адреса, вычисляет DS и проверяет непрерывность.

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

Поэтому метрики разделяют обнаружение цели, доставку уведомления, запуск сбора, согласованность, решение, публикацию и валидацию. Доставка звонка не является доказательством изменения DS.

После публикации начинается переход кэшей

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

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

RFC 10026 рекомендует временно снизить TTL нового DS примерно до пяти–пятнадцати минут для быстрого отката, а обычное значение восстановить после достаточного времени для исчезновения старого RRset. Новый короткий TTL не меняет уже сохранённые старые копии.

Внешние проверки должны покрывать горизонт старого TTL и несколько сетей. Каждая проба фиксирует увиденный DS, использованный DNSKEY и результат. Один успех доказывает один путь в один момент, а не глобальную сходимость.

Автоматика обязана оставить независимый выход

Обслуживание ключей — штатная безопасность. Обычная блокировка обновлений у регистратора или реестра сама по себе не должна останавливать аутентифицированное DS-обслуживание: чаще она защищает клиентский портал, а не действия посредника через его собственные полномочия.

Одновременно RFC 10026 требует иной, в том числе ручной, канал. Ключи могут быть утрачены, провайдер может не поддерживать протокол, а миграция — создать конкурирующие источники. Резервный путь должен аутентифицироваться независимо от потерянного ключа и оставлять равнозначную историю.

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

Источники