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: Что такое и зачем
Предисловие
Как оказалось, не так много людей знают что такое 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, поэтому запись имеет номер пять.
Таблица номеров алгоритмов:
| Number | Algorithm |
|---|---|
| 1 | RSAMD5 |
| 2 | DH |
| 3 | DSA/SHA1 |
| 4 | ECC |
| 5 | RSA/SHA-1 |
| 6 | DSA-NSEC3-SHA1 |
| 7 | RSASHA1-NSEC3-SHA1 |
| 8 | RSA/SHA-256 |
| 9 | — |
| 10 | RSA/SHA-512 |
| 11 | — |
| 12 | ГОСТ Р 34.10-2001 |
Digest Type в приведенном примере у первой записи равен 1, во второй 2.
Таблица номеров Digest Type:
| Number | Digest Type |
|---|---|
| 1 | SHA-1 |
| 2 | SHA-256 |
| 3 | SHA-512 |
У некоторых регистраторов, например 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 для вашего домена
Deploying DNSSEC for your domain
Тема безопасности в интернете, как нетрудно заметить, является одной из главной тем данного сайта. Уже довольно подробно рассмотрев многие аспекты этой многоплановой проблемой автор пока не останавливался на одном из базовых, а именно обеспечении безопасности базового механизма сетевого взаимодействия — системы разрешения доменных имён DNS.
Сетевое сообщество давно осознало угрозы, которые несут особенности устройства и функционирования DNS. На протяжении многих лет велись обусждения подходов, выработка механизмов и формирование стандартов, которые бы позволили нейтрализовать выявленные опасности. Этот процесс в итоге вылился в стандарт DNSSEC, который призван если не полностью, то в максимальной степени решить проблемы с безопасностью DNS сохранив, при этом, саму её базовую инфраструктуру и предоставив возможность развёртывания нового механизма защиты прозрачно для конечного пользователя сети.
Согласно статистики на сегодня в мире около 14 процентов от всего количества доменых имён корректно поддерживают DNSSEC. Данная статья является скромной попыткой помочь улучшить ситуацию на расширив практику применения этой актуальной и полезной технологии.
1. Как работает DNSSEC
DNSSEC является расширением протокола DNS позволяющим подтвердить достоверность хранимых в DNS записей путём их цифровой подписи.
Звучит знакомо и, на первый взгляд, понятно и несложно для реализации. Однако, если принять внимание потребовашиеся 20 (!) лет от момента первой расстановки точек над «Ё» в качестве осознания наличия серьёзных проблем с безопасностью DNS в 1990 году и подписи корневой зоны . в 2010 по стандарту DNSSEC, можно понять, что путь был весьма непрост. Безусловно, это отразилось и на самом механизме реализации DNSSEC, который подробно изложен сразу в трёх документах — RFC4033, RFC4034 и RFC4035.
Сразу необходимо подчеркнуть два важных момента касательно DNSSEC.
Рассмотрим сам механизм подписи и передачи удостоверяющих данных.
Как во всякой системе на базе цифровых подписей используется пара из закрытого и открытого ключей. Однако, в DNSSEC таких пар, как минимум, две.
Рабочий набор, который предназначен для непосредственно подписи данных содержащихся в зоне, называется Zone Signing Key (или ZSK). Ввиду того, что размер зоны может быть достаточно большим для снижения вычислительной нагрузки при проверки подписи его длина относительно невелика. В настоящее время используются ключи длиной 1024 бита. Очевидно, что столь небольшая размерность сказывается на криптостойкости набора. Поэтому ZSK согласно стандарту рекомендуется регулярно менять на новый набор.
Вторым набором, который носит название Key Signing Key (или KSK) подписывается рабочий набор ключей. Ввиду того, что размер данных ZSK невелик, размерность ключа подписи их набора для надёжности может быть больше. На сегодня обычная их длина составляет 2048 битов. Данная размерность считается достаточно стойкой ко взлому. В этой связи ротация KSK может осуществляться на порядок реже нежели в случае ZSK.
Потребность в использовании второго более криптостойкого набора ключей (KSK) возникла ещё и потому, что, как было упомянуто выше, DNSSEC предполагает передачу удостоверяющих данных для включения в доменную зону более высокого уровня через регистратора подписываемого при помощи DNSSEC домена. Эти данные создаются именно на базе более надёжного KSK в виде хэша открытого ключа. Так как нет необходимости в его частой ротации ввиду высокой надёжности, не возникает и необходимости в регулярном обновлении данных у регистратора.
Подписанной с помощью DNSSEC зоной считается такая зона, которая содержит следующий набор специальных ресурсных DNS-записей.
Рассмотрим как эти записи выглядят в реальности, опросив, к примеру, зону .ru.
Суть контроля целостности данных DNSSEC, которую реализуют записи типа NSEC, состоит в необходимости обеспечить подтверждённый цифровой подписью ответ в случае отсутствия искомой информации в данной зоне. В случае использования стандартного DNS сервер может просто вернуть пустую строку. Но пустую строку невозможно подписать цифровой подписью. Поэтому в данном случае сервер поддерживающий DNSSEC вернёт в ответ набор данных, который будет содержать ближайшую, следующую по алфавиту за запрошенной, существующую запись в зоне с выдачей информации из NSEC и ассоциированных с ними RRSIG как подтверждение её отсутствия.
Для наглядности и понимания проблемы возьмём для примера домен 2 уровня dxdt.ru для демонстрации организации структуры записей NSEC.
Из ответа можно увидеть, что вслед за первым доменом зоны dxdt.ru со списком используемых им типов ресурсных записей следует запись для поддомена dns.dxdt.ru. Если мы воспользуемся аналогичным запросом уже для dns.dxdt.ru мы получим аналогичную запись и для него с указанием последующего домена в данной зоне.
Последняя запись для домена xn--80adjurfhd.xn--click-uye2a8548c.dxdt.ru замыкается вновь на первый домен зоны. По сути мы сейчас осуществили сканирование зоны DNS для домена dxdt.ru методом zonewalking что, как правило, является нежелательным действием для владельца домена и может служить базой для атаки со стороны злонамеренного исследователя.
Тот же процесс можно проделать в автоматическом режиме используя утилиту ldns-walk передав ей имя зоны как параметр.
Указанную проблему решает расширение стандарта DNSSEC носящее название одноимённой ресурсной записи NSEC3 и описанной в стандарте RFC5155. В отличие от NSEС, в качестве указателя используется хэш наименования следующей записи. При этом при вычислении этого хэша, во-первых, может использоваться специальная парольная фраза, т.н. «соль», а, во-вторых, сам хэш может вычисляться в несколько итераций. Всё это существенно повышает стойкость к подбору для вычисления следующей подписанной DNSSEC записи.
Для указания всех этих параметов используется специальная ресурсная запись NSEC3PARAM сам факт наличия которой говорит о том, что зона должна содержать подписанные описанным в ней методом записи NSEC3.
Первое число после типа записи 1 означает используемый алгоритм формирования хэша, в данном случае RSA/MD5; значение 0 далее является флагом Opt-Out и означает, что NSEC3 не будет включать неподписанные цифровой подписью записи; следующее далее 3 означает число итераций при вычислении хэша; и, наконец, 00ff это «соль».
Как можно догадаться при таком способе формирования цепочки задача просканировать зону методом zonewalking становится не столь тривиальной, как это было показано выше при использовании NSEC.
При выборе настроек вычисления хэша для NSEC3 следует учесть, что сам этот процесс более затратен в части используемой вычислительной мощности и, соответственно, производительности DNS серверов, которые будут обращаться к данной зоне (см. подробное исследование от NLnetLabs).
2. Как подписать DNSSEC свой домен
2.1. Прежде чем начать
Как видно из вышеизложенного, система DNSSEC, во-первых, предполагает наличие иерархической цепочки подписанных зон, которая должна не прерываться от корневого домена вплоть до вашего, во-вторых, регистратор домена должен иметь функционал добавления в свою выдачу отпечатка открытого ключа KSK, которым будет подписываться конкретная зона и, в-третьих, все обслуживающие зону DNS серверы должны поддерживать DNSSEC.
Обычно на этом сайте все действия показаны на примере используемого им домена kostikov.co. Однако, на этот раз традиция будет нарушена. Ввиду того, что домен зарегистрирован у компании Namecheap который на данный момент времени не поддерживает DNSSEC для зоны .co, отступим от этой традиции и рассмотрим реализацию данной технологии базе домена peek.ru.
Домен peek.ru зарегистрирован в RU-center который осуществляет поддержку DNSSEC для зоны .ru.
В качестве вторичного DNS-сервера мы будем использовать бесплатный DNS сервис от afraid.org благодаря наличию у него поддержки DNSSEC чего, к сожалению, лишён более популярный сервис от Hurricane Electric.
Таким образом, проблем с поддержкой нет и можно начинать.
2.2. Подготовка инструментария
Для развёртывания DNSSEC будет использоваться DNS-сервер NSD работающий как первичный для нашей зоны в среде операционной системы FreeBSD.
Для облегчения процессов создания ключей и подписи с их помощью доменной зоны воспользуемся набором утилит ldns, который поддерживается создателем NSD и Unbound — компанией NLnetLabs. Он имеется в составе портов FreeBSD.
Обратите внимание, что в состав ldns входит также и популярная утилита drill для работы с запросами к DNS серверам. Она имеется также и в наборе кэширующего DNS Unbound, который уже предустановлен во FreeBSD начиная с версии 10.0. Поэтому, если вы уже имеете Unbound в системе то нет нужды устанавливать drill из пакета ldns. Выше, как видно, её повторная установка отключена.
Далее проверим структуру хранения файлов доменов для которых NSD будет выступать в качестве первичного сервера. Если его установка производилась в соответствии со статьёй «Настройка первичного DNS-сервера на базе NSD» то вы должны иметь примерно следующую картину.
То есть файлы зон хранятся в отдельных подкаталогах имена которых соответствуют именам обслуживаемых доменов, равно как и сам файл носит имя домена и расширение .zone.
2.3. Создание ключей
Прежде чем приступать к созданию пар ключей следует определиться, будет ли осуществляться поддержка NSEC3 или достаточно будет NSEC. Автор рекомендует использовать первый вариант. Сам хэш в любом случае будет формироваться по алгоритму SHA1.
Для целей демонстрации воспользуемся протоколом DSA-NSEC3-SHA1 или номер 6.
В качестве первого этапа создадим набор ZSK длиной 512 битов при помощи утилиты ldns-keygen.
В результате в рабочем каталоге подписываемой зоны появилось три файла, назначение которых понятно из расширений — закрытый и открытый ключи, а также отпечаток открытого ключа. Кроме того в наименовании файла фигурирует код используемого алгоритма и id ключей.
Создадим также пару KSK. Несмотря на то, что на практике продемонстрирована возможность использования разных алгоритмов для KSK и ZSK, мы строго последуем рекомендациям RFC4035 и RFC6840 и воспользуемся тем же DSA-NSEC3-SHA1 увеличив, однако, размерность до 1024 битов. Кстати, эта размерность является максимально возможной для этого алгоритма.
KSK был создан с id 44711, а увеличенная длина пар ключей сполна отразилась и на длине файлов пары закрытый / открытый ключ, но не на размере отпечатка.
2.4. Подписывание зоны
Перед подписанием зоны следует обновить serial нашей зоны который расположен в ресурсной записи SOA, после чего файл зоны peek.ru приобретёт следующий вид (публикуется в сокращённом виде).
Подпишем её используя утилиту ldns-signzone. В качесте параметров укажем: при помощи ключа -n что будет использоваться NSEC3, -t используя 10 итераций (справочно, RFC6781 рекомендовано значение 100 но, при этом, оно не должно превышать значения, указанные в п.10.3. RFC5155) и ключа -s где будет указана «соль».
Предварительно сгенерируем случайную «соль», например, таким способом.
И, собственно, подпишем зону.
В результате в рабочем каталоге был создан файл с раширением .signed который и является файлом с подписанной DNSSEC зоной. Взглянем на его содержимое (также сокращено).
Как видно, всё подписалось так, как это и было задумано, включая NSEC3. Публичные ключи DNSKEY были автоматически добавлены в подписанную зону. Обратите внимание, что сроком окончания действия наших подписей установлено 13:34:47 09-12-2016 то есть через 4 недели от момента формирования цифровых подписей.
2.5. Подключение к DNS
Теперь включим изменёный файл зоны в конфигурацию DNS-сервера NSD. В результате раздел для peek.ru приобретёт следующий вид.
Перезапустив NSD с новой конфигурацией можно увидеть прошедший успешно трансфер зоны на вторичные DNS-серверы.
Осталось сообщить отпечаток нашего публичного KSK регистратору домена. Напомню, он хранится в файле с раширением .ds. Регистратор нашего домена RU-center также (почему-то) требует предоставления публичной части KSK.
Добавление производится путём копирования вышеприведённых данных в специальную форму в личном кабинете.
2.6. Проверка результатов
Итак, после данные нашей свежеподписанной DNSSEC зоны peek.ru синхронизировались и можно проверить результаты.
Самым простым способом это сделать будет воспользоваться уже знакомой утилитой drill с ключами трассировки (-T) DNSSEC (-D).
Более наглядно это можно увидеть воспользовавшись мощным аналитическим инструментом DNSViz от компании Verisign.
Схема показывает связи между зонами и используемыми ключами цифровых подписей.
С помощью того же ресурса можно производить детальный анализ проблем с DNSSEC выявляя место и причины их возникновения.
Итак, развёртывание технологии DNSSEC для нашего домена завершено успешно. Впереди её эксплуатация и использование преимуществ, а также, что важно, поддержание в работоспособном состоянии. Но это уже тема для новых статей.
Статья была полезной? Тогда прошу не стесняться и поддерживать деньгами через PayPal или Яндекс.Деньги.
