DNSSEC

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

Обеспечение безопасности DNS критически важно для интернет-безопасности в целом. Распространению DNSSEC в значительной мере препятствовали:

1. Разработка обратно совместимого стандарта, который можно масштабировать до размера интернета
2. Применение реализаций DNSSEC в огромном количестве DNS серверов и клиентов
3. Разногласия между ключевыми игроками по поводу того, кто должен владеть доменами верхнего уровня (.com, .net)
4. Преодоление предполагаемой сложности и применение DNSSEC

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

Описание

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

DNSSEC была разработана для обеспечения безопасности клиентов от фальшивых DNS данных, например, создаваемых DNS cache poisoning. Все ответы от 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.

История

DNS является одним из важнейших и основных интернет-сервисов. Однако в 1990 Стив Белловин (Steve Bellovin) выявил серьёзные недостатки в безопасности. Исследования в этой области начались и проводились полным ходом со времен публикации доклада в 1995.^[1]

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

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

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

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

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

В основе действия протокола DNSSEC лежит метод цифровой подписи ответов на запрос DNS lookup, который обеспечивает неприкосновенность данных в системе DNS. Для этого было создано несколько типов DNS записей, в их числе RRSIG, DNSKEY, DS и NSEC. Вся информация о защищенном домене (COM, NET, RU…) в системе DNSSEC определенным образом зашифрована, поэтому может быть изменена только при помощи закрытого ключа шифрования. В процессе защищенного делегирования домена происходит генерация пары ключей. Информация о ключах хранится на первичном DNS-сервере. Закрытый ключ используется для подписи зоны после каждого изменения. С помощью DS-записи (англ. Designated Signer) цифровая подпись открытого ключа хранится в родительской зоне. Сам же открытый ключ хранится в подписываемой (дочерней) зоне в записи DNSKEY. Таким образом организуется цепочка доверия. Зная открытый ключ администратора родительской зоны, можно проверить валидность открытого ключа любой из дочерних зон.

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

Применение

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

1. DNS серверы должны поддерживать DNSSEC
2. TCP/IP должны использовать обновленный DNS Resolver, умеющий работать с DNSSEC
3. Каждый клиент должен получить хотя бы один доверенный открытый ключ до того момента, как он начнет использовать DNSSEC

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

1. ↑ "Using the Domain Name System for System Break-Ins" by Steve Bellovin, 1995
2. ↑ DNSSEC Root Signing Announcement
3. ↑ Deploying Security Extensions in .com Top Level Domain
4. ↑ Шести программистам раздали "ключи для перезагрузки интернета"
5. ↑ DNSSEC for the Root Zone
6. ↑ DNSSEC в RU-CENTER
7. ↑ DNSSEC in Windows Server

Ссылки

• DNSSEC - DNSSEC информационный сайт: DNSSEC.ru
• 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

Документы 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