RFC 4033 | DNS безопасность | Введение и требования

Аннотация

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

Скачать оригинальный документ на английском языке RFC 4033 PDF

1. Введение
2. Определения важных терминов DNSSEC
3. Услуги, предоставляемые DNS-безопасностью
3.1. Аутентификация источника данных и целостность данных
3.2. Аутентификация имени и типа несуществования
4. Услуги, не предоставляемые DNS-безопасностью
5. Сфера действия набора документов DNSSEC и проблемы с последним прыжком
6. Решения соображений
7. Решения для заглушки
8. Зональные соображения
8.1. Значения TTL и период действия RRSIG
8.2. Новые проблемы временной зависимости для зон
9. Соображения сервера имен
10. Семейство документов безопасности DNS
11. Соображения IANA
12. Вопросы безопасности
13. Благодарности
14. Ссылки
14.1. Нормативные ссылки
14.2. Информационные ссылки
Адреса авторов
Заявление об авторском праве

Статус этой заметки

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

Уведомление об авторских правах

1. Введение

В этом документе представлены расширения безопасности системы доменных имен (DNSSEC). Этот документ и два сопутствующих документа ([RFC4034] и [RFC4035]) обновляют, уточняют и уточняют расширения безопасности, определенные в [RFC2535] и его предшественниках. Эти расширения безопасности состоят из набора новых типов записей ресурсов и модификаций существующего протокола DNS ([RFC1035]). Новые записи и модификации протокола не полностью описаны в этом документе, но описаны в семействе документов, описанных в разделе 10. В разделах 3 и 4 более подробно описаны возможности и ограничения расширений безопасности. Раздел 5 обсуждает сферу действия набора документов. В разделах 6, 7, 8 и 9 обсуждается влияние этих расширений безопасности на распознаватели, преобразователи-заглушки, зоны и серверы имен.

Этот документ и два сопутствующих ему документа устарели [RFC2535], [RFC3008], [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757] и [RFC3845]. Этот набор документов также обновляет, но не устарел [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225], [RFC3007], [RFC3597] и части [RFC3226], которые имеют дело с DNSSEC.

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

2. Определения важных терминов DNSSEC

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

Цепочка аутентификации (Authentication Chain): чередующаяся последовательность наборов RR наборов открытых ключей DNS (DNSKEY) и RRsets делегирования подписи (DS) образует цепочку подписанных данных, каждая из которых в цепочке ручается за следующую. DNSKEY RR используется для проверки подписи, охватывающей DS RR, и позволяет аутентифицировать DS RR. DS RR содержит хэш другого DNSKEY RR, и этот новый DNSKEY RR аутентифицируется путем сопоставления хэша в DS RR. Эта новая DNSKEY RR, в свою очередь, аутентифицирует другой DNSKEY RRset, и, в свою очередь, некоторая DNSKEY RR в этом наборе может использоваться для аутентификации другой DS RR и т. Д., Пока цепочка окончательно не закончится DNSREY RR, соответствующий закрытый ключ которого подписывает желаемый DNS. данные. Например, корневой DNSKEY RRset может использоваться для аутентификации DS RRset для «примера». Пример.» DS RRset содержит хеш, который соответствует некоторому «примеру». DNSKEY, и соответствующий закрытый ключ этого DNSKEY подписывает «пример». DNSKEY RRset. Закрытые ключи аналоги «примера». DNSKEY RRset подписывает записи данных, такие как «www.example». и DS RR для делегаций, таких как «subzone.example».

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

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

Точка делегирования (Delegation Point): термин, используемый для описания имени на родительской стороне сокращения зоны. То есть точкой делегирования для «foo.example» будет узел foo.example в зоне «example» (в отличие от вершины зоны зоны «foo.example»). См. Также верхушку зоны.

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

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

Не проверяющий средство защиты заглушки с поддержкой безопасности (Non-Validating Security-Aware Stub Resolver): средство распознавания заглушек с поддержкой безопасности, которое доверяет одному или нескольким рекурсивным серверам имен с поддержкой безопасности для выполнения большинства задач, обсуждаемых в этом документе, от его имени. В частности, не проверяющий распознаватель заглушки с поддержкой безопасности — это объект, который отправляет DNS-запросы, принимает ответы DNS и способен устанавливать надлежащим образом защищенный канал к рекурсивному серверу имен с поддержкой безопасности, который будет предоставлять эти услуги от имени распознаватель заглушки с поддержкой безопасности. См. Также распознаватель заглушек с поддержкой безопасности, проверка правильности распознавателя заглушек с учетом безопасности.

