DNSSEC (DNSSEC)

DNSSEC (англ. Domain Name System Security Extensions) — набор расширений протокола DNS, позволяющих минимизировать атаки, связанные с подменой IP-адреса при разрешении доменных имён. Он направлен на предоставление DNS-клиентам (англ. термин resolver) гарантии достоверности и целостности данных.

Описание

DNSSEC была разработана для обеспечения безопасности клиентов от фальшивых DNS-данных, например, создаваемых DNS cache poisoning.

DNSSEC не шифрует данные и не изменяет управление ими. DNSSEC может подтвердить и такую информацию, как криптографические сертификаты общего назначения, хранящиеся в CERT record DNS. RFC 4398 описывает, как распределить эти сертификаты, в том числе по электронной почте, что позволяет использовать DNSSEC в качестве глобального распределённого хранилища сертификатов ключей подписи.

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

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

История

Изначально система доменных имён не имела механизмов защиты от подмены информации в ответе сервера, так как во времена разработки (в начале 1980-х годов) угрозы безопасности современного Интернета не являлись актуальными. При этом клиенты судили о верности полученной информации исключительно по двухбайтовому идентификатору запроса. Таким образом, злоумышленнику требовалось перебрать 65536 значений, чтобы «отравить кэш». Это означало, что данные в системе DNS повреждены. Сервер кэширует ложные данные в целях оптимизации и начинает предоставлять эти их своим клиентам. Ещё в 1990 году Стив Белловин (англ. Steve Bellovin) выявил серьёзные недостатки в безопасности. Исследования в этой области начались и проводились полным ходом со времён публикации доклада в 1995 году.

Первая редакция DNSSEC RFC 2065 была опубликована IETF в 1997 году. Попытки реализации этой спецификации привели к появлению нового стандарта RFC 2535 в 1999 году. Реализацию DNSSEC планировали, основываясь на IETF RFC 2535.

К сожалению, у IETF RFC 2535 были серьёзные проблемы с масштабированием. К 2001 году стало ясно, что эта спецификация была непригодна для крупных сетей. При нормальной работе DNS серверы часто десинхронизировались со своими родителями. Обычно это не являлось проблемой, но при включенном DNSSEC, десинхронизованные данные могли нести непроизвольный DoS эффект. Защищённый DNS гораздо более ресурсоёмок в вычислительном плане, и с большей, относительно «классического» DNS, лёгкостью может занять все вычислительные ресурсы.

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

Эти сложности, в свою очередь, вызвали появление новых спецификаций: RFC 4033, RFC 4034, RFC 4035 с принципиальными изменениями. Стандарты устранили основную проблему предыдущей реализации и, хотя клиентам пришлось совершать дополнительные действия для проверки ключей, спецификация оказалась вполне пригодной для практического применения.

В 2005 появилась текущая и последняя спецификация DNSSEC. Знаковое событие случилось в 2008 году, когда Дэн Камински показал миру, что отравить кэш можно за 10 секунд. Производители программного обеспечения DNS ответили тем, что кроме идентификатора запроса стали случайно выбирать исходящий порт для запроса. Попутно начались споры по поводу внедрения DNSSEC.

Изменение DNSSEC, которое называется DNSSEC-bis. Название было дано чтобы отличать DNSSEC-bis от первоначального подхода DNSSEC в RFC 2535. DNSSEC-bis использует принцип DS (англ. delegation signer) для обеспечения дополнительного уровня косвенной делегации при передаче зон от родителя к наследнику. В новом подходе при смене открытого ключа администратору вышестоящего домена отсылается только одно-два сообщения вместо шести: наследник посылает дайджест (fingerprint, хеш) нового открытого ключа родителю.

Подпись и проверка данных создают дополнительные оверхеды. К примеру, в среднем совокупность доменных имён определённого уровня входящих в конкретный домен в 7-10 раз превышает по размеру саму DNS. Генерация и проверка подписей отнимает значительное процессорное время. Подписи и ключи занимают на порядок больше места на диске и в оперативной памяти, чем сами данные.

Принцип работы

Проверка подлинности данных в DNSSEC

