Кратко

  • RFC 3090 заменила состояния для отдельных алгоритмов и класс «экспериментально безопасная» тремя атрибутами: глобально безопасная, локально безопасная и небезопасная зона.
  • Резолвер всё равно получал двоичный итог из собственной конфигурации: якорей, алгоритмов, свидетельств делегирования и выбранного пути проверки.

Подпись зоны не меняла знания всех наблюдателей

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

RFC 3090 разделила четыре роли. Администратор определял состояние зоны. Сервер динамических обновлений должен был сохранять его после изменений. Родитель выражал переход к дочерней зоне. Резолвер решал, позволяют ли доступные материалы подтвердить ответ. Подпись дочерней зоны, заявление родителя и локальное доверие находились под разным управлением.

Документ отказался от отдельного состояния зоны для каждого алгоритма. Исчезла и категория «экспериментально безопасная». Для резолверов с ключом эксперимента зона была локальным безопасным островом; для остальных — небезопасной. Эксперимент задавал круг наблюдателей, а не новый вид безопасности.

Остров существовал только для знавших правильный берег

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

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

При нескольких якорях требовался правильный выбор. Ближайшим корнем безопасности RFC 3090 называла настроенный корень с самым длинным упорядоченным совпадением правых меток имени. Начав от более далёкого корня, программа могла встретить NULL-ключ и заключить, что потомок небезопасен, хотя ближе был настроен другой остров. Пересечение островов превращало выбор старта в часть доказательства.

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

Родитель мог сообщить о безопасности отсутствием записи

У поколения RFC 2535 на границе делегирования действовало непривычное правило. У безопасного родителя отсутствие KEY дочерней зоны могло означать безопасного ребёнка, тогда как подписанный NULL-ключ отмечал небезопасного. Положительное утверждение выглядело как молчание, отрицательное оставляло подписанный объект.

RFC 3090 назвала это неинтуитивным и неудобным для эксплуатации. Она прояснила чтение, но не заменила механизм. Значит, простое отсутствие записи не было универсальным доказательством. Сначала следовало установить безопасность родителя, аутентифицированный контекст отсутствия и применимость исторических правил.

Позже RFC 3658 ввела DS, а RFC 4033, 4034 и 4035 построили современную схему DNSKEY, RRSIG, NSEC и DS вместо KEY, SIG и NXT. Эти документы показывают развитие, но не дают права задним числом переименовывать факты 2001 года.

Глобальный класс не был гарантией неуязвимости

Глобально безопасной зоне требовались обязательные алгоритмы, цепочка родительских подписей внутри дерева, подходящие ключи подписания в вершине, покрытие NXT и подписи нужных RRset. Локально безопасная зона могла применять другие алгоритмы или заранее заданный путь вне дерева, сохраняя свойства подписанной зоны. Остальное относилось к небезопасному классу.

Слова «глобальная» и «локальная» описывали атрибуты, а не удостоверяли соответствие реализации. Строгий резолвер мог принимать лишь первый класс. Более способный или специально настроенный — часть второго. Во время запроса оба всё равно выдавали безопасный либо небезопасный результат.

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

Источники

  1. https://www.rfc-editor.org/info/rfc3090
  2. https://www.rfc-editor.org/rfc/rfc3090.html
  3. https://www.rfc-editor.org/rfc/rfc3090.txt
  4. https://datatracker.ietf.org/doc/rfc3090/
  5. https://www.rfc-editor.org/errata/rfc3090
  6. https://www.rfc-editor.org/rfc/rfc2535.html
  7. https://www.rfc-editor.org/rfc/rfc3007.html
  8. https://www.rfc-editor.org/rfc/rfc3008.html
  9. https://www.rfc-editor.org/rfc/rfc3658.html
  10. https://www.rfc-editor.org/rfc/rfc4033.html
  11. https://www.rfc-editor.org/rfc/rfc4034.html
  12. https://www.rfc-editor.org/rfc/rfc4035.html
  13. https://www.rfc-editor.org/rfc/rfc5011.html