Расширения безопасности системы доменных имен

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

Обзор

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

DNSSEC был разработан для защиты приложений, использующих DNS, от приема поддельных или манипулируемых данных DNS, например, созданных в результате отравления кэша DNS . Все ответы из защищенных зон DNSSEC имеют цифровую подпись . Проверяя цифровую подпись, распознаватель DNS может проверить, идентична ли информация (т. е. не изменена и полна) информации, опубликованной владельцем зоны и обслуживаемой авторитетным DNS-сервером. Хотя защита IP-адресов является непосредственной заботой многих пользователей, DNSSEC может защитить любые данные, опубликованные в DNS, включая текстовые записи (TXT) и записи обмена почтой (MX), и может использоваться для загрузки других систем безопасности, которые публикуют ссылки на криптографические сертификаты, хранящиеся в DNS, такие как записи сертификатов ( записи CERT , RFC   4398 ), отпечатки пальцев SSH ( SSHFP , RFC   4255 ), IPSec (IPSECKEY, открытые ключи RFC   4025 ), TLS якоря доверия ( TLSA , RFC   6698 ) или Encrypted Client Hello (записи SVCB/HTTPS для ECH). ).

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

Другие стандарты (не DNSSEC) используются для защиты больших объемов данных (например, передачи зоны DNS ), пересылаемых между DNS-серверами. Как документировано в RFC   4367 , некоторые пользователи и разработчики делают ложные предположения относительно DNS-имен, например, предполагая, что общее имя компании плюс «.com» всегда является ее доменным именем. DNSSEC не может защитить от ложных предположений; он может только подтвердить, что данные действительно принадлежат владельцу домена или недоступны ему.

Спецификации DNSSEC (называемые DNSSEC-bis ) очень подробно описывают текущий протокол DNSSEC. Видеть RFC   4033 , RFC   4034 и РФК   4035 . После публикации этих новых RFC (март 2005 г.), более раннего RFC, RFC   2535 устарел. Полный набор RFC, определяющий DNSSEC, собран в RFC   9364 , который также является BCP 237.

Широко распространено мнение что защита DNS критически важна для безопасности Интернета в целом, но внедрение DNSSEC в частности затруднено (по состоянию на 22 января 2010 г. ) рядом трудностей:

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

Операция

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

Записи ресурсов

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

RRSIG (подпись записи ресурса)

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

DNSKEY

Содержит открытый ключ, который преобразователь DNS использует для проверки подписей DNSSEC в записях RRSIG.

DS (подписавший делегацию)

Содержит имя делегированной зоны. Ссылается на запись DNSKEY в подделегированной зоне. Запись DS помещается в родительскую зону вместе с делегирующими записями NS.

NSEC (следующий безопасный рекорд)

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

NSEC3 (следующая версия защищенной записи 3)

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

NSEC3PARAM (следующие параметры защищенной записи версии 3)

Авторитетные DNS-серверы используют эту запись для расчета и определения, какие записи NSEC3 включать в ответы на запросы DNSSEC для несуществующих имен/типов.

При использовании DNSSEC каждый ответ на поиск DNS содержит DNS-запись RRSIG в дополнение к запрошенному типу записи. Запись RRSIG — это цифровая подпись набора записей ресурсов DNS ответа . Цифровая подпись проверяется путем поиска правильного открытого ключа, найденного в записи DNSKEY. Записи NSEC и NSEC3 используются для предоставления криптографического доказательства отсутствия какой-либо записи ресурса (RR). Запись DS используется при аутентификации DNSKEY в процедуре поиска с использованием цепочки доверия. Записи NSEC и NSEC3 используются для надежной защиты от подделки.

Алгоритмы

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

Поле алгоритма	Алгоритм	Источник	Подписание DNSSEC	Проверка DNSSEC
1	RSA / MD5		Не следует реализовывать	Не следует реализовывать
3	ДСА / ША-1		Не следует реализовывать	Не следует реализовывать
5	RSA/SHA-1	RFC   3110	Не рекомендуется	Необходимый
6	DSA-NSEC3-SHA1		Не следует реализовывать	Не следует реализовывать
7	RSASHA1-NSEC3-SHA1	RFC   5155	Не рекомендуется	Необходимый
8	RSA/ SHA-256	RFC   5702	Необходимый	Необходимый
10	RSA/ SHA-512		Не рекомендуется	Необходимый
12	ГОСТ Р 34.10-2001.	RFC   5933	Не следует реализовывать	Необязательный
13	ECDSA P-256/ ША-256	RFC   6605	Необходимый	Необходимый
14	ECDSA P-384/ ША-384		Необязательный	Рекомендуется
15	Эд25519	RFC   8080	Рекомендуется	Рекомендуется
16	Эд448		Необязательный	Рекомендуется

