Страницы: 1 2 3 4 5 6 .. 16

Глава 3. Active Directory и доменная система имен
Служба каталога Active Directory Microsoft Windows Server 2003 при поиске ресурсов в сети полностью полагается на доменную систему имен (DNS). Без надежной инфраструктуры DNS контроллеры домена в сети не смогут делать реплики друг с друга, клиенты Microsoft Windows 2000 и Microsoft Windows XP Professional не смогут входить в сеть, а серверы, на которых выполняется приложение Microsoft Exchange Server 2000, не смогут посылать электронную почту. По существу, если ваша реализация службы DNS нестабильна, то сеть Windows Server 2003 не будет работать. Это значит, что для управления средой Active Directory вы должны иметь глубокое знание концепций DNS и ее реализации в Windows Server 2003.
Данная глава начинается с краткого обзора DNS как службы. Далее подробно рассказывается, почему Active Directory зависит от DNS, и как работает процесс разрешения имен. Затем речь идет о службе DNS в системах Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition. В операционной системе Windows Server 2003 доменная система имен имеет свойства, которые делают весьма привлекательным развертывание Active Directory.
Примечание. Версия Windows Server 2003, Web Edition не требует и не поддерживает службу Active Directory.
Краткий обзор DNS
DNS является службой разрешения имен. Если вы пытаетесь найти сервер в интернете, более вероятно, что вы помните его имя, например, www.microsoft.com, чем IP-адрес, который может выглядеть как 207.46.230.219. Однако вашему компьютеру для соединения с Web-сайтом Microsoft требуется знать его IP-адрес. Служба DNS выполняет этот перевод. Вы сообщаете своему браузеру имя компьютера, с которым вы хотели бы соединиться, a DNS превращает это имя в правильный IP-адрес.
Примечание. Поскольку доменная система имен важна для работы Active Directory, вы должны ознакомиться с концепциями службы DNS и знать, как она реализована. Если вы не знакомы с DNS, вам следует просмотреть некоторые ресурсы, имеющиеся на веб-сайте Microsoft по адресу http://msdn.microsoft.com/ library/en-us /dns/dns_concepts. asp.
Иерархическое пространство имен
DNS использует иерархическое пространство имен для поиска компьютеров. На рисунке 3-1 показан пример организации пространства имен. Корневой домен обозначается точкой («.»). Он представляет собой верхний уровень DNS, остальное пространство имен располагается ниже. На следующем уровне под корневым доменом располагаются домены первого уровня, включая семь основных (generic) доменных имен (com, edu, mil, net, org), около двухсот сокращений названий стран (са, uk, fr, br), семь новых доменов (biz, info, pro и т.д.), которые были введены в 2001 году.

Рис. 3-1. Иерархическое пространство имен DNS
Под доменами верхнего уровня расположены домены второго уровня, которые обычно относятся к названиям компаний и должны быть зарегистрированы властями интернета. Ниже доменов второго уровня располагаются поддомены. Поддомены обычно относятся к отделам или подразделениям в пределах компании. Эти поддомены регистрируются и управляются с DNS-серверов, которые содержат информацию о доменах второго уровня.
Другим способом представления иерархического пространства имен является полностью определенное имя домена (FQDN — Fully Qualified Domain Name), например, www.NAmerica.Contoso.com. FQDN представ-
ляет собой полное имя, которое можно использовать для идентификации определенного компьютера в пределах всего пространство имен DNS. Чтобы понять, как FQDN идентифицирует компьютер в пространстве имен DNS, прочтите его справа налево. Справа находится точка («.»), которая идентифицирует корневой домен, она предшествует имени домена первого уровня. За ней следуют домен com первого уровня, домен Contosoвторого уровня и поддомен NAmerica. Слева в имени FQDN находится www - имя определенного компьютера.
Распределенная база данных
Поскольку DNS использует иерархическое пространство имен, то достаточно просто сконфигурировать его как распределенную базу данных. Прежде чем в интернете была реализована доменная система имен, вся информация, необходимая для разрешения имен, хранилась в единственном файле. Поскольку количество хостов в интернете увеличилось до сотен тысяч компьютеров, то управление одним файлом стало непрактичным. Была разработана система DNS, использующая распределенную базу данных. Использование распределенной базы данных означает, что информация DNS хранится на многих компьютерах во всем мире (в случае интернета) и повсюду в вашей сети (в случае внутренней сети). Каждый DNS-сервер обслуживает только одну маленькую часть базы данных DNS. Вся база данных разделена на зонные файлы на основе имен доменов. Зонные файлы распределены между несколькими серверами. К примеру, существует около дюжины серверов, которые содержат зонные файлы для корневого домена. Они хранят информацию о DNS-cep-верах, которые несут зонную информацию для доменов высшего уровня. Корневые серверы не содержат всю информацию о доменах высшего уровня, но они знают, какие серверы имеют эту информацию.
DNS-серверы, хранящие информацию о доменах высшего уровня, содержат также информацию о том, на каких серверах находятся зонные файлы для доменов следующего уровня. Например, сервер может содержать зонные файлы для домена сот, т.е. этот сервер знает обо всех доменах второго уровня, которые зарегистрированы с доменом сот, но он может не знать отдельные детали о домене второго уровня. Сервер домена высшего уровня знает, какой компьютер на следующем уровне содержит детали, касающиеся домена второго уровня, и так продолжается до самого низа пространства имен DNS. Сервер, ответственный за домен com, может иметь домен Contoso, зарегистрированный как домен второго уровня. Этот сервер может передавать любые запросы на информацию о домене Contoso на сервер, который содержит зонные файлы для Contoso.com.
Использование метода распределенной базы данных означает, что никакому серверу в интернете не требуется иметь всю информацию DNS. Большинство серверов хранят информацию о некоторой части дерева,
но когда приходит запрос, который они не могут выполнить, им известно, какой DNS-сервер хранит необходимую информацию. DNS-серверы используют делегированные записи, ретрансляторы (forwarders) и корневые ссылки для определения того, какой DNS-сервер имеет необходимую информацию. Эти темы будут обсуждаться далее в главе.
Процесс разрешения имен
Иерархическое пространство имен DNS и распределенная база данных используются тогда, когда клиент пробует найти IP-адрес ресурса в интернете. Используя пример из предыдущего раздела (см. рис. 3-1), предположим, что клиент DNS (назовем его преобразователем), расположенный в какой-то точке земного шара, хочет соединиться с веб-сервером, имеющим адрес www.NAmerica.Contoso.com. Для получения IP-адреса выполняются следующие действия.

