up next index search
   UP: 4.4.12 DNS (структура, обработка запросов, ресурсные записи)
    Next: 4.4.12.2 Протокол динамического конфигурирования ЭВМ DHCP (и NAT/PAT)

4.4.12.1 Безопасность DNS (DNSSEC)

Семенов Ю.А. (ИТЭФ-МФТИ)
Yu. Semenov (ITEP-MIPT)

Определения терминов DNSSEC
Ресурсная запись DNSKEY
Формат представления RRSIG RR
Ресурсная запись NSEC
Формат представления NSEC RR
Ресурсная запись DS
Каноническая форма и порядок ресурсных записей
Модификации протокола для обеспечения безопасности DNS
Подписывание зон
Обслуживание
Рекурсивные серверы имен
Распознавание
Кэширование откликов
Синтезированные CNAME
Аутентификация DNS-откликов
Аутентификация ссылок
Аутентифицирующий RRset с RRSIG RR
Аутентифицированный отказ существования
Поведение распознавателя, когда подписи некорректны
Безопасность DNS (DNSSEC). Хэшированное аутентифицированное отрицание существования
Ресурсные записи NSEC3
Формат презентации
Ресурсная запись NSEC3PARAM
Вычисление хэша
Opt-Out
Авторизованный сервер
Зона обслуживания
Вторичные серверы
Динамическое обновление
Соображения относительно валидаторов
Валидация откликов на ошибку имени
Соображения по распознавателю
Ограничения на длину имени домена
Соображения IANA
Соображения безопасности
Ссылки
Приложения (Типы алгоритмов DNSSEC и типы дайджестов)

1. Введение

Проблема безопасности серверов DNS становилась все актуальнее. В период с 2005 по 2008 гг было разработано несколько документов, которые призваны решить проблему безопасности DNS (RFC-4033, -4034, -4035, -5155). Эти документы не являются исчерпывающими, к этому перечню следует добавить [RFC2536], [RFC2671], [RFC2672], [RFC2929], [RFC2931], [RFC3110], [RFC3225], [RFC3226] и [RFC3597]. Основная угроза DNS исходит от возможности фальсифицировать серверы DNS или хотя бы их отклики. Проблема усложняется тем, что процедура преобразования имени в IP-адрес часто носит итеративный характер и в процесс оказываются вовлечены многие DNS-серверы. Для решения проблемы выявлений безопасных DNS-серверов и их аутентификации используются ресурсные записи и различные методы сертификации записей.

Расширения протокола DNS для обеспечения безопасности обеспечивают аутентификацию и целостность DNS-данных, а также средства рассылки общедоступных крипто ключей. Эти расширения не обеспечивают конфиденциальности.

2. Определения терминов DNSSEC (RFC-4033)

Цепочка аутентификации: Чередующаяся последовательность DNS общедоступных ключей (DNSKEY) RRsets и подписантов делегирования (DS) RRsets образуют цепочку подписанных данных, каждый узел цепочки подтверждает корректность предыдущего. Ресурсная запись DNSKEY используется для верификации подписи, покрывающей DS RR, и позволяет DS RR быть аутентифицированной. DS RR содержит хэш другой записи DNSKEY и эта новая запись DNSKEY RR аутентифицируется за счет соответствия хэша в DS RR. Эта новая DNSKEY RR в свою очередь аутентифицирует другой набор DNSKEY RRset и, в свою очередь, некоторая DNSKEY RR в этом наборе может использоваться для аутентификации другой DS RR, и так далее, до завершения цепочки с DNSKEY RR, чей соответствующий секретный ключ подписывает нужные DNS-данные. Например, корневой DNSKEY RRset может использоваться для аутентификации DS RRset "example." DS RRset содержит хэш, который соответствует некоторому "example." DNSKEY и этот соответствующий DNSKEY секретный ключ подписывает "example." DNSKEY RRset. Секретный ключ соответствует "example". DNSKEY RRset подписывает записи данных, такие как "www.example." и DS RRs для делегирований типа "subzone.example."

Ключ аутентификации: Общедоступный ключ, который должен верифицировать безопасный распознаватель и который, следовательно, может использоваться для аутентификации данных. Безопасный распознаватель может получить ключи аутентификации тремя способами. В первом распознаватель, сконфигурированный стандартным образом, знает о, по крайней мере, одном общедоступном ключе; эта сконфигурированная информация представляет собой либо сам общедоступный ключ, либо хэш общедоступного ключа. Во втором, распознаватель может использовать аутентифицированный общедоступный ключ для верификации DS RR и DNSKEY RR, к которому относится DS RR. В третьем - распознаватель может определить, что новый общедоступный ключ был подписан секретным ключом, соответствующим другому общедоступному ключу, который распознаватель верифицировал. Заметим, что распознаватель должен всегда следовать локальной политике, когда принимает решение аутентифицировать новый общедоступный ключ, даже если местная политика заключается в аутентификации любого общедоступного ключа, для которого распознаватель может верифицировать подпись.

Авторизованный RRset: В контексте конкретной зоны, RRset является "авторизованным", если и только если имя владельца RRset находится в пределах субнабора пространства имен, в области или ниже вершины зоны и в области или выше границы, которая отделяет зону от дочерних зон, если такие имеются. Все RRsets в вершине зоны являются авторизованными, за исключением некоторых RRsets для этого доменного имени, которое, если присутствует, относится к родительской зоне. Эти RRset могут включать в себя DS RRset, NSEC RRset, ссылающиеся на этот DS RRset ("родительский NSEC"), и RRSIG RR, ассоциированные с этими RRsets и авторизованные в рамках родительской зоны. Аналогично, если эта зона содержит какие-либо точки делегирования, только родительский NSEC RRset, DS RRsets и любые RRSIG RR, ассоциированные с этими RRsets, являются авторизованными для этой зоны.

Точка делегирования: термин используется для описания имени на родительской стороне границы зоны. Т.е., точкой делегирования для "foo.example" будет узел foo.example в зоне "example" (в отличие от вершины зоны "foo.example").

Остров безопасности: термин используется для описания подписанной, делегированной зоны, которая не имеет цепочки аутентификации от делегирующей родительской зоны. Т.е., не существует DS RR, содержащей хэш DNSKEY RR для острова в его делегирующей родительской зоне (см. [RFC4034]). Остров безопасности обслуживается безопасными серверами имен и может порождать цепочки аутентификации до любых делегированных дочерних зон. Отклики от островов безопасности или его дочерних зон могут быть аутентифицированы, если его ключи аутентификации могут быть аутентифицированы, какими-то доверительными средствами за пределами DNS-протокола.

Key Signing Key (KSK - ключ подписывающего ключа): Аутентификационный ключ, который соответствует секретному ключу, использованному, для подписания одного или более других аутентификационных ключей для заданной зоны. Обычно, секретный ключ, соответствующий ключу подписывающего ключа, подписывает ключ подписи зоны, который в свою очередь имеет соответствующий секретный ключ, для подписания данных зоны. Локальная политика может требовать, чтобы ключ подписания зоны менялся достаточно часто, в то время как ключ подписания ключа может иметь длительный период пригодности, чтобы обеспечить более стабильную точку безопасного входа в зону. Назначение аутентификационного ключа в качестве ключа подписания ключа является чисто операционным моментом: валидация DNSSEC не делает различия между ключами подписания ключа и другими DNSSEC ключами, и имеется возможность использования одного ключа, как для подписи ключа, так и зоны.

Невалидирующий безопасный Stub Resolver: stub resolver - это распознаватель, который полагается на использование DNS-сервера, выполняющего для него рекурсивные запросы. Безопасный stub resolver, который выполняет доверительную проверку одного или более безопасных рекурсивных серверов имен. В частности, невалидирующий безопасный stub resolver является объектом, который посылает DNS-запросы, получает DNS-отклики, и способен формировать безопасный канал до безопасного рекурсивного сервера имен, который будет осуществлять сервисы для безопасного stub resolver.

Невалидирующий Stub Resolver: Упрощенное название невалидирующего безопасного stub resolver.

Безопасный сервер имен: объект, выполняющий роль сервера имен, который распознает безопасные расширения DNS, определенные в данном наборе документов. В частности, безопасный сервер имен является объектом, который воспринимает DNS-запросы, посылает DNS-отклики, поддерживает EDNS0 ([RFC2671]) расширение размера сообщений и DO-бит ([RFC3225]).

Безопасный рекурсивный сервер имен: объект, который выполняет роли безопасного сервера имен и безопасного распознавателя (resolver). Более сложное, но эквивалентное определение - "безопасный сервер имен, который может предоставить рекурсивные услуги".

Безопасный распознаватель: объект, который исполняет роль распознавателя, адаптированный к требованиям расширения безопасности DNS. В частности, безопасный распознаватель является объектом, который посылает DNS-запросы, получает DNS-отклики, поддерживает EDNS0 ([RFC2671]) расширение размера сообщений и DO-бит ([RFC3225]), и способный использовать типы RR и биты заголовков, определенные в рассматриваемых документах и обеспечивающих DNSSEC-сервисы.

Безопасный Stub Resolver: объект, который выполняет роль stub resolver, который обеспечивает DNS-безопасность. Безопасный stub resolvers может либо "валидировать" или "не валидировать", в зависимости от того, пытается ли он верифицировать подписи DNSSEC сам или поручает эту работу доверительному безопасному серверу имен.

Security-Oblivious <anything>: <что-то> небезопасное.

Подписанная зона: зона, чей RRsets подписан и содержит правильно сформированный DNSKEY, подпись ресурсной записи (RRSIG), NSEC (Next Secure) и (опционно) DS-запись.

Доверительная ссылка (Trust Anchor): Сконфигурированная DNSKEY RR или DS RR хэш DNSKEY RR. Валидирующий безопасный распознаватель использует общедоступный ключ или хэш в качестве отправной точки построения аутентификационной цепочки для подписанного DNS-отклика. Вообще, валидирующий распознаватель будет должен получить начальные значения доверительных ссылок через посредство каких-то безопасных методов, лежащих за пределами DNS-протокола. Присутствие доверительной ссылки предполагает, что распознаватель может рассчитывать, что эта ссылка указывает на подписанную зону.

Валидирующий безопасный Stub Resolver: безопасный распознаватель, который посылает запросы в рекурсивном режиме, но который осуществляет валидацию подписи самостоятельно, а не слепо доверяет результатам вышестоящего безопасного рекурсивного сервера имен.

Вершина зоны (Zone Apex): термин, используемый для описания имени на дочерней стороне границы зоны.

Ключ подписания зоны (ZSK - Zone Signing Key): аутентифицирующий ключ, который соответствует секретному ключу, использованному для подписания зоны. Обычно, ключ подписания зоны будет частью того же DNSKEY RRset, что и ключ подписания ключа, чей секретный ключ подписывает данный DNSKEY RRset, но ключ подписания зоны используется слегка для другой цели, и может отличаться некоторыми свойствами от ключа подписания ключа, например, временем жизни. Предназначение аутентификационного ключа в качестве ключа подписания зоны имеет чисто операционный смысл; валидация DNSSEC не делает различия между ключами подписания зоны и другими аутентификационными ключами DNSSEC, имеется возможность использования одного ключа для обеих задач.

Нумерация зоны: практика выявления полного содержимого зоны через посредство последовательных запросов. Нумерация зоны была нетривиальной до введения DNSSEC.

Имя исходного владельца зоны: имя владельца, соответствующее хэшированному имени владельца.

Хэшированное имя владельца: имя владельца, сформированное с применением хэш-функции для имени владельца.

Порядок хэшей: порядок, в котором хэшированные имена владельца расставлены согласно их номерам, полученным из левого (старшего) октета. Заметим, что этот порядок совпадает с каноническим порядком DNS-имен, специфицированным в [RFC4034], Хэшированные имена владельцев записываются в кодировке base32, с применением расширенного Hex-алфавита [RFC4648].

Пустое нетерминальное (Empty non-terminal): имя домена, которое не имеет своих ресурсных записей, но имеет один или более субдоменов, которые такие записи имеют.

Делегирование: набор NS RRSet с именем отличным от вершины текущей зоны (non-zone-apex), означает делегирование дочерней зоне.

Безопасное делегирование: имя, содержащее делегирование (NS RRSet) и подписанный набор DS RRSet, означающие делегирование дочерней подписанной зоне.

Небезопасное делегирование: имя содержит делегирование (NS RRSet), но отсутствует DS RRSet, что означает делегирование к неподписанной дочерней зоне.

Ресурсная запись Opt-Out NSEC: ресурсная запись NSEC3, которая имеет флаг Opt-Out=1.

Зона Opt-Out: зона с, по крайней мере, одной записью Opt-Out NSEC3 RR.

Ближайший завершитель (Closest encloser): самый длинный существующий прародитель имени.

Ближайший проверяемый завершитель (Closest provable encloser): самое длинное имя прародителя, существование которого может быть проверено.

Следующее имя завершителя (Next closer name): имя на одну метку длиннее, чем ближайший проверяемый завершитель имени.

Base32: "Кодирование Base 32 с расширенным шестнадцатеричным алфавитом", как это специфицировано в [RFC4648]. Заметим, что завершающие символы-заполнители ("=") в спецификации NSEC3 не используются.

Покрыть: ресурсная запись NSEC3 RR "покрывает" имя, если хэш имени попадает между именем владельца и следующим хэшированным именем владельца NSEC3. Другими словами, если она показывает отсутствие данного имени, либо непосредственно, либо доказывая отсутствие прародителя для данного имени.

Соответствовать: Считается, что NSEC3 RR соответствует имени, если имя владельца NSEC3 RR является тем же, что и хэшированное имя владельца для этого имени.

Расширения безопасности протокола DNS (DNSSEC) представляют собой коллекцию новых ресурсных записей (RR) и модификаций протокола, которые реализуют аутентификацию происхождения данных и целостность информации DNS.

Безопасное расширение система доменных имен (DNS) предоставляет аутентификацию происхождения данных, а также целостность и гарантированность сервисов в отношении DNS-данных, включая механизмы аутентифицированного отрицания существования DNS-данных.

Эти механизмы требуют изменения DNS-протокола. DNSSEC добавляет четыре новых типа ресурсных записей: подпись ресурсной записи RRSIG (Resource Record Signature), DNS общедоступный ключ (DNSKEY), подписант делегирования (DS) и Next Secure (NSEC). Добавлены также два новых бита заголовка сообщения: проверка блокирована CD (Checking Disabled) и аутентифицированные данные (AD). Для того чтобы поддерживать большие DNS-сообщения, что связано с добавлением DNSSEC RRs, DNSSEC требует также поддержки EDNS0 ([RFC2671]). Наконец, DNSSEC требует поддержки бита заголовка DNSSEC OK (DO) EDNS ([RFC3225]) , чтобы безопасный распознаватель мог индицировать в своих запросах потребность получения в отклике DNSSEC RR.

Эти сервисы защищают от большинства угроз, описанных в [RFC3833].

DNSSEC обеспечивает аутентификацию путем ассоциирования с DNS RRsets криптографически формируемой подписи. Эти цифровые подписи записываются в новой ресурсной записи - RRSIG. Обычно, имеется один общедоступный ключ, которым подписываются зонные данные, но допускается и несколько ключей. Например, могут быть ключи для каждого из разных алгоритмов электронной подписи. Если безопасный распознаватель получает общедоступный ключ зоны, он может аутентифицировать подписанные данные зоны. Важной концепцией DNSSEC является то, что ключ, которым подписаны данные зоны, ассоциирован с самой зоной, а не с авторизованным сервером имен зоны. Общедоступные ключи для механизма выполнения аутентификации в DNS могут также проявляться в зоне, как это описано в [RFC2931], но сам DNSSEC сопряжен с объектной безопасностью DNS-данных, а не с безопасным каналом DNS-транзакций. Ключи, ассоциированные с безопасностью транзакций, могут быть записаны в разных типах RR. Смотри [RFC3755].

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

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

Ресурсная запись подписанта делегирования (DS) упрощает некоторые административные задачи делегирования подписания данных при переходе через границы зон ответственности. Набор DS RRset размещается в точке делегирования и индицирует соответствие общедоступного и секретного ключей, использованных в DNSKEY RRset в вершине делегированной дочерней зоны. Администратор дочерней зоны, в свою очередь, использует общедоступный ключ, соответствующий одному или нескольким общедоступным ключам этого DNSKEY RRset, чтобы подписать данные дочерней зоны. Типичная аутентификационная цепочка, следовательно, имеет вид DNSKEY->[DS->DNSKEY]*->RRset, где "*" обозначает нуль или более субцепочек DS->DNSKEY. DNSSEC допускает более сложные аутентификационные цепочки, например, дополнительные уровни подписания DNSKEY RRs, отличные от DNSKEY RRs внутри зоны.

