Расширения безопасности DNS (DNSSEC)

Введение

Комплекс спецификаций IETF для защиты определенных видов информации, предоставляемой DNS

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

Операция

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

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

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

DNS is implemented by the use of several resource records. To implement DNSSEC, several new DNS record types were created or adapted to use with DNSSEC:
RRSIG (resource record signature) Contains the DNSSEC signature for a record set. DNS resolvers verify the signature with a public key, stored in a DNSKEY record. DNSKEY Contains the public key that a DNS resolver uses to verify DNSSEC signatures in RRSIG records. DS (delegation signer) Holds the name of a delegated zone. References a DNSKEY record in the sub delegated zone. The DS record is placed in the parent zone along with the delegating NS records. NSEC (next secure record) Contains a link to the next record name in the zone and lists the record types that exist for the record's name. DNS resolvers use NSEC records to verify the non existence of a record name and type as part of DNSSEC validation. NSEC3 (next secure record version 3) Contains links to the next record name in the zone (in hashed name sorting order) and lists the record types that exist for the name covered by the hash value in the first label of the NSEC3 record's own name. These records can be used by resolvers to verify the non existence of a record name and type as part of DNSSEC validation. NSEC3 records are similar to NSEC records, but NSEC3 uses cryptographically hashed record names to avoid the enumeration of the record names in a zone. NSEC3PARAM (next secure record version 3 parameters) Authoritative DNS servers use this record to calculate and determine which NSEC3 records to include in responses to DNSSEC requests for non existing names/types. When DNSSEC is used, each answer to a DNS lookup contains an RRSIG DNS record, in addition to the record type that was requested. The RRSIG record is a digital signature of the answer DNS resource record set. The digital signature is verified by locating the correct public key found in a DNSKEY record. The NSEC and NSEC3 records are used to provide cryptographic evidence of the non existence of any Resource Record (RR). The DS record is used in the authentication of DNSKEYs in the lookup procedure using the chain of trust. NSEC and NSEC3 records are used for robust resistance against spoofing.

Алгоритмы

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

Алгоритм | Поле | Источник алгоритма | Подпись DNSSEC | Валидация DNSSEC
------- | -------- | -------- | -------- | --------
1 | RSA/MD5 | | |
3 | DSA/SHA-1 | | |
5 | RSA/SHA-1 | | |
6 | DSA NSEC3 SHA-1 | | |
7 | RSA SHA-1 NSEC3 SHA-1 | | |
8 | RSA/SHA-256 | | |
10 | RSA/SHA-512 | | |
12 | GOST R 34.10-2001 | | |
13 | ECDSA P-256/SHA-256 | | |
14 | ECDSA P-384/SHA-384 | | |
15 | Ed25519 | Рекомендуется | Рекомендуется |
16 | Ed448 | | Рекомендуется |

Хеш-функция | Поле | Источник хеш-функции | Делегирование DNSSEC | Валидация DNSSEC
------- | -------- | -------- | -------- | --------
1 | SHA-1 | | |
2 | SHA-256 | | |
3 | GOST R 34.10-2001 | | |
4 | SHA-384 | | Рекомендуется |

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

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

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

Используя модель цепочки доверия, запись Delegation Signer (DS) в родительском домене (зоне DNS) может быть использована для проверки записи DNSKEY в поддомене, которая, в свою очередь, может содержать другие записи DS для проверки дальнейших поддоменов. Предположим, рекурсивный решатель, такой как сервер имен интернет-провайдера, хочет получить IP-адреса (записи A и/или AAAA) домена "www.example.com". Процесс начинается, когда решатель, поддерживающий безопасность, устанавливает флаг "DO" ("DNSSEC OK") в DNS-запросе. Поскольку флаг DO находится в расширенных битах флага, определенных механизмами расширения DNS (EDNS), все транзакции DNSSEC должны поддерживать EDNS. Поддержка EDNS также необходима для обеспечения больших размеров пакетов, требуемых для транзакций DNSSEC. Когда решатель получает ответ через обычный процесс поиска DNS, он проверяет корректность ответа. В идеале, защищенный решатель должен начать с проверки записей DS и DNSKEY в корне DNS. Затем он использует записи DS для домена верхнего уровня "com", найденные в корне, для проверки записей DNSKEY в зоне "com". Далее он проверяет наличие записи DS для поддомена "example.com" в зоне "com", и, если она есть, использует эту запись DS для проверки записи DNSKEY, найденной в зоне "example.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" или корневая зона не реализуют его, создавая "остров безопасности", который необходимо проверять другим способом. По состоянию на 2010 год развертывание DNSSEC в корневой зоне было завершено. Домен com был подписан действительными ключами безопасности, а безопасная делегация была добавлена в корневую зону 1 апреля 2011 года.