1. Клиент-преобразователь посылает рекурсивный запрос об IP-адресе на свой сконфигурированный DNS-сервер (обычно это DNS-сервер провайдера службы интернета). Рекурсивный запрос может иметь только два возможных ответа: IP-адрес, запрашиваемый клиентом, или сообщение об ошибках, указывающее, что информация не может быть найдена.
2. Если DNS-сервер провайдера имеет необходимую информацию в своем кэше, то он возвращает IP-адрес пользователю. Если нужной информации нет, то он пробует найти информацию, посылая итерационный запрос на другой сервер. Ответом на итерационный запрос может быть или разрешенное имя, запрашиваемое клиентом, или переадресация на другой DNS-сервер, который сможет выполнить запрос. В нашем примере DNS-сервер провайдера посылает итерационный запрос корневому серверу об IP-адресе, который соответствует www.NAmerica.Contoso.com.
3. Корневой сервер не может ответить на запрос, но в ответ он присылает список серверов, ответственных за домен высшего уровня сот. Этот процесс предоставления списка альтернативных DNS-серверов для дальнейшего контакта называется направлением (referral). DNS-сервер интернет-провайдера посылает итерационный запрос одному из этих серверов с просьбой об IP-адресе.
4. Сервер сот дает в ответ список серверов, которые являются ответственными за домен Contoso.com. Далее DNS-сервер провайдера посылает запрос DNS-серверу Contoso.com, который дает в ответ имена DNS-серверов, управляющих доменом NAmerica.Contoso.com.
5. DNS-сервер NAmerica.Contoso.com содержит всю информацию об этом домене, и он посылает DNS-серверу провайдера IP-адрес нужного хоста.
6. DNS-сервер провайдера отвечает на рекурсивный запрос, который он получил от клиента-преобразователя, и посылает IP-адрес запрошенного Web-сервера.
7. Компьютер клиента соединяется с www.NAmerica.Contoso.com.
8. Этот процесс происходит очень быстро и может не включать некоторые шаги. Когда DNS-сервер разрешает любой тип имени, он сохраняет эту информацию в кэше в течение определенного периода. Если кто-то искал этот же сайт раньше в этот день и DNS-сервер провайдера разрешил это имя, то он просмотрит свой кэш и даст ответ немедленно.

Записи ресурсов
Текущие записи, хранящиеся в зонных файлах DNS, называются записями ресурсов (RR — Resource Records). Записи ресурсов содержат текущую информацию о домене. Вы можете создать двадцать два различных типа записей ресурсов на DNS-сервере системы Windows Server 2003. Наиболее распространенные записи ресурсов перечислены в таблице 3-1.
Табл. 3-1. Наиболее распространенные записи ресурсов в доменной системе имен Windows Server 2003

Рис. 3-2. Запись SOA для домена Contoso.com
Совет. На рисунке 3-2 показана запись SOA в инструменте администрирования DNS. Записи DNS могут быть сохранены в стандартном текстовом формате. Например, стандартная запись хоста для сервера по имени Webl.Contoso.com может быть записана как Webl.Contoso.com IN A 192.168.1.100.
DNS-домены, зоны и серверы
Одним из важных аспектов изучения работы DNS является понимание терминологии, которая используется для описания компонентов DNS.
Сравнение доменов и зон
Одна из проблем терминологии, которая может затруднять понимание, состоит в различии между доменами и зонами. С одной стороны, это различие состоит в том, что домен представляет часть пространства имен DNS, а зоны — это информация об этой части пространства имен. Например, компания может владеть именем домена второго уровня Contoso.com. Это означает, что компания владеет одной частью полного пространства имен DNS, т.е. это их домен. Когда компания реализует DNS-серверы для домена, то вся информация о домене DNS будет храниться на одном или нескольких DNS-серверах. Эта информация включает все записи ресурсов всех компьютеров в домене DNS. Она является зонной информацией и хранится в зонных файлах на серверах DNS.
Существует два различных типа зонных файлов в DNS: зоны прямого просмотра и зоны обратного просмотра. Зона прямого просмотра используется для разрешения имен хоста к IP-адресам. Эти функциональные возможности обеспечивают записи хоста (А). Зона прямого просмотра может включать записи SOA и NS, а также записи MX, CNAME и SRV. Зона прямого просмотра используется всякий раз, когда клиент-преобразователь делает запрос DNS-серверу, чтобы найти IP-адрес сервера в сети.
Зоны обратного просмотра выполняют противоположную функцию. Она используется тогда, когда IP-адрес хоста известен, а имя хоста не известно. Зона обратного просмотра также имеет записи SOA и NS, остальная часть записей - это записи PTR. Формат записи PTR подобен записи хоста, но он обеспечивает ответ для обратного поиска. Для получения дополнительной информации о записях см. табл. 3-1.
Имя зоны прямого просмотра является именем домена. Имя зоны обратного просмотра определить более трудно, потому что она использует IP-адрес подсети, а не имя домена, в качестве границы зоны. Когда вы создаете зону обратного просмотра, вы должны дать ей имя, основанное на IP-адресе подсети. Например, если вы создаете зону обратного просмотра для подсети 192.168.1.0, то зонное имя будет L168.192.in-addr.arpa. Имя in-addr.arpa специально зарезервировано в DNS для ссылок на зоны обратного просмотра. Первая часть зонного имени является сетевым адресом, записанным в обратном порядке. Если вы создаете зону обратного просмотра для подсети класса В (150.38.0.0), имя зоны обратного просмотра будет 38.150.in-addr.arpa.
Основные серверы имен
Основным сервером имен (Primary Name Server) является единственный сервер, имеющий перезаписываемую копию зонных файлов (зона на основном сервере имен называется основной зоной - primary zone). Это означает, что DNS-администратор должен иметь доступ к основному серверу имен всякий раз, когда нужно внести какие-либо изменения в зонную информацию. После того как внесены изменения, эти данные автоматически копируются на дополнительные серверы имен с помощью процесса, который называется зонной передачей.
Дополнительные серверы имен
Дополнительный сервер имен (Secondary Name Server) имеет копию зонных файлов, которая предназначена только для чтения. Единственный способ обновления зонной информации дополнительного сервера имен состоит в зонной передаче с основного сервера имен. В ранних версиях DNS каждая зонная передача была полной зонной передачей, т.е. все содержимое зонного файла DNS передавалось с основного сервера имен на дополнительный. Документ Request for Comment 1995 (Запрос на комментарии) представил более эффективный механизм зонной передачи, называемый добавочной зонной передачей (incremental zone transfers), в котором на дополнительный сервер копируются только изменения, сделанные в зонных файлах с момента последней передачи. Другое усовершенствование представлено в документе Request for Comment 1996. Это механизм уведомлений, который позволяет основному серверу предупреждать дополнительные серверы имен о том, что были сделаны изменения к зонным файлам. Без опции уведомления дополнительный сервер имен будет контактировать с основным сервером только через интервалы времени, определенные в записях SOA для каждой зоны.
Примечание. DNS-сервер Windows Server 2003 поддерживает как добавочную зонную передачу, так и уведомления. Он также поддерживает интегрированные (integrated) зоны Active Directory, в которых регулярная зонная передача заменена репликацией Active Directory.
Кэширующие серверы имен
Третий тип сервера имен - это сервер, который только кэширует информацию (caching-only). Он не управляет зонными файлами, а только кэширует любые разрешения имен, которые он выполнял. Кэширующий сервер часто используется в удаленных офисах, подключенных к большому офису с ограниченной пропускной способностью. Поскольку кэширующий сервер не имеет никаких зонных файлов, то и трафик зонной передачи DNS через медленное сетевое подключение отсутствует. Кэширующий сервер должен конфигурироваться так, чтобы он переправлял все DNS-запросы на сервер, расположенный в главном офисе компании. Поскольку кэширующий сервер разрешает DNS-запросы, то он кэширует информацию в течение некоторого времени (по умолчанию -1 час). Это означает, что любой местный DNS-запрос той же самой информации может быть разрешен в местном масштабе.
Примечание. Все DNS-серверы Windows Server 2003, включая основной и дополнительные серверы имен, кэшируют информацию, но они не называются кэширующими (caching-only) серверами. Различие между этими серверами и только кэширующими серверами состоит в том, что последний не имеет никакой зонной информации.
Зоны полномочий
Чтобы полностью понимать DNS, вы должны познакомиться с зонами полномочий (zones of authority) и полномочными (authoritative) серверами имен. Каждый основной и дополнительный серверы имен являются полномочными для своего домена. Например, если DNS-сервер содержит зонные файлы для домена Contoso.com, то этот сервер является
полномочным сервером имен для этого домена. Как полномочный сервер имен он не будет отправлять никаких запросов о хостах этой зоны другим DNS-серверам. Многие компании устанавливают конфигурацию DNS-сервера так, как показано на рисунке 3-3. В этом сценарии имеются два основных DNS-сервера, сконфигурированные для домена Contoso.com. DNS1 содержит запись хоста для сервера по имени Webl.Contoso.com, a DNS2-cepBep этой записи не имеет. Когда клиент соединяется с DNS1, он сможет разрешить IP-адрес для Webl. Когда клиент соединяется с DNS2 и запрашивает IP-адрес для Webl, сервер ответит, что хост не может быть найден. Поскольку DNS2 сервер является полномочным для домена Contoso.com, он не будет отправлять запросы серверу DNS1. Его поведение заложено в проекте и, как показывает обсуждение примера в разделе «Практический опыт», это дает определенное преимущество в безопасности.

