Enable dnssec support что это

Настройка DNSSEC на Ubuntu Server + Bind9

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

Достоверность ответа DNS-сервера никак не проверяется. Это позволяет отправить пользователя, обратившегося к доменному имени, на произвольный IP-адрес, подменив ответ сервера.
Также уязвимы кэширующие DNS-серверы провайдеров, выступающие как резолверы для клиентов: Атака Каминского.
Сегодня существуют технологии, предусматривающие хранение открытых ключей в DNS-записях, например, DKIM-подписи в электронной почте, SSH-ключей в записях SSHFP и т.д. Все эти технологии требуют защиты от подделки DNS.Поэтому была разработана технология DNSSEC позволяющая убедиться, что DNS сервер является подлинным.

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

В этой статье разберём как можно внедрить данную технологию на наш сервер с операционной системой Ubuntu.

Начальная конфигурация

Формирование ключей

Создаём каталог, в котором будем хранить ключи и сразу переходим в него.

На CentOS / Red Hat:

На Ubuntu / Debian:

Генерируем мастер ключ для зоны (KSK):

Генерируем ключ для зоны (ZSK):

Ключи ГОСТ

Генерируем мастер ключ для зоны (KSK):

Генерируем ключ для зоны (ZSK):

Смена прав и владельца для сгенерированных файлов.

На CentOS / Red Hat:

На Ubuntu / Debian:

Подписываем зоны

Ручное подписывание зоны

Переходим в каталог, где хранится наша зона.

CentOS / Red Hat:

Ubuntu / Debian:

*Пути могут отличаться (зависит от ваших настроек)

Система должна вернуть, примерно, следующее:

В каталоге хранения зон мы должны увидеть obu4alka.ru.signed — это файл подписанной зоны.

Редактируем конфигурационный файл bind.

На CentOS / Red Hat:

На Ubuntu / Debian:

В настройке зоны меняем путь к файлу:

На CentOS / Red Hat:

На Ubuntu / Debian:

Автоматическое подписывание зоны

Каждый раз после редактирования зоны не очень удобно ее постоянно подписывать командой dnssec-signzone.
Для автоматизации процесса в конфигурационном файле bind добавим следующие опции:

Для зоны редактируем:

Проверяем, что у пользователя named/bind есть права на запись в каталог хранения зоны. При необходимости, меняем владельца:

Также права на файлы *.private должны быть выставлены в 400

Удаляем старый файл подписанной зоны:

На CentOS / Red Hat:

На Ubuntu / Debian:

В каталоге зоны должны появиться дополнительные 3 файла:

Так как DNSSEC основан на обеспечении цепочки доверия, чтобы процесс верификации заработал, требуется чтобы регистратор заверил созданный KSK-ключ,подтвердив своё доверие. Для этого создадим на основе KSK-ключа DSKEY-ключ (Delegation Signature Key)

Команда выдаст примерно следующее

Копируем две сгенерированные строки в интерфейсе ввода DSKEY на сайте регистратора домена.

Верификация заработает после того как регистратор обновит параметры первичной зоны.

Однако для полноты счастья, если регистратору вместо KSK потребуется именно запись формата DS, мы сгенерируем записи DS от созданного ранее KSK (Kobu4alka.ru+005+40201.key) с использованием трёх различных алгоритмов хэширования (SHA-1 (type 1), SHA-256 (type 2) и SHA-384 (type 4) соответственно):

В итоге, для завершения активации DNSSEC на нашем домене obu4alka.ru, мы должны отправить нашему регистратору доменных имён такую вот инфу:

Проверка DNS сервера на DNSSEC записи

Чтобы проверить, отдает ли наш сервер bind ответы с цифровыми подписями, вводим команду:

в данном примере мы запросили IP-адрес для записи www.obu4alka.ru, а +dnssec означает, что также клиент запрашивает RRSIG для этой записи.
Мы должны увидеть записи вместе с их RRSIG, например:

Если есть вопросы, то пишем в комментариях.

Также можете вступить в Телеграм канал, ВК или подписаться на Twitter. Ссылки в шапки страницы.
Заранее всем спасибо.

Источник

DNSSec: Что такое и зачем

Предисловие

Как оказалось, не так много людей знают что такое DNSSec, для чего он нужен, для чего нет и стоит ли его внедрять у себя. Так как на русском языке информации на этот счет мало, я постараюсь пролить свет на эти вопросы.

Что такое DNSSec

Немного истории

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

