Глава 4. Active Directory DNS

Содержание

Глава 4. Active Directory DNS
Что такое DNS?
Иерархические структуры именования
Диспетчеры TLD (Top-Level Domain)
Как работает DNS
Проектирование инфраструктуры DNS
Интегрирование DNS с уже имеющейся инфраструктурой DNS
Расчленение пространства имён
Развёртывание новой инфраструктуры DNS, интегрированной с AD
Основы DNS
Записи DNS
Запуск записи авторизации
Записи A и AAAA
Записи NS
Записи обмена почтовыми сообщениями
Записи канонических имён
Записи указателя
Записи SRV
Зоны
Первичная зона
Вторичная зона
Зоны заглушек
Зоны обратного просмотра
Условные ретрансляторы
Политики DNS
Безопасный клиент DNS поверх HTTPS (DoH)
Режимы работы сервера DNS
Передача зон
Делегирование DNS
Поставщики службы DNS
Выводы

Мы не можем обсуждать AD DS (Active Directory Domain Services) без упоминания DNS (Domain Name System). Начиная с Windows Server 2003, DNS стал первичной службой разрешения имён. До этого Windows применял для разрешения имён NetBIOS и WINS (Windows Internet Name Service).

И WINS, и DNS, обе, являются сетевыми службами TCP/IP разрешения имён. Существуют наследуемые системы, которые всё ещё применяют WINS вместо DNS.

DNS помогает определять местоположение ресурсов через внутреннюю и внешнюю сетевую среду. DNS способен запускаться как некая независимая роль сервера во внешней сетевой среде, сети периметра или общедоступной сети. Существуют отличные от Microsoft разнообразные производители, которые предоставляют решения DNS; Хорошим примером этого является Linux/ Unix BIND (Berkeley Internet Name Domain). В целом имеются две категории инфраструктуры DNS. Одной категорией выступают организации, которые размещают свои собственные серверы DNS для обеспечения требований разрешения имён в своих корпоративных инфраструктурах. Другой категорией являются категории, которые продают DNS в качестве службы, такие как Azure DNS, DynDNS (Dynamic DNS) и Amazon Route 53.

В этой главе мы в целом сосредоточимся на понимании того как в нашей инфраструктуре работает интегрированный с AD DNS. На протяжении данной главы мы изучим такие вопросы:

  • Что такое DNS?

  • Структуры иерархического именования

  • Проектирование инфраструктуры DNS

  • Существенные моменты DNS

  • Условные ретрансляторы

  • Политики DNS

  • Режимы операций сервера DNS

  • Транспорт зон

  • Делегирование DNS

  • Поставщики службы DNS

Если вы работаете с AD, вы уже можете обладать основной идеей о том как в некой среде AD работает DNS. Прежде чем мы окунёмся в углублённые вопросы DNS, давайте двинемся далее и вначале освежим свои знания об основах DNS.

Что такое DNS?

В мобильных телефонах у нас имеются телефонные книги. Когда нам требуется сохранить чей- то телефонный номер, как мы это делаем? Просто ли мы вводим для его сохранения? Нет. Мы сохраняем этот номер с именем некой персоны или как- то ещё чтобы запомнить, а потому, в следующий раз, когда мы открываем свой список контактов, мы запросто отыскиваем его. То же самое применимо и к тому, когда вы имеете дело с адресами IP. Я помню несколько наиболее часто используемых IP адресов в своей инфраструктуре клиентов, но я не помню большинство прочих. Большинство серверов я запоминаю по их именам хостов вместо того чтобы помнить их IP адреса. Это происходит по той причине, что имена хостов более дружественны для пользователя, чем их IP адреса. И именно этим и занята DNS: она устанавливает соответствие IP адресов именам домена или распространённым терминам, которые более дружественны пользователю.

Как я уже утверждал, невозможно обсуждать какую бы то ни было работу инфраструктуры домена AD без DNS. Имеются две основные причины зачем требуется DNS в AD DS:

  • Сопровождение иерархической инфраструктуры проекта: В своих предыдущих главах я рассуждал о проектировании инфраструктуры AD. Я упоминал реализацию множества Лесов, доменов и дочерних доменов. Мы используем пространства имён домена для отделения их друг от друга и выстраивания требуемой иерархии AD. Единственным способом, которым вы способны отражать свою логическую инфраструктуру является применение DNS.

  • Определение местоположения контроллеров домена: Устройствам в инфраструктуре для аутентификации требуется взаимодействовать с Контроллерами домена AD. Когда это не удалённая площадка, для выполнения аутентификации требуется определение ближайшего к нему Контроллера домена. Этот процесс выполняется с применением записей DNS service (SRV). Кроме того, когда некому приложению или службе требуется определить местоположение какого- либо хоста или ресурса, с его разрешением приходит на помощь DNS.

До применения DNS системы использовали LMHOSTS (LAN Manager Hosts) и файлы хостов для установки соответствия IP адресов дружественным именам. В небольших сетевых средах это всё ещё применяется. Файл LMHOSTS помогает в поиске имён NetBIOS в сетевых средах TCP/IP. Файлы с именами хостов помогают при поиске доменах имён в сетях TCP/IP. Они также применяются для перекрытия соответствующих записей DNS, так как при разрешении имён такой файл hosts всё ещё обладает приоритетом.

Файлы LMHOSTS и hosts располагаются в C:\Windows\System32\drivers\etc:

 

Рисунок 4-1


Пример файла hosts

[Замечание]Замечание

DNS был предназначен для поддержки взаимодействия при помощи электронных писем в ARPANET (Advanced Research Projects Agency Network). Позднее люди применяли файлы LMHOSTS и hosts, и, по мере роста сетевых сред, становилось не практичным поддерживать большие файлы хостов. Самое первое соглашение для запуска лучшей, централизованной системы разрешения имён стартовала в декабре 1973 в RFC 606. Потребовалось почти десятилетие с различными RFC чтобы принять решение по технологии, приведшей к современному DNS, и в ноябре 1983 были выпущены окончательные RFC (RFC 881, 882, 883).

DNS поддерживает некую базу данных, которая содержит разнообразные типы данных DNS (A, MX, SRV и AAAA). Эта база данных может распределяться по множеству серверов. Если это требуется, когда мы не можем обеспечивать безопасность инфраструктуры, мы также можем сопровождать доступную только на чтение такую базу данных.

[Замечание]Замечание

В Windows Server данные DNS хранятся в C:\Windows\System32\dns. Здесь содержатся файлы зон DNS и файлы настройки Root Hints cache.dns.

Иерархические структуры именования