Рис. 3-3. Множество полномочных DNS-серверов
Практический опыт. Использование нескольких полномочных серверов для одной зоны
Иногда возникает ситуация, когда компания имеет два DNS-сервера, являющимися полномочными для одного домена, и интернет-имя DNS компании и ее внутреннее имя DNS идентичны (как показано на рис. 3-3). Сервер DNS1 находится с внутренней стороны брандмауэра, а сервер DNS2 - с его внешней стороны. Сервер DNS2 используется для разрешения DNS-запросов клиентов интернета, в то время как DNS1 используется для внутренних клиентов и для SRV-записей Active Directory. Поскольку оба сервера полномочны для одной и той же зоны (Contoso.com), они не будут отправлять запросы об этом домене друг другу.
В этом случае необходимо поддерживать уникальную зонную информацию на каждом DNS-сервере. Внешний DNS-сервер, вероятно, будет иметь относительно маленький зонный файл, состоящий из веб-серверов и МХ-записей, которые должны быть доступны из интернета. Внутренний DNS-сервер будет иметь намного больший зонный файл, содержащий все записи контроллера домена, все внутренние записи сервера и, возможно, записи хоста для всех клиентских компьютеров в сети. Единственное дублирование между двумя зонными файлами может состоять из некоторых внешних записей DNS. Например, когда внутренние клиенты соединяются с www.Contoso.com, вы можете потребовать, чтобы они соединялись с тем же внешним веб-сервером, к которому обращаются интернет-клиенты. Для этого нужно включить запись хоста для вебсервера в зонный файл на DNS1. Если вы не сделаете этого, то внутренние клиенты не смогут соединяться с веб-сервером.
Делегированные зоны
Поскольку система DNS использует иерархическое пространство имен, должен существовать механизм соединения разных уровней иерархии. Например, если клиент соединяется с сервером, который является полномочным для домена первого уровня сот, и запрашивает сервер в домене Contoso.com, corn-сервер должен уметь определять, какой сервер имен является полномочным для домена Contoso.com. Это возможно при помощи записей делегирования (delegation records).
Запись делегирования представляет собой указатель на домен низшего уровня, который идентифицирует сервер имен для домена низшего уровня. Например, на рисунке 3-4 показано, что DNSl.Contoso.com является полномочным сервером имен для домена Contoso.com. DNS2 и DNS3 являются полномочными серверами имен для домена NAmerica.Contoso.com. Сервер DNS1 считается полномочным для домена NAmerica.Contoso.com, но он не имеет всех записей ресурса дочерних доменов. Однако сервер DNS1 использует запись делегирования, указывающую на DNS2 и DNS3 как на серверы имен для дочернего домена. Когда клиент соединяется с сервером DNS1, запрашивая информацию об NAmerica.Contoso.com, сервер перешлет клиента на сервера имен дочернего домена.
Ретрансляторы и корневые ссылки
Второй способ соединения различных уровней иерархии системы DNS состоит в использовании корневых ссылок и ретрансляторов. В большинстве случаев ретрансляторы и корневые ссылки используются низкоуровневыми серверами пространства имен DNS для поиска информации, находящейся на высокоуровневых серверах DNS-иерархии. Ретрансляторы и корневые ссылки используются DNS-сервером для поиска информации, которая отсутствует в их собственных зонных файлах. Например, DNS-сервер может быть полномочным только для домена Contoso.com. Когда он получит запрос от клиента, запрашивающего разрешение имени в домене Fabrikam.com (см. рис. 3-1), DNS-сервер Contoso.com должен иметь какой-то способ поиска этой информации.

Рис. 3-4. Делегированные зоны
Одним из способов конфигурирования сервера для этих целей является использование ретрансляторов. Ретранслятор (forwarder) - это просто другой DNS-сервер, который используется определенным DNS-сервером, когда он не может разрешить запрос. Например, полномочный сервер имен для Contoso.com может получить рекурсивный запрос для домена Fabrikam.com. Если DNS-сервер Contoso был сконфигурирован с ретранслятором, то он отправит рекурсивный запрос ретранслятору, запрашивая эту информацию. Ретрансляторы часто используются во внутренней сети организации. Организация может иметь несколько DNS-серверов, главной задачей которых является внутреннее разрешение имен. Пользователям внутри организации может потребоваться разрешение IP-адресов интернета. Это можно выполнить, сконфигурировав все внутренние DNS-серверы так, чтобы они могли разрешать адреса интернета. Более распространенным вариантом является конфигурирование внутренних DNS-серверов с ретранслятором, указывающим на DNS-сервер, являющийся ответственным за разрешение имен интернета. Этот вариант показан на рисунке 3-5. Все внутренние DNS-серверы отправляют любой запрос для неполномочной зоны на один DNS-сервер, который разрешает интернет-адреса. Если DNS-сервер сконфигурирован с несколькими ретрансляторами, то он будет отправлять запросы всем ретрансляторам по порядку, прежде чем попытается использовать любой другой способ разрешения IP-адресов.

