Расширения безопасности системы доменных имен - Domain Name System Security Extensions

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

Обзор

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

DNSSEC был разработан для защиты приложений (и кэширующих преобразователей, обслуживающих эти приложения) от использования поддельных или измененных данных 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 ).

DNSSEC не обеспечивать конфиденциальность данных; в частности, все ответы DNSSEC аутентифицируются, но не шифруются. DNSSEC не защищать от DoS атакует напрямую, хотя косвенно дает определенные преимущества (поскольку проверка подписи позволяет использовать потенциально ненадежные стороны; это верно только в том случае, если DNS-сервер использует самозаверяющий сертификат, что не рекомендуется для DNS-серверов с выходом в Интернет).^{[нужна цитата ]}

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

Спецификации DNSSEC (называемые DNSSEC-бис) подробно описывают текущий протокол DNSSEC. Видеть RFC 4033, RFC 4034, и RFC 4035. С публикацией этих новых RFC (март 2005 г.), более раннего RFC, RFC 2535 устарело.

Широко распространено мнение^[1] что защита DNS критически важна для защиты Интернета в целом, но развертывание DNSSEC было затруднено (по состоянию на 22 января 2010 г.^{[Обновить]}) несколькими трудностями:

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

Майкрософт Виндоус использует преобразователь заглушек ; Windows 7 и выше, в частности, используют непроверяющий (но с поддержкой DNSSEC).^[2][3] Чтобы действительно полагаться на службы DNSSEC, этот резолвер-заглушка должен доверять как рекурсивные серверы имен в вопросе (который обычно контролируется Интернет-провайдер ) и каналы связи между ним и этими серверами имен с использованием таких методов, как IPsec (использование которого^{[когда? ]} не распространен),^[4] SIG (0) или TSIG.^[5]

Операция

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 содержит запись RRSIG DNS в дополнение к запрошенному типу записи. Запись RRSIG - это цифровая подпись ответа DNS набор записей ресурсов. Цифровая подпись проверяется путем нахождения правильного открытого ключа в записи DNSKEY. Записи NSEC и NSEC3 используются для предоставления криптографических свидетельств отсутствия какой-либо записи RR. Запись DS используется для аутентификации ключей DNSKEY в процедуре поиска с использованием цепочки доверия. Записи NSEC и NSEC3 используются для надежной защиты от спуфинга.

Алгоритмы

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

Поле алгоритма	Алгоритм	Источник	Статус реализации[7]
1	ЮАР /MD5		Не должен реализовывать
3	DSA /SHA-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 /SHA-256	RFC 6605	Необходимый
14	ECDSA /SHA-384		Необязательный
15	Ed25519	RFC 8080	рекомендуемые
16	Ed448		Необязательный

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

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

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

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

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

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

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

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

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

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

Резолверы заглушек

Резолверы-заглушки - это «минимальные резолверы DNS, которые используют режим рекурсивных запросов для переноса большей части работы по разрешению DNS на рекурсивный сервер имен».^[12] Резолвер-заглушка просто перенаправит запрос на рекурсивный сервер имен и будет использовать бит аутентифицированных данных (AD) в ответе в качестве подсказки, чтобы выяснить, смог ли рекурсивный сервер имен проверить подписи для всех данных в Разделы "Ответ" и "Авторитет" ответа ".^[5] Майкрософт Виндоус использует преобразователь заглушек, а Windows Server 2008 R2 и Windows 7, в частности, используют непроверяющий преобразователь заглушек, поддерживающий биты AD.^[2][3]

А проверка заглушки преобразователя также потенциально может выполнить собственную проверку подписи, установив бит Checking Disabled (CD) в своих сообщениях запроса.^[5] Проверяющий преобразователь заглушек использует бит CD для выполнения собственной рекурсивной аутентификации. Использование такого проверяющего преобразователя заглушек дает клиенту сквозную безопасность DNS для доменов, реализующих DNSSEC, даже если интернет-провайдер или соединение с ним не являются доверенными.

