Смена algorithm DNSSEC требует отдельного плана перехода
Увеличить схему
Фотография конкретного исполнения не приложена.
Обычная замена ключа и переход на другой signing algorithm имеют разные условия. Если считать их одинаковой операцией, можно опубликовать наборы, которые не соответствуют ожидаемому переходному состоянию. Особенно важны сочетания новых DNSKEY и старых подписей в кэшах.
RFC 6781 выделяет algorithm rollover как специальный класс. Публикация ключей, signatures и parent DS должна быть согласована с правилами подписания и проверки. Поздние clarifications также требуют различать обязанности signer и поведение validator, а не переносить одно правило на другой слой.
Статья не выбирает актуальный algorithm allowlist: это отдельное требование действующего профиля. Наличие старого алгоритма в историческом RFC не является рекомендацией его использовать. Для процедуры нужен конкретный исходный и целевой набор реализаций.
В приёмке проверяют промежуточные combinations и cache lifetimes выбранного плана. Сохраняют применимый профиль и результаты validator. Отчёт должен объяснять дополнительную зависимость смены algorithm. Один успешно проверенный новый RRset не подтверждает безопасное завершение всего перехода и готовность удалить прежние ключи и signatures.
Основание — Numbered DNSSEC chain, denial, key lifecycle and zone-integrity references with selected explicit updates, разделы RFC6781 4.1.4 Algorithm Rollovers; RFC6840 DNSSEC algorithm validation clarifications. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — указанные номерные RFC DNSSEC и целостности DNS-зон. Это разбор механизмов, а не полный актуальный профиль algorithms. Реальные signer, resolver, trust anchors, parent policy и ключи не проверялись; DNS-запросы, публикация zones и изменения делегации не выполнялись.
Запросы отправляются на наш e-mail из вашей почтовой программы.