Рис. 3-5. Использование ретрансляторов для разрешения имен в интернете
Второй метод, который может применить DNS-сервер при ответе на запросы для тех зон, для которых он не является полномочным, состоит в использовании корневых ссылок. Когда вы устанавливаете DNS-сервер Windows Server 2003, имеющий доступ к интернету, он автоматически конфигурируется со стандартным списком корневых серверов. Корневые серверы - это серверы, которые являются полномочными для корня в пространстве имен интернета. Если DNS-сервер получает запрос о зоне DNS, для которой он не является полномочным, сервер посылает итерационный запрос одному из корневых серверов. Итерационные запросы будет инициироваться до тех пор, пока нужное имя не будет разрешено или пока сервер не подтвердит, что оно не может быть разрешено.
Примечание. Корневые серверы, которые автоматически указываются на DNS-сервере при его конфигурировании, копируются из файла Cache.dns, который поставляется с файлами установки DNS-сервера.
Вы можете добавлять дополнительные DNS-серверы к списку корневых ссылок, включая в него DNS-серверы, имеющиеся в вашей внутренней сети.
По умолчанию DNS-серверы Windows Server 2003 используют ретрансляторы и корневые ссылки, когда они пытаются разрешать имена. Если сервер конфигурирован с ретрансляторами, он сначала отправит рекурсивные запросы всем ретрансляторам. Если ни один из ретрансляторов не может обеспечить необходимую информацию, то DNS-cep-вер начнет посылать повторяющиеся запросы серверам, сконфигурированным как корневые ссылки. В некоторых случаях необходим DNS-сервер, использующий только ретрансляторы и не использующий корневые ссылки. Чтобы сконфигурировать такой сервер, выберите опцию Do Not Use Recursion For This Domain (He использовать рекурсию для этого домена) на вкладке Forwarders (Передатчики) в окне Properties (Свойства) DNS-сервера. После этого DNS-сервер сначала будет пытаться разрешить любые запросы с помощью своей местной зонной или кэ-шированной информации, посылая рекурсивные запросы каждому из своих ретрансляторов. Если ретрансляторы не смогут обеспечить необходимую информацию, DNS-сервер не будет использовать другие средства, чтобы найти эту информацию. Он сообщит клиенту, что хост не может быть найден.
Примечание. В системе DNS Windows Server 2003 возможности традиционных ретрансляторов расширены за счет реализации условных ретрансляторов. Эта тема подробно рассматривается в разделе «Условная ретрансляция» далее в этой главе.
Динамическая система DNS
В прошлом сложность работы с DNS состояла в том, что вся зонная информация должна была вводиться вручную. До выхода документа RFC 2136 не существовало никакого способа автоматического обновления зонной информации DNS-сервера. В документе RFC 2136 описано, как DNS-серверы должны быть сконфигурированы, чтобы автоматически принимать обновления к записям ресурсов в зонных файлах. Эта опция называется динамической службой DNS (DDNS).
DNS-серверы Windows Server 2003 поддерживают динамическую службу DNS. По умолчанию все клиенты Windows 2000 и Windows XP Professional, а также Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition автоматически обновляют свои записи ресурсов в DNS. Windows 2000 и контроллеры домена Windows Server 2003 автоматически регистрируют SRV-записи на DNS-серверах, которые используются для поиска контроллеров домена. DNS-серверы Windows Server 2003 будут
также принимать динамическую регистрацию записей с серверов динамической конфигурации хостов (DHCP). DHCP-сервер Windows Server 2003 может конфигурироваться для автоматического обновления DNS-записей для любого из его клиентов, включая Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows Me или Microsoft Windows NT.
Одна из проблем динамической системы DNS связана с безопасностью. Без какого-либо контроля над тем, кому позволено обновлять записи ресурсов DNS, любой, имеющий доступ к вашей сети, потенциально может создать запись ресурса в ваших зонных файлах DNS, а затем использовать эту запись для переадресации сетевого трафика. Чтобы решить эту проблему в системе DNS Windows Server 2003 существуют безопасные обновления. Безопасные обновления имеются только в интегрированных зонах Active Directory. С помощью безопасных обновлений вы можете управлять тем, кому дается право регистрировать и обновлять DNS-записи. По умолчанию члены группы Authenticated Users (Уполномоченные пользователи) имеют право обновлять свои записи в системе DNS. Вы можете изменить это, изменяя список управления доступом ACL (ACL - Access Control List) для DNS-зоны.
Динамическая система DNS уменьшает объем работы, который должен делать администратор DNS. Далее вы узнаете, что Active Directory Windows Server 2003 требует присутствия SRV-записи каждого контроллера домена в зонной информации, поэтому поддержка динамических обновлений является важным свойством DNS-системы Windows Server 2003.
DNS и Active Directory Windows Server 2003
Active Directory не сможет функционировать без надежной конфигурации DNS. Контроллеры домена не смогут находить друг друга для репликации доменной информации, клиенты с системами Windows 2000 и Windows XP Professional будут очень медленно искать контроллеры домена для входа в систему. Без надежной DNS любые другие службы, которым требуется Active Directory, не смогут работать. Например, Exchange Server 2000 хранит всю свою конфигурационную информацию в Active Directory, поэтому если серверы, на которых выполняется Exchange Server 2000, не смогут найти контроллер домена при запуске, они не смогут запустить большинство служб Exchange Server 2000.
Совет. Клиенты, на которых выполняются системы Windows 95, Windows 98, Windows Me и Windows NT не полагаются на DNS в поиске контроллеров домена с Windows Server 2003. Они используют для поиска имена NetBIOS, а службу имен интернета для Windows (WINS - Windows Internet Naming Service) - для разрешения имен NetBIOS к IP-адресам. По умолчанию Windows Server 2003 поддерживает низкоуровневых клиентов, регистрируя необходимые имена NetBIOS с помощью WINS.
Служба DNS Locator
Служба DNS Locator (Указатель DNS) очень важна для Active Directory, потому что DNS обеспечивает информацию, которая необходима клиентам для поиска контроллеров домена в сети. Далее детально рассматривается процесс, которым пользуется клиент для поиска контроллеров домена.
Примечание. В Windows NT вход в систему домена был основан на именах NetBIOS. Каждый контроллер домена регистрировал имя NetBIOS Domainname с <1С> в качестве шестнадцатого символа имени в сети и в службе WINS. Когда клиент пробовал войти в сеть, он пытался найти серверы, которые имели зарегистрированное имя контроллера домена. Если клиент не находил ни один из этих серверов, то он не мог войти в систему. Записи SRV на Windows Server 2003 используются для поиска контроллеров домена клиентами, на которых выполняются системы Windows 2000 и Windows XP Professional. Без записей SRV эти клиенты не смогут войти на домен Windows Server 2003.

Записи ресурсов DNS, зарегистрированные контроллером домена Active Directory
Чтобы облегчить нахождение контроллеров домена, Active Directory использует указатель служб (service locator) или записи SRV. Записи SRV - это новый тип DNS-записи, описанный в документе RFC 2782, он используется для идентификации услуг в TCP/IP-сети. На примере одной из записей, используемых службой Active Directory, показано, как каждая запись SRV использует стандартный формат (см. табл. 3-2).
_ldap._tcp.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com

Табл. 3-2. Компоненты записи SRV