Безопасный распознаватель в норме формирует такую цепочку аутентификации от корневого DNS на основе известного по конфигурации общедоступного ключа. Локальная политика может позволять безопасному распознавателю использовать один или более конфигурационных общедоступных ключей (или хэшей этих ключей), отличных от корневого общедоступного ключа, может не предоставлять корневого общедоступного ключа на уровне конфигурации или может запрещать распознавателю использовать конкретный общедоступный ключ, даже если он надежно подписан. DNSSEC предоставляет механизмы, с помощью которых безопасный распознаватель может определить, является ли подпись RRset's корректной. Окончательный анализ аутентификационных ключей и данных является вопросом местной политики, которая может расширить или переписать расширения протокола, описанные в данном документе.

Аутентифицирующие имя и тип несуществования

Механизм обеспечения безопасности, описанный выше, предоставляет средства подписания существующих в зоне наборов RRsets. Проблема формирования отрицательных откликов с тем же уровнем аутентификации и целостности требует использования нового типа ресурсной записи NSEC. Запись NSEC позволяет безопасному распознавателю аутентифицировать отрицательный отклик для несуществования имени или типа с помощью механизмов, используемых для аутентификации других DNS-откликов. Использование записей NSEC требует канонического представления и упорядочения для доменных имен в зоне. Цепочки записей NSEC в явном виде описывают пустые промежутки, или "empty space", между именами доменов в зоне и список типов RRsets в существующих именах. Каждая запись NSEC является подписанной и аутентифицированной.

Сервисы, которые не предоставляются системой DNS-безопасности

DNS была первоначально создана в предположении, что DNS будет присылать один и тот же отклик вне зависимости от того, откуда пришел запрос, и что все DNS-данные общедоступны. Согласно DNSSEC, система сконструирована не для обеспечения конфиденциальности, списков для управления доступом, или других мер дифференциации запросов.

DNSSEC не предоставляет защиты от DoS-атак. Безопасные распознаватели и безопасные серверы имен уязвимы в отношении новых типов DoS-атак, основанных на криптографических операциях.

Расширения безопасности DNS предоставляют аутентификацию происхождения DNS-данных. Механизмы, описанные выше, не позволяют защитить операции зонного обмена и динамического обновления ([RFC2136], [RFC3007]). Схемы аутентификации сообщений, описанные в [RFC2845] и [RFC2931], адресованы к безопасности подобных операций.

Данная спецификация определяет поведение подписантов зон, безопасных серверов имен и безопасных распознавателей и служит для валидации данных с целью определения их состояния. Безопасный распознаватель может идентифицировать 4 состояния информации:

Безопасная: Валидирующий распознаватель имеет доверительную ссылку, имеет доверительную цепочку, и способен верифицировать все подписи в отклике.

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

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

Промежуточная: Отсутствует доверительная ссылка, которая бы указывала, что определенная часть дерева является безопасной.

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

Безопасный распознаватель должен быть способен выполнять криптографические функции, необходимые для верификации цифровых подписей. Безопасный распознаватель должен также формировать аутентификационную цепочку от новой зоны. Этот процесс может требовать дополнительных запросов в промежуточные DNS-зоны, чтобы получить необходимые записи DNSKEY, DS и RRSIG. Безопасный распознаватель должен быть сконфигурирован с, по крайней мере, одной доверительной ссылкой, являющейся стартовой точкой, от которой он будет пытаться сформировать доверительные цепочки.

Если безопасный распознаватель отделен от соответствующих безопасных серверов имен рекурсивным сервером имен или каким-либо иным промежуточным устройством, которое выполняет функцию прокси для DNS, и если рекурсивный сервер имен или промежуточное устройство не является безопасным, безопасный распознаватель не сможет работать в безопасном режиме. Например, если пакеты безопасного распознавателя маршрутизируются через систему трансляции сетевых адресов (NAT) , которая содержит в себе DNS-прокси, которая не является безопасной, безопасный распознаватель может счесть невозможным получение или валидацию подписанных DNS-данных. Безопасный распознаватель может столкнуться в таком случае с проблемами получения DS RRs, так как DS RRs не следуют обычным DNS-правилам владения RRs на границах зоны. Заметим, что эта проблема не является специфической для NAT: любое программное обеспечения DNS, не ориентированное на безопасность, работающее в области между безопасным распознавателем и авторизованным сервером имен, вызовет конфликт с DNSSEC.

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

Безопасный распознаватель должен принимать во внимание период валидации подписей, когда определяется TTL данных в кэше, чтобы избежать кэширования подписанных данных за пределами пригодности подписи. Однако он должен допускать возможность того, что часы самого безопасного распознавателя идут не точно. Таким образом, безопасный распознаватель, который является частью безопасного рекурсивного сервера имен, должен быть внимателен в отношении установки бита CD DNSSEC ([RFC4034]). Это нужно для того, чтобы избежать блокировки корректных подписей от других безопасных распознавателей, которые являются клиентами этого рекурсивного сервера имен. О работе рекурсивных серверов имен с битом CD смотри [RFC4035].

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

Даже stub resolver, который не заботится о безопасности, может извлечь выгоду из DNSSEC, если рекурсивные серверы имен, которые он использует, являются безопасными, но для stub resolver, чтобы полагаться на сервисы DNSSEC, он должен доверять, как серверам имен, так и каналам коммуникаций между ним и этими серверами имен. Первым в этой ситуации является то, что stub resolver, который не заботится о безопасности, не имеет выбора, кроме как положиться на милость рекурсивных серверов имен, которые он использует, так как он сам не производит валидации DNSSEC. Вторым пунктом является требования к безопасности каналов, корректное использование механизмов DNS аутентификации, таких как SIG(0) ([RFC2931]) или TSIG (Transaction SIGnature [RFC2845]) , пригодна также технология IPsec.

Безопасный stub resolver, который доверяет рекурсивному серверу имен и его коммуникационному каналу может решить анализировать состояние бита AD (Authenticated Data) в заголовке сообщений-откликов, которые он получает. Stub resolver может использовать этот флаг, как подсказку, чтобы выяснить, может ли рекурсивный сервер имен валидировать подписи для данных в секциях ответа и авторизации отклика.

Существует еще один шаг, который безопасный stub resolver может предпринять, если он по какой-либо причине не может установить нужное доверительное взаимодействие с безопасными серверами имен: он может выполнить самостоятельно валидацию подписи путем установки бита CD (Checking Disabled) в своих сообщениях-запросах. Валидирующий stub resolver, таким образом, может рассматривать DNSSEC подписи, в качестве доверительных средств взаимодействия между администратором зоны и самим stub resolver.

Ресурсные записи для расширений безопасности DNS (RFC-4034)
3. Ресурсная запись DNSKEY

DNSSEC вводит концепцию подписанных зон (signed zones). Подписанная зона имеет записи общедоступного ключа DNS (DNSKEY), сигнатуру ресурсной записи (RRSIG), Next Secure (NSEC), и (опционно) Delegation Signer (подписант делегирования) (DS). Зона, которая не имеет этих рекордов, считается неподписанной зоной. DNSSEC требует изменения определения ресурсной записи CNAME ([RFC1035]).

Для подписания и аутентификации ресурсных записей (RRsets) DNSSEC использует криптографию с общедоступным ключом. Общедоступные ключи записываются в ресурсный рекорд DNSKEY и используются в процессе аутентификации согласно [RFC4035] Зона подписывает свои официальные RRsets с помощью секретного ключа и записывает общедоступный ключ в DNSKEY RR. Распознаватель может далее использовать общедоступный ключ для валидации подписей RRsets в зоне.

Ресурсная запись DNSKEY RR не предназначена для записи произвольных общедоступных ключей и не должна использоваться для записи сертификатов или общедоступных ключей, которые не относятся непосредственно к инфраструктуре DNS.

Значение параметра Type (тип) для ресурсной записи DNSKEY равно 48.

3.1. Формат DNSKEY RDATA

RDATA для ресурсной записи DNSKEY состоит из двухоктетного поля флагов, одного октета поля протокола, одного октета поля алгоритма и поля общедоступного ключа.

Рис. 1. Формат RDATA ресурсной записи DNSKEY

Бит 7 поля флаги является флагом ключа зоны (Zone Key). Если бит 7 равен 1, тогда рекорд DNSKEY содержит ключ зоны DNS, а имя владельца ресурсной записи DNSKEY должно быть именем зоны. Если бит 7 равен 0, тогда запись DNSKEY содержит какой-то другой тип общедоступного ключа DNS и не должен использоваться для верификации RRSIG.

Бит 15 поля флаги является флагом безопасной точки входа (описано в [RFC3757]). Если бит 15 равен 1, тогда рекорд DNSKEY содержит ключ, предназначенный для точки безопасного входа. Этот флаг предназначен для указания на зону подписки или отладки программы, которая предполагает использовать запись DNSKEY; валидаторы не должны изменять свое поведение в процессе проверки подписи. Это также означает, что ресурсная запись DNSKEY с установленным битом SEP требует также установки флага Zone Key (ключ зоны), для того чтобы иметь возможность легально формировать подписи. Запись DNSKEY с установленным флагом SEP и не установленным флагом Zone Key не должен использоваться для верификации RRSIG, которая покрывает RRsets.

Биты 0-6 и 8-14 зарезервированы: эти биты должны быть равны 0 при формировании DNSKEY RR и должны игнорироваться при получении.

Поле протокола должно содержать значение 3, а запись DNSKEY должна восприниматься, как некорректная при валидации подписи, если там обнаружится значение отличное от 3.

Поле алгоритм идентифицирует криптографический алгоритм, значения кодов этого поля можно найти в приложении к RFC-4034 (А.1).

Поле общедоступный ключ содержит материал этого ключа. Формат зависит от алгоритма.

Поле общедоступного ключа должно быть закодировано в Base64 [RFC3548]. Пробелы в тексте Base64 допустимы. Ниже приведен образец поля общедоступного ключа.

example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
                                          Cbl+BBZH4b/0PY1kxkmvHjcZc8no
                                          kfzj31GajIQKY+5CptLr3buXA10h
                                          WqTkF7H6RfoRqXQeogmMHfpftf6z
                                          Mv1LyBUgia7za6ZEzOJBOztyvhjL
                                          742iU/TpPSEDhm2SNKLijfUppn1U
                                          aNvv4w==  )

Первые четыре текстовых поля специфицируют имя владельца, TTL, класс и тип ресурсной записи (DNSKEY). Значение 256 указывает на то, что бит ключа зоны (бит 7) в поле флаги равен 1. Значение 3 является фиксированным кодом протокола. Величина 5 указывает на тип алгоритма общедоступного ключа. В приложении A.1 RFC-4034 коду 5 соответствует алгоритма RSA/SHA1. Формат общедоступного ключа RSA/SHA1 описан в [RFC3110].

DNSSEC использует криптографию с открытым ключом для подписи и аутентификации набора ресурсных записей DNS (RRsets). Цифровые подписи, заносимые в ресурсные записи RRSIG, используются в процессе аутентификации DNSSEC, описанном в [RFC4035]. Валидатор может использовать эти RRSIG RRs для аутетификации RRset зоны. Ресурсные записи RRSIG должны использоваться исключительно для хранения верификационного материала (цифровых подписей), используемого для обеспечения безопасности операций DNS.

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

Так как каждый официальный RRset в зоне должен быть защищен цифровой подписью, должны существовать рекорды RRSIG RRs для имен, содержащих CNAME RR. Это является отличием от спецификации традиционного DNS [RFC1034], которая утверждает, что если для имени имеется CNAME, то для него разрешен лишь один тип.

Значение типа для ресурсной записи RRSIG равно 46.

Рекорд RRSIG должен иметь тот же класс, что и RRset, который он покрывает.

Значение TTL для записи RRSIG должно соответствовать величине TTL набора RRset, который покрывает. Это является исключением по отношению к правилам [RFC2181] для TTL значений индивидуальных записей RR в пределах RRset: индивидуальный набор RRSIG RR с одним и тем же именем владельца будет иметь разные значения TTL, если RRsets, которые они покрывают, имеют разные TTL.

RDATA для записи RRSIG RR состоит из двух октетов поля типа покрытия (Type Covered), октета поля алгоритма, октета поля меток, 4 октетов поля исходного TTL, 4 октетов поля истечения срока действия подписи, 4 октетов поля начала действия подписи (Signature Inception), 2 октетов тэга ключа, поля имени подписанта и поля подписи.

Рис. 2. Формат поля RDATA

Поле Type Covered указывает на тип набора RRset, который покрыт для этого рекорда RRSIG.

Поле кода алгоритма идентифицирует криптографический алгоритм, использованный при формировании подписи. Список DNSSEC типов алгоритмов можно найти в приложении A.1 RFC-4034.

Поле меток специфицирует число меток в исходном рекорде RRSIG имени владельца. Важность этого поля заключается в том, что валидатор использует его для определения того, был ли отклик синтезирован на основе произвольной подстановки (wildcard). Если это так, оно может быть использовано для определения того, какое имя владельца было использовано при формировании подписи.

Чтобы провести валидацию подписи, валидатору нужно оригинальное имя собственника, которое было использовано при формировании подписи. Если оригинальное имя содержит символы подмены (wildcard) типа ("*"), имя владельца может быть развернуто сервером при формировании отклика, когда валидатор будет реконструировать исходное имя владельца, чтобы верифицировать подпись. В [RFC4035] описано, как использовать поле метки для реконструкции исходного имени владельца.

Значение поля меток не должно включать в себя ни нулевую метку (root), которая завершает имя владельца, ни меток символов подмены (wildcard). Значение поля меток должно быть меньше или равно числу меток в имени владельца RRSIG. Например, "www.example.com." имеет значение поля метки 3, а "*.example.com." имеет значение поля меток равное 2. Root (".") имеет значение поля меток равное 0.

Хотя метка подмены (wildcard) не включается в число, записанное в поле метки RRSIG RR, такая метка является частью имени владельца RRset при формировании или валидации подписи.

Поле исходного TTL специфицирует TTL покрытого RRset, когда этот набор оказывается в заданной авторизованной зоне.

Поле исходного значения TTL нужно для того, чтобы кэширующий распознаватель (resolver - клиент сервиса DNS , который запрашивает сервер DNS для разрешения имен в сетях) мог различать значение TTL для кэшированных RRset. Для того чтобы проверять подписи, валидатору нужно исходное TTL. В [RFC4035] описано, как использовать значение поля исходного TTL для реконструкции исходного значения TTL.

Поля завершения пригодности подписи и времени его формирования (Inception) специфицируют время пригодности подписи. Рекорд RRSIG не должен использоваться для аутентификации, до момента создания и по истечении времени пригодности подписи.

Значения поле завершения пригодности подписи и времени его формирования определяют дату и время в виде 32-битового числа без знака секунд, прошедших после 1 января 1970 00:00:00 UTC, игнорируя секунды коррекции (leap seconds), (используется сетевой порядок байт). Максимальный временной интервал, который можно записать в таком формате, равен 136 годам. Рекорд RRSIG может иметь значение поля истечения пригодности, которое численно меньше, чем время создания вблизи точки переполнения, или в случае, когда подпись недействительна.

Поле тэга ключа содержит значение тэга ключа рекорда DNSKEY, который валидирует эту подпись, при сетевом порядке байт. В приложении B (RFC-4034) объясняется способ вычисления значения тэга ключа.

Значение поля имени подписанта определяет имя владельца, рекорда DNSKEY, которое валидатор будет использовать при проверке подписи. Поле имени подписанта должно содержать имя зоны покрытия RRset. Отправитель не должен использовать сжатие имени DNS для поля имени подписанта при пересылке записи RRSIG.

Поле подписи содержит криптографическую подпись, которая покрывает RRSIG RDATA (исключая поле подписи) и RRset, специфицированный именем владельца RRSIG, класс RRSIG и поле RRSIG Type Covered. Формат этого поля зависит от используемого алгоритма.

Подпись покрывает RRSIG RDATA (исключая поле подписи) и данные RRset, специфицированные именем владельца RRSIG, класс RRSIG и поле RRSIG Type Covered. RRset имеет каноническую форму, а набор RR(1),...RR(n) подписываются следующим образом:

signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) где

          "|" означает конкатенацию (слияние);
          RRSIG_RDATA представляет собой связанный формат полей RRSIG RDATA
          с полем имени подписанта в канонической форме, исключая поле подписи;
          RR(i) = owner | type | class | TTL | RDATA length | RDATA

"owner" является полностью определенным именем владельца RRset в канонической форме (для RR с именем владельца в виде произвольной символьной подстановки, подстановка включена в имя владельца);