В Главе 1, Основы Active Directory мы рассматривали деревья доменов и изучали как они могут применяться для организации общей структуры домена соответствующим методом иерархии. DNS позволяет вам транслировать эту логическую структуру в имеющееся пространство имён домена. Аналогично некому дереву, она начинается со своего корня и расширяется на различные уровни, такие как филиалы и листья. В соответствующем дереве домена общий корень представляется точкой (.). Некое обычное дерево филиалов содержит множество уровней. В таком дереве домена филиал представляет собой какой- то набор именованных ресурсов, а некий лист (leaf) в филиале представляет отдельную именованную запись. В дереве филиалы и листья зависят друг от друга. Филиалы и листья являются частью одной системы пока все объединено. Когда мы описываем некий лист или филиал, мы поясняем его во взаимодействии с общим деревом. Например, когда нам требуется отобразить какой- то лист на яблоне, я буду называть его листом яблони. После этого мой оппонент понимает, что это часть дерева яблони.

В нашей следующей схеме Уровень 1 представляет TLD (Top-Level Domains), Домены верхнего уровня). Они управляются компетенцией регистрации имён в Интернете согласно международным стандартам:

 

Рисунок 4-2


Иерархия именования домена

Диспетчеры TLD (Top-Level Domain)

Административную ответственность за TLD несёт IANA (Internet Assigned Numbers Authority). TLD разбивается на категории двух различных классов с названиями country-code TLD (ccTLDs, TLD кодов стран) и generic TLDs (generic, обобщённые TLD). Административная ответственность ccTLDs делегируется диспетчерам отдельных стран. Управляющие TLD несут ответственность за делегированный им домен и обязаны служить всему сообществу. Диспетчеры TLD предоставляют общественную услугу от имени глобального интернет- сообщества. Список имеющихся в настоящее время диспетчеров доступен на https://bit.ly/3raaQaK. Кроме того, дополнительные сведения относительно структуры DNS, делегирования и диспетчеров TLD Интернета доступны в https://go.icann.org/3FJVCxv.

Приводимая ниже таблица описывает наиболее часто встречающиеся TLD:

Таблица 4-1. Наиболее распространённые TLD
TLD имя Описание

.com

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

.org

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

.net

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

.edu

Это ограниченная регистрация для обучающих институтов.

.gov

Ограничен записями государственных органов.

.ca, .co.uk

Применяются для представления стран. Регистрация под ними в домене зависит от правил и соглашений регулирования их представителями полномочий регистрации имён доменов в соответствующей стране.
[Замечание]Замечание

Полный перечень TLD можно просмотреть по ссылке.

Уровень 2 в этой иерархии контролируется самой организацией. В моём примере мне требуются для своих организаций два доменных имени с названиями rebeladmin.com и rebeladmin.net. Я могу обратиться к регистратору доменных имён и зарегистрировать необходимые имена (например, в GoDaddy или Dotster).

После того как я зарегистрировал их, никто больше не обладает тем же самым именем без авторизации на это с моей стороны, пока не истекает срок пользования этим именем. В качестве владельца этого домена, я могу создавать некие подчинённые домены (дочерние домены) в rebeladmin.com и rebeladmin.net. В DNS также имеются некие записи, которые требуется публиковать в самом Интернете. Например, когда мне требуется размещать в своём домене некий вебсайт, к которому люди смогут получать доступ через Интернет, мне потребуется установить соответствие IP адреса моего веб сервера с записью DNS www.rebeladmin.com.

Для этого мне требуется некий обладающий на то полномочиями сервер (authoritative server). Такой сервер DNS будет содержать копию всех относящихся к https://bit.ly/3nI6pSF. Когда другой сервер DNS (рекурсивный сервер DNS) выполняет запрос записи DNS, относящейся к https://bit.ly/3cG0JCi, этот уполномоченный сервер будет способен ответить. Уполномоченные серверы (authoritative servers), к тому же, требуют высокой доступности. Когда вы регистрируете своё доменное имя, регистратор этого домена будет применять по умолчанию в качестве таких облачённых надлежащим правом свои собственные серверы DNS. Но если нам это потребуется, мы можем иметь свои собственные серверы DNS, и указывать на них при помощи записей NS (nameserver).

На Уровне 3 владельцы домена имеют все права на создание любого подуровня пространства имён DNS. В моём примере ими являются blog.rebeladmin.com forum.rebeladmin.net. Каждая точка (.) представляет очередной уровень в общем дереве домена:

 

Рисунок 4-3


Пример имени домена

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

Когда вы являетесь владельцем доменного имени, вы можете применять одно и то же имя для представления имени домена своего AD, однако имеется ряд моментов, которые вам требуется учитывать:

  • Ручная настройка записей DNS для установки соответствия общедоступным записям DNS: В качестве примера я собираюсь воспользоваться в качестве своего доменного имени AD rebeladmin.com. Для установки общедоступных записей DNS я воспользовался, и я указываю его для общедоступного IP адреса 38.117.80.2. Для сопровождения локальной инфраструктуры записей я также применяю интегрированные с AD серверы DNS. Но когда я собираюсь получить доступ в своему вебсайту www.rebeladmin.com с некого ПК в домене, для начала мне требуется убедиться что он не пытается разрешать это имя при помощи некого локального сервера DNS. Когда некая запись DNS требует своего разрешения во внешних IP адресах, нам требуется создавать соответствующие записи вручную в неком локальном сервере DNS.

  • Изменение записей DNS для использования самого нижнего пути маршрутизации: В моём предыдущем примере общедоступным адресом моего веб сервера выступает 38.117.80.2. К этому веб серверу также можно получить доступ через его локальный адрес, 192.168.0.100. Когда я запускаю отслеживание маршрута до www.rebeladmin.com с записью DNS 38.117.80.2, это требует около 10 сетевых прыжков (hop) для достижения данного веб сервера. Но когда я применяю локальный IP адрес 192.168.0.100, он разрешается одним сетевым прыжком. Таким образом, когда ваше доменное имя имеет общедоступную и частную записи DNS, убедитесь что вы отрегулировали её чтобы помогать пользователям применять кратчайший маршрут пути для улучшения производительности и доступности.

[Совет]Совет

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

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

Несколько дней назад я отправил карточку поздравления с днём рождения своей маме, которая живёт на Шри Ланке. Я отправил её по почте из локального почтового офиса в Кингстон на Темзе, Англия. Как только я поместил её в почтовый ящик, стартовал процесс доставки, причём теперь именно почтовая служба отвечает за её доставку правильному получателю. Итак, когда работник почтового офиса, который подхватил моё письмо, знает ли он точное местоположение дома моих родителей? Нет, не знает. Однако в самом конце моего адреса названа страна, которой является Шри Ланка. Так они узнают что когда письмо следует на Шри Ланку, тогда эта почтовая служба будет способна доставить его. Поэтому следующей остановкой моего письма была Шри Ланка. После того как эта карточка достигает главного сортировочного офиса на Шри Ланке, знает ли берущий в свои руки карточку работник точное местоположение? Может быть и нет, но когда он его не знает, он может посмотреть название города для доставки. Затем почтовый офис в этом городе уже знает что делать. Когда моя почтовая карточка достигает сортировочного подразделения в этом городе, работники знают в какое именно почтовое отделение её следует доставить.

