Для понимания протокола DNSSEC (расширения безопасности системы доменных имен) важно иметь общее представление о системе доменных имен (DNS).

Надлежащее функционирование интернета напрямую зависит от DNS. Посещение веб-страниц, отправка сообщений по электронной почте, получение изображений из соцсетей — во всех этих формах взаимодействия для преобразования понятных человеку доменных имен (например, icann.org) в IP-адреса (например, 192.0.43.7 и 2001:500:88:200::7), необходимые серверам, маршрутизаторам и другим сетевым устройствам для придания трафику в интернете нужного направления, используется DNS.

Пользование интернетом на любом устройстве начинается с DNS. Представьте, например, момент ввода пользователем имени сайта в браузер на телефоне. Браузер при помощи stub-резолвера, являющегося частью операционной системы устройства, начинает преобразование доменного имени сайта в адрес интернет-протокола (IP-адрес). Stub-резолвер представляет собой простейший DNS-клиент, передающий запрос данных DNS более сложному DNS-клиенту, называемому рекурсивным резолвером. У многих сетевых операторов есть рекурсивные резолверы для обработки DNS-запросов — или просто запросов — отправляемых устройствами в их сети. (Менее крупные операторы и организации иногда пользуются рекурсивными резолверами других сетей, в том числе предоставляемыми открыто в качестве услуги, такими как Google Public DNS, OpenDNS и Quad9).

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

Сама по себе DNS не имеет системы защиты

DNS разрабатывалась в 1980-х годах, когда интернет был гораздо меньше, и безопасность не являлась основным приоритетом при ее разработке. Как следствие, отправляя запрос авторитативному DNS-серверу, рекурсивный резолвер не имеет возможности проверить подлинность ответа. Резолвер может лишь проверить, поступает ли ответ с того же IP-адреса, по которому был отправлен исходный запрос. Но полагаться на IP-адрес источника ответа — это ненадежный механизм проверки подлинности данных, поскольку IP-адрес источника ответного DNS-пакета легко подделать или подменить. Изначально заложенная структура DNS не позволяет с лёгкостью распознать поддельный ответ на один из своих запросов. Злоумышленник легко принимает вид авторитативного сервера, которому резолвером отправлен исходный запрос, путем подмены ответа, поступающего, как кажется, от этого авторитативного сервера. Иначе говоря, злоумышленник может направить пользователя на потенциально вредоносный сайт, а пользователь этого не заметит.

Для ускорения преобразования рекурсивные резолверы хранят данные DNS, получаемые ими от авторитативных DNS-серверов, в кэше. Если stub-резолвер запрашивает данные DNS, находящихся в кэше рекурсивного резолвера, то последний может ответить немедленно, без задержки, связанной с необходимостью сначала отправить запрос одному или нескольким авторитативным серверам. Однако у использования возможностей кэширования есть и обратная сторона: если злоумышленник отправляет поддельный ответ DNS, который принимается рекурсивным резолвером, то это приводит к отравлению кэша. После этого резолвер начинает возвращать мошеннические данные DNS другим запрашивающим эти данные устройствам.

Рассмотрим пример угрозы, которую представляет собой атака типа «отравление кэша». Представим, что пользователь заходит на сайт своего банка. Устройство пользователя запрашивает у заданного рекурсивного DNS-сервера IP-адрес сайта банка. Но некий злоумышленник мог отравить резолвер IP-адресом, который ведет не к настоящему сайту, а к сайту, созданному этим злоумышленником. Этот мошеннический сайт имеет вид сайта банка и выглядит точно так же. Ничего не подозревающий пользователь, вводит свое имя и пароль, как обычно. К сожалению, таким образом пользователь раскрывает свои учетные данные злоумышленнику, который затем может под видом этого пользователя войти в систему на настоящем сайте банка, чтобы перевести средства или совершить другие несанционированные действия.

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

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

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

У каждой зоны DNS есть пара открытых/закрытых ключей. Владелец зоны использует ее закрытый ключ для подписания данных DNS в этой зоне и генерирования цифровых подписей для этих данных. Как следует из названия «закрытый ключ», сведения о нем держатся владельцем зоны в секрете. А вот открытый ключ зоны публикуется в ней свободно, и получить его может каждый. Любой рекурсивный резолвер, производящий поиск данных в зоне, также получает открытый ключ этой зоны и использует его для проверки подлинности данных DNS. Резолвер проверяет подлинность цифровой подписи полученных им данных DNS. Если подлинность подтверждается, то данные DNS считаются настоящими и возвращаются пользователю. Если подпись не проходит проверку подлинности, то резолвер предполагает, что произошла атака, избавляется от данных и сообщает пользователю об ошибке.

Применение DNSSEC позволяет обеспечить две важные функции в DNS:

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

Доверие к ключам DNSSEC

Каждая зона публикует свой открытый ключ, и рекурсивный резолвер получает его для проверки подлинности данных в этой зоне. Но как резолверу проверить подлинность самого этого ключа? Как и все остальные данные в зоне, открытый ключ зоны тоже подписывается. Однако открытый ключ зоны подписывается не ее же закрытым ключом, а закрытым ключом ее родительской зоны. Например, открытый ключ зоны icann.org подписывается зоной org. Родительская зона DNS отвечает как за публикацию списка авторитативных DNS-серверов своей дочерней зоны, так и за подтверждение подлинности ее открытого ключа. Открытый ключ каждой зоны подписывается ее родительской зоной. Исключение составляет корневая зона — ее ключ подписывать некому.

Таким образом, открытый ключ корневой зоны является важной отправной точкой проверки подлинности данных DNS. Если резолвер доверяет открытому ключу корневой зоны, то он может доверять подписанным ее закрытым ключом открытым ключам зон верхнего уровня, например, открытому ключу зоны org. И поскольку резолвер может доверять открытому ключу зоны org, он может доверять открытым ключам, подписанным ее закрытым ключом, например, открытому ключу зоны icann.org. (На самом деле родительская зона не подписывает ключ дочерней зоны напрямую — реальный механизм более сложен, но конечный результат ничем не отличается от подписания дочернего ключа родительским.)

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

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

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

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

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

Если говорить о внедрении DNSSEC владельцем зоны путем подписания ее данных, то для обеспечения максимальной эффективности DNSSEC требуется, чтобы родительская зона этой зоны тоже была подписана, как и следующая за ней, и так далее вплоть до корневой зоны. Благодаря непрерывной цепи подписанных зон, начинающейся с корневой зоны, резолвер может выстроить цепочку доверия от корневой зоны для проверки подлинности данных. Например, для эффективного внедрения DNSSEC в зоне icann.org необходимо, чтобы была подписана зона org, а также корневая зона. К счастью, корневая зона DNS подписана с 2010 года, и все gTLD и многие ccTLD тоже.

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

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

Дальнейшие действия, связанные с DNSSEC

По мере внедрения DNSSEC DNS может стать основой для других протоколов, предполагающих наличие надежного способа хранения данных. Разработаны новые протоколы, опирающиеся на DNSSEC и работающие только в подписанных зонах. Например, DANE (аутентификация именованных объектов на базе DNS) предусматривает публикацию в зонах ключей защиты транспортного уровня (TLS) для таких приложений как почта. DANE предоставляет возможность проверять подлинность открытых ключей, не зависящую от центров сертификации. Новые способы повышения уровня конфиденциальности DNS-запросов также будут предусматривать возможность использования DANE.

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