Не проверяющий заглушку Resolver (Non-Validating Stub Resolver): менее утомительный термин для не проверяющего распознаватель заглушки с поддержкой безопасности.

Сервер Имен Безопасности С Поддержкой Имен (Security Name-Aware Name Server): объект, действующий в роли сервера имен (определенный в разделе 2.4 [RFC1034]), который понимает расширения безопасности DNS, определенные в этом наборе документов. В частности, сервер имен с поддержкой безопасности — это объект, который принимает запросы DNS, отправляет ответы DNS, поддерживает расширение размера сообщения EDNS0 ([RFC2671]) и бит DO ([RFC3225]), а также поддерживает типы RR и заголовок сообщения. биты, определенные в этом наборе документов.

Рекурсивный сервер имен с защитой (Security-Aware Recursive Name Server): объект, действующий как в роли сервера имен, поддерживающего безопасность, так и в роли распознавателя, учитывающего безопасность. Более громоздкой, но эквивалентной фразой будет «сервер имен с поддержкой безопасности, который предлагает рекурсивный сервис».

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

Безопасности Заглушки Распознавателя (Security-Aware Stub Resolver): объект, выступающий в роли решателя-заглушки (определенный в разделе 5.3.1 [RFC1034]), у которого достаточно понимания расширений безопасности DNS, определенных в этом наборе документов, для предоставления дополнительных услуг, недоступных из не обращающий внимания на безопасность заглушка. Средство распознавания заглушки с поддержкой безопасности может быть «проверяющим» или «не проверяющим», в зависимости от того, пытается ли средство распознавания заглушки проверить подписи DNSSEC самостоятельно или доверяет дружественному серверу имен с поддержкой безопасности. См. Также валидационный решатель, не валидирующий решатель.

Забвение безопасности (Security-Oblivious)<что-нибудь>: <что-нибудь>, которое не «заботится о безопасности».

Зона со знаком (Signed Zone): Зона, RRsets которой подписаны и которая содержит правильно сконструированный DNSKEY, подпись записи ресурса (RRSIG), Next Secure (NSEC) и (необязательно) записи DS.

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

Зона без подписи (Unsigned Zone): зона, которая не подписана.

Проверка защищенного заглушки с поддержкой безопасности (Validating Security-Aware Stub Resolver): распознаватель с защитой, который отправляет запросы в рекурсивном режиме, но выполняет проверку подписи самостоятельно, а не просто слепо доверяет обратному серверу рекурсивных имен с поддержкой безопасности. См. Также распознаватель заглушек с поддержкой безопасности, не проверяющий распознаватель заглушек с поддержкой безопасности.

Валидация заглушки резольвера (Validating Stub Resolver). Менее утомительный термин для проверки распознающего заглушки с учетом безопасности.

Зона Apex (Zone Apex): термин, используемый для описания имени на стороне ребенка в разрезе зоны. Смотрите также пункт делегирования.

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

3. Услуги, предоставляемые DNS-безопасностью

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

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

Эти службы защищают от большинства угроз Системе доменных имен, описанных в [RFC3833]. Пожалуйста, смотрите раздел 12 для обсуждения ограничений этих расширений.

3.1. Аутентификация источника данных и целостность данных

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

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

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

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

Средство распознавания, обеспечивающее безопасность, обычно создает эту цепочку аутентификации от корня иерархии DNS до конечных зон на основе настроенного знания открытого ключа для корня. Локальная политика, однако, может также разрешать распознавателю, осведомленному о безопасности, использовать один или несколько настроенных открытых ключей (или хэшей открытых ключей), отличных от корневого открытого ключа, может не предоставлять сконфигурированные знания корневого открытого ключа или может препятствовать отказаться от использования определенных открытых ключей по произвольным причинам, даже если эти открытые ключи должным образом подписаны проверяемыми подписями. DNSSEC предоставляет механизмы, с помощью которых распознаватель безопасности может определять, является ли подпись RRset «действительной» в значении DNSSEC. В конечном счете, однако, аутентификация как ключей DNS, так и данных является вопросом локальной политики, которая может расширять или даже переопределять расширения протокола, определенные в этом наборе документов. См. Раздел 5 для дальнейшего обсуждения.

