RFC: 4033
Оригинал: DNS Security Introduction and Requirements
Предыдущие версии: RFC 2065, RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , ,
Перевод: Николай Малых

RFC 4033, Страница 7 из 14

5. Сфера действия набора документов DNSSEC и проблема последнего интервала

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

Проверяющий преобразователь может определять 4 перечисленных ниже состояния:

  • Secure — защищенное
  • Проверяющий преобразователь имеет доверенную привязку (trust anchor) или цепочку доверия или способен проверить все подписи в отклике.
  • Insecure — незащищенное
  • Проверяющий преобразователь имеет доверенную привязку (trust anchor) или цепочку доверия и (в некой точке деленирования) подписанное подтверждение отсутствия записи DS. Это показывает, что последующие ветви дерева могут оказаться незащищенными. Проверяющий преобразователь может иметь локальное правило для маркировки части доменного пространства, как незащищенной.
  • Bogus — подделка
  • Проверяющий преобразователь имеет доверенную привязку (trust anchor) и защищенное делегирование, показывающие, что дополнительные данные подписаны, но проверка отклика по той или иной причине дала отрицательный результат (отсутствие подписи, просроченная подпись, отсутствие данных, которые должны присутствовать в соответствующей NSEC RR и т.п.).
  • Indeterminate — неопределенное
  • Нет доверенной привязки, которая показывает, что определенная часть дерева защищена. Это состояние принимается по умолчанию.

Эта спецификация определяет лишь, как защищенные серверы имен могут сигнализировать не проверяющим корректность оконечным преобразователям, что данные были квалифицированы как подставные (с помощью RCODE=2, "Server Failure"; см. [RFC4035]).

Существует механизм, с помощью которого защищенный сервер имен может сообщить защищенному оконечному преобразователю о том, что данные были сочтены защищенными (с помощью бита AD; см. [RFC4035]).

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

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

Страница 7 из 14

2007 - 2022 © Русские переводы RFC, IETF, ISOC.