Расширения безопасности системы доменных имен ( DNSSEC ) — это набор спецификаций расширений , разработанных IETF ( Internet Engineering Task Force ) для защиты данных, передаваемых в системе доменных имен ( DNS ) в сетях Интернет-протокола ( IP ) . Протокол обеспечивает криптографическую аутентификацию данных, аутентифицированное отрицание существования и целостность данных , но не доступность или конфиденциальность .
Первоначальный дизайн системы доменных имен не включал никаких функций безопасности. Она была задумана только как масштабируемая распределенная система. Расширения безопасности системы доменных имен (DNSSEC) пытаются повысить безопасность, сохраняя при этом обратную совместимость . RFC 3833 от 2004 года документирует некоторые известные угрозы DNS и их решения в DNSSEC.
DNSSEC был разработан для защиты приложений, использующих DNS, от приема поддельных или измененных данных DNS, например, созданных путем отравления кэша DNS . Все ответы из защищенных зон DNSSEC имеют цифровую подпись . [1] Проверяя цифровую подпись, DNS-резолвер может проверить, идентична ли информация (т. е. неизмененная и полная) информации, опубликованной владельцем зоны и обслуживаемой на авторитетном DNS-сервере. Хотя защита IP-адресов является непосредственной проблемой для многих пользователей, DNSSEC может защищать любые данные, опубликованные в DNS, включая текстовые записи (TXT) и записи обмена почтой (MX), и может использоваться для загрузки других систем безопасности, которые публикуют ссылки на криптографические сертификаты, хранящиеся в DNS, такие как записи сертификатов ( записи CERT , RFC 4398), отпечатки пальцев SSH ( SSHFP , RFC 4255), открытые ключи IPSec (IPSECKEY, RFC 4025), якоря доверия TLS ( TLSA , RFC 6698) или зашифрованные приветствия клиента (записи SVCB/HTTPS для ECH [2] [3] ).
DNSSEC не обеспечивает конфиденциальность данных; в частности, все ответы DNSSEC аутентифицированы, но не зашифрованы. DNSSEC не защищает от DoS- атак напрямую, хотя косвенно обеспечивает некоторую выгоду (поскольку проверка подписи позволяет использовать потенциально ненадежные стороны). [ необходима цитата ]
Другие стандарты (не DNSSEC) используются для защиты больших объемов данных (например, передачи зоны DNS ), отправляемых между серверами DNS. Как задокументировано в RFC 4367, некоторые пользователи и разработчики делают ложные предположения об именах DNS, например, предполагая, что общее имя компании плюс ".com" всегда является ее доменным именем. DNSSEC не может защитить от ложных предположений; он может только подтвердить, что данные действительно получены или недоступны владельцем домена. [ необходима цитата ]
Спецификации DNSSEC (называемые DNSSEC-bis ) очень подробно описывают текущий протокол DNSSEC. См. RFC 4033, RFC 4034 и RFC 4035. С публикацией этих новых RFC (март 2005 г.) более ранний RFC, RFC 2535, устарел. Полный набор RFC, определяющих DNSSEC, собран в RFC 9364, который также является BCP 237.
Широко распространено мнение [4] , что защита DNS имеет решающее значение для защиты Интернета в целом, однако развертывание DNSSEC в частности затрудняется (по состоянию на 22 января 2010 г. [update]) несколькими трудностями:
DNSSEC работает путем цифровой подписи записей для поиска DNS с использованием криптографии с открытым ключом . Правильная запись DNSKEY аутентифицируется через цепочку доверия , начиная с набора проверенных открытых ключей для корневой зоны DNS , которая является доверенной третьей стороной . Владельцы доменов генерируют свои собственные ключи и загружают их с помощью панели управления DNS у своего регистратора доменных имен, который, в свою очередь, отправляет ключи через secDNS оператору зоны (например, Verisign для .com), который подписывает и публикует их в DNS.
DNS реализуется с использованием нескольких записей ресурсов. Для реализации DNSSEC были созданы или адаптированы для использования с DNSSEC несколько новых типов записей DNS :
При использовании DNSSEC каждый ответ на поиск DNS содержит запись RRSIG DNS в дополнение к запрошенному типу записи. Запись RRSIG является цифровой подписью набора записей ресурсов DNS ответа . Цифровая подпись проверяется путем нахождения правильного открытого ключа, найденного в записи DNSKEY. Записи NSEC и NSEC3 используются для предоставления криптографического доказательства отсутствия какой-либо записи ресурса (RR). Запись DS используется при аутентификации DNSKEY в процедуре поиска с использованием цепочки доверия. Записи NSEC и NSEC3 используются для надежной защиты от подделки.
DNSSEC был разработан с возможностью расширения, чтобы по мере обнаружения атак на существующие алгоритмы можно было вводить новые алгоритмы с сохранением обратной совместимости , как описано в RFC 8624. В следующей таблице по состоянию на июнь 2019 года определены алгоритмы безопасности, которые используются или использовались наиболее часто: [5]
По результатам поиска DNS, DNS-распознаватель , поддерживающий безопасность , может определить, поддерживает ли авторитетный сервер имен для запрашиваемого домена DNSSEC, безопасен ли полученный ответ и есть ли какая-то ошибка. Процедура поиска отличается для рекурсивных серверов имен , таких как у многих интернет-провайдеров , и для резольверов-заглушек, таких как те, что включены по умолчанию в основные операционные системы. Microsoft Windows использует резольвер-заглушку, а Windows Server 2008 R2 и Windows 7 в частности используют невалидирующий, но поддерживающий DNSSEC резольвер-заглушку. [6] [7]
Используя модель цепочки доверия , запись Делегирования Подписывающего (DS) в родительском домене ( зона DNS ) может использоваться для проверки записи DNSKEY в поддомене , которая затем может содержать другие записи DS для проверки дальнейших поддоменов. Предположим, что рекурсивный распознаватель, такой как сервер имен ISP, хочет получить IP-адреса ( запись A и/или записи AAAA ) домена "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 года [update]развертывание DNSSEC в корневой зоне завершено. [8] Домен .com был подписан с действительными ключами безопасности, и безопасное делегирование было добавлено в корневую зону 1 апреля 2011 года. [9]
Stub resolvers — это «минимальные DNS resolvers, которые используют режим рекурсивных запросов для разгрузки большей части работы по разрешению DNS на рекурсивный сервер имен». [10] Stub resolver просто пересылает запрос на рекурсивный сервер имен и использует бит Authenticated Data (AD) в ответе как «подсказку, чтобы выяснить, смог ли рекурсивный сервер имен проверить подписи для всех данных в разделах Answer и Authority ответа». [11] Microsoft Windows использует stub resolver, а Windows Server 2008 R2 и Windows 7 в частности используют непроверяющий, но поддерживающий AD bit stub resolver. [6] [7]
Проверяющий заглушку распознаватель также может потенциально выполнять собственную проверку подписи, устанавливая бит Checking Disabled (CD) в своих сообщениях запроса. [11] Проверяющий заглушку распознаватель использует бит CD для выполнения собственной рекурсивной аутентификации. Использование такого проверочного заглушки распознавателя обеспечивает клиенту сквозную DNS-безопасность для доменов, реализующих DNSSEC, даже если поставщик услуг Интернета или подключение к ним не являются доверенными.
Невалидирующие заглушки-резолверы должны полагаться на внешние службы проверки DNSSEC, например, те, которые контролируются интернет-провайдером пользователя или публичным рекурсивным сервером имен , а также на каналы связи между ним и этими серверами имен, используя такие методы, как DNS через TLS . [11] [12]
Чтобы иметь возможность доказать, что ответ DNS верен, нужно знать по крайней мере один ключ или запись DS, которая верна из источников, отличных от DNS. Эти отправные точки известны как якоря доверия и обычно получаются с помощью операционной системы или через какой-либо другой доверенный источник. Когда DNSSEC был изначально разработан, считалось, что единственный якорь доверия, который понадобится, — это корень DNS . Корневые якоря были впервые опубликованы 15 июля 2010 года. [13]
Цепочка аутентификации представляет собой ряд связанных записей 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 [14] и .ph . Verisign перенесла .com, .net и .edu на алгоритм 13 в конце 2023 года. [15] [16] Миграция корневого домена с алгоритма 8 на алгоритм 13 в настоящее время планируется на начало 2024 года. [17]
DNS-based Authentication of Named Entities (DANE) — это рабочая группа IETF [18], целью которой является разработка протоколов и методов, позволяющих интернет-приложениям устанавливать криптографически защищенные соединения с использованием TLS , DTLS , SMTP и S/MIME на основе DNSSEC.
Новые протоколы позволят обеспечить дополнительные гарантии и ограничения для традиционной модели, основанной на инфраструктуре открытых ключей . Они также позволят владельцам доменов утверждать сертификаты для себя, без обращения к сторонним центрам сертификации .
Поддержка DNSSEC stapled certificates была включена в Google Chrome 14, [19] но позже была удалена. [20] Для Mozilla Firefox поддержка была предоставлена дополнением [21], в то время как собственная поддержка в настоящее время ожидает, когда кто-то начнет над ней работать. [22]
DNS является критически важной и фундаментальной службой Интернета, однако в 1990 году Стив Белловин обнаружил в ней серьезные уязвимости безопасности. Исследования по ее защите начались и значительно продвинулись, когда его статья была опубликована в 1995 году. [23] Первоначальный 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 зоны DNS требует двух операций проверки подписи вместо одной, требуемой RFC 2535 (нет никакого влияния на количество проверенных подписей для других типов наборов ключей). Большинство считает это небольшой ценой, поскольку это делает развертывание DNSSEC более практичным. Новая версия опубликована в RFC4033-4035.
В январе 2024 года была объявлена атака типа «отказ в обслуживании» «KeyTrap» для всех DNSSEC-резолверов, соответствующих спецификации. В спецификации DNSSEC (RFC4033-4035) указано, что резольвер при получении подписанного пакета от вышестоящего узла должен пробовать все ключи с правильным «тегом» на всех подписях, пока одна из комбинаций не будет успешно проверена. Помещая в пакет много ключей с одинаковым «тегом» и много подписей, соответствующих этому «тегу», исследователи могут замедлить работу резольвера в 2 миллиона раз. В ответ на это резольверы начали устанавливать ограничения на количество ошибок проверки, коллизий ключевых тегов и вычислений хэшей. [24]
Криптографическое доказательство отсутствия домена требует подписания ответа на каждый запрос для несуществующего домена. Это не проблема для серверов онлайн-подписи, которые хранят свои ключи в сети. Однако DNSSEC был разработан с использованием автономных компьютеров для подписи записей, чтобы ключи подписи зоны можно было хранить в холодном хранилище. Это представляет проблему при попытке аутентификации ответов на запросы для несуществующих доменов, поскольку невозможно заранее сгенерировать ответ на каждый возможный запрос имени хоста.
Первоначальное решение состояло в создании записей NSEC для каждой пары доменов в зоне. Таким образом, если клиент запросил запись в несуществующем k.example.com, сервер ответил бы записью NSEC, сообщающей, что между a.example.comи ничего не существует z.example.com. Однако это приводит к утечке большего количества информации о зоне, чем традиционные неаутентифицированные ошибки NXDOMAIN, поскольку это раскрывает существование реальных доменов.
Записи NSEC3 (RFC 5155) были созданы как альтернатива, которая хэширует имя вместо того, чтобы перечислять его напрямую. Со временем достижения в хэшировании с использованием графических процессоров и выделенного оборудования привели к тому, что ответы NSEC3 можно было бы легко взломать методом подбора с помощью офлайновых атак по словарю. NSEC5 был предложен для того, чтобы позволить авторитетным серверам подписывать ответы NSEC без необходимости хранить закрытый ключ, который можно использовать для изменения зоны. Таким образом, кража NSEC5KEY приведет только к возможности более легкого перечисления зоны. [25]
Из-за беспорядочной эволюции протокола и желания сохранить обратную совместимость, онлайн-серверы подписи DNSSEC возвращают «белую ложь» вместо того, чтобы напрямую подтвердить отрицание существования. Метод, описанный в RFC 4470, возвращает запись NSEC, в которой пары доменов лексически окружают запрошенный домен. Например, запрос на k.example.comприведет к записи NSEC, доказывающей, что ничего не существует между (фиктивными) доменами j.example.comи l.example.com. Это также возможно с записями NSEC3. [26]
CloudFlare стал пионером пары альтернативных подходов, которые позволяют достичь того же результата за одну треть размера ответа. [27] Первый подход представляет собой вариацию подхода «белая ложь», называемую «черная ложь», которая использует обычное поведение DNS-клиента для более компактного заявления о несуществовании. [28] Второй подход вместо этого выбирает доказательство того, что «запись существует, но запрошенный тип записи не существует», что они называют «DNS shotgun». [29] [27]
Интернет является критической инфраструктурой, однако его работа зависит от фундаментально незащищенного DNS. Таким образом, существует сильный стимул для защиты DNS, и развертывание DNSSEC обычно считается критической частью этих усилий. Например, Национальная стратегия США по обеспечению безопасности киберпространства специально определила необходимость защиты DNS. [30] Широкомасштабное развертывание 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 , были разработаны для снижения этой нагрузки. [31] Для решения этих проблем продолжаются значительные усилия по развертыванию DNSSEC, поскольку Интернет жизненно важен для многих организаций.
Среди первых последователей — Бразилия ( .br ), Болгария ( .bg ), Чешская Республика ( .cz ), Намибия ( .na ) [32] Пуэрто-Рико ( .pr ) и Швеция ( .se ), которые используют DNSSEC для своих национальных доменов верхнего уровня ; [33] RIPE NCC , который подписал все записи обратного просмотра (in-addr.arpa), делегированные ему Управлением по распределению номеров в Интернете (IANA). [34] ARIN также подписывает свои обратные зоны. [35] В феврале 2007 года TDC стал первым шведским интернет-провайдером, который начал предлагать эту функцию своим клиентам. [36]
IANA публично тестировала образец подписанного корня с июня 2007 года. В течение этого периода до производственного подписания корня также существовало несколько альтернативных якорей доверия. IKS Jena представила один 19 января 2006 года, [37] Internet Systems Consortium представил другой 27 марта того же года, [38] в то время как сама ICANN объявила о третьем 17 февраля 2009 года. [39]
2 июня 2009 года Afilias , поставщик услуг регистрации для зоны .org Public Interest Registry, подписал TLD .org. [40] Afilias и PIR также подробно рассказали 26 сентября 2008 года, что первая фаза, включающая крупных регистраторов, с которыми у них есть прочные рабочие отношения («друзья и семья»), станет первой, которая сможет подписать свои домены, начиная с «начала 2009 года». [41] 23 июня 2010 года 13 регистраторов были перечислены как предлагающие записи DNSSEC для доменов .ORG. [42]
VeriSign запустила пилотный проект, позволяющий доменам .com и .net регистрироваться самостоятельно в целях эксперимента NSEC3. 24 февраля 2009 года они объявили, что развернут DNSSEC на всех своих доменах верхнего уровня (.com, .net и т. д.) в течение 24 месяцев, [43] а 16 ноября того же года они заявили, что домены .com и .net будут подписаны к первому кварталу 2011 года, после задержек, вызванных техническими аспектами внедрения. [44] Эта цель была достигнута в срок [45] , и вице-президент Verisign по DNSSEC Мэтт Ларсон получил премию InfoWorld's Technology Leadership Award за 2011 год за свою роль в продвижении DNSSEC. [46] [47]
DNSSEC был впервые развернут на корневом уровне 15 июля 2010 года. [48] Ожидается, что это значительно упростит развертывание преобразователей DNSSEC, поскольку корневой якорь доверия может использоваться для проверки любой зоны DNSSEC, которая имеет полную цепочку доверия от корня. Поскольку цепочка доверия должна быть прослежена обратно до доверенного корня без прерывания для проверки, якоря доверия все равно должны быть настроены для безопасных зон, если какая-либо из зон выше них не является безопасной. Например, если зона "signed.example.org" была защищена, а зона "example.org" - нет, то, даже если зона ".org" и корень подписаны, якорь доверия должен быть развернут для проверки зоны.
Политические вопросы, связанные с подписанием соглашения, постоянно вызывают беспокойство, в первую очередь по поводу некоторых центральных вопросов:
В сентябре 2008 года ICANN и VeriSign опубликовали предложения по внедрению [49] , а в октябре Национальное управление по телекоммуникациям и информации (NTIA) обратилось к общественности с просьбой прокомментировать ситуацию [50] . Неясно, повлияли ли полученные комментарии на разработку окончательного плана развертывания.
3 июня 2009 года Национальный институт стандартов и технологий (NIST) объявил о планах подписать корень к концу 2009 года совместно с ICANN, VeriSign и NTIA. [51]
6 октября 2009 года на 59-й конференции RIPE ICANN и VeriSign объявили о запланированном графике развертывания DNSSEC в корневой зоне. [52] На встрече было объявлено, что он будет поэтапно развертываться на одном корневом сервере имен в месяц, начиная с 1 декабря 2009 года, а последний корневой сервер имен будет обслуживать подписанную зону DNSSEC 1 июля 2010 года, а корневая зона будет подписана с помощью RSA/SHA256 DNSKEY. [52] В течение периода поэтапного развертывания корневая зона будет обслуживать намеренно непроверяемую корневую зону (DURZ), которая использует фиктивные ключи, а финальная запись DNSKEY не будет распространена до 1 июля 2010 года. [53] Это означает, что ключи, которые использовались для подписи использования зоны, намеренно непроверяемы; Причиной этого развертывания было отслеживание изменений в моделях трафика, вызванных более крупными ответами на запросы, запрашивающие записи ресурсов DNSSEC.
Домен верхнего уровня .org был подписан с DNSSEC в июне 2010 года, за ним последовали .com , .net и .edu позднее в 2010 и 2011 годах. [54] [55] Национальные домены верхнего уровня могли размещать ключи, начиная с мая 2010 года. [ 56] По состоянию на ноябрь 2011 года более 25% доменов верхнего уровня были подписаны с DNSSEC. [57] [update]
25 января 2010 года корневой сервер L (ell) начал обслуживать преднамеренно непроверяемую корневую зону (DURZ). Зона использует подписи хэша SHA-2 (SHA-256), созданного с использованием алгоритма RSA , как определено в RFC 5702. По состоянию на май 2010 года все тринадцать корневых серверов начали обслуживать DURZ. [53] 15 июля 2010 года была подписана первая корневая полнофункциональная корневая зона DNSSEC с серийным номером SOA 2010071501. Корневые доверенные якоря доступны в IANA. [48]
Под корнем находится большой набор доменов верхнего уровня, которые должны быть подписаны для достижения полного развертывания DNSSEC. Список доменов верхнего уровня Интернета содержит сведения о том, какие из существующих доменов верхнего уровня были подписаны и связаны с корнем.
В марте 2006 года Internet Systems Consortium представил реестр DNSSEC Lookaside Validation. [58] DLV был призван упростить развертывание DNSSEC при отсутствии корневого якоря доверия. В то время предполагалось, что валидатору, возможно, придется поддерживать большое количество якорей доверия, соответствующих подписанным поддеревьям DNS. [59] Целью DLV было позволить валидаторам переложить усилия по управлению репозиторием якорей доверия на доверенную третью сторону. Реестр DLV поддерживал центральный список якорей доверия, вместо того чтобы каждый валидатор повторял работу по поддержанию своего собственного списка.
Для использования DLV требовался поддерживающий его валидатор, такой как BIND или Unbound , настроенный с якорем доверия для зоны DLV. Эта зона содержала записи DLV; [60] они имели точно такой же формат, как и записи DS, но вместо ссылки на делегированную подзону они ссылались на зону в другом месте дерева DNS. Когда валидатор не мог найти цепочку доверия от корня до RRset, который он пытался проверить, он искал запись DLV, которая могла бы предоставить альтернативную цепочку доверия. [61]
Пробелы в цепочке доверия, такие как неподписанные домены верхнего уровня или регистраторы, которые не поддерживали делегирование DNSSEC, означали, что администраторы доменов нижнего уровня могли использовать DLV, чтобы разрешить проверку своих данных DNS резолверами, настроенными на использование DLV. Это могло помешать развертыванию DNSSEC, сняв нагрузку с регистраторов и реестров TLD для надлежащей поддержки DNSSEC. DLV также добавил сложности, добавив больше участников и путей кода для проверки DNSSEC.
ISC вывела из эксплуатации свой реестр DLV в 2017 году. [62] Поддержка DLV была прекращена в BIND 9.12 и полностью удалена из BIND 9.16. [63] Непривязанная версия 1.5.4 (июль 2015 г.) пометила DLV как выведенный из эксплуатации в примере конфигурации и на странице руководства. [64] Knot Resolver и PowerDNS Recursor никогда не реализовывали DLV.
В марте 2020 года IETF опубликовала RFC 8749, отменяющий DLV как стандарт и переводящий RFC 4432 и RFC 5074 в статус «Исторический». [65]
Директорат по науке и технике Министерства внутренней безопасности США (DHS) спонсирует «Инициативу по развертыванию DNSSEC». Эта инициатива призывает «все секторы добровольно принять меры безопасности, которые улучшат безопасность инфраструктуры именования Интернета, как часть глобальных совместных усилий, в которых участвуют многие страны и организации в государственном и частном секторах». DHS также финансирует усилия по развитию DNSSEC и его развертыванию в федеральном правительстве США.
Сообщалось [66] , что 30 марта 2007 года Министерство внутренней безопасности США предложило «надежно передать ключ для подписи корневой зоны DNS в руки правительства США». Однако на встрече не присутствовали официальные лица правительства США, а комментарий, который послужил поводом для статьи, был сделан другой стороной. Позже Министерство внутренней безопасности прокомментировало [67] [68] то, почему, по их мнению, другие сделали ложный вывод о том, что правительство США сделало такое предложение: «Министерство внутренней безопасности США финансирует разработку технического плана по внедрению DNSSec и в октябре прошлого года распространило его первоначальный проект среди большого числа международных экспертов для комментариев. В проекте излагается ряд вариантов того, кто может быть держателем или «оператором» ключа корневой зоны, по сути сводящихся к государственному агентству или подрядчику. «Нигде в документе мы не делаем никаких предложений относительно личности оператора корневого ключа», — сказал Моган, менеджер по исследованиям и разработкам в области кибербезопасности Министерства внутренней безопасности».
Национальный институт стандартов и технологий (NIST) опубликовал 16 мая 2006 года специальное издание NIST 800-81 Secure Domain Name System (DNS) Deployment Guide с рекомендациями по развертыванию DNSSEC. NIST намеревался выпустить новые требования Федерального закона об управлении информационной безопасностью (FISMA) DNSSEC в NIST SP800-53-R1, ссылаясь на это руководство по развертыванию. У агентств США тогда был бы один год после окончательной публикации NIST SP800-53-R1, чтобы выполнить эти новые требования FISMA. [69] Однако на тот момент NSEC3 еще не был завершен. NIST предложил использовать разделенные домены — метод, который, как известно, возможен, но его сложно правильно развернуть, и который имеет указанные выше недостатки безопасности.
22 августа 2008 года Управление по управлению и бюджету (OMB) опубликовало меморандум, требующий от федеральных агентств США развернуть DNSSEC на всех сайтах .gov; корень .gov должен быть подписан к январю 2009 года, а все поддомены в .gov должны быть подписаны к декабрю 2009 года. [70] Хотя меморандум фокусируется на сайтах .gov, Агентство информационных систем обороны США заявляет, что оно намерено выполнить требования OMB DNSSEC также и в домене .mil (военный домен США). Кэролин Даффи Марсан из NetworkWorld заявила, что DNSSEC «не был широко развернут, потому что страдает от классической дилеммы «курица или яйцо»… с мандатом OMB, похоже, яйцо треснуло». [71]
Несколько интернет-провайдеров начали развертывать DNSSEC-валидирующие рекурсивные резолверы DNS. Comcast стал первым крупным интернет-провайдером, который сделал это в Соединенных Штатах, объявив о своих намерениях 18 октября 2010 года [72] [73] и завершив развертывание 11 января 2012 года. [74]
Согласно исследованию APNIC , доля клиентов, которые используют исключительно DNS-резолверы, выполняющие проверку DNSSEC, выросла до 8,3% в мае 2013 года. [75] Около половины этих клиентов использовали общедоступный DNS-резолвер Google .
В сентябре 2015 года компания Verisign анонсировала свой бесплатный публичный сервис DNS-резолвера [76] , и хотя об этом не упоминалось в пресс-релизах, он также выполняет проверку DNSSEC.
К началу 2016 года мониторинг APNIC показал, что доля клиентов, которые используют исключительно DNS-резолверы, выполняющие проверку DNSSEC, увеличилась примерно до 15%. [77]
Публичный рекурсивный DNS- сервер Google включил проверку DNSSEC 6 мая 2013 года. [78]
BIND , самое популярное программное обеспечение для управления DNS, включает поддержку DNSSEC по умолчанию, начиная с версии 9.5.
Публичный рекурсивный DNS Quad9 выполнил проверку DNSSEC на своем основном адресе 9.9.9.9 с момента своего создания 11 мая 2016 года. Quad9 также предоставляет альтернативную службу, которая не выполняет проверку DNSSEC, в основном для отладки. [79]
В сентябре 2023 года Microsoft объявила, что будет использовать DNSSEC (через DANE ) для проверки подлинности сертификатов во время SMTP-коммуникаций. [80]
Джефф Хатсон утверждал, что от развертывания DNSSEC следует отказаться. [81]
Для развертывания DNSSEC требуется программное обеспечение на стороне сервера и клиента. Некоторые из инструментов, поддерживающих DNSSEC, включают:
Клиент Windows DNS — это заглушка-резолвер...
DNS-клиент в Windows Server 2008 R2 и Windows® 7 — это непроверяющий безопасный заглушечный преобразователь.
Заглушки-резолверы по определению являются минимальными DNS-резолверами, которые используют режим рекурсивных запросов для передачи большей части работы по разрешению DNS рекурсивному серверу имен.Более раннее определение было дано в более раннем RFC: Роберт Брейден (октябрь 1989 г.). Брейден, Р. (ред.). RFC 1123 — Требования к интернет-хостам — применение и поддержка. IETF ( Internet Engineering Task Force ). стр. 74. doi :10.17487/RFC1123.
«Заглушка-резолвер» полагается на службы рекурсивного сервера имен [...]