3.2. Аутентификация имени и типа несуществования

Механизм безопасности, описанный в разделе 3.1, предоставляет только способ подписать существующие наборы RR в зоне. Проблема предоставления отрицательных ответов с одинаковым уровнем аутентификации и целостности требует использования другого нового типа записи ресурса, записи NSEC. Запись NSEC позволяет распознавателю, осведомленному о безопасности, аутентифицировать отрицательный ответ для несуществования имени или типа с теми же механизмами, которые используются для аутентификации других ответов DNS. Использование записей NSEC требует канонического представления и упорядочения доменных имен в зонах. Цепочки записей NSEC явно описывают промежутки, или «пустое пространство», между доменными именами в зоне и перечисляют типы наборов RR, присутствующих в существующих именах. Каждая запись NSEC подписывается и аутентифицируется с использованием механизмов, описанных в разделе 3.1.

4. Услуги, не предоставляемые DNS-безопасностью

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

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

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

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

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

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

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

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

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

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

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

6. Решения соображений

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

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

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

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

7. Решения для заглушки

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

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

Средство распознавания заглушек с поддержкой безопасности, которое доверяет им как свои рекурсивные серверы имен, так и свой канал связи, может решить проверить настройку бита Authenticated Data (AD) в заголовке сообщения полученных им ответных сообщений. Средство распознавания заглушки может использовать этот бит флага в качестве подсказки, чтобы выяснить, смог ли рекурсивный сервер имен проверить подписи для всех данных в разделах «Ответ» и «Полномочия» ответа.

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

8. Зональные соображения

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

8.1. Значения TTL и период действия RRSIG

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

С другой стороны, поля ввода и истечения срока действия в RRIG RRIG ([RFC4034]) указывают период времени, в течение которого подпись может использоваться для проверки покрытого RRset. Подписи, связанные с данными подписанной зоны, действительны только в течение периода времени, указанного этими полями в рассматриваемых RRIG RR. Значения TTL не могут продлить срок действия подписанных наборов RR в кэше распознавателя, но распознаватель может использовать время, оставшееся до истечения периода действия подписи подписанного набора RR, в качестве верхней границы для TTL подписанного набора RR и связанных с ним RRSIG RR. в кеше резольвера.

8.2. Новые проблемы временной зависимости для зон

Информация в подписанной зоне имеет временную зависимость, которой не было в исходном протоколе DNS. Подписанная зона требует регулярного обслуживания, чтобы гарантировать, что каждый RRset в зоне имеет текущий действительный RRIG RR. Период действия подписи RRIG RRIG представляет собой интервал, в течение которого подпись для одного конкретного подписанного RRset может считаться действительной, и подписи разных RRset в зоне могут истекать в разное время. Повторная подпись одного или нескольких наборов RR в зоне изменит один или несколько записей RRSIG, что, в свою очередь, потребует увеличения серийного номера SOA зоны, чтобы указать, что произошло изменение зоны, и повторной подписи самого набора RR SOA. Таким образом, повторная подпись любого набора RR в зоне может также инициировать сообщения DNS NOTIFY и операции передачи зоны.

9. Соображения сервера имен

Сервер имен с поддержкой безопасности должен включать соответствующие записи DNSSEC (RRSIG, DNSKEY, DS и NSEC) во все ответы на запросы от распознавателей, которые сигнализировали о своей готовности получать такие записи с помощью бита DO в заголовке EDNS, субъект ограничения размера сообщения. Поскольку включение этих DNREC RR может легко вызвать усечение сообщений UDP и откат к TCP, сервер имен с поддержкой безопасности должен также поддерживать EDNS-механизм «полезной нагрузки UDP отправителя».