Чтобы непроверяющий преобразователь заглушек мог реально полагаться на службы DNSSEC, преобразователь заглушек должен доверять обоим рассматриваемым рекурсивным серверам имен (которые обычно контролируются интернет-провайдер ) и каналы связи между ним и этими серверами имен, используя такие методы, как IPsec, SIG (0) или TSIG.^[5] Использование IPsec не имеет широкого распространения.^[4]

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

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

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

Подписи и подпись зоны

Чтобы ограничить атаки повторного воспроизведения, существуют не только обычные значения TTL DNS для целей кэширования, но и дополнительные отметки времени в записях 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 находились в родительской зоне.

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

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

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

Поддержка сшитых сертификатов DNSSEC была включена в Гугл Хром 14,^[15] но позже был удален.^[16] За Mozilla Firefox, поддержка была предоставлена ​​дополнением^[17] в то время как нативная поддержка в настоящее время ждет, чтобы кто-то начал над ней работать.^[18]

История

DNS - критически важный и фундаментальный интернет-сервис, но в 1990 г. Стив Белловин обнаружил в нем серьезные недостатки безопасности. Исследования по его защите начались и резко прогрессировали, когда его статья была обнародована в 1995 году.^[19] Начальный 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-бис при необходимости отличить его от оригинального подхода DNSSEC RFC 2535. В этой новой версии используются «записи ресурсов подписывающего лица (DS)», чтобы обеспечить дополнительный уровень косвенности в точках делегирования между родительской и дочерней зоной. В новом подходе, когда изменяется главный открытый ключ дочернего элемента, вместо шести сообщений для каждой записи в дочернем элементе есть одно простое сообщение: дочерний элемент отправляет новый открытый ключ своему родительскому элементу (подписанному, конечно). Родители просто хранят один главный открытый ключ для каждого ребенка; это гораздо практичнее. Это означает, что родителю передается небольшой объем данных вместо того, чтобы обмениваться огромными объемами данных между родителем и потомками. Это означает, что клиентам нужно проделать немного больше работы при проверке ключей. В частности, для проверки KEY RRset зоны DNS требуется две операции проверки подписи вместо той, которая требуется RFC 2535 (это не влияет на количество проверенных подписей для других типов RRset). Большинство считает это небольшой платой, поскольку это делает развертывание DNSSEC более практичным.

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

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

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

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

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

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

Интернет является критически важной инфраструктурой, но его работа зависит от фундаментально небезопасной DNS. Таким образом, существует серьезный стимул для защиты DNS, и развертывание DNSSEC обычно считается важной частью этих усилий. Например, в США Национальная стратегия защиты киберпространства специально обозначили необходимость защиты DNS.^[22]Широкомасштабное развертывание 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, были разработаны для уменьшения этой нагрузки.^[23] Для решения этих проблем прилагаются значительные усилия по развертыванию DNSSEC, поскольку Интернет так важен для многих организаций.

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

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

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

2 июня 2009 г. Афилиас, поставщик услуг реестра для Реестр общественных интересов Зона .org подписала домен верхнего уровня .org.^[32] Afilias и PIR также подробно рассказали 26 сентября 2008 г., что первая фаза с участием крупных регистраторов, с которыми у нее есть прочные рабочие отношения («друзья и семья»), будет первой, кто сможет подписать свои домены, начиная с «начала 2009 г. .^[33] 23 июня 2010 г. 13 регистраторов были перечислены как предлагающие записи DNSSEC для доменов .ORG.^[34]

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

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

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

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

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

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

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

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

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

В .org домен верхнего уровня был подписан с DNSSEC в июне 2010 года, после чего .com, .сеть, и .edu позже в 2010 и 2011 гг.^[46][47] Домены верхнего уровня с кодом страны смогли передать ключи с мая 2010 года.^[48] По состоянию на ноябрь 2011 г.^{[Обновить]} более 25% доменов верхнего уровня подписаны с помощью DNSSEC.^[49]

Выполнение

25 января 2010 г. корневой сервер L (ell) начал обслуживать Намеренно недопустимая корневая зона (ДУРЗ). В зоне используются подписи SHA-2 (SHA-256) хэш, созданный с использованием ЮАР алгоритм, как определено в RFC 5702.^[50][51][52] По состоянию на май 2010 года все тринадцать корневых серверов начали обслуживать DURZ.^[45] 15 июля 2010 г. была подписана первая корневая полноценная корневая зона DNSSEC с серийным номером SOA 2010071501. Корневые якоря доверия доступно в IANA.^[40]

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

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

