Настройка windows server 2018 dns. перенос зон dns

Ключевые характеристики DNS

DNS обладает следующими характеристиками:

Распределённость администрирования. Ответственность за разные части иерархической структуры несут разные люди или организации.
Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности и (возможно) адреса корневых DNS-серверов.
Кеширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.

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

DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы содержится в RFC 882 и RFC 883. В публикация RFC 1034 и RFC 1035 изменила спецификацию DNS и отменила RFC 882, RFC 883 и RFC 973 как устаревшие.

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

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

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

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

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

Возьмите шаблон с названием и сделайте его копию (Вам предложат выбор типа шаблона – V2 (2003 Enterprise) или V3 (2008 Enterprise), выберите V2). Это сократит объём работы. Назвать шаблон можно как-то наглядно – , например.
Откройте сертификат и убедитесь, что в нём стоит опция (на вкладке General). Также у сертификата должен быть разрешен экспорт закрытого ключа (это называется ).
Теперь надо будет добавить нужные применения сертификата. Это делается во вкладке . Необходимо, чтобы у нашего шаблона были следующие применения:
- Client Authentication
- Domain Name System (DNS) Server Trust
- IP security IKE intermediate
- Server Authentication
Если не нашли , то сделайте с нужным именем () и OID = .
Теперь про назначение ключа. В у нашего сертификата должно быть следующее – в плане подписи , а в плане шифрования – , и пункт, делающий поддержку этих назначений обязательным – . То есть данный шаблон будет создавать сертификаты, которые будут подтверждать целостность и аутентичность, а ключевая информация сможет использоваться как для шифрования других ключей в ходе обмена ключами, так и для защиты передаваемых данных. Заметьте, что архивировать этот тип сертификатов не получится.
Теперь зайдите на вкладку и поменяйте группу тех, кому можно получать сертификат, на созданную в начале операции . В плане разрешений Вы должны указать права и .

Шаблон создан. Осталось выбрать CA, которые будут иметь право его выдавать, и добавить его на них, а после – зайти в групповую политику и поставить автоматический запрос сертификата. Если забыли, где это – это примерно в . Поставьте автоматический запрос, обновление и удаление отозваных сертификатов.

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

Как отключить кэширование на стороне клиента

Чтобы отключить кэширование DNS, выполните одну из следующих команд:

чтобы полностью отключить кэш DNS в Windows, используйте средство контроллера служб или средство «службы», чтобы задать для параметра «тип запуска службы DNS-клиента значение» отключено»

обратите внимание, что имя Windows службы DNS-клиента также может отображаться как «днскаче»

Примечание

Если кэш сопоставителя DNS деактивируется, Общая производительность клиентского компьютера снижается, а сетевой трафик для запросов DNS увеличивается.

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

когда сопоставитель Windows получает ответ (положительный или отрицательный) на запрос, он добавляет этот ответ в свой кэш и тем самым создает запись ресурса DNS. Сопоставитель всегда проверяет кэш перед запросом DNS-сервера. Если запись ресурса DNS находится в кэше, сопоставитель использует запись из кэша вместо запроса к серверу. Такое поведение ускоряет запросы и уменьшает сетевой трафик для запросов DNS.

Для просмотра и очистки кэша сопоставителя DNS можно использовать средство ipconfig. Чтобы просмотреть кэш сопоставителя DNS, выполните в командной строке следующую команду:

Эта команда отображает содержимое кэша сопоставителя DNS, включая записи ресурсов DNS, предварительно загруженные из файла Hosts, и все недавно запрошенные имена, разрешенные системой. Через некоторое время сопоставитель отклоняет запись из кэша. Период времени указывается значением срока жизни (TTL) , связанным с записью ресурса DNS. Кэш также можно очистить вручную. После очистки кэша компьютер должен снова запрашивать DNS-серверы для любых записей ресурсов DNS, которые ранее были разрешены компьютером. Чтобы удалить записи в кэше сопоставителя DNS, выполните команду из командной строки.

Симптомы

Компьютер под управлением Microsoft Windows 2000 Server или Microsoft Windows Server 2003 может вызывать проблемы с подключением, если сервер настроен следующим образом:

Служба маршрутизации и удаленного доступа настроена для разрешения входящих подключений.
Служба доменных имен (DNS) или windows Internet Name Server (WINS) устанавливается и настраивается на сервере, на котором выполняется маршрутизация и удаленный доступ.

После подключения удаленного компьютера к серверу маршрутизации и удаленного доступа с помощью коммутируемого или VPN-подключения может возникать один или несколько из следующих симптомов:

Если на сервере маршрутизации и удаленного доступа также запущен сервер Microsoft Internet Security and Acceleration (ISA) Server 2000, вы не сможете просматривать Интернет с клиентских компьютеров в локальной сети независимо от того, настроены ли компьютеры для использования веб-прокси или клиент межсетевого экрана (Майкрософт). Например, в веб-браузере может появиться сообщение об ошибке «Не удается найти сервер или DNS».
Если сервер маршрутизации и удаленного доступа работает под управлением ISA Server 2000, а пользователь на клиентском компьютере выбирает «Обновить сейчас» в диалоговом окне «Параметры клиента брандмауэра», пользователь получает следующее сообщение об ошибке:
При попытке проверить связь с сервером маршрутизации и удаленного доступа с локального компьютера с помощью netBIOS-имени сервера или полного доменного имени (FQDN) компьютер пытается проверить связь с неправильным IP-адресом.
Если сервер маршрутизации и удаленного доступа является главным браузером для сети, вы не сможете просмотреть список компьютеров в сетевом окружении или в разделе «Мои сетевые расположения».
Невозможно подключиться к http:// server_name/myconsole
сайт на компьютере Small Business Server 2000.
На сервере маршрутизации и удаленного доступа вы получаете сообщение о событии, похожее на следующее:
При попытке открыть общие папки или сопоставить сетевые диски с сервером маршрутизации и удаленного доступа вы получите сообщения об ошибках.
Если сервер маршрутизации и удаленного доступа также является контроллером домена, при попытке входа в сеть вы получаете сообщения об ошибках.
Если сервер маршрутизации и удаленного доступа является контроллером домена, при попытке открыть общие файловые ресурсы или сопоставить сетевые диски с любым общим ресурсом в сети вы получите сообщения об ошибках. Например, компьютеры под управлением Microsoft Windows 2000 Профессиональный или Microsoft Windows XP Professional получают сообщение об ошибке, похожее на следующее:

Эта проблема обычно затрагивает компьютеры под управлением Small Business Server, так как эта версия Windows Server часто является единственным сервером в сети. Однако эта проблема может повлиять на любой сервер под управлением Windows 2000 или любой сервер маршрутизации и удаленного доступа windows Server 2003, на котором запущена служба DNS или WINS.

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

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

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

ZSK (Zone Signing Key) — ключ для подписи ресурсных записей зоны;
KSK (Key Signing Key) — ключ для подписи ключей.

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

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

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

Публикация DS-записей нового KSK-ключа в родительской зоне. В ISPmanager следующий KSK-ключ создаётся сразу при подписании домена или сразу после удаления старого KSK-ключа. В таком случае у пользователя появляется возможность заранее опубликовать DS-записи нового ключа. Для корректной работы обновления KSK-ключа DS-записи нового ключа нужно опубликовать в родительской зоне за месяц до конца обновления KSK-ключа.
Замена KSK-ключа. Активный действующий KSK-ключ заменяется новым KSK-ключом. В ISPmanager замена происходит за 2 недели до конца обновления KSK-ключа.
Удаление DS-записей старого ключа в родительской зоне. В этот момент ISPmanager генерирует следующий новый ключ, позволяя пользователям одновременно выполнить необходимые действия в родительской зоне: удалить DS-записи старого ключа и добавить DS-записи следующего нового ключа.

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

Создание и публикация в доменной зоне нового ключа ZSK-ключа. В ISPmanager выполняется за 2 недели до смены ключа. Новый ключ является пассивным и не участвует в процессе подписывания доменной зоны.
Замена ZSK-ключа. Опубликованный заранее новый ZSK-ключ становится активным. Действующий до этого ZSK-ключ становится пассивным и больше не участвует в процессе подписи.
Удаление старого пассивного ZSK-ключа. Действие выполняется через 2 недели после замены ZSK-ключа.

Обратите внимание!

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

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

Обратите внимание!

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

Зачем нужна технология DNS и как она работает

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

Работу DNS-технологии в качестве этой самой «телефонной книги» обеспечивает DNS-сервер— оборудование или программное обеспечение, с помощью которого предоставляется доступ к системе доменных имен, хранятся данные о соответствии конкретного IP-адреса соответствующему домену, а также осуществляется кэширование информации в виде IP-адреса и соответствующего ему домена других DNS-серверов.

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

Ниже список самых популярных и общедоступных DNS-серверов (актуально на октябрь 2021):

Google: 8.8. 8.8 & 8.8. 4.4.
Quad9: 9.9. 9.9 & 149.112. 112.112.
OpenDNS: 208.67. 222.222 & 208.67. 220.220.
Cloudflare: 1.1. 1.1 & 1.0. 0.1.
CleanBrowsing: 185.228. 168.9 & 185.228. 169.9.
Alternate DNS: 76.76. 19.19 & 76.223. 122.150.
AdGuard DNS: 94.140. 14.14 & 94.140.

Схема работы DNS-технологии

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

Принцип работы DNS-технологии

Затем браузер делает запрос на сервер по этому IP-адресу и после получения ответа отображает страницу ресурса.

Выделим основные характеристики DNS-технологии:

Хранение и управление данными распределенного характера. То есть отдельный DNS-сервер хранит только информацию по делегированным ему доменам.
Кэширование данных.При помощи кэширования ускоряется загрузка нужной информации с сервера. Ведь при обращении к любому ресурсу (даже при запросе внутренних страниц) серверы проверяют связь домена и IP-адреса. Но если запрашиваемый ресурс расположен, допустим, в другой точке мира, то скорость его загрузки может быть довольно медленной. Например, пользователь регулярно делает запросы на ресурс, который находится в другом государстве. Расположенный ближе всего к пользователю DNS-сервер кэширует данные о ресурсе и при следующим запросе выдает их клиенту максимально быстро. Источником кэширования, из которого поступают данные о сайте, являются первичные и вторичные DNS-серверы.
Для уменьшения уровня нагрузки DNS-сервер может хранить некоторое время определенное количество информации о других, не делегированных ему доменах.
Резервирование. Несколько изолированных логически и физически DNS-серверов хранят и обрабатывают информацию об одних и тех же узлах. Благодаря такому подходу обеспечивается доступность информации даже при сбое одного или нескольких серверов.
Иерархическая структура. База доменных имен организована по принципу иерархии: корневой домен расположен на верхнем уровне, к которому примыкают домены первого уровня, к ним присоединяются домены второго уровня и т.д.

Как работают DNS-серверы:

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

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

Причина

Когда удаленный компьютер подключается к серверу маршрутизации и удаленного доступа с помощью подключения с помощью набора или VPN-подключения, сервер создает адаптер протокола «точка — точка» (PPP) для взаимодействия с удаленным компьютером. Затем сервер может зарегистрировать IP-адрес этого адаптера PPP в DNS или базе данных WINS.

Когда сервер маршрутизации и удаленного доступа регистрирует IP-адрес своего адаптера PPP в DNS или WINS, при попытке подключения к серверу на локальных компьютерах могут возникнуть ошибки. Вы получите эти ошибки, так как DNS-серверы или WINS-серверы могут возвращать IP-адрес адаптера PPP компьютерам, которые запрашивают DNS или WINS для IP-адреса сервера. Затем компьютеры пытаются подключиться к IP-адресу адаптера PPP. Так как локальные компьютеры не могут подключиться к адаптеру PPP, подключения завершались сбоем.

Зачем нужна технология DNSSEC

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

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

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

Основные компоненты DNSSEC определены в следующих RFC:

RFC 4033
RFC 4034
RFC 4035

DoH — DNS поверх HTTPS

DNS-over-HTTPS (DNS поверх HTTPS, DoH)— это экспериментальный протокол, продвигаемый совместно Mozilla и Google. Его цели схожи с протоколом DoT — усиление конфиденциальности людей в интернете путем шифрования запросов и ответов DNS.

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

DoH использует другой подход и передает зашифрованные запросы на преобразование имен сетевых узлов через HTTPS-соединения, которые по сети выглядят как любой другой веб-запрос.

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

DNS-фильтрация — это распространенный способ фильтрации веб-трафика для защиты пользователей от фишинговых атак, сайтов, распространяющих вредоносные программы, или другой потенциально опасной интернет-активности в корпоративной сети. Протокол DoH обходит эти фильтры, потенциально подвергая пользователей и сеть более высокому риску.
В текущей модели преобразования имен каждое устройство в сети в той или иной степени получает DNS-запросы из одного и того же места (из указанного DNS-сервера). DoH и, в частности, его реализация от Firefox показывают, что в будущем это может измениться. Каждое приложение на компьютере может получать данные из разных источников DNS, что значительно усложняет поиск и устранение проблем, обеспечение безопасности и моделирование рисков.

В чем разница между DNS поверх TLS и DNS поверх HTTPS?

Начнем с DNS поверх TLS (DoT)

Основное внимание здесь уделяется тому, что оригинальный протокол DNS не изменяется, а просто безопасно передается по защищенному каналу. DoH же помещает DNS в формат HTTP перед выполнением запросов

Настройка клиентов WIndows на использование DNSSEC

Чтобы заставить клиентов Windows выполнять только «безопасные» запросы (DNSSEC), то есть принимать данные DNS только в том случае, если их цифровая подпись верна, вы должны использовать GPO для использования политики NRPT (Таблица разрешения имен политик).

Для этого в разделе «Конфигурация компьютера объекта групповой политики» -> «Политики» -> «Параметры Windows» -> «Политика разрешения имен» на вкладке «DNSSEC» включите следующие параметры:

Включите DNSSEC в этом правиле
Требовать от DNS-клиентов проверки того, что имя и адресные данные были проверены DNS-сервером

Осталось назначить политику необходимому организационному подразделению. После применения политики убедитесь, что клиент настроен на использование безопасного DNS:

Get-DnsClientNrptPolicy

DNSSecValidationRequired = True, что означает, что клиент требует обязательной проверки ответов DNS.

Если ответ, полученный от DNS-сервера, не подписан или подписан неверными сертификатами, команда вернет ошибку незащищенного пакета DNS.

Modifying Zone Records

Each time you edit the zone by adding or removing records, it has to be signed to make it work. So we will create a script for this so that we don’t have to type long commands every time.

Save the file and make it executable.

Whenever you want to add or remove records, edit the and NOT the file. This file also takes care of incrementing the serial value, so you needn’t do it each time you edit the file. After editing it run the script by passing the domain name and zone filename as parameters.

You do not have to do anything on the slave nameserver as the incremented serial will ensure the zone if transferred and updated.

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

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

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

Генерация ZSK

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

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

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

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

Генерация KSK

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

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

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

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

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

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