Кратко

  • RFC 9904 — документ IETF, относящийся к треку стандартов и опубликованный в ноябре 2025 года. Он формально заменяет RFC 8624 и обновляет RFC 9157.
  • Требования к реализации и рекомендации по использованию DNSSEC переносятся в реестры IANA DNS Security Algorithm Numbers и DS Digest Algorithms.
  • Четыре ячейки не сводятся к одной отметке: требования к валидатору и подписанту различаются, как различаются рекомендации по проверке и по созданию подписей.
  • RFC 9904 сама не меняет ни один статус MUST, MAY, RECOMMENDED или другой унаследованный статус. Последующее изменение рекомендации требует Standards Action и должно описывать последствия перехода и интероперабельности.

Речь идёт о новом способе публикации и изменения рекомендаций, а не о новой оценке конкретного алгоритма. RFC 8624 объединяла требования к реализации и рекомендации по применению в статической таблице. RFC 9904 помещает эту информацию в два реестра IANA. В будущем отдельная RFC сможет обновить нужные столбцы посредством целевого действия в рамках процесса стандартизации, не заменяя каждый раз полную таблицу в новом общем документе.

Для одного номера алгоритма нужно задать четыре разных вопроса: должен ли валидатор реализовывать этот алгоритм; должен ли его реализовывать подписант; рекомендуется ли он для проверки входящих подписей; рекомендуется ли он для создания подписей. Обозначение «поддерживается» не отвечает на все четыре вопроса. После RFC 9904 реестры IANA являются справочной поверхностью для рекомендаций, а текст RFC остаётся источником правил, по которым эти столбцы могут изменяться.

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

Анализ Theo March: при подготовке решения может быть полезно сохранить копию обоих соответствующих реестров, время наблюдения, источник и четыре рассмотренные ячейки. Если условия развертывания это позволяют, анализ также может предусматривать проверку перекрытия старого и нового алгоритмов, раздельную проверку валидаторов и подписантов, поэтапное изменение и материалы для возврата. Это предложения из анализа Theo March по управлению изменениями, а не обязательные операции, предписанные RFC 9904.

RFC 9904 содержит конкретное предупреждение: слишком ранний вывод алгоритма может привести к тому, что зона, подписанная только этим алгоритмом, будет выглядеть для валидаторов фактически неподписанной. Поэтому вывод из эксплуатации должен быть обдуманным и, по возможности, постепенным. Анализ Theo March переводит это предупреждение в рабочие вопросы: какая ячейка меняется, какие роли затронуты, где описан переход и какие последствия для интероперабельности нужно проверить? Источники не позволяют утверждать, что такой сценарий является текущим, частым, быстрым или дорогостоящим.

Порядок рассмотрения по анализу Theo March

  1. Зафиксировать: записать версию и время обращения к реестрам IANA.
  2. Разделить: определить, относится ли решение к реализации валидатора, реализации подписанта, проверке или подписанию.
  3. Проверить: изучить соответствующую Standards Action и описание последствий перехода и интероперабельности.
  4. Сопоставить: при необходимости сравнить пути подписания и проверки и рассмотреть результаты тестов перекрытия.
  5. Документировать: согласно анализу Theo March, сохранить материалы, объясняющие решение и позволяющие оценить возврат.

Это аналитическое предложение Theo March по управлению жизненным циклом; оно не добавляет требований к RFC 9904.

Источники