Каждая запись RR должна иметь то же имя владельца, что и RRSIG RR;

Каждая RR должна иметь тот же класс, что и RRSIG RR;

Каждая RR в RRset должна иметь тип RR, названный в поле RRSIG RR тип поля покрытия;

Каждая RR в RRset должна иметь TTL, представленное в поле исходное TTL RRSIG;

Любые имена DNS в поле RDATA каждого RR должно иметь каноническую форму; и

RRset должен быть отсортирован в каноническом порядке.

3.2. Формат представления RRSIG RR

Формат представления RDATA можно охарактеризовать следующим образом:

Поле Type Covered представляется как RR-тип мнемонического кода. Когда мнемоника не известна, представление типа осуществляется так, как это описано в [RFC3597].

Значение поля алгоритм должно быть представлено либо в виде целого десятичного числа без знака, либо как алгоритмическая мнемоника, специфицированная в приложении A.1 RFC-4034.

Значение поля метки должно иметь вид десятичного целого числа без знака.

Значение поля исходное TTL должно иметь форму целого десятичного числа без знака.

Значения полей Время истечения пригодности и Время формирования подписи должны характеризоваться целым числом секунд, указывающим время после 1 января 1970 00:00:00 UTC, или иметь форму YYYYMMDDHHmmSS в UTC, где:

YYYY год (0001-9999;
MM - номер месяца (01-12);
DD номер дня (01-31);
HH - часы, в 24-часовой нотации (00-23);
mm - минуты (00-59); и
SS - секунды (00-59).

Заметим, что всегда возможно различить эти два формата, так как формат YYYYMMDDHHmmSS будет иметь всегда ровно 14 цифр, в то время как десятичное представление 32-битового целого без знака не может быть длиннее 10 цифр.

Поле тэг ключа должно иметь вид целого десятичного числа без знака.

Значение поля Имя подписанта должно иметь формат имени домена.

Для поля Сигнатура используется кодировка Base64. Внутри этой кодовой последовательности допускаются символы пробела.

3.3. Пример RRSIG RR

Следующее значение RRSIG RR представляет собой подпись для A RRset узла host.example.com:

host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
                                  20030220173103 2642 example.com.
                                  oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
                                  PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
                                  B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
                                  GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

Четыре первых поля специфицируют имя владельца, TTL, Класс и тип RR (RRSIG). "A" указывает на поле Type Covered. Код 5 идентифицирует алгоритм (RSA/SHA1), используемый для формирования подписи. Код 3 является числом меток в исходном имени владельца. Код 86400 в RRSIG RDATA является исходным значением TTL для покрываемого A RRset. 20030322173103 и 20030220173103 равны времени истечения пригодности и временем создания подписи, соответственно. Число 2642 равно тэгу ключа и, наконец, example.com. представляет собой имя подписанта. Остальной текст представляет собой подпись.

Заметим, что комбинация имени владельца RRSIG RR, класса и Type Covered указывает, что этот RRSIG покрывает "host.example.com" A RRset. Значения метки 3 указывает на то, что использования произвольной символьной подмены (wildcard) не было. Алгоритм, Имя подписанта и тэг ключа указывают, что данная подпись может быть аутентифицирована с использованием зонной ресурсной записи DNSKEY RR example.com, чей алгоритм имеет код 5, а тэг ключа равен 2642.

4. Ресурсная запись NSEC

Ресурсная запись NSEC содержит две вещи: следующее имя собственника (в каноническом порядке зоны), которое содержит официальные данные или точку делегирования NS RRset, и набор типов ресурсных записей, который присутствует в NSEC RR имени владельца [RFC3845]. Полный набор ресурсных записей NSEC в зоне указывает, какие RRset присутствуют в зоне, они образует цепочку авторизованных имен владельцев в зоне. Эта информация используется для реализации авторизованного отказа существования (authenticated denial of existence) для данных DNS, как это описано в [RFC4035].

Так как каждое авторизованное имя в зоне должно быть частью цепочки NSEC, должны существовать ресурсные записи NSEC RR для имен, содержащих CNAME RR. Это не совпадает с требованиями традиционной спецификации DNS [RFC1034], которая утверждает, что если существует CNAME для имени, она является единственным именем, допустимым для этого имени.

Значение типа для NSEC RR равно 47.

Ресурсная запись NSEC должна иметь то же значение TTL, что и поле минимального TTL SOA.

4.1. Формат NSEC RDATA

RDATA ресурсной записи NSEC RR представлено ниже:

Рис. 3

4.1.1. Поле имени следующего домена

Поле следующего домена содержит имя следующего владельца (в каноническом порядке зоны), которое содержит авторизованные данные или хранит точку делегирования RRset. Значением поля имени следующего домена в последнем рекорде NSEC зоны является имя верхней границы зоны (zone apex) (имя владельца ресурсной записи зонной SOA RR). Это указывает, что имя владельца NSEC RR является последним именем в каноническом перечне зоны.

Отправитель не должен использовать сжатие DNS имен в поле следующего домена при передаче NSEC RR.

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

4.1.2. Поле типа бит-карт (Type Bit Maps)

Поле типа бит-карт (Type Bit Maps) идентифицирует типы RRset, которые существуют для имени владельца ресурсных записей NSEC.

Пространство типа RR расщеплено на 256 блоков, каждый из которых представляет младшие 8 бит 16-битового пространства типа RR. Каждый блок, который имеет, по крайней мере, один тип активной ресурсной записи, кодируется с помощью одного октета (от 0 до 255), одного октета длины битовой карты (от 1 до 32), индицируя число октетов, используемых для бит-карт блоков окон, и до 32 октетов (256 бит) бит-карты.

Блоки размещаются в NSEC RR RDATA по нарастанию порядкового номера.

Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ где "|" означает конкатенацию.

Каждая бит-карта кодирует младшие 8 бит типа RR в пределах окна блока, при сетевом порядке бит. Первый бит имеет номер 0. Для окна блока 0, бит 1 соответствует типу RR 1 (A), бит 2 соответствует типу RR 2 (NS) и так далее. Для окна блока 1, бит 1 соответствует типу RR 257, а бит 2 - типу RR 258. Если бит равен 1, это означает, что RRset этого типа присутствует для NSEC RR имени владельца. Если бит равен нулю, это говорит о том, что никакого RRset данного типа нет (для данного NSEC RR имени владельца).

Биты псевдо типов должны быть обнулены, так как они не появляются в зонных данных. Если они все же встретятся, то должны игнорироваться при чтении.

Блоки, не имеющие кода тип не должны использоваться. Завершающие нулевые октеты в бит-картах игнорируются. Длина каждой бит-карты блока определяется кодом типа.

Бит-карты для NSEC RR в точке делегирования требуют особого внимания. Биты, соответствующие NS RRset делегирования, и RR типов, для которых родительская зона имеет авторизованные данные, должны равняться 1; биты, соответствующие любым не-NS RRset, для которых родительская зона не авторизована, должны равняться 0.

4.1.3. Включение имен с произвольными символьными подстановками в NSEC RDATA

Если в зоне появляется имя собственника с произвольной символьной подстановкой, метка ("*") рассматривается как литеральный символ и обрабатывается как любые другие имена владельцев для целей формирования NSEC RRs. Имена владельцев типа Wildcard появляются в поле имя следующего домена без какого-либо раскрытия wildcard.

4.2. Формат представления NSEC RR

Формат презентации секции RDATA имеет следующий вид:

Поле имя следующего домена имеет формат имени домена.

Поле типа бит-карт представляются как последовательность ресурсных записей типа мнемоники. Когда мнемоника неизвестна, должно использоваться представление типа, описанное в [RFC3597].

4.3. Пример NSEC RR

Следующая NSEC RR идентифицирует RRset, ассоциированные с alfa.example.com. и определяет авторизированное имя, следующее за alfa.example.com.

alfa.example.com. 86400 IN NSEC host.example.com. ( A MX RRSIG NSEC TYPE1234 )

Первые 4 текстовые поля специфицируют имя, TTL, класс и тип RR (NSEC). Запись host.example.com. является следующим авторизованным именем после alfa.example.com. в каноническом порядке. A, MX, RRSIG, NSEC и TYPE1234 мнемонические слова, которые указывают, что существуют A, MX, RRSIG, NSEC и TYPE1234 RRsets, ассоциированные с именем alfa.example.com.

Секция RDATA ресурсной записи NSEC RR, рассмотренной выше, следует кодировать как:

            0x04 'h'  'o'  's'  't'
            0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
            0x03 'c'  'o'  'm'  0x00
            0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
            0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
            0x00 0x00 0x00 0x00 0x20

Предполагая, что валидатор может аутентифицировать этот рекорд NSEC, его можно использовать, чтобы проверить, что beta.example.com не существует, или проверить, что нет рекорда AAAA, сопряженного с alfa.example.com. Аутентифицированный отказ существования обсуждается в [RFC4035].

5. Ресурсная запись DS

Ресурсная запись DS относится к DNSKEY RR и используется в процессе аутентификации DNS DNSKEY. Ресурсная запись DS относится к DNSKEY RR, так как хранит тэг ключа, код алгоритма и дайджест DNSKEY RR. Заметим, что если дайджест должен быть достаточен, чтобы идентифицировать общедоступный ключ, запоминание тэга ключа и ключа алгоритма делает процесс идентификации еще более эффективным. При аутентификации DS распознаватель может аутентифицировать DNSKEY RR, на который указывает запись DS. Процесс аутентификации ключа описан в [RFC4035].

Ресурсная запись DS и соответствующая ей DNSKEY RR имеют идентичные имена владельца, но они записываются в разных местах. Ресурсная запись DS появляется только на верхней (родительской) стороне делегирования, и является аутентификационной информацией в родительской зоне. Например, DS RR для "example.com" записывается в "com"-зоне (родительской зоне), а не в "example.com"-зоне (дочерняя зона). Соответствующая DNSKEY RR записывается в "example.com"-зоне (дочерняя зона). Это упрощает управление DNS-зонами, но требует специальных требований к обработке откликов для DS RR; это описано в [RFC4035].

Код типа для DS-рекорда равен 43.

DS RR не вносит ограничений на TTL.

5.1. DS RDATA Wire Format

RDATA для DS RR состоит из двух октетов поля тэга ключа, 1 октета поля алгоритма, 1 октета поля типа дайджеста и собственно поля дайджеста.

Рис. 4.

5.1.1. Поле тэга ключа

Поле тэга ключа содержит тэг ключа DNSKEY RR, относящийся к DS-записи, с сетевым порядком байтов.

Тэг записи используется DS RR также как и в случае RRSIG RRs. В приложении B (RFC-4034) описывается алгоритм вычисления тэга ключа.

5.1.2. Поле алгоритма

Поле алгоритма содержит в себе код алгоритма DNSKEY RR, относящийся к DS-рекорду.

Код алгоритма используется DS RR также как и в случае RRSIG и DNSKEY RRs. В приложении A.1 (RFC-4034) перечислены коды алгоритмов.

5.1.3. Поле типа дайджеста

Запись DS имеет отношение к DNSKEY RR, так как в нее включен дайджест этой DNSKEY RR. Поле типа дайджеста идентифицирует алгоритм, использованный при вычислении дайджеста. В приложении A.2 (RFC-4034) перечислены возможные типы алгоритмов.

5.1.4. Поле дайджеста

DS-рекорд относится к DNSKEY RR и содержит в себе дайджест этого DNSKEY RR.

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

digest = digest_algorithm( DNSKEY имя владельца | DNSKEY RDATA);

      "|" означает конкатенацию

     DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.

Размер дайджеста может варьироваться в зависимости от используемого алгоритма и размера DNSKEY RR. На момент написания данных регламентаций был один алгоритм вычисления дайджеста - SHA-1, который формирует 20-октетный дайджест.

5.2. Обработка ресурсных записей DS при валидации откликов

Ресурсная запись DS прокладывает связь аутентификационной цепочки за пределы границы зоны, по этой причине DS RR требует особой тщательности при обработке. DNSKEY RR, относящаяся к DS RR, должна быть DNSSEC зонным ключом. Флаги ресурсной записи DNSKEY должны иметь флаг 7 равным 1. Если флаги DNSKEY не индицируют зонный ключ DNSSEC, DS RR не должна использоваться в валидационном процессе.

5.3. Формат представления ресурсной записи DS

Формат представления RDATA имеет следующий вид:

class=txt2>Поле тэга ключа должно иметь форму десятичного целого без знака.

Поле алгоритма должно представлять собой либо десятичное целое число без знака, либо мнемоническое имя алгоритма, специфицированное в приложении A.1 (RFC-4034).

Поле типа дайджеста должно иметь форму десятичного целого без знака.

Дайджест должен представлять собой последовательность шестнадцатеричных цифр чувствительных к регистру. Пробелы в теле дайджеста допускаются.

5.4. Пример ресурсной записи DS

Следующий пример показывает вид DNSKEY RR и соответствующий ему DS RR.

   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
                                             fwJr1AYtsmx3TGkJaNXVbfi/
                                             2pHm822aJ5iI9BMzNXxeYCmZ
                                             DRD99WYwYqUSdjMmmAphXdvx
                                             egXd/M5+X7OrzKBaMbCVdFLU
                                             Uh6DhweJBjEVv5f2wwjM9Xzc
                                             nOf+EPbtG9DMBmADjFDc2w/r
                                             ljwvFw==
                                             ) ;  key id = 60485

   dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
                                              98631FAD1A292118 )

Первые 4 текстовые поля специфицируют имя, TTL, класс и тип RR (DS). Код 60485 является ключом для соответствующего "dskey.example.com." DNSKEY RR, а код 5 обозначает алгоритм, используемый в "dskey.example.com." DNSKEY RR. Код 1 соответствует алгоритму, используемому при формировании дайджеста, а остальной RDATA-текст является дайджестом в шестнадцатеричном виде.

6. Каноническая форма и порядок ресурсных записей

Канонический порядок имен нужен для формирования цепочки имен NSEC. Каноническая форма RR и упорядочивание в пределах RRset нужны для того, чтобы формировать и верифицировать RRSIG RR.

6.1. Канонический порядок DNS-имен

С целью обеспечения безопасности DNS имена владельцев упорядочены в соответствии с индивидуальными метками, которые рассматриваются как выровненные по левому краю последовательности октетов.

Чтобы придать цепочке DNS-имен каноническую форму сортировка производится сначала с учетом самых правых меток (наиболее значимых) Для имен с идентичными самыми значимыми метками упорядочение производится с учетом последующих меток.

Например, следующие имена отсортированы согласно каноническому порядку DNS-имен. Наиболее значимая метка - "example". На этом уровне "example" считается первой, далее следуют имена, завершающиеся "a.example", а за ними имена, кончающиеся "z.example". Имена в пределах каждой метки сортируются аналогичным образом.

             example
             a.example
             yljkjljk.a.example
             Z.a.example
             zABC.a.EXAMPLE
             z.example
             \001.z.example
             *.z.example
             \200.z.example

6.2. Каноническая форма RR

Для обеспечения безопасности DNS, канонической формой RR является связанный формат (wire format) RR, где:

  1. каждое доменное имя в RR является полностью развернутым (никакой архивации DNS-имен) и полностью авторизованным;
  2. все US-ASCII символы в верхнем регистре в имени владельца RR заменяются соответствующими символами в нижнем регистре;
  3. если тип RR является NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG, или NSEC, все US-ASCII-символы верхнего регистра в DNS-именах, содержащихся в RDATA заменяются на соответствующие символы в нижнем регистре;
  4. если имя владельца RR содержит символы произвольной подмены, имя владельца остается в исходном виде, включая "*" (никаких wildcard подмен); и
  5. TTL RR устанавливается равным исходной величине, которая содержалась в поле исходного значения TTL, покрывающего RRSIG RR.

Документ [RFC2181] специфицирует то, что RRset не разрешено содержать дублирующие рекорды (несколько RR с одним и тем же именем владельца, классом, типом и RDATA). Следовательно, если программная реализация процесса приведения RRset в каноническую форму детектирует дубликат RR, она должна воспринимать это, как протокольную ошибку.

Типы ресурсных записей DNS: в документе [RFC2535] присвоены значения следующим типам RR SIG - 24, KEY - 25. В документе [RFC3658] присвоено DS-типу значение 43. В документе [RFC3755] присвоены следующие значения типов RR RRSIG - 46, NSEC - 47 и DNSKEY - 48.

Модификации протокола для обеспечения безопасности DNS (RFC-4035)

Расширения безопасности DNS (DNSSEC) представляют собой коллекцию новых ресурсных записей и модификаций протокола, которые вводят аутентификацию происхождения данных DNS и их целостности.