Поле дайджеста	Дайджест	Источник	Делегация DNSSEC	Проверка DNSSEC
1	ША-1	RFC   3658	Не следует реализовывать	Необходимый
2	ША-256	RFC   4509	Необходимый	Необходимый
3	ГОСТ Р 34.10-2001.	RFC   5933	Не следует реализовывать	Необязательный
4	ША-384	RFC   6605	Необязательный	Рекомендуется

Процедура поиска

По результатам поиска DNS безопасный преобразователь DNS может определить, поддерживает ли авторитетный сервер имен для запрашиваемого домена DNSSEC, безопасен ли полученный ответ и есть ли какая-либо ошибка. Процедура поиска различна для рекурсивных серверов имен, например серверов многих интернет-провайдеров , и для заглушек, например тех, которые включены по умолчанию в основные операционные системы. Microsoft Windows использует преобразователь заглушек, а Windows Server 2008 R2 и Windows 7, в частности, используют непроверяющий, но поддерживающий DNSSEC преобразователь заглушек.

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

Используя модель цепочки доверия , запись подписывающего лица (DS) в родительском домене ( зоне DNS ) может использоваться для проверки записи DNSKEY в поддомене , которая затем может содержать другие записи DS для проверки дальнейших поддоменов. Предположим, что рекурсивный преобразователь, такой как сервер имен интернет-провайдера, хочет получить IP-адреса ( запись A и/или записи AAAA ) домена «www.example.com » .

1. Процесс начинается, когда безопасный преобразователь устанавливает бит флага «DO» («DNSSEC OK») в DNS-запросе. Поскольку бит DO находится в битах расширенного флага, определенных механизмами расширения DNS (EDNS) , RFC   6891 , все транзакции DNSSEC должны поддерживать EDNS. Поддержка EDNS также необходима для обеспечения гораздо больших размеров пакетов, которые требуются для транзакций DNSSEC.
2. Когда распознаватель получает ответ посредством обычного процесса поиска DNS, он затем проверяет правильность ответа. В идеале, безопасный распознаватель должен начать с проверки записей DS и DNSKEY в корне DNS . Затем он будет использовать записи DS для домена верхнего уровня «com» , найденного в корне, для проверки записей DNSKEY в зоне «com». Оттуда он проверит, существует ли запись DS для поддомена «example.com» в зоне «com», и если да, то он будет использовать запись DS для проверки записи DNSKEY, найденной в «example. ком» зона. Наконец, он проверит запись RRSIG, найденную в ответе на записи A для «www.example.com».

Из приведенного выше примера есть несколько исключений.

Во-первых, если «example.com» не поддерживает DNSSEC, в ответе не будет записи RRSIG и не будет записи DS для «example.com» в зоне «com». Если есть запись DS для «example.com», но нет записи RRSIG в ответе, что-то не так, и, возможно, атака «человек посередине» происходит , удаляющий информацию DNSSEC и изменяющий записи A. Или это может быть сломанный сервер имен, не обращающий внимания на безопасность, который удалил бит флага DO из запроса или запись RRSIG из ответа. Или это может быть ошибка конфигурации.

Далее может случиться так, что доменное имя с именем «www.example.com» отсутствует, и в этом случае вместо возврата записи RRSIG в ответе будет либо запись NSEC, либо запись NSEC3. Это записи «следующей безопасности», которые позволяют преобразователю доказать, что доменное имя не существует. Записи NSEC/NSEC3 содержат записи RRSIG, которые можно проверить, как указано выше.

Наконец, может случиться так, что зона «example.com» реализует DNSSEC, а зона «com» ​​или корневая зона — нет, создавая «остров безопасности», который необходимо проверить каким-либо другим способом. По состоянию на 15 июля 2010 г. , развертывание DNSSEC для root завершено. Домен .com был подписан действительными ключами безопасности, а безопасное делегирование было добавлено в корневую зону 1 апреля 2011 года.

Заглушки резольверов

