Кратко

  • draft-kaizer-dnsop-ml-dsa-mtl-dnssec-02 заменяет множество полных ML-DSA-подписей одной подписанной Merkle-лестницей и отдельными путями включения для RRset.
  • Криптографически правильный ответ не доказывает, что authoritative signers сохранили историю node set для обновления, передачи зоны, failover и восстановления.

Редакция 02 опубликована 28 сентября 2026 года. Она изменила intended status на Standards Track и предложила реестр IANA для MTL Types. Это по-прежнему индивидуальный Internet-Draft, а не документ, принятый DNSOP, не консенсус IETF и не RFC. Номер алгоритма остаётся TBD. Упомянутые тестовые реализации LDNS, NSD, Unbound и библиотека C показывают наличие эксперимента; сам текст предупреждает, что сведения не проверены и не означают одобрения IETF.

Мотивация измерима. ML-DSA стандартизован NIST как постквантовый алгоритм цифровой подписи, но полная подпись велика для DNSSEC. Если повторять её для каждого RRset, растут зона, кэш и сетевой ответ. Merkle Tree Ladders позволяют сообщениям разделить дорогую подпись.

DNSKEY несёт открытый ключ ML-DSA. Для каждого сообщения подписант выбирает randomizer, вычисляет leaf hash и назначает последовательный индекс, начиная с нуля. Листья входят в развивающийся node set с 32-октетным SID. Rungs аутентифицируют накопленные листья, а ML-DSA подписывает flags, SID, число и данные ступеней.

Полный RRSIG содержит также индекс, randomizer, sibling hashes и подписанную лестницу. Резолвер проверяет подпись лестницы, заново вычисляет лист из RRset и проходит authentication path до совместимой ступени. Затем остаётся обычная проверка DNSSEC. Одна полная подпись действительно способна покрывать много RRset.

Но общее доказательство опирается на порядок. SID задаёт серию, индекс — позицию, randomizer — значение листа, а набор ступеней меняется по мере добавления сообщений. Для старого сообщения может потребоваться новый путь относительно текущей лестницы. Экономия переносит значение в историю состояния.

Документ запрещает повторно использовать один SID для разных MTL instantiations и прямо приводит KSK и ZSK как пример отдельных node sets. Значит, резервной копии private key недостаточно. Необходимо сохранить связь роли с SID, следующий индекс и принятую generation лестницы.

Представим кластер из primary signer, standby и отдельного disaster-recovery узла. Резерв запускается со snapshot, сделанного на один batch раньше. Ключ и данные зоны корректны, но он может повторить индекс, поднять старую лестницу или начать новую серию. Каждый вариант требует правил и наблюдаемого перехода. Редакция 02 их не задаёт.

Граница описана честно. Draft занимается code points, DNSKEY/RRSIG и криптографическими операциями. Zone signing, composition, updates, transfer, обработка name server, resolver и cache оставлены будущим версиям или документам. Это не означает невозможность восстановления; это означает отсутствие общего operational contract.

Batch signing связывает состояние со временем. Чем больше сообщений добавлено до новой подписи лестницы, тем ниже средняя нагрузка ML-DSA и HSM. Но свежее изменение ждёт закрытия batch. Размер вправе выбирать оператор, однако сервису нужны максимальная задержка, правило promotion и защита от расхождения поколений.

Для online signing draft допускает новый node set на каждый динамический ответ. Такой подход сокращает общую историю, но может ограничить amortization одним запросом. Поддержка функции сама по себе ничего не говорит о CPU, HSM, latency или recovery.

Revision 01 убрала EDNS(0)-опцию начальной версии и оставила для каждого RRset только full MTL-Type response. Revision 02 утверждает, что такой ответ всегда превышает возможности DNS over UDP. Ожидается больше TCP; клиентам, не желающим проходить truncation и повтор, рекомендуется сразу использовать TCP.

TCP доставляет байты, но не синхронизирует подписантов. Успешный поток не доказывает одинаковую ladder generation на authoritative nodes. Merkle proof не доказывает поддержку алгоритма. Подпись лестницы не заменяет цепочку DS/DNSKEY до trust anchor. Валидный DNSSEC-ответ не доказывает результат приложения.

Ранее опубликованный материал о SigTag отвечает на другой вопрос: какую лестницу клиент считает закэшированной, когда сервер выбирает condensed response, что раскрывает этот сигнал и как происходит fallback. Здесь граница находится раньше — в создании, сохранении, переносе и восстановлении самой истории подписанта.

Принцип running-code primacy требует точности. Репозитории — свидетельство эксперимента, а не эксплуатации. Standards Track intention и запрошенный code point — направление, а не обязанность. Об adoption можно говорить после независимых испытаний update, transfer, KSK/ZSK separation, rollback, failover и TCP capacity.

Для каждой лестницы нужен receipt: роль ключа, SID, диапазон индексов, rungs, SOA serial, signer identity, версия, время и predecessor. Приёмочный тест должен специально восстановить отставший snapshot и показать, что система либо продолжает принятую серию, либо явно переходит на новую. Валидность вчерашнего ответа не заменяет этот тест.

Источники