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 SRV 0 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 SRV 0 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 SRV 0 100 3268 dc2.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._tcp.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-серверы в реализациях, не принадлежащих 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 не выполнен, клиент отправляет запрос на запись _kerberos._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 является возможность использования интегрированных зон 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 (Система), затем - папку MicrosoftDNS. Зонная информация для всех интегрированных зон 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-сервер может теперь передавать запросы домена на различные серверы 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, а клиент делает запрос о сервере Web1.Europe.Fabrikam.com, то DNS-сервер отправит запрос на DNS-сервер для Europe.Fabrikam.com.

Сокращенные зоны

Сокращенные зоны - это второе улучшение к службе 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.

• Для всех серверов DNS в лесу Active Directory с именем domainname. Информация хранится в разделе ForestDnsZones и копируется на все серверы DNS контроллеров домена леса Active Directory. Эта конфигурация задана по умолчанию для зоны _msdcs в интегрированной зоне Active Directory.

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

• Для всех серверов DNS в домене Active Directory domainname: информация хранится в разделе DomainDnsZones, откуда она реплицируется на все серверы DNS, работающие на контроллерах домена. Это стандартная конфигурация для интегрированной зоны Active Directory, созданной в процессе обновления контроллера домена.
• Для всех контроллеров домена в домене Active Directory domainname: информация хранится в разделе домена каталога, откуда она реплицируется на все контроллеры домена. Отличие этой опции от предыдущей заключается в том, что здесь все контроллеры домена получают информацию, в то время как раздел DomainDnsZones реплицируется только на контроллеры домена, которые также являются серверами DNS.
• Для всех контроллеров домена в пределах определенного раздела приложений каталога: эта опция доступна только при создании дополнительного раздела приложений каталога с уникальной конфигурацией репликации. Информация DNS будет реплицироваться на все контроллеры домена, имеющие реплику этого раздела.

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

Рис. 3-12. Конфигурирование области репликации для зон DNS

Обычно заданная по умолчанию конфигурация зон не изменяется. При наличии нескольких контроллеров домена в домене, причем только некоторые из них являются серверами DNS, использование раздела DomainDnsZones уменьшает количество репликаций на контроллеры домена, которые не являются серверами DNS. Зона _msdcs для каждого домена, которая включает только информацию о серверах Active Directory в домене, хранится в разделе ForestDnsZones. Эта информация реплицируется по всему лесу.