DNSSEC в Windows Server – функционал и использование

Привет.

Технология DNSSEC существует достаточно давно и реализована в Windows Server 2008 R2 и Windows 7. Не идеально, но реализована. В следующем поколении продуктов – Windows Server 2012 и Windows 8 – реализация DNSSEC уже является полноценно работоспособной.

Но пользуются ей (в основном из-за смутности преимуществ DNSSEC и пугающей своей неочевидностью настройки) – единицы.

За последний год (стартовый вариант статьи написан в 2010 году, поэтому к ряду оборотов типа “недавно” надо относиться с пониманием) я использовал эту технологию в двух проектах, и после устного общения с коллегами (которые в большинстве своём в администрировании Windows-систем далеко не первый год) выяснил, что DNSSEC вообще является мёртвой зоной – она вроде есть в плане технической реализации, но её вроде и нет. В enterprise-сетях её вообще не заметно, разве что только у части хостинг провайдеров.

Это нужно исправлять, так как в DNS достаточно много негатива, который или не лечится совсем, или лечится “костыльными” решениями.

Я предполагаю, что Вы знаете, как работает обычный DNS, плюс прочитали статью про обеспечение безопасности DNS на Windows Server. Если ещё не сделали это – сейчас самое время.

Все записи DNS, IP-адреса и прочие выбраны случайно и не имеют никакого отношения к реальности. Совпадения случайны. Цель придумывания этих значений – наглядность изложения и упрощение понимания технологии DNSSEC. Их (имена записей и IP-адреса) не надо добуквенно копировать к себе, а потом удивляться артефактам поведения системы DNS. Я предупредил.

DNSSEC в Windows Server

• Что делает DNSSEC
• Не рано ли внедрять DNSSEC / Нужен ли DNSSEC для внутрикорпоративной сети?
• Как работает DNSSEC
• DNSSEC и логика кэширования
• Терминология DNSSEC
  • Записи SIG и RRSIG
  • Записи NXT и NSEC
  • Запись NSEC3
  • Ключевые пары – ZSK и KSK
  • Записи DNSKEY, они же “Якори доверия”, они же trust anchors
  • Записи DS
  • Записи DLV – “подстраховка”
• Включаем DNSSEC: Создаём ключи
  • Создание ключей защиты ключей (KSK)
  • Создание ключевой пары для зоны (ZSK)
  • Резервное копирование ключей DNSSEC
• Включаем DNSSEC: Операции с DNS-зонами
  • Подписываем зону
  • Распространяем её trust anchor’ы
• Включаем DNSSEC: Подготавливаем DNS-сервера
• DNSSEC: Настройки со стороны клиентов (NRPT)
• Тестируем DNSSEC

Что делает DNSSEC

Ключевой задачей DNSSEC является построение доверенной инфраструктуры разрешения имён в Интернете. То есть и запросы и ответы сервера (как с данными, так и негативные) должны быть авторизованы.

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

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

Не рано ли внедрять DNSSEC?

Не рано ли внедрять DNSSEC? Не поздно ли Microsoft добавила его в Windows Server 2008 R2?

Нет и нет.

Для полноценного функционирования DNSSEC необходимо, чтобы цепочка доверия начиналась с корневой зоны, т.е. “точки”. “Точку” подписали 28 июля 2010 года, а, к примеру, зону “com” – только 31 марта 2011 года. Поэтому и внедрять DNSSEC уже можно, и Microsoft добавил DNSSEC в продукт заранее (вспомните, что Windows Server 2008 R2 вышел 1 августа 2009 года). Плюс необходима поддержка со стороны client resolver – этот функционал поддерживается Windows 7 (правда, фигово).

Поэтому для использования DNSSEC в корпоративных сетях есть все основания даже если клиентский парк имеет в своём составе далеко не современную Windows 7.

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

Техническая информация доступна на официальном сайте “безопасной точки” – www.root-dnssec.org, ключи и прочее доступны на www.iana.org/dnssec.

Фундаментальные механизмы DNSSEC описаны в RFC 4033, RFC 4034 и RFC 4035. Ранее DNSSEC был документирован в RFC 2535, но так как данный стандарт полностью перекрывается тремя вышеупомянутыми, то получается следующая ситуация: в Windows Server 2003 и 2008 DNSSEC вроде как есть, но только для secondary-зон и в соответствии с устаревшим RFC. Поэтому он вроде как есть, но частично и не совместим с правильной и актуальной реализацией в Windows Server 2008 R2 и Windows 7.