Достигнув требуемого почтового отделения в городе моих родителей, разносчик почты там несомненно знает где располагается дом в котором живут мои родители и это письмо доставлено. Как это получилось? Даже когда они не знали конечного местоположения доставки, они знают кого- то, кто выясняется на очередном этапе. Именно так разрешает адреса DNS. Имеющийся в вашей инфраструктуре сервер DNS. Сервер DNS в вашей инфраструктуре не осведомлён о миллиардах вебсайтов в Интернете их IP адреса. Когда вы набираете некое доменное имя и нажимаете Enter, ваш сервер DNS попробует его разрешить, но если он не знает, он поработает с прочими серверами DNS, которые могут знать о нём и отработают с ними поиск правильного места назначения.

В нашем следующем примере мой друг Вильям пытается получить доступ к нашему вебсайту www.rebeladmin.com со своего ноутбука. Это устройство является подключённым к домену и этот пользователь зарегистрировался в данном устройстве с применением имени пользователя и пароля домена.

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

Некий запрос DNS может выполняться между клиентом DNS и его сервером DNS или между серверами DNS.

Существует два типа запросов DNS:

  • Рекурсивные: Рекурсивный запрос обычно отправляется клиентами DNS. После выработки такого запроса, он ожидает отклика успеха или отказа от своего сервера DNS. Именно сервер DNS отвечает за работу с прочими серверами DNS для предоставления ответа когда он не способен обработать этот запрос самостоятельно.

  • Итеративные: Когда соответствующий сервер DNS получает какой- то итеративный запрос, он становится ответственным за наилучший ответ, который он найдёт в своих зонах и кэшах DNS. Когда он не способен разрешить этот запрос, он откликнется с отрицательным ответом.

В нашем следующем примере некий пользователь в среде AD пытается получить доступ к вебсайту www.rebeladmin.com. Этот вебсайт размещается в соответствующей внешней сетевой среде. Давайте проследуем дальше и посмотрим как работает данный запрос DNS:

 

Рисунок 4-4


Пример запроса DNS

Приводимые далее шаги поясняют нашу предыдущую схему:

  1. Ноутбук Вильяма отправляет рекурсивный запрос DNS в свой сервер DNS AD чтобы разрешить искомый IP адрес вебсайта www.rebeladmin.com. Сведения об этом сервере DNS определены в настроенной конфигурации данного ноутбука.

  2. Интегрированный с AD DNS сервер пытается разрешить полученное имя в некий IP адрес, но его нет. Он не имеет соответствующей настроенной для него записи DNS. Однако он знает, что какой- то сервер DNS способен разрешить его. Это определяется в настройке сервера DNS как ретранслятор (forwarder) DNS. Обычно это будет сервер DNS ISP (Internet Service Provider, поставщика Интернет услуг) или какой- то общедоступный сервер DNS, например, Google.

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

    
Get-DnsServerForwarder

    {Прим. пер.: Если вы работаете с клиентской машиной (не c сервером), для выполнения данных командлетов вам потребуется иметь установленными Средства удалённого администрирования сервера: средства DNS- сервера (RSAT: DNS Server Tools). Начиная с Windows 10 October 2018 Update RSAT входит в состав "Features on Demand" (Дополнительные параметры); прямо из Windows 10. Для более ранней версии Windows 10 обратитесь к инструкции по установке пакета RSAT. Для установки, в меню Start (Пуск) нажмите на шестерёнку (Settings - Параметры) и проследуйте через "Manage optional features" (Приложения и возможности) в "Features on Demand" (Дополнительные компоненты), где выберите "Add a feature" (Добавить компонент) и отыщите RSAT: DNS Server Tools (Средства удалённого администрирования сервера: средства DNS- сервера).}

    Приводимый далее снимок экрана отображает вывод предыдущей команды:

     

    Рисунок 4-5


    Ретрансляторы DNS

  3. Когда данный решатель DNS не имеет записи в своих кэше или локальной зоне, тогда он отправляет некий итеративный запрос к самому корню NS. Существует 13 собранных в кластер корневых серверов, причём работающих в различных географических местоположениях. Они контролируются IANA ( Internet Assigned Numbers Authority).

    DNS Microsoft применяет некую опцию с названием подсказки корня (root hints). По умолчанию они содержат все 13 корневых сервера. Когда у вас нет в вашем сервере DNS установленного ретранслятора, сервер DNS Microsoft будет применять эти корневые серверы для разрешения запросов DNS:

     

    Рисунок 4-6


    Серверы корня DNS

  4. Так как это некий итеративный запрос, такой корневой сервер просматривает его и отвечает, сообщая, что я, мол, не знаю об rebeladmin.com, но я знаю кого- то, кто знает об .com и присоединяет такие сведения об NS TLD (nameservers TLD, серверы имён домена верхнего ровня) .com в своём отклике.

  5. На основании полученного отклика от данного сервера корня наш решатель DNS отправляет некий итеративный запрос в NS TLD .com.

  6. NS TLD рассматривают полученный запрос и отвечают, сообщая, что я не знаю значения IP адреса rebeladmin.com, но у меня есть сведения об NS для rebeladmin.com; пройдите на него и проверьте там - возможно он сможет вам помочь.

  7. Теперь наш решатель DNS знает об NS rebeladmin.com и отправляет некий итеративный запрос ему осведомляясь о значении IP адреса для www.rebeladmin.com.

  8. Этот запрос наконец поступает к правильному адресату, который знает ответ на наго. NS rebeladmin.com отвечает на него IP адресом для www.rebeladmin.com.

  9. Теперь наш решатель DNS знает правильный ответ и отвечает соответствующему серверу DNS AD.

  10. После этого соответствующий клиент DNS в ноутбуке Вильяма получает отклик на свой рекурсивный запрос со значением IP адреса для www.rebeladmin.com.

  11. Ноутбук Вильяма соединяется с веб сервером rebeladmin.com и просматривает этот вебсайт.

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

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

Проектирование инфраструктуры DNS

В своей первой главе я упоминал как домен и Лес AD представляют имеющуюся логическую структуру установки AD. Для поддержки соответствующей логической структуры AD нам также необходимо спроектировать инфраструктуру DNS.

AD DS должен требовать интеграции с DNS. В противном случае его клиенты не будут способны находить местоположение Контроллеров домена. Собственно проектирование инфраструктуры DNS в целом обладает двумя моделями:

  1. Организация уже обладает имеющуюся инфраструктуру DNS и она желала бы придерживаться её. В таком случае нам требуется интегрировать имеющуюся инфраструктуру DNS с пространством имён AD. Это вовлекает в наш процесс развёртывание новых серверов DNS и делегирование DNS.

  2. Ваша организация совсем не имеет никакой инфраструктуры DNS. В такой ситуации проще реализовать новую инфраструктуру DNS совместно с процессом установки нового AD. Это упрощает процесс сопровождения и администрирования.

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