Принцип работы DNSSEC основан на использовании цифровых подписей. У администратора имеются записи о соответствии имени домена и IP-адреса. DNSSEC ставит каждой из них в строгое соответствие специальную цифровую подпись.

Все ответы от DNSSEC имеют обратную совместимость и подразумевают наличие цифровой подписи.

Допустим, пользователь обращается к сайту wikipedia.org. Происходит следующее:

1. Пользователь запрашивает доменное имя у резолвера;
2. Допустим, в кэше локальных серверов информации о домене не нашлось и запрос дошёл до сервера провайдера. Резолвер запрашивает данные у DNS сервера.
3. При отсутствии информации в кэше серверов провайдера запрос перенаправляется на корневой сервер с битом DO, информирующем о использовании DNSSEC;
4. Корневой сервер сообщает, что за зону org отвечает сервер a.b.c.net. При этом сервер отправляет набор NS-записей для зоны org, дайджесты её KSK (записи DS) и подпись (запись типа RRSIG) записей NS и DS;
5. Резолвер проводит валидацию полученного ZSK путём проверки соответствия подписи, выполненной ключом KSK корневой зоны. Затем резолвер проверяет цифровую подпись записей DS корневой зоны, содержащуюся в записи RRSIG. Если и тут всё верно, то сервер доверяет полученным дайджестам и проверяет с их помощью подпись записи DNSKEY уровня ниже — зоны org;
6. Теперь, после получения адреса сервера, ответственного за зону org (сервера a.b.c.net), резолвер переправляет ему тот же запрос;
7. a.b.c.net сообщает о том, что сервер, ответственный за зону wikipedia.org, имеет адрес d.org. Также он отправляет подписанные с помощью закрытого KSK зоны org набор ключей подписи (ZSK) зоны org и подписанный с помощью ZSK зоны org дайджест KSK зоны wikipedia.org;
8. Резолвер проводит сравнение полученного от корневого сервера хеша с тем, что он посчитал самостоятельно из KSK зоны org, полученного от сервера a.b.c.net, и в случае совпадения начинает доверять этому KSK. После этого резолвер проверяет подписи ключей из зоны org и начинает доверять ZSK зоны org. Затем резолвер проверяет KSK зоны wikipedia.org. После всех этих проверок у резолвера есть дайджест (DS) KSK зоны wikipedia.org и адрес сервера d.org, где хранится информация о зоне wikipedia.org;
9. Наконец резолвер обращается на сервер d.org за сайтом wikipedia.org, и при этом выставляет бит о том, что использует DNSSEC;
10. Сервер d.org понимает, что зона wikipedia.org находится на нём самом, и отправляет резолверу ответ, содержащий подписанный с помощью KSK зоны wikipedia.org набор ключей подписи (ZSK) зоны wikipedia.org и подписанный с помощью ZSK зоны wikipedia.org адрес сайта wikipedia.org;
11. Также, как в пункте 7 резолвер проверяет KSK зоны wikipedia.org, ZSK зоны wikipedia.org и адрес сайта wikipedia.org;
12. При удачной проверке в пункте 10 резолвер возвращает пользователю ответ, содержащий в себе адрес сайта wikipedia.org и подтверждение, что ответ верифицирован (выставленный бит AD).

При невозможности валидации резолвер вернет ошибку servfail.

Таким образом получившаяся цепочка доверия сводится к корневому домену и ключу корневой зоны.

Delegation of Signing (DS) — запись содержит хеш доменного имени наследника и его ключа KSK. Запись DNSKEY содержит публичную часть ключа и его идентификаторы (ID, тип и используемая хеш-функция).

KSK (Key Signing key) — ключ подписи ключа (ключ долговременного пользования), а ZSK (Zone Signing Key) — ключ подписи зоны (ключ кратковременного пользования). С помощью KSK подтверждается ZSK, которым подписывается корневая зона. ZSK корневой зоны создаёт компания PTI (функциональное подразделение IANA корпорации ICANN), которая технически отвечает за распространение корневой зоны DNS. По принятой ICANN процедуре, ZSK корневой зоны обновляется четыре раза в год.

Подпись корневой зоны

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

К июню 2010 года все корневые серверы корректно работали с зоной, подписанной невалидным ключом. В июле ICANN провёл международную конференцию, посвящённую процедуре генерации ключей электронной подписи, которой впоследствии была подписана корневая зона.