Принцип работы DNSSec тот же, что и у цифровой подписи. То есть закрытым ключом подписываем, открытым сверяем.
Особенность состоит в том, что DNSSec использует два типа ключей — одним подписывается зона (ZSK, zone signing key), другим подписывается набор ключей (KSK, key signing key). Сделано это из таких соображений: зона может быть достаточно большой чтобы удалось подобрать закрытый ключ, поэтому его надо менять почаще, да и сделать его можно покороче, чтобы зоны подписывались быстрее; KSK же используется для небольших объемов данных, поэтому его можно и подлиннее сделать и менять пореже. Тем более, что хэш от открытой части KSK требуется отправить в родительскую зону, что хотелось бы делать не слишком часто.

Этим ключом подписывается набор DNSKEY записей.
Кроме того, от открытой части KSK берется хэш, который в дальнейшем отправляется в родительскую зону. В вышеприведенном примере это DS записи (Delegation Signer).
В случае с корневой зоной предполагается, что открытая часть ключа будет сообщена резолверу вручную. А чтобы при смене ключа не обновлять его каждый раз вручную, существуют механизмы его автоматического обновления, например у BIND’а есть опция managed-keys.
Очевидно, что закрытую часть KSK следует хранить как зеницу ока — во-первых иначе исчезает весь смысл DNSSec, во-вторых в случае компрометации быстро сменить KSK не получится.

Next SECure

Ну, вот подписали мы зону, но все равно кто-то посторонний может добавить в нее свою информацию и, даже неподписанная, она будет отдаваться сервером наравне с подписанной.

Чтобы такого не происходило, при подписи зоны доменные имена сортируются в алфавитном порядке, к каждому из них добавляется запись NSEC, в которой указывается какое следующее доменное имя защищено и какие записи для него присутствуют в зоне. Последняя NSEC запись указывает на SOA.
Если авторитетный сервер возвращает ответ NXDOMAIN (RCODE=3) или NODATA (RCODE=0), то в ответе обязательно должна присутствовать NSEC запись. Пример такого ответа:

Так как ответ NXDOMAIN всегда сопровождается SOA записью, то в подписанной зоне возвращается SOA и подпись для нее.

Эта NSEC запись показывает, что указанное имя не попадает под маску.

А уже эта NSEC запись говорит о том, что доменное имя не обнаружено.

Недостаток NSEC очевиден — кто угодно может получить содержимое зоны просто опросив для каждого имени эту запись. В связи с этим механизм был доработан и появились записи NSEC3, в которых доменные имена хэшируются.
NSEC3 для вычисления хэша может использовать соль, помимо соли можно задать количество итераций. Стоит заметить, что увеличение количества итераций приводит к увеличению нагрузки как на резолвер, так и на авторитетный сервер, причем на последний в большей степени. Это происходит из-за того, что для возвращения NXDOMAIN, авторитетный сервер должен вычислить хэш, и не один. Процесс описан в RFC 5155.

Кроме того, NSEC3 запись имеет поле флагов, которого нет у NSEC. На данный момент определен только один флаг — OPT-OUT, благодаря которому существует возможность подписывать не всю зону (что при больших размерах может быть весьма длительным процессом), а только те доменные имена, для которых есть DS записи.
С одной стороны OPT-OUT позволяет сильно сократить время подписи, однако при его использовании, наличие у злоумышленника доступа к файлу зоны позволяет ему добавить незащищенную запись, которая в дальнейшем может доставить проблемы.

Механизм работы

Оказываемые эффекты

Зачем это нужно

Это сложный вопрос. Во-первых, надо учитывать создаваемые эффекты; во-вторых, требуется организовать надежное хранилище для ключей; в-третьих, следить за ротацией ключей; в-четвертых, следить за сроком годности подписей; в-пятых, DNSSec усиливает эффект amplified ddos.
Все это является платой за то, чтобы быть уверенным в информации, получаемой от авторитетных DNS серверов. Сейчас, правда, сообщество придумывает что еще можно включить в DNSSec, чтобы его можно было монетизировать, а некоторые и вовсе задаются весьма смелыми и интересными вопросами, например Phil Regnauld, член научного совета AFNIC, поинтересовавшийся «Will DNSSEC bring down the certificate industry?» на семинаре этого совета.

Источник

Практическое применение 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 разработана как расширение системы DNS для защиты от подмены данных. Позволяет не допустить фишинга, отравления кэша и других интернет-угроз.

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

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

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