1. Подписывание зон

DNSSEC вводит концепцию подписанных зон. Подписанная зона включает в себя записи общедоступного ключа DNS (DNSKEY), ресурсную запись подпись (RRSIG), следующий безопасный (Next Secure) (NSEC), и (опционно) подписант делегирования (DS). Зона, которая не имеет этих ресурсных записей, считается неподписанной.

DNSSEC требует изменения определения ресурсной записи CNAME ([RFC1035]).

DNSSEC специфицирует два новых типа ресурсных записей: NSEC и DS, которые могут помещаться на границе родительской стороны зоны (то есть, в точке делегирования).

1.1. Включение в зону ресурсных записей DNSKEY

Чтобы подписать зону администратор зоны генерирует одну или более пар ключей общедоступный/секретный и использует общедоступный ключ(и) для подписания авторизованных RRsets в зоне. Для каждого секретного ключа, используемого для формирования в зоне RRSIG RR, зона должна содержать ресурсную запись DNSKEY RR, в которой хранится общедоступный ключ. Ресурсная запись зоны DNSKEY RR должна иметь зонный бит (Zone Key) флагов RDATA равным 1. Общедоступные ключи, сопряженные с другими операциями DNS, могут храниться в DNSKEY RR, которые не помечены, как зонные ключи, но не должны использоваться для верификации RRSIGs.

Если зонный администратор намерен использовать подписанную зону не как остров безопасности, вершина зоны должна содержать, по крайней мере, одну ресурсную запись DNSKEY RR, которая будет служить в качестве безопасной точки входа в зону. Эта безопасная точка входа может использоваться в качестве адресата делегирования через посредство DS RR в родительской зоне (смотри [RFC4034]).

1.2. Включение в зону ресурсных записей RRSIG

Для каждого авторизованного RRset в подписанной зоне, должна существовать, по крайней мере, одна запись RRSIG, которая отвечает следующим требованиям:

Процесс конструирования ресурсной записи RRSIG RR для заданного RRset описан в [RFC4034]. RRset может иметь несколько ресурсных записей RRSIG, с ним сопряженных. Заметим, что, так как RRSIG RRs тесно сопряжена с RRsets, чьи подписи она содержит, RRSIG RR, в отличие от других типов ресурсных записей DNS, не образует RRsets. В частности, значения TTL для RRSIG RR с общим владельцем не следуют RRset-правилам, описанным в [RFC2181].

Сама RRSIG RR не должна подписываться, так как подпись RRSIG RR практически ничего не добавит, но может вызвать бесконечную петлю процесса подписания.

NS RRset, который появляется на вершине имен должен подписываться, но NS RRsets, который появляется в точке делегирования (т.е., NS RRsets в родительской зоне, делегирует имя дочерним зонным серверам имен), не должен подписываться.

Должен существовать RRSIG для каждого RRset, использующего по крайней мере один DNSKEY каждого алгоритма в вершине зоны DNSKEY RRset. Сам вершинный DNSKEY RRset должен быть подписан для каждого алгоритма, появляющегося в DS RRset.

1.3. Включение в зону ресурсных записей NSEC

Каждое имя владельца в зоне, которая имеет авторизованные данные или точку делегирования NS RRset должен иметь ресурсную запись NSEC. Формат записи NSEC и процесс конструирования NSEC RR для заданного имени описан в [RFC4034].

Значение TTL для любого NSEC RR должно быть тем же самым, что и в поле минимального значения TTL в зонном SOA RR.

Запись NSEC (и сопряженный с ней RRSIG RRset) не должен быть единственным RRset при любом конкретном имени собственника. Т.е., процесс подписания не должен создавать NSEC или RRSIG RR для именных узлов собственника, которые не были именами собственника какого-либо RRset до подписания зоны. Главными причинами для этого является желание обеспечить совместимость пространства имен между подписанной и неподписанной версиями одной и той же зоны и желание уменьшить риск несовместимости откликов рекурсивных именных серверов.

Тип бит-карт каждой ресурсной записи NSEC в подписанной зоне должен указывать на присутствие как самой записи NSEC, так и соответствующей записи RRSIG.

Различие между набором имен владельцев, который требует RRSIG RR и набором имен владельцев, который требует рекордов NSEC, является тонким и требующим разъяснения. Запись RRSIG присутствует во всех именах владельцев всех авторизованных RRsets. Записи NSEC присутствуют во всех именах владельцев всех имен, для которых авторизована подписанная зона, а также в именах владельцев делегирования для подписанной зоны в отношении дочерних объектов. Таким образом, только имена пользователей, которые имеют NSEC RRset, будут иметь RRSIG RRs и в подписанной зоне.

Бит-карта для NSEC RR в точке делегирования требует специального внимания. Биты, соответствующие NS RRset и любые RRsets, для которых родительская зона имеет авторизованные данные, должны равняться 1; биты, соответствующие любым не-NS RRset, для которых прародитель не авторизован, должны равняться нулю.

1.4. Включение в зону ресурсных записей DS

Ресурсная запись DS формирует цепочку аутентификации между DNS-зонами. DS RRset должен присутствовать в точке делегирования, когда дочерняя зона подписана. DS RRset может содержать несколько записей, каждая из которых ссылается на общедоступный ключ в дочерней зоне, используемой для верификации RRSIGs в этой зоне. Все DS RRsets в зоне должны быть подписаны, а DS RRsets не должны появляться в вершине зоны.

DS RR должна указывать на DNSKEY RR, которая присутствует в вершинном DNSKEY RRset дочерней зоны а дочерний DNSKEY RRset вершины зоны должен быть подписан соответствующим секретным ключом. Ресурсные записи DS, которые не удовлетворяют этим требованиям, не годятся для валидации, но так как DS RR и соответствующий ей DNSKEY RR, находятся в разных зонах, и так как DNS не жестко взаимносогласован, возможно временное рассогласование.

TTL набора RRset должно соответствовать набору делегирования NS RRset (т.е., NS RRset из одной и той же зоны).

Конструирование DS RR требует знания соответствующей DNSKEY RR в дочерней зоне.

1.5. Изменения ресурсной записи CNAME

Если CNAME RRset присутствует в имени подписанной зоны, необходимы соответствующие RRSIG и NSEC RRsets этого имени. KEY RRset этого имени допускается для безопасного динамического обновления в соответствии с ([RFC3007]). Другие типы не должны присутствовать.

1.6. Типы DNSSEC RR, появляющиеся на границах зоны

DNSSEC вводит два новых типа ресурсных записей, которые необычны из-за того, что могут появляться на родительской стороне границы зоны. На родительской стороне границы зоны (т.е., в точке делегирования), необходимы NSEC RR для имени владельца. DS RR может также присутствовать, если делегированная зона подписана и ищет цепочку аутентификации до родительской зоны.

2. Обслуживание

Термины "SNAME", "SCLASS" и "STYPE" используются далее в значениях, определенных в [RFC1034].

Сервер безопасности имен должен поддерживать расширение размера сообщения EDNS0 ([RFC2671]), должен поддерживать сообщения с размером, по крайней мере, 1220 октетов и желательна поддержка сообщений размером до 4000 октетов. Так как пакеты IPv6 могут фрагментироваться только в машине отправителя, сервер имен должен заботиться о фрагментации UDP-дейтограмм, если это необходимо с учетом MTU.

Безопасный сервер имен, который получает DNS-запрос, который не содержит псевдо-ресурсную запись EDNS OPT или у которого бит DO равен нулю, должен рассматривать ресурсные записи RRSIG, DNSKEY и NSEC не должен осуществлять каких-либо действий, описанных ниже. Так как тип DS RR имеет особенность - существования только в точках делегирования родительской зоны, DS RR всегда требует некоторой специальной обработки.

Безопасный сервер имен, который получает прямые запросы ресурсных записей безопасности, которые соответствуют более чем одной зоне, которую он обслуживает (например, записи NSEC и RRSIG выше и ниже точки делегирования, где сервер авторизован для обеих зон) должен действовать по обстоятельствам. Так как отклик всегда соответствует запросу, сервер имен может прислать одно из следующего:

DNSSEC выделяет два новых бита в заголовке DNS-сообщения: CD-бит (проверка блокирована) и AD-бит (авторизованные данные). CD-бит контролируется распознавателем; безопасный сервер имен должен копировать CD-бит из запроса в соответствующий отклик. AD-бит контролируется серверами имен; безопасный сервер имен должен игнорировать равенство бита AD 1 в запросах.

Безопасный сервер имен, который синтезирует ресурсные записи CNAME из DNAME RR, как это описано в [RFC2672], не должен генерировать подписи для создаваемых записей CNAME.

2.1. Авторизованные серверы имен

При получении корректного запроса, который имеет EDNS ([RFC2671]) OPT псевдо-записи DO-бит =1([RFC3225]), авторизованный безопасный сервер имен подписанной зоны должен содержать дополнительные ресурсные записи RRSIG, NSEC и DS RR, в соответствии со следующими правилами:

Эти правила применимы к откликам, где семантика транспортирует информацию о присутствии или отсутствии ресурсных записей. Т.е., эти правила не предназначены для управления такими откликами, как RCODE 4 ("Not Implemented") или RCODE 5 ("Refused").

DNSSEC не изменяет зонный обмен протокола DNS.

2.1.1. Включение ресурсных записей RRSIG в отклик

При реагировании на запросы, которые имеют бит DO=1, безопасный авторизованный сервер имен должен пытаться послать RRSIG RR, которые распознаватель может использовать для аутентификации RRsets в отклике. Сервер имен должен всячески пытаться включить в отклик RRset и соответствующий ему RRSIG(s) в отклик. Включение RRSIG RR в отклик регулируется следующими правилами:

2.1.2. Включение ресурсных записей DNSKEY в отклик

При реагировании на запросы, которые имеют бит DO=1, а также на запросы SOA или NS RRs в вершине подписанной зоны, безопасный авторизованный сервер имен может вернуть DNSKEY RRset для вершины зоны в дополнительной секции. В этой ситуации DNSKEY RRset и сопряженные RRSIG RRs имеют более низкий приоритет по сравнению с любой информацией, которая будет помещена в дополнительную секцию. Сервер имен не должен включать DNSKEY RRset, если недостаточно места в сообщении отклика для DNSKEY RRset и сопряженного с ним RRSIG RR(s). Если не хватает места для размещения этих DNSKEY и RRSIG RRs, сервер имен должен отбросить их и не устанавливать бит TC.

2.1.3. Включение ресурсных записей NSEC в отклик

При реагировании на запрос с установленным битом DO, безопасный авторизованный сервер имен подписанной зоны должен включить NSEC RRs в каждом из следующих случаев:

Нет данных: зона содержит RRsets, которые соответствуют <SNAME, SCLASS> но не содержат какого-либо RRsets, который бы соответствовал <SNAME, SCLASS, STYPE>.

Ошибка имени: Зона не содержит каких-либо RRsets, которые соответствуют <SNAME, SCLASS> точно или для произвольной символьной подстановки в имени.

Ответ Wildcard: Зона не содержит каких-либо RRsets, которые точно соответствуют <SNAME, SCLASS>, но содержит RRset, который соответствует <SNAME, SCLASS, STYPE> за счет расширения имени с wildcard.

Wildcard нет данных: Зона не содержит каких-либо RRsets, которые точно соответствуют <SNAME, SCLASS> и содержит один или более RRsets, которые соответствуют <SNAME, SCLASS> за счет расширения имени wildcard, но не содержит какого-либо RRsets, который соответствует <SNAME, SCLASS, STYPE> за счет расширения имени с wildcard.

В каждом из этих случаев, сервер имен включает NSEC RRs в отклик, чтобы проверить, есть ли в зоне точное соответствие для <SNAME, SCLASS, STYPE> и что отклик, который присылает сервер имен, содержит корректные данные.

2.1.3.1. Включение NSEC RR: Отклик No Data

Если зона содержит RRsets, соответствующие <SNAME, SCLASS>, но не содержит ни одного RRset, соответствующего <SNAME, SCLASS, STYPE>, тогда сервер имен должен включить NSEC RR для <SNAME, SCLASS> вместе с сопряженными с ней RRSIG RR(s) в авторизованной секции отклика. Если место не позволяет включить NSEC RR или ассоциированные с ним RRSIG RR(s), сервер имен должен установить бит TC.

Так как существует поиск имен, расширения имен с подстановкой символов (wildcard) не применяется для этого запроса, и одного подписанного NSEC RR достаточно, чтобы доказать, что запрашиваемый тип RR не существует.

2.1.3.2. Включение NSEC RR: Отклик Name Error

Если зона не содержит каких-либо RRsets, соответствующих <SNAME, SCLASS> либо точно, либо за счет расширения имен с помощью произвольных символьных подстановок (wildcard), тогда сервер имен должен включить следующие NSEC RRs в авторизованную секцию, совместно с RRSIG RRs:

В некоторых случаях, одна NSEC RR может подтвердить оба эти тезиса. Если это так, сервер имен должен включить NSEC RR и ее RRSIG RR(s) в авторизованную секцию.

Если пространство не позволяет включить эти записи NSEC и RRSIG, сервер имен должен установит бит TC.

Имена собственников этих NSEC и RRSIG RRs не подвергаются расширению с помощью wildcard, когда эти ресурсные записи включены в авторизованную секцию отклика.

Заметим, что эта форма отклика охватывает случаи, в которых SNAME соответствует пустому нетерминальному имени в пределах зоны (имя, которое не является именем собственника для любого RRset, но которое является родительским именем одного или более RRsets).

2.1.3.3. Включение NSEC RRs: отклик Wildcard Answer

Если зона не содержит каких-либо RRsets, которые точно соответствуют <SNAME, SCLASS> но содержат RRset, которые согласуются с <SNAME, SCLASS, STYPE> за счет расширения имен wildcard, сервер имен должен включить в ответ wildcard-расширение и соответствующие wildcard-расширенные RRSIG RRs в секцию ответа и должен включить в авторизованную секцию NSEC RR и ассоциированные RRSIG RR(s), подтверждающие, что зона не содержит более точного соответствия для <SNAME, SCLASS>. Если пространство не позволяет, включить записи ответа, NSEC и RRSIG RRs, сервер имен должен установить бит TC.

2.1.3.4. Включение NSEC RRs: отклик Wildcard No Data Response

Этот случай является комбинацией предыдущих случаев. Зона не содержит точного подобия <SNAME, SCLASS>, и хотя зона содержит RRsets, который соответствует <SNAME, SCLASS> за счет расширения wildcard, ни один из RRsets не соответствует STYPE. Сервер имен должен включить следующие NSEC RRs в авторизованную секцию, вместе с ассоциированными с ними RRSIG RRs:

В некоторых случаях, отдельная запись NSEC может подтвердить оба эти тезиса. Если это так, сервер имен должен только включить NSEC RR и ее RRSIG RR(s) в авторизованную секцию.

Имена собственников этих NSEC и RRSIG RRs не могут использовать расширений имен wildcard, когда эти ресурсные записи включены в авторизованную секцию отклика.

Если свободное место не позволяет включить эти NSEC и RRSIG RR, сервер имен должен установить бит TC.

2.1.3.5. Нахождение правильных NSEC RRs

Как показано выше, существует несколько ситуаций, в которых безопасный авторизованный сервер имен должен локализовать NSEC RR, которая не согласуется с RRsets для конкретного SNAME. Локализация такой записи NSEC в пределах авторизованной зоны относительно проста, по крайней мере в принципе. Алгоритм представленный ниже призван прояснить картину.

Чтобы найти NSEC, которая подтверждает, что нет RRsets соответствующего имени N в зоне Z, который бы поддерживал его, формируем последовательность S, с каноническим порядком ([RFC4034]) и без имен дубликатов. Находим имя M, которое бы непосредственно предшествовало N в S, если существует любой RRsets с именем владельца N. M является именем владельца NSEC RR, который подтверждает, что не существует RRsets с именем владельца N.

Алгоритм нахождения NSEC R, которая подтверждает, что данное имя не покрыто каким-либо wildcard является подобным, но требует дополнительных шагов. Точнее, алгоритм нахождения NSEC, подтверждающего, что нет RRsets с приемлемым именем wildcard, в точности тот же, что и алгоритм нахождения NSEC RR, которая подтверждает, что RRsets с любым другим именем не существует.

2.1.4. Включение в отклик DS RRs

При формировании отклика на запрос, который имеет установленный бит DO, безопасный авторизованный сервер имен присылает ссылку, содержащую данные DNSSEC вместе с NS RRset.

Если в точке делегирования присутствует DS RRset, сервер имен должен прислать DS RRset и сопряженные с ним RRSIG RR(s) в авторизованной секции совместно с NS RRset.