DNSSEC и логика кэширования

До

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

• Подписанные зоны (целиком, чтобы подтвердить их неизменность и подлинность)
• Подписанные одиночные записи
• Подписанные негативные ответы об отсутствии записей
• Подтверждённое информирование клиента о причинах невозможности разрешения записи

Т.е. нам надо, чтобы ответ сервера вида “Запись X разрешилась в адрес Y”, равно как и “Запись X не существует” мог существовать как отдельный объект, кэшироваться, проверяться на подлинность и отсутствие модификаций. Вот всё это DNSSEC будет нам предоставлять.

Теперь время изучить специфичную терминологию.

Терминология DNSSEC

До подробного изучения этого раздела следующие читать не нужно.

Терминология DNSSEC: Новый тип записи – RRSIG (ранее SIG)

Тип записи RRSIG переводится как Resource Record Signature (подпись ресурсной записи) и является ключевым компонентом DNSSEC. Ранее был тип записи под названием SIG (почитать подробнее можно в RFC 2931), а RRSIG – это её обновлённый вариант, адресно “привязаный” к технологиям семейства DNSSEC. То есть, если у Вас есть DNSSEC – то надо возвращать RRSIG к каждой записи, если просто хотите подписать отдельную запись в зоне – SIG. Записи данных типов будут возвращаться в ответе со стороны сервера в качестве “дополнения” к основной части ответа, подтверждая её подлинность. Как выглядела SIG, и как сейчас выглядит RRSIG: sig-host.atraining.ru. 1800   IN A   127.1.2.3 sig-host.atraining.ru. 1800   SIG   (      A      5      3      1800      20110101123456      20120101123456      12345      atraining.ru.      abcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabc= ) Разберём её состав. Первой строчкой идёт та запись, которую подписываем. Видим, что это хостовая запись sig-host в домене atraining.ru., с TTL равным получасу (1800 секунд), класса IN и разрешается она в IPv4-адрес (потому что имеет тип A) равный 127.1.2.3. В нашей же записи, которая SIG, и имеет то же значение TTL в 1800 секунд, поля будут следующими (я выписал их в столбик для наглядности, они могут и через пробел идти):

• Тип оригинальной записи – A (в данный момент, т.к. используется RRSIG, здесь пишут нуль, чтобы показать, что данная SIG-запись подпадает под стандарт RFC 2931).
• Идентификатор алгоритма подписи (некоторые из них: MD5 – 1, DH – 2, DSA – 3, RSA-SHA-1 – 5).
• Количество компонентов в подписываемом FQDN – в нашем случае их 3 (“sig-host” + “atraining” + “ru”).
• TTL подписываемой записи – 1800 секунд.
• Время начала действия (01.01.2011, с 12:34:56) и окончания (01.01.2011, по 12:34:56).
• Идентификатор ключа (т.н. key tag) зоны. Идея в том, что для подписи зоны может использоваться несколько ключевых пар, тогда надо как-то понимать, какая использовалась для подписи этой записи. Т.е. вот представьте, что идёт плановая смена ключей. Зону подписывали ключом с идентификатором 12345, а теперь новый с 23456. А в кэше у одного из серверов лежит ответ сервера с SIG-записью. Её надо проверить. А как, если ключей несколько? Перебором всех? Тогда не очень понятно будет, когда не расшифруется корректно – это запись изменилась или ключ неудачный попался.
• Последнее поле – которое atraining.ru.. Это поле показывает название зоны, в которой надо искать ключ подписи – запись типа KEY с вышеуказаным идентификатором ключа. Данная пара значений однозначно указывает на нужную запись.
• Ну и сама подпись – результат работы закрытого ключа из ключевой пары над всеми полями записи SIG, исключая это. :)

Примечание: Несколько полей от оригинальной записи – и имя, и тип, и TTL нужны, т.к. локальном кэше клиента может храниться множество разных ответов, и ему надо точно понимать, что этот RRSIG подтверждает. Поэтому сравнение будет не только по имени, но и по типу и TTL. Замечу, что TTL у всех записей из “пачки”, которая имеет RRSIG, должен быть одинаковым

