Динамическое обновление dns в windows 2012 r2

Содержание

Понятие роли DNS Server
Установка DNS
Конфигурирование автономного DNS-cepвepa
Интеграция с другими DNS-серверами
Реализация зон для управления пространствами имен
Типы записей
Управление клиентами DNS и преобразованием имен
Система DNS в Active Directory
Автоматическое конфигурирование DNS
Записи SRV и клиенты
Дополнительные компоненты Windows Server 2012 R2
Поддержка преобразования имен DNS на основе Интернета 
Поддержка внешних доменов DNS
Преобразование внешних пространств имен
Администрирование и устранение неполадок с помощью инструментов DNS
Администрирование DNS-cepвepa с помощью консоли управления DNS и PowerShell
Использование NsLookup и DcDiag
Полезные ссылки по устранению неполадок в DNS

Компьютеры взаимодействуют друг с другом с использованием IР-адресов,
либо 1 Pv4, либо 1 Pv6. Тем не менее, большинству людей трудно запомнить
IР-адрес излюбленного веб-сайта или файлового сервера. Людям нравится приме­
нять дружественные текстовые имена. Таким образом, для преобразования этих дру­жественных имен компьютеров в назначенные им I Р-адреса реализуются системы имен. Система доменных имен (Domain Name System — DNS) — это система имен, используемая серверами Windows Server 2012 R2. Система DNS не только помогает пользователям легко идентифицировать устройства, она является обязательной для множества служб, таких как Active Directory, чтобы клиенты и серверы могли взаи­модействовать с контроллерами доменов.
В этой главе вы изучите следующие темы:
• фундаментальные компоненты и процессы DNS;
• конфигурирование DNS для поддержки среды Active Directory;
• управление и устранение неполадок с преобразованием имен DNS для внут­
ренних и внешних имен.

Система DNS существовала на протяжении десятилетий до того, как в Microsoft
разработали свою первую редакцию DNS в Windows NT 4.0. Существует много раз­
новидностей реализаций DNS, которые поддерживают компоненты и процессы, оп­ределяющие DNS. В этом разделе мы раскроем концепции системы доменных имен от Microsoft и покажем, как она применяется в операционных системах Windows.
Система DNS реализована внутри ОС Windows Server 201 2 R2 для управления
преобразованием имен в I Р-адреса. После установки на сервере службе DNS по­
надобится взаимодействовать с другими серверами имен DNS, что достигается с
использованием множества разных методов, таких как переадресация, корневые
подсказки и делегирование. Служба DNS будет также поддерживать базы данных,
называемые зонами, для внутреннего домена Active Directory или других пространств имен. Компьютерам домена необходимо будет опрашивать эту службу DNS, поэто­му вам придется сконфигурировать отдельные компьютеры, чтобы обеспечить эф­фективное и быстрое преобразование имен.
Windows Server 2012 R2 и предыдушие выпуски ОС Windows Server предлагают
встроенную роль DNS Server (DNS-cepвep). Система Windows Server 201 2 R2 DNS
совместима со старыми версиями DNS вплоть до Windows Server 2003; однако вер­сии, более ранние, чем Windows Server 2008, не поддерживают 1Pv6 и функциониру­ют только с адресами IPv4.
Ниже приведена краткая сводка по фундаментальным концепциям DNS, имею­
щим отношение к данной главе.
• Имя хоста (hostname). Это (дружественное) имя компьютера. Согласно стан­
дартам DNS, оно может иметь длину до 255 символов. Имя хоста эквиваflент­
но первому имени компьютера, например, ECOl.
• Пространство имен (namespace). Это имя домена, хотя и не обязательно доме­
на Active Directory. Пространство имен представляет собой логический набор
хостов, обозначенных именем, которое управляется набором серверов имен.
Это эквивалент второго имени компьютера; все они являются частью одного
семейства. Например, Bigfirm. com — пространство имен для хостов в домене
Bigfirm. com.
• Полное имя домена (Fully Qualified Domain Name — FQDN). Ичя FQDN —
это имя хоста, к которому добаrшено пространство имен домена, такое как
ECOl . Bigfirm. com.
• Файл ноsтs. Это текстовый файл, в котором имена хостов статически отоб­
ражаются на IР-адреса. Файл HOSTS расположен в с : windowssystem32
driversetc для стандартных установок Windows Server 2012 R2 и может при­
меняться в качестве простейшей альтернативы DNS-cepвepy для преобразо­
вания имен в небольших средах. Тем не менее, не пытайтесь управлять круп­
ными производственными средами с помощью записей в статическом файле
ноsтs, поскольку это быстро превратится в кошмар администрирования!
• Сервер имен (name server). Это DNS-cepвep, который будет преобразовывать
имена FQDN в IР-адреса. Серверы имен также управляют пространствами
имен для указанных доменов. Они будут обрабатывать запросы для этих про­
странств имен, поступающие от клиентов DNS через сеть.
• Иерархическая структура имен (blerarchical naming stгucture). Пространство имен создано, поэтому левой частью имени является подмножеством правой части
имени, как можно видеть в FQDN. С учетом этого сервера имен могут начи­
нать с правой части имени, а ответы от серверов имен направят его на коррек­
тный сервер имен для заданноrо пространства имен. Например, как показано
на рис. 6. 1 , Ес0 1 . Ecoast . Bigfirm. com является именем FQDN для сервера в домене Ecoast . Bigfirm. com. Данный домен в действительности представ­ляет собой подмножество, или поддомен, находящееся под контролем домена Bigfirm. com. То же самое можно сказать
о Bigfirm. com в отношении имени доме­
на верхнего уровня . com. Достоинство за­
ключается в том, что вы можете запросить
у сервера доменных имен . com, где на­
ходится сервер имен Bigfirm. com. То же
самое можно делать для сервера Ecoast .
Bigfirm. com и т.д. Имя FQDN направля­
ет запрос правильному серверу имен пос­
редством процесса, который называется
рекурсией.
Домен .com
Д о мен Bi g firm.com
+ Рекурсия (recursion). Это управляемый
сервером процесс преобразования имени
FQDN. Если сервер не может распознать
имя FQDN посредством собственной ин-
формации, он отправит запрос другим
Рис. 6.1 . Иерархическое именова-
ние DNS
серверам имен. В процесс рекурсии вовле-
чены корневые серверы и серверы имен доменов. Корневые серверы находят­
ся на верхушке иерархической структуры имен. Корневые серверы содержат
списки серверов имен, которые управляют именами доменов верхнего уровня,
такими как . com, . gov и . edu. Серверы доменов верхнего уровня управля­
ют реестром поддоменов, расположенных в иерархии ниже доменов верхнего
уровня. Например, серверы имен для поддомена Sybex. com зарегистрированы
на серверах домена . com. Н иже описаны действия, которые происходят при
поступлении запроса имени (рис. 6.2).
Корневой («.») DNS-cepвep
DNS-cepвep Sybex.com
www .Sybex.com
DNS-клиент
Рис. 6.2. Процесс рекурсии в DNS

. Клиент DNS запрашивает у DNS-cepвepa имя, подобное www . Sybex . com.
2. Через процесс рекурсии DNS-cepвep запрашивает у корневых серверов сер­
веры имен домена . com.
3. Корневые серверы предостамяют список серверов имен Дll Я домена . com.
4. DNS-cepвep запрашивает у серверов домена . com серверы имен ДllЯ Sybex .
com.
5. Он получает еще один список серверов имен Дll Я домена Sybex. com.
6. DNS-cepвep запрашивает у предоставленных серверов имен FQDN-имя
www. Sybex . com.
7. DNS-cepвep Sybex . com выдает I Р-адрес веб-сервера исходному DNS­
cepвepy.
8. Исходный DNS-cepвep передает IР-адрес клиенту.
9. Располагая этим 1 Р-адресом, клиент подключается к веб-серверу www .
Sybex . com.
• Делеrирование (delegation). Это означает разрешение другому серверу имен
управлять поддоменом заданного пространства имен. Например, серве­
ры имен Bigfirm. com могут делегировать управление пространством имен
Ecoast . Bigfirm. com другому серверу.
• Переадресация (forwarding). Это является альтернативой процессу рекурсии.
Переадресация представляет собой ответвленный запрос к другому серверу
имен внугри сети. Сервер, на который бьша произведена переадресация, полу­
чает ответ и ретранслирует его исходному серверу имен.
• Итерация (iteration). Это управляемый клиентом процесс преобразования име­
ни FQDN. Если клиент получает отрицательный ответ от сервера имен, он бу­
дет запрашивать другой сервер имен.
• Система имен NetBIOS (NetBIOS naming system). Эта унаследованная система
имен использовалась главным образом в старых сетях Microsoft NT 4.0. Тем не
менее, ее процессы по-прежнему являются частью современных операцион­
ных систем Windows, особенно когда применяются компьютеры, входящие не
в домен, а в рабочую группу.
• Записи служб (service records). Записи служб (SRV) представляют собой записи
внутри пространства имен DNS, предназначенные мя преобразования службы
в имя хоста. Они являются неоrьемлемой частью поддержки DNS мя Active
Directory.
• Динамическое обновление DNS (dynamic DNS update). Динамическое обновле­
ние DNS (Dynamic DNS — DDNS) — это процесс, который позволяет кли­
ентам DNS регистрировать свои имена хостов в назначенном пространстве
имен, Т’Jком как DHCP. Это сокращает необходимость ручного ввода записей
администраторами в базы данных серверов имен. Динамическое обновление
DNS является еше одной неотъемлемой частью поддержки DNS для Active
Directory.

Установка DNS

Роль DNS для Windows Server 2012 R2 может быть развернута в нескольких от­личающихся конфиrурациях, зависящих от выбранного сценария. Можно устано­вить автономный DNS-cepвep на компьютере, не присоединенном к домену, или же можно развернуть его либо на серверах-членах домена, либо на серверах, явля­ющихся контроллерами домена Active Directory. Какой бы сценарий не был выбран, установка роли DNS проста. Сначала мы покажем, что понадобится сделать для ручного развертывания DNS на компьютере, не присоединенном к домену, в авто­номной конфиrурации. Затем мы объясним, как автоматически сконфиrурировать DNS для интеграции с Active Directory, чтобы обеспечить гладкое выполнение пре­образования имен внутри среды домена.

Конфигурирование автономного DNS-cepвepa

Самое важное: вы должны выделить серверу, на котором хотите установить
роль DNS, статический IР-адрес, поскольку попадать в движущуюся цель клиенту
DNS будет очень непросто! Если на рабочем столе вы нажмете комбинацию кла­
виш <Ctrl+R>, а затем введете ncpa. cpl и нажмете , откроется окно Network
Connections (Подключения к сети). В этом окне можно щелкнуть правой кнопкой на сетевом адаптере и выбрать в контекстном меню пункт Properties (Свойства), чтобы открыть окно конфигурирования. Если вы дважды щелкнете на элементе lnternet Protocol Version 4 (TCP/1Pv4) (Протокол Интернета версии 4 ((TCP/1Pv4))), откроется
диалоговое окно lnternet Protocol Version 4 (TCP/1Pv4) Properties (Свойства протокола Интернета версии 4 (TCP/1Pv4)). В нем можно назначить статический IР-адрес, как показано на рис. 6.3.
После назначения статического 1 Р-адреса вы должны добавить первичный DNS­
суффикс, такой как Bigf i rm . com, в диалоговом окне Advanced TCP/1Pv4 Settings
(Расширенные настройки TCP/1Pv4), как показано на рис. 6.4.

Добавление первичного DNS-суффикса требуется не всегда. Он модифицируется
автоматически, когда компьютер присоединяется к домену. Если по плану сервер
должен функционировать как часть рабочей группы (в рассматриваемом примере
так и есть), первичный DNS-суффикс необходимо добавить, чтобы другие DNS­
cepвepы могли находить этот сервер внутри структуры DNS, а служба DNS была
корректно сконфигурирована во время установки.
После указания статического IР-адреса и DNS-суффикса на сервере, не при­
соединенном к домену, выполните перечисленные ниже шаги для установки роли DNS.
l . Откройте диспетчер серверов щелкните на элементе Dashboard (Управляющая
панель) и затем щелкните на ссылке Add Roles and Features (Добавить роли и
компоненты),

2. На экране Before You Begin (Прежде чем начать) мастера добавления ролей и
компонентов (Add Roles and Features Wizard) щелкните на кнопке Next (Далее),
чтобы продолжить.
3. На экране Select lnstallation Туре (Выбор типа установки) выберите переклю­
чатель Role-Based or Feature-Based installation (Установка на основе ролей или
на основе компонентов) и щелкните на кнопке Next.
4. На экране Select Destination Server (Выбор сервера назначения) мастера вы­берите переключатель Select а Server from the Server Pool (Выбрать сервер из пула серверов) и удостоверьтесь в том, что ваш сервер отмечен; щелкните на кнопке Next.
5. На экране Select Server Roles (Выбор серверных ролей) мастера отметьте фла­жок возле роли DNS Server (DNS-cepвep) и, если после выбора роли DNS
Server откроется диалоговое окно, щелкните в нем на кнопке Add Features
(Добавить компоненты), как показано на рис. 6.6.
6. На всех последующих экранах щелкайте на кнопке Next, пока не достигнете
экрана Confirm lnstallation Selections (Подтверждение выбранных настроек для
установки). Проверьте, все ли выбранные настройки корректны, и щелкните
на кнопке lnstall (Установить), чтобы начать процесс установки.

7. После завершения установки роли DNS Server щелкните на кнопке Close Закрыть) для закрытия окна мастера.
Установка роли подобным образом приводит к созданию изолированного серве­
ра имен DNS, который взаимодействует только с корневыми серверами Интернета.
Он может поддерживать среду локальной вычислительной сети для преобразова­
ния имен Интернета, но на этом и все. Система доменных имен использует другие серверы имен для преобразования имен по всей структуре DNS. По этой причине вы должны будете сконфигурировать сервер на взаимодействие с другими DNS­ серверами, которые существуют во внутренней сети. Хотя настройка DNS-cepвepa в автономной конфиrурации без присоединения к домену может иметь свои преимущества (вроде его развертывания в средах, где управление многочисленными ста­тическими файлами ноsтs на серверах становится мучительным), действительная мощь системы Windows Server 201 2 R2 DNS проявляется при ее применении с Active Directory.