Проверка DNSSEC Lookaside - историческая

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

Для использования DLV был необходим валидатор, который его поддерживает, например СВЯЗЫВАТЬ или же Несвязанный, настроенный с помощью якоря доверия для зоны DLV. Эта зона содержала записи DLV;^[55] они имели точно такой же формат, что и записи DS, но вместо ссылки на делегированную подзону они ссылались на зону в другом месте в дереве DNS. Когда валидатор не смог найти цепочку доверия от корня до RRset, которую он пытается проверить, он искал запись DLV, которая могла бы предоставить альтернативную цепочку доверия.^[56]

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

ISC сняла с эксплуатации свой реестр DLV в 2017 году.^[57] Поддержка DLV устарела в BIND 9.12 и полностью удалена из BIND 9.16.^[58] Несвязанная версия 1.5.4 (июль 2015 г.) пометила DLV как списанную в примере конфигурации и на странице руководства [^[59]]. Узел Resolver и PowerDNS Recursor никогда не реализовывали DLV.

В марте 2020 г. IETF опубликовано RFC 8749, отказавшись от стандарта DLV и RFC 4432 и RFC 5074 до статуса «Исторический».^[60]

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

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

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

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

В Национальный институт стандартов и технологий (NIST) 16 мая 2006 г. опубликовал специальную публикацию NIST 800-81 «Руководство по развертыванию защищенной системы доменных имен (DNS)» с инструкциями по развертыванию DNSSEC. NIST намеревался выпустить новые требования DNSSEC Federal Information Security Management Act (FISMA) в NIST SP800-53-R1, ссылаясь на это руководство по развертыванию. У агентств США был бы один год после окончательной публикации NIST SP800-53-R1, чтобы соответствовать этим новым требованиям FISMA.^[64] Однако на тот момент NSEC3 не был завершен. NIST предложил использовать разделенные домены, метод, который, как известно, возможен, но его сложно правильно развернуть, и он имеет недостатки безопасности, указанные выше.

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

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

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

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

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

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

Поддержка DNSSEC

Google Public DNS - это бесплатная общедоступная служба DNS, полностью поддерживающая DNSSEC.

6 мая 2013 г. Google Public DNS включил проверку DNSSEC по умолчанию; Это означает, что все запросы будут проверяться, если клиенты явно не откажутся от них.^[73]

СВЯЗЫВАТЬ, самое популярное программное обеспечение для управления DNS, по умолчанию включает поддержку DNSSEC, начиная с версии 9.5.

Quad9 по умолчанию включает DNSSEC на своих основных серверах. Однако они также предоставляют серверы, которые не используют DNSSEC на разных IP-адресах.^[74]

Публикации IETF

• RFC 2535 Расширения безопасности системы доменных имен
• RFC 3225 Указывая на поддержку DNSSEC резолвером
• RFC 3226 Требования к размеру сообщения сервера / распознавателя DNSSEC и IPv6 A6
• RFC 3833 Анализ угроз системы доменных имен
• RFC 4033 Введение в безопасность DNS и требования (DNSSEC-бис)
• RFC 4034 Записи ресурсов для расширений безопасности DNS (DNSSEC-бис)
• RFC 4035 Модификации протокола для расширений безопасности DNS (DNSSEC-бис)
• RFC 4398 Хранение сертификатов в системе доменных имен (DNS)
• RFC 4431 Запись ресурса DNS с дополнительной проверкой DNSSEC (DLV)
• RFC 4470 Минимальное покрытие записей NSEC и подписание DNSSEC в режиме онлайн
• RFC 4509 Использование SHA-256 в записях ресурсов (RR) лица, подписывающего делегирование (DS) DNSSEC
• RFC 4955 Эксперименты по безопасности DNS (DNSSEC)
• RFC 5011 Автоматические обновления якорей доверия безопасности DNS (DNSSEC)
• RFC 5155 DNSSEC Hashed Authenticated Denial of Existence
• RFC 5702 Использование алгоритмов SHA-2 с RSA в записях ресурсов DNSKEY и RRSIG для DNSSEC
• RFC 6605 Алгоритм цифровой подписи (DSA) с эллиптической кривой для DNSSEC
• RFC 6725 Безопасность DNS (DNSSEC) Алгоритм DNSKEY Обновления реестра IANA
• RFC 6781 Практика эксплуатации DNSSEC, версия 2
• RFC 6840 Разъяснения и примечания по реализации для безопасности DNS (DNSSEC)
• RFC 7344 Автоматизация поддержки доверия делегирования DNSSEC
• RFC 7583 Рекомендации по синхронизации ключевого ролловера DNSSEC
• RFC 8080 Алгоритм цифровой безопасности Edwards-Curve (EdDSA) для DNSSEC
• RFC 8624 Требования к реализации алгоритма и руководство по использованию DNSSEC
• RFC 8749 Перемещение альтернативной проверки DNSSEC (DLV) в исторический статус