15 июля 2010 года состоялось подписание корневой зоны и началось внедрение подписанной зоны на серверы. 28 июля ICANN сообщил о завершении этого процесса. Корневая зона была подписана электронной подписью и распространилась в системе DNS.

31 марта 2011 года была подписана самая большая зона в Интернете (90 млн доменов) — .com.

Инфраструктура ключей

ICANN выбрал такую модель, когда управление подписанием зоны происходит под контролем представителей интернет-сообщества (Trusted community representative, TCR). Представители выбирались из числа людей, не связанных с управлением корневой зоной DNS. Выбранные представители занимали должности крипто-офицеров (Crypto Officer, CO) и держателей частей ключа восстановления (Recovery key shareholder, RKSH). CO были вручены физические ключи, позволяющие активировать генерацию ключа ЭЦП ZSK, а RKSH владеют смарт-картами, содержащими части ключа (KSK), используемого внутри криптографического оборудования. Некоторые СМИ сделали вывод, что процедуры, требующие присутствия CO или RKSH, будут проводиться в случае чрезвычайных ситуаций в сети. Однако в соответствии с процедурами ICANN, CO будут привлекаться каждый раз при генерации ключа подписания зоны (ZSK), до 4 раз в год, а RKSH — вероятно, никогда или в случае утраты ключей CO, либо при компрометации корневой зоны.

Текущее состояние

На октябрь 2013 года в корневой зоне присутствуют 81 национальный домен и 13 общих доменов, подписанных DNSSEC (без IDN-доменов), и обеспечивающих таким образом цепочку доверия доменам второго уровня. В 2011 году при помощи DNSSEC (NSEC3 opt-out) была подписана зона .su, имеющая отношение к России, а в конце октября 2012 года в ней началась публикация DS-записей, созданных пользователями. В конце 2012 года был подписан российский домен .ru, а его DS-записи опубликованы в корневой зоне.

Смена KSK корневой зоны

11 октября 2018 года произошла первая ротация ключей KSK корневой зоны после подписи корневой зоны в 2010. Ротация ключей, первоначально запланированная на октябрь 2017 года, была отложена по решению ICANN, когда выяснилось, что значительное количество (около 2 %) резолверов используют один ключ для подтверждения цепочки подписей DNSSEC. За год были реализованы некоторые технические решения в пакетах DNS-серверов Bind, PowerDNS, Knot и др., проведена масштабная кампания по информированию широкого круга общественности о ротации ключей, и в итоге в сентябре 2018 года совет директоров ICANN принял решение осуществить ротацию. Значительных проблем, связанных с ротацией ключей, не выявили. Следующая ротация KSK корневой зоны планируется на период 2024-2025 годов.

Проблемы внедрения и недостатки

Внедрение DNSSEC сильно задержалось по таким причинам, как:

1. Разработка обратно совместимого стандарта, который можно масштабировать до размера интернета;
2. Разногласия между ключевыми игроками по поводу того, кто должен владеть доменами верхнего уровня (.com, .net);
3. DNS серверы и клиенты должны поддерживать DNSSEC;
4. Обновлённые DNS-резолверы, умеющие работать с DNSSEC, должны использовать TCP;
5. Каждый клиент должен получить хотя бы один доверенный открытый ключ до того момента, как он начнёт использовать DNSSEC;
6. Возрастание нагрузки на сеть из-за серьёзно (в 6-7 раз) возросшего трафика;
7. Возрастание нагрузки на процессор из-за потребности генерации и проверки подписей, что может потребовать замену некоторых DNS-серверов;
8. Увеличение требований для хранилищ информации об адресации, так как подписанные данные занимают гораздо больше места;
9. Нужно создавать, тестировать и дорабатывать программное обеспечение как серверной, так и клиентской части, что требует времени и испытаний в масштабах всего интернета;
10. Stub-резолверы не защищены от отравления кеша — валидация происходит на стороне рекурсивного сервера, клиент получает только ответ с выставленным битом AD;
11. Резко возросла опасность атак вида DNS Amplification.

Большая часть этих проблем разрешена техническим интернет-сообществом.

