Кратко

  • RFC 2065 прикреплял проверяемое свидетельство к ресурсным записям DNS: резолвер мог оценить подписанные данные, не признавая каждый сервер на пути доставки доверенным центром безопасности.
  • Обычный сервер мог хранить и возвращать KEY, SIG и NXT, но автоматическая выдача подписей, обработка CNAME и делегирования, а также семантика AD и CD требовали дополнительных возможностей.
  • Механизм защищал происхождение и целостность публичных данных, но не тайну запроса, не разные права спрашивающих и не подлинность узла, найденного после разрешения имени.

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

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

Три службы вместо одной ауры безопасности

RFC 2065 разделял распространение открытых ключей, подтверждение происхождения и целостности данных и необязательную аутентификацию транзакции или запроса. Успешный обмен DNS не подтверждал автоматически все три свойства.

Ресурсная запись KEY связывала открытый ключ с DNS-именем. Резолверу по-прежнему требовался хотя бы один начальный ключ, полученный через надёжную настройку. От этой опоры он мог проверять подписанные ключи безопасных зон. Доверие не исчезло: стали видны его исходная точка и проверяемый путь.

Запись SIG была главным свидетельством для RRset. Она указывала охваченный тип, подписанта, алгоритм, исходный TTL, начало и окончание действия, а также саму подпись. Корректный SIG поддерживал ограниченное утверждение: конкретный набор записей происходит от удостоверенного ключа и не изменён в заданном временном окне. Соседние данные в том же пакете от этого не становились удостоверенными.

NXT решал другую задачу — доказывал отсутствие имени либо типа у существующего имени. Позднейшие поколения DNSSEC изменили механизм, но граница уже была ясна в 1997 году: для положительных данных и удостоверенного отсутствия нужны разные свидетельства. Молчание не является подписанным отрицанием.

Необязательная подпись транзакции охватывала ещё одну поверхность. RFC предупреждал: SIG, удостоверяющий обмен, не удостоверяет ресурсные записи лишь потому, что они пересылались в сообщении. Доказательство отправителя сообщения не заменяет подпись зоны под содержимым.

Обычный сервер оставался полезным перевозчиком

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

Цена проявлялась при получении. Сервер с поддержкой защиты мог автоматически приложить нужные подписи. Неосведомлённый сервер иногда возвращал только явно запрошенный тип, и резолверу приходилось отдельно получать все SIG данного имени и выбирать те, которые покрывали нужный RRset. Дополнительные обмены обеспечивали миграцию, не приписывая старой программе ложных полномочий.

Совместимость не была универсально прозрачной. CNAME назывался исключением: прежнее поведение сервера могло сначала пройти по псевдониму и не вернуть защитные записи исходного имени. RFC различал минимальное и полное соответствие сервера. Минимальное включало хранение, получение и зонную передачу KEY, SIG и NXT. Полное добавляло корректное построение ответов, автоматическое вложение подписей, обработку псевдонимов и точек делегирования, а также биты AD и CD.

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

У кэша и подписи были разные часы

TTL в DNS-кэше уменьшается, но изменение подписанного значения разрушает подпись. RFC 2065 сохранял в SIG исходный TTL и отдельно указывал начало и окончание действия подписи. Резолвер мог сократить рабочий TTL, но не увеличить его выше подписанного исходного. Истёкшая подпись не становилась доказательством только потому, что запись ещё находилась в кэше.

Часы резолвера поэтому оказались частью зависимости. Если перевести их назад, старая подпись может снова показаться действительной. Подписант управляет ключом и сроком; авторитетные и кэширующие серверы — доступностью и доставкой; резолвер — опорами доверия, временем и политикой приёма. Один удачный ответ не превращает эти обязанности в общий зелёный индикатор.

Публичная подлинность имела намеренную границу

Документ необычно прямо называл свои нецели. DNS-данные считались публичными, а ответы — одинаковыми для всех спрашивающих. RFC 2065 не добавлял список контроля доступа и не распределял права между клиентами. Запросы и ответы также не скрывались; для конфиденциальности требовался отдельный канал, например разрабатывавшаяся тогда архитектура IPsec.

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

Первая спецификация, а не окончательный DNSSEC

RFC 2065 имел статус Proposed Standard, что не свидетельствует о повсеместном внедрении. IETF Datatracker хранит редакции черновика с 1994 по 1996 год и публикацию января 1997-го, но не устанавливает число операторов, применивших схему. В марте 1999 года его заменил RFC 2535, прямо объяснивший, что новая версия учитывает ранний опыт реализаций и пожелания потенциальных пользователей. В 2005 году это поколение сменили RFC 4033, 4034 и 4035.

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

Через позднейшую концепцию Lu Heng о минимальной первоначальной спецификации RFC 2065 можно прочитать как попытку сосредоточить общий минимум в объектах, проверяемых локально, и разрешить неравномерное внедрение по краям. Это редакционная интерпретация, а не свидетельство исторического замысла Eastlake и Kaufman. Её практический смысл в другом: общий слой способен точно определить действительную подпись, не разрешая каждому перевозчику решать, во что обязаны верить все остальные.

Источники