Интеграция с другими DNS-серверами

В разделе «Понятие роли DNS Server» упоминалось, что существуют разные ме­
тоды для преобразования имен DNS, такие как переадресация, рекурсия, делегиро­
вание и итерация. Эти методы относятся к интеграции с другими DNS-серверами.
Прежде чем начать, вспомните, что итерация по существу управляется клиентом.
Если DNS-cepвep не имеет ответа, клиент перейдет на другой DNS-cepвep. Сервер
или клиент можно настроить только на итерацию, но это не делается по умолчанию
и редко реализуется. Другие три приема — переадресация, рекурсия и делеrирова­
ние — предусматривают взаимодействие запрашиваемого DNS-cepвepa с другими
D N S-серверами.
Рекурсия — это главный процесс, происходящий в Интернете. Запрашиваемый
DNS-cepвep начинает с самого верха и проходит вниз по ссылкам, получаемым от
каждого DNS-cepвepa, с которым он взаимодействует. На серверах Windows DNS
серверы верхнего уровня перечислены на вкладке Root Hiпts (Корневые подсказки)
диалогового окна свойств DNS-cepвepa (рис. 6.7). Это окно можно отобразить в
оснастке DNS Maпagemeпt (Управление DNS), щелкнув правой кнопкой мыши на
значке сервера и выбрав в контекстном меню пункт Properties (Свойства). По умол­
чанию список Name servers (Серверы имен) на вкладке Root Hiпts заполнен «дей­ствующими» DNS-серверами из Интернета.
Roo t hnts resofve queries for zones that do not exist оп the 1оса1 DNS
serve- . lhey are ony used tf furwarders l>.EDU
О. ROOT-SERVERS . NЕТ.
;
; f o rmerly NS. NASA.GOV
Е. ROOT-SERVERS. NЕТ.
3600000
3600000
360000 0
36000 00
360000 0
36000 00
36000 00
36000 00
3600000
3600000
IN NS А. ROOT-SERVERS . NET.
д 198.41.0.4
NS В. ROOT -SERVERS. NET.
д 192 . 228. 79. 201
NS С . ROOT-SERVERS .NЕТ.
д 192. ЗЗ.4.12
NS О. ROOT-SERVERS .NET.
д 126.8.10.90
NS Е . ROOT -SERVERS.NEТ.
А 192.203.230.10
Рис. 6.8. Список корневых подсказок в файле cache . dns

В единственной среде домена Active Directory это можно оставить в том виде, как
есть. DNS-cepвepы могут использовать эти ссылки для распознавания пространств
имен, основанных на Интернете, таких как Sybex . сот, когда клиент их запраши­
вает. В более крупных средах корневые подсказки на других серверах DNS можно
удалить и полагаться на поддержку одного сервера в преобразовании имен DNS из внешней среды. В сущности это мог бы быть кеширующий DNS-cepвep для внут­ренней структуры.
В то время как корневые подсказки управляют запросами, следующими вверх по
иерархической структуре DNS, делегирование управляет запросами, проходящими вниз. В рассматриваемом примере DNS-cepвepaм, которые управляют пространс­твом имен . сот, делегируется контроль над зарегистрированными поддоменами вроде Sybex . сот. Делегирование представляет собой просто список этих серверов.
Таким образом, сервер имен . сот отправляет список серверов имен DNS-cepвepy,
ищущему пространство имен Sybex . сот.
В среде Windows делегирование можно увидеть в действии с множеством доменов Active Directory. При наличии домена Active Directory по имени Bigfirт . сот вы имеете связанное с ним пространство имен DNS под названием Bigfirт. сот. Вы могли бы создать домен Active Directory по имени Ecoast . Bigfirт. сот. Вместо
того чтобы хранить все пространства имен DNS на DNS-cepвepe Bigfirт. сот, вы
можете делегировать пространство имен DNS под названием Ecoast . Bigfirт. сот другому DNS-cepвepy.
На рис. 6.9 такое делегирование демонстрируется в консоли управления
DNS. В DNS-cepвepe по имени осо 1 поддерживается зона прямого просмот­
ра Bigfirт. сот. Поддомен Ecoast, представленный значком с папкой серого
цвета с текстовым файлом поверх него, содержит только запись сервера имен для
ECl . Ecoast . Bigfirт. сот с его I Р-адресом.
Сервер пересылки — это еще один DNS-cepвep для обработки ответвленного за­
проса. Когда серверу не удается преобразовать имя DNS, он может переадресовать
запрос другому DNS-cepвepy, а не проходить по корневым подсказкам.
Во внуrренней среде DNS серверы пересылки могут применяться дЛЯ распознава­
ния других пространств имен. Например, DNS-cepвepy ECl . Ecoast . Bigfirm. com
необходимо распознавать серверы Bigfirm . com и другие пространстоа имен, по­
этому на вкладке Forwarders (Серверы пересылки) окна его свойств указан сервер
пересылки (рис. 6.10).
На рис. 6. 10 обратите внимание на флажок Use root hints if по forwarders are
availaЫe (Использовать корневые подсказки, если нет доступных серверов пересыл­ки). В более крупной среде его можно не отмечать, если необходимо централизовать DNS-запросы, основанные на Интернете. Кроме того, взгляните на текст, касаю­щийся серверов условной пересылки.
Серверы условной пересылки имеют собственный узел в дереве областей внутри
левой панели окна DNS Manager (Диспетчер DNS). Для управления распознава­
нием конкретного пространства имен сервер условной пересылки может направ­
лять запросы определенному серверу. На рис. 6. 1 1 видно, что сервер условной
пересылки был настроен для пространства имен Otherdomain . local. В резуль­
тате любые запросы к этому пространству имен будут передаваться DNS-cepвepy
OSOl . Otherdomain . local.
Серверы условной пересылки создаются путем щелчка правой кнопкой мыши
на папке Conditional Forwarder (Сервер условной пересылки) в консоли управления DNS и выбора в контекстном меню пункта New Conditional Forwarder (Новый сервер условной пересылки). Откроется диалоговое окно New Conditional Forwarder (Новыйсервер условной пересылки), которое предоставит вариант репликации настройки другим контроллерам домена в домене или лесе с использованием разделов каталога приложений Active Directory.
Переадресация также может применяться дЛЯ обработки запросов, основанных
на Интернете, вместо использования корневых подсказок.
Мы предпочитаем поступать так в небольших средах, обслуживаемых поставши­
ком Интернет-услуг посредством кабеля или цифровой абонентской линии (Digital
Subscriber Liпe — DSL). Эти поставщики Интернет-услуг имеют собственные DNS­
cepвepы, которые находятся в конфигурации маршрутизатора. Таким образом, ониуказаны как серверы пересылки во внутренних серверах DNS. Хотя корневые под­сказки и могут работать в такой среде, мы считаем прием с переадресацией более надежным. Вдобавок он ограничивает коммуникации внутреннего DNS-cepвepa за­данным внешним источником.
Интеграция с другими DNS-серверами может завершить конфигурирование
роли DNS. Один DNS-cepвep может получать запросы и затем отправлять их дру­
гим DNS-cepвepaм. После того, как DNS-cepвep получит ответ, он может кеширо­
вать информацию в течение определенного периода времени, который в Windows
Server 2012 R2 по умолчанию установлен равным одному часу. Такая конфигурация
называется сервером только для кеширования. Если сервер предназначен д.11я управле­ния пространством имен, вы должны добавить зоны.

Реализация зон для управления пространствами имен

Зона — это база данных д.11я пространства имен. В И нтернете имеется DNS­
cepвep, который управляет пространством имен Sybex . сот. Если вам необходим
1 Р-адрес для www . s уЬех . сот, то д.11я нахождения ответа этот DNS-cepвep будет
просматривать свою зону (базу данных). Таким образом, д.11 я управления пространс­
твами имен на серверах DNS можно создать зоны.
На серверах Wiпdows DNS существуют зоны четырех типов:
• стандартная основная зона;
• стандартная дополнительная зона;
• зона, интегрированная с Active Directory;
• зона-заглушка.

Зона-заглушка не управляет пространством имен и
больше похожа на сервер условной пересылки. Все типы
зон обсуждаются в последующих разделах.
стандартная основная зона
Серверы имен были спроектированы для централиза­
ции преобразования имен в сети. Первоначально DNS­
cepвep отвечал на запросы, основываясь на своем текс­
товом файле ноsтs. По существу это то, что в Microsoft
называют стандартной основной зоной. Стандартная ос­
новная зона представляет собой текстовый файл, в ко­
тором сервер поддерживает записи для заданного про­
странства имен. Это то, что характеризует реализацию
Windows DNS как стандартную. Характеристика основная
относится к репликации.
Во времена Windows NT существовал один ведущий
контроллер домена, называемый главным контроллером
домена (primary domain controller — РОС), который уп­
равлял всеми операциями записи в свою базу данных. Остальные операции управ­
лялись резервными контроллерами домена (backup domain controller — BDC), кото­рые представляли собой копии только для чтения. В терминах DNS основные зоны означают, что имеется только один хозяин, и им является данный сервер. Другие
DNS-cepвepы могут содержать лишь копии этой зоны, предназначенные только для
чтения; они являются дополнительными зонами.
Рис. б.12.
Создание НОВОЙ ЗОНЫ
Зона создается с помощью мастера новой зоны (New Zone Wizard), который
можно запустить, щелкнув правой кнопкой мыши на папке Forward Lookup Zones
(Зоны прямого просмотра) в диспетчере DNS и выбрав в контекстном меню пункт
New Zone (Новая зона), как показано на рис. 6.12.
Мастер новой зоны запросит перечисленную ниже информацию.
• Пространство имен или имя домена, такое как Primaryzone . local.
• Имя текстового файла, который по умолчанию имеет расширение . dns.
• Возможность динамического обновления DNS. Мы обсудим это в разделе
«Динамическое обновление DNS» далее в главе.
После создания зоны можно просмотреть содержимое текстового файла, кото­
рый хранится в папке c : windowssystem32dns (рис. 6.13). Созданные для при­
меров дополнительные записи CNAME и А находятся в конце файла.
Стандартная дополнительная зона
Стандартная дополнительная зона — это копия только для чтения стандартной
основной зоны или зоны, интегрированной с Active Directory. Репликация выполня­
ется посредством процесса переноса зоны, который конфигурируется через свойс­
тва зоны. На серверах Windows DNS стандартная настройка предусматривает раз­
решение переносов зоны только на зарегистрированные серверы имен этой зоны,
что можно видеть на вкладке Zone Transfers (Переносы зоны), представленной на
рис. 6.14.
Чтобы разрешить репликацию на сервер имен ECl . Ecoast . Bigfirm . com, его
необходимо добавить в список Name servers (Серверы имен) на вкладке Name Servers
(Серверы имен), как показано на рис. 6.15.
Теперь можно запустить мастер New Zone Wizard для создания стандартной до­
полнительной зоны на сервере ECl. Это потребует указания IР-адреса сервера-хо­зяина, у которого может запрашиваться перенос зоны. Он не обязательно должен
быть DNS-cepвepoм со стандартной основной зоной. Результатом будет успеш ный
перенос зоны на ECl (рис. 6.16).
Процесс переноса зоны не отличается особой сложностью. Сервер для основной
зоны отслеживает вносимые им изменения, назначая каждому из них серийный но­мер. Когда сервер для дополнительной зоны контактирует с сервером для основной
зоны, он проверяет этот серийный номер в записи Start of Authority (Начало зоны).
Если серийный номер на сервере для дополнительной зоны не совпадает, значит,
наступил момент для репликации изменений. Это просто текстовый способ заталки­вания информации в базу данных. Ранние версии DNS поддерживали репликацию
AXFR (все переносы зоны), которая означала, что на сервер для дополнительной
зоны реплицировалась вся зона целиком. В результате по линии передавался намно­го больший объем трафика. В Windows DNS поддерживается репликация IXFR (ин­крементные переносы зоны), при которой реплицируются только изменения. Кроме
того, в DNS поддерживается уведомление серверов для дополнительных зон, что со­кращает время ожидания для запуска репликации.