Интегрирование DNS с уже имеющейся инфраструктурой DNS

При интеграции AD DS с уже имеющимся DNS нам следует рассмотреть следующие рекомендации:

  1. Рекомендуется устанавливать роль DNS в каждом из Контроллеров домена. Таким образом эти Контроллеры домена не придётся зависеть от другого сервера для разрешения запросов DNS. Кроме того, нам не требуется перемещать зоны или серверы.

  2. Настраивайте каждый региональный Контроллер домена для размещения той зоны DNS, которая относится к его собственному домену. Это также снизит число зависимостей.

  3. Реплицируйте те зоны, которые содержат записи местоположения по всему Лесу AD во все серверы DNS. Это поможет партнёрским репликациям обнаруживать друг друга, а также находить серверы Глобального каталога.

Настраивайте корневой Контроллер домена соответствующего Леса размещать зону DNS Леса AD. Вместо зависимости от имеющегося пространства имён DNS мы также можем реализовать новое пространство имён DNS только для AD DS. Это носит название расщепления конфигурации пространства имён.

Расчленение пространства имён

При данном методе участники домена могут в конце концов прийти к двум именам DNS. Например, Rebeladmin Inc. обладает некой существующей настройкой DNS hq.rebeladmin.com. Новая настройка AD DS обладает значением суффикса DNS пространства имён DNS ad.rebeladmin.com. ComputerA уже обладает записью DNS с именем ComputerA.hq.rebeladmin.com. Когда ComputerA добавляется в создаваемый домен, наша система зарегистрирует его запись DNS в соответствующей интегрированной с AD зоной DNS в качестве ComputerA.ad.rebeladmin.com. Мы можем применять для ComputerA оба имени DNS. Это носит название расчленённого пространства имён. Это именно то, что очень сложно сопровождать и чем трудно управлять. Прежде чем мы продолжим рассмотрение расчленённого пространства имён, нам следует обратить внимание на следующее:

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

  2. Значение суффикса расчленённого пространства имён не должно соответствовать никакому иному имени Леса или домена, которые требуют "доверия". Это не будет работать по причине отказа такой маршрутизации.

  3. Для оптимизации разрешения имён нам требуется применять Групповые политики или параметры службы DHCP чтобы установить порядок поиска суффиксом DNS.

  4. Приложения (в особенности самостоятельно разработанные) должны быть проверены на проблемы совместимости. Для проверки пользуйтесь лабораторной средой, а также, если это возможно, получите подтверждение от разработчика прежде чем реализовывать расчленённое пространство имён.

Когда организация не обладает пространством имён DNS, мы можем создать пространство имён DNS как часть своего процесса настройки AD DS. Именно его очень просто и легко сопровождать.

Развёртывание новой инфраструктуры DNS, интегрированной с AD

Применяя Мастер установки AD DS мы можем создать новую интегрированную с AD DS инфраструктуру DNS. Как часть данного процесса, ваша система создаст интегрированные с AD зоны DNS для представления своего пространства имён DNS.

Имеется несколько преимуществ применения интегрированных с AD зон DNS:

  • Они применяют ту же самую топологию репликации AD для репликации зон. Нам нет нужды настраивать и сопровождать различные топологии репликации.

  • Все авторизованные Контроллеры домена способны обновлять записи DNS и эти обновления будут реплицироваться во все прочие Контроллеры домена (множество хозяев).

  • Применяя динамические обновления безопасности, мы можем контролировать кто может обновлять имеющиеся записи DNS.

  • После того, как первоначальный процесс настройки завершён, мы также можем создать свои собственные интегрированные с AD зоны DNS чтобы обладать всеми перечисленными выше преимуществами.

Основы DNS

В среде Windows Server его служба DNS может быть запущена как некая индивидуальная служба, либо как некая интегрированная с AD служба. В любом случае, центральные компоненты DNS, технология и термины будут одними и теми же в обоих случаях.

Записи DNS

База данных DNS содержит различные типы записей ресурсов. В некой интегрированной с AD настройке DNS большинство таких записей будут создаваться автоматически при добавлении ресурсов в данный домен, изменении настроек в ресурсах или когда продвигаются/ демонтируются контроллеры домена (записи SRV, A и AAAA). Однако в какой- то инфраструктуре в DNS серверах всё ещё может требоваться создание вручную записей ресурсов (статических).

Запуск записи авторизации

Каждая зона DNS должна иметь некую запись SOA (start of authority), причём она создаётся при создании какой- то зоны в самый первый раз. Эта запись предоставляет множество общих сведений для имеющихся зон DNS, например, следующие:

  • Primary server: Наилучший источник DNS для этой зоны.

  • Responsible person: адрес электронной почты для администратора этой зоны.

  • Serial number: Некое число, которое применяется для отслеживания изменений данной зоны. Когда имеется некая вторичная зона DNS на другом сервере, при его проверке на наличие обновлений в своей зоне хозяина, он будет сравнивать этот серийный номер. В случае, когда такая вторичная зона имеет меньший серийный номер чем зона его хозяина, она обновит свою копию.

  • Refresh interval: Это значение определено когда вторичный сервер должен проверять обновления зон в своём сервере хозяина.

  • Retry interval: Данное значение определяет сколько времени должен ожидать обновлений такой вторичный сервер когда самый первый запрос является неудачным.

  • Expires after: Когда данный вторичный сервер не способен обновить свою зону до установленного здесь значения, он больше не будет рассматривать этот вторичный сервер как самостоятельно авторизуемый.

  • Minimum (default) TTL: Когда в определённой записи ресурса не определяется величина значения TTL (time-to-live), будет использоваться то установленное по умолчанию значение TTL, которое определяется здесь. Данное значение TTL присоединяется к вырабатываемому отклику запросов разрешения DNS.

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


Get-DnsServerResourceRecord -ZoneName "REBELADMIN.COM" -RRType "SOA" | Select-Object -ExpandProperty RecordData

В нашей предыдущей команде REBELADMIN.COM может быть заменён любой иной зоной. Select-Object -ExpandProperty RecordData применяется для раскрытия получаемого вывода.

Записи A и AAAA

Записи хоста используются для установки соответствия некого FQDN (fully qualified domain name) какому- то IP адресу. Такие записи A применяются для IPv4, а записи AAAA используются для IPv6. В AD и интегрированном DNS все устройства будут иметь некую запись A или AAAA при их добавлении в соответствующий домен. если этот адрес IP изменяется, система автоматически обновит также и эту запись.

[Замечание]Замечание

FQDN содержит значение имени хоста и имени домена. В качестве примера давайте рассмотрим FQDN DC01.rebeladmin.com. DC01 это значение имени хоста нашего объекта, а rebeladmin.com это значение имени домена.

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