Откуда будут браться эти записи? Они будут создаваться в ходе процедуры подписывания зоны. Заметьте, процедура может проводиться не только DNS-сервером – в логике работы DNSSEC подписывающий и сервер разделены. Подписывающий может брать файл зоны, ключевую пару и создавать подписанные элементы, после чего отдавать результат DNS-серверу, который уже будет отвечать на запросы клиентов. Так как все записи RRSIG и прочие, про которые мы поговорим далее, уже будут созданы, наличие закрытого ключа зоны не является требованием для работы DNSSEC-сервера.

Терминология DNSSEC: Новый тип записи – NSEC

Давным-давно в DNS была запись-предтеча NSEC’а. Называлась она NXT и использовалась очень редко. Почему же? Давайте разберёмся.

Примечание: Как понятно, NSEC – это Nxt, только SECured.

Когда Вы запрашиваете у сервера разрешение имени – допустим, testhost.atraining.ru, то сервер может поступить двояко. В частности, может вернуть ответ, в котором будет содержаться информация о том, что Вы запрашивали (да и не только; вообще, сервер может вернуть в ответе и ту доп.информацию, которую сочтёт для Вас полезной), а может вернуть ответ, который будет показывать то, что записи, которую Вы хотите разрешить в адрес, нет. Тут начинается самое интересное. По идее, чтобы получить уведомление об отсутствии записи в зоне, как раз нужна запись вида NXT. Оригинальный механизм, предложеный в RFC 2065, выглядит так:

• Берём DNS-зону и представляем её в виде массива RR (resource record’ов).
• Сортируем эти записи, представляя их идентификаторы как строки беззнаковых октетов, считая прописные символы строчными (т.е. большие английские буквы – маленькими) (этот процесс ещё называется canonical ordering).
• Автоматически генерим записи вида NXT, которые будут содержать информацию “Какая запись идёт после записи X”. Для последней записи в зоне представляем, что зона “закольцована” и за последней записью идёт первая.

Когда мы всё это сделаем, то получится очень полезная штука – если клиент запросит разрешить некоторое имя, и мы его не найдём, мы вернём ему NXT-запись, которая закрывает “промежуток” между двумя записями, где должна была бы быть его запрашиваемая. Т.е. если в зоне есть записи aaa.atraining.ru, ccc.atraining.ru, ddd.atraining.ru, а клиент хочет bbb.atraining.ru, мы говорим – у нас есть точная информация, что такой записи нет, вот тебе NXT за aaa.atraining.ru, которая говорит, что после только ccc.atraining.ru. Если просит zzz.atraining.ru – вернём инфу, что после ddd.atraining.ru только aaa.atraining.ru.

Примечание: Данный стандарт и подход, как понятно, устарел и не используется по целой пачке причин. Например, так не получится поступить с не-ANSI именами хостов, потому что в Unicode для множества национальных алфавитов банально нет прописных и строчных символов.

Только вот это всё нудно и неинтересно показалось людям. И подавляющее большинство DNS-серверов (я не пишу “все”, хотя это, по сути, так и есть) сэкономят. Нафиг зону перебирать, сортировать, генерить записи, отвечать – можно ведь прислать пустой ответ. Мол, не нашёл ничего. Извини. Вот тебе ответ с нулём reply-записей.

И наконец-то теперь – суть проблемы.

Она в том, что пустой ответ нельзя подписать. Т.е. если зайдёт речь о кэшировании негативного ответа “нет такой записи”, то нельзя закэшировать безопасный ответ, потому что ответ пустой. Его, чтобы не “выпадать” из схемы DNSSEC, придётся тогда постоянно запрашивать.

Вот чтобы этого не было, NXT возродили в лице NSEC. Выглядит она как-то так:

aaa.atraining.ru. 14400 IN NSEC ccc.atraining.ru. (A RRSIG TXT NSEC DNSKEY)

Такая запись говорит, что после сортировки вида canonical ordering между хостами aaa и ccc ничего нет. Её уже можно закэшить, и она содержит чёткую информацию об отсутствии записи, а не умолчание, которое предположительно обозначает отсутствие оной. Более того, у NSEC есть дополнительный плюс. Допустим, у Вас отправляется запрос на получение A-записи для хоста ipv6.atraining.ru. А у этого хоста есть только AAAA-запись. Ну вот решили так – мол, будет только новая и технологичная. Что сделает обычный DNS-сервер, без DNSSEC? Он опять пришлёт пустой ответ – извини, не нашёл ничего. А сервер с DNSSEC пришлёт ответ, как на примере выше, и запрашивающий хост сможет подчерпнуть очень ценную информацию о том, что именно его типа записи нет. Вроде мелочь, но вдумайтесь и увидите, что это крайне полезная штука. Одно дело – молчание со стороны сервера, другое – подписанный ответ, по которому можно четко понять, что причина отказа – отсутствие запрашиваемого типа записи и наличие другого.