По сути, информация в этой записи говорит, что если клиент ищет сервер облегченного протокола службы каталогов (LDAP) в домене Contoso.com, он должен соединиться с dc2.contoso.com.
Контроллеры домена в домене Windows Server 2003 регистрируют много SRV-записей в системе DNS. Следующий список включает все записи, зарегистрированные первым сервером леса.
contoso.com. 600 IN A 192.168.1.201
_ldap._tcp.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
_ldap._tcp.Default-First-Site-Name._sites.contoso.com. 600 IN SRV 0 100 389
dc2.contoso.com.
_ldap._tcp.pdc._msdcs.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
_ldap._tcp.gc._msdcs.contoso.com. 600 IN SRVO 100 3268 dc2.contoso.com.
_ldap._tcp. Default-First-Site-Name._sites._gc._msdcs.contoso.com. 600 IN SRV 0
100 3268 dc2.contoso.com.
_ldap._tcp.64c228cd-5f07-4606-b843-d4fd114264b7.domains._msdcs.contoso.com.
600 IN SRV 0 100 389 dc2.contoso.com.
gc._msdcs.contoso.com. 600 IN A 192.168.1.201
175170ad-0263-439f-bb4c-89eacc410ab1._msdcs.contoso.com. 600 IN CNAME
dc2.contoso.com.
_kerberos._tcp.dc._msdcs.contoso.com. 600 IN SRVO 100 88 dc2.contoso.com.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.contoso.com. 600 IN
SRV 0 100 88 dc2.contoso.com.
_ldap._tcp.dc._msdcs.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.contoso.com. 600 IN SRV 0
100 389 dc2.contoso.com.
_kerberos._tcp.contoso.com. 600 IN SRV 0 100 88 dc2.contoso.com.
_kerberos._tcp.Default-First-Site-Name._sites.contoso.com. 600 IN SRV 0 100 88
dc2.contoso.com.
_gc._tcp.contoso.com. 600 IN SRV 0 100 3268 dc2.contoso.com.
_gc._tcp.Default-First-Site-Name._sites.contoso.com. 600 IN SRVO 100 3268
dl2.contoso.com.
_kerberos._udp.contoso.com. 600 IN SRV 0 100 88 dc2.contoso.com.
_kpasswd._tcp.contoso.com. 600 IN SRV 0 100 464 dc2.contoso.com.
_kpasswd._udp.contoso.com. 600 IN SRV 0 100 464 dc2.contoso.com.
DomainDnsZones.contoso.com. 600 IN A 192.168.1.201
_ldap._tcp.DomainDnsZones.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
_ldap._lcp.Default-First-Site-Name._sites.DomainDnsZones.contoso.com. 600 IN
SRV 0 100 389 dc2.contoso.com.
ForestDnsZones.contoso.com. 600 IN A 192.168.1.201
_ldap._tcp.ForestDnsZones.contoso.com. 600 IN SRV 0 100 389 dc2.contoso.com.
_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.contoso.com. 600 IN
SRV 0 100 389 dc2.contoso.com.
Примечание. Если на котроллере домена установлена система Windows Server 2003, все эти записи записываются в файл по имени Netlogon.dns, расположенный в папке %systemroot%\ system32\config. Если вы не хотите допускать динамические обновления на DNS-серверах, вы можете импортировать эти записи в зонные файлы DNS.
Первая часть SRV-записи идентифицирует службу, на которую указывает запись SRV. Существуют следующие службы:

• _ldap Active Directory является службой каталога, совместимой с LDAP-протоколом, с контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV идентифицирует LDAP серверы, имеющиеся в сети. Эти серверы могут быть контроллерами домена Windows Server 2003 или другими LDAP-серверами;
• _kerberos - основной опознавательный протокол для всех клиентов Windows 2000 и Windows XP Professional. SRV-записи _kerberos идентифицируют все ключевые центры распределения (KDC - Key Distribution Centers) в сети. Они могут быть контроллерами домена с Windows Server 2003 или другими KDC-серверами;
• _kpassword — идентифицирует серверы изменения паролей kerberos в сети (это или контроллеры домена с Windows Server 2003 или с другими системами изменения пароля kerberos);
• _gc - специфическая запись, относящаяся к функции глобального каталога в Active Directory. Сервер глобального каталога выполняет множество важных функций в Active Directory.

Многие из SRV-записей содержат идентификатор сайта в дополнение к компонентам, перечисленным в таблице 3-2. Сайт используется в Active Directory для идентификации одной или более IP-подсетей, которые связаны через высокоскоростные сетевые подключения. Одно из преимуществ использования сайтов состоит в том, что сетевые клиенты всегда будут пробовать войти на контроллер домена, который находится на том же самом сайте, что и клиент. Записи сайта нужны компьютерам для поиска контроллеров домена, расположенных в том же самом сайте, где находится клиент. Подробности механизма, который используется клиентом для поиска информации, касающейся сайта, обсуждаются в следующем разделе.
Другим необходимым компонентом SRV-записей является значение _msdcs, которое имеется во многих записях. Некоторые службы, предусмотренные записями SRV, не относятся к службам, разработанным компанией Microsoft. Например, могут встретиться LDAP или kerberos-cep-веры в реализациях, не принадлежащих Microsoft. Эти серверы также могут регистрировать записи SRV на сервере DNS. Контроллеры домена с Windows Server 2003 регистрируют как основные (generic) записи (например, _ldap._tcp.contoso.com), так и записи, содержащие ссылку на _msdcs. Они ссылаются только на роли, определенные продуктами Microsoft, т.е. на Windows Server 2003 или на контроллеры домена Windows 2000. Записи идентифицируют основную функцию каждого сервера: gc (глобальный каталог), dc (контроллер домена) или pdc (основной эмулятор контроллера домена).
Другая зарегистрированная запись содержит глобальный уникальный идентификатор (GUID - globally unique identifier) домена. Запись GUID домена используется для поиска контроллеров домена в случае его переименования.
Примечание. Имеются записи, расположенные ниже поддоме-нов ForestDnsZones и DomainDnsZones. О них более подробно вы узнаете в разделе «Раздел приложений каталога» этой главы.
Поиск контроллера домена службы Active Directory
Контроллеры домена, на которых выполняется Windows Server 2003, регистрируют некоторые (или все) записи, описанные выше. Эти записи играют важную роль, когда клиент, на котором выполняется система Windows 2000 или Windows XP Professional, пытается войти в домен. Далее описаны действия, которые выполняются при входе клиента в домен.

1. Во время входа пользователя компьютер клиента выполняет удаленный вызов процедуры (RPC) запроса местной сетевой службе входа в систему, которая инициирует сеанс входа в систему. Являясь частью RPC-запроса, клиент посылает такую информацию, как имя компьютера, имя домена и имя сайта, службе Net Logon (Вход в сеть).
2. Служба входа в сеть использует службу указателя доменов (domain locator), чтобы вызвать API-функцию DsGetDcName (), передающую одно из значений параметра флага, перечисленных в таблице 3-3.

Табл. 3-3. Значения параметра флага DsGetDcName

Примечание. Почти всегда функция DsGetDcName включает параметр sitename. Для всех запросов, кроме запроса DS_PDC_REQUIRED, клиент делает начальный запрос, используя параметр сайта. Если DNS-сервер не отвечает на запрос, клиент пошлет тот же самый запрос без параметра сайта. Например, если запрос DS_KDC_REQUIRED не выполнен, клиент пошлет запрос на запись _kdc._tcp.dc._msdcs.forestrootdomain. Это может случиться, если клиент находится на сайте, который не распознан серверами DNS. Клиент может также передать параметр DomainGUID вместо имени домена с помощью функции DsGetDcName (). В этом случае клиент запрашивает запись _ldap._tcp.domainGUID.domains._msdcs.forestname. Это случится только в том случае, если домен был переименован.