Add-DnsServerResourceRecordA -Name "blog" -ZoneName "REBELADMIN.COM" -IPv4Address "192.168.0.200"

Для удаления некой записи A выполните такую команду:


Remove-DnsServerResourceRecord -ZoneName "REBELADMIN.COM" -RRType "A" -Name "blog"

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


Get-DnsServerResourceRecord -ZoneName "REBELADMIN.COM" -RRType "A"

В наших приведённых выше командах REBELADMIN.COM можно заменить на любое название зоны.

Записи NS

Записи NS применяются для перечисления авторизованных DNS серверов данной зоны. При некой интегрированной с AD установке DNS все его контроллеры домена с установленной ролью DNS будут добавляться в соответствующие записи NS для файла этой зоны. При наличии множества NS добавляется отказоустойчивость имеющейся настройки DNS.

Приводимая ниже команда перечислит все NS для некой зоны. REBELADMIN.COM можно заменить на любое название зоны.


Get-DnsServerResourceRecord -ZoneName "REBELADMIN.COM" -RRType "NS"

Записи обмена почтовыми сообщениями

Записи MX (Mail exchanger) определяют основной сервер MX для некого домена. Значением MX может быть любой сервер электронной почты (включая Microsoft Exchange, Exim или Office 365). Домен может обладать множеством записей MX и численное значение приоритета такого почтового сервера будет применяться для сопровождения порядка приоритетов. Самое наинизшее значение получит наивысший приоритет.

Записи канонических имён

Записи CNAME (Canonical name) являются псевдонимами для FQDN. Они работают подобно кличкам. Например, у меня имеется настроенной для blog.rebeladmin.com запись A; имеется некий запущенный под ней блог. Не так давно я применял my.rebeladmin.com для того же самого блога. Если пользователи всё ещё применяют my.rebeladmin.com, мне требуется чтобы они всё ещё видели мой блог в blog.rebeladmin.com. Для того чтобы сделать это мне придётся воспользоваться записями CNAME.

Записи указателя

Записи PTR (Pointer) применяются для установления соответствия IP адреса с FQDN. Некоторые именуют его также обратными (reverse) записями DNS. При настройке DNS с AD не будет создаваться зона обратного просмотра; вместо этого её требуется создавать вручную. Когда у вас имеется несколько адресных пространств, вам требуется создавать отдельные зоны обратного просмотра для представления каждого адресного пространства.

Записи SRV

Записи SRV используются для определения значения местоположения некой службы внутри инфраструктуры. Например, когда в вашей инфраструктуре имеется некий веб сервер, применяя запись SRV вы можете определить его протокол, службу и доменное имя, а затем определить местоположение данной службы.

В некой среде AD записи SRV важны, так как они способствуют определению местоположения ближайших контроллеров домена. В своих предыдущих главах я объяснял площадки AD: при входе некого пользователя в систему, этой системе требуется указывать значение локального домена контроллера площадки вместо конкретного контроллера домена в его хабе. Это осуществляется через записи SRV.

В записи SRV можно определять следующие сведения:

  • Service: Определяет название службы, относящейся к данной записи SRV.

  • Protocol: Задаёт используемый протокол. Это может быть либо TCP (Transmission Control Protocol), либо UDP (User Datagram Protocol).

  • Priority: Устанавливает значение приоритета данной службы (только когда эта служба поддерживает данную функцию).

  • Weight: Помогает определять значение приоритета для записей одного и того же типа.

  • Port number: Определяет значение номера порта данной службы.

  • Host offering this service (Предлагающий данную службу хост): Задаёт тот сервер, который предлагает именно эту службу. Должен быть определён как FQDN.

 

Рисунок 4-7


Образец записи SRV

В определённой интегрированной с AD средой DNS имеется некий набор создаваемых по умолчанию записей SRV.

Перечислить записи SRV можно с применением такой команды:


Get-DnsServerResourceRecord -ZoneName "REBELADMIN.COM" -RRType "SRV"

Подробный вывод можно просмотреть следующим образом:


Get-DnsServerResourceRecord -ZoneName "REBELADMIN.COM" -RRType "SRV" | Select-Object -ExpandProperty RecordData

В наших предыдущих командах REBELADMIN.COM можно заменять на любое иное название зоны.

Зоны

Сервер DNS Microsoft поддерживает четыре типа зон, объясняемых последующими разделами. Каждая из этих зон обладает различными обязательствами и характеристиками внутри данного пространства имён DNS.

Первичная зона

Первичной зоной выступает некий доступный для чтения/ записи контейнер, который содержит все DNS записи для домена. Когда вы создаёте самый первый контроллер домена с интегрированным в домене DNS, это создаёт по умолчанию некую первичную зону. Она содержит копию хозяина данной зоны и хранит её в AD DS. Первичные зоны выступают источником для вторичных зон. Пользователям позволено создавать первичные зоны и интегрировать их с AD DS, даже когда те и не соотносятся с установленным для этой AD DS доменным именем.

Существует два вида первичных зон:

  • Стандартные первичные зоны

  • Интегрированные с AD первичные зоны

Стандартные первичные зоны в основном используются в средах без AD для управления DNS. Например, когда вы размещаете развёрнутый в общедоступное пространство веб сервер, вы также можете установить некую роль DNS и управлять этим DNS для него самостоятельно. Однако DNS сервер не обязан иметь некий контроллер домена или сервер участником среды AD. Стандартная первичная зона будет сохранять свои данные в текстовом файле, располагающемся в папке c:\windows\system32\DNS. Самый первый сервер для размещения стандартной первичной зоны становится сервером хозяином. Все записи DNS в такой первичной зоне могут обновляться исключительно через сервер своего хозяина.

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

В некоторой интегрированной с AD настройке первичную зону можно создать воспользовавшись следующей командой:


Add-DnsServerPrimaryZone -Name "rebeladmin.net" -ReplicationScope "Forest" -PassThru

Это создаст некую интегрированную с AD первичную зону DNS для нашего домена rebeladmin.net. Его сферой репликаций назначается весь Лес, что означает, что она будет реплицироваться во все серверы DNS, запущенные в контроллерах домена в Лесу rebeladmin.net. Когда вы пользуетесь имеющимся мастером для создания своей первичной зоны, по умолчанию сфера производимых репликаций устанавливается на весь домен rebeladmin.net, что соотносится со всеми серверами DNS, запущенными в контроллерах домена такого домена rebeladmin.net.

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

Вторичная зона

Вторичная зона содержит доступную только для чтения копию некой первичной зоны. Требуется обновление данных этой зоны посредством контактов с её первичной зоной, размещающейся в другом сервере. Ключевыми для поддержания жизнеспособности вторичной зоны являются надёжная сетевая среда и достаточные полномочия для обмена между зонами. Вторичная зона не может храниться в AD DS.