Программное обеспечение DNSSEC

Серверная часть

Две наиболее распространённые реализации DNS-серверов — BIND и NSD — поддерживают DNSSEC (10 из 13 корневых серверов используют BIND, оставшиеся 3 — NSD). Также есть поддержка у PowerDNS, Unbound и некоторых других DNS-серверов.

Клиентская часть

По причине того, что серверов, на которых было развёрнуто расширение DNSSEC, было крайне мало, то программного обеспечения для конечных пользователей с поддержкой DNSSEC создавалось также совсем немного. Однако в операционных системах от Microsoft DNSSEC уже интегрирован. В Windows Server 2008 — RFC 2535, в Windows 7 и Windows Server 2008 R2 — актуальная версия DNSSEC-bis.

В Windows ХP и Windows Server 2003 поддерживается RFC 2535, но они лишь могут успешно распознавать пакеты от серверов с DNSSEC, на этом их возможности заканчиваются.

Отдельного упоминания стоит проект DNSSEC-Tools, представляющий набор приложений, дополнений и плагинов, который позволяет добавить поддержку DNSSEC в браузер Firefox, почтовый клиент Thunderbird, FTP-серверы proftpd, ncftp и в некоторые другие приложения.

Использование DNSSEC требует программного обеспечения как на серверной, так и на клиентской стороне.

• BIND (англ. Berkeley Internet Name Domain).
• Drill — инструмент с поддержкой DNSSEC, входящий в набор инструментов ldns.
• DNSSEC-Tools проект SourceForge, направленный на обеспечение простого в использовании набора инструментов для работы с DNSSEC.
• Unbound резолвер написанный с нуля, основываясь на принципах работы DNSSEC.
• поддержка DNSSEC была предоставлена в Windows 7 и Windows Server 2008 R2.
• mysqlBind
• OpenDNSSEC
• IPC Подборка инструкций по настройке DNSSEC в BIND-е.
• Открытый резолвер от Google

Ссылки

• Проверка поддержки DNSSEC из браузера
• DNSSEC — DNSSEC information site: DNSSEC.net (недоступная ссылка)
• DNSEXT — DNS Extensions IETF Working Group (неактивная рабочая группа)
• CircleID — News and Opinions on all DNSSEC related issues
• DNSSEC-Tools Project
• DNSSEC Deployment Coordination Initiative
• Nox.su: пример внедрения DNSSEC в домене .su
• Проверка использования DNSSEC
• Защищайте серверы DNS

Документы RFC

• RFC 2535 Domain Name System Security Extensions
• RFC 3225 Indicating Resolver Support of DNSSEC
• RFC 3226 DNSSEC and IPv6 A6 Aware Server/Resolver Message Size Requirements
• RFC 3833 A Threat Analysis of the Domain Name System
• RFC 4033 DNS Security Introduction and Requirements (DNSSEC-bis)
• RFC 4034 Resource Records for the DNS Security Extensions (DNSSEC-bis)
• RFC 4035 Protocol Modifications for the DNS Security Extensions (DNSSEC-bis)
• RFC 4398 Storing Certificates in the Domain Name System (DNS)
• RFC 4431 The DNSSEC Lookaside Validation (DLV) DNS Resource Record
• RFC 4470 Minimally Covering NSEC Records and DNSSEC On-line Signing
• RFC 4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
• RFC 4641 DNSSEC Operational Practices
• RFC 4955 DNS Security (DNSSEC) Experiments
• RFC 5011 Automated Updates of DNS Security (DNSSEC) Trust Anchors
• RFC 5155 DNSSEC Hashed Authenticated Denial of Existence
• RFC 5702 Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
• RFC 6605 Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC
• RFC 6725 DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates
• RFC 6781 DNSSEC Operational Practices, Version 2
• RFC 6840 Clarifications and Implementation Notes for DNS Security (DNSSEC)
• RFC 7344 Automating DNSSEC Delegation Trust Maintenance
• RFC 7583 DNSSEC Key Rollover Timing Considerations
• RFC 8080 Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC
• RFC 8624 Algorithm Implementation Requirements and Usage Guidance for DNSSEC
• RFC 8749 Moving DNSSEC Lookaside Validation (DLV) to Historic Status