Кратко

  • RFC 3655 заменил широкую отметку серверной политики более узким сигналом: соответствующие RRset ответа прошли аутентификацию по обновлённым правилам.
  • AD — сообщение резолвера о состоянии данных, а не подпись DNS-пакета и не доказательство надёжности резолвера, сетевого пути или выбранной пользователем модели доверия.

Анализ

Обычная сцена: приложение запрашивает имя через локальный stub resolver. Тот пересылает запрос рекурсивному резолверу, который может пройти цепочку ключей, получить подписи и использовать кэш. В ответе один бит заголовка способен сообщить приложению, что было сделано выше по цепочке. Вопрос не в количестве битов, а в том, кто вправе сделать такое заявление и какие доказательства оно обобщает.

RFC 2535 придавал биту Authenticated Data (AD) широкое значение: сервер сообщал, что данные в секциях Answer и Authority аутентифицированы согласно его политике. В ноябре 2003 года RFC 3655 объяснил, почему на практике такой сигнал мало полезен. Соответствующий требованиям сервер и так не должен возвращать данные, нарушающие его политику безопасности. Поэтому AD в основном характеризовал общую позицию сервера, а не позволял приложению понять статус конкретного ответа.

Пересмотр уточнил эту передачу. Рекурсивный сервер не должен устанавливать AD, если соответствующие RRset в Answer и Authority не отвечают условиям аутентификации. Бит следует установить, когда записи ответа — и относящиеся к нему записи, обосновывающие отрицательный ответ, — аутентифицированы. Это не означает, что каждый DNS-пакет теперь подписан. DNSSEC аутентифицирует наборы ресурсных записей, а AD кратко передаёт локальную оценку резолвера для этого ответа.

Поэтому DO, CD и AD нельзя смешивать. DO запрашивает включение DNSSEC-записей; RFC 3655 требовал, чтобы такие записи были запрошены и соответствующие SIG-записи вернулись, прежде чем устанавливать AD. CD отключает проверку для данного запроса, но не стирает AD автоматически: сервер мог отметить данные, уже прошедшие криптографическую проверку либо соответствующие локальной политике. Биты описывают разные этапы: запрос доказательств, управление проверками и передачу результата.

Так RFC 3655 сделал рекурсивный резолвер посредником доверия. Каждому приложению не требовалось встраивать полноценный валидатор, а проверку можно было повторно использовать из кэша. Но stub не мог считать AD самоподтверждающимся доказательством. Требовалось явно доверять резолверу и защищать связь — безопасным каналом или аутентификацией сообщений вроде TSIG либо SIG(0). Иначе AD, добавленный ответчиком на сетевом пути, оставался заявлением о проверке, а не защищённо доставленным свидетельством.

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

Нулевой AD тоже легко истолковать неверно. RFC 3655 запрещал AD для небезопасного ответа, но сброшенный бит сам по себе не сообщал, были ли данные небезопасными, не проверил ли их резолвер, отсутствовали ли запрошенные DNSSEC-записи или сервер предпочёл не заявлять статус. AD=1 имеет смысл внутри отношений доверия; AD=0 не является полным диагнозом.

В 2005 году RFC 4033, RFC 4034 и RFC 4035 пересмотрели DNSSEC и заменили RFC 3655. Передача статуса через AD сохранилась, но оказалась в более полном описании валидаторов, stub-резолверов, авторитетных серверов и путей аутентификации. Историческая роль RFC 3655 — исправление узкого интерфейса: передать оценку рекурсивного резолвера, не выдавая бит заголовка за криптографическое доказательство.

Цепочку доказательств нужно рассматривать послойно. RRSIG может поддерживать аутентификацию RRset через цепочку ключей и якорь доверия. Валидирующий резолвер принимает локальное решение о статусе. AD способен сообщить это решение. Защищённый канал с доверенным резолвером связывает ответ с выбранным потребителем сервисом. Ни один из этих фактов сам по себе не доказывает добросовестность владельца имени, актуальность сведений для приложения или безопасность действий приложения.

Источники