У меня имеется интегрированная с AD первичная зона с названием rebeladmin.net. У меня есть обособленный сервер DNS, а для требований приложения мне требуется установить в нём некую вторичную зону.

Прежде чем я настрою необходимую вторичную зону, мне требуется отрегулировать полномочия для обмена между зонами. По умолчанию, в интегрированных с AD зонах обмен между зонами запрещён:


Set-DnsServerPrimaryZone -Name "rebeladmin.net" -SecureSecondaries TransferToSecureServers -SecondaryServers 192.168.0.106

В приводимой выше команде rebeladmin.net это моя зона, а TransferToSecureServers определяет, что необходимый обмен будет разрешён только для перечисляемого вторичного сервера, 192.168.0.106.

Если это требуется, конфигурацию можно изменять с помощью -TransferAnyServer для разрешения перенесения на любой сервер и -TransferToZoneNameServer для разрешения переноса только на NS:

 

Рисунок 4-8


Настройки передачи зоны

Теперь я могу настроить вторичную зону в своём сервере 192.168.0.106.

В следующей команде -MasterServers определяет значение IP адреса сервера хозяина. Здесь имеется параметр -ZoneFile, однако лишь для основанных на файлах серверов DNS:


Add-DnsServerSecondaryZone -Name "rebeladmin.net" -ZoneFile "rebeladmin.net.dns" -MasterServers 192.168.0.105

Зоны заглушек

Зона заглушки (Stub) является доступной только на чтение копией зоны хозяина, тем не менее, содержит лишь записи SOA и NS. Она не выступает каким бы то ни было авторизованным сервером DNS для такой зоны. Зоны заглушек не являются заменой для вторичных зон и они не могут использоваться для совместного использования нагрузки или целей избыточности. Кое кто полагает, что зоны заглушек и условные ретрансляторы делают похожие вещи, но они совершенно различны.

Условный ретранслятор (conditional forwarder) имеет список DNS серверов, которые помогает вашему серверу DNS разрешать запросы DNS для определённого домена. Когда ваш сервер DNS получает некий запрос для этого домена, он переправляет этот запрос в те серверы, которые перечислены списком в условном ретрансляторе. Он может содержать или нет все имеющиеся для этого домена авторизованные серверы DNS. Когда ваш сервер DNS получает некий запрос для зоны заглушек, он следует далее и выполняет запрос напрямую в тех серверах, что перечислены в этой зоне и доставляет полученный результат.

Зоны обратного просмотра

Зоны обратного просмотра содержат записи PTR. Зона обратного просмотра также может быть первичной зоной, вторичной зоной или зоной заглушек. Зонам обратного просмотра необходимо соответствие с имеющимся сетевым сегментом своей организации. Даже когда она интегрирована с AD DS, сама система не создаст какую бы то ни было зону обратного просмотра по умолчанию. Её требуется создавать вручную.

Например, мне требуется создать некую зону обратного просмотра для своей сетевой среды 10.10.10.0/24. Для этого я могу воспользоваться следующей командой:


Add-DnsServerPrimaryZone -NetworkID "10.10.10.0/24" -ReplicationScope "Domain"

В приведённой выше команде -ReplicationScope установлен в Domain. Это означает, что она будет реплицироваться во все интегрированные в этом домене Контроллеры домена.

Теперь мы прошлись по всем четырём типам зон DNS. Мы изучили различные характеристики каждой из зон и также рассмотрели установленные для каждой из зон роли.

Условные ретрансляторы

В серверах DNS мы пользуемся "ретрансляторами" (forwarders) для передачи запросов DNS во внешние серверы DNS когда они не могут быть разрешены ими внутри. Обычно это будут серверы ISP (Поставщика услуг Интернет). Здесь также могут применяться общедоступные серверы DNS от сторонних организаций, например, ретрансляторы Google:

 

Рисунок 4-9


Ретрансляторы DNS

Если ретрансляторы не отвечают, ваш сервер DNS для разрешения полученного запроса будет применять "Root Hints".

Серверы ретрансляции и Корневые ссылки (Root Hints) в целом применяются для разрешения внешних запросов. Однако когда нам требуется направлять DNS запросы для конкретного домена в определённый сервер/ серверы DNS, мы можем выполнять это при помощи "условных ретрансляторов". Например, когда имеется партнёрская компания с доменным именем rebeladmin.net. Их DNS сервер это 10.0.0.5. Эти две организации соединены совместно через подключение VPN. Поэтому когда пользователь из домена rebeladmin.com пытается выполнить разрешение соответствующего имени хоста из rebeladmin.net, он должен переправляться в 10.0.0.5. Для осуществления этого нам надлежит создать условный ретранслятор при помощи


Add-DnsServerConditionalForwarderZone -Name "rebeladmin.net" -ReplicationScope "Forest" -MasterServers 10.0.0.5

Выше я создал интегрированный с AD условный ретранслятор для своего домена rebeladmin.net. Все запросы для rebeladmin.net будут разрешаться при помощи нашего DNS сервера 10.0.0.5. Эта настройка будет реплицироваться во все Контроллеры домена данного леса.

Условные ретрансляторы в основном применяются когда организация создаёт "доверие" AD с другим Лесом или доменом AD. Дополнительные сведения о доверительных отношениях AD будут пояснены в Главе 11, Службы Active Directory - Часть 01.

Запросы DNS через условные ретрансляторы быстрее и более безопасны. Когда мы выполняем разрешение через ретрансляторы DNS, они применяют итеративные запросы обратно и вперёд для поиска необходимых ответов. Однако условные ретрансляторы применяют рекурсивные запросы, что ускоряет разрешение имён.

Политики DNS

