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

Служба, которую идентифицирует запись. Дополнительные службы включают _kerberos, _kpassword и _gc.

;

Протокол

_tcp

Протокол, используемый для этой службы. Может быть протоколом TCP или протоколом пользовательских датаграмм (UDP).

;

Имя

contoso.com

Имя домена, на который ссылается запись.

;

Время жизни (TTL - Time to Live)

600

Заданное по умолчанию «время жизни» записи (в секундах).

Класс

IN

Стандартный DNS-класс интернета.

Запись ресурса

SRV

Идентифицирует запись как запись SRV.

Приоритет

0

Идентифицирует приоритет записи для клиента. Если существует несколько SRV-записей для одной и той же службы, клиенты будут сначала пытаться соединиться с сервером, имеющим самый низкий приоритет.

Вес

100

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

Порт

389

Порт, используемый этой службой.

Адресат

dc2.contoso.com

Хост, который обеспечивает службу, идентифицированную записью.

По сути, информация в этой записи говорит, что если клиент ищет сервер облегченного протокола службы каталогов (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. Существуют следующие службы:

  • _ldapActive 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

Требуемая запись DNS

DS_PDC_REQUIRED

_ldap._tcp.pdc._msdcs.domainname

DS_GC_SERVER_REQUIRED

_ldap._tcp.sitename._sites.gc. _msdcs.Forestrootdomainname

DS_KDC_REQUIRED

_kdc._tcp.sitename._sites.dc ._msdcs.domainname

DS_ONLY_LDAP_NEEDED

_ldap._tcp.sitename._sites._ msdcs.domainname

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

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

Клиент кэширует информацию контроллера домена, чтобы в следующий раз, когда ему потребуется обратиться к 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без усовершенствованнойслужбыDNSWindowsServer2003
Корпорация, состоящая из четырех различных компаний, каждая из которых была независимой до момента слияния, планировала развертывание 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. Эта информация реплицируется по всему лесу.