Using the chain of trust model, a Delegation Signer (DS) record in a parent domain (DNS zone) can be used to verify a DNSKEY record in a subdomain, which can then contain other DS records to verify further subdomains. Say that a recursive resolver such as an ISP name server wants to get the IP addresses (A record and/or AAAA records) of the domain "www. example. com". The process starts when a security aware resolver sets the "DO" ("DNSSEC OK") flag bit in a DNS query. Since the DO bit is in the extended flag bits defined by Extension Mechanisms for DNS (EDNS), , all DNSSEC transactions must support EDNS. EDNS support is also needed to allow for the much larger packet sizes that DNSSEC transactions require. When the resolver receives an answer via the normal DNS lookup process, it then checks to make sure that the answer is correct. Ideally, the security aware resolver would start with verifying the DS and DNSKEY records at the DNS root. Then it would use the DS records for the "com" top level domain found at the root to verify the DNSKEY records in the "com" zone. From there, it would see if there is a DS record for the "example. com" subdomain in the "com" zone, and if there were, it would then use the DS record to verify a DNSKEY record found in the "example. com" zone. Finally, it would verify the RRSIG record found in the answer for the A records for "www. example. com". There are several exceptions to the above example. First, if "example. com" does not support DNSSEC, there will be no RRSIG record in the answer and there will not be a DS record for "example. com" in the "com" zone. If there is a DS record for "example. com", but no RRSIG record in the reply, something is wrong and maybe a man in the middle attack is going on, stripping the DNSSEC information and modifying the A records. Or, it could be a broken security oblivious name server along the way that stripped the DO flag bit from the query or the RRSIG record from the answer. Or, it could be a configuration error. Next, it may be that there is not a domain name named "www. example. com", in which case instead of returning a RRSIG record in the answer, there will be either an NSEC record or an NSEC3 record. These are "next secure" records that allow the resolver to prove that a domain name does not exist. The NSEC/NSEC3 records have RRSIG records, which can be verified as above. Finally, it may be that the "example. com" zone implements DNSSEC, but either the "com" zone or the root zone do not, creating an "island of security" which needs to be validated in some other way. as of 2010, deployment of DNSSEC to root is completed. The com domain was signed with valid security keys and the secure delegation was added to the root zone on 1 April 2011.

Резолюторы нагрузок

Резольверы Stub – это "минимальные DNS-резольверы, использующие рекурсивный режим запроса для передачи большей части работы по разрешению DNS рекурсивному серверу имен". Резольвер Stub просто пересылает запрос рекурсивному серверу имен и использует бит аутентифицированных данных (AD) в ответе как "указание на то, смог ли рекурсивный сервер имен проверить подписи для всех данных в секциях Ответ и Авторитет ответа".

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

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

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

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

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

DNSSEC включает в себя множество различных ключей, хранящихся как в записях DNSKEY, так и в других источниках для формирования доверительных якорей. Для обеспечения возможности замены ключей требуется схема смены ключей. Обычно это включает в себя первоначальное развертывание новых ключей в новых записях DNSKEY в дополнение к существующим старым ключам. Затем, когда можно с уверенностью предположить, что время жизни (TTL) записей привело к истечению кэша старых ключей, эти новые ключи могут быть использованы. Наконец, когда можно с уверенностью предположить, что кэш записей, подписанных старыми ключами, истек, старые записи 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 и ph. Verisign перевела com, net и edu на алгоритм 13 в конце 2023 года. В настоящее время планируется миграция корневой зоны с алгоритма 8 на алгоритм 13 в начале 2024 года.

