Кратко

  • Редакция 01 dry-run DNSSEC предлагает переходное состояние: поддерживающий резолвер проверяет подписанную зону и сообщает об ошибках, но при результате bogus возвращает обычному клиенту небезопасный ответ, который существовал бы без пробного DS.
  • Предложенный отчёт NOERROR доказывает присутствие одного успешно проверившего участника. Он не даёт числа молчащих резолверов и их клиентов; кроме того, отчётность RFC 9567 подавляется кэшем и не удостоверяет отправителя.
  • Прежде чем родитель заменит пробный DS настоящим, квитанция перехода должна связать наблюдаемую группу, клиентские проверки, состояние родителя, пределы транспорта, реестр IANA и остаточные неизвестные. Это рекомендация Daniel Kade, а не требование IETF.

Самая жёсткая граница внедрения DNSSEC находится не только в подписанной дочерней зоне. Пока родитель не опубликовал DS, подписи можно проверять, не создавая публичной цепочки доверия. После настоящего DS та же ошибка способна превратиться в SERVFAIL у независимых валидаторов и дойти до пользователей через чужие кэши.

Активный проект рабочей группы DNSOP dry-run DNSSEC пытается вставить наблюдаемую ступень между подготовкой и принуждением. Редакция 01 опубликована 21 июня 2026 года и указывает Standards Track как предполагаемый путь. Но это пока Internet-Draft, не RFC, не утверждённый стандарт и не свидетельство внедрения каким-либо названным оператором. Предлагаемые коды EDE и EDNS остаются TBD.

Механизм использует правило RFC 6840 для неизвестного алгоритма дайджеста DS. Валидатор не учитывает аутентифицированный DS, если не умеет применять его алгоритм. Когда поддерживаемого пути аутентификации не остаётся, дочерняя зона считается неподписанной. Проект образует пробные значения старшим битом и требует, чтобы весь DS RRset родителя состоял из пробных типов. Смесь с обычными DS заставит поддерживающий резолвер игнорировать пробную часть и продолжить обычную проверку.

Одна делегация создаёт две группы наблюдателей. Резолвер без поддержки отбрасывает незнакомый дайджест, разрешает имя как небезопасное и не посылает пробного отчёта. Поддерживающий распознаёт сигнал, проверяет зону и может сообщить результат. При успехе он способен отметить данные как аутентичные. При bogus он сохраняет диагноз, но скрывает стандартный отказ DNSSEC от обычного клиента и выдаёт небезопасный ответ, доступный без пробного DS.

Такой fail-open — не частичная защита DNSSEC. Проект говорит, что пробную делегацию ещё нельзя считать подписанной. Раздел безопасности предупреждает: небезопасный возврат отключает гарантию целостности и может позволить поддельному ответу повлиять на зону. Наблюдаемость реального пути покупается периодом без принуждения, поэтому пробный режим не должен становиться постоянным.

Увидеть ошибку — не значит навязать её клиенту

Extended DNS Errors из RFC 8914 описывают причину сбоя. RFC 9567 определяет DNS Error Reporting: резолвер составляет запрос к домену агента мониторинга, объявленному авторитативным сервером. В имени отчёта кодируются ошибочный QNAME, QTYPE и код EDE.

Такой сигнал ценнее лабораторной проверки. Он приходит с реально развёрнутого валидатора, через его кэш и рабочий поток запросов. Однако достоверный вывод узок: некоторый путь отчётности в некоторый момент увидел конкретную ошибку.

RFC 9567 не удостоверяет личность резолвера перед агентом. TCP и DNS Cookies усложняют подмену адреса, но не превращают источник в подтверждённую организацию. UDP-отчёт и его кажущийся отправитель могут быть ложными. Отчётность также раскрывает внутренние дефекты, например устаревшие якоря доверия, поэтому минимизация имени запроса важна для приватности.

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

NOERROR подтверждает присутствие, но не представительность

Пустой график ошибок может означать правильную подпись. Возможны и другие причины: ни один поддерживающий резолвер не пришёл, не получил запроса, уже подавил отчёт, не достиг агента или вовсе не реализовал функцию.

Редакция 01 предлагает NOERROR, чтобы закрыть часть неопределённости. После успешной пробной валидации резолвер посылает положительный сигнал, построенный на вершине зоны; кэш ограничивает частоту. Оператор узнаёт, что хотя бы один участник присутствовал и успешно проверил данные.

Но внешний знаменатель не появляется. Неподдерживающие резолверы молчат по конструкции, считая дочернюю зону неподписанной. Поддерживающие без трафика тоже невидимы. Один NOERROR не перечисляет всех клиентов за резолвером, их будущие маршруты и иные состояния кэша. Соотношение успехов и ошибок описывает видимую группу, а не долю готового интернета.

Проект приводит в пример отчётность DMARC, индикатор корневого якоря из RFC 8509 и сигналы знания якорей из RFC 8145. Небольшая, свежая и удачно расположенная группа наблюдателей способна дать сильные эксплуатационные сведения. Это не делает её автоматической статистической моделью всей сети.

