Кратко

  • 1 сентября 2026 года сопредседатели DNSOP констатировали явную поддержку принятия draft-huque-dnsop-multi-alg-rules-08, но прямо оставили вопросы сложности для последующей работы группы.
  • Проект вводит состояния UNIVERSAL и FORMERLY-UNIVERSAL; при определённом составе алгоритмов подписывающая сторона сможет не выдавать часть объявленных подписей.
  • То же состояние меняет решение валидатора, локально отключившего алгоритм, поэтому это исполняемое правило, а не справочная отметка.
  • Daniel Kade предлагает отдельную квитанцию с данными о развёртывании для каждого будущего изменения классификации. Принятие выбирает работу, а Standards Action должна будет разрешить запись IANA.

В итоговом решении остался открытый вопрос

В письме о завершении call for adoption председатели сообщили о явной поддержке принятия документа. Следующей фразой они сохранили замечания о сложности предложенного механизма и направили их в дальнейшую работу WG. Первая фраза меняет процессуальный статус; вторая ограничивает смысл этого изменения.

Обсуждение началось 13 августа и завершилось 31-го. Текущая карточка Datatracker называет активный Internet-Draft принятым рабочей группой. В разделе IESG по-прежнему стоит I-D Exists; shepherd, ответственный Area Director и дата telechat не указаны. Редакция 08 перешла под управление изменений DNSOP, но не стала RFC или утверждённым правилом IETF.

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

Действующее правило требует полного набора не случайно

RFC 4035 требует для каждого RRset подпись хотя бы одним DNSKEY каждого алгоритма из apex DNSKEY RRset. Сам apex-набор должен быть подписан каждым алгоритмом, присутствующим в родительском DS RRset. RFC 6840 повторяет требование полноты для подписанта, но говорит валидатору принимать любой действительный путь.

Подписант не знает, какие алгоритмы реализованы у каждого валидатора. Полный опубликованный набор не позволяет выдать удаление поддерживаемой подписи за разрешённое отсутствие. Эта страховка создаёт зависимость между провайдерами. По RFC 8901 участникам multi-signer-схемы нужен общий алгоритм. Провайдеры с непересекающимися наборами не могут провести переход простым объединением своих ключей.

Редакция 08 пытается ослабить это ограничение. Среди её сценариев — постоянная работа нескольких подписантов, смена провайдера, раздельная замена алгоритмов KSK и ZSK, предварительная публикация trust anchor и эксперимент с новым алгоритмом у одного поставщика без синхронного обновления всех остальных. DNSOP признала эти задачи достойными общей работы. Конкретная конструкция остаётся предметом этой работы.

Слово в реестре станет условием выполнения

Проект предлагает новую колонку IANA Validation support status со значениями UNIVERSAL, FORMERLY-UNIVERSAL или пусто. В начальном варианте алгоритмы 8 и 13 получают UNIVERSAL, а бывших универсальных алгоритмов нет. В действующем реестре алгоритмов DNSSEC IANA такой колонки пока нет; для 8 и 13 там указано требование реализации проверки MUST.

Если в DS или наборе trust anchors есть хотя бы один UNIVERSAL и нет ни одного FORMERLY-UNIVERSAL, подписант сможет выдать подпись лишь одним универсальным алгоритмом. Остальные объявленные подписи будут необязательны. В иных сочетаниях сохранится требование подписывать всеми алгоритмами.

У валидатора появится другое ветвление. Если он не поддерживает объявленный UNIVERSAL или когда-то универсальный алгоритм, то должен считать зону неподписанной, даже поддерживая иной алгоритм из того же набора. В остальных случаях принимается любой действительный путь. Локальное отключение алгоритма потребует помнить его прежний глобальный статус.

Следовательно, метка определяет не престиж. Она задаёт, что подписант вправе не передать и когда несовместимость заканчивается состоянием Insecure, а не Bogus. Преждевременная или устаревшая оценка превращается в поведение доступности и безопасности.

RFC 9904 уже разделяет рекомендации по использованию и требования к реализации и хранит их канонические значения в IANA. Документ предполагает изменение рекомендаций и постепенный вывод алгоритмов. Новая колонка выполняла бы иную функцию. Соседство с существующими полями не даёт ей их доказательной основы.

Поддержка работы не устранила возражения против схемы

Публичные ответы показывают содержание оговорки. Mark Andrews выступил против проекта и оспорил предположение о поддержке среди валидаторов по всему миру. Paul Hoffman поддержал ослабление старого правила, но отверг нынешнюю пару состояний. Paul Wouters поддержал принятие и попросил значительно упростить документ.

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

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

Для классификации нужна отдельная квитанция

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

Там же нужны ожидаемые результаты Secure, Insecure и Bogus для типичных multi-signer-конфигураций и смены провайдера, взаимодействие с локальными предпочтениями, окно вступления в силу, зависимости подписантов и ответственный за аварийный переход или откат. Имена резолверов и коммерческие данные парка можно защитить. Границы глобального вывода должны быть открыты.

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

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

Источники