Преобразователи-заглушки — это «минимальные преобразователи DNS, которые используют режим рекурсивных запросов для переноса большей части работы по разрешению DNS на рекурсивный сервер имен». Преобразователь-заглушка просто пересылает запрос на рекурсивный сервер имен и использует бит аутентифицированных данных (AD) в ответе как «подсказку, чтобы выяснить, смог ли рекурсивный сервер имен проверить подписи для всех данных в Разделы «Ответ» и «Авторитет» ответа». Microsoft Windows использует преобразователь-заглушку, а Windows Server 2008 R2 и Windows 7, в частности, используют непроверяющий, но поддерживающий бит AD преобразователь-заглушку.

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

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

Якоря доверия и цепочки аутентификации

Чтобы доказать правильность ответа DNS, необходимо знать хотя бы один правильный ключ или запись DS из источников, отличных от DNS. Эти отправные точки известны как якоря доверия и обычно получаются вместе с операционной системой или из другого доверенного источника. Когда DNSSEC изначально разрабатывался, считалось, что единственный необходимый якорь доверия — это корень DNS . Корневые якоря были впервые опубликованы 15 июля 2010 года.

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

Подписи и подписание зон

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

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

Управление ключами

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

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

Ключи в записях DNSKEY могут использоваться для двух разных целей, и обычно для каждой из них используются разные записи DNSKEY. Во-первых, существуют ключи подписи ключей (KSK), которые используются для подписи других записей DNSKEY, содержащих ключи подписи зоны (ZSK), которые используются для подписи других записей. Поскольку ZSK находятся под полным контролем и используются одной конкретной зоной DNS , их можно переключать легче и чаще. В результате ZSK могут быть намного короче, чем KSK, и при этом обеспечивать тот же уровень защиты, уменьшая при этом размер записей RRSIG/DNSKEY.

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

Тесно связанным принципом является смена алгоритма , он предполагает миграцию зоны от одного алгоритма подписи к другому. Хорошим примером этого может быть переход от алгоритма 8 (RSA/SHA-256) к алгоритму 13 (ECDSA/SHA-256). Несколько ccTLD уже перешли, включая .at , .br , .cz , .ch , .fr , .ie , .nl. и .ф . Verisign перевела .com, .net и .edu на алгоритм 13 в конце 2023 года. Миграция корневого домена с алгоритма 8 на алгоритм 13 в настоящее время планируется в начале 2024 года.

Рабочая группа DANE

Аутентификация именованных объектов на основе DNS (DANE) — это рабочая группа IETF. с целью разработки протоколов и методов, которые позволяют интернет-приложениям устанавливать криптографически защищенную связь с TLS , DTLS , SMTP и S/MIME на основе DNSSEC.

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

Поддержка вшитых сертификатов DNSSEC была включена в Google Chrome 14. но позже был удален. Для Mozilla Firefox поддержка осуществлялась дополнением в то время как встроенная поддержка в настоящее время ожидает, чтобы кто-то начал над ней работать.

История

DNS — это важнейшая и фундаментальная служба Интернета, однако в 1990 году Стив Белловин обнаружил в ней серьезные недостатки безопасности. Исследования по его обеспечению начались и резко продвинулись, когда его статья была обнародована в 1995 году. Первоначальный RFC 2065 был опубликован IETF в 1997 году, и первоначальные попытки реализовать эту спецификацию привели к созданию пересмотренной (и признанной полностью работоспособной) спецификации в 1999 году под названием IETF RFC 2535. Планировалось развернуть DNSSEC на основе RFC 2535.

К сожалению, спецификация IETF RFC 2535 имела очень серьезные проблемы с масштабированием на весь Интернет; к 2001 году стало ясно, что эта спецификация непригодна для больших сетей. При нормальной работе DNS-серверы часто не синхронизируются со своими родительскими серверами. Обычно это не проблема, но когда DNSSEC включен, эти несинхронизированные данные могут привести к серьезному отказу в обслуживании, создаваемому самим пользователем. Первоначальный DNSSEC требовал сложного протокола из шести сообщений и большого количества передач данных для выполнения ключевых изменений для дочернего элемента (дочерние зоны DNS должны были отправлять все свои данные родительскому элементу, заставлять родительский элемент подписывать каждую запись, а затем отправлять эти подписи обратно дочернему элементу для хранения в записи SIG). Кроме того, изменения открытого ключа могут иметь абсурдные последствия; например, если зона «.com» изменит свой открытый ключ, ей придется отправить 22 миллиона записей (потому что потребуется обновить все подписи во всех своих дочерних зонах). Таким образом, DNSSEC, определенный в RFC 2535, не может масштабироваться до Интернета.