3. DNS сервер возвращает запрошенный список серверов, рассортированный согласно приоритету и весу. Затем клиент посылает LDAP запрос, используя UDP-порт 389 по каждому из адресов записи в том порядке, как они были возвращены. После отсылки каждого пакета клиент ждет в течение 0,1 с, если никакого ответа не получено, он посылает пакет следующему контроллеру домена. Клиент продолжает этот процесс до тех пор, пока не получит допустимый ответ или не перепробует все контроллеры домена.
4. Когда контроллер домена ответит клиенту, клиент проверяет ответ, чтобы удостовериться, что он содержит запрошенную информацию. Если информация имеется, клиент начинает процесс входа в систему с контроллера домена.

Клиент кэширует информацию контроллера домена, чтобы в следующий раз, когда ему потребуется обратиться к Active Directory, не нужно было снова проходить процесс обнаружения.
Как клиент определяет, какому сайту он принадлежит
Наличие специфических для сайта записей важно для эффективной работы Active Directory, потому что поле деятельности клиента ограничено определенным сайтом. Например, в процессе входа в систему клиент всегда пробует соединиться с контроллером домена, расположенном в своем сайте, прежде чем соединяться с любыми другими сайтами. Как же клиент узнает, какому сайту он принадлежит?
Информация сайта для леса хранится в разделе конфигурации ката-, лога в Active Directory, она копируется на все контроллеры домена в лесу. Список IP-подсетей, которые связаны с определенным сайтом, включается в конфигурационную информацию. Когда клиент впервые входит в Active Directory, первый ответивший контроллер домена сравнивает IP-адрес клиента с IP-адресом сайта. Часть ответа контроллера домена клиенту составляет информация сайта, которую клиент затем кэширует. Любые последующие попытки входа в систему будут включать информацию сайта клиента.
Если клиент переместился между сайтами (например, портативный компьютер может быть подсоединен к сети в другом городе), он все еще посылает информацию сайта как часть входа в систему. DNS-сервер ответит с записью контроллера домена, который находится в запрашиваемом сайте. Однако если на основе нового IP-адреса клиента контроллер домена решит, что клиент не находится на первоначальном сайте, он пошлет новую информацию сайта клиенту. Затем клиент выполнит кэширование новой информации и попытается найти контроллер домена в правильной подсети.
Если клиент не находится ни в одном из сайтов, которые определены в Active Directory, то он не сможет выполнять запросы на специфическую для сайта информацию о контроллерах домена.
Интегрированные зоны Active Directory
Одно из самых больших преимуществ выполнения DNS в операционной системе Windows Server 2003 заключается в использовании интегрированных зон (integrated zones) Active Directory. Интегрированные зоны Active Directory дают множество преимуществ.

• Зонная информация больше не хранится в зонных файлах на жестком диске DNS-сервера, она хранится в базе данных Active Directory. Это обеспечивает дополнительную защиту.
• Процесс зонной передачи заменен репликацией Active Directory. Поскольку зонная информация хранится в Active Directory, то данные копируются через нормальный процесс репликации Active Directory. Это означает, что репликация происходит на уровне атрибутов так, что копируются только изменения зонной информации. Трафик репликации между сайтами можно сильно сжать, увеличив пропускную способность. Использование интегрированной зоны Active Directory дает возможность использовать разделы приложений для тонкой настройки репликации информации DNS.
• Интегрированные зоны дают возможность конфигурирования DNS-сервера с несколькими хозяевами. Без Active Directory DNS может поддерживать только один основной сервер имен для каждого домена. Это означает, что все изменения в зонной информации должны быть сделаны на основном сервере имен, а затем переданы на дополнительные серверы имен. С интегрированными зонами Active Directory каждый DNS-сервер имеет перезаписываемую копию доменной информации, так что изменения зонной информации могут быть сделаны в любом месте в организации. Информация затем копируется на все другие серверы DNS.

Интегрированные зоны предлагают опцию безопасных обновлений. Если зона является интегрированной зоной Active Directory, вы можете сконфигурировать ее так, чтобы использовать только безопасные обновления. Это означает, что вы имеете больше контроля над тем, какие пользователи и компьютеры обновляют записи ресурсов в Active Directory.
Самым большим недостатком интегрированной зоны Active Directory является необходимость установки DNS на контроллере домена Windows Server 2003, что создает дополнительную нагрузку на него.
Совет. Возможно соединение интегрированных зон Active Directory с дополнительными. Например, можно иметь три контроллера домена в центральном месте и несколько отдаленных офисов, в которых отсутствует контроллер домена. Если вы хотите иметь DNS-сервер в отдаленном офисе, вы можете установить DNS на сервере, на котором выполняется система Windows Server 2003, а затем сконфигурировать дополнительную зону на сервере DNS. Тогда дополнительный сервер будет принимать зонные передачи от интегрированной зоны Active Directory.
Когда зона сконфигурирована как интегрированная зона Active Directory, вы может просматривать информацию DNS в Active Directory
(см. рис. 3-6). Для этого запустите консоль управления Microsoft (MMC -Microsoft Management Console) и убедитесь, что оснастка Active Directory Users And Computers (Пользователи и компьютеры Active Directory) была добавлена к консоли. Выберите папку Active Directory Users And Computers (Пользователи и компьютеры Active Directory) из меню View (Вид), выберите Advanced Features (Дополнительные свойства). Откройте папку с именем домена, затем откройте папку System (Система), затем - папку Microsof tDNS. Зонная информация для всех интегрированных зон Active Directory перечислена в каждой зонной папке.

Рис. 3-6. Просмотр информации интегрированной зоны Active Directory
Практический опыт. Разрешение имен DNS без усовершенствованной службы DNS Windows Server 2003
Корпорация, состоящая из четырех различных компаний, каждая из которых была независимой до момента слияния, планировала развертывание Active Directory в системе Windows 2000 Advanced Server. Каждая компания настаивала на поддержке собственного пространства имен в пределах одного леса; это означало, что должен быть развернут лес с назначенным (dedicated) корневым доменом и четырьмя доменами компании (см. рис. 3-7). Все компании были расположены в разных городах в Канаде.

Рис. 3-7. Проект леса Active Directory с несколькими деревьями
Поскольку смежного пространства имен для всей компании не существовало, нормальный процесс делегирования дочерних доменов не применялся. Процесс конфигурирования ретрансляторов и корневых ссылок также оказался неэффективным, потому что не является достаточно отказоустойчивым. Например, если кому-то из Contoso.com требовалось найти ресурс в домене Fabrikam.com, клиент должен был запрашивать DNS-сервер Contoso. Поскольку сервер не был полномочным сервером для домена Fabrikam, он должен был разрешить имя, используя корневую ссылку или ретранслятор. Если DNS-сервер Contoso был сконфигурирован с ретранслятором на DNS-сервер в домене Fabrikam, имя могло быть разрешено. Однако эта запись ретранслятора не могла использоваться для разрешения компьютерных имен в домене TailspinToys.com или во внутренней сети. Использование системы DNS Windows 2000 предложило несколько путей решения этой проблемы (см. ниже), но ни один из них не был достаточно удовлетворительным.

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