Зона, интегрированная с Active Directory
Зона, интегрированная с Active Directory, является преобладаюшей реализацией
серверов Windows DNS. Присугствие в ее названии Active Directory говорит о многом.
• Во-первых, записи DNS хранятся в базе данных Active Directory, а не в тексто­
вом файле.
• Во-вторых, зоны реплицируются всем другим контроллерам домена Active
Directory в домене, а не посредством процесса переноса зоны.
Поскольку в базе данных Active Directory применяется репликация с нескольки­
ми хозяевами, изменения могуг вноситься в зону DNS на любом контроллере доме­на, и они будуг реплицироваться на другие контроллеры домена. Благодаря интег­рации DNS с Active Directory, связка ролей DNS и контроллера домена становится
нормой. За дополнительными сведениями о процессе репликации обращайтесь в
главу 22.
Подобно стандартным зонам, зона, интегрированная с Active Directory, может
быть создана с помощью мастера New Zопе Wtzard. На экране Zone Туре (Тип зоны)мастера
На экране Active Directory Zone Replication Scope (Область действия репликации зоны Active Directory) мастера (рис. 6.1 на выбор предусмотрены четыре опции: науровне леса, на уровне домена, на уровне домена (совместимого с Windows 2000) и
хранение базы данных зоны в указанном специальном разделе каталога приложений
(последняя опция по умолчанию обычно недоступна, но в следующем абзаце мы
объясним, как сделать ее доступной). Первые две опции приводят к размешению
базы данных в автоматически созданном стандартном разделе каталога приложе­
ний: один для леса и один для домена, членом которого является контроллер доме­на. Местоположением, совместимым с Windows 2000, является раздел домена базыданных Active Directory, поэтому база данных зоны будет реплицироваться только контроллерам этого домена.
Если вы хотите создать специальные разделы каталога приложений, такие как
отображаемый в последней опции на рис. 6. 18, то вам придется воспользоваться
либо утилитой DNSCmd, либо командлетом Add-DNSServerDirectoryParti tion
в PowerShell. Оба средства встроены в Windows Server 201 2 R2 и предоставляют
возможность управления указанными типами специальных разделов. В сеансе
PowerShell с разрешениями администратора введите показанную ниже команду, что­бы создать новый раздел каталога приложений для упомянутой ранее зоны, интег­рированной с Active Directory. Имя раздела не обязательно должно совпадать с име­нем зоны; тем не менее, применение того же самого имени способствует лучшему пониманию конфигурации:
C : Usersadministrator . BIGFIRM>Add-DNSServerDirectoryPartition
-Name «adintegratedzone . local»
После того, как новый раздел создан, ему можно назначить зону, интегрирован­
ную с Active Directory (см. рис. 6.18).
Затем также с помощью PowerShell можно сконфигурировать другие контролле­
ры домена для поддержки зоны. Давайте предположим, что на сервере ECl, который является контроллером домена Ecoast . Bigfirm . com, необходимо добавить следу­ющие две зоны Active Directory:
+ зону adintegratedzone . local, которая помещена в собственный раздел ка­
талога приложений;
• зону обратного просмотра для подсети 192.168.0.0, которая помещена в общий
раздел леса.
Для начала добавьте сервер в список на вкладке Name Servers окна свойств жела­
емых зон подобно тому, как было показано на рис. 6.15 ранее в главе.
Затем запустите следующий командлет для вывода доступных разделов на серве­
ре ECl:
C : Usersadministrator . BIGFIRM>Get-DNSServerDirectoryPartition
В выводе можно заметить наличие четырех разделов каталога приложений.
Первый из них — это специальный раздел, созданный недавно, который сервер вовлек в совместное использование. Второй является разделом каталога приложенийдомена, который совместно используется всеми контроллерами домена, отличны­ми от Windows 2000, внутри домена Bigfirm. com. Третий раздел предназначен для домена Ecoast . Bigfirm. сот. Четвертый раздел ориентирован на все контроллеры доменов в рамках леса доменов. Сервер ECl уже вовлечен в совместное использова­ние этих двух разделов.
Использование зон-заглушек для интеграции с другими DNS-серверами
Зона-заглушка — это еще одно усовершенствование, впервые появившееся в
Windows Seiver 2003. В версии Windows Seiver 2012 R2 концепции и функциональ­ность зоны-заглушки не изменились, и по суmеству она представляет собой до­полнительный метод для интеграции с другими DNS-серверами. В зоне-заглушке перечислены только серверы имен для заданного пространства имен. Она не имеет никакого контроля над зоной, так что она указывает только на то, какой сервер мог бы поддерживать преобразование имен для пространства имен. Подобно серверам условной пересылки, зона-заглушка предоставляет ответвленное взаимодействие с авторитетным DNS-cepвepoм. Эти зоны также могут реплицироваться между конт­
роллерами домена.
Мастер New Zone Wiz.ard настраивает зону-заглушку со следующими параметрами:
• тип зоны Stub (Зона-заглушка);
• необязательное хранение в Active Directory с заданным разделом каталога при­ложений;
• пространство имен зоны, такое как Арех. сот;
• DNS-cepвep, который поддерживает это пространство имен.
После создания зоны-заглушки можно просмотреть ее содержимое (рис. 6. 19).
В нем присутствует запись Start of Authority для пространства имен, запись Nam
Seiver (Сервер имен) для пространства имен и запись Host (Хост) для сервера имен.
Использование зон обратного просмотра для увеличения безопасности
Вы можете заметить, что созданные зоны находятся в папке Forward Lookup Zones
(Зоны прямого просмотра) внутри консоли управления DNS. При прямом просмот­
ре клиент предоставляет полное имя домена (FQDN), а DNS-cepвep возвращает IР­
адрес. При обратном просмотре делается противоположное: клиент предоставляет
IР-адрес, а DNS-cepвep возвращает имя FQDN.

Вас может интересовать, мя чего это может потребоваться? Основные причины
связаны с безопасностью. Представьте себе взломшика, который настроил вредонос­
ную службу мя прослушивания DNS-запросов к именам FQDN, начинаюшимся с
www . , внутри сети. Когда эта служба получает запрос, она автоматически отправляет
клиенту поддельный ответ с 1 Р-адресом веб-сервера взлом шика, который загрузит
черви, вирусы, «троянские кони» еще до того, как пользователь узнает, что про­
изошло. Если веб-браузер можно было бы сконфигурировать на выполнение обрат­ного просмотра для предоставленного IР-адреса, то он мог бы сравнивать результат
с запрошенным именем и в случае несовпадения не подключаться к веб-серверу.
В качестве реального примера работы такого обратного просмотра при преобра­
зовании имен можно привести службу SMTP в Windows. Эта служба позволяет вы­
полнять обратный просмотр для подключений к серверу. Серверы SMTP предостав­
ляют при взаимодействии свои доменные имена, а при подключении указывается адрес TCP/IP. Затем может быть выполнен обратный просмотр для проверки, соот­ветствуют ли имена адресам, как должно быть.
Команда NsLookup иллюстрирует использование обратного просмотра. Как по­
казано ниже, эта команда запушена в интерактивном режиме для сервера, который
не имеет записи указателя (PTR) в зоне обратного просмотра. Обратите внимание,
что стандартный сервер обозначен как UnKnown. В этом случае запросы DNS могут быть ненадежными.
C : UsersAdministrator . BFl>Nslookup
De fault Server : UnKnown
Address : 1 92 . 1 6 8 . 0 . 1 0
Если в зоне обратного просмотра создана запись PTR, то вывод команды
NsLookup выглядит гораздо лучше. Легко заметить, что в выводе присутствует имя
сервера:
C : UsersAdministrator . BFl>Nslookup
Default Server: BFl . bigfi rm . com
Address : 1 92 . 1 6 8 . 0 . 1 0
Для корректного конфигурирования зон обратного просмотра внутри сети не­
обходимо понимать, как работает обратное преобразование. Адрес 1Pv4 представля­
ется в десятичной точечной нотаuии с помощью четырех октетов — x.y.w.z. Адрес
1 Pv6 похож, но в нем применяются шестнадuатеричные числа, и их намного боль­ше. В обоих случаях проuесс обратного преобразования один и тот же. DNS-cepвep,получающий запрос, изменяет порядок следования числе в IР-адресе. Таким об­разом, запрос имени FQDN мя IР-адреса x.y.w.z становится z.w.y.x, а в конuе до­бавляется . in-addr . arpa. Затем DNS-cepвep пытается преобразовать FQDN-имя z . w. у . х. in-addr . arpa подобно обычному имени FQDN. Преобразование начина­ется с домена верхнего уровня . arpa и проходит вниз к серверам имен in-addr . ,
при этом каждое десятичное значение становится поддоменом пространства имен справа от него. В небольших средах, которые включают только одну подсеть, эта подсеть мо­жет быть представлена единственной зоной. В рассматриваемом примере подсеть 192. 1 68.0.0 является одной зоной (рис. 6.20). При создании зоны обратного про­смотра мастер New Zone Wuard запрашивает имя подсети.
В более крупных средах, имеющих несколько подсетей, потребуется создать зону
для октета с наибольшим приоритетом, а октеты с меньшими приоритетами долж­ны быть представлены как поддомены или делегированные поддомены. Например,
если крупная организация использует схему частной I Р-адресации 10.0.0.0, то в ней можно создать зону обратного просмотра для доменного имени 1 О . in-addr . arpa.
Когда происходят динамические обновления, поддомены будут автоматичес­
ки создаваться для следующего октета от l до 254, а записи PTR будут заполняться
подпапками структуры. В определенный момент поддомены можно делегировать
другому множеству DNS-cepвepoв, вроде контроJUiеров домена, находящихся внутри сайта, который содержит эти подсети. Затем записи PTR можно зарегистрировать в
соответствующей зоне, представляющей подсеть.
На рис. 6.21 видно, что на сервере BFl была создана зона 10 . in-addr . arpa.
Если нужно, чтобы подсети 10. 1 1.0.0 управлялись другим сервером, понадобится де­легировать 1 1 поддоменов. Это было делегировано серверу ECl. Внутри него дейс­твительная подсеть 10. 1 1 .12.0 также представлена как делегированный поддомен.

На вкладJСе Advanced (Дополнительно) окна свойств DNS-cepвepa имеется несколь­
ко отмеченных флажком, два из которых приведены ниже:
• ЕnаЫе round roЬin (Включить циклический перебор)
• ЕnаЫе netmask ordering ( Включить упорядочение сетевых масок)
Циклический перебор (round rоЬiп). Это прием балансировки сетевой нагрузки (network
load balancing — N LB) «для бедняков». Если вы зарегистрировали несколько записей
хостов с одним и тем же именем, но разными I Р-адресами, то DNS-cepвep будет от­
вечать последовательно с отличающимся I Р-адресом для каждого запроса, начиная с самого меньшего IР-адреса. Хотя такой прием не распределяет клиентскую нагруз­ку равномерно или интеллектуально по доступным хостам, он все же предоставляет возможность некоторой балансировки между серверами.
Упорядочение сеrевых масок (пetmask ordering). Подобно циклическому перебору, при упорядочении сетевых масок используется множество записей хостов с одинаковым именем, но разными IР-адресами. Вместо выбора случайным образом выбирается за­пись, которая определена математически как более близкая. Это делается путем срав­нения подсетей. Такой прием хорош при наличии географически разделенных хостов и клиенту необходимо взаимодействовать с хостом, находящимся в его сети. Таким
образом, когда примен яютс я географически разнесенные серверы, вы должны решить, какой метод лучше избрать. Упорядочение сетевых масок сохранит время отклика на минимальном уровне из-за более короткого маршрута. Циклический перебор более равномерно распределит нагрузку, если клиенты сконцентрированы в одном месте.
Однако эти процессы доступны в случае применения Wmdows Server 20 l 2 R2 с
Windows 7 или Windows 8. Стек TCP/IP для I Pv6 и I Pv4, «когда возможно», будет
выполнять процесс похожий на упорядочение сетевых масок, который называется стандартным выбором адресов. Это значит, что он получает I Р-адреса от DNS-cepвepa и самостоятельно решает, какой из них лучше использовать.
Подобно большинству конфигураций, это можно переопределить с помощью объек­та групповой политики, указанного в следующем параметре реестра:
Hkey_Local_MachineSystemCurrentControlSet
ServicesTcpip ParametersOverrideDefaultAddressSelection
Значение 1 отключает стандартный выбор и разрешает произвольный выбор цикли­ческих серверов NLB.
Увидеть эффект от всего этого можно при использовании циклического перебора
географически ра:щеленных серверов. Например, среда с сайтом для восстановления после аварий может предлагать два сервера, которые выполняют одну и ту же службу,но расположены на разных сайтах. В таком случае для загрузки данных доступны два сервера FГР. DNS-cepвep сконфигурирован на предоставление двух I Р-адресов для одного имени ftp . Bigfirm. сот. Циклический перебор обеспечит последователь­ную обработку записей. Даже когда один из серверов FГР прекращает функциони­рование из-за аварийной ситуации, у клиентов по-прежнему сохранится подключае­мость к ftp. Bigf irm. сот. (Время от времени будет выбираться IР-адрес нерабочегосервера, но после повторного подключения поток данных возобновится.)Тем не менее, если включено упорядочение сетевых масок или стандартный выбор адресов, то клиенты могут никогда не получить IР-адрес функционирующего серве­ра FГР. Выбор будет делать либо DNS-cepвep, либо клиент. Таким образом, этот сце­нарий наталкивает на применение проверенного временем правила: «тестировать,тестировать, тестировать». Проверяйте, какие серверы используются в нормальном сценарии, и что происходит в аварийной ситуации.

Типы записей

Теперь, когда базы данных настроены для извлечения информаuии клиента­
ми, необходимо добавить в них записи. Как упоминалось ранее, Dynamic DNS
(DDNS) — это проuесс, который позволяет DNS-клиентам регистрировать свои
имена хостов в назначенном пространстве имен, таком как DHCP, и это приводит
к добавлению записей для компьютеров Windows внутри среды. Тем не менее, не­
которые записи по-прежнему придется добавлять вручную, равно как и проверять
корректность записей, созданных динамически. Для зоны DNS доступно свыше
25 типов записей. В этом разделе мы рассмотрим наиболее распространенные типы записей в рамках реализации Windows DNS.
Записи хостов и указателей
Записи хостов (А) и указателей (PTR) наиболее распространены в зонах прямого
просмотра и зонах обратного просмотра, соответственно. В записи А указывается
имя хоста компьютера и возвращается !Р-адрес. В записи PTR указывается !Р-адрес
и возвращается имя FQDN. Эти записи может потребоваться создать дnя компьюте­ров, не имеющих доступного протокола обномения DDNS.
записи псевдонимов
Записи псевдонимов (CNAME) создаются для определения второго имени ком­
пьютера. В записи CNAME указывается имя и возвращается имя FQDN, назначен­
ное компьютеру. Эти записи полезны в случае замены сервера с опубликованным
именем, которое клиенты применяют для доступа к приложениям или службам. Безнеобходимости в переконфигурировании после замены клиенты по-прежнему будут иметь доступ через псевдоним.
записи обмена почтой
Записи обмена почтой (mail exchanger — МХ) предназначены для коммуникаций
по протоколу SMTP. Почтовые серверы запрашивают записи МХ пля взаимодейс­
твия с получающим сервером SMTP в данном пространстве имен. Обычно записи
МХ настраиваются во внешней зоне DNS. Тем не менее, для специализированных
приложений они могут потребоваться и внутренне. Записи МХ нужно имя FQDN
сервера SMTP и значение приоритета.
Приоритет помогает определить, с какой записью МХ контактировать сначала,
а с какой впоследствии, если записей несколько. Чем меньше значение, тем выше
приоритет. Запомните это как «приоритет номер один».
Предположим, что у вас есть основной SМТР-сервер и SМТР-сервер типа смарт­
хост (smart host), предназначенный для поддержки получения электронной почты, когда основной сервер недоступен. Вам необходимо создать записи МХ для обоих серверов. Основной SМТР-сервер должен иметь меньшее значение приоритета, чем смарт-хост, например 10 и 20, соответственно. Когда основной SМТР-сервер недо­ступен, взаимодействие производится со смарт-хостом.
Записи служб
Записи служб (SRV) являются «знатным шаманом» для реализаuий Windows
DNS. Без записей SRV рабочие станции и серверы не смогли бы находить контрол­
леры доменов.

Сами по себе записи SRV имеют дело только с пятью значениями.
• Имя службы. Стандартное значение, обычно предваренное символом подчер­
кивания, такое как _gc или _ ladp. Оно является эквивалентом имени хоста и
будет присоединено к имени FQDN службы.
• Имя FQDN сервера. Сервер, который предоставляет службу.
• Порт. Порт ТСР или UDP, на котором доступна служба. Протокол обозначает­
ся своим зарегистрированным именем, например, _ ТСР.
• Приоритет. Работает точно так же, как в записях МХ — имеет «приоритет но­
мер один».
• Вес. Используется для разрешения конфликтов с приоритетами. Оставьте его
равным О, если вас это не заботит.
Вы обнаружите изобилие записей SRV в зоне Windows DNS, которая поддерживает
Active Directory. Они находятся в папках поддоменов, поскольку именам служб назна­чаются разные имена FQDN. Запрашиваемая служба описывается с помощью имени
FQDN наподобие _gс . tcp .Ьigfirrn. corn. Записи SRУ можно видеть на рис.
Записи начала зон
Запись начала зоны (Start of Authority — SOA) в единственном экземпляре при­
сутствует в каждой зоне. Она определяет информацию о том, какой DNS-cepвep уп­
равляет этой зоной, а также параметры, касающиеся того, каким образом трактовать
распознанные записи. Запись SOA содержит несколько значений, которые не долж­ны изменяться при редактировании записи. Редактирование производится на вклад­ке Start of Authority (SOA) (Запись начала зоны (SOA)) в окне свойств зоны (рис. 6.23).
Ниже описаны поля, находящиеся на вкладке Start of Authority (SOA).
• Serial Number (Серийный номер). Номер ревизии файла зоны. На самом деле
он имеет значение для стандартных основных зон, т.к. репликация Active
Directory поддерживает собственный серийный номер. Дополнительные зоны
могут сравнивать с ним свои номера, чтобы выяснять, актуальна ли информа­
ция в них. Если информация не актуальна, необходим перенос зоны.

• Primary Server (Основной сервер). Сервер, на котором зона была изначально
настроена. Если вы хотите изменить способ обновления зон в среде посредс­
твом репликации, можете переключать основной сервер на дополнительный
сервер и наоборот.
• ResponsiЫe Person (Ответственное лицо). Предположительно это должен быть
адрес электронной почты лица, администрирующего зону. Обратите внимание,
что символ @ заменяется точкой ( . ). Если хотите кого-то по-настоящему свес­
ти с ума, можете указать здесь его электронный адрес.
• Refresh lnterval (Интервал обновления). Период времени, в течение которого
дополнительный сервер может ожидать до того, как начнет попытки прове­
рить наличие изменений на основном сервере. В этот момент он сравнивает
серийный номер из записи SOA со своим номером. По умолчанию интервал
обновления составляет 1 5 минут. Внутри самой записи это значение указыва­
ется в секундах.
• Retry lnterval (Интервал повтора). Период времени, в течение которого допол­
нительный сервер ожидает до того, как повторить попытку после отказавшего
переноса зоны. По умолчанию интервал повтора составляет 10 минут и также
внутри самой записи указывается в секундах.
• Expires After (Истекает после). Период времени, в течение которого дополни­
тельный сервер может продолжать отвечать на запросы в этой зоне после того,
как перенос зоны был выполнен. По умолчанию составляет один день. Внутри
самой записи это значение также указывается в секундах и равно 86 400.
• Minimum (Detault) TTL (Минимальное (стандартное) время ТТL). Период време­
ни, в течение которого запись должна находиться в кеше или, другими слова­
ми, значение времени существования (Time То Live — ТТL). По умолчанию
составляет один час, или 3 600 секунд.

записи серверов имен
Записи серверов имен (NS) перечисляют серверы, которые могут отвечать на за­
просы для этой зоны. В зоне должна присутствовать, по меньшей мере, одна такаязапись. Подобно записи SOA, запись NS модифицируется на вкладке Name Servers(Серверы имен) окна свойств зоны, которая была показана ранее на рис. 6.15.Единственным обязательным значением в записи NS является имя FQDN сервера.В нижней части вкладке Name Servers вы заметите короткое примечание, указываю­щее на то, что 1 Р-адрес представляет собой извлеченное значение.

Управление клиентами DNS и преобразованием имен

Вы можете прийти к выводу, что каждый компьютер является клиентом DNS.
Служба DNS — это жизненно важный компонент сети, даже если Active Directory не входит в ее состав. Вдобавок он представляет собой единственный метод для пере­хода на ваши избранные веб-сайты в И нтернете, такие как www . Sybex . сот.
В операционных системах Windows есть две области, касающиеся клиентов DNS:
преобразование имен хостов и регистрация имен хостов и I Р-адресов через динами­
ческие обновления DNS.
Преобразование имен хостов
Процесс преобразования имен на компьютере Windows делится на две части.
Данный процесс настолько важен, что мы будет называть его «жизненным циклом».
Одной частью, которая близка к исчезновению, является NetBIOS, в друтой — DNS.
(Вы могли бы назвать ее процессом имени хоста, но большинство администраторов
называют его DNS.) Этот цикл состоит из набора шагов, которые компьютер дол­
жен предпринять для преобразования заданного имени (рис. 6.24).
Преобразование имен NetBios,__-+- —
Ретрансляция
Поиск в DNS
Поиск вWINS
Файл HOSTS
Файл LMHOSТS
Преобразование (имен хостов) DNS

Процесс NetBIOS предусматривает выполнение следующих шагов.
1 . Ретрансляция имени в сети и ожидание, ответит ли кто.
2. Поиск имени в WNS.
3. Поиск имени в файле LMHOSTS. Это еще один текстовый файл, аналогич­
ный файлу ноsтs, который находится в том же самом месте: с : windows
system32 drivers etc. Вместо имен хостов в нем перечислены имена
NetBIOS.
Порядок следования первых двух шагов можно изменять, особенно через сервер
DHCP. Шаг с ретрансляuией или шаг с поиском в WINS может быть опущен. По
умолчанию в Windows Server 2012 R2 сначала производится поиск имени посред­
ством WINS, а затем с помощью ретрансляции. Однако поиск в файле LMHOSTS
всегда выполняется последним.
Список шагов для процесса DNS короче.
1. Поиск имени в файле HOSTS.
2. Поиск имени в DNS.
Порядок следования шагов в процессе DNS настройке не поддается, но можно
изменить поведение просмотра DNS. С тем, что поиск имени сначала производится
в файле ноsтs, связаны как положительные, так и отрицательные моменты. Если
получить доступ к DNS-cepвepy невозможно или требуется переадресовать преобра­
зование имени в другое место, то редактирование файла ноsтs дает замечательные
результаты. Если же файл ноsтs содержит устаревшие или вредоносные записи, то
устранение неполадок DNS может оказаться затруднительным.
Процесс преобразования имен циркулирует по обеим частям до тех пор, пока не
будет получен IР-адрес. Кроме того, имеется выбор с чего начинать — NetBIOS или
DNS. В основном это зависит от приложения. Старые унаследованные приложения
Windows рассматривают имя как относящееся к NetBIOS. Приложения, основанные
на TCP/IP, считают его именем хоста. Это влияет на способ преобразования имен и является частью операционных систем Windows.
Примерами могут служить команды net view и ping.
Комама net view существует со времен LAN Manager, когда все полагалось uе­
ликом на NetBIOS. Если вы попытаетесь подключиться к серверу с применением
указанной команды, то увидите, что имя сервера заносится в кеш имен NetBIOS.
Содержимое этого кеша можно отобразить с помощью команды nЬtstat — с . Для
очистки кеша предназначена команда nbtstat -R.
rem Просмотр кеша имен NetBios
С: Users Adrnini strator . BFl >nhtstat -с
Local Area Connection :
Node IpAddress : [ 1 92 . 1 68 . 0 . 1 0 ] Scope Id: [ ]
No names in cache
rem Доступ к общим ресурсам на сервере Ьfscl
С: UsersAdrninistra�or . BFl>net view Ьfscl
Shared resources at \bfscl
Share name Туре Used as Comment
NETLOGON Disk Logon server share
SALES Disk
SYSVOL Disk Logon server share
Users Disk
The command completed success fully .
rem Повторный просмос>р кеша имен NetBios
С : UsersAdminis trator. BFl>nЬtstat -с
Local Area Connection :
Node IpAddress : ( 1 92 . 1 68 . 0 . 10 ] Scope I d : [ ]
NetBIOS Remote Cache Name ТаЫе
Name Туре
Host Address
BFSCl UNIQUE 1 92 . 1 68 . 0 . 1 1
ГЛАВА 6
Life [ sec]
6 0 0
При пинговании сервера используется проuесс DNS, т.к. команда ping являет­
ся утилитой ТСР /1 Р. Вы можете убедиться, что эта утилита распознает сервер че­
рез DNS, отобразив содержимое кеша DNS с применением команды ipconfig
/di splaydns. Кеш DNS очищается с помощью команды ipconfig / flushdns.
rem Очистка кеша DNS
С : Users Administrator . BFl>ipconfiq /flushdns
Windows I P Configuration
Success fully flushed the DNS Resolver Cache .
С : Users Administrator. BFl>pin9 BFSCl
Pinging BFSCl . bigfirm . com [ 1 92 . 1 68 . 0 . 1 1 ] with 32 bytes o f data :
Reply from 1 92 . 1 68 . 0 . 1 1 : bytes=32 time Reply from 192 . 1 68 . 0 . 1 1 : bytes=32 time Reply from 1 92 . 1 68 . 0 . 1 1 : bytes=32 time< lms TTL=128
Reply from 1 92 . 1 68 . 0 . 1 1 : bytes=32 timeipconfiq /displaydns
Nindows I P Con figuration
BFSCl
Record Name .
Record Туре .
Time То Live
Data Length .
Section . . .
А ( Host ) Record .
BFSCl . bigfirm . com
1
1 1 8 5
4
Answer
1 92 . 1 68 . 0 . 1 1
Такие сведения помогают решить, каким образом поддерживать проuесс преоб­
разования имен DNS для клиентов и устранить либо поддерживать (при необходи­
мости) имена NetBIOS. Проuесс NetBJOS потребляет излишние uиклы ЦП. В слу­
чае корректной конфигурации сервера и клиентов DNS поддержку преобразования
имен NetBIOS можно отключить или, по крайней мере, свести к минимуму.
Конфигурирование клиентов
Конфигураuии DNS и NetBIOS можно просмотреть в окне свойств протокола IP
для сетевого подключения. Конфигурация NetBIOS находится на вкладке WINS. На
рис. 6.25 показана вкладка WINS со стандартными настройками.

По умолчанию включен поиск в файле LMHOSTS и выбрано использование на­
строек NetBTOS из сервера DHCP. По умолчанию файл LMHOSTS пуст. Было бы не­
плохо отключить поиск в этом файле, поскольку вредоносное ПО могло в прошлом
занести в него данные.
Настройки NetBIOS получаются от сервера DHCP. Области видимости сервера
DHCP имеют опцию под названием NBT Node Туре (046) (Тип узла NBT (046)). Эта
настройка предписывает первые два шага проuесса NetBIOS в жизненном uикле.
Четыре опuии задаются десятичным значением:
• только ретрансляция: «Ь-узел», 1
• только обращение к WINS: «р-узел», 2
• сначала ретрансляция, а затем обращение к WINS: «m-узел», 4
• обращение к WINS, а затем ретрансляция: «h-узел», 8
Н-узел лучше всего подходит для сети, полагающейся на NetВIOS, т.к. он сокра­
щает объем обмена в среде, поддерживающей WINS. При отсутствии доступных сер­
веров WINS компьютер может, по крайней мере, получить какой-то ответ в подсети,
например, дома или в рабочей группе. Если сервер DHCP не сконфигурирован с этим значением, применяется стандартная конфигурация, установленная в ОС. В Windows Server 2012 R2 по умолчанию используется h-узел, т.е. rибридный (hybrid) режим.
Дrtя сред Active Directory лучше отключать NetBIOS, поскольку это сокращает объ­
ем дополнительного обмена и количество процессов. Кроме тоrо, это помогает снизить
угрозы безопасности со стороны ботов, которые ищут в сетях компьютеры с целью
атаки с применением данной системы имен. Однако прежде чем отключать NetBIOS,
удостоверьтесь в отсутствии слабых мест в системе преобразования имен DNS.
Конфигурация клиента DNS находится на вкладке DNS окна свойств сети, по­
казанной на рис. 6.26. Вполне очевидно, что обязательным является IР-адрес DNS­ cepвepa. Подключение должно осуществляться к ближайшему серверу, как правило,
на контроллере домена внутри локального сайта. Рекомендуется указать также до­полнительный DNS-cepвep.
Advanced TCP/IP Settings

Средняя часть вкладки DNS имеет отношение к неполным именам. Это имя хос­
та без его «второго имени», суффикса DNS (такого как BFSCl, используемого ра­
нее в примере команды ping). DNS-cepвepy необходимо имя FQDN, поэтому пе­
ред отправкой запроса клиент DNS добавляет суффиксы DNS, т.е. «второе имя».
Основной суффикс DNS отображается на странице System (Система) панели уп­
равления, в области Computer Name (Имя компьютера). Он управляется автомати­
чески ОС, когда компьютер присоединяется к домену, поэтому заботиться об этом
суффиксе не придется. Дополнительные суффиксы могут понадобиться в крупных
средах, но для сред с одним доменом стандартных настроек вполне достаточно.
Добавлять суффикс DNS подключения нужно только в редких случаях.
Все это становится спорным в случае регулярного применения имен FQDN.
Используйте имена FQDN серверов при конфигурировании приложений, папок
или переадресации папок, равно как при написании сценариев, которые подклю­
чают сетевые диски. Уловили смысл? Вдобавок применение имен FQDN обходит
процесс NetBIOS. Приложения могут определить разницу между именами NetBIOS
и FQDN и прибегнуть к DNS, когда они распознают FQDN.

динамическое обновление DNS
Чтобы сделать процесс преобразования имен DNS надежным, понадобится пе­
речислить все компьютеры в зонах DNS. В прошлом система DNS требовала от
системных администраторов работы в полную смену, т.к. нужно было вводить пос­тоянно растущее количество записей для их сети. Для сокращения объема работы системных администраторов в Microsoft при создании ОС Windows NT нашли ди­намическое решение через WINS и затем перешли на DNS, когда стал доступным протокол обновлений Dynamic DNS (DDNS). Сам процесс довольно прост.
1. Клиент запрашивает запись SOA мя пространства имен с основным суффик­
сом DNS. Это сообщит, может ли сервер принимать DDNS. То же самое дела­
ется для зоны обратного просмотра, с которой связан 1 Р-адрес сервера.
2. Клиент отправляет запрос DDNS этому серверу.
В записях Start of Authority стандартных зон указан основной сервер. В зонах,
интегрированных с Active Directory, контроллер домена, получающий запрос, моди­
фицирует запись SOA с таким именем. Поскольку он может изменять содержимое
базы данных Active Directory, нет нужды выискивать контроллер домена, находя­
шийся где-то в другом месте. Если процесс обновления терпит неудачу, производит­ся поиск других серверов имен для выполнения обновлений.
На вкладке DNS с протоколом обновлений DDNS связаны два флажка в самом
низу (см. рис. 6.26). Имеется возможность зарегистрировать имя с основным суффик­сом DNS или с суффиксом подключения. Второй флажок по умолчанию не отмечен.
Странно то, что служба клиента DNS не выполняет обновления DDNS. Это де­
лает служба клиента DHCP. Это напоминает нам богатый событиями день, когда
один из нас отключил службу клиента DHCP на контроллере домена. Он наивно
полагал, что эта служба не нужна, т.к. имеется статический IР-адрес. Как уже упо­миналось, �процесс DDNS используется контроллерами домена с целью предостав­ления записей SRV для Active Directory. В конечном итоге клиенты не смогли найти контроллер домена, т.к. для него не было никаких записей SRY. К счастью, все это происходило в испытательной среде.
Существуют еше два места, где производится управление процессом DDNS: зона
для пространства имен и сервер DHCP.
Зона DNS может быть включена для обновлений DDNS в мастере New Zone
Wizard или же путем изменения свойств зоны. На рис. 6.27 показаны опции для об­новлений DDNS — только безопасные, безопасные и небезопасные, а также пол­
ное отключение обновлений. Безопасные динамические обновления означают, что до их выполнения клиент DNS проходит аутентификацию на контроллере домена. Небезопасные динамические обновления означают, что они принимаются без аутен­тификации. Учитывая название, вы легко можете предположить, что злоумышлен­ники способны воспользоваться этой опцией. В случае отключения никакие обнов­
ления DDNS поступать не будут.
Сервер DHCP также может участвовать в процессе DDNS. В самых ранних вер­
сиях Windows Server было много клиентов Windows, которые не обладали возмож­
ностями DDNS. Для решения этой проблемы сервер DHCP идентифицирует такие
ОС и выполняет мя них обновления. Кроме того, сервер DHCP может выполнять
обновления по запросу. На рис. 6.28 приведена вкладка DNS окна свойств 1 Pv4 для сервера DHCP.
Здесь показаны стандартные настройки, которые редко изменяются. В сущности,
сервер DHCP не выполняет никаких обновлений, поскольку клиенты делают это
самостоятельно. Сервер DHCP производит очистку, когда истекает срок аренды.
Защита имен, включаемая за счет отметки флажка в окне, открывающемся по щелч­ку на кнопке Configure (Конфигурировать) в области Name Protectioп (Защита имен),предотврашает обновление сервером DHCP существуюшей записи DNS.

Система DNS в Active Directorv

В Microsoft настолько тесно интегрировали DNS и Active Directory, что обсуж­
дать их по отдельности довольно трудно. Во время создания среды Active Directory с Windows Server 2012 R2 проuесс установки Active Directory автоматически конфигу­рирует DNS при добавлении роли. Это освобождает спеuиалистов по 1Т от ручной настройки DNS.
В последующих разделах мы раскроем способ, которым Active Directory конфиrу­
рирует систему DNS и применяет ее для поддержки клиентов. За дополнительными
сведениями о терминах и конuепuиях Active Directory обращайтесь в главу 7.

Автоматическое конфигурирование DNS

ОС Windows Server 2012 R2 предлагает два способа установки службы DNS: до­
бавление роли DNS самой по себе (как было показано ранее для автономной кон­
фигурации, не присоединенной к домену) или добавление роли Active Directory
Domain Services (Службы домена Active Directory). В случае выбора второго спо­
соба вы должны запустить мастер установки служб домена Active Directory (Active
Diгectory Domain Services lnstalation Wizard), который проведет ряд настроек для
роли Active Directory Domain Services, включая автоматическое конфигурирование
и интеграцию с ролью DNS. В главе 7 процесс установки Active Directory будет рас­
смотрен во всех деталях, а здесь мы лишь посмотрим, что произоЙдет с ролью DNS.
Первым делом вы должны понять предварительные условия, которые должны
быть удовлетворены для проведения установки Active Directory. Будущему конт­
роллеру домена необходима возможность подключения к существующей структуре
Active Directory DNS. В противном случае нельзя будет подключиться к контрол­
лерам домена и получить нужную информацию. Таким образом, в настройках IР­
адресов должен быть указан DNS-cepвep внутри среды Active Directory, желательно
DNS-cepвep корня леса или DNS-cepвep в том же самом домене, к которому пла­
нируется присоединение. Единственным исключением является ситуация, когда со­здается самый первый контроJVIер домена в среде Active Directory. В этот момент нет
никакой структуры Active Directory DNS, на которую можно было бы указывать.
Во время выполнения мастера Active Directory Domain Services конфигурируется
новый контроллер домена. В зависимости от опций, выбранных в мастере, может
быть создан новый контроллер домена. В любом случае служба DNS и соответству­
ющие настройки конфигурируются автоматически. В среду вносятся описанные да­лее изменения.
Создание разделов каталога приложений
Разделы каталога приложений — это граниuы внутри базы дан ных Active
Directory, которые создаются для совместного использования зон DNS разными до­
менами при создании нового домена или леса.
Раздел Doma inDNSZones . doma in . name создается для контроллеров домена
внутри домена. Раздел ForestDNSZones . domain . name создается для совместного
использования контроллерами домена в рамках леса Active Directory.
Если вы снова взглянете на рис. 6.9, то заметите, что поддомен msdcs .
Ьigfirm . com делегирован подобно Ecoast. Он делегирован на тот же самый конт­
роллер домена, в рассматриваемом случае это DCOl . Bigfirm. com.
Зона _msdcs . Bigfirm . com создается в разделе ForestDNSZone . Bigfirm . com
каталога приложений. Это позволяет данной порции пространства имен реплициро­ваться на все домены внутри леса.
После создания дополнительных контроллеров доменов они автоматически по­
являются в этих разделах каталога приложений.
Добавление сервера пересылки
Сервер пересылки можно добавить, просмотреть и сконфигурировать на вкладке
Forwarders (Серверы пересылки) окна свойств DNS-cepвepa. Обычно это будет IР­
адрес исходного DNS-cepвepa, которым пользовался данный сервер.
Изменение /Р -адреса
Новый контроллер домена, созданный мастером Active Directory Domain Services
Wizard, также является новым DNS-cepвepoм. Адрес основного DNS-cepвepa кон­
фигурируется на I Р-адреса обратной связи ::1 (для 1Pv6) и 127.0.0. 1 (для 1Pv4).
делегирование поддомена
Дочерний домен имеет имя, являющееся поддоменом внутри существующе­
го пространства имен домена. Например, Ecoast . Bigfirrn . corn — это поддомен
в пространстве имен Bigfirrn . corn. В результате работы мастера Active Directory
Domain Services Wizard пространство имен нового домена будет поддерживаться в
новом контроллере домена в виде делегированного поддомена.
В родительском домене поддомен вроде Ecoast . Bigfirrn. corn делегируется но­
вому контроллеру домена. Делегирование свяжет родительский и дочерний домены дпя преобразования имен. Это иллюстрировалось ранее на рис. 6.9.
дополнительные рекомендации по конфигурированию
После создания контроллера домена мы рекомендуем внести в настройки DNS
перечисленные ниже изменения.
1 . В свойствах ТСР /1 Pv4 сетевого адаптера измените основной DNS-cepвep на 1 Р­
адрес основного сетевого подключения. Например, если IР-адресом сервера яв­
ляется 192.168.0. l, его понадобится указать в качестве основного DNS-cepвepa.
При поиске и устранении неполадок в DNS с помощью утилиты NsLookup ад­
рес обратной связи ( 1 27.0.0. 1) указывается как «неавторитетный». Мы нахо­
дим результаты применения адреса обратной связи несколько ненадежными,
поэтому лучше придерживаться основного I Р-адреса.
2. Создайте зоны обратного просмотра в разделе ForestDNSZones . dornain . name каталога приложений.Зону обратного просмотра для подсетей может потребоваться совместно ис­пользовать в контроллерах различных доменов.
3. Создайте зону-заглушку для новых деревьев доменов на корневом DNS­
cepвepe.
Дерево домена имеет имя, отличающееся от имени корневого DNS-cepвepa.
Поскольку запись об исходном DNS-cepвepe указана как сервер пересылки,
подобно поднятиям других контроллеров домена, этот DNS-cepвep может
взаимодействовать с остальной структурой Active Directory DNS. Тем не ме­
нее, для остальной структуры Active Directory DNS никакого автоматического
конфигурирования для преобразования имен в новом пространстве имен не
предусмотрено. Например, нам придется настроить сервер условной пересыл­
ки или зону-заглушку, чтобы нацелить DNS-cepвepы на новый контроллер до­
мена для Арех. сот. На рис. 6. 19 демонстрируется применение зоны-заглушки
для содействия преобразования имен FQDN домена Арех . com.

Записи SRV и клиенты

Глядя на зону DNS нового домена, вы заметите наличие в ней множества новых па­пок или поддоменов. Открывая эти папки, вы найдете множество записей расположе­ния служб, как было показано ранее на рис. 6.22. Как уже упоминалось, записи SRV и динамические обновления DNS необходимы для обеспечения работы Active Directory.
Они представляют собой результат совместного функuионирования двух технологий.
Служба netlogon выполняет запросы DDNS для создания записей SRV внутри
пространства имен Active Directory DNS. Единственная причина заключается в га­рантировании того, что компьютеры смогут найти контроллеры домена.
Внутри проuессов ОС Windows определенные службы находятся с исполhЗовани­
ем DNS. На рис. 6.22 присутствовало несколько служб:
• _gc (global catalog — глобальный каталог) — служба LDAP для поиска данных
в глобальном каталоге;
• kerberos — проuесс аутентификаuии;
• kpassword — еще одна часть процесса аутентификации;
• ldap — служба LDAP для поиска данных в домене.
Каждая из перечисленных служб выполняется контроллерами домена внут­
ри домена или леса. На рис. 6.22 было видно, что все эти роли выполнялись на
DCOl . Bigfirm. сот и прослушивался порт ТСР.
Таким образом, когда компьютеру Windows требуется какая-то служба контроллера домена, например, LDAP, он запросит запись SRV для ldap . tcp . Bigf i rrn . сот.
После этого он получит все, что необходимо мя взаимодействия с IР-адресом и
портом.
Если компьютеру Windows нужно найти контроллер домена внутри собственного
сайта, он может искать его в поддомене sites . Bigfirm . com. В этом поддомене будут отображаться все созданные сайты в консоли Active Diгectory Sites and Services(Сайты и службы Active Directory).
Вероятность того, что администраторы могли бы поддерживать все это множес­
тво записей DNS вручную, довольно низка. Для одного контроллера домена можно
ожидать регистрации, по меньшей мере, 16-20 разных записей SRV. Изучение их
всех — задача, безусловно, не из простых. Именно здесь в игру вступают инстру­менты, подобные DcDiag. Инструкции по работе с этими утилитами приведены в разделе «Использование NsLookup и DcDiag» далее в главе.

Дополнительные компоненты Windows Server 2012 R2

К этому моменту мы обсудили существенные компоненты и способы обраще­
ния с ними, что уже позволяет вам достаточно квалифицированно управлять средой Windows Server 2012 R2 DNS. В настоящем разделе будут рассматриваться дополни­тельные компоненты DNS в Windows Server 2012 R2, которые развертываются не так
часто, как основные компоненты, но о которых, тем не менее, полезно знать.
rлобальный список блокировки запросов
Существует несколько распространенных записей хостов, которые могут быть за­
регистрированы в DNS другими службами. Одной из таких служб является протокол
автоматического обнаружения веб-прокси (\еЬ Proxy Automatic Discovery Protocol —
WPAD). Он помогает веб-браузерам автоматически загружать конфигураuии прок­
си из сервера. Так как эта запись не относится к конкретному компьютеру, любой
компьютер, включая потенциально скомпрометированный злоумышленниками, мо­жет попытаться зарегистрировать свое имя. Другой распространенной записью хоста является протокол автоматической внутрисайтовой адресаuии туннелей (lntra-Site Automatic Tunneliпg Addressing Protocol — ISATAP). Как объяснялось в главе 4, прото­кол ISATAP предназначен для выполнения маршрутизации из сети 1Pv4 в сеть 1Pv6.
В глобальном списке блокировки запросов (global query Ыосk list) указаны имена, для которых регистраuия DDNS заблокирована. Таким образом, попытки компью­тера злоумышленника зарегистрировать имена WPAD или ISATAP отклоняются.
Показанные ниже команды иллюстрируют способы администрирования это­
го списка. Для просмотра списка служит командлет Get — DNSSe rverGl oba l
QueryBlocklist. Обратите внимание, что по умолчанию в списке находятся wpad
и isatap.
C : UsersAdministrator . BFl>Get-DNSServerGlobalQueryBlocklist
ЕnаЫе : True
List : { wpad, isatap }
Чтобы добавить в этот список имя вроде www, можно воспользоваться командле­
том Set-DNSServerGlobalQueryBlocklist. По умолчанию компонент глобально­
го списка блокировки запросов включен. Он отключается и повторно включается с применением опции -ЕnаЫе со значением $True или $False.
Преобразование глобальных имен и одиночных имен
Даже с учетом того, что использование WINS идет на убыль, возникает пот­
ребность в поддержке для некоторых приложений процесса преобразования имен
NetBIOS. Компонент GlobalNames (глобальные имена) — это специальная зона, со­зданная для преобразования имен NetBIOS (15 символов безо всяких точек). Клиент
DNS осуществляет запрос в зону GlobaName, когда поиски с основным и дополни­
тельным суффиксом DNS завершились неудачей.
Конфигурирование компонента GlobalNames выполняется несложно.
1. Создайте новую зону по имени GlobalNames.
Рекомендуется выбрать тип зоны, интегрированной с Active Directory, чтобы
обеспечить репликацию в другие контроллеры домена.
2. Включите поддержку зоны Gl oba lNames с помощью командлета Set­
DNSServerGlobalNameZone:
C : UsersAdmiпistrator . BFl>Set-DNSServerGlobalNameZoпe -ЕпаЫе $True
3. Проведите репликацию зоны в другие контроллеры домена.
Не забудьте добавить эти контроллеры домена в список серверов имен для зоны.
4. Добавьте в зону записи CNAME для переадресации на определенные хосты.
В данном примере www переадресуется на hostrecord . Pr imaryZone . local
(рис. 6.29).
5. Добавьте запись местоположения службы, если необходимо, чтобы эту зону
запрашивали другие леса Active Directory.
DNS И ПРЕОБРАЗОВАНИЕ ИМЕН В WINDOWS 5ERVER 201 2 R2
DNS Manager
———-�.— — ——
� � С a:ched Lookups
� ..::J Forwгrd loolcup Zont’S
1> ,Vf _msda.Bigfirm.com
1> :Р 1dint�nite:hone.loc1J
1> …; Bigfirm.com
.:,c_Gl_o_balNomt:’:
� Prim1ryZone.lcк.al
1> _. R�erse lookup Zon�
1> _.; Trust:Po1nts
1>
Cond» rtionlll Fo�rders
1> IDJ G l o bal log:.
! Name Туре Dat.• Тimm:.Jmp
{] (same 1Js p1tr.» SЬrt of Authonty(SOA) 111 dc01.bigfirm.com» hostm.itst.» static
� (same IS rur». N t!t m e Smrer (NS) dc01.Ьigfirm.com. stnic
{ijwww AJi1s (СNАМЕ) hostrecord.Prim1ryZone.loc1’i
< f . » Рис. 6.29. Зона GlobalNames 277 Протестировать преобразование глобальных имен можно посредством уrилиты NsLookup: C: UsersAdrninistrator . DCl>Nslookup
Default Server : DCOl .Ыgfirm. com
Address : 1 92 . 1 68 . 0 . 1
> www
Server :
Address :
Name :
Address :
Aliases :
DCOl .Ыgfirm. com
1 92 . 1 68 . 0 . 1
hostrecord.primaryzone . local
1 92 . 1 68 . 0 . 2 1
www . Ьigfirm. com
Как обсуждалось ранее, в большинстве сред, полагающихся на серверы Windows,
потребность в преобразовании одиночных имен (NetBIOS) сведена к минимуму.
Она также была минимизирована за счет подходящего развертывания приложений с
применением имен FQDN и привлечения DNS.
Фоновая загрузка зон
Некоторые старые среды имеют настолько большие зоны DNS, что перезапуск
службы DNS контроллерами доменов занимает более часа. Для решения этой про­
блемы предназначено средство фоновой загрузки зон. Чтобы такая проблема воз­
никла, зона DNS должна содержать огромное количество записей.
Во время запуска службы DNS она начинает реагировать на запросы к зонам,
которые уже загрузились. Запросы к пока еще не загруженным зонам будуr отсы­
латься другим DNS-cepвepaм.
DNSSEC
Подобно НТТР, система DNS является нешифрованной и неауrентифицируе­
мой. Как упоминалось при рассмотрении зон обратного просмотра, злоумышленни­
ки мoryr подделывать ответы DNS. Чтобы противостоять этому, были разработаны
стандарты DNSSEC (DNS Security Extensions — расширения безопасности DNS),
которые позволяют DNS-cepвepy добавлять цифровую подпись к записям ресурсов.
ОС Windows Server 2012 R2 обеспечивает поддержку дополнительных зон как зон
DNSSEC. Она реагирует только на запросы записей из зоны с цифровой подписью.
ОС также будет предостамять необходимые записи ресурсов для аутентификации
подписи.
Такими записями ямяются КЕУ, SIG и NXT Запись КЕУ — это открытый ключ
подписи DNS-cepвepa. Запись SIG представляет цифровую подпись записи ресурса.
В записи NXT перечислены все допустимые записи в пространстве имен.
В версии Windows Server 2012 R2 стандарты DNSSEC претерпели следующие
улучшения:
• интеграция с Active Directory и поддержка динамических обновлений DNS;
• обновленная поддержка стандартов DNSSEC (NSECЗ и RSA/SHA-2);
• проверка достоверности записей с использованием обноменных стандартов
DNSSEC;
• дополнительная поддержка DNSSEC в PowerShell.
Если вы хотите протестировать DNSSEC в испытательной среде, обратитесь к
пошаговому руководству от Microsoft, доступному по ссылке http : / /tinyurl . сот/
dnsseclab.
якори доверия
Якори доверия (trust anchors) — это открытые сертификаты серверов DNSSEC,
которым DNS-cepoep будет доверять при взаимодействии. Сертификаты якорей до­
верия будут применяться для проверки достоверности цифровых подписей ответов.
Они добавляются в снойства DNS-cepвepa в форме открытых ключей.
В якори доверия Windows Server 201 2 R2 внесены следующие усовершенствова-
ния:
• использование Active Directory для распространения якорей доверия;
• поддержка автоматического перебора;
• упрошенное извлечение корневого якоря доверия.
В Windows Server 2012 R2 якори доверия отображаются о консоли DNS Manager,
внутри расположенной в левой части папки Trust Points (Точки доверия).

Поддержка преобразования именDNS на основе Интернета

В рамках организации существует также потребность в управлении пространс­
твами имен Интернета. Пользователям локальной сети понадобится доступ к веб­
сайтам и другим основанным на Интернете службам. Внешним пользователям будет
нужен доступ к оеб-сайтам организации и, как минимум, постовым серверам. Таким образом, вы не должны упускать из виду и эти требования.
Чтобы разрешить внешним пользователям обращаться к веб-сайтам организа­
uии, должен существовать внешний домен DNS. Следовательно, вам придется об­
думать вопрос о необходимости развертывания внешнего DNS-cepвepa. Внутренние
компьютеры будут преобразовывать внешние имена с помощью внутренних DNS­
cepвepoo. По этой причине требуется интеграuия со структурой DNS из Интернета.

Поддержка внешних доменов DNS

Большинство компаний мя поддержки веб-сайта и электронной почты регист­
рируют какое-то пространство имен DNS. Мелкие и некоторые средние компании
поручают управлять пространством имен на внешних DNS-cepвepax поставщикам
Интернет-услуг. Преимущества такого подхода связаны с готовностью серверов
и устранению потребности в обслуживании дополнительных серверов в подсети,
открытой мя Интернета. Эти серверы управляются посредством неб-интерфейса
и позволяют работать только с небольшим набором типов записей, таких как А,
CNAME и МХ.
Допускается применение сервера Windows Server 2012 R2 мя внешних операций
DNS. Роль DNS можно установить на сервере, не являющемся членом домена (как
обсуждалось в разделе «Конфигурирование автономного DNS-cepвepa» ранее в гла­ве), и затем изменить запись сервера имен мя зарегистрированного пространства
имен DNS, указав публичный IР-адрес сервера. Конечно, открыть Интернету ав­
тономный DNS-cepnep можно и таким способом, но в реальности существует не­
сколько аргументов против такого подхода.
• ОС Windows Server 2012 R2 не является бесплатной, и ее использование в ка­
честве внешнего решения DNS нельзя считать экономически оправданным
подходом.
• Сервер Windows Server 2012 R2 нуждается в ограничении функциональных воз­
можностей и зашите, когда он открыт внешне.
• Сервер должен обладать высокой доступностью, поэтому вам придется класте­
ризировать его или настроить несколько DNS-cepвepoв.
• Если вы еще об этом не позаботились, вам также понадобится высокоскорост­
ное подключение к Интернету.
Общая цена, которую придется заплатить, двигаясь в таком направлении, вы­
сока, поэтому многие компании предпочитают тратить свои деньги по-другому.
Именно здесь преимущество следует отдать простой реализации DNS на базе Linux.
Тем не менее, мы рекомендуем наиболее распространенный подход — поручить уп­
равление внешним пространством имен поставщику Интернет-услуг.
Разделение
Когда дело доходит до DNS, многие компании также внедряют сценарий с раз­
делением (spit-brain), хотя и неумышленно. Это означает, что они имеют внутрен­нее пространство имен, совпадающее с внешним пространством имен. Например,компания регистрирует внешнее пространство имен Eigfirrrc. corn и затем решает строить среду Active Directory с тем же самым именем.
Управление данным сценарием на единственном сервере было бы идеальным.
Реализация разделенной DNS — хорошая идея, предназначенная для решения про­
блемы. Можно бьuю бы иметь один DNS-cepвep, поддерживающий внутреннюю и
внешнюю зону того же самого пространства имен. Тогда бы 1 Р-адреса мя внешней
зоны предоставлялись бы внешним запросам, а внутренние 1 Р-адреса — внутрен­
ним запросам.
ПРЕДОСТЕРЕЖЕНИЯ ОТНОСИТЕЛЬНО ПРИМЕНЕНИЯ РАЗДЕЛЕННОЙ DNS
Разные специалисты и различные технические документы тто DNS могут утверждать
о том, что использовать одно и то же доменное имя для внугреннего и внешнего
пространства имен DNS компании не рекомендуется. Взамен предлагается выбрать
другое имя, которое не встречается в Интернете, или зарегистрированное имя, кото­рым вы не пользовались.
Когда компании не следуют этой рекомендации, они вскоре обнаруживают кон­
фликт при распознавании внешних ресурсов, которыми владеют, таких как www .
Bigfirm . com. Внутренний DNS-cepвep не может найти это имя, и запрос терпит
неудачу. Администраторы пытаются исправить это путем ручного добавления име­ни с внешним 1Р-адресом, но добавление внешнего IР-адреса вызьшает проблемы с маршрутизацией. Кроме того, разработчики будут жаловаться на невозможность за­грузки нового содержимого по внешнему IР-адресу. Им нужен внугренний IР-адрес.
Такие дополнительные трудности администрирования становятся нормой при разде­лении DNS.
Идея неплоха, но Windows Server 201 2 R2 это не поддерживает. В первую очередь
не поддерживается организация, открывающая контроллер домена, на котором размещено внутреннее пространство имен DNS, даже на границе Интернета. Так сде­лано не только из соображений безопасности. База данных Active Directory слишком ценна, чтобы помещать ее в демилитаризованную зону (DMZ), где она станет лако­мым кусочком для злоумышленников. Поэтому придется прибегнуть к альтернативе.
Цель заключается в том, чтобы обеспечить предоставление внешним запросам
внешних IР-адресов, а внутренним запросам — внутренних IР-адресов. Для подде­
ржки такого сценария вы должны будете администрировать (минимум) два DNS­
cepвepa с помощью Microsoft DNS. Ниже перечислены базовые шаги.
1. Реализуйте внешний DNS-cepвep для поддержки Bigfirrn. corn. Обычно это
становится готовым после регистрации доменного имени с помощью постав­
щика Интернет-услуг.
2. Реализуйте внутреннюю структуру DNS. Это делается с применением мастера
Active Directory Domain Services lnstalation Wizard.
3. Добавьте любые внешние записи во внугреннюю зону для Bigfirrn. corn.
Помните, что DNS-cepвepы внутри сети будут авторитетными для домена
Bigfirm. corn. Если не удается найти сайт www . Bigfirrn. corn, то он не сущест­вует. Внешние записи должны быть продублированы во внутренней зоне, что­бы мог возвращаться положительный результат. Вам придется протестировать
маршрутизацию, удостоверившись в доступности указанного IР-адреса. В слу­
чае возникновения проблем с маршрутизацией может понадобиться использо­
вать внутренний адрес.
4. Сконфигурируйте преобразование внешних пространств имен с применени­
ем корневых подсказок или серверов пересылки. Данная тема раскрывается в
следующем разделе.

Преобразование внешних пространств имен

Мы обсуждали, каким образом интегрировать DNS-cepвep с другими. Основными
методами преобразования имен DNS в Интернете являются корневые подсказки
или серверы пересылки. Корневые подсказки содержат список DNS-cepвepoв, на­
ходящихся наверху структуры DNS Интернета. DNS-cepвep может взаимодейство­
вать с такими серверами дЛЯ выполнения рекурсивных запросов к внешним про­
странствам имен. Серверы пересылки производят ответвленные запросы к другому
DNS-cepвepy, чтобы посмотреть, не распознает ли он имя. Ранее мы упоминали,
что в небольших средах предпочитаем использовать серверы пересылки на внешний
DNS-cepвep, поддерживаемый поставщиком Интернет-услуг, но корневые подсказ­
ки в данном сценарии также работают.
Важно не смешивать эти два подхода. Не определяйте в корневых подсказках
серверы как серверы пересылки. Запрос к корневой подсказке — это направленный
запрос, который всегда возвращает сервер имен лля домена. Он не отвечает запися­ми хостов и не выполняет рекурсивную операцию, которую будет делать сервер пе­ресылки. Кроме того, серверы пересылки имеют приоритет перед корневыми под­сказками. На приведенном ранее рис. 6. 1 О вкладка Forwarders (Серверы пересылки)
содержала флажок Use root hints if по forwarders are availaЫe (Использонать корневые
подсказки, если нет доступных серверов пересылки). Вы можете сделать вывод, что если сервер пересылки указан, но получен отрицательный ответ, запрос завершится, а корневые подсказки вообще затрагиваться не будут.
В обширных внутренних средах DNS обдуманное применение серверов пере­
сылки и корневых подсказок является обязательным. Внутренние серверы имен
поддоменов должны распознавать запросы от корневого DNS-cepвepa. Они также
должны распознавать запросы, основанные на И нтернете. Получая преимущес­
тво возможности кеширования DNS, они могут полагаться на сервер в распозна­
вании и сохранять распространен ные запросы, чтобы сократить внешний трафик.
В Microsoft рекомендуют, чтобы кеширующий сервер не был корневым, что поз­
волит не перегружать корневой сервер дополнительной рабочей нагрузкой. Кроме того, в Microsoft предостерегают от прямого взаимодействия с Интернетом внутрен­них DNS-cepвepoв, на которых размещены зоны, чтобы уменьшить их видимость в
Интернете. На рис. 6.30 показано одно решение, которое могло бы работать с нашейвымышленной структурой DNS.
В этом примере серверы пересылки используются для отправки запросов корне­
вому DNS-cepвepy в Bigfirm . com. Корневые подсказки можно было бы задейство­
вать, уда,1ив корневые подсказки И нтернета и указав B F l . Bigfirm . com в качестве сервера корневых подсказок. Кеширующий сервер предотвращает отправку запросов
в Интернет DNS-серверами, на которых размещены зоны, интегрированные с Active
Directory. Он осуществляет преобразование имен посредством корневых подсказок.
Дr�я обработки запросов в домене Арех . сот применяется зона-заглушка или сервер
условной пересьшки.
Возможны другие решения, обеспечивающие преимущества по разным причи­
нам. Мы отдаем предпочтение простоте использования серверон пересылки дr1я уп­
равления интеграцией серверов.
Кеширующий
DNS-cepвep
Сервер пересылки
�
DNS-cepвep
Ecoast. Bigfirm.com
Зона-заглушка или
сервер условной пересылки
DNS-cepвep
Apex.com
Рис. 6.30. Внутренняя структура DNS

Администрирование и устранение неполадок с помощью инструментов DNS

В этом разделе мы обсудим доступные инструменты и приемы устранения непо­
ладок в преобразовании имен DNS. Учитывая важность DNS, вы должны хорошо
знать инструменты, которые предоставляют ценную информацию, позволяющую
выявить возможные проблемы с преобразованием имен. Вдобавок к конфигуриро­ванию стандартные инструменты администрирования, консоль управления DNS и PowerShell предлагают также и дополнительную информацию такого рода. Утилиты
NsLookup, DcDiag и DNSLint предоставляют удобные начальные признаки нали­
чия проблем, касающихся преобразования имен DNS.

Администрирование DNS-cepвepa с помощью консоли управления DNS и PowerShell

Для администрирования DNS-cepвepa придется иметь дело с двумя инструмен­
тами: консолью управления DNS, которая является оснасткой М МС, и PoweгShell,
представляющим собой инструмент командной строки. Подобно оснастке ММС,
инструмент PowerShell предлагает возможность администрирования всего сервера, а также немного дополнительной функциональности. Например, как вы уже знаете,консоль управления DNS не позволяет изменять глобальный список блокировки за­просов или создавать разделы каталога.
Повсюду в этой главе демонстрировалось применение консоли управления DNS
для создания зон и редактирования свойств серверов и зон, что является обыденны­ми задачами, с которыми приходится иметь дело.

Вы также можете воспользоваться внутри консоли несколькими диагностически­
ми конфигураuиями. Они настраиваются в свойствах DNS-cepвepa.
• Вкладка Event Logging (Ведение журнала событий). Для службы DNS создается
отдельный журнал, который можно открыть в программе просмотра событий
(Event Viewer). Он связан с консолью управления DNS. Вдобавок сервер по
умолчанию собирает все события, что настраивается на вкладке Event Logging.
+ Вкладка Debug Logging (Ведение журнала отладки). В целях анализа можно
собрать в журнале более детальные сведения о действительных коммуникаци­
ях, возникающих на DNS-cepвepe. Ведение журнала отладки по умолчанию
отключено, но может быть включено через свойства DNS-cepвepa; вкладка
Debug Logging представлена на рис. 6.3 1 . Эта возможность полезна при выяв­
лении причин ненадежной работы DNS-cepвepa. Хотя большинство проблем
с DNS решаются путем подходящей подключаемости IP, вы найдете данное
средство полезным, когда подключаемость IP не имеет отношения к пробле­
ме. В редких случаях мы должны проверять, попадают ли специфичные запро­
сы на сервер, и это средство предоставляет нужную информацию.
• Вкладка Monitoring (Мониторинг). Эта вкладка также доступна из окна свойств
DNS-cepвepa; она показана на рис. 6.32. Она позволяет проверить запросы
DNS из этого сервера или предназначенные другому серверу — обратите вни­
мание, не конкретному серверу, а любому произвольно выбранному серверу.
Можно задать частоту запуска этого теста.
В выводе указывается только о том, прошел тест или нет. По существу, если на
DNS-cepвepe имеются проблемы, тест не проходит. Нам не удалось обнаружить на
этой вкладке сколько-нибудь полезные данные при решении проблем с DNS и,
скорее всего, вы не найдете здесь ничего нового. Для мониторинга DNS-cepвepoв
рекомендуется применять инструменты вроде диспетчера операций системного цен­тра 2012 R2 (Microsoft System Center 2012 R2 Operations Manager), и эта тема обсуж­дается в главе 30 (том 2).
Инструмент PowerShell предлагает несколько диагностических командлетов, ко­
торые могут оказаться полезными при сборе и анализе данных.
• Get-DNSServer предоставляет конфигурационные настройки для DNS­
cepвepa.
• Get-DnsServer 1 Export-Clixml -Path «c: configDnsServerConfig.xml»
генерирует текстовый файл с конфигурацией и свойствами зон.
• Get-DNSServerDiagnostics предоставляет сведения о ведении журналов со­
бытий для специфических операций DNS на сервере.
• Clear-DNSServerCache опустошает кеш. Иногда устаревшие распознанные
записи должны быть удалены после решения проблемы. Данная задача также
доступна в консоли управления DNS.
Все эти инструменты предоставляют средства администрирования и мониторин­
га. Мы находим их полезными для проведения более глубоких исследований, когдапередовые инструменты, такие как NsLookup, DcDiag и DNSLint, не сразу указыва­ют на проблему.

Использование NsLookup и DcDiag

При устранении проблем с DNS чаще всего используются инструменты
NsLookup, DcDiag и DNSLint. Утилита NsLookup предоставляет немедленное ука­
зание на проблемы с преобразованием имен. Утилиты DcDiag и DNSLint обеспе­
чивают указание на наличие проблем, связанных с Active Directory, таких как ре­гистрация DDNS и записи SRV. Если с помощью этих инструментов не удается
идентифицировать проблему, можно положиться на средства консоли управления
DNS и PowerShell.

NsLookup
Утилита NsLookup является первым инструментом, который мы применяем при
поиске и устранении проблем с преобразованием имен. Она подключается к указан­
ному в конфигурации IР-адресов основному DNS-cepвepy и делает запросы DNS.
Обратите внимание, что данная утилита не выполняет полный процесс преоб­
разования имен, т.е. весь жизненный цикл. Она ограничивается одной частью это­го цикла. Во время обсуждения клиентов приводились примеры команд ping и
net view, демонстрирующие различные части процесса. Пример команды ping
показывал процесс DNS, включающий первый шаг поиска имени в файле ноsтs.
Если файл ноsтs содержит записи для того же имени хоста, вы заметите расхожде­ние между ping и NsLookup.
ВИРУС CONFICKER
Одним из примеров вредоносного ПОf использующего DNS мя нарушения нор­
мальной работы, является вирус Conficker. Он появился в 2008 году, и, верите вы или нет, его до сих пор можно обнаружить на компьютерах, где не применялись
исправления системы и обновления антивирусного ПО. В зараженных вирусом
Coпficker системах предотвращается доступ из браузеров к важным сайтам внутри
определенных пространств имен DNS, таких как Microsoft . сот, Symantec . сот
и Norton . сот.
В результате ПО становится непригодным для использования. Компьютер не может
загрузить обновления Wi11dows; он не может найти возможные решения проблемы.
Даже если на машине установлено ПО Norton AntiVirus, ему не удается получить до­
ступ к сайту обновлений Symantec для загрузки последних обновлений. Машина не может исправить сама себя!
Когда мы столкнулись с Co11ficker, утилита NsLookup была первым инструментом,
задействованным в процессе обнаружения проблемы. Запросы к Microsoft . сот и
Symantec . сот проходили нормально, но обращение к указанным сайтам из браузе­ра Inteшet Explorer или Firefox оказывалось невозможным. Это помогло сузить об­ласть поиска. Таким образом, браузеры были заражены.
Конечно, утилита NsLookup предоставляет I Р-адреса мя сайтов, к которым нам не­обходим доступ. Однако веб-сайты Мicrosoft не функционируют в случае указания в URL только I Р-адреса. В результате такой обходной путь не срабатьmает.
Мы нашли решение с применением инструмента удаления вредоносного ПО
(Microsoft Windows Malicio11s Software Removal Tool — MSRT). Этот инструмент дол­жен быть загружен на отдельном компьютере и затем физически перенесен на зара­женный компьютер. С помощью MSRT вирус удалось идентифицировать и удалить.
К счастью, в наши дни распространение вируса Conficker ограничивается старыми ОС с устаревшим или отсутствующим антивирусным ПО и обновлениями Windows.
Тем не менее, это хороший пример того, как за счет изменения в преобразовании
имен нарушается работа системы и каким образом с помощью инструментов, подоб­
ных NsLookup, найти и идентифицировать причину.
Если приложению не удается получить доступ к серверу, то после проверки
подключаемости ТСР /1 Р мы начинаем исследования с использованием команды
NsLookup.

Ниже перечислены вопросы, которые требуют прояснения.
• Отвечает ли DNS-cepвep? Команда в самом начале сообщит, можно ли под­
ключиться к DNS-cepвepy. При наличии задержки или тайм-аута нет необхо­
димости продолжать. Имеется проблема с подключаемостью.
• Является ли стандартный сервер неизвестным’? Это указывает на сбой обрат­
ного просмотра, инициируемого утилитой NsLookup. При таком состоянии
остальные проверки NsLookup становятся бессмысленными.
• Можно ли преобразовать локальное имя FQDN’? Это обходит часть обработки
со стороны клиента. Для поиска имен хостов клиент будет добавлять основ­
ные суффиксы DNS.
• Можно ли преобразовать имя хоста без суффикса DNS? Это то, что делает
клиент, и данный шаг можно проверить.
• Можно ли преобразовать внешние имена FQDN’? Это позволит проверить воз­
можность выхода в Интернет стандартного DNS-cepвepa.
С утилитой NsLookup можно работать двумя способами: с помощью командных
запросов и в интерактивном режиме. Интерактивный режим намного мощнее, по­
этому вначале используется именно он. Он предлагает возможность выполнять за­просы к разным типам записей ресурсов и позволяет переключаться на другой сер­вер. Ниже приведены примеры распространенных запросов (вместе с поясняющими комментариями):
C : Use r s Ad.rninis t r ator . BFl>Nslookup
De fault Server : BFl . bigfirm . com
Address : 1 92 . 1 68 . 0 . 1 0
rem Запрос записи хоста
> BFl .bigfirm. com
Server : BFl . bigfirm . com
Address : 1 92 . 1 68 . 0 . l J
Name :
Addres s :
BFl . Ьigfirm . com
1 92 . 1 68 . 0 . 1 0
rem Запрос обратной записи PTR
> set q=ptr
> 192 . 168 . 0 . 10
Server :
l’.ddres s :
BFl . Ьigfi rm . com
1 92 . 1 68 . 0 . 1 0
10 . 1 . 1 68 . 1 92 . in-addr . a rpa
rem Запрос записи SOA
> set q=soa
> Ьigfirm . com
Server : BFl . Ьigfi rm . com
Address : 1 9 2 . 1 68 . О . 1 0
Ыgfirm . com
name = BFl . Ьigfirm . com
primary name server BFl . Ьigfirm . com
DNS и ПРЕОБРАЗОВАНИЕ ИМЕН в WINDOWS SERVER 201 2 R2
responsiЫe rnail addr = hostrnaster . bigfirm . com
serial = 124
ref resh = 900 ( 1 5 mins )
retry = 600 ( 10 min s )
expire = 8 6400 ( 1 day)
default TTL = 3600 ( 1 hour )
BFl . Ьigfirrn . сот
rem Запрос записи NS
> set <i»‘ns > bigfirrn . corn
interпet address
Server : BFl . bigfirm . com
Address : 1 92 . 1 68 . О . 1 0
1 92 . 1 68 . 0 . 1 0
bigfirm . com
BFl . Ьigfirm . com
nameserver = BFl . Ьigfirm . com
iпternet address = 1 92 . 1 68 . 0 . 1 0
rem Запрос записи SRV
> set q,zsrv
> _1dap._tcp .biqf’irm. com
Server : BFl . Ыgfir�. com
Address : 1 92 . 1 68 . 0 . 10
ldap . tcp . Ьigfirm . com SRV service locatioп :
priority О
weight 100
port 389
svr hostпame BFl . Ыgfirm . com
BFl . Ьigfirm . com iпterпet address = 1 92 . 1 68 . 0 . 1 0
DcDiaq
287
Утилита DcDiag изначально была частью набора инструментов для поддержки
администрирования (которые нужно было устанавливать отдельно) в ранних верси­ях Windows Server, но теперь она по умолчанию является частью установки Windows Server 2012 R2. Это инструмент, который нужно применять первым для быстрой проверки работоспособности структуры DNS. Поскольку утилита DcDiag прово­дит диагностику контроллеров домена, она должна проверить корректность работы DNS. После выполнения стандартного набора тестов вы можете заметить ошибки при попытках подключения к контроллерам домена. После этого можно запустить дополнительные тесты DcDiag, ориентированные специально на DNS. В следующем примере осуществляется проверка, может ли контроллер домена выполнять DDNS для регистрации записей SRV:
dcdiaq /test:ReqisterrnDNS /DnsDomain:biqf’irm. com
/f : docшnentsdcdiaqRegisterinDNS . txt
Н иже показан вывод этой команды:
Startiпg tes t : Regis teriпDNS
DNS coпfiguratioп is suf f icieпt to allow this domaiп coпtroller to
dyпamicall y register the domaiп controller Locator records i n DNS .
The DNS coпfiguration is sufficient to allow this computer to dyпarnically
register the А record correspoпdiпg to its DNS паmе .
. . . . . . . . . . . . . . . . . . . . . . . . . BFl passed test RegisteriпDNS
288
Запуск теста : Regis terinDNS
Конфигурация DNS доста точна для того, чтобы позволить этому
контроллеру домена динамически регистрировать записи Loca tor
контроллеру домена в DNS .
Конфигурация DNS достаточна для того, чтобы позволить этому
контроллеру домена динамически регистрировать запись А,
соответствующую его имени DNS .
. . . . . . . . . . . . . . . . . . . . . . . . . Brl прошел тест RegisterinDNS
Утилита DcDiag выполняет множество тестов, относящихся к контроллеру доме­
на, включая несколько тестов DNS. Выше был упомянут один из таких тестов —
RegisterinDNS. Эти тесты в первую очередь сосредоточены на интеграции между
DNS-серверами внутри среды Active Directol)’. Тесты могут быть выполнены в отно­
шении делегирования, серверов пересылки, обновлений и преобразовании внешних
имен DNS.
Ниже приведена часть справочной информации по утилите DcDiag. В ней при­
сутствует список тестов, доступных для DNS. При тестировании преобразования
внешних имен мы обычно полагаемся на NsLookup, поэтому никогда не пользуемся
тестами /DnsForwarders и /DnsResolveExtName, но для полноты они здесь пока­
заны.
DNS
Этот тест проверяет работоспособность настроек DNS для целого
предприятия . Подтесты могут запускаться по отдельности с применением
перечисленных далее ключей . По умолчанию запускаются все тесты кроме
тех , кото�:;ые проверяют преобразование внешних имен .
/DnsBas ic
/Dпs Forwarders
/DnsDelegation
/DnsDynamicUpda te
/DnsRecordRegistrat ion
/DnsResolveExtName
/DnsAll
/Dns internetName :
( базовые тесты, не могут быть пропущены)
(тесты для серверов пересылки и корневых подсказок)
( тесты для делегирования )
( тесты для динамических обновлений )
( тесты для регистрацv.и записей )
(тесты для преобразования вl-!ешних имен)
includes all tests above )
<Интер!-!ет-имя> (для теста /DnsResolveExtName )
( по умолчанию www .microsof t . com)
Как обсуждалось ранее при рассмотрении записей SRV, количество та­
ких записей, зарегистрированных контроллером домена, настолько велико,
что определить на глаз, корректно ли они работают, достаточно трудно. В до­
полнение к тесту / regi sterinDNS прогоняются тесты /DnsDynamicUpdate и
/DnsRecordRegistration, проверяющие регистрацию записей SRV контроллерами
доменов. В отличие от /registerinDNS, они не обязательно должны запускаться
локально на контроллере домена. Представленная ниже команда будет верифици­
ровать записи SRV мя контроллера домена. Опция /v означает «verЬose» («подроб­
но»). Вывод получаетсs� минным, поскольку в нем перечислены все записи SRV мя контроллера домена.
С : Jsers Administrator . БFl >dcdiag /s :BFl .Ьigfirm. com
/test : dns /dnsrecordregistration /v
DNS И ПРЕОБРАЗОВАНИЕ ИМЕН В WINDOWS 5ERVER 201 2 R2 289
Следующая команда будет проверять работоспособность обновлений DDNS мя
зоны. Она зарегистрирует хост и удалит его из зоны DNS сервера. В данном случае сервером является Ecoast . Bigfirm. сот.
C : UsersAdministrator . BFl>dcdiag /s :ecl . Ecoast . Bigfirm. com
/test:dns /dnsdynamicupdate /v
ИНСТРУМЕНТ DIG МОЩНЕЕ, ЧЕМ NsLookup
Существует инструмент для устранения неполадок в DNS, который эксплуатиру­
ется в мире Unix на протяжении продолжительного времени и называется Domain
Wormation Groper (Прощупывание доменной информации), или DJG. Если вы спро­
сите у пользователей DJG их мнение о том, насколько сравнима утилита NsLookup с DIG как инструмент для устранения неполадок в DNS, то не удивляйтесь, если они сначала рассмеются, после чего вежливо скажут, что они вообще несравнимы!
Однако хорошая новость в том, что DIG можно загрузить совершенно бесплатно
(http: //www . isc . org/software/Ьind) и установить в среде Windows Server 2012 R2, тем самым серьезно усилив уровень устранения неполадок в DNS. Инструмент DIG можно запускать в обычном формате командной строки, но он располагает так­же пакетным режимом, который поддерживает чтение запросов просмотра из файла.
Сведения по установке DIG в системе Windows Server доступны по ссылке http : / /tinyurl . com/DIGinstall. Можете также просмотреть онлайновое руководство поработе с DIG, воспользовавшись ссылкой http : //tinyurl . com/DIGusage.

Полезные ссылки по устранению неполадок в DNS

Все рассмотренные до сих пор инструменты основаны на том, что доступно в
готовом виде в ОС Windows Serveг 2012 R2. Именно с этих инструментов вы должны начинать поиск и устранение проблем в сети. В настоящем разделе мы поделимся с вами адресами нескольких веб-сайтов, имеющих отношение к DNS, которые ока­жут содействие в решении проблем с внешними именами DNS.
• www . IntoDNS . com. Это простой, но эффективный веб-сайт, который вы долж­ны добавить в свой арсенал инструментов для поиска и устранения неполадок
в DNS. Когда вы достигаете домашней страницы, понадобится лишь ввести
DNS-имя домена, о котором нужно получить информацию, и щелкнуть на
кнопке Report (Отчет). В результате возвратится все доступные сведения по за­писям А (родительской), NS, SOA, МХ и WWW мя домена. Располагая этой
информацией, вы можете быстро идентифицировать некорректно сконфигу­
рированные записи или же просто использовать ее при перекрестном контро­
ле предоставленных вам сведений.
• www . мхтоо lЬо х . com. Этот сайт делает намного больше того, что заявлено на
его начальной странице. Он предназначен для содействия в поиске и устра­
нении проблем с записями МХ и может оказаться полезным при попытках
выяснить, почему почтовый поток для отдельного домена электронной почты
не работает. В отношении любого домена можно запускать несколько разных
тестов, таких как просмотр МХ, проверка черного списка (Blacklist), просмотр
Whois и верификация SMTP. Если вы не пользовались этим сайтом ранее, то
самое время добавить его в список закладок.
290 ГЛАВА 6
• http://www.DNSStuff . com. Это еще один популярный сайт, который можно приме­
нять мя формирования отчетов по DNS, просмотров Whois и информаuии об
1 Р-адресах. Здесь вы можете также получить доступ к большому количеству
дополнительных инструментов дЛЯ поиска и устранения проблем с DNS, если
приобретете учетную запись на нем, но сначала имеет смысл оценить обещан­
ные преимущества, воспользовавшись пробным периодом.

Сейчас мы установим роль сервера DNS-сервер на операционной системе Microsoft Windows Server 2012 R2 Datacenter, затем создадим зону прямого просмотра, а также вспомним, что такое вообще DNS и для чего он нужен.

И прежде чем устанавливать и настраивать DNS сервер, давайте вспомним, что такое DNS и DNS сервер. Так как подобной информации в Интернете полно мы рассмотрим это кратко и перейдем сразу к делу. Напомню, что в прошлых статьях мы рассматривали установку Windows Server 2012 R2 и установка и настройку DHCP сервера на этой же операционной системе, теперь продолжаем и на очереди у нас DNS сервер.

DNS (Domain Name System) – это система доменных имён, которая позволяет по доменному имени узнать IP адрес хоста и наоборот. Так как у каждого компьютера или сетевого устройства есть свой IP адрес и для того чтобы обратиться к тому или иному компьютеру или устройству соответственно нужно знать этот IP адрес, но так как запоминать определенную последовательность цифр не удобно, да и как если, например Вы обращаетесь ко многим компьютерам (запомнить просто не реально) поэтому чтобы  не запоминать эти цифры, и существует система доменных имен, например, что лучше для восприятия 192.168.1.1 или mycomp.  Вот такое простое определение, но так как материал для начинающих администраторов, этого вполне достаточно.

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

Хватит теории, и так как материал посвящен именно установки роли DNS сервер, давайте переходить непосредственно к этому.

Примечание! Как видно из названия, DNS сервер мы будем устанавливать на ОС Windows Server 2012 R2 Datacenter, только мы будем использовать, как и в прошлых статьях, ознакомительную версию.

Установка DNS сервера на Windows Server 2012 R2

Шаг 1

Открываем диспетчер серверов и выбираем «Добавить роли и компоненты»

Шаг 2

На следующем окне ничего не нужно делать, это окно простое напоминание администратору о том, что учетная запись администратора должна быть защищена надежным паролем, о том, что необходимо устанавливать все последние обновления, кстати, можно сделать так чтобы это окно не появлялось в следующий раз, для этого поставьте соответствующую галочку. И жмем «Далее»

Шаг 3

На этом шаге, также ничего не нужно делать, все по умолчанию выбрано правильно именно так как нам и нужно, жмем «Далее»

Шаг 4

Затем предстоит выбрать сервер, на который будет производиться установка роли DNS сервера, так как у меня сервер один я его и выбираю, жму «Далее»

Шаг 5

Вот как раз на этом шаге и нужно выбрать, какие роли мы будем устанавливать, а мы соответственно будем устанавливать роль DNS сервер, поэтому выбираем его

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

Затем жмем «Далее»

Шаг 6

И так как компоненты мы уже добавили нам искать их здесь не нужно, но для примера я покажу, где они находятся и что они уже выбраны, жмем «Далее»

Шаг 7

На следующем окне нам говорят, на что обратить внимание при установке роли DNS сервер, жмем «Далее»

Шаг 8

Все подтверждаем установку нажатием кнопку «Установить», ставить галочку «Автоматический перезапуск сервера» в данном случае не нужно.

Вот и все началась установка

Продлится она не долго минуты 3, и появится следующее сообщение, жмем «Закрыть»

Все, роль сервера DNS-сервер установлена. Для запуска средств управления DNS сервером используйте Диспетчер серверов->Средства ->DNS

Или через меню Пуск

Само средство управления выглядит следующим образом

Создание зоны прямого просмотра на DNS сервере 2012 R2

На группе «Зоны прямого просмотра» щелкаем правой кнопкой мыши и выбираем «Создать новую зону»

После у нас запустится мастер создания новой зоны, жмем «Далее»

В следующем окне выбираем тип наше зоны, описание можете посмотреть непосредственно под каждым типов, я выбираю «Основную» жму «Далее»

Затем нам предстоит написать имя нашей зоны, в моем случае, так как сервер тестовый я выберу имя local, Вы в свою очередь пишете, название вашего домена, или если Ваш домен не будет иметь выхода в Интернет другими словами локальный (чисто в Вашей сети), то в принципе можете писать все что угодно.

Далее я выбираю «Создать новый файл», так как у меня другого DNS сервера нет, жму «Далее»

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

Заключительное окно, которое говорит нам, что все готово, мы соответственно и жмем «Готово»

Вот и все зона создана, давайте создадим запись типа A, например для нашего же сервера. Для этого по зоне щелкаем правой кнопкой мыши и жмем «Создать узел A или AAAA»

Затем вводим имя нашего узла, которое мы хотим, чтобы у него было, и соответственно какой у него IP адрес, это уже по факту. Жмем «Добавить узел»

Появится сообщение о том, что узел создан

И появится соответствующая запись

Затем не забываем проверить, какой днс сервер установлен у нас в настройках сетевого интерфейса (он должен быть соответственно наш, т.е. ip адрес этого сервера). Потом соответственно мы можем проверить работу только что установленного DNS сервера, например, запустить командную строку и попробовать пропинговать узел который мы создали чуть ранее

Как видите, система распознала по доменному имени его IP адрес. И на этом предлагаю заканчивать. Удачи!