DNSSEC involves many different keys, stored both in DNSKEY records, and from other sources to form trust anchors. In order to allow for replacement keys, a key rollover scheme is required. Typically, this involves first rolling out new keys in new DNSKEY records, in addition to the existing old keys. Then, when it is safe to assume that the time to live values have caused the caching of old keys to have passed, these new keys can be used. Finally, when it is safe to assume that the caching of records using the old keys have expired, the old DNSKEY records can be deleted. This process is more complicated for things such as the keys to trust anchors, such as at the root, which may require an update of the operating system. Keys in DNSKEY records can be used for two different things and typically different DNSKEY records are used for each. First, there are key signing keys (KSK) which are used to sign other DNSKEY records containing zone signing keys (ZSK), which are used to sign other records. Since the ZSKs are under complete control and use by one particular DNS zone, they can be switched more easily and more often. As a result, ZSKs can be much shorter than KSKs and still offer the same level of protection while reducing the size of the RRSIG/DNSKEY records. When a new KSK is created, the DS record must be transferred to the parent zone and published there. The DS records use a message digest of the KSK instead of the complete key in order to keep the size of the records small. This is helpful for zones such as the com domain, which are very large. The procedure to update DS keys in the parent zone is also simpler than earlier DNSSEC versions that required DNSKEY records to be in the parent zone. A closely related principle is that of Algorithm rollover, this involves migrating a zone from one signing Algorithm to another. A good example of this would be migrating from Algorithm 8 (RSA/SHA 256) to Algorithm 13 (ECDSA/SHA 256). Several ccTLD's have already migrated including at, br, cz, ch, fr, ie, nl and ph. Verisign migrated com, net and edu to Algorithm 13 in late 2023. The migration of the root domain from Algorithm 8 to Algorithm 13 is currently in planning as of early 2024.

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

DNS-based Authentication of Named Entities (DANE) — это рабочая группа IETF, целью которой является разработка протоколов и методов, позволяющих интернет-приложениям устанавливать криптографически защищенные соединения с использованием TLS, DTLS, SMTP и S/MIME на основе DNSSEC. Новые протоколы обеспечат дополнительные гарантии и ограничения по сравнению с традиционной моделью, основанной на инфраструктуре открытых ключей. Они также позволят владельцам доменов самостоятельно подтверждать свои сертификаты, без обращения к сторонним удостоверяющим центрам. Поддержка сертификатов, прикрепленных DNSSEC, была реализована в Google Chrome 14, но впоследствии удалена. В Mozilla Firefox поддержка обеспечивалась через дополнение, а разработка встроенной поддержки в настоящее время ожидает исполнителя.

История

DNS — это важный и основополагающий интернет-сервис, но в 1990 году Стив Белловин обнаружил в нем серьезные недостатки безопасности. Исследования по его обеспечению начались и значительно продвинулись, когда его статья была опубликована в 1995 году. Первоначальный RFC 2065 был опубликован IETF в 1997 году, и первоначальные попытки внедрить эту спецификацию привели к пересмотренной (и считавшейся полностью работоспособной) спецификации в 1999 году как IETF RFC 2535. Были разработаны планы по развертыванию DNSSEC на основе RFC 2535. К сожалению, спецификация IETF RFC 2535 имела очень серьезные проблемы с масштабированием до полного Интернета; к 2001 году стало ясно, что эта спецификация непригодна для больших сетей. В обычной работе DNS-серверы часто не синхронизируются со своими родителями. Это обычно не проблема, но когда DNSSEC включен, эти не синхронизированные данные могут привести к серьезному самопроизвольному отказу в обслуживании. Первоначальный DNSSEC требовал сложного протокола с шестью сообщениями и множества передач данных для выполнения изменений ключей для дочерней зоны (дочерние зоны DNS должны были отправить все свои данные родителю, чтобы родитель подписал каждую запись, а затем отправить эти подписи обратно дочерней зоне для хранения в записи SIG). Кроме того, изменения открытого ключа могли иметь абсурдные последствия; например, если зона ".com" изменила свой открытый ключ, ей пришлось бы отправить 22 миллиона записей (потому что ей нужно было бы обновить все подписи всех своих дочерних зон). Таким образом, DNSSEC, как определено в RFC 2535, не мог масштабироваться до масштабов Интернета. IETF фундаментально изменил DNSSEC, который при необходимости называется DNSSEC bis, чтобы отличить его от оригинального подхода DNSSEC в RFC 2535. Эта новая версия использует "записи ресурсов подписанта делегирования (DS)", чтобы обеспечить дополнительный уровень косвенности в точках делегирования между родительской и дочерней зонами. В новом подходе, когда главный открытый ключ дочерней зоны меняется, вместо шести сообщений для каждой записи в дочерней зоне, отправляется одно простое сообщение: дочерняя зона отправляет новый открытый ключ своему родителю (подписанный, конечно). Родители просто хранят один главный открытый ключ для каждой дочерней зоны; это намного практичнее. Это означает, что небольшое количество данных передается родителю, вместо обмена огромным количеством данных между родителем и дочерними зонами. Это означает, что клиентам придется выполнять немного больше работы при проверке ключей. В частности, проверка KEY RRset DNS-зоны требует двух операций проверки подписи вместо одной, необходимой по RFC 2535 (на количество проверяемых подписей для других типов RRset это не влияет). Большинство считают это небольшой ценой, поскольку это делает развертывание DNSSEC более практичным. Новая версия опубликована в RFC 4033 и RFC 4035. В январе 2024 года была объявлена атака типа "отказ в обслуживании" (DoS) под названием "KeyTrap" для всех DNSSEC-резолверов, соответствующих спецификации. Спецификация DNSSEC (RFC 4033 и RFC 4035) определяет, что резолвер, получая подписанный пакет от вышестоящего сервера, должен перебрать все ключи с правильным "тегом" для всех подписей, пока одна из комбинаций не будет успешно проверена. Поместив в пакет множество ключей с одним и тем же "тегом" и множество подписей, соответствующих этому "тегу", исследователи могут замедлить работу резолвера в 2 миллиона раз. В ответ на это резолверы начали устанавливать ограничения на количество ошибок проверки, коллизий ключевых тегов и вычислений хеша.