Терминология DNSSEC: Новый тип записи – NSEC3

Если Вы поняли, зачем нужна NXT, и почему появилась NSEC, то готовы к тому, чтобы понять, что механизм возврата записей NSEC небезопасен.

Причина проста – NSEC, добавляя безопасности в ряде вопросов, даёт, по сути, возможность выгрузки зоны (т.н. атака zonewalk). Т.е. атакующий может запрашивать записи по алфавиту, получая указатель на следующую, добавляя к имени следующей букву и спрашивая далее, что, учитывая что зона закольцована, даст ему за конечное число попыток полное содержимое зоны, включая информацию об именах и типах записей в ней. Это негативно. Поэтому по стандарту RFC 5155 DNS-сервер, поддерживающий DNSSEC, может вместо NSEC вернуть более безопасную NSEC3. Чем же она безопаснее?

Отличий несколько:

• Вместо имени следующей записи возвращается значение хэша.
• Хэш считается не просто от имени записи, а от имени + опционально от добавленных случайных бит (“salt”), что эффективно предотвращает словарные атаки (всё ж имён узлов не так много разных, поэтому словарные атаки на хэш имени хоста были бы крайне эффективны).
• Хэш считается не один раз, а несколько, что увеличивает вычислительную сложность задачи по подбору.

В результате NSEC3 достаточно эффективно закрывает данную проблему безопасности (выгрузку зоны путём последовательных запросов). Атакующий просто не получит имя следующего хоста. Есть и негатив – NSEC3 вычислительно сложнее и имеет ряд ограничений криптографического характера.

Вообще, чтобы лучше представлялась картинка, вот пример – допустим, в HTTPS похожей ситуации просто нет. Там если запрашиваемая страница не найдена, Вам придёт 404й ответ, который тоже страница. И он находится внутри защищённой сессии, поэтому вопрос с его подлинностью не поднимается. Но промежуточные сервера закэшировать его не смогут, т.к. они видят не отдельный HTTP-ответ, а непрерывную защищённую сессию. В DNS ситуация иная – надо, чтобы можно было “придержать” в кэше конкретный ответ сервера X, что на конкретное время запроса в зоне Y нет записи Z. Защищается объект, а не сессия.

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

Откуда берутся записи NSEC/NSEC3? Их надо создавать руками? Нет.

Эти записи делаются со стороны того механизма, который подписывает зону. Алгоритм примерно таков:

• Вы зафиксировали состав DNS-зоны (т.е. запретили в ней обновления и добавили все нужные записи).
• Вы запускаете процесс подписывания зоны.
• Этот процесс выстраивает записи в нужном порядке и сразу же создаёт NSEC/NSEC3 записи (в зависимости от того, какой вариант Вы выберете). Это делается, чтобы снизить нагрузку – т.е. ту же NSEC3 генерить каждый раз нет смысла – понятно, что будет этих записей ровно столько, сколько всего записей в зоне, поэтому имеет смысл сделать их заранее, а потом выдавать нужную, поняв в какую “дырку” попадает клиентский запрос о несуществующей записи в зоне.

Понятное дело, что зона должна быть статической.

Примечание: Увы, в клиентском ПО от Microsoft – даже в распоследней на момент написания Windows 7 SP1 – записи NSEC3 не поддерживаются. Т.е. прислать их можно, но клиент их не обработает. Позиция Microsoft в этом плане проста – это должен делать ближайший к клиенту DNS-сервер, а до него клиент может безопасно ходить, например, по IPSec. Я лично считаю, что это плохая точка зрения, и надеюсь, что в Windows 8 это поправят.

Терминология DNSSEC: ZSK и KSK

ZSK = Zone Signing Key. Ключ, используемый для подписи зоны.

KSK = Key Signing Key. Ключ, используемый для подписи ключей, которыми подписана зона.