Если в точке делегирования нет DS RRset, сервер имен должен прислать как NSEC RR, которая подтверждает, что DS RRset отсутствует, и NSEC RR's совместно с NS RRset. Сервер имен должен поместить NS RRset до NSEC RRset и ассоциированного с ним RRSIG RR(s).

Включение этих DS, NSEC и RRSIG RRs увеличивает размер сообщений и может вызвать отбрасывание некоторых ресурсных записей. Если место не позволяет включить DS или NSEC RRset и ассоциированных RRSIG RRs, сервер имен должен установить бит TC.

2.1.4.1. Формирование откликов на запросы DS RRs

Тип ресурсной записи DS является необычным, в том смысле, что он появляется только на родительской стороне зоны. Например, DS RRset для делегирования "foo.example" записан в зоне "example", а не в зоне "foo.example". Это требует специальных правил обработки, как для серверов имен, так и распознавателей, так как сервер имен для дочерней зоны является авторизованным для имени на границе зоны, но дочерняя зона не содержит DS RRset. Безопасный распознаватель посылает запросы в родительскую зону, когда ищет нужную DS RR в точке делегирования. Однако, чтобы избежать сбоев безопасных распознавателей (resolver), необходимы специальные правила, которые могут быть включены в процесс обработки таких запросов (например, при конфигурировании сети, которая вынуждает безопасного распознавателя направлять свои запросы через небезопасные рекурсивные серверы имен).

Требование специальной обработки для безопасного сервера имен возникают только когда реализуются следующие условия:

Во всех прочих случаях, сервер имен либо имеет некоторую возможность получения DS RRset, либо не предполагается получение DS RRset даже в случае использования предварительной DNSSEC обработки, так что сервер имен может возвратить либо DS RRset, либо выдать сигнал ошибки.

Если все вышеназванные условия выполнены, однако, сервер имен является авторизованным для SNAME, но не может предоставить запрошенный RRset. В этом случае сервер имен возвращает авторизованный отклик "no data", демонстрируя, что в дочерней зоне отсутствует DS RRset.

2.1.5. Отклики на запросы типа AXFR или IXFR

DNSSEC не модифицирует процесс DNS зонного обмена. Подписанная зона будет содержать ресурсные записи RRSIG, DNSKEY, NSEC и DS, но эти записи не имеют специального значения с точки зрения зонных операций обмена.

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

DS RRsets появляется только на родительской стороне границы зоны и является авторизованными данными в родительской зоне. DS RRset должен быть включен в зонный обмен, в котором RRset является авторизованной информацией. В случае DS RRset, это родительская зона.

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

Ресурсные записи RRSIG появляются как в родительских, так и в дочерних граничных зонах и являются авторизованными для любой зоны, которая содержат RRset, для которого RRSIG RR предоставляет подпись. Т.е., RRSIG RR для DS RRset или родительская NSEC RR на границе зоны будут авторизованы в родительской зоне, а RRSIG для любого RRset в вершине дочерней зоны будет авторизован в дочерней зоне. Родительская и дочерняя RRSIG на границе зоны никогда не будут идентичны, так как поле имени подписанта RRSIG RR в вершине дочерней зоны будет индицировать DNSKEY RR в вершине дочерней зоны, в то время как то же самое поле родительской RRSIG RR на границе зоны будет указывать на DNSKEY RR в вершине родительской зоны.

2.1.6. Биты AD и CD в авторизованных откликах

Биты CD и AD созданы для коммуникации между безопасными распознавателями и безопасными рекурсивными серверами имен.

Безопасный сервер имен не выполняет валидацию подписи авторизованных данных в ходе обработки запросов, даже когда бит CD =0. Безопасный сервер имен должен обнулить CD-бит, при формировании авторизованного отклика. Безопасный сервер имен не должен устанавливать бит в отклике, если только сервер имен не считает все RRsets в секциях ответа и авторизации аутентичными. В рамках локальной политики безопасный сервер имен может рассматривать данные из авторизованной зоны аутентичными без дальнейшей валидации. Однако, сервер имен не должен делать этого, если только он не получит доступ к авторизованной зоне через какие-то безопасные средства (такие как безопасные механизмы зонного обмена) и не должен делать этого, если только он не был сконфирурирован явно для выполнения таких действий.

Безопасный сервер имен, который поддерживает рекурсию, должен следовать правилам для битов CD и AD, рассмотренным ниже.

2.2. Рекурсивные серверы имен

Как это описано в [RFC4033], безопасный рекурсивный сервер имен является объектом, который действует как безопасный сервер имен и как безопасный распознаватель. Далее используются понятия "сторона сервера имен" и "сторона распознавателя", чтобы ссылаться на программу в безопасном рекурсивном сервере имен, который выполняет функцию безопасного сервера имен и на программу, реализующую функцию безопасного распознавателя.

Сторона распознавателя выполняет обычные роли кэширования и негативного кэширования, которые возлагаются на любой безопасный распознаватель.

2.2.1. Бит DO

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

2.2.2. Бит CD

Бит CD существует для того, чтобы позволять безопасному распознавателю блокировать валидацию подписи безопасным сервером имен при обработке конкретного запроса.

Сторона сервера имен должна копировать установку CD-бита из запроса в соответствующий отклик.

Сторона сервера имен безопасного рекурсивного сервера должна пропускать состояние CD-бита стороне распознавателя вместе с остальной частью исходного запроса, так чтобы сторона распознавателя знала, нужно ли верифицировать данные отклика, передаваемые стороне сервера имен. Если бит CD=1, это индицирует, что исходный распознаватель желает выполнить аутентификацию в согласии с локальной политикой. Таким образом, стороне распознавателя рекурсивного сервера имен не нужно выполнять аутентификацию RRsets в отклике. Когда бит CD=1, рекурсивный сервер имен должен, если возможно, вернуть запрошенные данные исходному распознавателю, даже если локальная политика рекурсивного сервера имен требует удаления соответствующих записей. Т.е., при установке бита CD, исходный распознаватель индицирует, что он берет ответственность за выполнение аутентификации на себя, и рекурсивный сервер имен не должен в это вмешиваться.

Если сторона распознавателя реализует BAD кэш, а сторона сервера имен получает запрос, который соответствует входным данным в кэше распознавателя, отклик стороны сервера имен зависит от состояния CD-бита в исходном запросе. Если бит CD=1, сторона сервера имен должна прислать данные BAD-кэша; если бит CD=0, сторона сервера имен должна прислать сигнал RCODE 2 (ошибка сервера).

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

2.2.3. Бит AD

Сторона сервера имен безопасного рекурсивного сервера не должна устанавливать бит AD в отклике, если только сервер имен не рассматривает все RRsets в секциях ответа и авторизации отклика, как аутентичные. Сторона сервера имен должна установить бит AD, если и только если сторона распознавателя рассматривает все RRsets в секции ответа и любые адекватные ресурсные записи негативного отклика в авторизационной секции аутентичными. Сторона распознавателя должна следовать процедуре обработки, описанной в разделе 4, чтобы определить, являются ли ресурсные записи аутентичными. Однако, для обратной совместимости, рекурсивный сервер имен может установить бит AD, когда отклик содержит неподписанную CNAME RR, если эти CNAME RR были синтезированы из аутентичных DNAME RR, которые также включают в себя отклик согласно требованиям [RFC2672].

3. Распознавание

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

3.1. Поддержка EDNS

Безопасный распознаватель должен включать в поддержку псевдо ресурсных записей EDNS ([RFC2671]) OPT с установкой бита DO ([RFC3225]) при посылке запроса.

Безопасный распознаватель должен поддерживать размеры сообщений, по крайней мере, 1220 октетов, желательно, чтобы он поддерживал сообщения размером до 4000 октетов, он также должен использовать поле "размер поля данных UDP отправителя" в псевдо ресурсных записях EDNS OPT, чтобы объявлять размер сообщения, который будет воспринят. IP-уровень безопасного распознавателя должен обрабатывать правильно фрагментированные UDP-пакеты вне зависимости от того, получены эти фрагменты через IPv4 или IPv6.

3.2. Поддержка верификации подписи

Безопасный распознаватель должен поддерживать механизмы верификации подписи, описанные ниже, и должен применять их к каждому полученному отклику за исключением:

Поддержка безопасным распознавателем верификации подписи должна включать в себя верификацию имен владельцев wildcard.

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

При попытке получить потерянные записи DS, безопасный распознаватель, работающий в итеративном режиме, должен посылать запросы серверам имен для родительской зоны.

3.3. Определение статуса безопасности данных

Безопасный распознаватель должен уметь определять, следует ли ожидать того, что конкретный RRset подписан. Более точно безопасный распознаватель должен уметь разделять случаи:

Безопасный: RRset, для которого распознаватель способен построить цепочку подписанных ресурсных записей DNSKEY и DS RRs от надежного безопасного узла до RRset. В этом случае RRset должен быть подписан и являться субъектом валидации, как это описано выше.

Небезопасный: RRset для которого распознаватель знает, что он не имеет цепочки подписанных ресурсных записей DNSKEY и DS RRs от любой доверительной начальной точки до RRset. Это может случиться, когда адресный RRset лежит в неподписанной зоне. В этом случае, RRset может быть подписан или не подписан, но распознаватель будет неспособен верифицировать подпись.

Фиктивный: RRset для которого распознаватель полагает, что он может установить цепочку доверия, но для которого он не может этого сделать, либо из-за подписей, которые по некоторой причине не удается верифицировать или из-за потери некоторых данных. Этот случай может указывать на атаку, но может быть также результатом конфигурационной ошибки или повреждения информации.

Неопределенный: RRset, для которого распознаватель не способен определить, должен ли RRset быть подписан, так как распознаватель не способен получить необходимые ресурсные записи DNSSEC. Это может случиться, когда безопасный распознаватель не способен контактировать с безопасным сервером имен для соответствующей зоны.

3.4. Сконфигурированные доверительные ссылки (Configured Trust Anchors)

Безопасный распознаватель должен быть способен конфигурироваться с, по крайней мере, одним общедоступным ключом или DS RR и должен быть конфигурируем с несколькими проверенными общедоступными ключами или DS RRs. Так как безопасный распознаватель не сможет валидировать подписи без сконфигурированного доверительного узла, распознаватель должен иметь разумно надежный механизм для получения таких ключей в процессе загрузки; примерами таких механизмов могут служить некоторые формы неразрушаемой памяти (такой как дисковый драйв) или некоторый доверительный конфигурационный механизм с привлечением локальной сети.

Заметим, что доверительные узлы также покрывают ключевой материал, который может обновляться безопасным образом. Безопасная техника может быть реализована за счет физической среды, протокола обмена ключами, или какими-то иными средствами.

3.5. Кэширование откликов

Безопасный распознаватель должен кэшировать каждый отклик в качестве отдельного рекорда, содержащего весь ответ, включая именованный RRset и любые сопряженные ресурсные записи DNSSEC. Распознаватель должен ликвидировать запись, когда для любой из RR завершается срок пригодности. В большинстве случаев соответствующий индекс кэша содержит три компонента <QNAME, QTYPE, QCLASS>, но в случае типа отклика индекс включает в себя два компонента <QNAME,QCLASS>.

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

Существует две ситуации, для которых это подходит:

  1. при использовании рекорда RRSIG, можно прийти к заключению, что ответ был синтезирован с применением wildcard. Безопасный рекурсивный сервер имен может запомнить эти данные wildcard и использовать их для генерации позитивных откликов на запросы, отличные от случая имен, для которых был получен ответ в первый раз.
  2. полученные ресурсные записи NSEC для проверки несуществования имени могут быть использованы повторно безопасным распознавателем, чтобы проверить несуществавание любого имени из диапазона, который он покрывает.

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

3.6. Обработка битов CD и AD

Безопасный распознаватель может установить бит CD в запросе, чтобы индицировать, что распознаватель берет ответственность на себя, даже если местная политика требует помещения RRsets в отклик.

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

Распознаватель должен игнорировать значение битов CD и AD в отклике, если только отклик не был получен с использованием безопасного канала или распознаватель был специально сконфигурирован соответствующим образом.

3.7. Кэширование плохих данных (BAD Data)

В то время как многие сбои валидации являются временными, некоторые могут быть постоянными, например, вызванные административными ошибками (отказ при повторной попытке подписи зоны, сбой часов и т.д.). Так как регламентации в этих случаях не помогут, распознаватели-валидаторы могут генерировать значительный объем ненужного DNS-трафика, в результате повторных запросов RRsets с постоянными ошибками валидации.

Чтобы предотвратить такой ненужный трафик, безопасные распознаватели могут кэшировать данные с неверными подписями с определенными ограничениями. Кэширование таких данных сходно с негативным кэшированием ([RFC2308]), за исключением того, что вместо кэширования корректного негативного отклика распознаватель кэширует факт неудачной валидации конкретного ответа. Далее такие данные (с некорректной подписью) будут называться "BAD cache".

Распознаватель, который использует BAD cache должен предпринять шаги, чтобы предотвратить кэширование в следующих случаях:

Распознаватели не должны возвращать RRsets для случая BAD cache, если только распознаватель не должен проверять подпись RRsets.

3.8. Синтезированные CNAME

Безопасный распознаватель-валидатор должен рассматривать подпись корректной ресурсной записи DNAME, как покрывающую также и неподписанные CNAME RRs, которые могут быть получены из DNAME RR, как это описано в [RFC2672]. Распознаватель может сохранять такие CNAME RRs в своем кэше или посылать в виде ответов.

4. Аутентификация DNS-откликов

Чтобы использовать DNSSEC RR для аутентификации, безопасный распознаватель требует знания, по крайней мере, одного аутентифицированного DNSKEY или DS RR. Процесс получения этой исходной доверительной привязки реализуется через некоторый внешний механизм. Например, распознаватель может использовать некоторый внешний обмен с целью получения DNSKEY RR зоны или DS RR, которая идентифицирует и аутентифицирует ресурсную запись DNSKEY зоны.

Исходная запись DNSKEY RR может использоваться для аутентификации DNSKEY RRset вершины зоны. Чтобы аутентифицировать DNSKEY RRset вершины зоны с помощью исходного ключа, распознаватель должен:

  1. проверить, что исходная DNSKEY RR присутствует в DNSKEY RRset вершины, и что DNSKEY RR имеет установленный флаг зоны (DNSKEY RDATA бит 7); и
  2. проверить, что имеется RRSIG RR, которая покрывает DNSKEY RRset вершины, и что комбинация RRSIG RR и исходной DNSKEY RR аутентифицирует DNSKEY RRset.

Раз распознаватель аутентифицировал DNSKEY RRset вершины, используя исходную DNSKEY RR, делегирование из этой зоны может быть аутентифицировано с использованием DS RRs. Это позволяет распознавателю стартовать с исходного ключа и использовать рекурсивно DS RRsets вдоль всего дерева DNS, получая другие вершинные DNSKEY RRsets. Если распознаватель был сконфигурирован с корневой DNSKEY RR, и если каждое делегирование имеет DS RR, ассоциированное с ним, тогда распознаватель может получить и валидировать любой вершинный DNSKEY RRset.

Когда распознаватель индицирует поддержку для DNSSEC (путем установки бита DO), безопасный сервер имен должен попытаться предоставить в отклике необходимые DNSKEY, RRSIG, NSEC и DS RRsets. Однако, безопасный распознаватель может получить отклик, который не имеет соответствующих DNSSEC RRs, либо из-за конфигурационных особенностей безусловно надежного вышерасположенного рекурсивного сервера имен, который случайно интерферирует с DNSSEC RRs, либо из-за атаки, в которой атакер фальсифицирует отклик, удаляет DNSSEC RRs из отклика, или модифицирует запрос, так что появляется незапрошенная ресурсная запись DNSSEC. Отсутствие данных DNSSEC в отклике не должно само по себе рассматриваться, как указание на отсутствие аутентификационной информации.

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

4.1. Специальные соображения по островам безопасности

Острова безопасности (смотри [RFC4033]) представляют собой подписанные зоны, для которых невозможно сформировать аутентификационную цепочку до ее прародителя. Валидирующие подписи в пределах острова безопасности требуют, чтобы валидатор имел некоторые другие средства для получения исходного зонного ключа. Если валидатор не может получить такой ключ, он должен перейти в режим работы, когда зоны в пределах острова безопасности не подписаны.

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

4.2. Аутентификация ссылок