DNS is a critical and fundamental Internet service, yet in 1990 Steve Bellovin discovered serious security flaws in it. Research into securing it began, and progressed dramatically when his paper was made public in 1995. The initial RFC 2065 was published by the IETF in 1997, and initial attempts to implement that specification led to a revised (and believed fully workable) specification in 1999 as IETF RFC 2535. Plans were made to deploy DNSSEC based on RFC 2535. Unfortunately, the IETF RFC 2535 specification had very significant problems scaling up to the full Internet; by 2001 it became clear that this specification was unusable for large networks. In normal operation DNS servers often get out of sync with their parents. This isn't usually a problem, but when DNSSEC is enabled, this out of sync data could have the effect of a serious self created denial of service. The original DNSSEC required a complex six message protocol and a lot of data transfers to perform key changes for a child (DNS child zones had to send all of their data up to the parent, have the parent sign each record, and then send those signatures back to the child for the child to store in a SIG record). Also, public key changes could have absurd effects; for example, if the ". com" zone changed its public key, it would have to send 22 million records (because it would need to update all of the signatures in all of its children). Thus, DNSSEC as defined in RFC 2535 could not scale up to the Internet. The IETF fundamentally modified DNSSEC, which is called DNSSEC bis when necessary to distinguish it from the original DNSSEC approach of RFC 2535. This new version uses "delegation signer (DS) resource records" to provide an additional level of indirection at delegation points between a parent and child zone. In the new approach, when a child's master public key changes, instead of having six messages for every record in the child, there is one simple message: the child sends the new public key to its parent (signed, of course). Parents simply store one master public key for each child; this is much more practical. This means that a little data is pushed to the parent, instead of massive amounts of data being exchanged between the parent and children. This does mean that clients have to do a little more work when verifying keys. More specifically, verifying a DNS zone's KEY RRset requires two signature verification operations instead of the one required by RFC 2535 (there is no impact on the number of signatures verified for other types of RRsets). Most view this as a small price to pay, since it makes DNSSEC deployment more practical. The new version is published in RFC4033 4035. In January 2024, a "KeyTrap" denial of service attack was announced for all specification respecting DNSSEC resolvers. The DNSSEC specification (RFC4033 4035) specifies that a resolver, when receiving a signed packet from the upstream, should try all keys with the correct "tag" on all signatures until one of the combinations successfully verifies. By putting many keys with the same "tag" and many signatures corresponding to that "tag" in a packet, the researchers can slow down a resolver by a factor of 2 million. In response, resolvers began to place limits on the amount of verification errors, key tag collisions, and hash calculations.

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

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

Предотвращение ходьбы по домене