Политики DNS впервые были введены в Windows Server 2016 и доступны также и в Windows Server 2022. В целом, политики DNS обладают следующими возможностями:

  1. Геолокация на основе маршрутизации обмена - Давайте предположим, что Rebeladmin Inc. пользуется двумя веб серверами, для размещения своего вебсайта rebeladmin.com. Один из этих веб серверов расположен в Канаде, а другой размещается в Великобритании. Большинство посетителей этих вебсайтов приходят из этих двух регионов и через поддержку своего локального центра обработки данных Rebeladmin Inc. ожидает улучшения установленной практики пользователей. Применяя политику DNS, Rebeladmin Inc. может указывать клиентам в США/ Канаде на свой веб сервер в Канаде, а пользователям из Европы на соответствующий сервер в Великобритании.

    [Замечание]Замечание

    Мы также можем осуществлять это при помощи Azure Traffc Manager. Дополнительные подробности относительно его настройки доступны в https://bit.ly/30QoPr8.

  2. Балансировка нагрузки приложения - Наш вебсайт rebeladmin.com имеет четыре веб сервера в четырёх различных центрах обрабоки данных (ЦОД) в Канаде. Каждый сервер обладает аналогичной ёмкостью оборудования и посредством применения политик DNS я способен выполнять маршрутизацию 25% обмена в каждый ЦОД. Кроме того, давайте предположим, что rebeladmin.com обладает веб сервером, запущенном в ЦОД Великобритании. Однако этот сервер не обладает лучшей мощностью обработки. Применяя политики DNS я могу маршрутизировать 50% Европейского обмена в свой веб сервер в Великобритании, а остальной обмен в свой веб сервер в Торонто.

  3. Отклик DNS на основании времени - rebeladmin.com обладает двумя веб серверами; один из них запущен в Канаде, а другой работает в Великобритании. 70% пользователей этого сайта имеют доступ из США и самые загруженные часы приходятся на промежуток между 7 и 10 вечера. В последнее время пользователи из США жалуются на производительность сайта. На протяжении этих часов использование соответствующего веб сервера в Великобритании крайне низкое.

    Таким образом, для улучшения практики пользователей, мы можем применяя политики DNS выполнять маршрутизацию 40% обмена пользователей США в пиковые часы в веб сервер Великобритании.

  4. Расщепление сознания DNS - Когда пользователи офиса Rebeladmin Inc. получают доступ к rebeladmin.com, я принуждаю их обращаться на внутренний IP адрес этого веб сервера, а если кто- то ещё выполняет доступ к rebeladmin.com из внешних сетевых сред, он должен следовать к общедоступному IP адресу этого веб сервера. Это носит название ситуации расщепления сознания DNS и теперь мы способны управлять такой конфигурацией при помощи политик DNS.

  5. Фильтрация запросов DNS - Мы можем создавать политики DNS для фильтрации запросов на основании значения подсети клиента, IP адреса сетевого интерфейса, транспортного протокола, интернет протокола, FQDN, типа запроса и времени дня. Например, мы можем создать политику DNS блокировки запросов из диапазона 40.114.1.0/24.

Давайте двинемся далее и рассмотрим конкретную политику DNS в действии. В своей демонстрационной настройке у меня имеется компьютер с IP адресом 10.0.0.6. Наш сервер DNS запущен в 10.0.0.4 и имеется размещённой некая запись A для портала portal.rebeladmin.com, которая разрешается в 10.0.0.7. Когда я запускаю nslookup из 10.0.0.6, я получаю ожидаемый мною отклик:

 

Рисунок 4-10


Запрос DNS

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


Add-DnsServerClientSubnet -Name "blockA" -IPv4Subnet 10.0.0.6/32

В своей предудущей команде я присвоил название "blockA" указанной подсети. Затем давайте двинемся далее и создадим политику.


Add-DnsServerQueryResolutionPolicy -Name "blockApolicy" -Action IGNORE -ClientSubnet "EQ,blockA"

В приведённом выше примере я создал политику с названием "blockApolicy" для блокирования запросов DNS с адреса 10.0.0.6.

После размещения этой политики, я проследовал далее и снова попробовал запрос nslookup с адреса 10.0.0.6:

 

Рисунок 4-11


Отказавший запрос DNS

Как мы можем наблюдать, 10.0.0.6 не получает никакие отклики.

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

Безопасный клиент DNS поверх HTTPS (DoH)

Запросы DNS между DNS сервером и DNS клиентом обычно представлены в обычном формате простого текста. Однако начиная с Windows Server 2022 запросы DNS могут передаваться через безопасные подключения HTTP (HTTPS). Это препятствует тому чтобы некто изменял/ получал доступ к данным DNS при обмене. Обратите внимание, что эта настройка действует только для клиентов DNS. Windows DNS сервер не поддерживает запросы DoH. Таким образом, вам не следует включать DoH в подключённых к домену компьютерах. Когда имеется обмен между подключённым к домену компьютером и его сервером домена AD, нам потребуется рассмотреть безопасные подключения IPSec. На данный момент времени запросы DoH поддерживают DNS серверы Google и Cloudflare.

Режимы работы сервера DNS

Существует три типа режимов работы сервера DNS. Эти режимы не являются чем- то, что можно выбирать в процессе установки. Они перечисляются на основе своих характеристик:

  • Dynamic: Интегрированные с каталогом AD DS DNS по умолчанию применяют DynDNS. DynDNS делает возможной регистрацию хостов и пользователей, обновление и удаление записей DNS в серверах DNS. Давайте предположим, что у нас имеется некая среда AD с 200 компьютерами. Она применяет DHCP (Dynamic Host Configuration Protocol) для поддержки назначения IP; поэтому каждые три дня все устройства обновляют свои выделенные IP. Некоторые могут иметь тот же самый адрес, но прочие могут получать какой- то новый. Но когда наша система использует статический DNS, администраторам потребуется раз в три дня обновлять имеющийся перечень DNS для поддержки соответствия выделенным IP адресам. Кроме того, AD не будет способен отыскивать свои устройства для установки аутентификации или обработки ресурсами запрошенного доступа. Тем не менее, благодаря DynDNS это больше не является ручной работой и это позволяет вашей среде поддерживать современные сведения DNS без вмешательства пользователя.

  • Read/write: Это приемлемо когда зоны DNS запущены без интеграции с AD DS. Например, один из клиентов Rebeladmin Corp. желает разместить свой собственный веб сервер. Таким образом, в качестве поставщика услуг, нам потребуется предоставить некое решение, в котором проектирование DNS является частью. Данный клиент хотел бы оставлять стоимость минимальной, а поскольку это это среда для проверки, они не заботятся о высокой доступности. Для требований DNS их веб сервера мы можем настроить некий обособленный DNS сервер. Его записи не должны изменяться часто, потому нет потребности в DynDNS. Когда требуется обновление записей, некий пользователь с достаточной авторизацией сможет обновлять их вручную.

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

В Windows Server 2008, Microsoft ввёл RODC (read-only domain controllers). RODC можно применять в инфраструктурах, в которых не гарантируются физическая безопасность и соединения. RODC запускают интегрированные с AD DS первичные зоны DNS в доступном только для чтения режиме.

Для соответствия своим требованиям DNS в инфраструктурах могут применяться эти режимы. Имеется возможность смешения в DNS серверах различных режимамов работы. Но для устранения неполадок важно чётко понимать возможности каждого режима работы DNS.

Передача зон

Жизнеспособность репликации DNS выступает ключевым требованием для целостности службы и инфраструктуры. В своём предыдущем разделе я объяснял различные зоны. Я также упомянул как настраивать полномочия обмена между зонами. Теперь настало время рассмотреть репликации.

Существует два типа репликации файлов зон:

  • Asynchronous Full Transfer Zone (AXFR) (Асинхронная полная передача зоны): При установке некой новой вторичной зоны, ваша система будет реплицировать полную копию всего файла зоны со своего сервера хозяина. Это применимо не только к подобной вторичной зоне; это также применимо и для прочих зон. В случае проблем с репликацией DNS, его администратору может время от времени требоваться передача полной зоны (синоним передача целой зоны) со своего сервера хозяина.

  • Incremental Zone Transfer (IXFR) (Передача зоны приращениями): После первоначальной полной передачи зоны, ваша система будет реплицировать только те записи, которые были подвержены изменениям. Это снижает обмен при реплицировании, а также предоставляет более быструю репликацию.

