Кратко

  • С 10 сентября 2026 года резолвер Cloudflare 1.1.1.1 мог проверять подписи ML-DSA-44 для тестовых зон. На RIPE 93 Joe Abley представил DNSSEC-эксперимент с измерениями в браузере.
  • У резолверов, проверяющих подписи, двойная подпись по сравнению с классическим контролем дала +1 мс в медиане и +1 405 мс на p99. На слайдах совокупный результат обозначен как net breakage 6,0%; ранний шумный тест не установил долю сбоев для всей пользовательской аудитории.

Медиана успокаивает, длинный хвост будит дежурного

Дополнительная миллисекунда в медиане — цифра, которую объявление об обновлении напечатает крупным шрифтом. На RIPE 93 Joe Abley показал строку менее удобную для рекламного слайда: на p99 путь с двойной подписью занял на 1 405 миллисекунд больше, чем классический контроль. Это медленный край распределения: часть людей ждёт, пока большинство быстрых ответов делает среднее аккуратным.

График в оригинальных слайдах RIPE 93 сравнивает время двойной подписи минус контроль с алгоритмом 13 у проверяющих резолверов. Разница составила +1 мс в медиане, +147 мс на p90, +618 мс на p95 и +1 405 мс на p99. Это время браузерного испытания целиком, а не отдельный замер криптографической проверки. В качестве базового сравнения без валидации Abley также показал намеренно сломанную классическую подпись 13 против контроля: 0, +73, +215 и +1 132 мс на тех же перцентилях.

Эксперимент собрал около 140 тысяч точек данных: браузерное задание показывали одному пользователю из тысячи. Каждое задание запускало четыре параллельных HTTPS-запроса к DNS-именам, обслуживаемым Cloudflare: контроль алгоритма 13, намеренно сломанную подпись 13, путь ML-DSA-44 с алгоритмом 18 и имя с обеими подписями. Слайд 19 обозначил совокупный результат валидирующих резолверов как net breakage 6,0%. По словам Abley, примерно в 20 автономных системах сбои заметно участились; в большинстве наблюдавшихся AS различий не было. Доклад не установил причину каждого сбоя.

Новая подпись может закрыть старый запасной выход

Тест стал возможен потому, что с 10 сентября 1.1.1.1 проверял ML-DSA-44 для всех клиентов, но на тестовых зонах. Это поддержка валидации, а не запуск постквантовой подписи для заказчиков. В реестре IANA алгоритм 18 указан как ML-DSA-44, а для подписи и проверки стоит MAY. Для алгоритма 13 — ECDSA P-256 с SHA-256 — стоит RECOMMENDED.

В обычном DNSSEC резолвер может принять набор записей, если действительна любая покрывающая его RRSIG. RFC 6840 говорит, что резолвер должен принимать любую действительную подпись и помечать набор как bogus, только когда не проходят все подписи. RFC 4035 оставляет обработку конфликтов локальной политике безопасности. Более строгая постквантовая политика Cloudflare закрывает запасной выход: если присутствует подпись алгоритма 18, она должна пройти проверку. Действительная подпись 13 не спасает сломанную ML-DSA-44. Так компания хочет не дать превратить переход к постквантовой защите в незаметный откат к классической подписи.

У такой защиты есть цена для доступности. Если новая подпись испорчена, резолвер может отвергнуть ответ, который классическая подпись сама по себе подтвердила бы. Это решение локальной политики резолвера, а не изменение базового протокола DNSSEC.

Браузер — не стерильная лаборатория

Abley назвал результаты очень ранними и зашумлёнными. Имена DNS повторно использовались, поэтому на сравнение мог влиять кэш; тест не обходил его. HTTPS-перенаправления добавляли время. Пользователи, быстро завершившие задание, могли уйти до конца замера, а двухсекундный таймаут обрезал медленные запросы. Свою погрешность добавляли домашняя сеть и браузер. Слайды дают повод проверить сигнал, но не объясняют причину каждого сбоя.

Решение о внедрении ещё не было принято. Cloudflare продолжала экспериментировать с онлайн-подписью ML-DSA-44 и не назначила дату её доступности клиентам. Требования комплаенса могли создать спрос на добровольное подключение; двойная подпись по умолчанию требовала высокой уверенности, что сервис не сломается. В индивидуальном черновике Joe Abley предложена метка Extended DNS Error, чтобы клиент видел применение строгой локальной политики, а не получал необъяснённый отрицательный ответ.

Повторный тест со случайным порядком, обходом кэша и трассами на резолвере изменил бы решение о внедрении: он отделил бы ошибки DNS-проверки от перенаправлений, выхода из браузера и таймаутов. Пока ясна форма результата: середина почти ровная, хвост крутой, а политика требует считать постквантовую подпись обязательной.

Источники