Кратко

  • В revision 00 клиент может передать в EDNS(0) до восьми SigTag для известных ему подписанных ladders; совпадение разрешает condensed signature.
  • 32-октетный идентификатор не доказывает наличие данных в кэше, правильного подписанта, успешную проверку или конечный результат DNSSEC.
  • Полный fallback, signer-scoped cache, раздельные receipts и политика приватности являются условиями эксплуатации, а не дополнительными удобствами.

Состояние переехало с линии в резолвер

Полная ML-DSA-MTL signature состоит из condensed Merkle path и signed ladder с базовой подписью ML-DSA. Одна ladder может покрывать несколько RRset. Это уменьшает среднюю вычислительную нагрузку, но базовый draft прямо говорит: полный ответ не помещается в DNS over UDP.

SigTag — результат SHAKE128(SIGNED_LADDER, 256) над полной сериализацией ladder. Если клиент объявил подходящее значение и сервер всё ещё хранит объект, он может вернуть MTL-Type 0x02. При отсутствии совпадения или самой ladder сервер обязан отправить full signature.

Пропущенные байты остаются частью доказательства. Резолвер должен достать нужную ladder, проверить её подпись соответствующим DNSKEY, связать Merkle path с RRset и завершить обычную DNSSEC validation. Совпадение tag определяет упаковку ответа, но не присваивает статус secure.

Правильный hash без authority context недостаточен

Базовый draft предупреждает: другой подписант может использовать тот же SID. Поэтому кэшированная ladder связывается с именем signer. SID или SigTag не являются глобальным именем authority; иначе точные bytes могут быть применены к чужому контексту.

Утверждение клиента также может устареть между query и response. Запись вытесняется, key rollover меняет контекст, сервер теряет собственную копию. Condensed path на линии образует третье состояние. Одна метрика cache hit скрыла бы эти переходы.

Пустая SigTag option сообщает только поддержку. Пустой echo позволяет серверу дедуплицировать ladder внутри одного ответа, поместив full signature в первый RRSIG. Это не receipt проверки, а данные response option клиент должен игнорировать.

Возможность вернуть full signature определяет устойчивость

При невалидном ответе клиент может повторить запрос с пустой option, убрать SigTag и ожидать full signatures либо выбрать другой DNS server. Draft приводит mismatch и missing payload как примеры.

Без этих ветвей устаревший cache превращает оптимизацию в отказ разрешения. TCP способен избежать части truncation, но не доказывает validation или использование ответа приложением. Размер, транспорт, retry, upstream, DNSSEC result и service outcome должны храниться отдельно.

Идентификатор экономии раскрывает историю

Непустой SigTag говорит authoritative server, какую ladder клиент видел раньше. Revision 00 отмечает риск вывода о прошлых запросах и tracking, если authority выдаёт уникальные ladders. Всегда пустая option сохраняет дедупликацию внутри response; очистка при смене адреса или интерфейса сокращает время связи.

Это компромиссы, не гарантии. Решение о раскрытии принимает оператор, несущий последствия. Протокол не даёт authority общего права профилировать клиентов и не позволяет поставщику скрыть выбор в непрозрачном default.

Опубликованный draft ещё не является работающей нормой

Revision 00 датирован 28 сентября 2026 года; EDNS code и MTL-Type остаются TBD. LDNS, NSD и Unbound перечислены как тестовые реализации, но сведения предоставлены участниками, не проверены и не означают одобрение IETF.

IANA-номер задаёт общее значение. Наличие кода показывает попытку реализации. Только версии, воспроизводимые traces, rollover tests, validation receipts и распределение ошибок дают операционное доказательство.

Источники