Кратко

  • RFC 9083 определяет delegationSigned как true, когда в родительской зоне присутствуют записи DS. zoneSigned, данные DS и данные ключей остаются отдельными частями объекта RDAP secureDNS.
  • Это поле служит регистрационным свидетельством, а не живым результатом проверки. Обоснованный вывод о DNSSEC требует также текущего DS родителя, DNSKEY и RRSIG дочерней зоны, доступности авторитетных серверов, проверки времени и результата конкретного валидатора.

Точное значение с узкими границами

Исследованный ответ LACNIC для 84.7.200.in-addr.arpa ясно показывает своё содержимое. Это объект класса domain. Он перечисляет три сервера имён, а в объекте secureDNS значения zoneSigned и delegationSigned равны false; массив dsData пуст.

Ответ является полезным свидетельством о записи, которую LACNIC вернул в момент наблюдения. Он не описывает все обратные зоны региона и не показывает текущее рабочее состояние перечисленных серверов. В нём нет трассы резолвера и DNS-пакетов, позволяющих воспроизвести проверку.

DS родителя — лишь одно звено

RFC 9083 намеренно разделяет значения полей. zoneSigned сообщает, подписана ли зона. delegationSigned сообщает, присутствуют ли записи DS у родителя. dsData может содержать тег ключа, алгоритм, дайджест и его тип, а keyData — материал DNSKEY.

Эти поля описывают регистрационные данные. Валидация DNSSEC выполняется над цепочкой живых ответов DNS в определённый момент. Валидатор получает DS родителя, DNSKEY и подписанные записи дочерней зоны, сопоставляет дайджесты и алгоритмы, проверяет подписи и интервалы времени, обрабатывает недоступность и ошибки ответов. Логическое поле RDAP не выполняет эти действия незаметно.

И true, и false требуют осторожной формулировки

Если delegationSigned равно true, подтверждённый вывод таков: представление RDAP сообщает о DS у родителя. Оно не доказывает публикацию соответствующего DNSKEY дочерней зоной, действительность подписей, достижение якоря доверия или успех проверки определённым резолвером.

Если значение равно false, RDAP сообщает об отсутствии DS у родителя согласно определению поля. Это не объясняет причину отсутствия, не исключает незавершённое изменение и не гарантирует совпадение с более поздним наблюдением. Следует сохранять точный URL, байты ответа и время получения.

Сохраняйте две поверхности доказательств

Регистрационная поверхность должна включать URL объекта RDAP, ldhName, список серверов, значения secureDNS, массивы DS или ключей, хеш ответа и время. Операционная поверхность отдельно хранит запросы к родителю и дочерней зоне, адреса серверов, коды ответа, флаги авторитетности, DNSKEY, DS, RRSIG, вывод валидатора и временной контекст.

Только сравнив обе поверхности, можно описывать текущую валидацию. Даже тогда результат относится к указанным точке и времени наблюдения. Успех криптографической цепочки не устанавливает право собственности, договорные полномочия или контроль над хостами.

Источники