Если возможно, закрытая половина каждой пары ключей DNSSEC должна храниться в автономном режиме, но это не будет возможно для зоны, для которой включено динамическое обновление DNS. В случае динамического обновления первичный главный сервер для зоны должен будет повторно подписать зону, когда она обновляется, поэтому закрытый ключ, соответствующий ключу подписи зоны, должен оставаться в сети. Это пример ситуации, в которой может быть полезна возможность разделения набора DNSKEY RRset на ключ (ы) подписи зоны и ключ (ы) подписи ключа, поскольку ключ (ы) подписи ключа в таком случае все еще может быть хранится в автономном режиме и может иметь более длительный срок полезного использования, чем ключи подписи зоны.

Само по себе DNSSEC недостаточно для защиты целостности всей зоны во время операций передачи зоны, поскольку даже подписанная зона содержит некоторые неподписанные неавторизованные данные, если у зоны есть дочерние элементы. Поэтому операции обслуживания зоны потребуют некоторых дополнительных механизмов (скорее всего, некоторой формы защиты канала, такой как TSIG, SIG (0) или IPsec).

10. Семейство документов безопасности DNS

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

«Набор документов протокола DNSSEC» относится к трем документам, которые составляют ядро расширений безопасности DNS:

Введение и требования безопасности DNS (этот документ)
Ресурсные записи для расширений безопасности DNS [RFC4034]
Модификации протокола для расширений безопасности DNS [RFC4035]

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

Набор документов «Спецификация алгоритма цифровой подписи» относится к группе документов, которые описывают, как должны быть реализованы конкретные алгоритмы цифровой подписи для соответствия формату записи ресурса DNSSEC. Каждый документ в этом наборе имеет дело с определенным алгоритмом цифровой подписи. Пожалуйста, смотрите приложение «Алгоритм DNSSEC и типы дайджеста» в [RFC4034] для списка алгоритмов, которые были определены, когда была написана эта базовая спецификация.

Набор документов «Протокол аутентификации транзакций» относится к группе документов, которые касаются аутентификации сообщений DNS, включая установление и проверку секретного ключа. Хотя эта группа не является строго частью спецификации DNSSEC, как определено в этом наборе документов, она отмечена из-за ее связи с DNSSEC.

Окончательный набор документов «Новое использование безопасности» относится к документам, которые стремятся использовать предлагаемые расширения безопасности DNS для других целей, связанных с безопасностью. DNSSEC не обеспечивает никакой прямой безопасности для этих новых применений, но может использоваться для их поддержки. К этой категории относятся документы, описывающие использование DNS при хранении и распространении сертификатов ([RFC2538]).

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

Этот обзорный документ не вводит новых соображений IANA. Пожалуйста, смотрите [RFC4034] для полного обзора соображений IANA, представленных DNSSEC.

12. Вопросы безопасности

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

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

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

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

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

В связи с осознанным выбором дизайна DNSSEC не обеспечивает конфиденциальность.

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

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

DNSSEC не защищает от несанкционированного доступа к данным зоны без знака. Неавторизованные данные при разрезе зоны (клей и RR NS в родительской зоне) не подписываются. Это не создает проблемы при проверке цепочки аутентификации, но означает, что сами неавторизованные данные уязвимы для подделки во время операций передачи зоны. Таким образом, хотя DNSSEC может обеспечить аутентификацию источника данных и целостность данных для наборов RR, он не может сделать это для зон, и для защиты операций передачи зон должны использоваться другие механизмы (такие как TSIG, SIG (0) или IPsec).

Пожалуйста, смотрите [RFC4034] и [RFC4035] для дополнительных соображений безопасности.

13. Благодарности

Этот документ был создан на основе мнений и идей членов рабочей группы по расширениям DNS. Хотя составить точный список всех, кто внес свой вклад в течение десятилетия, в течение которого DNSSEC находился в процессе разработки, было бы невозможно, редакторы особенно хотели бы поблагодарить следующих людей за их вклад и комментарии к этому набору документов: Jaap Akkerhuis, Марк Эндрюс, Дерек Аткинс Рой Бадами, Алан Барретт, Дэн Бернштейн, Дэвид Блэка, Лен Будни, Рэнди Буш, Фрэнсис Дюпон, Дональд Истлейк, Роберт Элз, Мик Гибен, Майкл Графф, Олафур Гудмундссон, Жиль Гетте, Андреас Густафссон, Джун-Ичиро Итожун Хагино, Фаши Хэллам-Бейкер, Боб Халли, Тед Харди, Уолтер Ховард, Грег Хадсон, Кристиан Уитема, Йохан Ирен, Стивен Якоб, Йельте Янсен, Саймон Йозефссон, Андрис Калнозолс, Питер Кох, Олаф Колкман, Марк Костерс, Суреш Кришнасвами, Бен Лори, Дэвид Лоуренс, Тед Лемон, Эд Льюис, Тед Линдгрин, Джош Литтлфилд, Рип Лумис, Билл Мэннинг, Расс Манди, Томас Нартен, Манс Нильссон, Масатака Охта, Майк Паттон, Роб Пейн, Джим Рейд, Майкл Ричардсон, Эрик Ро Зендаал, Маркос Санз, Пекка Савола, Якоб Шлайтер, Майк Стжонс, Пол Викси, Сэм Вейлер, Брайан Веллингтон и Сюзанна Вульф.