Записи NSEC3 (RFC 5155) были созданы как альтернатива, которая хеширует имя вместо прямого перечисления. Со временем, прогресс в области хеширования с использованием графических процессоров и специализированного оборудования привел к тому, что ответы NSEC3 можно было относительно дешево взламывать методом грубой силы, используя автономные атаки по словарю. NSEC5 было предложено для того, чтобы авторитетные серверы могли подписывать ответы NSEC, не храня при этом закрытый ключ, который можно использовать для изменения зоны. Таким образом, кража NSEC5KEY приведет лишь к возможности более легкого перечисления зоны. Из-за сложной эволюции протокола и желания сохранить обратную совместимость, онлайн-серверы DNSSEC-подписи возвращают "белую ложь" вместо прямой аутентификации отрицания существования. Метод, описанный в RFC 4470, возвращает запись NSEC, в которой пары доменов лексически окружают запрошенный домен. Например, запрос для k.example.com приведет к записи NSEC, доказывающей отсутствие чего-либо между (фиктивными) доменами j.example.com и l.example.com. Это также возможно с записями NSEC3. CloudFlare стала пионером в разработке двух альтернативных подходов, позволяющих достичь того же результата при уменьшении размера ответа в три раза. Первый – это вариация подхода "белой лжи", называемая "черной ложью", которая использует распространенное поведение DNS-клиентов для более компактного указания на несуществование. Второй подход вместо этого выбирает доказательство того, что "запись существует, но запрошенный тип записи отсутствует", что они называют "DNS-дробовик". Широкомасштабное внедрение DNSSEC может решить множество других проблем безопасности, таких как безопасное распространение ключей для адресов электронной почты. Внедрение DNSSEC в крупных сетях также является сложной задачей. Ozment и Schechter отмечают, что DNSSEC (и другие технологии) имеет "проблему запуска": пользователи обычно внедряют технологию только в том случае, если получают немедленную выгоду, но если для получения выгоды, превышающей затраты (как это происходит с DNSSEC), требуется минимальный уровень внедрения, то внедрение затруднено. DNSSEC может быть развернут на любом уровне иерархии DNS, но он должен быть широко доступен в зоне, прежде чем другие захотят его принять. DNS-серверы должны быть обновлены программным обеспечением, поддерживающим DNSSEC, а данные DNSSEC должны быть созданы и добавлены к данным DNS-зоны. TCP/IP-клиент, использующий DNS-резольвер (клиент), должен быть обновлен, прежде чем он сможет использовать возможности DNSSEC. Более того, любой резольвер должен иметь, или иметь возможность получить, хотя бы один открытый ключ, которому он может доверять, прежде чем начать использовать DNSSEC. Реализация DNSSEC может значительно увеличить нагрузку на некоторые DNS-серверы. Типичные ответы с DNSSEC-подписью намного больше, чем размер UDP по умолчанию – 512 байт. Теоретически, это можно обработать с помощью нескольких IP-фрагментов, но многие "промежуточные устройства" не обрабатывают их корректно. Это приводит к использованию TCP. Однако многие современные реализации TCP хранят большой объем данных для каждого TCP-соединения; сильно загруженные серверы могут исчерпать ресурсы, просто пытаясь ответить на большое количество (возможно, ложных) DNSSEC-запросов. Некоторые расширения протокола, такие как TCP Cookie Transactions, были разработаны для снижения этой нагрузки. Для решения этих проблем прилагаются значительные усилия по внедрению DNSSEC, поскольку Интернет имеет жизненно важное значение для многих организаций.

The NSEC3 records (RFC 5155) were created as an alternative which hashes the name instead of listing them directly. Over time, advancements in hashing using GPUs and dedicated hardware meant that NSEC3 responses could be cheaply brute forced using offline dictionary attacks. NSEC5 has been proposed to allow authoritative servers to sign NSEC responses without having to keep a private key that can be used to modify the zone. Thus stealing an NSEC5KEY would only result in the ability to more easily enumerate a zone. Due to the messy evolution of the protocol and a desire to preserve backwards compatibility, online DNSSEC signing servers return a "white lie" instead of authenticating a denial of existence directly. The technique outlined in RFC 4470 returns a NSEC record in which the pairs of domains lexically surrounding the requested domain. For example, request for k. example. com would thus result in an NSEC record proving that nothing exists between the (fictitious) domains j. example. com and l. example. com. This is also possible with NSEC3 records. CloudFlare pioneered a pair of alternative approaches, which manage to achieve the same result in one third of the response size. The first is a variation on the "white lies" approach, called "black lies", which exploits common DNS client behavior to state the nonexistence more compactly. The second approach instead chooses to prove that "the record exists but the requested record type does not", which they call "DNS shotgun". Wide scale deployment of DNSSEC could resolve many other security problems as well, such as secure key distribution for e mail addresses. DNSSEC deployment in large scale networks is also challenging. Ozment and Schechter observe that DNSSEC (and other technologies) has a "bootstrap problem": users typically only deploy a technology if they receive an immediate benefit, but if a minimal level of deployment is required before any users receive a benefit greater than their costs (as is true for DNSSEC), it is difficult to deploy. DNSSEC can be deployed at any level of a DNS hierarchy, but it must be widely available in a zone before many others will want to adopt it. DNS servers must be updated with software that supports DNSSEC, and DNSSEC data must be created and added to the DNS zone data. A TCP/IP using client must have their DNS resolver (client) updated before it can use DNSSEC's capabilities. What is more, any resolver must have, or have a way to acquire, at least one public key that it can trust before it can start using DNSSEC. DNSSEC implementation can add significant load to some DNS servers. Common DNSSEC signed responses are far larger than the default UDP size of 512 bytes. In theory, this can be handled through multiple IP fragments, but many "middleboxes" in the field do not handle these correctly. This leads to the use of TCP instead. Yet many current TCP implementations store a great deal of data for each TCP connection; heavily loaded servers can run out of resources simply trying to respond to a larger number of (possibly bogus) DNSSEC requests. Some protocol extensions, such as TCP Cookie Transactions, have been developed to reduce this loading. To address these challenges, significant effort is ongoing to deploy DNSSEC, because the Internet is so vital to so many organizations.

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

