Кратко

  • DS, которым пользуются валидаторы, является данными родительской зоны. CDS/CDNSKEY сообщает желаемое состояние со стороны ребёнка. При существующем DS текущая цепочка проверяет смену ключей; при первом включении этой цепочки ещё нет.
  • RFC 9615 использует одинаковые сигналы в уже защищённых пространствах каждого внешнего сервера имён. Это доказывает согласие перечисленных операторов, но не право собственности регистранта и не осознанное одобрение человека.
  • Политика допуска, выбор дайджеста, запись в родителе, истечение TTL и результат резолвера требуют отдельных доказательств. Нулевой алгоритм удаляет весь DS и не является обычной сменой ключа.

Подпись, которой не на что было опереться

Компания включает DNSSEC у управляемого DNS-провайдера. Сервис создаёт ключи, публикует DNSKEY, CDS и CDNSKEY на вершине зоны и корректно подписывает наборы RR. Все авторитетные серверы показывают одно состояние. В родительской зоне DS пока отсутствует.

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

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

Автоматизация решает реальную проблему: ручная передача дайджеста при каждой смене KSK или CSK даёт ошибки и задержки. Но сокращение ручного труда безопасно только тогда, когда сохраняется ответ на вопрос, почему именно этот родительский акт разрешён.

Ребёнок просит, родитель записывает

DS находится в родительской зоне и через метку ключа, алгоритм, тип дайджеста и сам дайджест указывает на DNSKEY дочерней зоны. CDS повторяет поля DS в отдельном типе RR. CDNSKEY несёт открытый ключ, по которому родительский агент вычисляет DS.

RFC 7344 задаёт смысл замены. Набор RR описывает желаемый итог, а получатель сравнивает его с текущим DS и выполняет изменения в своей системе. Ребёнок не получает права прямой записи в родителя.

Если нет ни CDS, ни CDNSKEY, состояние не меняется. После синхронизации сигналы могут быть удалены. Пустой результат опроса, ошибка запроса или такое удаление не означают убрать DS.

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

Роли остаются независимыми: оператор дочерней зоны публикует, родительский агент проверяет и допускает, родитель записывает, резолвер валидирует. Формат координирует их, не передаёт всю власть первому участнику.

Существующий DS создаёт мост для смены ключей

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

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

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

Актуальное руководство BIND показывает эту зависимость. BIND публикует CDS/CDNSKEY, опрашивает parental-agents и приостанавливает смену ключей, пока каждый не подтвердит ожидаемый DS. Если родитель не поддерживает автоматическую обработку, нужна ручная передача. Автоматический ребёнок не делает родителя автоматическим.

Первый DS заимствует доверие у оператора

RFC 8078 перечисляет способы первичного включения: защищённый интерфейс или API, дополнительные проверки регистрации, наблюдение в течение времени из разных мест, проверочный запрос или обработка при создании делегирования. Они могут подходить отношениям сторон, но не являются цепочкой DNSSEC из ещё незащищённой дочерней зоны.

RFC 9615 применяет другой путь, если есть хотя бы один сервер имён вне дочернего домена. К каждому имени из родительского набора NS добавляется _signal; под ним имя _dsboot конкретного ребёнка содержит копию CDS/CDNSKEY с вершины зоны.

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

Родительский агент подтверждает отсутствие DS и получает набор NS со стороны родителя. Без кэша он опрашивает каждый авторитетный сервер ребёнка. Затем валидирует каждый внешний сигнал и требует равенства отдельно по каждому типу RR.

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

Требование защищает делегирование с несколькими провайдерами. Один оператор не может единолично добиться DS на свой KSK, пока другие авторитетные серверы отдают несовместимое состояние. RFC 8901 также требует общей картины CDS/CDNSKEY при совместной подписи несколькими операторами.

Контроль оператора не равен праву владельца

RFC 9615 показывает, что операторы из набора NS готовы подписывать ребёнка и согласны с ключевым материалом. Она не показывает, кто заказал услугу, кто владеет доменом и было ли внутреннее одобрение.

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

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

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

Нулевой алгоритм означает полное удаление DS

Точные формы CDS 0 0 0 0 и CDNSKEY 0 3 0 0 требуют удалить весь набор DS. Ноль не является рабочим алгоритмом подписи, а отсутствие ответа не эквивалентно этому запросу.

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

Документированные состояния Cloudflare дают пример: во время отключения зона продолжает подписываться и выдаёт нулевой сигнал до исчезновения родительского DS; позже материал DNSSEC удаляется. Названия принадлежат продукту, раздельные часы принадлежат задаче.

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

Доказательство заканчивается у валидатора

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

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

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

Источники