Dnssec unsigned что значит

DNSSEC

DNSSEC не может обеспечить тотальную защиту вашего сайта. Он:

Для каких доменов можно подключить DNSSEC

Как работает DNSSEC

В системе DNS долгое время не было механизмов защиты от подмены информации. Это значит, что операция обмена данными между клиентом (резолвером) и сервером провайдера не была застрахована от вторжения «третьей стороны» (злоумышленника). Он перехватывает запрос резолвера, возвращает ему произвольный IP-адрес вместо запрашиваемого. Также атака переходит и на серверы провайдера: их кеш заполняется ложными данными.

Протокол DNSSEC исключает из цепи возможного злоумышленника. Если ответ на запрос резолвера проходит проверку на авторитетность, то «кража» и «подмена» будут обнаружены и предотвращены сразу.

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

Ключ состоит из 2 частей:

В работе DNSSEC используется 2 типа ключей:

Для безопасности рекомендуется обновлять ключи со следующей периодичностью:

Как подключить услугу DNSSEC

Если ваш домен зарегистрирован в REG.RU и делегирован на DNS-серверы REG.RU ns1.reg.ru и ns2.reg.ru, закажите услугу Премиум DNS. Для этого воспользуйтесь инструкцией: Как заказать Premium DNS. Об управлении услугой читайте ниже.

Если ваш домен зарегистрирован в REG.RU, но делегирован на сторонние DNS, воспользуйтесь информацией ниже.

Важно: DNS-серверы ns1.hosting.reg.ru, ns2.hosting.reg.ru, ns5.hosting.reg.ru и ns6.hosting.reg.ru не поддерживают работу DNSSEC.

Управление услугой DNSSEC

Чтобы изменить настройки DNSSEC:

Выберите домен, на котором установлена услуга DNSSEC, и кликните по нему:

На странице услуги в поле «DNS-серверы и управление зоной» нажмите Изменить:

На вкладке «Управление» в поле DNSSEC отображается тумблер с текущим статусом услуги (в примере ниже — статус услуги Выключено). Здесь вы можете управлять настройками услуги DNSSEC:

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

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

Убедитесь, что услуга включена (переключатель зелёного цвета):

Чтобы обновить ключ, нажмите на три точки и выберите Обновить KSK ключ или Обновить ZSK ключ:

Новый ключ сгенерируется в течение нескольких минут.

Готово! Вы изменили настройки DNSSEC.

Если ваш домен зарегистрирован в REG.RU, но используются DNS стороннего хостинг-провайдера, выполните следующие действия:

Кликните по домену, для которого вы подключили DNSSEC:

На странице услуги в поле «DNS-серверы и управление зоной» нажмите Изменить:

На вкладке «Управление» нажмите Добавить ключи. В открывшейся шторке вставьте полученные от вашего хостинг-провайдера KSK-ключи или DS-записи (не более десяти). Каждая запись добавляется с новой строки. Нажмите Добавить:

Источник

Практическое применение DNSSEC

Чем плох DNS

Система DNS в нынешнем виде была разработана более 20 лет назад, когда о защите информации не особенно задумывались. Она имеет несколько фундаментальных уязвимостей.

Достоверность ответа DNS-сервера никак не проверяется. Это позволяет отправить пользователя, обратившегося к доменному имени, на произвольный IP-адрес, подменив ответ сервера. На практике подобная атака может выглядеть так.

Также уязвимы кеширующие DNS-серверы провайдеров, выступающие как резолверы для клиентов: Атака Каминского.

Сегодня существуют технологии, предусматривающие хранение открытых ключей в DNS-записях, например, DKIM-подписи в электронной почте, SSH-ключей в записях SSHFP и т.д. Все эти технологии требуют защиты от подделки DNS.

Теория DNSSEC

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

Популярно о DNSSEC можно прочитать здесь: dxdt.ru/2009/03/04/2163

Перед продолжением настоятельно рекомендуется внимательно прочитать вышеприведенные ссылки, так как на первый взгляд процедура подписания зоны кажется довольно запутанной.

Максимально упрощенно это выглядит примерно так: есть корневая зона «.», которая содержит в себе информацию о всех доменах первого уровня. Условно говоря, это текстовый файл с некоторым множеством строк, который изменяется не очень часто. Создается пара открытый/закрытый ключ и каждая строка в этом файле подписывается (по типу «clear sign» в PGP/GPG, которая используется в электронной почте для открытого подписания текста и начинается с «BEGIN PGP SIGNATURE»).
Теперь, имея открытый ключ от этой пары, можно удостовериться в подлинности каждой записи в этом списке. Например, проверить, что за зону «ru.» действительно отвечают серверы ripn.net:

В ответе можно увидеть запись RRSIG содержащую хеш-подпись.

Но этого недостаточно, так как в резолве участвуют нижестоящие серверы, ответы которых тоже нужно верифицировать. Тогда владельцы домена верхнего уровня, например «com.», создают такую же пару ключей и подписывают все записи в своей зоне, и после этого добавляют слепок своего открытого ключа в корневую зону. В результате доверяя открытому ключу корневой зоны можно проверить подлинность ключа зоны «com.» и, соответственно, доверять ему:

В ответе запись DS содержит слепок ключа, которым подписывается зона «com.»

Важно понимать, что после каждого изменения в зоне подписание происходит заново. Но, так как корневая зона подписывает только открытый ключ зоны «com.», то нет необходимости перехешировать записи в корневой зоне при каждом изменении в зоне «com.»

Теперь можно установить подлинность ответов от серверов, ответственных за домен «com.»:

Видно, что запись о домене verisign.com. подписана, но на этом этапе возможно установить только подлинность адресов NS-серверов, ответственных за домен verisign.com. Для резолва IP-aдреса необходимо получить ответ от них, поэтому владельцы этих NS-серверов имеют свою пару ключей, которыми подписывают зону и помещают слепок открытого ключа в DS-запись.

Запрашиваем A-запись для домена verisign.com.:

В результате, для проверки подлинности факта, что А-запись verisign.com содержит значение 192.5.6.31 выстраивается такая цепочка доверия:
нам заранее известен открытый ключ корневой зоны «.» и мы ему доверяем. В корневой зоне существует DS-запись о том, что все записи зоны «com.» подписаны указанным в ней ключом и сама запись, соответственно, подписана ключом корневой зоны. Проверив подлинность этой записи, мы доверяем всем записям в зоне «com.», подписанным этим ключом. На серверах, ответственных за зону «com.» содержится DS-запись с открытым ключом verisign.com, подписанная ключом зоны «com.», что позволяет проверить подлинность подписи в ответе NS-сервера, ответственного за verisign.com.

Схематически это выглядит так:

Приведенное выше описание достаточно примитивно и нелепо. Оно написано с целью объяснить принцип работы «на пальцах». Вероятно, оно нисколько не упростит понимание, а только еще больше запутает.

Практика внедрения DNSSEC

Внимание! Данная инструкция устарела. Подписание зоны без использования NSEC3 позволяет обнаружить все DNS записи зоны.
Актуальная инструкция www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server—2

Далее предполагается, что у нас уже есть домен, делегированный на собственные, полностью настроенные DNS, и готовый файл зоны.
Для включения поддержки DNSSEC в named.conf в секцию options нужно добавить:

Инструменты для генерации ключей и подписания зон входят в пакет BIND последних версий.
На этом этапе предполагается, что читателю уже известно что такое ZSK (Zone Sign Key) и KSK (Key Sign Key).
Все приведенные ниже операции необходимо проводить в отдельно созданной папке.

Генерация ключа ZSK:

Генерация ключа KSK:

где my-domain.com — домен для которого генерируются ключи. В результате выполнения этих команд будут созданы две пары ключей.
Далее необходимо скопировать файл зоны в текущую папку и выполнить подписание:

где my-domain.com — текстовый файл зоны. Важно выполнять команду, находясь в одной папке с ключами и файлом зоны; имя файла указывать без пути.
В результате будут созданы два файла:

my-domain.com.signed — подписанный файл зоны
dsset-my-domain.com — файл содержащий две DS-записи

Исходный файл зоны останется без изменений. Далее в конфиге BIND необходимо заменить файл на подписанный:

Развернутые примеры файлов зон можно посмотреть на nox.su.
Чтобы повысить отказоустойчивость своих DNS, рекомендуется использоваться secondary серверы. Cуществует несколько бесплатных сервисов предлагающих slave-серверы с поддержкой DNSSEC. Вот неполный список http://www.frankb.us/dns/. Я использую rollernet.us, поэтому разрешаю трансфер с адресов 208.79.240.3 и 208.79.241.3. При использовании secondary-серверов, записи о них должны присутствовать в файле зоны еще до подписания. Я рекомендую активировать трансфер уже после того как на master-сервере будет находиться подписанная зона.

Далее предполагается, что подписанная зона уже размещена на авторитарном NS-сервере и доступна снаружи:

Команда должна вернуть подписанную зону.

На этом этапе можно активировать secondary сервера и синхронизировать зону по AXFR.

Далее необходимо добавить DS-записи в панели регистратора домена. Они были сгенерированы при выполнении dnssec-signzone и находятся в файле dsset-my-domain в таком виде:

Так выглядит форма добавления DS-записей в панели GoDaddy:

Необходимо переключиться в «Advanced mode» и скопировать обе строки, предварительно отредактировав. Нужно добавить значение TTL и удалить пробел во второй строке в отпечатке ключа, иначе форма вернет ошибку. В результате копируемые строки должны выглядеть так:

Записи будут добавлены только в случае если зона на master-сервере доступна и подписана правильно.

Значения полей в DS-записи:

86400 — TTL данной записи
40513 — Key Tag
5 — Algorithm
1/2 — Digest Type

В приведенном выше примере при генерации ключей был использован алгоритм RSA-SHA1, поэтому запись имеет номер пять.
Таблица номеров алгоритмов:

Digest Type в приведенном примере у первой записи равен 1, во второй 2.
Таблица номеров Digest Type:

У некоторых регистраторов, например Dyn.com, форма добавления DS-записи не предусматривает копирование строк, а требует заполнения всех полей отдельно:

Из-за того, что у Dyn.com список алгоритмов расположен не по порядку и не отмечен номерами, это вызывает некоторую путаницу. При добавлении через эту форму так же нужно удалить пробел в отпечатке второго ключа.

После добавление DS-записей можно проверить их появление на серверах, ответственных за домен верхнего уровня. Для домена «com.» это выглядит так:

В момент, когда это произойдет, можно проверить правильность подписания зоны с помощью DNSSEC Debugger от Verisign и визуализатора цепочки подписания.
Напомню, что после каждого изменения в записях зоны, необходимо выполнять подписание повторно. DS-записи при этом обновлять не нужно.
Если всё правильно, можно переходить к настройке клиентской части.

Настройка клиентского резолвера

Для проверки подписей на стороне клиента, эту функцию должен поддерживать системный DNS, через который происходит резолв адресов. Публичный DNS от Google 8.8.8.8 поддерживает передачу DNSSEC записей, но не производит их верификацию. Подробнее написано в FAQ.
UPD: С 19.03.2013 Google Public DNS производит верификацию подписей DNSSEC, и в случае невалидной подписи не резолвит домен googleonlinesecurity.blogspot.com/2013/03/google-public-dns-now-supports-dnssec.html

Наиболее простой вариант — плагин для Firefox и Chrome.

Плагин позволяет производить резолв в обход системных DNS, имеет свои предустановленные серверы с поддержкой валидации DNSSEC. По умолчанию плагин использует системные DNS, изменить это можно в настройках плагина: выбрать CZ.NIC’s или 217.31.57.6

Для того, чтобы научить утилиту dig проверять подпись, необходимо создать отправную точку в цепочке доверия, создав файл с ключом корневой зоны:

После необходимо в файле /etc/trusted-key.key удалить строку:

Если этого не сделать dig вернет:

Теперь можно проверять подлинность подписей с помощью dig:

Как настроить рекурсивный резолвер с функцией проверки подписей можно прочитать здесь

Практическая польза

Не смотря на то, что стандарт DNSSEC до сих пор находится в разработке, уже возможно извлекать из него пользу.

Публичный SSH-ключ

При первом подключении к серверу SSH клиент просит самостоятельно проверить отпечаток публичного ключа сервера и ввести yes, после чего публичный ключ сервера сохраняется в файле known_hosts.
С появлением DNSSEC публичный ключ может быть помещен в DNS-запись типа SSHFP и, при первом подключении к серверу, проверяться автоматически без запроса. Для активирования этой функции нужно добавить опцию VerifyHostKeyDNS=yes в конфиг SSH-клиента, также необходимо чтобы системный резолвер поддерживал верификацию DNSSEC.

Самоподписанный SSL-сертификат (HTTPS)

UPD: Описанное ниже уже не актуально, после того как стандарт хранения ssl-ключей в DNS был опубликован, и получил название DANE ru.wikipedia.org/wiki/DANE Google убрал поддержку DANE из Chrome. Дисскуссия по этому поводу с разработчиком Chrome github.com/agl/dnssec-tls-tools/issues/4
С помощью DNSSEC можно самостоятельно подписать SSL-сертификат который будет «валидным» в браузере.
Эта экспериментальная функция на данный момент находится в активной разробтке и пока поддерживается только браузером Google Chrome/Chromium.
Черновой вариант стандарта: tools.ietf.org/html/draft-agl-dane-serializechain-01

Технология разрабатывается сотрудником Google по имени Адам Лэнгли (Adam Langley), он ведет очень интересный блог http://www.imperialviolet.org/.
Пост об этой технологии.

Далее предполагается, что домен для которого генерируется сертификат, может быть подписан DNSSEC.

Создание отпечатка ключа:

где gencaa.py файл из пакета dnssec-tls-tools.
Команда вернет строку вида:

Это DNS-запись, которую необходимо добавить в свой файл зоны, заменив EXAMPLE.COM. своим значением. Если зона еще не подписана, это нужно сделать. Если запись добавляется к уже подписанной зоне, нужно, соответственно, выполнить подписание заново.

Проверяем правильность ключа в DNS:

Команда должна вернуть DNSSEC validation is ok: SUCCESS

После того как запись type27 доступна и подписана, можно сгенерировать цепочку доверия DNSSEC:

Подключение сертификата в Nginx выглядит так:

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

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

Источник

DNSSEC – что это такое и почему эта технология так важна?

Страница также доступна на следующих языках:

Интересуетесь протоколом DNSSEC (расширениями безопасности системы доменных имен)? Нажмите на изображение ниже, чтобы изучить нашу инфографику с описанием принципов работы DNSSEC и преимуществ его развертывания.

Краткое описание принципов работы DNS

Для понимания протокола 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 (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 для большего количеста пользователей.

Источник