Среди первых пользователей технологии стали Бразилия (.br), Болгария (.bg), Чешская Республика (.cz), Намибия (.na), Пуэрто-Рико (.pr) и Швеция (.se), использующие DNSSEC для своих доменов верхнего уровня, соответствующих кодам стран; RIPE NCC, подписавший все записи обратного просмотра (в addr.arpa), делегированные ему Internet Assigned Numbers Authority (IANA). ARIN также подписывает свои обратные зоны. В феврале 2007 года TDC стал первым шведским интернет-провайдером, предложившим эту функцию своим клиентам. IANA публично тестировала пример подписанного корневого сервера с июня 2007 года. В этот период, предшествовавший производственному подписанию корневого сервера, существовало несколько альтернативных доверенных якорей. IKS Jena представил один 19 января 2006 года, Internet Systems Consortium – другой 27 марта того же года, а ICANN объявила о третьем 17 февраля 2009 года. 2 июня 2009 года Afilias, поставщик услуг реестра для зоны org Public Interest Registry, подписал TLD org. Afilias и PIR также сообщили 26 сентября 2008 года, что первый этап, включающий крупных регистраторов, с которыми у них налажены тесные рабочие отношения ("друзья и партнеры"), первыми смогут подписывать свои домены, начиная с "начала 2009 года". 23 июня 2010 года 13 регистраторов были указаны как предлагающие записи DNSSEC для доменов ORG. VeriSign провел пилотный проект, позволяющий доменам .com и .net регистрироваться для экспериментов с NSEC3. 24 февраля 2009 года они объявили о развертывании DNSSEC во всех своих доменах верхнего уровня (.com, .net и т.д.) в течение 24 месяцев, а 16 ноября того же года заявили, что домены .com и .net будут подписаны к первому кварталу 2011 года после задержек, вызванных техническими аспектами реализации. Эта цель была достигнута в срок, и вице-президент Verisign по DNSSEC Мэтт Ларсон получил награду InfoWorld Technology Leadership Award за 2011 год за вклад в развитие DNSSEC.

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

В сентябре 2008 года ICANN и VeriSign опубликовали предложения по реализации, а в октябре Национальное управление связи и информации (NTIA) запросило общественные отзывы. Неясно, повлияли ли полученные отзывы на разработку окончательного плана развертывания. 3 июня 2009 года Национальный институт стандартов и технологий (NIST) объявил о планах подписать корневую зону к концу 2009 года совместно с ICANN, VeriSign и NTIA. 6 октября 2009 года на 59-й конференции RIPE ICANN и VeriSign объявили о запланированном графике развертывания DNSSEC в корневой зоне. На встрече было объявлено о поэтапном развертывании на одном корневом сервере имен в месяц, начиная с 1 декабря 2009 года, с тем чтобы последний корневой сервер имен обслуживал зону, подписанную DNSSEC, к 1 июля 2010 года. Корневая зона будет подписана с использованием RSA/SHA256 DNSKEY. Это означает, что ключи, использованные для подписи зоны, намеренно не поддаются проверке; это развертывание было проведено для мониторинга изменений в структуре трафика, вызванных увеличенными ответами на запросы DNSSEC-ресурсов. Домен верхнего уровня .org был подписан с помощью DNSSEC в июне 2010 года, за ним последовали .com, .net и .edu позднее в 2010 и 2011 годах. Домены верхнего уровня с кодами стран могли депонировать ключи, начиная с мая 2010 года. По состоянию на 2011 год более 25% доменов верхнего уровня были подписаны с помощью DNSSEC.