Раз вершинный DNSKEY RRset для подписанной родительской зоны аутентифицирован, DS RRsets может использоваться для аутентификации делегирования, подписанных дочерних зон. DS RR идентифицирует DNSKEY RR в DNSKEY RRset вершины дочерней зоны и содержит криптографический дайджест DNSKEY RR дочерней зоны. Использование сильного алгоритма криптографического дайджеста гарантирует то, что для атакера неэффективно генерировать DNSKEY RR, который бы соответствовал дайджесту. Таким образом, аутентифицирующий дайджест позволяет распознавателю аутентифицировать соответствующий DNSKEY RR. Распознаватель может тогда использовать этот дочерний DNSKEY RR, чтобы аутентифицировать весь дочерний DNSKEY RRset для вершины.

Данная запись DS RR для делегирования и DNSKEY RRset дочерней вершины могут быть аутентифицированы:

Если ссылка из родительской зоны не содержит DS RRset, отклик должен содержать подписанный NSEC RRset, подтверждающий, что для делегированного имени не существует DS RRset. Безопасный распознаватель должен запрашивать сервер имен DS RR родительской зоны, если ссылка не содержит ни DS RRset, ни NSEC RRset, подтверждающие, что не существует DS RRset (см. раздел 3).

Если валидатор аутентифицирует NSEC RRset, который подтверждает, что для данной зоны не существует DS RRset, тогда нет аутентификационного пути, ведущего от родительской к дочерней зоне. Если распознаватель имеет исходный DNSKEY или DS RR, который принадлежит дочерней зоне или какой-либо делегированной зоне ниже дочерней, этот исходный DNSKEY или DS RR может использоваться для восстановления аутентификационного пути. Если не существует такого исходного DNSKEY или DS RR, валидатор не может аутентифицировать RRsets в пределах или ниже дочерней зоны.

Если валидатор не поддерживает ни одного алгоритма, перечисленного в аутентифицированном DS RRset, тогда распознаватель не имеет аутентификационного пути, ведущего от родительской к дочерней зоне. Распознаватель должен обрабатывать такой случай, как если бы это был случай аутентифицированного NSEC RRset, подтверждающий, что не существует DS RRset.

Заметим, что для подписанного делегирования существует два NSEC RRs, ассоциированных с делегированным именем. Один NSEC RR находится в родительской зоне, и может использоваться для подтверждения того, существует ли DS RRset для делегированного имени. Второй NSEC RR размещается в дочерней зоне и идентифицирует, какой RRsets присутствует в вершине дочерней зоны. Родительская и дочерняя NSEC RR могут быть всегда различены, так как бит SOA будет установлен в дочерней NSEC RR и обнулен в родительской NSEC RR. Безопасный распознаватель должен использовать родительский NSEC RR, когда пытается проверить, существует ли DS RRset.

Если распознаватель не поддерживает ни одного алгоритма, перечисленного в аутентифицированном DS RRset, тогда распознаватель будет не способен верифицировать путь аутентификации в дочерней зоне. В этом случае распознаватель должен рассматривать дочернюю зону, как неподписанную.

4.3. Аутентифицирующий RRset с RRSIG RR

Валидатор может использовать RRSIG RR и соответствующую ему запись DNSKEY RR, чтобы попытаться аутентифицировать RRsets. Валидатор сначала проверяет RRSIG RR, чтобы выяснить, покрывает ли она RRset, пригодна ли она, и идентифицирует ли DNSKEY RR. Валидатор затем формирует каноническую форму подписанных данных путем подключения RRSIG RDATA (исключая поле подписи) с канонической формой покрытого RRset. И наконец, валидатор использует открытый ключ и подпись, чтобы аутентифицировать подписанные данные.

4.3.1. Проверка корректности RRSIG RR

Безопасный распознаватель может использовать RRSIG RR для аутентификации RRset, если выполняются следующие условия:

Возможно, что более одной записи DNSKEY RR соответствуют перечисленным выше условиям. В этом случае валидатор не может установить, какую запись DNSKEY RR использовать при аутентификации подписи, и он должен попытаться работать с каждой из записей, пока подпись не будет верифицирована.

Заметим, что процесс аутентификации имеет смысл лишь, если валидатор аутентифицирует DNSKEY RR до ее использования для валидации подписей. Соответствие записи DNSKEY RR считается корректным, если:

4.3.2. Реконструкция подписанных данных

Раз RRSIG RR отвечает требованиям, валидатор должен реконструировать исходные подписанные данные. Исходные подписанные данные включают в себя RRSIG RDATA (исключая поле подпись) и каноническую форму RRset. Помимо упорядочения каноническая форма RRset может также отличаться от полученного RRset из-за, например, архивации DNS-имен, декрементированного TTL или выражений типа wildcard. Валидатор должен реализовать следующие процедуры, чтобы реконструировать исходные подписанные данные:

подписанные данные = RRSIG_RDATA | RR(1) | RR(2)...  где
            "|" означает конкатенацию

          RRSIG_RDATA представляет собой формат полей RRSIG RDATA
               за исключением поля подпись и имя подписанта в канонической форме.

          RR(i) = name | type | class | OrigTTL | RDATA length | RDATA

               name вычислено в соответствии с функцией, описанной ниже
               class является классом RRset
               type является типом RRset и всех RRs в классе
               OrigTTL является значением исходного значения TTL RRSIG.

               Все имена в поле RDATA имеют каноническую форму
               Набор всех RR(i) отсортированных в каноническом порядке.

         Чтобы вычислить имя нужно:
               пусть rrsig_labels = значение поля метки RRSIG

               пусть fqdn = RRset's полностью определенное имя домена в канонической форме

               пусть fqdn_labels = числу меток fqdn.

               если rrsig_labels = fqdn_labels,
                   name = fqdn

               если rrsig_labels < fqdn_labels,
                  name = "*." | самый правый rrsig_label из меток fqdn

               если rrsig_labels > fqdn_labels
                  RRSIG RR не прошла необходимую валидацию и не должна использоваться для аутентификации этого RRset.

Канонические формы для имен и RRsets определены в [RFC4034].

NSEC RRsets на границе делегирования требует специальной обработки. Существует два набора NSEC RRsets, ассоциированных с подписанными именами делегирования. Один NSEC RRset размещается в родительской зоне и специфицирует, какой RRsets присутствует в родительской зоне. Второй NSEC RRset размещается в дочерней зоне и идентифицирует, какой RRsets находится в вершине дочерней зоны. Родительский и дочерний NSEC RRset могут быть всегда различимы, так как только дочерний NSEC RR будет указывать, что существует SOA RRset для данного имени. При реконструировании исходного NSEC RRset для делегирования из родительской зоны, NSEC RRs не должен объединяться с NSEC RRs из дочерней зоны. При реконструировании исходного NSEC RRset для вершины дочерней зоны, NSEC RRs не должны объединяться с NSEC RRs из родительской зоны.

Заметим, что каждый из двух NSEC RRsets в точке делегирования имеют сходные RRSIG RR с именем владельца, соответствующие делегированному имени, и каждый из этих RRSIG RRs являются авторизованными данными, ассоциированными с той же зоной, которая содержит соответствующий NSEC RRset.

4.3.3. Проверка подписи

Раз распознаватель проверил RRSIG RR и реконструировал исходные подписанные данные, валидатор может попытаться использовать криптографическую подпись для аутентификации подписанных данных, и тем самым аутентифицировать RRset.

Поле алгоритм в RRSIG RR идентифицирует криптографический алгоритм, использованный для генерации подписи. Сама подпись содержится в поле подпись RRSIG RDATA, а общедоступный ключ, использованный для верификации подписи, хранится в поле общедоступный ключ соответствующей записи DNSKEY RR(s). В [RFC4034] имеется перечень типов алгоритмов.

Заметим, что имеется возможность существования нескольких DNSKEY RR. В этом случае, валидатор может только определить, какая DNSKEY RR является корректной, пытаясь применить общедоступный ключ для валидации подписи.

Если поле меток RRSIG RR не равно числу меток в RRset авторизованного имени владельца, тогда RRset либо не корректен, либо является результатом расширения wildcard. Прежде чем рассматривать аутентичность RRset, распознаватель должен верифицировать, какое расширение wildcard было применено.

Если другие RRSIG RRs также покрывают этот набор RRset, местный распознаватель политики безопасности определяет, должен ли распознаватель проверить также эти RRSIG RRs и как разрешить конфликты, если эти RRSIG RRs приводят к разным результатам.

Если распознаватель признает RRset аутентичным, валидатор должен установить TTL для RRSIG RR и каждой RR в аутентифицированном RRset на уровне не больше минимума:

4.3.4. Аутентификация положительных откликов RRset с расширениями типа Wildcard

Если число меток в RRset имени владельца больше содержимого поля меток покрывающего RRSIG RR, тогда RRset и покрывающая его запись RRSIG RR были созданы в результате расширения wildcard. Раз валидатор верифицировал подпись, он должен предпринять дополнительные шаги для верификации несуществования точного соответствия wildcard для данного запроса.

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

4.4. Аутентифицированный отказ существования

Распознаватель может использовать аутентифицированные NSEC RRs для проверки того, присутствует ли RRset в подписанной зоне. Безопасный сервер имен должен автоматически включить любые необходимые NSEC RRs для подписанных зон в свои отклики безопасным распознавателям.

Отказ существования определяется следующими правилами:

Чтобы проверить отсутствие RRset, распознаватель должен быть способен верифицировать как то, что нет запрошенного RRset, так и соответствующего RRset для wildcard. Реализация этого может потребовать больше чем одного NSEC RRset для зоны. Если полного набора необходимых NSEC RRsets в отклике нет (возможно из-за отбрасывания сообщения), тогда безопасный распознаватель должен послать запрос повторно, для того чтобы получить полный набор необходимых NSEC RR, чтобы верифицировать отсутствие существования запрошенного RRset.

Так как валидация NSEC RR доказывает существование, как самой ресурсной записи, так и соответствующей ей RRSIG RR, валидатор должен игнорировать установки бит NSEC и RRSIG в NSEC RR.

5.5. Поведение распознавателя, когда подписи некорректны

Если по какой-то причине ни одна из RRSIGs не может быть верифицирована, отклик должен рассматриваться как плохой. Если валидация была выполнена при обслуживании рекурсивного запроса сервер имен должен прислать клиенту RCODE 2. Однако он должен прислать полный отклик, если и только если исходный запрос имел бит CD=1.

Безопасность DNS (DNSSEC). Хэшированное аутентифицированное отрицание существования (RFC-5155)

DNSSEC специфицирует расположение двух новых типов RR, NSEC и DS, которые могут помещаться на родительской стороне границы зоны (т.е., в точке делегирования). Это является исключением для общего запрета размещения данных в родительской зоне у границы.

Чтобы подписать зону администратор генерирует один или более пар ключей публичный/секретный и использует секретный ключ(и) для подписания авторизованных RRsets в зоне. Для каждого секретного ключа, использованного для формирования RRSIG RRs в зоне, зона должна включать запись DNSKEY RR, содержащую соответствующий общедоступный ключ. Зонный ключ DNSKEY RR должен иметь установленный бит зоны поля флаги RDATA. Общедоступные ключи, ассоциированные с другими DNS-операциями, могут записываться в DNSKEY RRs, которые не помечены как зонные ключи, но не должны использоваться для верификации RRSIGs.

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

Безопасные расширения протокола DNS содержат ресурсные записи NSEC RR, чтобы обеспечить аутентифицированный отказ существования. Хотя NSEC RR отвечает требованиям аутентифицированного отказа существования, это позволяет пронумеровать содержимое зоны. Нумерация разрешается за счет набора записей NSEC, которые существуют внутри подписанной зоны. Рекорд NSEC содержит два имени, которые канонически упорядочены, для того чтобы показать, что ничего не существует между этими именами. Полный набор записей NSEC содержит все имена зоны.

Нумерованная зона может использоваться, например, в качестве вероятного e-mail адреса для рассылки SPAM, или в качестве ключа для множественных WHOIS-запросов, чтобы выявить регистрационные данные, которые следует защищать. Многие узлы запрещают копирование их зонных данных.

1. Ресурсные записи NSEC3

Ресурсная запись NSEC3 (RR) обеспечивает аутентифицированный отказ существования для набора ресурсных записей DNS (RRSet). В NSEC3 RR перечисляются типы RR, которые присутствуют для оригинального имени владельца NSEC3 RR. В нее включено хэшированное имя следующего владельца. Полный набор NSEC3 RRs в зоне индицирует, какие RRSets существуют для имени исходного владельца RR и образует цепочку хэшированных имен владельца в зоне. Эта информация используется для получения аутентифицированного отказа существования для DNS данных. Чтобы осуществить защиту против зонной нумерации, имена владельцев в NSEC3 RR являются криптографическими хэшами исходных имен владельцев, добавленными в виде метки спереди к имени зоны. NSEC3 RR индицирует, какая хэш-функция используется при формировании хэша, какой применен двоичный код перемешивания (salt) и сколько итераций хэш-функции осуществлено над исходным именем владельца.

Хэшированные имена владельца неподписанных делегирований могут быть исключены из цепочки. NSEC3 RR, чья область покрывает хэш имени владельца или следующего соседа неподписанного делегирования считается записью Opt-Out NSEC3 RR и выделяется присутствием флага. Имя владельца для NSEC3 RR закодировано base32.

Тип ресурсной записи NSEC3 RR равен 50. Формат NSEC3 RR RDATA не зависит от класса.

Класс должен быть тем же, что и класс исходного имени владельца. Запись NSEC3 RR должна иметь то же значение TTL, что и в поле SOA минимальной величины TTL.

1.1. Поля RDATA

1.1.1. Хэш алгоритм

Поле алгоритма хэша идентифицирует криптографический алгоритм, использованный при формировании хэша.

1.1.2. Флаги

Поле флаги содержит 8 бит флагов, которые могут использоваться для индикации различной обработки. Все неопределенные флаги должны равняться нулю. В данной спецификации определен только флаг Opt-Out.

1.1.2.1. Флаг Opt-Out

Если флаг Opt-Out=1, запись NSEC3 покрывает нуль или более неподписанных делегирований. Если флаг Opt-Out=0, запись NSEC3 не покрывает неподписанных делегирований.

Флаг Opt-Out индицирует, может ли запись NSEC3 RR покрывать неподписанные делегирования. Это младший бит поля флаги.

1.1.3. Итерации

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

1.1.4. Длина псевдослучайного кода (salt)

Поле длины псевдослучайного кода определяет длину кода salt в октетах, обычно длина лежит в диапазоне от 0 до 255.

1.1.5. Псевдослучайный код (salt)

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

1.1.6. Длина хэша

Поле длина хэша определяет длину поля следующего хэшированного имени владельца (Next Hashed имя владельца), его значение лежит в пределах от 1 до 255 октетов.

1.1.7. Следующее хэшированное имя пользователя

Поле Следующее хэшированное имя владельца содержит следующее хэшированное имя владельца, размещенное в хэш-порядке. Эта величина имеет двоичный формат. В данном упорядоченном наборе всех хэшированных имен владельцев, поле Следующее хэшированное имя пользователя содержит хэш-имя владельца, которое следует за именем, заданным в NSEC3 RR. Значение поля Следующее хэшированное имя пользователя в последней записи NSEC3 RR зоны является тем же самым хэш-именем владельца, что содержится в первой записи NSEC3 RR. Заметим, что в отличие от имени владельца NSEC3 RR, значение этого поля не содержит прикрепленного к нему имени зоны.

1.1.8. Карта битов типа

Поле типа бит-карты идентифицирует типы RRSet, которые существуют в исходном имени владельца записи NSEC3 RR.

1.2. NSEC3 RDATA Wire Format

RDATA записи NSEC3 RR показан ниже:

Рис. 5.

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

Длина хэша характеризуется октетом без знака. Длина хэша определяет длину поля следующее хэш-имя владельца в октетах. Поле Следующее хэшированное имя пользователя кодируется в base32, в отличие от имени владельца в NSEC3 RR, оно не содержит в себе имени зоны.

1.2.1. Кодирование карты битов типа

Кодирование поля типа бит-карт идентично используемому в NSEC RR, как это описано в [RFC4034].

Пространство типов RR разделено на 256 блоков-окон, каждый из которых характеризуется младшими 8 битами 16-битового пространства типов RR. Каждый блок, который имеет по крайней мере один активный тип RR, кодируется с использованием одного октета номера окна (от 0 до 255), однооктетная длина бит-карты (от 1 до 32) указывает число октетов, использованных для бит-карты блока-окна (256 бит). Блоки присутствуют в NSEC3 RR RDATA и располагаются по возрастанию номеров. Поле типа бит-карты = ( Номер блока окна | длина бит-карты | бит-карта ), где символ "|" означает конкатенацию. Каждая бит-карта кодирует 8 младших бит типа RR в пределах блока-окна в сетевом порядке. Первым является бит 0. Для блока-окна 0, бит 1 соответствует типу RR 1 (A), бит 2 соответствует типу RR 2 (NS), и т.д.. Для блока-окна 1, бит 1 соответствует типу RR 257, бит 2 типу RR 258. Если бит равен 1, он указывает, что RRSet этот тип присутствует в NSEC3 RR для исходного имени владельца. Если бит равен нулю, это указывает на то, что RRSet этого типа в NSEC3 RR для исходного имени владельца отсутствует.

