Кратко

  • RFC 5155 позволяет не включать подходящие неподписанные делегирования в цепочку NSEC3, если покрывающая интервал запись имеет флаг Opt-Out.
  • Такая запись не утверждает ни существование, ни отсутствие покрытых незащищённых делегирований; она удостоверяет более узкое отрицательное утверждение.
  • Для защищённого делегирования нужны подписанный RRset DS и проверенная цепочка доверия, а не только действительная подпись NSEC3 рядом с запрошенным хешем.
  • Операционный журнал должен различать защищённый, незащищённый, bogus и неопределённый результаты, а не сводить их к отметке «DNSSEC пройден».

Представим трассировку резолвера: все RRSIG успешно проверены, интервалы NSEC3 согласованы, результат показан зелёным. Позднее экспорт аудита превращает эту строку в вывод «дочернее делегирование защищено». Но запрошенное имя попадает в интервал Opt-Out. Доказательство подлинное, а вывод шире его фактического содержания.

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

Что меняет Opt-Out

RFC 5155 определяет NSEC3 как хешированный способ аутентифицированного доказательства отсутствия. Вместо открытого списка имён владельцев в каноническом порядке зона подписывает записи, образующие цепочку в порядке хешей.

В зоне с большим количеством делегирований поддерживать запись NSEC3 и подпись для каждого неподписанного дочернего домена может быть дорого. Opt-Out позволяет исключать имена подходящих незащищённых делегирований. Запись с этим флагом может охватывать от нуля до нескольких таких делегирований, поэтому их можно добавлять или удалять без перестройки соответствующей части цепочки.

Эта операционная экономия меняет значение доказательства. RFC 5155 прямо говорит: запись NSEC3 Opt-Out не утверждает существование или отсутствие незащищённых делегирований, которые она может покрывать. Она по-прежнему удостоверяет утверждения о других авторитетных данных в интервале, но неподписанная дочерняя зона намеренно исключена из полного криптографического реестра.

Корректное доказательство может дать результат «незащищённо»

В точке делегирования решающее значение имеют данные родительской зоны. RFC 5155 различает защищённое делегирование — RRset NS вместе с подписанным RRset DS — и незащищённое делегирование, где NS есть, а DS отсутствует. Именно DS связывает аутентифицированные данные родителя с DNSKEY дочерней зоны.

Проверка RRSIG записи NSEC3 доказывает, что родитель подписал именно это утверждение NSEC3. Она не создаёт DS для покрытого дочернего домена. Флаг Opt-Out сам по себе также не доказывает существование конкретного делегирования. RFC 7129 формулирует следствие однозначно: записи Opt-Out не могут доказать или опровергнуть существование покрытых незащищённых делегирований, и те не получают криптографической защиты DNSSEC.

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

Сохранять область действия вместе с результатом

Доказательство должно указывать запрос, код ответа, зону и точку делегирования. Для NSEC3 следует сохранить алгоритм хеширования, число итераций, соль, хеш владельца, следующий хеш владельца, bitmap типов и флаг Opt-Out. Если в отрицательном доказательстве участвует closest provable encloser, нужны и его элементы, а также результаты проверки DNSKEY и RRSIG и использованный якорь доверия.

Кеш и время тоже ограничивают вывод. TTL, начало и окончание действия подписей, публикация в родительской зоне и возраст кеша резолвера задают окно наблюдения. Более позднее добавление или удаление DS может изменить состояние делегирования, хотя прежнее доказательство останется в архиве аудита.