Для работы DNSSEC Вам нужна как минимум одна пара ZSK и одна пара KSK. Идея в том, что KSK подтверждает подлинность ZSK и служит относительно долго, а ZSK участвуют в штатной ротации ключей (операцию ещё называют key rollover), чем увеличивают степень защиты всего механизма. Заметим, что основная причина разделения этих ключей – разный lifetime (одни должны чаще подвергаться ротации) и разная защита на уровне хранения (т.е. ключи KSK можно и нужно хранить безопаснее, т.к. они реже требуются для выполнения операций). Математически эти ключевые пары не обязаны быть разными.

Терминология DNSSEC: Trust anchors (запись DNSKEY)

Под термином “Trust anchors” понимается комплект ключевой информации, который позволит всем, а не только авторитативным DNS-серверам за данную зону, проверять подлинность данных из данной зоны. То есть эти записи будут нужны всем промежуточным серверам, которые будут кэшировать ответы (те же NSEC/NSEC3 и RRSIG), чтобы ответы можно было проверять по всему пути их следования, и не распространять далее заведомо ложную (потерявшую целостность) информацию.

В реализации, которую мы рассматриваем (Windows Server 2008 R2), trust anchors создаются в момент подписывания зоны автоматически, в виде отдельного файла с именем вида keyset-FQDN_зоны. Эти файлы (а точнее, информацию из них) надо будет распространить на все сервера, которым нужно будет участвовать в процессе безопасного кэширования данных подписанной зоны. Эта операция, в случае подписи одиночной зоны, не связаной с глобальной DNSSEC-иерархией, будет проводиться вручную. В случае, если зона хранится в Active Directory, ситуация улучшится – достаточно будет добавить trust anchor для нужной зоны на один сервер и указать, что надо распространить этот trust anchor на весь лес.

Терминология DNSSEC : Записи DS

Пом

имо всех уже перечисленых выше плюсов, у DNSSEC есть ещё один – безопасное делегирование. Суть в том, что в родительской зоне есть запись, подтверждающая факт существования делегирования, и делающая это безопасно. Это как раз запись типа DS. Существуя в составе родительской зоны (у которой тоже проверяема целостность), она даёт возможность проверить DNSKEY. Как же будет устроена эта запись? Давайте разберёмся на примере пары записей.  dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz      fwJr1AYtsmx3TGkJaNXVbfi/      2pHm822aJ5iI9BMzNXxeYCmZ      DRD99WYwYqUSdjMmmAphXdvx      egXd/M5+X7OrzKBaMbCVdFLU      Uh6DhweJBjEVv5f2wwjM9Xzc      nOf+EPbtG9DMBmADjFDc2w/r      ljwvFw==      ) ; key id = 60485

 dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A      98631FAD1A292118 )

Верхняя запись будет в зоне example.com., запись типа DS – в .com. Поля будут обозначать:

• 86400 – TTL записи.
• 60485 – Идентификатор ключа, по которому будет определяться соответствие записей DNSKEY и DS.
• 5 – Идентификатор алгоритма подписи (5 – это RSA/SHA-1).
• 1 – Идентификатор алгоритма дайджеста (1 – это SHA-1).

Терминология DNSSEC : Записи DLV – “подстраховка”

DLV (это от DNSSEC Look-aside Validation) – расширение протокола DNSSEC. Задача его достаточно проста. DNSSEC требует, чтобы подлинность запроса была проверяема по всей цепочке – то есть, необходимо, чтобы при запросе можно было проверить и целостность запроса, и корректность подписи зоны, и корректность делегирования зоны (т.е. есть ли наша зона в родительской), а после – проверить целостность родительской и так до “точки”. По сути, то же самое, что в PKI, когда мы говорим про т.н. certificate chain – когда надо проверить каждый сертификат на целостность/содержимое/отзыв, а после – родительский и так до доверенного корневого.

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

В результате придуман выход. Он прост. Если система при проверке не находит запись в родительской зоне, то она не сразу говорит “Всё плохо”, а проверяет, не зарегистрирована ли специальная DNSSEC DLV-запись в служебном пространстве имён с FQDN = dlv.isc.org.

То есть, вот решил я подписать зону dnssec.atraining.net.. А в родительской зоне – atraining.net. – я по какой-то причине сделать DNSSEC-делегирование не могу. Благодаря механизму DLV в таком сценарии становится возможным реализация “полноценного” DNSSEC. Мне лишь надо зарегистрировать имя dnssec.atraining.net.dlv.isc.org., которое разрешалось бы в что-то вида:

dnssec.atraining.net.dlv.isc.org. TTL_записи IN DLV идентификатор_ключа код_алгоритма_проверки_целостности код_алгоритма_генерации_дайджеста (D5D722703D848E85D85E8A8442AF47512B385418)

Где идентификатор_ключа – это число, которое совпадает с key id у DNSKEY, коды алгоритмов – такие же, как у DNSKEY и RRSIG.

Благодаря этой схеме централизованного хранения “страховых” DLV-записей Вам не надо вручную скачивать и распространять по клиентам ключи DNSSEC-зон, которые не обладают DNSSEC-родителями. Хотя вот DNSKEY от dlv.isc.org. Вам всё ж скачать и поставить придётся. Я бы предложил сделать это на уровне всего домена Active Directory, т.е. добавить этот trust anchor централизованно – это сразу же откроет возможность использовать этот механизм у всех DNSSEC-enabled серверов. Скачать ключ можно по адресу https://ftp.isc.org/www/dlv/dlv.isc.org.key.

Примечание: Такие безопасные “одиночные зоны” иногда называются security isle. Регистрировать DLV за свою зону ранее можно было тут – http://www.isc.org/solutions/dlv – но сейчас механизм DLV уже в статусе deprecated.

Структура DLV, в общем-то, такая же, как у DS, что логично, поэтому детально мной здесь не расписывалась.

Начинаем развёртывать DNSSEC: генерация ключевых пар

Для начала Вам нужно создать ключевые пары – ZSK и KSK.

В случае с Windows Server 2008 R2 технически это будет делаться утилитой dnscmd.exe, а храниться результирующие ключевые пары будут в локальном хранилище сертификатов компьютера, в контейнере \MS-DNSSEC, в виде самоподписаных сертификатов. Я не углубляюсь в детали функционирования хранилища сертификатов, предполагая, что тема DNSSEC и так достаточно обширна, а про сертификаты можно и отдельно поговорить будет.

Генерация ZSK

Выполняем команду:

dnscmd.exe /OfflineSign /GenKey /Alg rsasha1 /Length длина /Zone имя_зоны /SSCert /FriendlyName AtrainingRuZSK /ValidFrom может_использоваться_начиная_с_этой_даты_и_времени /ValidTo и_по_эту_дату_и_время

(понятное дело, от администратора. причина проста – нам надо этой командой не только создать ключевую пару, что может сделать и не-админ, а ещё и, возможно, сделать новый контейнер в локальном хранилище сертификатов и записать туда новый сертификат. это уже требует нужный уровень полномочий.)

Разбираемся, что мы указываем в виде ключей (большинство, замечу, фиксированные).

• /OfflineSign и /GenKey– обязательный ключ, чтобы dnscmd понял, какую операцию будем делать (создание новой клювой пары).
• /Alg – используемый алгоритм. В реализации Windows Server 2008 R2 – только RSA+SHA-1, поэтому данный ключ, по сути, константа.
• /Length – длина ключа. Для ZSK можно выбрать 1024 или 2048 бит. Допустимый технически диапазон – от 512 до 4096. Длина ключа не сильно повлияет на загрузку промежуточных узлов, а лишь на время генерации ключевой пары.
• /Zone – имя подписываемой зоны. Имя – это FQDN. Он “с точкой”. Люди, пишущие FQDN без точки, должны прервать чтение статьи прямо сейчас и пойти удавиться.
• /SSCert – говорим, что результат генерации надо хранить в виде самоподписанного сертификата в дефолтном DNSSEC’овском контейнере.
• /FriendlyName – то, что поможет нам отличать получившийся сертификат от других. Ни на что с точки зрения функционала не влияет, просто description у сертификата.
• /ValidFrom и /ValidTo – Диапазон, в пределах которого ключ считается действительным для использования. Данная пара параметров является необязательной. Если всё ж решите задать – помните, что задаётся в формате ГГГГММДДЧЧММСС (год-месяц-день-час-минута-секунда). Если не указано, то все равно создаётся по следующей логике: время начала использования берётся текущее минус 1 час, время завершения использования – начало+5 лет.

Генерация KSK

Выполняем похожую команду:

dnscmd.exe /OfflineSign /GenKey /Alg rsasha1 /Flags KSK /Length длина /Zone имя_зоны /SSCert /FriendlyName AtrainingRuKSK /ValidFrom может_использоваться_начиная_с_этой_даты_и_времени /ValidTo и_по_эту_дату_и_время

Отличия – другая рекомендованная длина (от 2048 до 4096 бит), дополнительный ключ /Flags KSK, показывающий в битовом поле “назначения ключевой пары”, что это KSK, ну и другое FriendlyName, чтобы не запутаться, т.к. ZSK и KSK хранятся в одном контейнере.

Теперь сразу же делаем нелюбимую всеми администраторами (до первого прецедента с показательным расстрелом виновных) процедуру – резервное копирование.

Резервное копирование ключей DNSSEC

Вам необходимо открыть оснастку управления сертификатами, зайти в хранилище локального компьютера, найти там контейнер MS-DNSSEC и там, в /Certificates, найти по FriendlyName свежесозданные самоподписанные сертификаты. Их необходимо выгрузить вместе с закрытыми ключами, защитить надёжными паролями и хорошо спрятать.

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

Включаем DNSSEC: Операции с DNS-зонами

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

У нас будет два варианта, отличающихся друг от друга – подпись зоны, хранящейся в текстовом файле, и подпись зоны, хранящейся в Active Directory.

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

Не забудьте, что вне зависимости от метода хранения зоны, у DNSSEC-зоны не должны использоваться динамические обновления. Под это подпадают как динамические обновления с точки зрения хостов (добавление/обновление записей), так и результаты работы механизмов aging/scavenging. Их тоже надо выключить на DNSSEC-зонах.

Примечание: Вот сейчас надо зоны забэкапить, хуже не будет точно.

Приступим. Команда

dnscmd.exe /OfflineSign /SignZone /Input исходный_файл_зоны /Output результирующий_файл_зоны /Zone FQDN_зоны /SignKey /ValidFrom время_начала_действия_подписи /ValidTo время_окончания_действия_подписи /Cert /FriendlyName Имя KSK-сертификата /signkey /cert /friendlyname Имя ZSK-сертификата

сделает нам подписанную зону, плюс ещё 2 файла – dsset-FQDN_зоны и keyset-FQDN_зоны, где FQDN_зоны – тот же, который идёт в команде после ключа /Zone.

Порядок указания KSK- и ZSK-сертификатов не критичен; утилита по битовым флагам догадается, кто KSK.

Исходный файл зоны по умолчанию лежит в %WINDIR%\System32\DNS\.

Флаги /ValidFrom и /ValidTo, как обычно, опциональны.

Теперь наша зона готова. Можно удалить её неподписанную копию и загрузить подписанную (т.е. просто заменить файл). Сервер поймёт и теперь будет возвращать клиентам дополнительные типы записей (если клиенты намекнут ему до этого, что они умеют читать такие типы записей). Но если клиент – это другой DNS-сервер, то как же он будет проверять, правду ли ему прислали или нет? Чтобы он мог это делать, ему нужны криптографические ключи, которые помогут понять, целостна ли RRSIG/NSEC/NSEC3 или нет.

Распространяем trust anchor’ы нашей подписанной зоны

Эти ценные записи типа DNSKEY будут находиться в файле, который автоматически создался при предыдущем шаге (подписи зоны) и начинается с keyset-. Их необходимо добавить на другие сервера. Есть два способа – через графический интерфейс и через dnscmd.exe. Через графический интерфейс достаточно просто: зайдите в Properties у сервера, выберите вкладку Trust Anchors, нажмите Add... для добавления информации о новой “чужой” подписанной зоне, информацию из которой этот сервер должен научиться проверять, и введите два параметра – FQDN зоны и её открытый ключ (находится в файле путём открытия его Блокнотом). Так как речь о реализации в Windows Server 2008 R2, которая кроме RSA/SHA-1 других вариантов не знает, особо настраивать в New Trust Anchor, кроме вышеупомянутых двух полей, нечего.

Вариант с командной строкой подразумевает ввод команды:

dnscmd.exe /TrustAnchorAdd FQDN_зоны DNSKEY флаги_из_файла 3 5 открытый_ключ_из_файла

Флаги из файла – это то, число, которое после параметра DNSKEY в keyset-файле, открытый ключ – аналогично. Файл маленький, не перепутаете.

Включаем DNSSEC: Подготавливаем DNS-сервера