IETF фундаментально изменил DNSSEC, который при необходимости называется DNSSEC-bis, чтобы отличить его от исходного подхода DNSSEC, описанного в RFC 2535. В этой новой версии используются «записи ресурсов подписывающего лица (DS)», чтобы обеспечить дополнительный уровень косвенности в точках делегирования между родительская и дочерняя зона. В новом подходе, когда изменяется главный открытый ключ дочернего элемента, вместо шести сообщений для каждой записи в дочернем элементе имеется одно простое сообщение: дочерний элемент отправляет новый открытый ключ своему родителю (конечно, с подписью). Родители просто хранят один главный открытый ключ для каждого ребенка; это гораздо практичнее. Это означает, что родителю передается небольшой объем данных вместо обмена огромными объемами данных между родителем и дочерними элементами. Это означает, что клиентам придется проделать немного больше работы при проверке ключей. Более конкретно, проверка набора KEY RRset зоны DNS требует двух операций проверки подписи вместо одной, требуемой RFC 2535 (это не влияет на количество подписей, проверенных для других типов наборов RR). Большинство считают это небольшой ценой, поскольку это делает развертывание DNSSEC более практичным. Новая версия опубликована в RFC4033-4035.

В январе 2024 года было объявлено об атаке типа «KeyTrap» на отказ в обслуживании для всех преобразователей DNSSEC, соответствующих спецификациям. Спецификация DNSSEC (RFC4033-4035) указывает, что преобразователь при получении подписанного пакета из восходящего потока должен пробовать все ключи с правильным «тегом» во всех подписях до тех пор, пока одна из комбинаций не будет успешно проверена. Поместив в пакет множество ключей с одним и тем же «тегом» и множество подписей, соответствующих этому «тегу», исследователи могут замедлить работу преобразователя в 2 миллиона раз. В ответ резолверы начали устанавливать ограничения на количество ошибок проверки, коллизий ключевых тегов и вычислений хэша.

Аутентификация ответов NXDOMAIN и NSEC

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

Первоначальное решение заключалось в создании записей NSEC для каждой пары доменов в зоне. Таким образом, если клиент запросил запись по несуществующему адресу k.example.com, сервер ответит записью NSEC, в которой будет указано, что между a.example.com и z.example.com. Однако при этом теряется больше информации о зоне, чем при традиционных ошибках NXDOMAIN без аутентификации, поскольку раскрывается существование реальных доменов.

Предотвращение перемещения домена

Записи NSEC3 (RFC 5155) были созданы в качестве альтернативы, которая хеширует имена вместо их прямого перечисления. Со временем достижения в хешировании с использованием графических процессоров и выделенного оборудования привели к тому, что ответы NSEC3 можно было дешево перебрать с помощью автономных атак по словарю. NSEC5 был предложен, чтобы позволить авторитетным серверам подписывать ответы NSEC без необходимости хранить закрытый ключ, который можно использовать для изменения зоны. Таким образом, кража NSEC5KEY приведет только к возможности более легкого перечисления зон.

Из-за беспорядочной эволюции протокола и желания сохранить обратную совместимость, онлайн-серверы подписи DNSSEC возвращают «ложь во спасение» вместо прямой аутентификации отрицания существования. Метод, описанный в RFC 4470, возвращает запись NSEC, в которой пары доменов лексически окружают запрошенный домен. Например, запрос на k.example.com Таким образом, запись NSEC докажет, что между (фиктивными) доменами ничего не существует. j.example.com и l.example.com. Это также возможно с записями NSEC3.

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

Развертывание

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

Развертывание DNSSEC в крупномасштабных сетях также представляет собой сложную задачу. Озмент и Шехтер отмечают, что DNSSEC (и другие технологии) имеют «проблему начальной загрузки»: пользователи обычно развертывают технологию только в том случае, если они получают немедленную выгоду, но если требуется минимальный уровень развертывания, прежде чем какие-либо пользователи получат выгоду, превышающую их затраты. (как и в случае с DNSSEC), его сложно развернуть. DNSSEC можно развернуть на любом уровне иерархии DNS, но он должен быть широко доступен в зоне, прежде чем многие другие захотят его принять. DNS-серверы необходимо обновить с помощью программного обеспечения, поддерживающего DNSSEC, а данные DNSSEC необходимо создать и добавить к данным зоны DNS. Клиент, использующий TCP/IP, должен обновить свой преобразователь DNS (клиент), прежде чем он сможет использовать возможности DNSSEC. Более того, любой преобразователь должен иметь или иметь возможность получить хотя бы один открытый ключ, которому он может доверять, прежде чем он сможет начать использовать DNSSEC.

