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, Страница 9 из 14

7. Оконечные преобразователи

Хотя протокол не требует этого жестко, большинство запросов DNS приходит от оконечных преобразователей. Такие преобразователи по определению являются минимальными преобразователями DNS, которые используют режим рекурсивных запросов для передачи большей части работы по преобразованию имен DNS рекурсивным серверам имен. Исходя из такого повсеместного использования оконечных преобразователей, архитектура DNSSEC принимает такие преобразователи во внимание, но средства защиты, требуемые от оконечного преобразователя, отличаются в некоторых аспектах от требований к защищенным итеративным преобразователям.

Хотя обычные (security-oblivious) оконечные преобразователи могут получить некоторые преимущества DNSSEC, если используемые ими рекурсивные серверы имен являются защищенными, для реального доверия к службам DNSSEC оконечный преобразователь должен доверять как используемым серверам имен, так и коммуникационных каналам, связывающим его с этими серверами. Первый вопрос определяется локальной политикой — обычный преобразователь, по сути, не имеет выбора кроме как положиться на используемый рекурсивный сервер, поскольку преобразователь не может выполнять операций DNSSEC по проверке корректности. Второй вопрос требует того или иного механизма защиты канала — надлежащего использования механизмов аутентификации транзакций DNS (таких, как SIG(0) ([RFC2931]) или TSIG ([RFC2845]) будет вполне достаточно, подойдет и использование IPsec. Конкретные реализации могут выбирать и другие доступные варианты (например, поддерживаемые операционной системой механизмы обмена данными между процессами). Конфиденциальность для канала не требуется, но нужна аутентификация и обеспечение целостности данных.

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

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

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

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