Реализация

25 января 2010 года корневой сервер L (ell) начал обслуживать зону корня с преднамеренной невозможностью проверки (Deliberately Unvalidatable Root Zone, DURZ). В зоне используются подписи хеша SHA 2 (SHA 256), созданного с использованием алгоритма RSA, как определено в RFC 4432. По состоянию на май 2010 года все тринадцать корневых серверов начали обслуживать DURZ. DLV (Delegation Validator) был разработан для упрощения развертывания DNSSEC в отсутствие корневого якоря доверия. В то время предполагалось, что валидатору может потребоваться поддерживать большое количество доверенных якорей, соответствующих подписанным поддеревьям DNS. Целью DLV было позволить валидаторам переложить задачу управления репозиторием доверенных якорей на доверенную третью сторону. Регистр DLV поддерживал централизованный список доверенных якорей, вместо того чтобы каждый валидатор самостоятельно вел свой список. Для использования DLV требовался валидатор, поддерживающий эту функцию, например BIND или Unbound, сконфигурированный с доверенным якорем для зоны DLV. Эта зона содержала записи DLV, имевшие точно такой же формат, как и записи DS, но вместо ссылки на делегированную подзону они указывали на зону в другом месте дерева DNS. Если валидатор не мог найти цепочку доверия от корня до проверяемого набора записей (RRset), он искал запись DLV, которая могла бы предоставить альтернативную цепочку доверия. Пробелы в цепочке доверия, такие как неподписанные домены верхнего уровня или регистраторы, не поддерживающие делегирование DNSSEC, позволяли администраторам доменов нижнего уровня использовать DLV для проверки их DNS-данных резольверами, настроенными на использование DLV. Это могло замедлить развертывание DNSSEC, снижая требования к регистраторам и реестрам TLD по обеспечению надлежащей поддержки DNSSEC. DLV также усложнял процесс валидации DNSSEC, добавляя больше участников и путей кода. ISC прекратил работу своего регистра DLV в 2017 году. Поддержка DLV была объявлена устаревшей в BIND 9.12 и полностью удалена из BIND 9.16. В Unbound версии 1.5.4 (июль 2015 года) DLV был помечен как устаревший в примере конфигурации и справочной странице. Knot Resolver и PowerDNS Recursor никогда не реализовывали поддержку DLV. В марте 2020 года IETF опубликовала документ, отменяющий DLV как стандарт и переведя RFC 4432 и RFC 5074 в статус "Исторический".

On January 25, 2010, the L (ell) root server began serving a Deliberately Unvalidatable Root Zone (DURZ). The zone uses signatures of a SHA 2 (SHA 256) hash created using the RSA algorithm, as defined in As of May 2010, all thirteen root servers began serving the DURZ. DLV was intended to make DNSSEC easier to deploy in the absence of a root trust anchor. At the time it was imagined that a validator might have to maintain large numbers of trust anchors corresponding to signed subtrees of the DNS. The purpose of DLV was to allow validators to offload the effort of managing a trust anchor repository to a trusted third party. The DLV registry maintained a central list of trust anchors, instead of each validator repeating the work of maintaining its own list. To use DLV, a validator that supports it was needed, such as BIND or Unbound, configured with a trust anchor for a DLV zone. This zone contained DLV records; these had exactly the same format as DS records, but instead of referring to a delegated sub zone, they referred to a zone elsewhere in the DNS tree. When the validator could not find a chain of trust from the root to the RRset it is trying to check, it searched for a DLV record that could provide an alternative chain of trust. Gaps in the chain of trust, such as unsigned top level domains or registrars that did not support DNSSEC delegations, meant administrators of lower level domains could use DLV to allow their DNS data to be validated by resolvers which had been configured to use DLV. This may have hindered DNSSEC deployment by taking pressure off registrars and TLD registries to properly support DNSSEC. DLV also added complexity by adding more actors and code paths for DNSSEC validation. ISC decommissioned its DLV registry in 2017. DLV support was deprecated in BIND 9.12 and completely removed from BIND 9.16. Unbound version 1.5.4 (July 2015) marked DLV as decommissioned in the example configuration and manual page. Knot Resolver and PowerDNS Recursor never implemented DLV. In March 2020, the IETF published , retiring DLV as a standard and moving RFC 4432 and RFC 5074 to "Historic" status.

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