Реализация DNSSEC может значительно увеличить нагрузку на некоторые DNS-серверы. Общие ответы, подписанные DNSSEC, намного больше, чем размер UDP по умолчанию, составляющий 512 байт. Теоретически это можно сделать с помощью нескольких IP-фрагментов, но многие «промежуточные устройства» в этой области не обрабатывают их правильно. Это приводит к использованию вместо этого TCP. Однако многие современные реализации TCP хранят большой объем данных для каждого TCP-соединения; сильно загруженные серверы могут исчерпать ресурсы, просто пытаясь ответить на большее количество (возможно, поддельных) запросов DNSSEC. Некоторые расширения протокола, такие как TCP Cookie Transactions , были разработаны для уменьшения этой нагрузки. Для решения этих проблем предпринимаются значительные усилия по развертыванию DNSSEC, поскольку Интернет жизненно важен для многих организаций.

Ранние развертывания

Среди первых пользователей — Бразилия ( .br ), Болгария ( .bg ), Чехия ( .cz ), Намибия ( .na ). Пуэрто-Рико ( .pr ) и Швеция ( .se ), которые используют DNSSEC для доменов верхнего уровня с кодом своей страны ; RIPE NCC , который подписал все записи обратного поиска (in-addr.arpa), делегированные ему Управлением по присвоению номеров в Интернете (IANA). ARIN также подписывает свои обратные зоны. В феврале 2007 года TDC стал первым шведским интернет-провайдером, который начал предлагать эту функцию своим клиентам.

IANA публично тестировала образец подписанного корня с июня 2007 года. В течение этого периода до производственного подписания корня также существовало несколько альтернативных якорей доверия. IKS Jena представила его 19 января 2006 г. Консорциум Интернет-систем представил еще один 27 марта того же года, а сама ICANN объявила о третьем 17 февраля 2009 г.

2 июня 2009 г. Afilias , поставщик услуг реестра для Public Interest Registry, подписала TLD .org. зоны .org 26 сентября 2008 г. Afilias и PIR также подробно рассказали, что на первом этапе с участием крупных регистраторов, с которыми у компании сложились прочные рабочие отношения («друзья и родственники»), будет первая возможность подписывать свои домены, начиная с «начала 2009 г.». . 23 июня 2010 г. было указано 13 регистраторов, предлагающих записи DNSSEC для доменов .ORG.

VeriSign запустила пилотный проект, позволяющий доменам .com и .net регистрироваться в целях экспериментов NSEC3. 24 февраля 2009 г. они объявили, что развернут DNSSEC во всех своих доменах верхнего уровня (.com, .net и т. д.) в течение 24 месяцев. а 16 ноября того же года они заявили, что домены .com и .net будут подписаны к первому кварталу 2011 года после задержек, вызванных техническими аспектами реализации. Эта цель была достигнута в срок а вице-президент Verisign по DNSSEC Мэтт Ларсон получил награду InfoWorld за технологическое лидерство в 2011 году за свою роль в продвижении DNSSEC.

Развертывание в корне DNS

DNSSEC был впервые развернут на корневом уровне 15 июля 2010 года. Ожидается, что это значительно упростит развертывание преобразователей DNSSEC, поскольку корневой якорь доверия можно использовать для проверки любой зоны DNSSEC, имеющей полную цепочку доверия от корня. Поскольку цепочка доверия должна быть прослежена до доверенного корня без прерывания для проверки, якоря доверия все равно необходимо настроить для безопасных зон, если какая-либо из зон над ними не является безопасной. Например, если зона «signed.example.org» была защищена, а зона «example.org» — нет, то, даже если зона «.org» и корень подписаны, необходимо развернуть якорь доверия в для проверки зоны.

Политические вопросы, связанные с подписанием root, вызывали постоянную озабоченность, в первую очередь в отношении некоторых центральных вопросов:

• Другие страны обеспокоены контролем США над Интернетом и по этой причине могут отказаться от любого централизованного ввода ключей.
• Некоторые правительства могут попытаться запретить распространение ключей шифрования с помощью DNSSEC.

Планирование

В сентябре 2008 года ICANN и VeriSign опубликовали предложения по реализации. а в октябре Национальное управление по телекоммуникациям и информации (NTIA) обратилось к общественности за комментариями. Неясно, повлияли ли полученные комментарии на разработку окончательного плана развертывания.

