Кратко

  • Редакция 02 позволяет дочерней зоне отправлять точные изменения NS, glue и DS обычным DNS UPDATE, защищённым SIG(0), на приёмник, найденный через DSYNC.
  • Самоподпись подтверждает владение закрытым ключом. Приёмник сначала помечает KEY как known и лишь после отдельной bootstrap-проверки повышает его до trusted.
  • При повторной привязке старый доверенный ключ сохраняется до проверки нового. Даже ответ NOERROR подтверждает только приём, а не публикацию в родительской зоне и не наблюдение резолвера.

В начальном сообщении опаснее всего выглядит не добавление, а удаление.

Согласно draft-ietf-dnsop-delegation-mgmt-via-ddns-02, дочерняя сторона посылает самоподписанный запрос удалить прежний KEY RRset и добавить новый KEY. Представленным открытым ключом можно проверить подпись и доказать, что отправитель владеет соответствующим секретом. Если этого было бы достаточно для немедленного удаления, злоумышленнику не требовалось бы подтвердить полномочия: созданная им пара ключей уже позволила бы выбить действующий доступ.

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

Обсуждение актуально сейчас. DNSOP открыл Working Group Last Call 20 августа и назначил 7 сентября датой окончания. 4 сентября председатель попросил явной поддержки и конструктивных замечаний, поскольку отсутствие возражений недостаточно. Geoff Huston поддержал публикацию и назвал push эффективнее родительского опроса. Johan Stenstam выделил работу с неподписанными дочерними зонами и сообщил о своей роли в реализации. Michael Richardson счёл текст пригодным для написания кода, но поднял вопросы KEY против DNSKEY, состояний, будущих алгоритмов и диаграммы переходов.

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

Новый opcode не появляется. Дочерняя зона формирует DNS UPDATE по RFC 2136, а SIG(0) из RFC 2931 и RFC 3007 подписывает транзакцию. DSYNC из RFC 9859 сообщает, принимает ли родитель такой способ и где расположен логический UPDATE Receiver. Приёмник может быть отделён от primary и передавать запрос в provisioning-систему, не меняя работающую зону напрямую.

Следовательно, аутентифицированный пакет не является приказом на исполнение. Приёмник ограничивает допустимые RRset. По умолчанию доверенный SIG(0)-ключ с точным именем дочерней зоны управляет только её делегированием. После этого всё ещё нужны содержательные проверки CDS/CDNSKEY и CSYNC. Push сокращает поиск изменения, но не забирает решение у родителя.

Методы bootstrap дают разные утверждения. Подписанная DNSSEC дочерняя зона публикует KEY в apex и предоставляет проверяемую цепочку. Если сама зона не подписана, но её nameserver находится в подписанной зоне, оператор сервера может опубликовать KEY под специальным именем у себя. Возможна и ручная сверка.

Для полностью неподписанного случая родитель сравнивает поданный KEY с ответами авторитетного сервиса из нескольких точек, в разное время и по разным транспортам. Это затрудняет перехват, но не создаёт права регистранта. Проект прямо ограничивает вывод: проверяется текущий оператор авторитетных серверов, а не держатель регистрации; доказательство не сильнее самих серверов.

Тип записи тоже нельзя стирать. SIG(0) использует KEY, а не DNSKEY. DNSKEY входит в структуру подписания DNSSEC-зоны; KEY здесь подтверждает транзакцию. Общая подпись «ключ DNS» скрывает разные хранилища, ротацию, реакцию на компрометацию и предел полномочий.

Коды ответа дают частичные квитанции. NOERROR означает, что приёмник получил и принял UPDATE, поэтому изменение родительских данных ожидается позже. Это не свидетельство завершённого provisioning, опубликованного serial, истёкшего кеша или успешного разрешения. REFUSED может означать политику, rate limit или ошибку настройки. BADKEY сообщает об отсутствии нужного открытого ключа, но не описывает все промежуточные состояния. Молчание не показывает, потерялся запрос или ответ.

Полная цепочка должна хранить DSYNC endpoint и версию политики, хеш UPDATE и prerequisites, идентификатор KEY, метод bootstrap, доказательства переходов known и trusted, решение и подписанный ответ, provisioning transaction, родительский serial, опубликованный RRset, виды резолверов после TTL и только затем результат сервиса.

Здесь работает принцип Heng Lu о слоях реальности. Запись может верно говорить, что ключ известен, но не вправе объявлять полномочия доказанными. Опубликованный проект не равен внедрению. Принятый запрос не равен публичному DNS. Автоматизация становится надёжной, когда один настоящий факт — владение — не получает символическую власть над всеми последующими фактами.

Источники