DNSSEC — что это такое и почему это важно?
Интересуетесь протоколом DNSSEC (расширениями безопасности системы доменных имен)? Нажмите на изображение ниже, чтобы изучить нашу инфографику с описанием DNSSEC и преимуществ развертывания DNSSEC.
Содержание:
Краткое описание принципов работы DNS
Для понимания расширений безопасности системы доменных имен (DNSSEC) необходимо иметь базовое представление о системе доменных имен (DNS).
Нормальное функционирование интернета в значительной степени зависит от DNS. Каждая посещенная веб-страница, каждое отправленное электронное письмо и каждая фотография, полученная из социальных сетей, зависят от DNS. На самом деле DNS преобразует понятные человеку доменные имена, такие как icann.org, в IP-адреса, например 192.0.43.7 и 2001:500:88:200::7. Эти IP-адреса необходимы серверам, маршрутизаторам и другим сетевым устройствам для маршрутизации трафика через интернет к нужному адресату.
Использование интернета на любом устройстве начинается с DNS. Например, когда пользователь вводит название веб-сайта в браузер на своем телефоне, браузер сначала запускает процесс преобразования доменного имени в IP-адрес. Этот процесс начинается с преобразования доменного имени веб-сайта в IP-адрес с помощью stub-резолвера, входящего в состав операционной системы устройства. Stub-резолвер — это очень простой DNS-клиент, который передает запрос приложения на получение DNS-данных более сложному компоненту под названием рекурсивный резолвер, который представляет собой DNS-сервер. Многие сетевые операторы используют рекурсивные резолверы для обработки DNS-запросов, отправляемых устройствами в их сети. (Небольшие операторы и организации иногда используют рекурсивные резолверы в других сетях, включая рекурсивные резолверы, работающие как бесплатная услуга, такие как Google Public DNS, OpenDNS и Quad9).
Рекурсивный резолвер отслеживает, или разрешает, ответ на DNS-запрос, отправленный stub-резолвером. Этот процесс разрешения требует, чтобы рекурсивный резолвер отправлял свои собственные DNS-запросы, обычно к нескольким различным авторитативным серверам имен.. Данные DNS для каждого доменного имени хранятся на авторитативном сервере имен в интернете. Данные DNS для домена называются зоной. Некоторые организации используют собственные DNS-серверы для публикации своих зон, но обычно они передают эту функцию сторонним организациям. Существуют различные типы организаций, которые размещают DNS-зоны от имени других, включая регистраторов, регистратуры, компании хостинг-провайдеров, провайдеров сетевых серверов и т. д.
DNS сама по себе не является безопасной
DNS была разработана в 1980-х годах, когда интернет был гораздо меньше, и безопасность не была главным фактором при его разработке. В результате, когда рекурсивный резолвер отправляет запрос на авторитативный сервер имен, у него нет возможности проверить подлинность ответа. Резолвер может только проверить, что ответ пришел с того же IP-адреса, на который он отправил исходный запрос. Однако полагаться на IP-адрес источника ответа – это ненадежный механизмом аутентификации, поскольку IP-адрес источника пакета ответа DNS можно легко имитировать или подделать. В том виде, в каком DNS была разработана изначально, резолвер не может уверенно обнаружить поддельный ответ на один из своих запросов. Злоумышленник может легко выдать себя за авторитативный сервер, к которому изначально обращался резолвер, подменив ответ, который выглядит как исходящий от этого авторитативного сервера. Другими словами, злоумышленник может перенаправить пользователя на потенциально вредоносный сайт, и пользователь об этом не узнает.
Рекурсивные резолверы кэшируют данные DNS, которые они получают от авторитативных серверов имен, чтобы ускорить процесс разрешения. Если stub-резолвер запрашивает данные DNS, которые есть в кэше рекурсивного резолвера, последний может ответить немедленно, без задержки, возникающей при первом запросе к одному или нескольким авторитативным серверам. Однако такая зависимость от кэширования имеет и обратную сторону: если злоумышленник отправляет поддельный DNS-ответ, который принимается рекурсивным резолвером, значит, он отравил кэш рекурсивного резолвера. После этого резолвер будет возвращать поддельные данные DNS другим устройствам, запрашивающим их.
В качестве примера угрозы, которую представляет собой атака типа «отравление кэша», рассмотрим, что происходит, когда пользователь заходит на сайт своего банка. Устройство пользователя запрашивает IP-адрес веб-сайта банка у своего настроенного рекурсивного сервера имен. Но злоумышленник мог отравить резолвер IP-адресом, указывающим не на легитимный сайт, а на веб-сайт, созданный злоумышленником. Этот мошеннический сайт выдает себя за сайт банка и выглядит точно так же. Ничего не подозревающий пользователь, как обычно, вводит свое имя и пароль. К сожалению, пользователь по неосторожности предоставил свои банковские данные злоумышленнику, который затем может войти под этим пользователем на сайт легитимного банка, чтобы перевести средства или совершить другие несанкционированные действия.
Расширения безопасности DNS
В 1990-х годах инженеры из Инженерной проектной группы Интернета (IETF), организации, отвечающей за стандарты протокола DNS, осознали, что отсутствие более надежной аутентификации в DNS превратилось в проблему. В результате были разработаны расширения безопасности системы доменных имен (DNSSEC).
DNSSEC усиливает аутентификацию DNS с помощью цифровых подписей, основанных на криптографии открытого ключа. В DNSSEC криптографически подписываются не сами DNS-запросы и ответы, а данные DNS, которые подписываются владельцем этих данных.
Каждая зона DNS имеет пару открытых/закрытых ключей. Владелец зоны использует закрытый ключ зоны для подписи данных DNS в зоне и создания цифровых подписей на этих данных. Как следует из названия «закрытый ключ», этот ключевой материал хранится в секрете владельцем зоны. Однако открытый ключ зоны публикуется в самой зоне, и любой желающий может его получить. Любой рекурсивный резолвер, который ищет данные в зоне, также получает открытый ключ зоны, который он использует для проверки подлинности данных DNS. Резолвер подтверждает, что цифровая подпись на полученных им данных DNS действительна. Если это так, то данные DNS являются легитимными и возвращаются пользователю. Если подпись не подтверждается, резолвер предполагает наличие атаки, отбрасывает данные и возвращает пользователю сообщение об ошибке.
DNSSEC добавляет две важные функции в протокол DNS:
- Аутентификация происхождения данных позволяет резолверу криптографически проверить, что полученные им данные действительно поступили из зоны, из которой, по его мнению, они были получены.
- Защита целостности данных позволяет резолверу знать, что данные не были изменены при передаче с момента их первоначальной подписи владельцем зоны с помощью закрытого ключа зоны.
Доверие к ключам DNSSEC
Каждая зона публикует свой открытый ключ, который рекурсивный рекурсивный резолвер получает для проверки данных в зоне. Но как резолвер может убедиться в подлинности открытого ключа зоны? Открытый ключ зоны подписывается, как и другие данные в зоне. Однако открытый ключ подписывается не закрытым ключом зоны, а закрытым ключом родительской зоны. Например, открытый ключ зоны icann.org подписывается зоной org. Подобно тому как родительская зона DNS отвечает за публикацию списка авторитативных серверов имен дочерней зоны, родительская зона также отвечает за проверку подлинности открытого ключа дочерней зоны. Открытый ключ каждой зоны подписывается ее родительской зоной, за исключением корневой зоны: у нее нет родительской зоны, которая бы подписала ее ключ.
Поэтому открытый ключ корневой зоны является важной отправной точкой для проверки данных DNS. Если резолвер доверяет открытому ключу корневой зоны, он может доверять открытым ключам зон верхнего уровня, подписанным закрытым ключом корневой зоны, например открытому ключу зоны org. А поскольку резолвер может доверять открытому ключу для зоны org, он может доверять и открытым ключам, которые были подписаны соответствующим закрытым ключом, например открытому ключу для icann.org. (На практике родительская зона не подписывает ключ дочерней зоны напрямую — реальный механизм сложнее, — но эффект такой же, как если бы родительская зона подписала ключ дочерней зоны).
Последовательность криптографических ключей, подписывающих другие криптографические ключи, называется цепочкой доверия. Открытый ключ в начале цепочки доверия называется якорем доверия. У резолвера есть список якорей доверия, которые представляют собой открытые ключи для различных зон, которым он неявно доверяет. Большинство резолверов настроены только на один якорь доверия: открытый ключ корневой зоны. Доверяя этому ключу на вершине иерархии DNS, преобразователь может построить цепочку доверия к любому месту в пространстве имен DNS, если каждая зона в пути подписана.
Проверка и подписание с помощью DNSSEC
Для обеспечения повсеместной безопасности в интернете необходимо широко внедрить DNSSEC. DNSSEC не работают автоматически: в настоящее время операторы сети должны специально включать на своих рекурсивных резолверах, а владельцы доменных имен — на авторитативных серверах своих зон. У операторов резолверов и авторитативных серверов есть разные стимулы для включения DNSSEC в своих системах, но когда они это делают, больше пользователей гарантированно получают аутентифицированные ответы на свои DNS-запросы. Проще говоря, пользователь может быть уверен, что попадет в нужное ему место в интернете.
Включить проверку DNSSEC в рекурсивных резолверах очень просто. На самом деле, они поддерживаются почти всеми распространенными резолверами на протяжении многих лет. Для их включения нужно изменить всего несколько строк в конфигурационном файле резолвера. С этого момента, когда пользователь запрашивает у резолвера информацию DNS, полученную из подписанных зон, и эти данные были подделаны, пользователь (намеренно) не получит никаких данных. DNSSEC защищает пользователя от получения ложных данных из подписанной зоны, обнаруживая атаку и не позволяя пользователю получить фальсифицированные данные.
Подписание зон с помощью DNSSEC занимает несколько шагов, но миллионы зон подписывают свою DNS-информацию, чтобы пользователи валидирующих резолверов могли быть уверены в получении достоверных данных. Почти все распространенное программное обеспечение авторитарных серверов имен поддерживает подписание зон, а многие сторонние поставщики услуг хостинга DNS также поддерживают DNSSEC. Как правило, включить DNSSEC для зоны у хостинг-провайдера довольно просто; зачастую для этого требуется лишь установить флажок.
Если владелец зоны развертывает DNSSEC, подписывая данные своей зоны, то родительская зона этой зоны и ее родительская зона, вплоть до корневой зоны, также должны быть подписаны, чтобы DNSSEC были максимально эффективными. Непрерывная цепочка подписанных зон, начиная с корневой зоны, позволяет резолверу строить цепочку доверия от корневой зоны для проверки данных. Например, чтобы эффективно развернуть DNSSEC в зоне icann.org, необходимо подписать зону org, а также корневую зону. К счастью, корневая зона DNS подписана с 2010 года, и все домены общего пользования верхнего уровня (gTLD) и многие национальные домены верхнего уровня (ccTLD) также подписаны.
Для завершения развертывания DNSSEC в зоне необходимо выполнить еще один шаг — отправить материал открытого ключа только что подписанной зоны в ее родительскую зону. Как было описано ранее, родительская зона подписывает открытый ключ дочерней зоны, что позволяет выстроить цепочку доверия от родительской зоны к дочерней.
Сегодня владельцу зоны обычно приходится передавать материал открытого ключа зоны в родительскую зону вручную. В большинстве случаев эта связь осуществляется через регистратора владельца зоны. Точно так же, как владелец зоны взаимодействует со своим регистратором для внесения других изменений в зону, например в список авторитативных серверов имен зоны, владелец зоны также взаимодействует с регистратором для обновления материала открытого ключа зоны. В настоящее время этот процесс осуществляется вручную, однако ожидается, что недавно разработанные протоколы позволят автоматизировать этот процесс в будущем.
Следующие шаги в отношении DNSSEC
По мере расширения масштабов развертывании DNSSEC, DNS может стать фундаментом для других протоколов, требующих защищенного хранения данных. Были разработаны новые протоколы, которые опираются на DNSSEC и, таким образом, работают только в подписанных зонах. Например, аутентификация именованных объектов на базе DNS (DANE) позволяет публиковать ключи защиты транспортного уровня (TLS) в зонах для таких задач, как транспортировка почты. DANE предоставляет способ проверки подлинности открытых ключей, который не зависит от центров сертификации. Еще один способ повысить конфиденциальность DNS-запросов — использовать DANE.
В 2018 году ICANN впервые изменила якорь доверия для корня DNS. В ходе этого процесса было извлечено много уроков, касающихся DNSSEC. Кроме того, многие операторы резолверов стали более осведомлены о DNSSEC и включили проверку, что позволило мировому сообществу получить более четкое представление о функционировании всей системы DNSSEC. ICANN также работает с различными заинтересованными сторонами в интернет-сообществе, такими как правительства, операторы TLD, поставщики DNS-хостинга, поставщики интернет-услуг (ISP) и операторы мобильных сетей (MNO), чтобы расширить внедрение DNSSEC как на уровне подписания, так и на уровне проверки.
В 2024 году ICANN создала новый якорь доверия для корневой зоны DNS, который планируется ввести в действие в 2026 году. В ближайшие годы ICANN надеется на более широкое внедрение DNSSEC как операторами резолверов, так и владельцами зон. Это означает, что больше пользователей во всем мире смогут воспользоваться сильной криптографической гарантией DNSSEC того, что они получают подлинные ответы DNS на свои запросы.
Подробнее
Действия ICANN делает в отношении DNSSEC
-
Информация IANA о DNSSEC
Эта страница содержит информацию о роли IANA как оператора ключа для подписания ключей для корневой зоны DNS: якоря доверия и обновление ключей, материалы для церемонии KSK, политика и процедуры управления ключами корневой зоны и т. д. -
Взаимодействие с техническим сообществом
Эта страница содержит информацию о команде ICANN, отвечающей за проведение и администрирование инициатив по наращиванию технического потенциала и информированию различных заинтересованных сторон интернет-сообщества, чтобы помочь поддержать безопасную экосистему DNS.
Соответствующие публикации
- ICANN опубликовала новый якорь доверия DNSSEC в качестве подготовки к 2026 году, август 2024 года
- Два года оказания поддержки в развертывании DNSSEC в Африке и на Ближнем Востоке, Язид Аканхо (Yazid Akanho), октябрь 2022 года
- Сессии ICANN 2021 года в странах Латинской Америки и Карибского бассейна, посвященные взаимодействию, охватили более 3000 заинтересованных сторон, Николас Антониелло (Nicolas Antoniello) и Даниэл Финк (Daniel Fink), декабрь 2021 года
- Недавнее обновление ключа KSK: резюме и дальнейшие действия, октябрь 2018 года
- Пять лет технического обучения в странах азиатско-тихоокеанского региона для обеспечения безопасности, стабильности и отказоустойчивости интернета, Чампика Уайджаятунга (Champika Wijayatunga), сентябрь 2018 года
Чтобы найти другие блоги ICANN о DNSSEC, используйте ключевое слово «DNSSEC» в поле поиска на этой странице.
Документы ICANN
- OCTO-035: Наблюдение за жизненными циклами ключа DNSSEC, июль 2022 года
- OCTO-033: Использование алгоритмов DNSSEC в 2022 году, апрель 2022 года
- OCTO-029: Пособие по развертыванию DNSSEC для ccTLD, ноябрь 2021 года
- OCTO-012: Обзор обновления ключа KSK DNSSEC в 2018 году, июль 2020 года
- OCTO-006: DNSSEC: защита DNS, обновлено в июле 2020 года
- Архив проекта DNSSEC: архивные документы конкретных проектов сообщества, связанных с развитием и эволюцией DNSSEC в корневой зоне. Не следует полагаться на актуальную информацию о деятельности, она предоставляется исключительно в исторических целях.