Глава 4. Active Directory DNS

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

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

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

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

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

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

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

TLD Управляющие (Top-Level Domain Managers) - абсолютно все TLD имеют свои собственные организации управления доменом. Эти организации отвечают за делегирование из TLD. К полному перечню управляющих TLD можно получить доступ по ссылке в iana.org.

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

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

TLD имя	Описание
.com	Это наиболее часто применяемый TLD и он в основном применяется для регистрации сосредоточенных на получении прибыли бизнесов. Он также применяется для регистрации таких площадок как персональные веб сайты, блоги и вебсайты общения. Он открыт для регистрации любой персоны.
.org	В основном используется не извлекающими прибыль организациями и сообществами. Он открыт для регистрации любых персоналий.
.net	Применяется для представления распределённых сетевых сред компьютеров. Открыт для общего доступа и любой может зарегистрировать здесь своё имя.
.edu	Это ограниченная регистрация для обучающих институтов.
.gov	Ограничен записями государственных органов.
.ca, .co.uk	Применяются для представления стран. Регистрация под ними в домене зависит от правил и соглашений регулирования их представителями полномочий регистрации имён доменов в соответствующей стране.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для добавления некой записи 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"
		

Записи 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 можно определять следующие сведения:

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

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

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

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

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

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

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

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

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

Стандартные первичные зоны в основном используются в средах без 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 первичная зона с названием 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:

Теперь я могу настроить вторичную зону в своём сервере 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

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

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

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

Зоны обмена

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

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

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

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

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

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

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

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