3 июня 2009 г. Национальный институт стандартов и технологий (NIST) объявил о планах подписать корневой протокол к концу 2009 г. совместно с ICANN, VeriSign и NTIA.

6 октября 2009 г. на 59-й конференции RIPE ICANN и VeriSign объявили запланированные сроки развертывания DNSSEC в корневой зоне. На встрече было объявлено, что он будет постепенно развертываться на одном корневом сервере имен в месяц, начиная с 1 декабря 2009 г., при этом последний корневой сервер имен будет обслуживать зону, подписанную DNSSEC, 1 июля 2010 г., а корневая зона будет подписано с помощью DNSKEY RSA/SHA256. В период постепенного развертывания корневая зона будет обслуживать намеренно непроверяемую корневую зону (DURZ), в которой используются фиктивные ключи, при этом окончательная запись DNSKEY не будет распространяться до 1 июля 2010 года. Это означает, что ключи, которые использовались для подписи использования зоны, намеренно не поддаются проверке; Причиной этого развертывания было отслеживание изменений в структуре трафика, вызванных увеличением количества ответов на запросы, запрашивающие записи ресурсов DNSSEC.

Домен .org верхнего уровня .com , .net и .edu. был подписан с DNSSEC в июне 2010 года, а затем , в 2010 и 2011 годах, последовали Домены верхнего уровня с кодом страны смогли депонировать ключи, начиная с мая 2010 года. По состоянию на ноябрь 2011 г. более 25% доменов верхнего уровня подписаны DNSSEC.

Выполнение

25 января 2010 г. корневой сервер L (ell) начал обслуживать намеренно непроверяемую корневую зону (DURZ). Зона использует подписи хеша SHA-2 (SHA-256), созданные с использованием алгоритма RSA , как определено в РФК   5702 . По состоянию на май 2010 года все тринадцать корневых серверов начали обслуживать DURZ. 15 июля 2010 г. была подписана первая полноценная корневая корневая зона DNSSEC с серийным номером SOA 2010071501. Корневые якоря доверия доступны в IANA .

Развертывание на уровне TLD

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

DNSSEC Lookaside Validation – исторический

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

Чтобы использовать DLV, требовался поддерживающий его валидатор, например BIND или Unbound , настроенный с привязкой доверия для зоны DLV. Эта зона содержала записи DLV; они имели тот же формат, что и записи DS, но вместо ссылки на делегированную подзону они ссылались на зону в другом месте дерева DNS. Когда валидатору не удавалось найти цепочку доверия от корня до набора RRset, который он пытается проверить, он искал запись DLV, которая могла бы обеспечить альтернативную цепочку доверия.

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

ISC вывела из эксплуатации свой реестр DLV в 2017 году. Поддержка DLV устарела в BIND 9.12 и полностью удалена из BIND 9.16. В несвязанной версии 1.5.4 (июль 2015 г.) DLV помечен как выведенный из эксплуатации в примере конфигурации и на странице руководства. Knot Resolver и PowerDNS Recursor никогда не реализовывали DLV.

В марте 2020 года IETF опубликовал RFC   8749 , прекращающий использование DLV в качестве стандарта и переводящий RFC 4432 и RFC 5074 в «исторический» статус.

Инициатива федерального правительства США по развертыванию DNSSEC

Управление науки и технологий Министерства внутренней безопасности США (DHS) спонсирует «Инициативу по развертыванию DNSSEC». Эта инициатива призывает «все сектора добровольно принять меры безопасности, которые улучшат безопасность инфраструктуры именования Интернета, в рамках глобальных совместных усилий, в которых участвуют многие страны и организации в государственном и частном секторах». DHS также финансирует усилия по усовершенствованию DNSSEC и его внедрению в федеральном правительстве США.

Об этом сообщили что 30 марта 2007 года Министерство внутренней безопасности США предложило «надёжно передать ключ для подписи корневой зоны DNS в руки правительства США». Однако в зале заседаний не присутствовало ни одного представителя правительства США, а комментарий, послуживший причиной публикации статьи, был сделан другой стороной. Позже DHS прокомментировало о том, почему, по их мнению, другие пришли к ложному выводу, что правительство США сделало такое предложение: «Министерство внутренней безопасности США финансирует разработку технического плана по внедрению DNSSec и в октябре прошлого года распространило его первоначальный проект среди Длинный список международных экспертов для комментариев. В проекте изложен ряд вариантов того, кто может быть держателем или «оператором» ключа корневой зоны, по сути, сводится к правительственному учреждению или подрядчику: «Нигде в документе. делаем ли мы какие-либо предложения относительно личности оператора корневого ключа», — сказал Моэн, менеджер по исследованиям и разработкам в области кибербезопасности Министерства национальной безопасности.