Директорат по науке и технологиям Министерства внутренней безопасности США (DHS) спонсирует "Инициативу по внедрению DNSSEC". Эта инициатива призывает "все сектора добровольно принять меры безопасности, которые повысят безопасность инфраструктуры доменных имен в интернете, в рамках глобальных, совместных усилий с участием многих стран и организаций государственного и частного секторов". DHS также финансирует работы по развитию и внедрению DNSSEC внутри федерального правительства США. Сообщалось, что 30 марта 2007 года Министерство внутренней безопасности США предложило "обеспечить надежное нахождение ключа для подписи корневой зоны DNS под контролем правительства США". Однако в зале заседаний не присутствовали представители правительства США, и комментарий, послуживший причиной публикации статьи, был сделан другим участником. Позже DHS прокомментировал, почему, по их мнению, другие пришли к ошибочному выводу о том, что правительство США сделало подобное предложение: "Министерство внутренней безопасности США финансирует разработку технического плана по внедрению DNSSEC и в октябре прошлого года распространило его предварительный проект среди широкого круга международных экспертов для получения отзывов. В проекте представлены различные варианты того, кто может быть владельцем или "оператором" ключа корневой зоны, по сути сводящиеся к государственному учреждению или подрядчику. "Ни в одном месте документа мы не делаем никаких предложений относительно того, кто будет оператором ключа корневой зоны", – заявил Моуган, менеджер по исследованиям и разработкам в области кибербезопасности в Министерстве внутренней безопасности.

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

Национальный институт стандартов и технологий (NIST) опубликовал специальную публикацию NIST 800-81 «Руководство по развертыванию защищенной системы доменных имен (DNS)» 16 мая 2006 года, содержащую рекомендации по развертыванию DNSSEC. NIST планировал включить новые требования Федерального закона об управлении информационной безопасностью (FISMA) в NIST SP800-53 R1, ссылаясь на данное руководство по развертыванию. В этом случае у государственных учреждений США был бы год после окончательной публикации NIST SP800-53 R1 для соответствия этим новым требованиям FISMA. Однако на тот момент NSEC3 еще не был завершен. NIST предлагал использовать разделенные домены – метод, который, хотя и возможен, сложен в правильной реализации и имеет вышеупомянутые уязвимости в безопасности. 22 августа 2008 года Управление по бюджету и управлению (OMB) выпустило меморандум, предписывающий федеральным агентствам США развернуть DNSSEC на всех ресурсах домена .gov; корневая зона .gov должна быть подписана к январю 2009 года, а все поддомены .gov – к декабрю 2009 года. Хотя меморандум фокусируется на ресурсах .gov, Агентство информационных систем Министерства обороны США заявило о намерении выполнить требования OMB по DNSSEC и в домене .mil (Вооруженные силы США). Кэролин Даффи Марсан из NetworkWorld отметила, что DNSSEC «не получил широкого распространения из-за классической проблемы «что было раньше – курица или яйцо», но с появлением предписания OMB, похоже, яйцо начинает трескаться».

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

Несколько интернет-провайдеров начали развертывание рекурсивных DNS-резольверов с поддержкой валидации DNSSEC. Comcast стал первым крупным провайдером, сделавшим это в Соединенных Штатах, объявив о своих намерениях 18 октября 2010 года и завершив развертывание 11 января 2012 года. Согласно исследованию APNIC, доля клиентов, использующих исключительно DNS-резольверы, выполняющие валидацию DNSSEC, выросла до 8,3% к маю 2013 года. Примерно половина этих клиентов использовали общедоступный DNS-резольвер Google. В сентябре 2015 года Verisign объявила о своей бесплатной общедоступной службе DNS-резольвинга, которая, хотя и не упоминается в их пресс-релизах, также выполняет валидацию DNSSEC. К началу 2016 года мониторинг APNIC показал, что доля клиентов, использующих исключительно DNS-резольверы, выполняющие валидацию DNSSEC, увеличилась примерно до 15%.

Поддержка DNSSEC

Общедоступный рекурсивный DNS-сервер Google включил проверку DNSSEC 6 мая 2013 года. BIND, самое популярное программное обеспечение для управления DNS, поддерживает DNSSEC по умолчанию, начиная с версии 9.5. Публичный рекурсивный DNS Quad9 выполняет проверку DNSSEC по своему основному адресу 9.9.9.9 с момента запуска 11 мая 2016 года. Quad9 также предоставляет альтернативный сервис, который не выполняет проверку DNSSEC, главным образом для целей отладки.