Рекомендуем длину KSK-ключа и период его обновления выбирать больше, чем для ZSK-ключа. ZSK-ключ используется каждый раз, когда происходит редактирование доменной зоны или её обновление. Использование короткого ZSK-ключа облегчает процесс подписи, так как снижает нагрузку на сервер, а небольшой период обновления позволяет поддерживать высокий уровень безопасности. С помощью KSK-ключа производится только подписание ключей. Он используется реже ZSK-ключа. Поэтому длинный ключ не так сильно влияет на производительность. Для длинного ключа можно указать длинный период обновления ключа без ущерба для безопасности. Длинный период обновления KSK позволяет реже передавать DS-записи в родительскую зону.

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

Процесс обновления KSK-ключа:

Процесс обновления ZSK-ключа:

При использовании DNSSEC увеличивается размер пакета DNS. Если размер пакета превышает 512 байт, используется протокол TCP. На некоторых маршрутизаторах работа DNS по протоколу TCP может быть запрещена (закрыт порт 53).

При превышении размера MTU пакеты DNS фильтруются. MTU — максимальный размер полезного блока данных одного пакета, который может быть передан без фрагментации. Распространённый размер MTU — 1500 байт.

Некоторые регистраторы доменных имён требуют удалять пробелы из созданных ключей при публикации DS-записей.

Включение поддержки DNSSEC

Поддержка DNSSEC доступна для PowerDNS, начиная с версии 3.2.

PowerDNS до 4-й версии не полностью поддерживает CAA-записи. В связи с этим на DNS-сервере с PowerDNS до 4-й версии подписывание домена с помощью DNSSEC может привести к недоступности CAA-записей.

Включить поддержку DNSSEC и настроить параметры ключей может администратор в Домены → Доменные имена → Настройки. Подробнее см. в статье Настройки DNS-сервера.

Почтовые уведомления

Для включения и поддержки работы DNSSEC нужно вручную публиковать и обновлять DS-записи в родительской доменной зоне. Почтовые уведомления DNSSEC позволяют настроить получение уведомлений о новых DS-записях, требующих публикации. Для этого включите опцию Настройки → Почтовые уведомления → Уведомления от расширения DNSSEC dns-сервера.

Включение защиты DNSSEC домена

Включение состоит из этапов:

Проверка максимального значения TTL в доменной зоне

Для правильного обновления ключей нужно, чтобы максимальное значение TTL в доменной зоне имело значение менее 2 недель (1209600 секунд). Проверьте значения TTL ресурсных записей доменной зоны в Домены → Доменные имена → Записи → столбец TTL, сек. По умолчанию TTL-зоны равно 1 часу (3600 секунд).

Подписание доменной зоны

Включите опцию Домены → Доменные имена → Изменить → Подписать домен и нажмите Ok. Запустится фоновый процесс подписания доменной зоны. В ходе процесса генерируются KSK и ZSK ключи. На время работы процесса в Домены → Доменные имена → столбец Состояние отображается иконка . При успешном подписании доменной зоны иконка изменится на . Для домена становится доступной кнопка DNSSEC и отображается баннер «Есть неопубликованные DS-записи».

Подписание доменной зоны доступно пользователям с уровнем доступа «Пользователь» или «Администратор».

Создание цепочки доверия

Чтобы создать цепочку доверия, нужно передать DS-запись и, если требует регистратор, DNSKEY-записи в родительскую доменную зону. Эти записи доступны в Домены → Доменные имена → DNSSEC.

Для каждой записи из списка DS-записей отображаются данные:

Показать DNSKEY — по нажатию кнопки отображается таблица DNSKEY-записей. Для каждой записи из списка DNSKEY-записей отображаются следующие данные:

Передача DS-записей осуществляется одним из следующих образов:

Один раз в неделю ISPmanager проверяет наличие DS-записей в родительской зоне. Необходимо, чтобы было передано хотя бы по одной DS-записи для каждого KSK-ключа. Успешное прохождение проверки завершает процесс включения защиты DNSSEC. В Домены → Доменные имена → столбец Состояние появится иконка

Отключение защиты DNSSEC домена

Чтобы отключить защиту домена:

Отключить защиту домена может пользователь с уровнем доступа «Пользователь» или «Администратор».

Отключение поддержки DNSSEC

Отключить поддержку DNSSEC может администратор в Домены → Доменные имена → Настройки . Подробнее см. в статье Настройки DNS-сервера. После подтверждения изменений происходит отписывание всех доменов и удаление всех их ключей.

Источник