Summary

  • Начальная версия проекта DNSOP предлагает: если среди DS или якорей доверия есть хотя бы один алгоритм UNIVERSAL и нет FORMERLY-UNIVERSAL, достаточно подписи хотя бы одним UNIVERSAL; остальные становятся необязательными.
  • Первыми UNIVERSAL названы алгоритмы 8 и 13. В действующем реестре IANA реализация обоих для проверки уже обязательна, но новой графы статуса пока нет.
  • Резолвер, локально отключивший объявленный UNIVERSAL, считал бы зону неподписанной, даже если поддерживает другой объявленный алгоритм. Его собственная политика изменила бы результат проверки.

Подписывающая сторона платит за все алгоритмы, проверяющей достаточно одного правильного пути. Так распределяют работу RFC 4035 и RFC 6840. Зона готовит полный набор подписей на случай неизвестного резолвера. Резолвер выбирает валидную цепочку и забывает об остальных. Новый проект рабочей группы DNSOP собирается сократить обязательный набор, если один алгоритм должен поддерживаться практически везде.

При обслуживании зоны несколькими DNS-провайдерами это не просто экономия вычислений. RFC 8901 описывает модель с независимыми ключами у каждого поставщика. Если алгоритмы различаются, старое правило заставляет компании согласовывать полный набор подписей, хотя независимость была одной из причин использовать обеих. При переносе зоны к новому провайдеру возникает та же пауза. Предварительное распространение якоря доверия тоже сложно отделить от немедленного двойного подписывания всей зоны.

Реестр становится частью договора

Проект предлагает IANA добавить поле Validation support status со значениями UNIVERSAL, FORMERLY-UNIVERSAL либо пустым значением. Алгоритмы 8, RSA/SHA-256, и 13, ECDSA P-256/SHA-256, вначале получили бы UNIVERSAL. Действующий реестр требует их реализации для проверки. Класс бывших универсальных на старте пуст. Новая отметка превратила бы ожидание поддержки в условие, при котором подписывающая сторона вправе опустить часть подписей.

Проверяется состав DS у родительской зоны или набора якорей. Если в нем есть UNIVERSAL и нет FORMERLY-UNIVERSAL, зона обязана подписать хотя бы одним универсальным алгоритмом, а остальные подписи может не делать. DNSKEY можно ограничить алгоритмами, которыми зона действительно пользуется. Если UNIVERSAL нет или присутствует любой бывший универсальный, подписи всех алгоритмов остаются обязательными. Экономить по настроению оператора текст не разрешает.

Два провайдера, один с номером 8, другой с номером 13, смогли бы отдавать разные правильные пути. Новый якорь доверия можно было бы опубликовать до появления соответствующих DNSKEY и RRSIG. Один поставщик получил бы возможность попробовать постквантовый алгоритм без одновременного переоснащения всех партнеров. Завершение перехода на алгоритм без статуса UNIVERSAL всё еще может потребовать периода двойного подписывания.

Выключатель у резолвера меняет безопасность зоны

Пусть зона объявляет 8 и 13. Один провайдер отвечает правильной подписью алгоритма 8. Администратор резолвера локально отключил 8, хотя 13 поддерживается. Проект предписывает считать зону неподписанной. Нельзя обвинить поставщика в bogus и вернуть SERVFAIL только потому, что сам резолвер отключил алгоритм, обязательный для реализации. Схожий принцип касается алгоритма, который прежде был UNIVERSAL, а теперь местная политика его отвергает.

Ответ DNS может прийти пользователю, но аутентификация в этом резолвере отсутствует. Если панель показывает только успешность запросов, она прячет ключевое решение. Нужно раздельно считать secure, insecure и bogus и хранить изменение настройки с именем ответственного. Возможность программы проверять подпись и решение администратора воспользоваться ею — разные факты.

Старое правило всех подписей защищало от понятного нападения. Злоумышленник не должен удалить все подписи, которые резолвер понимает, оставить непонятные и незаметно превратить защищенный ответ в незащищенный. Авторы проекта утверждают, что категории UNIVERSAL и FORMERLY-UNIVERSAL сохраняют сопротивление такому понижению. Резолвер обязан помнить алгоритмы, когда-либо признанные универсальными, даже после локального отключения. Забытая история ведет к неверному результату.

Версия 00 датирована 31 октября 2026 года и остается ранним документом рабочей группы. В нем нет статистики затронутых резолверов и подтвержденных сбоев. Для реального внедрения нужен тест своей сети: как каждый резолвер классифицирует частичные наборы подписей разных провайдеров и что меняется при намеренном отключении 8 или 13? Надпись «DNSSEC поддерживается» не заменяет эту матрицу.

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

Проект IETF · RFC 4035 · RFC 6840 · RFC 8901 · Реестр IANA