Ни одно из этих решений не идеально. Операционная система Windows Server 2003 предлагает три варианта решения. В них используются условная переадресация, сокращенные зоны (stub zones) и разделы приложений каталога.
Совершенствование DNS
Большинство опций DNS, которые обсуждались до этого, доступны в Windows 2000. В операционной системе Windows Server 2003 имеется, по крайней мере, три существенных улучшения DNS. Описание практического опыта (см. выше) иллюстрирует одну из типичнейших трудностей в конфигурировании DNS большой корпорации, с которой сталкивались администраторы до выхода операционной системы Windows Server 2003.
Условная переадресация
Условная переадресация (conditional forwarding) значительно увеличивает возможности процесса переадресации. До выхода Windows Server 2003 в процессе переадресации нельзя было делать различий, основанных на именах домена. Когда клиент-преобразователь делал запрос, на который сервер не мог ответить с помощью своего кэша или зонных файлов, сервер посылал рекурсивный запрос по своему списку конфигурированных ретрансляторов. Не было возможности сконфигурировать ретранслятор так, чтобы он был чувствителен к специфике домена. Условная переадресация обеспечивает как раз такой тип осмысления: DNS-cep-вер может теперь передавать запросы домена на различные серверы DNS, учитывая имя домена.
Например, компания, о которой шла речь выше, имеет пять деревьев в единственном лесу. При репликации контроллеры домена должны суметь найти контроллеры домена в других доменах. Пользователи также часто путешествуют между компаниями. Они должны иметь возможность входить на свой домашний домен независимо от того, с какой сетью они связаны физически. Существует также значительное количество ресурсов, сконфигурированных для совместного использования между компаниями. Эти требования подразумевают, что информация DNS должна быть общедоступной для разных доменов.
С помощью Windows Server 2003 серверы DNS в каждом домене могут быть сконфигурированы с условным ретранслятором, переадресующим запросы на один или более серверов DNS в других доменах. Когда один из серверов DNS разрешает имя из другого домена, он может использовать только тот ретранслятор, который сконфигурирован для этого домена. Например, когда клиент в домене Contoso.com должен найти ресурс в домене Fabrikam.com, он делает запрос DNS-серверу домена Contoso.com. DNS-сервер проверяет свои зонные файлы, чтобы определить, является ли он полномочным сервером для этого домена, а затем проверяет свой кэш. Если он не сможет разрешить имя с помощью этих источников, он проверит список ретрансляторов. Один из ретрансляторов определен для домена Fabrikam.com, так что DNS-сервер Contoso.com пошлет рекурсивный запрос только этому серверу DNS. Если нет никаких условных ретрансляторов для домена Fabrikam.com, сконфигурированных на сервере DNS Contoso.com, то он отправит запрос любому ретранслятору, который сконфигурирован без каких-либо определенных параметров настройки домена, а затем попробует использовать корневые ссылки.
Предостережение. Обратите внимание, что DNS-сервер проверяет свои собственные зонные файлы, прежде чем использовать ретрансляторы. Если DNS-сервер является полномочным для данного домена, он не будет отправлять запрос условному ретранслятору.
Условная переадресация конфигурируется в окне Properties (Свойства) сервера в административном инструменте DNS (см. рис. 3-8). С его помощью вы можете сконфигурировать один или более контроллеров домена в качестве ретрансляторов для каждого имени домена. Если вы конфигурируете несколько серверов DNS для имени домена, то DNS-сервер будет пытаться использовать первый DNS-сервер в списке. Если этот сервер не отвечает в течение заданного значения интервала тайма -ута, которое устанавливается на вкладке Forwarders (Ретрансляторы), то сервер будет пробовать использовать следующий DNS-сервер из списка, пока не будут запрошены все имеющиеся в списке DNS-серверы. Если никаких условных ретрансляторов, сконфигурированных для имени домена, в списке нет, то сервер будет запрашивать серверы DNS, определенные в опции All Other DNS Domains (Другие домены DNS).

Рис. 3-8. Конфигурирование условных ретрансляторов
При использовании условной переадресации DNS-сервер всегда будет пробовать найти соответствие наиболее точному имени домена. На-
пример, если имеются условные ретрансляторы, сконфигурированные для Fabrikam.com и для Europe.Fabrikam.com, а клиент делает запрос о сервере Webl.Europe.Fabrikam.com, то DNS-сервер отправит запрос на DNS-сервер для Europe.Fabrikam.com.
Сокращенные зоны
Сокращенные зоны (stub zones) - это второе улучшение к службе DNS в Windows Server 2003. Они предназначены для упрощения конфигурирования разрешения имен между несколькими пространствами имен. Сокращенная зона подобна дополнительной зоне. При установлении сокращенной зоны вы должны определить IP-адрес основного сервера имен для зоны. Тогда сервер, владеющий сокращенной зоной, запрашивает зонную передачу у основного сервера имен. Однако сокращенная зона отличается от дополнительной тем, что она содержит только записи SOA, NS и записи хоста (А) для сервера имен домена, а не все записи зоны.
Это улучшает процесс разрешения имен без необходимости использовать дополнительные серверы. Когда DNS-сервер сконфигурирован с сокращенной зоной, он не является полномочным для домена. Он эффективен при поиске полномочного сервера имен для указанной зоны. С помощью дополнительных зон DNS-сервер может найти полномочный сервер имен для зоны без необходимости контактировать с серверами корневых ссылок. Обратите внимание, как дополнительная зона может работать в лесу с одним деревом, т.е. с непрерывным пространством имен (см. рис. 3-9). Без дополнительных зон в случае запроса клиента из NAmerica.Contoso.com IP-адреса хоста в домене SAmerica.Contoso.com DNS сервер в NAmerica. Contoso.com проверяет свои зонные файлы, кэш и ретрансляторы. Если ни один из этих источников не обеспечивает нужную информацию, он посылает итерационный запрос серверу корневых ссылок. В этом случае DNS сервер в корневом домене Contoso.com должен быть сконфигурирован как корневой сервер, чтобы DNS-сервер домена NAmerica. Contoso.com послал запрос ему. Корневой сервер проверяет свои записи делегирования и передает IP-адрес полномочного сервера имен домена SAmerica.Contoso.com серверу имен NAmerica. Contoso.com. Затем сервер имен NAmerica. Contoso.com запрашивает у одного из серверов DNS домена SAmerica. Contoso.com IP-адрес сервера, который требуется клиенту.
Если имеется сокращенная зона, DNS-сервер домена NAmerica. Contoso.com не должен соединяться с сервером DNS корневого домена. Ему не нужно использовать свои корневые ссылки, чтобы найти сервер имен для домена SAmerica.Contoso.com. Когда клиент делает запрос, сервер проверяет свои зонные файлы, находит сокращенную зону и посылает итерационный запрос любому из серверов имен домена SAmerica. Contoso.com.
Использование сокращенной зоны особенно эффективно при наличии нескольких деревьев. Возьмем предыдущий пример, в котором лес состоит из пяти деревьев. Использование записей делегирования в корневой зоне в этом случае не работает, потому что домены не используют
общего пространства имен. Вы можете сконфигурировать сокращенную зону для каждого домена на серверах DNS в других доменах. Если в этом случае какой-либо запрос DNS нуждается в информации из другого домена, DNS-сервер может использовать информацию сокращенной зоны, чтобы немедленно соединиться с сервером имен в другом домене.