Развертывание DNSSEC в федеральном правительстве США

Национальный институт стандартов и технологий (NIST) 16 мая 2006 г. опубликовал специальную публикацию NIST 800-81 «Руководство по развертыванию защищенной системы доменных имен (DNS)» с инструкциями по развертыванию DNSSEC. NIST намеревался опубликовать новые требования DNSSEC Федерального закона об управлении информационной безопасностью (FISMA) в NIST SP800-53-R1 со ссылкой на это руководство по развертыванию. У американских агентств тогда был бы один год после окончательной публикации NIST SP800-53-R1 для удовлетворения этих новых требований FISMA. Однако на тот момент NSEC3 еще не был завершен. NIST предложил использовать разделенные домены — метод, который, как известно, возможен, но его сложно правильно развернуть и который имеет отмеченные выше недостатки безопасности.

22 августа 2008 г. Управление управления и бюджета (OMB) опубликовало меморандум, требующий от федеральных агентств США развернуть DNSSEC на сайтах .gov; корень .gov должен быть подписан к январю 2009 г., а все поддомены под .gov должны быть подписаны к декабрю 2009 г. Хотя в меморандуме основное внимание уделяется сайтам .gov, Агентство оборонных информационных систем США заявляет, что намерено удовлетворить требования OMB DNSSEC и в домене .mil (военные силы США). Кэролайн Даффи Марсан из NetworkWorld заявила, что DNSSEC «не получил широкого распространения, поскольку страдает от классической дилеммы курицы и яйца... с учетом мандата OMB, похоже, яйцо треснет».

Развертывание в резолверах

Несколько интернет-провайдеров начали развертывать рекурсивные преобразователи DNS с проверкой DNSSEC. Comcast стал первым крупным интернет-провайдером, сделавшим это в США, объявив о своих намерениях 18 октября 2010 г. и завершение развертывания 11 января 2012 г.

Согласно исследованию APNIC , доля клиентов, использующих исключительно преобразователи DNS, выполняющие проверку DNSSEC, в мае 2013 года выросла до 8,3%. Около половины этих клиентов использовали общедоступный преобразователь DNS Google .

В сентябре 2015 года Verisign анонсировала бесплатный общедоступный сервис DNS-преобразователя. и хотя это не упоминается в их пресс-релизах, он также выполняет проверку DNSSEC.

К началу 2016 года мониторинг APNIC показал, что доля клиентов, использующих исключительно преобразователи DNS, выполняющие проверку DNSSEC, увеличилась примерно до 15%.

Поддержка DNSSEC

См. также: Public_recursive_name_server § Notable_public_DNS_service_operators

сервер Google Публичный рекурсивный DNS- включил проверку DNSSEC 6 мая 2013 года.

BIND , самое популярное программное обеспечение для управления DNS, включает поддержку DNSSEC по умолчанию, начиная с версии 9.5.

выполняет Публичный рекурсивный DNS Quad9 проверку DNSSEC для своего основного адреса 9.9.9.9 с момента его создания 11 мая 2016 года. Quad9 также предоставляет альтернативную службу, которая не выполняет проверку DNSSEC, в основном для отладки.

Развертывание в инфраструктуре

В сентябре 2023 года Microsoft объявила, что будет использовать DNSSEC (через DANE ) для проверки подлинности сертификатов во время связи SMTP.

Прием

Джефф Хатсон утверждает, что от развертывания DNSSEC следует отказаться.

Публикации IETF