Когда имеется некое изменение в зоне DNS хозяина, ваша система отправит уведомления во вторичные серверы об этом изменении. Затем, вторичные серверы запросят некое обновление зоны. Если вторичные серверы теряли подключение к своему первичному серверу или после перезапуска данной службы, такая система всё ещё запрашивает (на основе интервалов обновления SOA) обновления для зоны с серверов хозяев DNS.

Делегирование DNS

В своей предыдущей главе, когда мы рассматривали проектирование необходимой AD DS, я объяснял дочерние контроллеры и то как их можно применять для организации иерархии AD вашей компании. Когда вы создаёте некий дочерний домен в Лесе, это также создаёт его собственное адресное пространство имён DNS. В некой DNS структуре порой требуется чтобы вы делили имеющееся пространство имён DNS для создания дополнительных зон. Делегирование DNS позволяет организациям достигать этого без необходимости изменения установленной структуры DNS.

В интегрированном с AD DNS вам позволяется создавать любые зоны DNS, причём они будут реплицироваться в прочие Контроллеры домена. Однако существуют ситуации, при которых это может приводить к накладным расходам администрирования. Rebeladmin Corp. применяет в качестве своего доменного имени AD DS rebeladmin.com. У них имеется подразделение разработки программного обеспечения, которое разрабатывает веб- приложения.

Для проверки своих приложений им приходится применять некий URL веб. Всякий раз, когда им требуется что- то проверить, они открывают квитанцию поддержки и их ИТ команда создаёт для их веб сервера в своём DNS сервере запись A. В последнее время такие запросы стали слишком частыми и порой, в силу своей загрузки, ИТ команда сталкивается с задержками в обработке этих запросов. Это начинает воздействовать на срок завершения выпуска программного обеспечения. Что бы мы могли сделать чтобы обойти данную ситуацию и предоставить лучшее решение? Если бы имелся некий способ позволить команде разработчиков программного обеспечения создавать записи A когда они им требуются, им бы не приходилось дожидаться необходимых действий от своей ИТ команды. При помощи функциональной возможности делегирования необходимого DNS, мы имеем возможность развернуть некий сервер DNS и создать зону DNS с названием dev.rebeladmin.com. После этого мы можем разрешить своей команде разработчиков программного обеспечения управлять необходимыми записями DNS в ней. Они смогут создавать записи для приложений, такие как app1.dev.rebeladmin.com и app2.dev.rebeladmin.com. Кроме того, все имеющиеся в rebeladmin.com пользователи всё ещё будут способны получать доступ к этим URL без дополнительных изменений, так как зона DNS rebeladmin.com знает какой именно сервер DNS имеет авторизацию для записей DNS dev.rebeladmin.com.

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

Прежде чем мы приступим к процессу делегирования, нам потребуется некий второй сервер DNS с активной первичной зоной DNS.

В моём примере у меня имеется новый DNS сервер с названием REBEL-SDC01.rebeladmin.com. Я установил в нём необходимую роль DNS и создал первичную зону DNS с названием dev.rebeladmin.com:


Add-DnsServerPrimaryZone -Name "dev.rebeladmin.com" -ZoneFile "dev.rebeladmin.com.dns"

Также я создал некую запись A в этой зоне с названием app1:


Add-DnsServerResourceRecordA -Name "app1" -ZoneName "dev.rebeladmin.com" -AllowUpdateAny -IPv4Address "192.168.0.110"

Чтобы установить необходимое делегирование DNS, я зарегистрировался в контроллере домена REBEL-PDC-01.rebeladmin.com и запустил следующую команду:


Add-DnsServerZoneDelegation -Name "rebeladmin.com" -ChildZoneName "dev" -NameServer "REBEL-SDC-01.rebeladmin.com" -IPAddress 192.168.0.110

В приводимой выше команде ChildZoneName определяет значение названия зоны в соответствующем другом сервере DNS.

Теперь, когда я захожу в Диспетчер DNS и раскрываю его дерево, я могу видеть свою запись делегированной зоны для dev.rebeladmin.com:

 

Рисунок 4-12


Делегированная зона

Когда я выполняю ping app1.dev.rebeladmin.com с ПК в rebeladmin.com, я способен успешно достигать его:

 

Рисунок 4-13


Разрешение имён из делегированной зоны

Поставщики службы DNS

В этой главе мы в основном обсуждали то, как работает DNS в средах AD. Однако это не единственный способ использования DNS. Когда нам требуется управлять DNS для внешних URL, например для вебсайтов, нам настраивать серверы DNS неким иным образом. Такой тип DNS серверов в основном работает с общедоступными IP адресами. Для установки некого развёрнутого вовне сервера DNS вначале нам требуется зарегистрировать записи DNS. Затем, через регистратора NS домена нам требуется указать значение DNS домена на этот вновь созданный NS. После этого мы способны настраивать необходимые записи DNS для этого домена при помощи своего собственного сервера DNS. Как и с любой прочей ролью сервера, DNS также время от времени требует работ по сопровождению. Кроме того, нам требуется поддерживать для таких серверов DNS необходимый уровень высокой доступности. Вместо всех этих накладных расходов дополнительного сопровождения мы можем воспользоваться поставщиком службы DNS для выполнения всех этих моментов. Azure DNS, Godaddy, Dotster, 1&1 и DynDNS {Прим. пер.: а также nic.ru для зоны .ru} являются некими наиболее известными поставщиками служб DNS. Всё что нам требуется, это действующая подписка, после чего в пределах нескольких минут мы сможем начать добавлять необходимые относящиеся к делу записи DNS. Это не требует изменений межсетевого экрана, серверов или каких- либо ещё ресурсов. Управление DNS записью также очень простое для воплощения и использует веб интерфейс. Нам также не требуется заботиться о резервных копиях, репликациях или высокой доступности, поскольку всё это отрабатывается самими поставщиками этих услуг.

Выводы

В некой инфраструктуре мы не можем обсуждать AD DS без упоминания DNS. В данной главе мы охватили самые основы DNS и вы уяснили почему она так важна. Затем мы перешли к иерархическому именованию структуры и увидели как это способствует переводу некой логической структуры организации в пространство имён домена. Мы также изучили в точности как DNS выполняет работу за сценой. После этого мы рассмотрели записи DNS и зоны DNS. Это также включало некое объяснение того как создавать различные зоны. Мы также изучили политики DNS, которые впервые были предложены в Windows Server 2016. К концу данной главы вы изучили различные режимы работы DNS и репликации. Я надеюсь, что эти сведения помогут вам понимать всю важность DNS в некой инфраструктуре и как её применять надлежащим образом.

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