Инструменты

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

• Windows 7 и Windows Server 2008 R2 включить «учитывающий безопасность» преобразователь заглушек, который может различать безопасные и небезопасные ответы рекурсивного сервера имен. Windows Server 2012 DNSSEC совместим с безопасными динамическими обновлениями с зонами, интегрированными в Active Directory, а также с репликацией ключей привязки Active Directory на другие такие серверы.^[75][76]
• СВЯЗЫВАТЬ, самый популярный сервер имен DNS (который включает копать землю ), включает более новую DNSSEC-бис (Записи DS), а также поддержка записей NSEC3.
• Несвязанный - это сервер имен DNS, который был написан с нуля и разработан на основе концепций DNSSEC.
• mysqlBind GPL Программное обеспечение для управления DNS для DNS ASP теперь поддерживает DNSSEC.
• OpenDNSSEC является назначенным инструментом подписи DNSSEC, использующим PKCS # 11 взаимодействовать с аппаратные модули безопасности.
• Узел DNS добавлена ​​поддержка автоматической подписи DNSSEC в версии 1.4.0.
• PowerDNS полностью поддерживает DNSSEC, начиная с версии 3.0, в режимах с предварительной подписью и прямой подписью.
• DNSSEC: Что это такое и почему важно внедрять надолго? — Проверь это Инициатива интернет-сообщества и правительства Нидерландов

Смотрите также

• DNSCrypt
• DNSCurve
• EDNS
• TSIG
• RPKI

Рекомендации