Так как бит 0 в блок-окне относится к несуществующему типу RR 0, он должен быть установлен равным 0. После верификации, валидатор должен игнорировать значение бита 0 в блок-окне 0.

1.3. Формат презентации

Формат презентации RDATA характеризуется следующим образом:

2. Ресурсная запись NSEC3PARAM

NSEC3PARAM RR содержит параметры NSEC3 (алгоритм хэша, флаги, итерации и salt), необходимые авторизованному серверу для вычисления хэшированных имен владельца. Присутствие NSEC3PARAM RR в вершине зоны указывает, что специфицированные параметры могут быть использованы авторизованными серверами для выбора соответствующего набора записей NSEC3 для негативных откликов. NSEC3PARAM RR не используется валидаторами и распознавателями.

Если NSEC3PARAM RR присутствует в вершине зоны с полем флаги равным нулю, тогда должно быть NSEC3 RR, использующее идентичные параметры хэш алгоритма, итераций и salt для всех хэшированных имен владельца в зоне. Т.е., зона должна содержать полный набор записей NSEC3 с идентичными параметрами хэш алгоритма, итераций и salt.

Имя владельца для NSEC3PARAM RR является именем вершины зоны. Значение типа для NSEC3PARAM RR равно 51. Формат NSEC3PARAM RR RDATA не зависит от класса.

2.1. Поля RDATA

RDATA для этого RR копирует первые четыре поля в NSEC3 RR.

2.1.1. Хэш-алгоритм

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

2.1.2. Поля флагов

Флаг Opt-Out не используется и обнуляется. Все остальные флаги зарезервированы на будущее, и также должны равняться нулю.

2.1.3. Итерации

Поле итерации определяет число дополнительных циклов выполнения операции хэширования. Его приемлемое значение то же самое, что и для поля в NSEC3 RR.

2.1.4. Длина псевдослучайного кода (salt)

Поле длина salt определяет длину salt в октетах, и лежит в диапазоне от 0 до 255.

2.1.5. Псевдослучайный код (salt)

Поле Salt добавляется к исходному имени владельца до хэширования.

2.2. NSEC3PARAM RDATA Wire Format

Рис. 6.

Поля хэш алгоритма и флаги являются однооктетными. Поле итерации содержит 16-битовое целое число без знака, первым следует старший бит. Длина Salt характеризуется одним октетом без знака.

2.3. Формат презентации

Формат презентации RDATA описан ниже:

3. Вычисление хэша

Вычисление хэша использует три поля NSEC3 RDATA: Алгоритм хэша, Salt и итерации. Определим H(x) как хэш от x, используя алгоритм хэша, выбранный NSEC3 RR, пусть k число итераций, а || означает конкатенацию. Определим:

IH(salt, x, 0) = H(x || salt), и
IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0

Затем вычисляем хэш имени владельца

IH(salt, имя владельца, итерации), где имя владельца записывается в канонической форме, и определяется как:

  1. Имя владельца в развернутом виде (никакой архивации DNS-имени);
  2. Все символы US-ASCII верхнего регистра заменяются соответствующими символами нижнего регистра;
  3. Если имя владельца содержит символьную подмену типа wildcard, имя владельца используется в исходном виде, включая символы "*" (никакой замены символов wildcard);

4. Opt-Out

В данной спецификации, (имеются в виду [RFC4033], [RFC4034] и [RFC4035]), NS RRSets в точках делегирования не подписаны и могут сопровождаться DS RRSet. При бите Opt-Out=0, статус безопасности дочерней зоны определяется присутствием или отсутствием этого DS RRSet, криптографически подтверждаемым подписанным NSEC3 RR для хэшированного имени владельца делегирования. Установка флага Opt-Out модифицирует статус, допуская небезопасное делегирование. Считается, что Opt-Out NSEC3 RR покрывает делегирование, если хэшированное имя владельца делегирования располагается между хэшированным именем владельца NSEC3 RR и следующим хэшированным именем.

Запись Opt-Out NSEC3 RR не декларирует существование или несуществование безопасного делегирования, которое она может покрыть. Это допускает введение или удаление делегирований без повторного вычисления или подписания ресурсных записей в цепочке NSEC3 RR. Однако, записи Opt-Out NSEC3 подтверждают (не)существование других авторизованных RRSets.

Запись Opt-Out NSEC3 RR может иметь то же самое исходное имя владельца, что и небезопасное делегирование. В этом случае, делегирование указывает на небезопасность из-за отсутствия бита DS в типе бит-карты, а подписанная NSEC3 RR подтверждает существование делегирования.

Зоны, использующие Opt-Out, могут содержать смесь записей Opt-Out NSEC3 и non-Opt-Out NSEC3s. Если запись NSEC3 RR не является Opt-Out, не должно существовать каких-либо небезопасных делегирований для хэшированных имен владельца. Если запись является Opt-Out, она должна покрывать только хэшированные имена владельцев или хэшированные следующие имена небезопасных делегирований.

5. Авторизованный сервер

5.1. Подписание зоны

Зоны, использующие NSEC3 должны иметь следующие свойства:

  1. Выбирается хэш-алгоритм и значения salt и число итераций.
  2. Для каждого уникального имени владельца в зоне добавляется NSEC3 RR.
  3. Для каждого RRSet для исходного имени владельца, установить соответствующий бит в поле типа бит-карт.
  4. Если разница в числе меток между вершиной и исходным именем владельца больше 1, необходимо добавить NSEC3 RRs для каждого пустого нетерминального имени между вершиной и исходным именем владельца. Этот процесс может сформировать NSEC3 RRs с дублирующими хэшированными именами владельца. Опционно для детектирования столкновений следует отслеживать исходные имена владельца этих NSEC3 RRs и создавать временные записи NSEC3 для wildcard-столкновений, также, как это делалось на этапе 1 выше.
  5. Отсортировать набор NSEC3 RRs в хэш-порядке.
  6. Комбинируем NSEC3 RRs с идентичными хэшированными именами владельца путем замещения их одним NSEC3 RR с типом бит-карт, состоящим из объединения типов из набора NSEC3 RRs. Если исходное имя владельца было отслежено, тогда столкновение может быть детектировано в процессе комбинирования, так как все соответствующие NSEC3 RRs должны иметь идентичные исходные имена владельца. Отбрасываем временные NSEC3 RRs, если таковые имеются.
  7. Используя значение следующего NSEC3 RR, в каждую NSEC3 RR, вводим следующее хэш-имя владельца. Следующее хэш-имя владельца последней NSEC3 RR в зоне содержит значение хэш-имени владельца первой записи NSEC3 RR (в соответствии с хэш-порядком)
  8. Наконец, добавляем запись NSEC3PARAM с теми же полями хэш-алгоритма, числа итераций и Salt в вершину зоны. Если зафиксировано столкновение хэшей, выбираем новое значение salt, и процесс подписание начинаем сначала.

5.2. Зона обслуживания

Данная спецификация модифицирует DNSSEC-отклики, генерируемые авторизованными серверами. Авторизованный сервер заменяет используемые NSEC RRs в откликах на NSEC3 RRs.

В следующих случаях отклика, записи NSEC, диктуемые DNSSEC [RFC4035], заменяются на NSEC3 RR. Отклики, которые не содержат NSEC RR, остаются в рамках данной спецификации неизменными. Когда присылаются отклики, содержащие несколько записей NSEC3 RR, все они должны использовать идентичные значения кодов хэш-алгоритма, числа итераций и salt.

5.2.1. Проверка ближайшего ограничителя (encloser)

Для многих откликов NSEC3 необходима проверка ближайшего ограничителя. Это проверка того, что некоторый прародитель QNAME является ближайшим ограничителем QNAME.

Это подтверждение состоит из двух разных NSEC3 RRs:

Первая NSEC3 RR предлагает ближайшего разграничителя и показывает, что конкретный разграничитель действительно существует. Вторая NSEC3 RR показывает, что возможный ближайший разграничитель является действительно ближайшим и доказывает, что QNAME (и любой прародитель между и ближайшим разграничителем) не существует. Эти две записи совместно (NSEC3 RR) считаются подтверждением ближайшего разграничителя (closest encloser proof). Например, подтверждение ближайшего разграничителя для несуществующего имени владельца "alpha.beta.gamma.example." может показать, что "gamma.example." является ближайшим ограничителем. Этот отклик будет содержать NSEC3 RR, которая соответствует "gamma.example.", и будет содержать NSEC3 RR, покрывающая "beta.gamma.example." (которое является следующим завершителем имени).

При использовании Opt-Out возможна ситуация, когда нельзя проверить ближайшего завершителя, так как он является сам или составляет часть небезопасного делегирования, покрытого Opt-Out. В этом случае вместо проверки ближайшего завершителя используется ближайший завершитель, который может быть проверен. В этом случае, набор NSEC3 RRs, используемый для этого подтверждения, называется "closest provable encloser proof" (подтверждение ближайшего проверяемого завершителя).

5.2.2. Отклики на ошибку в имени

Чтобы проверить несуществование QNAME, подтверждение ближайшего завершителя и NSEC3 RR, покрывающая (несуществующую) запись wildcard RR для ближайшего завершителя, должны быть включены в отклик. Эта коллекция (вплоть до) трех NSEC3 RRs, подтверждает как то, что QNAME не существует, так и то, что и wildcard, которая бы могла соответствовать QNAME, также не существует.

Например, если "gamma.example." является ближайшим проверяемым завершителем для QNAME, тогда NSEC3 RR, покрывающая "*.gamma.example.", включается в авторизованную секцию отклика.

5.2.3. Отклики на отсутствие данных, QTYPE не является DS

Сервер должен включить в отклик запись NSEC3 RR, которая соответствует QNAME. Эта NSEC3 RR не должна иметь битов, соответствующих QTYPE или CNAME в своем поле типа бит-карт.

5.2.4. Отклики на отсутствие данных, QTYPE является DS

Если имеется NSEC3 RR, которая согласуется с QNAME, сервер должен вернуть ее в отклике. Биты, соответствующие DS и CNAME не должны быть установлены в поле типа бит-карт NSEC3 RR. Если нет NSEC3 RR, согласующихся с QNAME, сервер должен прислать для QNAME подтверждение для ближайшего завершителя. Запись NSEC3, которая покрывает "следующее ближайшее" имя, должна иметь бит Opt-Out=1 (заметим, что это так по определению -- если бит Opt-Out=0, происходит что-то не так). Если сервер является авторизованным для обеих сторон границы зоны при QNAME, сервер должен прислать подтверждение с родительской стороны границы зоны.

5.2.5. Отклики No Data для Wildcard

Если wildcard согласуется с QNAME, но QTYPE отсутствует в этом имени, отклик должен включать в себя подтверждение для ближайшего завершителя (closest encloser proof) для QNAME и должен включать NSEC3 RR, которое согласуется с wildcard. Эта комбинация подтверждает, что сама QNAME отсутствует и что wildcard, которое согласуется с QNAME, не существует. Заметим, что ближайший завершитель для QNAME должен быть непосредственным прародителем wildcard RR (если это не так, тогда что-то не так).

5.2.6. Отклики на Wildcard-ответ

Если wildcard согласуется с QNAME и QTYPE, тогда, в дополнение к развернутому wildcard RRSet в секции ответа отклика, должно быть прислано подтверждение того, что wildcard был корректным. Это подтверждение осуществляется путем доказательства того, что не существует QNAME и что ближайший завершитель QNAME и непосредственный прародитель wildcard тождественны (т.e., расширение wildcard было корректным). В отклик должна быть включена NSEC3 RR, которая покрывает "следующее ближайшее" имя непосредственного прародителя wildcard. Не нужно присылать NSEC3 RR, которое согласуется с ближайшим завершителем, так как существование этого завершителя подтверждено присутствием в отклике развернутого wildcard.

5.2.7. Ссылки на неподписанные субзоны

Если имеется запись NSEC3 RR, которая согласуется с именем делегирования, тогда эта NSEC3 RR должна быть включена в отклик. Бит DS в типе бит-карт NSEC3 RR не должен быть установлен. Если зона является Opt-Out, тогда может не быть NSEC3 RR, согласующейся с делегированием. В этом случае, closest provable encloser proof должен быть включен в отклик. Включенная запись NSEC3 RR, которая покрывает "следующее ближайшее" имя делегирования, должна иметь флаг Opt-Out=1.

5.2.8. Отлики на запросы имен владельца NSEC3

Имена владельцев NSEC3 RRs отсутствуют в цепочке NSEC3 RR также как и другие имена владельца. В результате, каждое имя владельца NSEC3 покрывается другим NSEC3 RR, эффективно опровергая существование NSEC3 RR. Это парадокс, так как существование NSEC3 RR может быть подтверждено ее RRSIG RRSet.

Если выполняются все приведенные ниже условия:

5.2.9. Отклик сервера на столкновение в процессе работы

Если хэш несуществующего QNAME сталкивается с именем владельца существующей NSEC3 RR, тогда сервер не сможет прислать отклик, который подтверждает, что QNAME не существует. В этом случае, сервер должен прислать отклик с RCODE 2 (сбой сервера). Заметим, что для алгоритма хэширования, специфицированном в данном документе, SHA-1, такие столкновения крайне маловероятны.

5.3. Вторичные серверы

Вторичные серверы (и, вероятно, другие объекты) нужны, чтобы надежно определить, какие параметры NSEC3 (т.e., хэш, salt и число итераций) присутствуют в каждом имени владельца, для того чтобы иметь возможность выбрать соответствующий набор NSEC3 RRs для негативного отклика. Это индицируется посредством NSEC3PARAM RR, присутствующей в вершине зоны. Если имеется несколько NSEC3PARAM RRs, то существует несколько корректных цепочек NSEC3. Сервер должен выбрать одну из них, и может использовать любые критерии для реализации этого.

5.4. Зоны, использующие неизвестные хэш-алгоритмы

Зоны, которые подписаны согласно этой спецификации, но используют нераспознанный код алгоритм хэша NSEC3, не могут быть эффективно обслужены. Такие зоны должны отвергаться при загрузке. Серверы должны реагировать откликом с RCODE=2 (отказ сервера) при обработке запросов, которые адресованы таким зонам.

5.5. Динамическое обновление

Зона, подписанная с использованием NSEC3 может воспринимать динамические обновления [RFC2136]. Однако NSEC3 вводит некоторые специальные особенности для динамических обновлений. Добавление и удаление имен в зоне должно учитывать создание и удаление пустых нетерминальных имен.

6. Соображения относительно валидаторов

6.1. Отклики на неизвестные типы хэшей

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

6.2. Верификация NSEC3 RRs (ресурсных записей)

Валидатор должен игнорировать NSEC3 RRs со значением поля флаги, отличным от нуля или 1. Валидатор может обрабатывать отклик, как некорректный, если он содержит записи NSEC3 RRs, которые имеют разные значения для кодов хэш-алгоритма, числа итераций или salt для рассматриваемой зоны.

6.3. Верификация NSEC3 RRs (ресурсных записей)

Для того чтобы верифицировать проверку ближайшего завершителя, валидатор должен найти самое длинное имя, X, такое что

Возможный алгоритм верификации этого доказательства заключается в следующем:

  1. Установить SNAME=QNAME. Приравниваем флаг нулю.
  2. Проверяем, существует ли SNAME:
  3. Отбрасываем в SNAME одну метку слева, переходим к шагу 2. Раз ближайший разграничитель найден, валидатор должен проверить, что NSEC3 RR, которая имеет ближайший разграничитель в качестве исходного имени владельца, находится в правильной зоне. Бит типа DNAME не должен быть установлен, а бит типа NS может быть установлен, если установлен бит типа SOA. Если эти условия не выполнены, это свидетельствует, что атакер использует для фальсификации отказа существования RRs, для которых сервер не является авторизованным.

В последующем описании, фраза "ближайший (provable) encloser proof for X" означает, что вышеприведенный алгоритм (или эквивалентный алгоритм) доказывает, что X не существует, подтверждая, что прародитель X является его ближайшим разграничителем.

6.4. Валидация откликов на ошибку имени

Валидатор должен верифицировать, что существует доказательство существования ближайшего разграничителя (closest encloser proof) для QNAME, присутствующего в отклике и что существует NSEC3 RR, которая покрывает wildcard для ближайшего завершителя (т.e., имя, сформированное с помощью звездочки-метки, введенной перед именем ближайшего разграничителя).