• RFC   2535 Расширения безопасности системы доменных имен
• RFC   3225, указывающий поддержку DNSSEC со стороны резольвера
• RFC   3226 DNSSEC и IPv6 A6 Требования к размеру сообщения сервера/преобразователя
• RFC   3833 Анализ угроз системы доменных имен
• RFC   4033: Введение и требования к безопасности DNS ( DNSSEC-bis )
• Записи ресурсов RFC   4034 для расширений безопасности DNS ( DNSSEC-bis )
• Модификации протокола RFC   4035 для расширений безопасности DNS ( DNSSEC-bis )
• RFC   4398 Хранение сертификатов в системе доменных имен (DNS)
• RFC   4431 DNSSEC Lookaside Validation (DLV) Запись ресурса DNS
• RFC   4470 минимально охватывает записи NSEC и онлайн-подпись DNSSEC
• RFC   4509 Использование SHA-256 в записях ресурсов (RR) подписывающего лица делегирования DNSSEC (DS)
• RFC   4641. Методы работы DNSSEC.
• Эксперименты по безопасности DNS RFC   4955 (DNSSEC)
• RFC   5011 Автоматическое обновление якорей доверия DNS Security (DNSSEC)
• RFC   5155 DNSSEC хэширует отказ в существовании с проверкой подлинности
• RFC   5702 Использование алгоритмов SHA-2 с RSA в DNSKEY и записях ресурсов RRSIG для DNSSEC
• RFC   6014 Распределение идентификаторов криптографического алгоритма для DNSSEC
• RFC   6605 Алгоритм цифровой подписи на основе эллиптической кривой (DSA) для DNSSEC
• RFC   6725 DNS Security (DNSSEC) Алгоритм DNSKEY Обновления реестра IANA
• RFC   6781. Методы работы DNSSEC, версия 2.
• Разъяснения RFC   6840 и замечания по реализации безопасности DNS (DNSSEC)
• RFC   6975: понимание криптографического алгоритма сигнализации в расширениях безопасности DNS (DNSSEC)
• RFC   7129 Аутентифицированное отрицание существования в DNS
• RFC   7344 Автоматизация обслуживания доверия делегирования DNSSEC
• RFC   7583 Вопросы времени смены ключей DNSSEC
• RFC   8078 Управление записями DS от родительского элемента через CDS/CDNSKEY
• RFC   8080 Алгоритм цифровой безопасности Эдвардса (EdDSA) для DNSSEC
• RFC   8198: агрессивное использование кэша, проверенного DNSSEC
• Требования к реализации алгоритма RFC   8624 и руководство по использованию DNSSEC
• RFC   8749 Перевод DNSSEC Lookaside Validation (DLV) в исторический статус
• RFC   9077 NSEC и NSEC3: TTL и агрессивное использование
• RFC   9157: пересмотренные рекомендации IANA для DNSSEC
• Руководство RFC   9276 по настройке параметров NSEC3
• RFC   9364 ( BCP 237) Расширения безопасности DNS

Инструменты

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

• Windows 7 и Windows Server 2008 R2 включают в себя «безопасный» преобразователь заглушек, который способен различать безопасные и незащищенные ответы рекурсивного сервера имен. Windows Server 2012 DNSSEC совместим с безопасными динамическими обновлениями с зонами, интегрированными в Active Directory, а также с репликацией ключей привязки Active Directory на другие такие серверы.
• BIND , самый популярный DNS-сервер имен (включая dig ), включает в себя новый протокол DNSSEC-bis (записи DS), а также поддержку записей NSEC3.
• Unbound — это DNS-сервер имен, который был написан с нуля с учетом концепций DNSSEC.
• mysqlBind , программное обеспечение управления DNS по лицензии GPL для DNS ASP, теперь поддерживает DNSSEC.
• OpenDNSSEC — это специальный инструмент подписывания DNSSEC, использующий PKCS#11 для взаимодействия с аппаратными модулями безопасности .
• В Knot DNS добавлена ​​поддержка автоматического подписания DNSSEC в версии 1.4.0.
• PowerDNS полностью поддерживает DNSSEC начиная с версии 3.0 в режимах с предварительной и активной подписью.
• DNSSEC : Что это такое и почему важно внедрить его надолго? — Check it Инициатива интернет-сообщества и правительства Нидерландов

См. также

• DNSCrypt
• DNSкривая
• Механизмы расширения DNS (EDNS)
• ТИГ
• Ресурсная инфраструктура открытых ключей (RPKI)

Дальнейшее чтение

• Х. Ян; Э. Остервейл; Д. Мэсси; С. Лу; Л. Чжан (8 апреля 2010 г.). «Развертывание криптографии в системах масштаба Интернета: пример DNSSEC». Транзакции IEEE для надежных и безопасных вычислений . 8 (5). стр. 656–669. CiteSeerX   10.1.1.158.1984 . дои : 10.1109/TDSC.2010.10 . S2CID   14887477 .

Внешние ссылки

• DNSSEC – информационный сайт DNSSEC: DNSSEC.net
• DNSEXT DNS-расширения Рабочая группа IETF
• Проект инструментов DNSSEC