1. Интервью с Дэном Камински о DNSSEC (25 июня 2009 г.) Интервью Камински: DNSSEC обращается к межорганизационному доверию и безопасности
2. «Понимание DNSSEC в Windows». Microsoft. 7 октября 2009 г. Клиент Windows DNS - это преобразователь заглушек ...
3. «Расширения безопасности DNS (DNSSEC)». Microsoft. 21 октября 2009 г. DNS-клиент в Windows Server 2008 R2 и Windows® 7 является непроверяющим преобразователем заглушек, учитывающим безопасность.
4. Муньос Мерино, Педро Дж .; Гарсиа-Мартинес, Альберто; Органеро, Марио Муньос; Клоос, Карлос Дельгадо (2006). Меерсман, Роберт; Тари, Захир; Эрреро, Эрреро Мартин (ред.). Включение практической аутентификации IPsec для Интернета (PDF). На пути к осмысленным интернет-системам 2006: Семинары OTM 2006. 1. Springer. Архивировано из оригинал (PDF) на 2012-04-26.
5. «RFC 4033: Введение в безопасность DNS и требования». Интернет-сообщество. Март 2005: 12.
6. «Номера алгоритмов безопасности системы доменных имен (DNSSEC)». IANA. 2010-07-12. Получено 2010-07-17.
7. "RFC-8624". IETF.
8. "RFC-4035". IETF.
9. Конрад, Д. «Указывая на поддержку DNSSEC резолвером». Инженерная группа Интернета. Получено 27 апреля 2017.
10. "Корневой DNSSEC".
11. http://www.v3.co.uk/v3-uk/news/2039287/verisign-adds-dnssec-com-domain-boost-online-security/
12. «RFC 4033: Введение в безопасность DNS и требования». Интернет-сообщество. Март 2005 г .: 11. Резолверы-заглушки, по определению, представляют собой минимальные резолверы DNS, которые используют режим рекурсивного запроса, чтобы переложить большую часть работы по разрешению DNS на рекурсивный сервер имен. Более раннее определение было дано в более раннем RFC: Роберт Брейден (октябрь 1989 г.). «RFC 1123 - Требования к Интернет-хостам - Применение и поддержка». IETF (Инженерная группа Интернета ): 74. «Резолвер заглушек» полагается на услуги рекурсивного сервера имен [...]
13. корневые якоря
14. IETF: аутентификация именованных объектов на основе DNS (датчанин)
15. «Императорский фиолетовый». Получено 2011-11-26.
16. "хромовый мерзавец". Получено 2013-03-09.
17. «Валидатор DNSSEC / TLSA».
18. Bugzilla @ Mozilla: ошибка 672600 - использование цепочки DNSSEC / DANE, скрепленной в рукопожатие TLS, при проверке цепочки сертификатов.
19. «Использование системы доменных имен для взлома системы» Стив Белловин, 1995
20. "NSEC5: Доказуемое предотвращение перечисления зон DNSSEC".
21. "DNSSEC сделано правильно". 2015-01-29.
22. НАС. Национальная стратегия защиты киберпространства, п. 30 февраля 2003 г.
23. Мецгер, Перри; Уильям Аллен Симпсон и Пол Викси. «Повышение безопасности TCP с помощью надежных файлов cookie» (PDF). Usenix. Получено 2009-12-17.
24. https://ccnso.icann.org/de/node/7603
25. Электронный информационный центр конфиденциальности (EPIC) (27 мая 2008 г.). DNSSEC
26. Политика RIPE NCC в отношении DNSSEC В архиве 22 октября 2007 г. Wayback Machine
27. План развертывания ARIN DNSSEC
28. Эклунд-Лёвиндер, Анн-Мари (12 февраля 2012 г.). "[dns-wg] Шведский интернет-провайдер TCD Song принимает DNSSEC". список рассылки dns-wg. RIPE NCC. Получено 2 декабря 2012.
29. dns-wg archive: список подписанных зон В архиве 5 марта 2007 г. Wayback Machine
30. ISC запускает реестр DLV, чтобы начать развертывание DNSSEC во всем мире В архиве 18 ноября 2008 г. Wayback Machine
31. Временный репозиторий якорей доверия
32. .ORG - первый открытый домен верхнего уровня, подписанный с помощью DNSSEC
33. Шон Майкл Кернер. ".ORG самый безопасный домен?". www.internetnews.com. Получено 2008-09-27.
34. "Список регистраторов .ORG - с включенным DNSSEC вверху". Получено 2010-06-23.
35. VeriSign: Мы будем поддерживать безопасность DNS в 2011 году В архиве 3 марта 2009 г. Wayback Machine
36. VeriSign: крупное обновление безопасности в Интернете к 2011 г.
37. Домен .com наконец-то безопасен
38. Мэтт Ларсон из Verisign получил награду InfoWorld Technology Leadership Award 2011
39. Награда за лидерство в сфере технологий InfoWorld 2011
40. «Обновление статуса корневого DNSSEC, 16.07.2010». 16 июля 2010 г.
41. Сингел, Райан (8 октября 2006 г.). «Федералы начинают двигаться через дыру в чистой безопасности». Проводные новости. CondéNet. Получено 2008-10-09.
42. «Пресс-релиз: NTIA ожидает комментариев общественности по поводу развертывания технологии безопасности в системе доменных имен Интернета» (Пресс-релиз). Национальное управление по телекоммуникациям и информации Министерства торговли США. 9 октября 2008 г.. Получено 2008-10-09.
43. «Департамент торговли будет работать с ICANN и VeriSign над повышением безопасности и стабильности системы доменных имен и адресации в Интернете» (Пресс-релиз). Национальный институт стандартов и технологий. 3 июня 2009 г.
44. «DNSSEC для корневой зоны» (PDF).
45. Хатчинсон, Джеймс (6 мая 2010 г.). «ICANN и Verisign поместили последние кусочки головоломки в сагу о DNSSEC». NetworkWorld.
46. «DNSSEC станет стандартом для доменов .ORG к концу июня». Архивировано из оригинал на 2010-03-15. Получено 2010-03-24.
47. The Inquirer: Verisign развертывает DNSSEC в TLD .com
48. Больше безопасности для корневых DNS-серверов Heise Online, 24 марта 2010 г.
49. CircleID: новости DNSSEC с конференции ICANN 42 в Дакаре
50. «Техническая архитектура верхнего уровня корневой зоны DNSSEC» (PDF).
51. RFC 5702, §2.1. «Открытые ключи RSA для использования с RSA / SHA-256 хранятся в ресурсных записях (RR) DNSKEY с номером алгоритма 8.»
52. RFC 5702, §3.1. «Подписи RSA / SHA-256 хранятся в DNS с использованием ресурсных записей (RR) RRSIG с алгоритмом номер 8».
53. ISC запускает реестр DLV, чтобы начать развертывание DNSSEC во всем мире В архиве 14 июня 2011 г. Wayback Machine
54. RFC 5011, «Автоматические обновления якорей доверия безопасности DNS (DNSSEC)»
55. RFC 4431, "Запись ресурса DNS для проверки DNSSEC (DLV)"
56. RFC 5074, "Альтернативная проверка DNSSEC (DLV)"
57. «DLV заменена пустой подписанной зоной - Консорциум интернет-систем». www.isc.org. Получено 2020-06-05.
58. «BIND 9.16.0, стабильная ветвь на 2020 год и далее - Консорциум интернет-систем». www.isc.org. Получено 2020-06-05.
59. «Несвязанные изменения 1.5.4». NLnet Labs. Получено 2020-06-05.
60. Меккинг, В.; Махони, Д. (Март 2020 г.). Перемещение альтернативной проверки DNSSEC (DLV) в исторический статус. IETF. Дои:10.17487 / RFC8749. RFC 879. Получено 3 июн 2020.
61. Министерству внутренних дел и безопасности требуется главный ключ для DNS В архиве 6 апреля 2007 г. Wayback Machine Heise Новости, 30 марта 2007 г.
62. Анализ: владения ключами от Интернета UPI, 21 апреля 2007 г.
63. Анализ UPI: владение ключами к Интернету 24 марта 2011 г. - первая ссылка мертва, предполагается, что это тот же контент.
64. Информационный бюллетень инициативы по развертыванию DNSSEC - Том 1, номер 2 В архиве 22 ноября 2007 г. Wayback Machine, Июнь 2006 г.
65. Меморандум для директоров по информационным технологиям В архиве 2008-09-16 на Wayback Machine Администрация президента - Управление по вопросам управления и бюджета, 22 августа 2008 г.
66. Федералы усиливают безопасность домена .gov В архиве 25 сентября 2008 г. Wayback Machine Network World, 22 сентября 2008 г.
67. Блог Comcast - Начинается развертывание безопасности DNS, 18 октября 2010 г.
68. Видео с объявлением о государственной службе Comcast DNSSEC В архиве 2010-10-21 на Wayback Machine, 18 октября 2010 г.
69. Comcast завершает развертывание DNSSEC, 11 января 2012 г.
70. Джефф Хьюстон: DNS, DNSSEC и общедоступная служба DNS Google (CircleID)
71. Представляем Verisign Public DNS
72. Использование валидации DNSSEC для всего мира (XA)
73. Google Public DNS теперь поддерживает проверку DNSSEC Блог Google Code, 1 июня 2013 г.
74. "Quad9 FAQ". Quad9. Получено 7 июля, 2018.
75. Сешадри, Шьям (11 ноября 2008 г.). «DNSSEC на DNS-клиенте Windows 7». Порт 53. Microsoft.
76. DNSSEC в Windows Server

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

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

внешняя ссылка

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