DNSSEC

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

Описание

Изначально Domain Name System (DNS) разрабатывался не в целях безопасности, а для создания масштабируемых распределённых систем. Со временем система DNS становится всё более уязвимой. Злоумышленники без труда перенаправляют запросы пользователей по символьному имени на подставные серверы и таким образом получают доступ к паролям, номерам кредитных карт и другой конфиденциальной информации. Сами пользователи ничего не могут с этим поделать, так как в большинстве случаев даже не подозревают о том, что запрос был перенаправлен — запись в строке браузера и сам сайт в точности такие, какими их и ожидает увидеть пользователь. DNSSEC является попыткой обеспечения безопасности при одновременной обратной совместимости.

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

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

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

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

История

Изначально система доменных имён не имела механизмов защиты от подмены информации в ответе сервера, так как во времена разработки (в начале 1980-х годов) угрозы безопасности современного Интернета не являлись актуальными. При этом клиенты судили о верности полученной информации исключительно по двухбайтовому идентификатору запроса. Таким образом, злоумышленнику требовалось перебрать 65536 значений, чтобы «отравить кэш». Это означало, что данные в системе DNS повреждены (преднамеренно или из-за ошибки), а 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 миллиона записей (так как необходимо было обновить все записи во всех наследниках). Таким образом, DNSSEC в виде RFC 2535 не мог быть масштабирован до размера интернета.

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

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

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

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

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

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

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

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

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

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

1. Пользователь запрашивает доменное имя у резолвера;
2. Резолвер запрашивает wikipedia.org у DNS-сервера (допустим, в кэше локальных серверов информации о домене не нашлось и запрос дошёл до сервера провайдера);
3. При отсутствии информации в кэше серверов провайдера запрос перенаправляется на корневой сервер, также выставляется бит DO, информирующий о том, что используется DNSSEC;
4. Корневой сервер сообщает, что за зону org отвечает сервер a.b.c.net. При этом сервер отправляет набор NS-записей для зоны org, дайджесты KSK зоны org (записи 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 принял решение осуществить ротацию. Значительных проблем, связанных с ротацией ключей, не наблюдалось.

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

Внедрение 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 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 4641 DNSSEC Operational Practices
• RFC 5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence