DNSSEC или Где ключи от Интернета?

08.03.2018

Протокол DNS используется для преобразования символьных имен сайтов в числовые IP- адреса. Без данного протокола трудно себе представить существование Интернета. Работу протокола DNS обеспечивают dns-сервера, которые отвечают за определенную доменную зону. Данные зоны построены по иерархическому принципу. На вершине иерархии находится корневая зона - зона, которые обслуживают домены уровня (.). Далее идут зоны верхнего уровня “.com .org .ru и тд”. Далее находятся подчиненные зоны. Часть доменных имен зоны, обычно, передается на управление (делегируется) тем или иным организациям. Программы (dns-клиенты), которые обращаются к dns-серверам за тем или иным ip-адрессом называются резолверами.

Удобство и простота использования DNS порождают и проблемы с безопасностью. Изначально, протокол DNS никак не был защищен и данные передаются в открытом виде. Это и стало причиной одной из самой распространенной атаки - фишингу. Злоумышленник подменяет ответ от dns-сервера на свой и клиент в полной уверенности, что находится на сайте банка или почтового сервера выкладывает на подставной сайт, который выглядит как настоящий, все свои пароли. Более того, любая атака типа человек посредине, начинается как раз с подмены одного из абонентов, и самым простым способом этого как раз является подмена dns ответа.

Начиная с 1995 года активно ведутся исследования безопасности протокола DNS. В 1999 году вышла первая редакция протокола DNSSEC ( RFC 2535), который должен был решить проблемы безопасности. Однако данная редакция оказалась неэффективной при масштабирования протокола до глобального уровня Интернет. После чего была предложена новая редакция DNSSEC-bis (См. RFC 4033, RFC 4034 и RFC 4035), которая и используется в настоящее время.

Итак, в чем основные положения протокола DNSSEC. Данный протокол расширяет ответы стандартного DNS-сервера новыми полями:

• RRSIG
• DNSKEY
• DS
• NSEC
• NSEC3
• NSEC3PARAM

Если посмотреть на иерархическую структуру доменных зон, то можно заметить, что такая структура схожа со структурой удостоверяющих центров PKI . Действительно, принцип работы DNSSEC очень схож с PKI. Для защиты ответов dns-сервера используется криптография с открытым ключом и алгоритмы цифровой подписи. Итак, ответ dns-сервера подписывается закрытым ключом сервера и данная подпись передаются клиенту в поле RRSIG. Чтобы проверить данную подпись сервер передает свой открытый ключ в поле DNSKEY. Однако надо убедиться, что данный ключ принадлежит именно данному dns-серверу. Для этого существует запись DS (Delegation Signer), которая является своего рода сертификатом, и содержит подпись родительского сервера под данным открытым ключом. Таким образом выстраивается цепочка доверия, на вершине которой находятся коневые зоны.

Поля NSEC, NSEC3, NCES3PARAM используются для того, чтобы доверенно сообщить клиенту об отсутствии в dns-сервере записи о доменном имени. Действительно, если бы dns-сервер вернул просто ответ, что запрашиваемого имени нет, это могло бы означать, что злоумышленник заблокировал верный ответ и пытается перенаправить запрос на какой-либо резервный сайт. Чтобы доверенно сообщить об отсутствии записи, сервер, используя поля NSEC, сообщает клиенту о существовании записей о доменных именах, ближайших к запрашиваемому. Другими словами, все имеющиеся записи сортируются в определенном порядке. Затем клиенту возвращаются записи о ближайших именах. Таким образом, клиент узнает, что запрашиваемого имени действительно нет среди записей данного сервера, иначе он бы присутствовал среди полей NSEC.

Изначально использовали поле NSEC, содержащее только пары ближайших имен, содержащихся в базе dns-сервера. Однако набор таких полей NSEC давал клиентам возможность получить полный список всех записей сервера, что является лакомым куском для спамеров и конкурентных dns-серверов. Поэтому решили использовать более сложную технику криптографических хэш-функций. Все имена хэшируются с использованием соли и кратного применения хэш-функции. Далее сортируются именно хэш-коды и клиенту возвращается только соответствующие ближайшие хэш-коды (поле NSEC3). Таким образом клиент может понять, что запрашиваемого имени нет, при этом он получает только хэш-коды от реальных имен, содержащихся в базе dns-сервера. Использование соли предотвращает атаки перебора, основанные на предварительных вычислениях (типа радужных таблиц). Параметры хэширования (соль и кратность применения ) передаются клиенту в поле NSEC3PARAM.

Активное внедрение данного протокола началось в 2009 году. Началась подпись корневой зоны. Данный процесс проходил очень медленно и по частям. К июлю 2010 года корневая зона (.) была подписана. После чего приступили к подписи зон следующего уровня. К апрелю 2011 года завершилась подписание самой большой зоны: зоны (.com) - около 100 млн. доменных имен. В 2011 году должна быть подписана и зона (.ru).

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

Несколько лет назад в новостях проходила информация о наличии в мире лиц, в том числе и в России, которые владеют ключами от Интернета. Журналисты как всегда не разобрались, а имелись ввиду как раз ключи подписи корневой зоны. Действительно, среди интернет сообщества выбраны представители, которые владеют своей частью ключа и которые собираются определенное число раз в году и осуществляют манипуляции с корневой зоной.

Внедрение данного протокола, безусловно, существенно повышает безопасность работы в интернете. К сожалению, это внедрение не проходит быстро. Однако рано или поздно все dns-сервера, даже сервера небольших хостингов, должны будут поддерживать данный протокол.