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

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

Системы доменных имен Расширение безопасности ( DNSSEC ) представляет собой набор Engineering Task Force Интернета (IETF) спецификацию для обеспечения определенных видов информации , представленных в системе доменных имен (DNS), которая используется в Internet Protocol сетей (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- атак, хотя косвенно дает некоторые преимущества (поскольку проверка подписи позволяет использовать потенциально ненадежные стороны). ^{[ необходима цитата ]}

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

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

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

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

Операция [ править ]

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

Записи ресурсов [ править ]

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

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 был разработан с возможностью расширения, чтобы при обнаружении атак на существующие алгоритмы можно было вводить новые с обратной совместимостью . В следующей таблице определены наиболее часто используемые алгоритмы безопасности по состоянию на апрель 2013 г .: ^[2]

Процедура поиска [ править ]

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

Рекурсивные серверы имен [ править ]

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

1. Процесс начинается, когда распознаватель, поддерживающий безопасность, устанавливает бит флага «DO» («DNSSEC OK» ^[7] ) в запросе DNS. Поскольку бит DO находится в битах расширенного флага, определенных механизмами расширения для DNS (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». Если есть запись DS для "example.com", но нет записи RRSIG в ответе, что-то не так и, возможно, происходит атака посредника , удаляющая информацию DNSSEC и изменяющая записи A. Или это может быть сломанный сервер имен, не обращающий внимания на безопасность, который по пути удалил бит флага DO из запроса или запись RRSIG из ответа. Или это может быть ошибка конфигурации.

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

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

Резолверы заглушек [ править ]

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

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

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

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

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

Аутентификации цепь представляет собой ряд связанных между собой 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 была включена в Google Chrome 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-bis.при необходимости отличить его от исходного подхода DNSSEC RFC 2535. Эта новая версия использует «записи ресурсов подписывающего делегирования (DS)», чтобы обеспечить дополнительный уровень косвенности в точках делегирования между родительской и дочерней зоной. В новом подходе при изменении главного открытого ключа дочернего элемента вместо шести сообщений для каждой записи в дочернем элементе есть одно простое сообщение: дочерний элемент отправляет новый открытый ключ своему родителю (подписанному, конечно). Родители просто хранят один главный открытый ключ для каждого ребенка; это намного практичнее. Это означает, что родителю передается небольшой объем данных вместо того, чтобы обмениваться огромными объемами данных между родителем и потомками. Это означает, что клиентам нужно проделать немного больше работы при проверке ключей. В частности, проверка зоны DNS »s KEY RRset требует двух операций проверки подписи вместо одной, требуемой 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, в которой пары доменов лексически окружают запрашиваемый домен. Например, запрос for 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), делегированные ему от Internet Assigned Numbers Authority (IANA). ^[26] ARIN также подписывает свои обратные зоны.^[27] In February 2007, TDC became the first Swedish ISP to start offering this feature to its customers.^[28]

IANA publicly tested a sample signed root since June 2007. During this period prior to the production signing of the root, there were also several alternative trust anchors. The IKS Jena introduced one on January 19, 2006,^[29] the Internet Systems Consortium introduced another on March 27 of the same year,^[30] while ICANN themselves announced a third on February 17, 2009.^[31]

2 июня 2009 г. Afilias , поставщик услуг реестра для зоны .org Public Interest Registry, подписал TLD .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) объявил о планах подписать корневой каталог к ​​концу 2009 г. совместно с ICANN, VeriSign и NTIA. ^[43]

6 октября 2009 г. на 59-й конференции RIPE Conference ICANN и VeriSign объявили о запланированном графике развертывания для развертывания DNSSEC в корневой зоне. ^[44] На собрании было объявлено, что он будет постепенно развертываться на одном корневом сервере имен в месяц, начиная с 1 декабря 2009 г., причем последний корневой сервер имен будет обслуживать подписанную зону DNSSEC 1 июля 2010 г., а корневой сервер зона будет подписана с помощью ключа DNS RSA / SHA256. ^[44] В течение периода инкрементного развертывания корневая зона будет обслуживать преднамеренно недопустимую корневую зону (DURZ), в которой используются фиктивные ключи, причем окончательная запись DNSKEY не будет распространяться до 1 июля 2010 года. ^[45] This means the keys that were used to sign the zone use are deliberately unverifiable; the reason for this deployment was to monitor changes in traffic patterns caused by the larger responses to queries requesting DNSSEC resource records.

The .org top-level domain has been signed with DNSSEC in June 2010, followed by .com, .net, and .edu later in 2010 and 2011.^[46][47] Country code top-level domains were able to deposit keys starting in May 2010.^[48] As of November 2011^{[Обновить]} more than 25% of top-level domains are signed with DNSSEC.^[49]

Implementation[edit]

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

Развертывание на уровне TLD [ править ]

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

Альтернативная проверка DNSSEC - историческая [ править ]

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

Для использования DLV был необходим валидатор, который его поддерживает, например BIND или Unbound , настроенный с привязкой доверия для зоны 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 в федеральном правительстве США [ править ]

Этот раздел необходимо обновить . Обновите эту статью, чтобы отразить недавние события или новую доступную информацию. ( Ноябрь 2015 г. )

The National Institute of Standards and Technology (NIST) published NIST Special Publication 800-81 Secure Domain Name System (DNS) Deployment Guide on May 16, 2006, with guidance on how to deploy DNSSEC. NIST intended to release new DNSSEC Federal Information Security Management Act (FISMA) requirements in NIST SP800-53-R1, referencing this deployment guide. U.S. agencies would then have had one year after final publication of NIST SP800-53-R1 to meet these new FISMA requirements.^[64] However, at the time NSEC3 had not been completed. NIST had suggested using split domains, a technique that is known to be possible but is difficult to deploy correctly, and has the security weaknesses noted above.

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]

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

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

Публикации IETF [ править ]

• RFC 2535 Расширения безопасности системы доменных имен
• RFC 3225, указывающий, что резольвер поддерживает DNSSEC
• RFC 3226 DNSSEC и IPv6 A6 A6 Aware Server / Resolver Требования к размеру сообщения
• RFC 3833 Анализ угроз системы доменных имен
• RFC 4033 Введение в безопасность DNS и требования ( DNSSEC-bis )
• RFC 4034 Записи ресурсов для расширений безопасности DNS ( DNSSEC-bis )
• RFC 4035 Модификации протокола для расширений безопасности DNS ( DNSSEC-bis )
• 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 Security (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]}
• BIND , самый популярный сервер имен DNS (включая dig ), включает в себя новый протокол DNSSEC-bis (записи DS), а также поддержку записей NSEC3.
• Несвязанный - это сервер имен 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
• DNSCurve
• Механизмы расширения для DNS (EDNS)
• TSIG
• Инфраструктура открытых ключей ресурсов (RPKI)

Ссылки [ править ]

Дальнейшее чтение [ править ]

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

Внешние ссылки [ править ]

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