Wet-Run указывает, кто согласился получить отказ

Из-за небезопасного возврата обычный клиент не испытывает настоящую ошибку DNSSEC. Значит, отчёт резолвера не показывает, как приложение поведёт себя после принудительной проверки. Предложенная опция EDNS Wet-Run позволяет клиенту явно запросить реальную пробную ошибку. Поддерживающий резолвер хранит рядом с обычным кэшированным статусом пробный и возвращает опцию вместе с отказом. Неподдерживающий игнорирует её.

Проверяется конкретная связка приложения, сети и резолвера. Клиенты без opt-in не охвачены. Резолверный NOERROR не заменяет эту сквозную проверку. Свести оба результата к отметке «пройдено» — значит потерять и маршрут, и согласие испытать отказ.

Отрицательные ответы требуют ещё одного теста. RFC 8198 разрешает синтезировать их из проверенных NSEC или NSEC3, сохранённых в кэше. Такая оптимизация может скрыть сломанное отрицательное доказательство на авторитативном сервере. Проект предписывает временно прекратить синтез, сделать явный запрос, сравнить ответы и сообщить расхождение предлагаемым EDE.

Переключатель перехода находится у родителя

Одной подписи дочерней зоны недостаточно. Родитель должен принять и опубликовать особый DS. Если интерфейс принимает готовые DS, ребёнок передаёт пробное значение. Если родитель строит DS из DNSKEY, ему нужен признак режима либо логика, читающая сопровождающий CDS. CDNSKEY сам по себе различие не несёт; проект советует публиковать CDS и CDNSKEY вместе.

Переход тоже является действием родителя: пробный набор целиком заменяется реальным. Подача заявки, принятие, наблюдаемая публикация и истечение старого кэша — разные факты и времена. Одна отметка «переключено» не подтверждает всю цепочку.

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

Предложенному сигналу ещё не выделено пространство

Редакция 01 предлагает задействовать старший бит алгоритма дайджеста DS и просит IANA обозначить 128–255 как Dry-run DNSSEC. В действующем реестре такого назначения нет. На 13 января 2026 года значения 128–252 помечены Reserved, 253–254 — Private Use, 255 — Unassigned со ссылкой на RFC 9904.

Если спецификация продвинется, эти состояния понадобится явно согласовать. Нынешняя таблица не доказывает отказ IANA: запрошенное в Internet-Draft действие становится назначением лишь после должной процедуры. До этого эксперимент не вправе представлять весь диапазон как уже выделенный публично.

RFC 9904 также разделяет рекомендации по использованию и реализации. Наличие функции в коде и её эксплуатационное применение — разные факты. Поддержка пробного режима, наблюдение конкретной зоны и обслуживание важных клиентских путей тоже требуют отдельных доказательств.

Проверяемая квитанция перехода

Сначала квитанция фиксирует точные артефакты: отпечаток подписанной зоны, набор DNSKEY, предлагаемый пробный DS, заявку родителю, принятие и увиденную извне публикацию. Отдельно называются окно наблюдения, авторитативные точки и горизонт кэша.

Затем описывается группа без притворного переписывания населения. Какие резолверы различимы по независимым данным? Какие представлены лишь адресом, доверие к которому слегка усилили TCP или Cookie? Сколько NOERROR и ошибок осталось после подавления, какие имена, типы и коды затронуты, чем закрыто каждое исправление? Агрегация защищает приватность, но не должна стирать структуру доказательства.

Клиентские проверки идут отдельно: Wet-Run по сети, резолверу и классу приложений; сравнение с обычным возвратом; положительные и отрицательные ответы; явные запросы NSEC/NSEC3; сроки кэша; недоступные группы. Прикладывается актуальный снимок реестра IANA, а экспериментальные коды отмечаются как неназначенные.

Наконец, указывается, кто вправе санкционировать настоящий DS, какой минимум сведений и какие неизвестные он принимает, кто отвечает за откат и как тот проверен. Заявка, принятие, наблюдаемая публикация и последующая валидация получают разные отметки времени.

Квитанция не сертифицирует каждый резолвер. Она не даёт выбранной выборке незаметно переименоваться в «интернет» внутри протокола решения. Ограниченных данных может хватить для действия, если отвечающие за последствия видят и принимают их границу.

Источники

  1. dry-run DNSSEC — редакция 01
  2. Карточка dry-run DNSSEC в Datatracker
  3. История документа
  4. Активные документы DNSOP
  5. Устав DNSOP
  6. RFC 9567 — DNS Error Reporting
  7. RFC 8914 — Extended DNS Errors
  8. RFC 6840 — замечания по реализации DNSSEC
  9. RFC 8198 — активное применение проверенного кэша
  10. RFC 8509 — индикатор корневого якоря доверия
  11. RFC 8145 — сигнал знания якоря доверия
  12. RFC 9904 — обновление рекомендаций алгоритмов DNSSEC
  13. Реестр IANA алгоритмов дайджеста DS