Кратко

  • draft-ietf-dnsop-delegation-mgmt-via-ddns-02 предлагает отправлять точные изменения NS, glue или DS от ребёнка к приёмнику родителя через DNS UPDATE с SIG(0), находя адрес с помощью DSYNC.
  • Первый запрос bootstrap подписан самим новым ключом. Это доказывает владение закрытым ключом, но не право управлять ребёнком. Приёмник сначала помечает ключ как known и лишь после отдельной проверки переводит в trusted.
  • Нужна ведомость передачи полномочий, связывающая прежний ключ, метод bootstrap, независимые доказательства, решение политики, приём UPDATE и фактическую публикацию. Это рекомендация статьи, а не требование DNSOP.

Стартовый запрос способен одновременно предложить новый KEY и потребовать удаления старого набора. Подпись нового ключа может проверяться без ошибок. И всё же доказательство замкнуто на заявителе: любой может создать пару ключей и показать, что владеет её закрытой частью. Самоподпись ничего не говорит о воле регистранта или уполномоченного DNS-оператора.

Редакция 02 документа Automating DNS Delegation Management via DDNS опубликована 17 июня 2026 года. Это активный рабочий Internet-Draft группы DNSOP, который может измениться, быть заменён или истечь. В шапке текста стоит Standards Track, но Datatracker оставляет предполагаемый статус RFC пустым. Документ не является RFC и не подтверждает внедрение каким-либо реестром.

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

Сканеры CDS и CSYNC заставляют родителя периодически опрашивать детей. Предложенная схема отдаёт инициативу ребёнку, который уже знает об изменении, вычисляет разницу и отправляет безопасный DNS UPDATE. Родитель публикует в DSYNC адрес и порт приёмника. Снижаются задержка и объём сканирования, а неподписанные дети тоже получают путь к автоматизации.

Но вместе с вычислениями нельзя незаметно передать право решения.

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

DNS UPDATE несёт точные добавления и удаления, а SIG(0) защищает транзакцию. Если открытый ключ уже пользуется доверием, получатель проверяет целостность и владение соответствующим секретом.

При первом обмене доверие ещё только создаётся. Проект подчёркивает: криптографическая стойкость SIG(0) может быть сопоставима с DNSSEC, но модели доверия различны. DNSSEC обычно ведёт цепочку к настроенному якорю. Ключ UPDATE принимается индивидуально после bootstrap. Алгоритм защищает заявление, не назначает заявителя.

Поэтому UPDATE Receiver — не прямая труба записи в работающую родительскую зону. Его можно отделить от primary и поручить родителю или третьей стороне, например регистратору. Он ограничивает имена и типы данных, выполняет проверки CDS/CSYNC, ведёт аудит и передаёт одобренную операцию в систему провижининга.

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

Между known и trusted находится решение

Успешная самоподпись позволяет узнать предлагаемый ключ. Состояние называется known. Оно не является частичным доверием: это зафиксированное ожидание отдельной проверки. Только её успех даёт trusted.

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

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

Разные методы удостоверяют разных субъектов

Подписанный ребёнок публикует SIG(0)-ключ в вершине зоны, и родитель проверяет DNSSEC-цепочку. Для неподписанного ребёнка с nameserver в подписанной зоне оператор сервера может перепубликовать ключ под специальным именем. Возникает проверяемая цепочка, но требуется координация с DNS-провайдером, чьи внутренние действия остаются вне полной спецификации.

Метод unsigned сравнивает KEY, полученный из нескольких сетевых точек, в разное время и по разным транспортам. Устойчивое совпадение осложняет кратковременную подмену на пути. Оно не устанавливает личность регистранта. По тексту метод удостоверяет текущего оператора авторитативных серверов, а не владельца записи, и является самым слабым автоматическим вариантом.

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

Родителю следует сначала назвать принципала: регистрант, DNS-оператор, администратор аккаунта или владелец подписанной зоны. Эти роли иногда совпадают, но доказательство одной не должно автоматически подменять другую.

Выбор метода тоже уязвим

В SVCB у цели DSYNC родитель может объявить методы at-apex, at-ns, unsigned и manual через параметр bootstrap. Ребёнок видит поддерживаемый набор и выбирает доступный путь.

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

Аудит должен хранить весь объявленный набор, результат его проверки, возможности ребёнка и правило выбора. Запись «unsigned успешно» не выявит, был ли выбор заранее подменён.

NOERROR ещё не означает публикацию

Даже доверенно подписанный UPDATE проходит проверку диапазона, корректности и политики. NOERROR подтверждает получение и принятие. Проект говорит, что изменение следует ожидать в родительской зоне позже. Между ответом и видимостью остаётся провижининг.

При переносе nameserver прежнюю инфраструктуру опасно выключать сразу после ответа, пока родитель отдаёт старый NS. С DS такая ошибка способна вызвать сбой DNSSEC-валидации. Нужны четыре отметки времени: ключ известен, ключ доверен, UPDATE принят, RRsets опубликованы.

BADKEY, ожидание проверки, её провал, отказ политики и задержка публикации требуют разных действий. Общее состояние «ошибка обновления» скроет владельца ремонта. В обратную сторону ребёнок должен доверять ключу Receiver, иначе поддельный ответ может инициировать лишний повторный bootstrap. Он не даст атакующему изменить делегацию, но создаст нарушение работы.

Ведомость передачи полномочий

Предлагаю для каждого первого и повторного bootstrap сохранять закрытую ведомость перехода. Это не дополнительное требование IETF. Она объясняет, почему система сменила known на trusted.

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

Для DNSSEC сохраняются имена запросов, цепочка, время и результат. Для unsigned — действительная независимость точек наблюдения, времена, транспорты, полные отпечатки ответов и решение о совпадении. Для ручного процесса — ссылки на аутентифицированную сессию, проверенную роль, challenge, согласующего, восстановление и исключения без публичного раскрытия персональных данных.

Состояния known, начало проверки, ошибка, trusted, замена и отзыв становятся отдельными событиями. Ведомость показывает, что старый ключ не исчез до успеха нового. Следующий UPDATE добавляет точную разницу NS/glue/DS, проверки, решение, ответ и задание провижининга. Завершает цепочку наблюдение новых RRsets на авторитативных серверах родителя.

Автоматизация должна сокращать ожидание, а не доказательство. Ключ может представить себя. Право распоряжаться делегацией приходит извне — и должно оставить след.

Источники

  1. Автоматизация управления DNS-делегацией через DDNS — редакция 02
  2. Карточка проекта DNSOP в Datatracker
  3. История проекта
  4. Документы DNSOP
  5. Рабочая группа DNSOP
  6. RFC 9859 — обобщённые DNS-уведомления
  7. RFC 2136 — динамические обновления DNS
  8. RFC 2931 — подписи DNS-запросов и транзакций
  9. RFC 3007 — безопасное динамическое обновление
  10. RFC 8078 — управление DS со стороны родителя
  11. RFC 7477 — синхронизация от ребёнка к родителю
  12. The Policy Mirror