Этот шаг будет нам необходим, когда мы захотим защитить канал связи между серверами и клиентами. Вспомните, что DNSSEC не шифрует передаваемые данные, следовательно, сохраняются риски для конфиденциальности запросов и ответов. Плюс, в текущей реализации клиентских ОС Microsoft отсутствует ряд полноценного функционала DNSSEC (NSEC3-записи), что добавляет проблем. Предлагаемый вариант решения – IPSec – обычно связан с достаточно тщательной и не самой простой настройкой. Поэтому нам надо и заранее подготовиться к тому, чтобы DNS-клиенты могли безопасно подключаться к серверам, и сделать это максимально централизованно и просто. Хороший вариант решения – выдать всем DNSSEC-серверам специальные цифровые сертификаты, подтверждающие их (серверов) подлинность и целевое назначение. Это можно будет сделать централизовано, через групповые политики, и это ничему не помешает. Тогда для защиты подключений клиентов (притом уже полноценной, с шифрованием запросов/ответов), надо будет лишь включить данный функционал с клиентской стороны.

Т.е. мы разбиваем комплексную задачу “защита ‘последней мили’ – от DNS-сервера до клиента” на части, которые могут быть сделаны отдельно и не помешают другим задачам.

Для начала создайте в домене группу с названием, например, DNSSEC Servers. В эту группу мы будем добавлять учётные записи DNS-серверов, на которых будет развёрнут DNSSEC. Это будет удобным способом ограничить запрос специального DNSSEC-сертификата только нужными серверами.

Теперь откройте редактор шаблонов сертификатов, хранящихся в лесу Active Directory и сделайте следующее:

• Возьмите шаблон с названием RAS and IAS Server и сделайте его копию (Вам предложат выбор типа шаблона – V2 (2003 Enterprise) или V3 (2008 Enterprise), выберите V2). Это сократит объём работы. Назвать шаблон можно как-то наглядно – DNSSEC Server, например.
• Откройте сертификат и убедитесь, что в нём стоит опция Publish certificate in Active Directory (на вкладке General). Также у сертификата должен быть разрешен экспорт закрытого ключа (это называется Allow private key to be exported).
• Теперь надо будет добавить нужные применения сертификата. Это делается во вкладке Extensions. Необходимо, чтобы у нашего шаблона были следующие применения:
  • Client Authentication
  • Domain Name System (DNS) Server Trust
  • IP security IKE intermediate
  • Server Authentication
  Если не нашли Domain Name System (DNS) Server Trust, то сделайте New Application Policy с нужным именем (Domain Name System (DNS) Server Trust) и OID = 1.3.6.1.4.1.311.64.1.1.
• Теперь про назначение ключа. В Key Usage у нашего сертификата должно быть следующее – в плане подписи Digital signature and Signature is proof or origin (nonrepudiation), а в плане шифрования – Allow key exchange only with key encryption (key encipherment), Allow encryption of user data и пункт, делающий поддержку этих назначений обязательным – Make this extension critical. То есть данный шаблон будет создавать сертификаты, которые будут подтверждать целостность и аутентичность, а ключевая информация сможет использоваться как для шифрования других ключей в ходе обмена ключами, так и для защиты передаваемых данных. Заметьте, что архивировать этот тип сертификатов не получится.
• Теперь зайдите на вкладку Security и поменяйте группу тех, кому можно получать сертификат, на созданную в начале операции DNSSEC Servers. В плане разрешений Вы должны указать права Enroll и Autoenroll.

Шаблон создан. Осталось выбрать CA, которые будут иметь право его выдавать, и добавить его на них, а после – зайти в групповую политику и поставить автоматический запрос сертификата. Если забыли, где это – это примерно в Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Public Key Policies -> 'Certificate Services Client – Auto-Enrollment'. Поставьте автоматический запрос, обновление и удаление отозваных сертификатов.

В общем-то, это всё – теперь Вам будет достаточно добавить учётную запись сервера, на котором развёрнут DNS-сервер, в группу DNSSEC Servers, и он сам впрок запросит для себя сертификат, который сделает после возможным защиту подключения к нему со стороны клиента.

DNSSEC: Настройки со стороны клиентов (NRPT)

Вынес в отдельную статью про настройку NRPT.

А дальше?

А дальше – во второй части статьи. Там мы уже поговорим про IPSec и делегирование дочерних зон. А то сразу слишком много получится.