Рис. 3-9. Конфигурация DNS с одним лесом без использования сокращенной зоны
Сокращенная зона поддерживает список серверов имен для делегированных зон. Когда вы устанавливаете делегированный поддомен, вы должны ввести IP-адреса всех серверов имен в делегированный домен. Если этот список серверов имен изменяется, например, один из серверов имен удален из сети, вам придется вручную обновить запись делегирования. Вы можете использовать сокращенную зону, чтобы автоматизировать процесс обновления списка серверов имен. Чтобы сделать это в домене Contoso.com, вы можете сконфигурировать сокращенную зону для домена NAmerica.Contoso.com на серверах DNS домена Contoso.com. Вы также можете сконфигурировать запись делегирования в зоне Contoso.com, указывающую на сокращенную зону. Когда записи сервера имен изменятся в дочернем домене, они будут автоматически обновлены в сокращенной зоне. Когда серверы DNS Contoso.com будут использовать запись делегирования, они получат ссылку на сокращенную зону, так что у них всегда будет доступ к обновленной информации сервера имен.
Чтобы сконфигурировать сокращенную зону, используйте New Zone Wizard (Мастер новой зоны) в инструменте администрирования DNS. Щелкните правой кнопкой мыши на Forward Lookup Zones (Прямая зона просмотра) или на Reverse Lookup Zones (Обратная зона просмотра)) и выберите New Zone (Новая зона). Появится опция создания сокращенной зоны (см. рис. 3-10).

Рис. 3-10. Создание новой сокращенной зоны
Раздел приложений каталога
Третье улучшение DNS, помогающее разрешению имен хоста между несколькими доменами, состоит в использовании раздела приложений каталога.
DNS в Active Directory Windows Server 2003 использует раздел приложений каталога для облегчения репликации информации DNS в лесу. При установке DNS, когда вы назначаете первый сервер в лесу на роль контроллера домена, в Active Directory создаются два новых раздела каталога. Это разделы DomainDnsZonesи ForestDnsZones. (Их не видно ни в одном из обычных инструментальных средств управления Active Directory, они отображаются при использовании ADSI Edit или Ldp.exe; использование ADSI Edit показано на рисунке 3-11.) Каждый из этих разделов хранит разную конфигурацию репликации. Раздел DomainDnsZones реплицируется на все серверы DNS, выполняющиеся на контроллерах домена. Раздел ForestDnsZones реплицируется на все серверы DNS, выполняющиеся на контроллерах домена в лесу. Вы можете хранить информацию DNS в разделе каталога домена, т.е. она будет копироваться на все контроллеры домена в домене.
Необходимо выбрать место хранения информации DNS при создании новой зоны (см. рис. 3-12) в окне Zone Properties (Свойства зоны) в инструменте администрирования DNS. Имеются четыре варианта хранения информации DNS.

• То All DNS Servers In The Active Directory Forest domainname (Ha все серверы DNS леса Active Directory). Информация хранится в разделе ForestDnsZones, откуда копируется на все серверы DNS контроллеров домена леса. Эта конфигурация задана по умолчанию для зоны _msdcs в интегрированной зоне Active Directory.

Рис. 3-11. Раздел приложений каталога DNS в инструменте ADSI Edit

• То All DNS Servers In The Active Directory Domain domainname (Ha все серверы DNS в домене Active Directory). Информация хранится в разделе DomamDnsZones, откуда копируется на все серверы DNS, выполняющиеся на контроллерах домена. Это конфигурация, принятая по умолчанию для интегрированной зоны Active Directory, созданной в процессе обновления контроллера домена.
• То All Domain Controllers In The Active Directory Domain domainname (На все контроллеры домена в домене Active Directory). Информация хранится в разделе домена каталога, откуда копируется на все контроллеры домена. Различие между этой опцией и предыдущей состоит в том, что в этом случае все контроллеры домена получат информацию, в то время как раздел DomamDnsZones реплицируется только на контроллеры домена, являющиеся серверами DNS.
• То All Domain Controllers Specified In The Scope Of The Following Application Directory Partition (На все контроллеры домена в пределах следующего раздела приложений каталога). Эта опция доступна только в том случае, если вы создаете дополнительный раздел приложений каталога с его собственной конфигурацией репликации. Информация DNS будет копироваться на все контроллеры домена, которые имеют реплику этого раздела.

Примечание. Раздел приложений каталога для DNS создается только в том случае, если выбрана установка DNS при назначении первого контроллера домена или леса. Если вы хотите воспользоваться преимуществами раздела приложений каталога для DNS после того, как обновили контроллер домена, необходимо вручную создать раздел перед его использованием. Для создания раздела применяется инструмент администрирования DNS или инструмент командной строки DNSCMD. При использовании инструмента администрирования DNS щелкните правой кнопкой мыши на имени сервера DNS и выберите Create Default Application Directory Partitions (Создание заданных по умолчанию разделов приложений каталога). При использовании инструмента DNSCMD откройте командную строку и напечатайте dnscmd DN S servername/CreateBuiltin-DirectoryPartitions /forest. В результате будет создан раздел ForestDnsZones. Чтобы создать раздел DomainDnsZones, используйте «/domain» в качестве последнего параметра в команде. Поскольку эта команда изменяет раздел конфигурации каталога в Active Directory, вы должны входить в систему как член группы Enterprise Admins (Администраторы предприятия).

Рис. 3-12. Конфигурирование области репликации для зон DNS
Обычно заданная по умолчанию конфигурация зон не изменяется. При наличии нескольких контроллеров домена в домене, причем только некоторые из них являются серверами DNS, использование раздела DomainDnsZones уменьшает количество репликаций на контроллеры домена, которые не являются серверами DNS. Зона _msdcs для каждого домена, которая включает только информацию о серверах Active Directory в домене, хранится в разделе ForestDnsZones. Эта информация реплицируется по всему лесу.
Резюме
Служба DNS является необходимой сетевой службой для сетей Windows Server 2003. Без нее практически любой вход в систему и усилия по поиску расположения ресурсов потерпят неудачу в Windows Server 2003. Как сетевой администратор вы должны стать экспертом по службе DNS. В данной главе был дан краткий обзор того, как работает DNS в качестве сетевой службы в любой среде, показана специфика интеграции DNS с Active Directory. Наиболее важным компонентом интеграции является процесс поиска контроллера домена, при котором контроллеры домена в Active Directory регистрируют записи SRV в DNS, а затем клиенты используют эти записи для поиска контроллеров домена. Кроме того, было приведено описание некоторых улучшений DNS в Windows Server 2003.

1 2 3 4 5 6 .. 16