Без сомнения, приведенный выше список неполон. Мы приносим извинения любому, кого мы оставили.

14. Ссылки

14.1. Нормативные ссылки

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

[RFC2535] Eastlake 3rd, D., «Domain Name System Security Extensions», RFC 2535, March 1999.

[RFC2671] Vixie, P., «Extension Mechanisms for DNS (EDNS0)», RFC 2671, August 1999.

[RFC3225] Conrad, D., «Indicating Resolver Support of DNSSEC», RFC 3225, December 2001.

[RFC3226] Gudmundsson, O., «DNSSEC and IPv6 A6 aware server/resolver message size requirements», RFC 3226, December 2001.

[RFC3445] Massey, D. and S. Rose, «Limiting the Scope of the KEY Resource Record (RR)», RFC 3445, December 2002.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for DNS Security Extensions», RFC 4034, March 2005.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, March 2005.

14.2. Информационные ссылки

[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, «Dynamic Updates in the Domain Name System (DNS UPDATE)», RFC 2136, April 1997.

[RFC2181] Elz, R. and R. Bush, «Clarifications to the DNS Specification», RFC 2181, July 1997.

[RFC2308] Andrews, M., «Negative Caching of DNS Queries (DNS NCACHE)», RFC 2308, March 1998.

[RFC2538] Eastlake 3rd, D. and O. Gudmundsson, «Storing Certificates in the Domain Name System (DNS)», RFC 2538, March 1999.

[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, «Secret Key Transaction Authentication for DNS (TSIG)», RFC 2845, May 2000.

[RFC2931] Eastlake 3rd, D., «DNS Request and Transaction Signatures ( SIG(0)s )», RFC 2931, September 2000.

[RFC3007] Wellington, B., «Secure Domain Name System (DNS) Dynamic Update», RFC 3007, November 2000.

[RFC3008] Wellington, B., «Domain Name System Security (DNSSEC) Signing Authority», RFC 3008, November 2000.

[RFC3090] Lewis, E., «DNS Security Extension Clarification on Zone Status», RFC 3090, March 2001.

[RFC3597] Gustafsson, A., «Handling of Unknown DNS Resource Record (RR) Types», RFC 3597, September 2003.

[RFC3655] Wellington, B. and O. Gudmundsson, «Redefinition of DNS Authenticated Data (AD) bit», RFC 3655, November 2003.

[RFC3658] Gudmundsson, O., «Delegation Signer (DS) Resource Record (RR)», RFC 3658, December 2003.

[RFC3755] Weiler, S., «Legacy Resolver Compatibility for Delegation Signer (DS)», RFC 3755, May 2004.

[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, «Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag», RFC 3757, April 2004.

[RFC3833] Atkins, D. and R. Austein, «Threat Analysis of the Domain Name System (DNS)», RFC 3833, August 2004.

[RFC3845] Schlyter, J., «DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format», RFC 3845, August 2004.

Адреса авторов

Roy Arends
Telematica Instituut
Brouwerijstraat 1
7523 XC Enschede
NL
EMail: roy.arends@telin.nl

Rob Austein
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
EMail: sra@isc.org

Matt Larson
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
EMail: mlarson@verisign.com

Dan Massey
Colorado State University
Department of Computer Science
Fort Collins, CO 80523-1873
EMail: massey@cs.colostate.edu

Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899-8920
USA
EMail: scott.rose@nist.gov