Кратко

  • RFC 9905 — документ IETF Standards Track от ноября 2025 года, обновляющий RFC 4034 и RFC 5155.
  • RSASHA1 и RSASHA1-NSEC3-SHA1 MUST NOT применяться для создания новых записей DS, DNSKEY или RRSIG.
  • Реализации валидаторов MUST по-прежнему поддерживать проверку с помощью этих алгоритмов. Это обязанность совместимости, а не разрешение продолжать выпуск SHA-1-подписей.

Главный эффект RFC 9905 — не универсальное немедленное удаление SHA-1 из всех систем. Он разводит роли. Авторитетная система подписи прекращает создание DNSKEY и RRSIG с RSASHA1 и RSASHA1-NSEC3-SHA1. Для DS действует отдельный такой же запрет: эти алгоритмы нельзя использовать при создании DS. Если в делегации остаётся только DS такого типа, валидатор должен трактовать её как insecure, а не как bogus или ошибку проверки. Если другого DS с допустимым алгоритмом нет, данные ниже точки делегации рассматриваются как незащищённые.

Другая сторона перехода — реализация проверки. Она должна сохраняться, поскольку на момент публикации RFC некоторые домены всё ещё использовали эти алгоритмы. Поэтому нельзя утверждать, что все операторы валидаторов уже могут удалить поддержку SHA-1. Программное обеспечение, из которого проверка SHA-1 была удалена, может потребовать ручной сборки, чтобы выполнить оставшееся требование к уровню реализации проверки.

Операционная последовательность

  1. Авторитетная подпись: составьте инвентаризацию DNSKEY, RRSIG и алгоритмов подписи. Подготовьте переход на более сильный алгоритм, рекомендованный реестрами IANA. Новые DS, DNSKEY и RRSIG с RSASHA1 или RSASHA1-NSEC3-SHA1 не создавайте.
  2. Публикация DS: до публикации у родительской зоны независимо проверьте DNSKEY и RRSIG более сильного пути. Зафиксируйте старые и новые значения, TTL, время распространения и ответы нескольких резолверов. Старый SHA-1 DS нельзя создавать заново.
  3. Рекурсивная проверка: проверьте более сильный путь и отдельно подтвердите, что резолвер всё ещё способен валидировать оставшиеся старые данные с SHA-1. Делегация, где есть только старый DS, должна пройти проверку как insecure, а не как bogus.

Перекрытие здесь означает, что более сильный путь уже опубликован и проверен, пока старые данные ещё существуют в установленной базе и кэшах. Оно не означает продолжение выпуска SHA-1-материалов. Доказательства отката должны включать последнюю исправную конфигурацию более сильной подписи и DS, окна TTL, результаты независимых проверок и безопасный путь восстановления. Откат не должен требовать повторного создания запрещённых SHA-1-записей.

Практические проверки

  • Блокирует ли конвейер подписи создание DS, DNSKEY и RRSIG с обоими алгоритмами SHA-1?
  • Есть ли более сильный алгоритм, рекомендованный реестрами IANA, и подтверждает ли его независимый рекурсивный резолвер?
  • Разделены ли документально запрет на подпись и обязанность продолжать проверку?
  • Отмечается ли делегация с единственным SHA-1 DS как insecure, а не как bogus или failed?
  • Видно ли, удаляла ли конкретная сборка поддержку проверки SHA-1 и нужен ли поэтому ручной build?

Путь решения оператора прост. Если зона всё ещё выпускает SHA-1, остановите этот поток и перейдите на более сильный алгоритм. Если опубликован только старый DS, исправьте состояние делегации и согласуйте допустимый DS. Если валидатор не имеет нужной реализации, восстановите её или соберите программное обеспечение вручную до объявления миграции завершённой. Нельзя дополнять эту картину данными о распространённости, поведении производителей, инцидентах, производительности или будущих изменениях реестров: таких фактов в замороженном наборе нет.

Источники