DNSSEC

DNSSEC — расширение DNS , которое проверяет подлинность ответа от DNS-сервера, то есть защищает от подмены IP-адресов . Это позволяет защитить ваш сайт от кибератак (загрязнения кеша DNS-серверов, перенаправления или подмены DNS-запросов).

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

• НЕ защищает от DDoS-атак ;
• НЕ гарантирует конфиденциальность обмена данными;
• НЕ шифрует информацию веб-сайтов.

Чтобы никто не смог взломать ваш сайт, используйте DNSSEC в комплекте с SSL -шифрованием, защитой от DDoS-атак и двухступенчатой аутентификацией.

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

На текущий момент услуга DNSSEC работает только для доменов в зонах .RU, .SU, .РФ, .COM, .NET, .NAME. Список зон будет пополняться.

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

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

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

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

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

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

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

1. ZSK — ключ подписывания зоны. Используется для подписывания наборов ресурсных записей доменной зоны. Обычно есть один ключ, которым подписываются данные зоны, но допускается и несколько ключей. Например, могут быть ключи для каждого из разных алгоритмов цифровой подписи. Важной концепцией DNSSEC является то, что ключ, которым подписаны данные зоны, ассоциирован с самой зоной, а не с ответственным сервером имён зоны.
2. KSK — ключ подписывания ключей. Используется для подписывания ключей ZSK. Он также связывает цепочкой доверия вашу и родительскую доменные зоны.

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

• ZSK — каждые 2-3 месяца;
• KSK — раз в 6 месяцев.

Как подключить услугу 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 для вашего домена

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.

• Во-первых, он предназначен именно для удостоверения данных, содержащихся в записях DNS но никак не для их сокрытия. Они по-прежнему хранятся и передаются в открытом виде.
• Во-вторых, так же как и в случае с сертификатами SSL / TLS подтверждение надёжности данных строится на цепочке доверия от корневой зоны к конечному домену. Но сам сам механизм передачи удостоверяющих данных, в отличие от сертификатов, выстраивается, как бы, снизу вверх. То есть подписанная доменная зона нижнего уровня передаёт данные, которые необходимы для подтверждения её достоверности, выше расположенной доменной зоне которая включает их в свою выдачу как заслуживающие доверия. Она сама, в свою очередь, таким же образом включает аналогичные данные в домены более высокого уровня и так вплоть до корневого домена. Корневому же домену, очевидно, оказывается изначальное и безусловное доверие.

Рассмотрим сам механизм подписи и передачи удостоверяющих данных.

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

Рабочий набор, который предназначен для непосредственно подписи данных содержащихся в зоне, называется Zone Signing Key (или ZSK). Ввиду того, что размер зоны может быть достаточно большим для снижения вычислительной нагрузки при проверки подписи его длина относительно невелика. В настоящее время используются ключи длиной 1024 бита. Очевидно, что столь небольшая размерность сказывается на криптостойкости набора. Поэтому ZSK согласно стандарту рекомендуется регулярно менять на новый набор.

Вторым набором, который носит название Key Signing Key (или KSK) подписывается рабочий набор ключей. Ввиду того, что размер данных ZSK невелик, размерность ключа подписи их набора для надёжности может быть больше. На сегодня обычная их длина составляет 2048 битов. Данная размерность считается достаточно стойкой ко взлому. В этой связи ротация KSK может осуществляться на порядок реже нежели в случае ZSK.

Потребность в использовании второго более криптостойкого набора ключей (KSK) возникла ещё и потому, что, как было упомянуто выше, DNSSEC предполагает передачу удостоверяющих данных для включения в доменную зону более высокого уровня через регистратора подписываемого при помощи DNSSEC домена. Эти данные создаются именно на базе более надёжного KSK в виде хэша открытого ключа. Так как нет необходимости в его частой ротации ввиду высокой надёжности, не возникает и необходимости в регулярном обновлении данных у регистратора.

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

1. DNSKEY или DNS Key Record. В данных записях публикуются открытые ключи ZSK и KSK.
2. RRSIG или DNSSEC Signature. В данных записях содержатся электронные подписи ресурсных записей.
3. NSEC (или более новая NSEC3) — Next-Secure Record. Служит для контроля целостности данных зоны. NSEC запись содержит отсортированный по алфавиту и закольцованный список записей для данной зоны (последняя ссылается на первую) с указанием типов используемых ресурсных записей.
4. DS или Delegation Signer. Содержит цифровой отпечаток открытого ключа KSK для низлежащего делегируемого домена. Она является необязательной для домена, который таких подчинённых доменов не имеет.

Рассмотрим как эти записи выглядят в реальности, опросив, к примеру, зону .ru.

В ответе видно, что DNS сервер вернул три публичных ключа для зоны .ru. Значение 257 первой записи DNSKEY соответствует типу ключа и означает что это KSK. Нетрудно заметить, что он короче двух следующих с кодом 256 соответствующим ZSK. Второе число после типа ключа, 3, означает код протокола, а третье, 8, использованный для цифрового ключа алгоритм — в данном случае RSA/SHA256 (см. полный список кодов алгоритмов и их применимость).

Полученный набор подписей ресурсных записей зоны .ru по количеству соответствует числе используемых в этой зоне их типов. Здесь их 4 — NSEC3PARAM, DNSKEY, NS и SOA. Первым числом, 8, после имени DNS-записи является тот код использованного алгоритма; далее, 1 указывает что .ru это домен первого уровня; число 345600 это значение TTL для данной записи; после идут дата и время окончания действия данной подписи и дата и время её создания в формате YYYYMMDDHHMMSS; и, наконец, число которое указывает идентификационный номер id ключа, с помощью которого сформирована данная подпись. Нетрудно заметить, что id 62160 соответствует ZSK, а 28642, соответственно, KSK.

Запись DS с цифровым, как видно по первому числу 28642 которое, как было показано чуть выше, является id для KSK зоны .ru. Ещё раз хотелось бы подчеркнуть, что этот ответ был получен не от 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 запросов или ознакомиться со сведениями о поддержке DNSSEC от ICANN.

В вводной части мы уже убедились, что зона .ru, к которой принадлежит наш домен peek.ru, поддерживает DNSSEC — на момент написания статьи ею используются по две пары ключей ZSK и одна пара KSK. Публичный KSK, соответственно, имеет цифровой отпечаток в корневой зоне.

В качестве вторичного 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.

Добавление производится путём копирования вышеприведённых данных в специальную форму в личном кабинете.

После сохранения введённых данных начнётся процесс обновления DNS-серверов в зоне .ru и через некоторое время можно будет посмотреть что получилось.

2.6. Проверка результатов

Итак, после данные нашей свежеподписанной DNSSEC зоны peek.ru синхронизировались и можно проверить результаты.

Самым простым способом это сделать будет воспользоваться уже знакомой утилитой drill с ключами трассировки (-T) DNSSEC (-D).

Вывод демонстрирует выстроенную полную цепочку доверия от корневой зоны, через зону .ru к нашему домену peek.ru. Значени [T] — Trusted по всему списку говорит о том, что всё функционирует должным образом и ошибок нет.

Более наглядно это можно увидеть воспользовавшись мощным аналитическим инструментом DNSViz от компании Verisign.

Схема показывает связи между зонами и используемыми ключами цифровых подписей.

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

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

3. PROFIT !

Статья была полезной? Тогда прошу не стесняться и поддерживать деньгами через PayPal или Яндекс.Деньги.