6.5. Валидация откликов No Data, QTYPE не является DS

Валидатор должен верифицировать то, что NSEC3 RR, которое соответствует QNAME, существует и что типы QTYPE и CNAME не установлены в ее поле типа бит-карт. Заметим, что этот тест покрывает также случай, где существует NSEC3 RR, так как она соответствует пустому нетерминальному имени, в таком случае NSEC3 RR будет иметь пустое поле типа бит-карт.

6.6. Валидация откликов No Data, QTYPE является DS

Если имеется запись NSEC3 RR, которая согласуется с QNAME, присутствующим в отклике, тогда NSEC3 RR должна не иметь битов, соответствующих набору DS и CNAME в поле типа бит-карт. Если такой записи NSEC3 нет, тогда валидатор должен проверить, что проверяемый ближайший разграничитель для QNAME присутствует в отклике, и что NSEC3 RR, которая покрывает "следующее ближайшее" имя, имеет бит Opt-Out=1.

6.7. Валидация откликов No Data для Wildcard

Валидатор должен верифицировать доказательство наличия ближайшего разграничителя для QNAME и должен выявить соответствие NSEC3 RR wildcard имени, присутствующей в отклике. Имя формируется путем добавления префикса в виде метки-звездочки к имени ближайшего разграничителя. Более того, биты, соответствующие как QTYPE, так и CNAME должны равняться нулю в wildcard, соответствующей NSEC3 RR.

6.8. Валидация откликов для ответов с Wildcard

Верифицированный ответ RRSet wildcard в отклике предоставляет валидатору (кандидата) на ближайшего разграничителя для QNAME. Этот ближайший разграничитель является непосредственным прародителем для генерации wildcard. Валидаторы должны верифицировать то, что существует NSEC3 RR, которая покрывает "следующее ближайшее" имя для QNAME, присутствующего в отклике. Это доказывает, что само QNAME не существует и что при формировании отклика, была использована корректная подстановка wildcard.

6.9. Валидация ссылок на неподписанные субзоны

Имя делегирования в ссылке является именем владельца NS RRSet, который присутствует в авторизованной секции отклика на ссылку. Если в отклике имеется NSEC3 RR, которая согласуется с именем делегирования, тогда валидатор должен гарантировать, что бит NS=1 и что бит DS=0 в поле типа бит-карт NSEC3 RR. Валидатор должен также гарантировать, что NSEC3 RR принадлежит корректной (т.e., родительской) зоне. Это делается за счет гарантии того, что бит SOA=0 в поле типа бит-карт этого NSEC3 RR. Заметим, что присутствие бита NS предполагает отсутствие бита DNAME, так что нет нужды в проверке бита DNAME в поле типа бит-карт NSEC3 RR. Если не существует NSEC3 RR, которая согласуется с именем делегирования, тогда валидатор должен верифицировать ближайший проверяемый ограничитель для имени делегирования. Валидатор должен верифицировать, что бит Opt-Out=1 в NSEC3 RR, которая покрывает "следующее ближайшее" имя для имени делегирования.

7. Соображения по распознавателю

7.1. Кэширование ресурсных записей NSEC

Кэширующие распознаватели должны быть способны находить подходящие NSEC3 RRs, формируются отклики, которые их содержат. В DNSSEC [RFC4035], во многих случаях можно найти корректную NSEC RR, чтобы прислать в отклике на имя (напр., когда возвращается ссылка, NSEC RR будет всегда иметь то же имя владельца что и делегирование).

Использование AD-бита

Бит AD, как это определено в [RFC4035], не должен устанавливаться, когда возвращаемый отклик содержит имя ближайшего разграничителя, в котором NSEC3 RR, покрывающая "следующее ближайшее" имя, имеет бит Opt-Out=1. Это правило базируется на том, что имя ближайшего разграничителя на самом деле подтверждает: имена, которые бы покрывались Opt-Out NSEC3 RR, могут или не могут существовать как безопасные делегирования. По существу, не все данные в откликах, содержащих подтверждения существования ближайшего ограничителя, являются криптографически верифицированными, так что бит AD не может быть установлен.

8. Специальные соображения

8.1. Ограничения на длину имени домена

Зоны, подписанные в соответствии с данными спецификациями, имеют дополнительные ограничения на длину имени. В частности, зоны с именами, которые при преобразовании в хэш имеют имена владельца длиннее 255 октетов (предел, установленный [RFC1035]), не могут использоваться в рамках данной спецификации. Действительная максимальная длина доменного имени в конкретной зоне зависит от длины имени зоны и используемой хэш-функции. Например, SHA-1 выдает хэш длиной 160 бит. Кодировка 60 бит в base-32 даст в результате 32 символа. Перед этими 32 символами размещается метка, которая представляет собой имя зоны. Метка содержит однооктетное поле длины. Максимальная длина имени зоны в случае SHA-1, равна 222 октетам (255 - 33).

8.2. DNAME в вершине зоны

Спецификация DNAME в разделе 3 [RFC2672] имеет ограничение для ’не потомков’. Если имеется запись DNAME RR для узла N, не должно быть данных для любого наследника N. Если N является вершиной зоны, у наследников N будут присутствовать типы NSEC3 и RRSIG. Данная спецификация обновляет спецификацию DNAME, чтобы разрешить существование типов NSEC3 и RRSIG у наследников, несмотря на существование DNAME в вершине.

8.3. Итерации

Установка числа используемых итераций позволяет владельцу зоны выбрать цену вычисления хэша, и следовательно генерировании словаря. Заметим, что это отличается от воздействия salt, которое предотвращает использование одного предварительно вычисленного словаря на все время. Очевидно, что число итераций влияет также на стоимость подписания и обслуживания зоны, на стоимость валидаторов и верификации откликов из зоны. Мы, следовательно, фиксируем верхний предел числа итераций. Пределы базируются на размере наименьшего ключа, используемого для подписания зоны, округленного до ближайшего табличного значения. Владелец зоны не должен использовать значения выше того, что приведено в таблице 1 ниже. Распознаватель может обрабатывать отклик с большим значением, как небезопасныe, после того как валидатор проверил подпись NSEC3 RR и убедился в ее корректности.

Таблица 1

Размер ключаЧисло итераций
1024150
2048500
40962,500

Эта таблица базируется на аппроксимации отношения между стоимостью вычисления SHA-1 и стоимостью RSA-верификации для ключей размера 1024 бита (150 к 1), 2048 бит (500 к 1) и 4096 бит (2500 к 1). Отношение между вычислением SHA-1 и DSA-верификацией (верификация электронной подписи) выше (1500 к 1 для ключей с размером 1024). Более высокие значения числа итераций ухудшают рабочие характеристики, в то время как DSA-верификация уже дороже, чем RSA для тех же длин ключей. Следовательно, значения в таблице должны использоваться независимо от алгоритма работы с ключами.

8.4. Перенос подписанной зоны от NSEC в NSEC3

При переносе уже подписанной и верифицированной зоны следует заботиться о том, чтобы в процессе выполнения предотвратить неудачи валидации клиента. Базовыми процедурами при этом являются:

  1. Перенос всех DNSKEYs в DNSKEYs, используя мнемонику алгоритмов, описанную выше. Действительный метод для надежного и безопасного изменения DNSKEY RRSet зоны, находится за пределами данной спецификации. Однако конечный результат должен быть таким, что все DS RRs в родительской зоне использовали специфицированные мнемоники алгоритмов. После завершения этого переноса все NSEC3-клиенты, незнакомые с ситуацией, рассматривают зону, как небезопасную. В это время авторизованный сервер продолжает присылать отрицательные и wildcard-отклики, которые содержат NSEC RRs.
  2. Добавить в зону подписанные NSEC3 RRs, последовательно или все сразу. При последовательном добавлении последним добавленным RRSet должен быть NSEC3PARAM RRSet.
  3. При добавлении NSEC3PARAM RRSet, сервер переключается к обслуживанию отрицательных и wildcard-откликов с NSEC3 RRs в соответствии с данной спецификацией.
  4. Удаляются NSEC RRs либо последовательно, либо все сразу.

8.5. Перенос подписанной зоны от NSEC3 в NSEC

Для безопасного перехода обратно в подписанную зону DNSSEC [RFC4035], процедуры выполняются в обратном порядке:

  1. Добавляются NSEC RRs последовательно или все сразу.
  2. Удаляются NSEC3PARAM RRSet. Это сигнализирует серверу использовать NSEC RRs для негативных и wildcard-откликов.
  3. Удаляются NSEC3 RRs последовательно или все сразу.
  4. Перенос всех идентификаторов алгоритмов из DNSKEYs в DNSSEC. После завершения переноса все NSEC3-клиенты будут рассматривать зону, как безопасную.

9. Соображения IANA

Хотя NSEC3 и NSEC3PARAM RR форматы включают хэш-алгоритм, данный документ не определяет конкретный механизм для безопасного перехода от одного NSEC3 хэш-алгоритма к другому. При спецификации нового хэш-алгоритма для NSEC3, должен быть определен также механизм такого перехода.

Этот документ создает новый IANA регистр для флагов NSEC3. Этот регистр имеет имя "DNSSEC NSEC3 Flags". В настоящее время определено следующее:

Рис. 8.

Бит 7 является флагом Opt-Out.
Биты 0 - 6 могут использоваться для приложений.
Назначение дополнительных NSEC3-флагов в этот регистр требует выполнения процедур стандартизации IETF [RFC2434].

Этот документ создает новый IANA регистр для флагов NSEC3PARAM. Этот регистр имеет имя "DNSSEC NSEC3PARAM Flags". На текущий момент фиксировано следующее:

Рис. 9.

Бит 7 зарезервирован и должен быть = 0.
Биты 0 - 6 могут использоваться для приложений.
Назначение дополнительных NSEC3PARAM-флагов в этот регистр требует выполнения процедур стандартизации IETF [RFC2434].

Наконец, Этот документ создает новый IANA регистр для NSEC3 хэш-алгоритмов. Этот регистр имеет имя "DNSSEC NSEC3 Hash Algorithms". Текущее содержимое этого регистра представлено ниже:

0 зарезервирован.
1 соответствует SHA-1.
2-255 Доступно для присвоения.

10. Соображения безопасности

10.1. Соображения хэширования

10.1.1. Атаки каталога

Записи NSEC3 RRs по-прежнему уязвимы для каталожных атак (т.e., атакер извлекает все NSEC3 RRs, затем вычисляет хэши всех вероятных имен доменов, сравнивая с хэшами, обнаруженными в NSEC3 RRs, и, таким образом, осуществляя нумерацию зоны). Это существенно более дорогая процедура, чем нумерация исходных записей NSEC RRs, и в любом случае, такая атака может использоваться непосредственно против самого сервера, осуществляющего запросы для наиболее вероятных имен. Затраты на эту атаку могут варьироваться путем выбора числа итераций в NSEC3 RR.

Зоны также уязвимы для атак с предварительно формируемым словарем -- т.е., списком хэшей для всех вероятных имен, вычисленных заранее, далее NSEC3 RR периодически сканируются и производится сравнение с предварительно вычисленными хэшами. Эта атака предотвращается регулярным изменением salt.

Код salt должен иметь, как минимум, 64 бита и быть непредсказуемым, так что атакер не может предугадать значение salt и вычислить следующий набор словарей.

10.1.2. Столкновения

Может случится столкновения хэшей между QNAME и именем владельца. Когда это случится, будет невозможно подтвердить несуществование QNAME, для которого произошло столкновение. Однако с SHA-1, это крайне маловероятно (по порядку 1 к 2160). Заметим, что DNSSEC полагается на предположение, что криптографическая хэш-функция является еще одним барьером против атаки, так как эти хэш-функции используются для генерации и валидации подписей и DS RRs.

10.1.3. Использование большого числа итераций

Так как валидаторы должны обрабатывать отклики, содержащие NSEC3 RRs с высокими значениями числа итераций, как небезопасные, присутствие в зоне хотя бы одной подписанной NSEC3 RR с высоким значением числа итераций предоставляет атакеру шанс использовать атаку с понижением уровня защищенности. Атака просто удаляет любые существующие NSEC3 RRs из отклика, и заменяет или добавляет в отклик одну (или несколько) NSEC3 RR, которая использует высокое значение числа итераций. Валидаторы будут вынуждены считать отклик небезопасным. Эта атака будет эффективной, если выполняются следующие условия:

10.2. Соображения Opt-Out

Флаг Opt-Out (O) позволяет для неподписанных имен, существовать в форме делегирования к неподписанным зонам в пределах подписанной зоны. Все неподписанные имена по определению являются небезопасными, и их корректность или существование не может быть криптографически подтверждена. Вообще:

Заметим, что с или без Opt-Out, небезопасное делегирование может быть изменено атакером недетектируемым образом. Из-за этого, главное отличие в безопасности, когда используется Opt-Out, заключается в потере возможности проверить, существует или нет небезопасное делегирование в области действия Opt-Out NSEC3 RR.

В частности, это означает, что вредоносный объект может ввести или удалить RR с неподписанными именами. Эти записи обычно являются NS RRs, но сюда относятся также подписанные расширения wildcard (в то время как wildcard RR сама подписана, его расширенное имя является неподписанным). Заметим, что возможность добавления делегирования функционально эквивалентна добавлению RR любого типа.

В этой связи рекомендуется использовать Opt-Out достаточно осторожно или не использовать вовсе.

11. Ссылки

  1. [RFC1034] Mockapetris, P., "Domain names - concepts и facilities", STD 13, RFC 1034, November 1987.
  2. [RFC1035] Mockapetris, P., "Domain names - implementation и specification", STD 13, RFC 1035, November 1987.
  3. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
  4. [RFC1982] Elz, R. и R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
  5. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  6. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., и J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
  7. [RFC2181] Elz, R. и R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
  8. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
  9. [RFC2434] Narten, T. и H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
  10. [RFC2460] Deering, S. и R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  11. [RFC2536] Eastlake 3rd, D., "DSA KEYs и SIGs in the Domain Name System (DNS)", RFC 2536, March 1999.
  12. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
  13. [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.
  14. [RFC2929] Eastlake, D., Brunner-Williams, E., и B. Manning, "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, September 2000.
  15. [RFC2931] Eastlake 3rd, D., "DNS Request и Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.
  16. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
  17. [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs и RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001.
  18. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.
  19. [RFC3226] Gudmundsson, O., "DNSSEC и IPv6 A6 aware server/resolver message size requirements", RFC 3226, December 2001.
  20. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
  21. [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.
  22. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004..
  23. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., и S. Rose, "DNS Security Introduction и Requirements", RFC 4033, March 2005.
  24. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., и S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
  25. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., и S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
  26. [RFC4648] Josefsson, S., "The Base16, Base32, и Base64 Data Encodings", RFC 4648, October 2006.

Приложения

Безопасный распознаватель DNSSEC или сервер имен должны использовать все обязательные алгоритмы (RFC-4034).

DNSKEY, RRSIG и DS RRs используют для идентификации применяемых алгоритмов безопасности 8-битовые коды. Эти коды записаны в поле "Номер алгоритма" ресурсной записи RDATA.

A.1. Типы алгоритмов DNSSEC

ЗначениеАлгоритм (Мнемоника)Подпись
зоны
СсылкаСтатус
0Резерв   
1RSA/MD5 [RSAMD5]n[RFC2537]Не рекоменд.
2Diffie-Hellman [DH]n[RFC2539]-
3DSA/SHA-1 [DSA]y[RFC2536]Опцион
4Elliptic Curve [ECC] TBA-
5RSA/SHA-1 [RSASHA1]y[RFC3110]Обязательный
252Indirect [INDIRECT] y -
253Private [PRIVATEDNS]yсм. нижеОпцион
254Private [PRIVATEOID]yсм. нижеОпцион
255Зарезерв.   

6 - 251 предназначены для распределения в рамках стандартов IETF.

A.2. Типы дайджестов DNSSEC

Поле "Тип дайджеста" в DS RR идентифицирует криптографический алгоритм дайджеста, используемый ресурсной записью. Ниже представлена таблица типов алгоритмов.

ЗначениеАлгоритмСтатус
0Резерв-
1SHA-1Обязательный
2-255Не распределено-

Смотри Tools, services emerge for enterprise DNSSEC adoption

См. статью Robert Westervelt, "Tools, services emerge for enterprise DNSSEC adoption".


   UP: 4.4.12 DNS (структура, обработка запросов, ресурсные записи)
    Next: 4.4.12.2 Протокол динамического конфигурирования ЭВМ DHCP (и NAT/PAT)