Новые функции для работы с многодоменными лесами

В статье «Устраняем проблемы DNS», опубликованной в этом же номере, речь идет о том, как построить инфраструктуру DNS для двухдоменного леса Active Directory (AD). В ней отмечается, что, хотя DNS-серверы на базе Windows 2000 успешно работают в многодоменных лесах, некоторых функций в них все же недостает. Этот пробел можно восполнить с помощью DNS-серверов на базе Windows 2003.

В качестве простого примера в статье рассматривается лес с двумя доменами — один из них назван bigfirm.biz, а другой — bigfirm.com. В обоих доменах используется разделенная (split-brain) DNS; они должны взаимно разрешать имена и SRV-записи для поиска контроллеров домена (DC), чтобы системы и пользователи каждого домена могли быть идентифицированы в любом из них. Компания Bigfirm может выбрать один из двух подходов. Можно построить динамические зоны для каждого домена и не интегрировать их с AD. В этом случае администраторы должны проверить все DNS-серверы корпоративной сети и убедиться, что каждый из них является первичным или вторичным сервером как для зоны bigfirm.biz, так и для bigfirm.com.

Альтернативный подход — преобразовать bigfirm.biz и bigfirm.com в зоны, интегрированные с AD. Как правило, интегрированные с AD зоны — более подходящее решение для AD-зон, чем разделенная DNS. Но, к сожалению, DNS-серверы на базе Windows 2000 обмениваются DNS-информацией о зоне только с DC данной зоны. Например, если DNS-зона bigfirm.biz интегрирована с AD, то только DNS-серверы, которые одновременно являются контроллерами домена bigfirm.biz, смогут получить DNS-информацию о bigfirm.biz. Даже если изменить DNS-зону bigfirm.com, интегрировав ее с AD, DNS-серверы bigfirm.com получат информацию только о bigfirm.com, но не о bigfirm.biz, даже если оба домена находятся в одной сети. Чтобы устранить невосприимчивость DNS-серверов на базе Windows 2000 к любой AD-интегрированной информации вне своего домена, следует сделать эти DNS-серверы обычными вторичными серверами для других серверов в лесу.

Предположим, что у компании Bigfirm имеется несколько тысяч хост-машин и несколько десятков DNS-серверов. Каждый из этих DNS-серверов играет роль вторичного сервера по крайней мере в одной зоне. Поэтому каждый раз, когда в зоне происходят изменения, эту информацию приходится пересылать на все вторичные серверы компании, что создает большую нагрузку на каналы связи и процессор. Microsoft DNS не требует пересылки всей зоны при любом незначительном изменении (в отличие от некоторых старых программных решений DNS), но все же процедура пересылки данных зоны способом, описанным в документе RFC (Request for Comments), неэффективна. В случае интеграции с AD пересылка выполняется более эффективным механизмом репликации AD со сжатием трафика репликации между сайтами. В DNS-серверах Windows 2003 появились три усовершенствования по сравнению с Windows 2000: зоны-заглушки (stub zones), условная ретрансляция (conditional forwarding) и зоны, интегрированные с AD в масштабах всего леса.

Зоны-заглушки

Благодаря зонам-заглушкам программы DNS-серверов Windows 2003 формируют зоны, которые отличаются от размещаемых на стандартных первичных и вторичных DNS-серверах. В зонах на стандартных первичных и вторичных DNS-серверах содержится полный экземпляр файла зоны, а в зоне-заглушке хранится лишь минимальный файл зоны. Зона-заглушка вместо всех записей зоны хранит лишь записи Start of Authority (SOA) и Name Server (NS). Другими словами, единственная информация, которую можно получить от DNS-сервера с зоной-заглушкой для данной зоны, — это имена DNS-серверов и сведения о том, какой из них является первичным DNS-сервером зоны. IP-адрес определенной хост-машины в зоне из зоны-заглушки получить нельзя.

Чем может быть полезна зона, которая лишь сообщает, какие серверы являются серверами имен зоны? Предположим, что bigfirm.biz располагает большой зоной, содержащей тысячи записей, и разработчикам домена требуется множество DNS-серверов. Они создали первичный DNS-сервер и группу вторичных DNS-серверов. Но сетевые трассировки показывают, что DNS-серверы тратят больше времени на получение последней информации о зоне от первичного DNS-сервера (и тем самым замедляют работу первичного сервера и нагружают каналы связи), чем на рассылку ответов на запросы. Разработчики сетей должны разместить зону какого-нибудь типа для bigfirm.biz на каждом DNS-сервере сети Bigfirm, но обмен данными между первичными и вторичными серверами приводит к дополнительной трате ресурсов. Выход — в преобразовании некоторых вторичных DNS-серверов в DNS-серверы зоны-заглушки. Если эти DNS-серверы получают запрос относительно bigfirm.biz, то они не дадут ответа, но им известно, на какой сервер нужно направить запрос. Для этого не требуется проходить по всей иерархии DNS-серверов в поисках источника информации о bigfirm.biz. Затем запрашивающий DNS-сервер задает DNS-серверу зоны-заглушки вопрос относительно bigfirm.biz, и сервер зоны-заглушки передает ответ. Кроме того, серверы зоны-заглушки играют роль серверов кэширования (как практически все DNS-серверы), поэтому следующий компьютер, запросивший информацию о bigfirm.biz, получит ответ немедленно, так как сервер с зоной-заглушкой может предоставить ответ на запрос из своего кэша.

Маленькая зона-заглушка быстро обновляется, поэтому не создает серьезной нагрузки на оперативную память и процессор DNS-сервера. Часто простые серверы кэширования (DNS-серверы без зон) размещаются в сети для преобразования имен клиентов, но разделенная DNS требует, чтобы все DNS-серверы содержали экземпляр каждой AD-зоны леса. Применение зон-заглушек — самый простой способ выполнить это требование.

Условная ретрансляция

Как быть, если администраторы Bigfirm не хотят использовать DNS-серверы с зоной-заглушкой? Существует ли способ разместить в сети группу DNS-серверов, не назначая их вторичными серверами для bigfirm.biz и bigfirm.com? Да, поскольку DNS-служба Windows 2003 обеспечивает метод, называемый условной ретрансляцией.

Для стандартной ретрансляции DNS следует настроить конфигурацию DNS-сервера таким образом, чтобы при поступлении запроса, на который он не может ответить, сервер не обращался за ответом в общедоступную сеть Internet. Вместо этого DNS-сервер просит другой DNS-сервер найти ответ. Процедура, в ходе которой один DNS-сервер просит другой DNS-сервер выполнить поиск, называется ретрансляцией. Можно указать два или несколько ретрансляторов, но я приведу простой пример.

Для условной ретрансляции DNS-сервер настраивается таким образом, что при поступлении запроса о конкретном домене (например, bigfirm.biz), на который у сервера нет ответа, он просит другой DNS-сервер (ретранслятор) найти ответ. Следует обратить внимание на различие: стандартная ретрансляция — это передача безответных запросов о любом домене конкретному DNS-серверу, а условная ретрансляция заставляет передавать ретранслятору только запросы о конкретном домене.

Служба DNS Windows 2003 позволяет указать сервер или серверы, которые будут отвечать на запросы о конкретном домене. Поэтому если компания Bigfirm намерена развернуть 10 вторичных DNS-серверов для bigfirm.biz и bigfirm.com и еще 100 DNS-серверов для разрешения внутренних запросов разделенной DNS bigfirm.biz и bigfirm.com, то нужно просто настроить 100 этих серверов на условную ретрансляцию всех запросов bigfirm.biz на 10 вторичных серверов.

Конечно, различия между зонами-заглушками и условной ретрансляцией весьма тонки, но ими нельзя пренебрегать. Например, какой из этих методов автоматически обновляет информацию о зоне? Предположим, что в зону добавлен DNS-сервер. Как информировать сервер зоны-заглушки или сервер с условной ретрансляцией об этом событии? В случае с сервером зоны-заглушки делать ничего не потребуется — новый сервер появится в зоне-заглушке после репликации. Но если используется условная ретрансляция, то необходимо посетить каждый DNS-сервер и изменить список серверов, к которым следует обращаться в поисках записи bigfirm.com. Насколько я понимаю, составить сценарий для такой процедуры нельзя.

Еще одна проблема, возникающая при сравнении зон-заглушек с условной ретрансляцией, связана с полномочиями. Мы предполагаем, что bigfirm.biz и bigfirm.com — единая дружная компания, но что если между подразделениями существует соперничество? В этом случае размещать зоны-заглушки для серверов bigfirm.com на серверах bigfirm.biz можно лишь с разрешения администраторов bigfirm.com. Для того чтобы серверы bigfirm.biz получали при репликации DNS информацию от серверов bigfirm.com, серверы bigfirm.com должны дать согласие на передачу этой информации при пересылке зоны. По умолчанию DNS-серверы Windows 2000 передают данные любому запросившему их серверу. Но находящиеся в зоне DNS-серверы на базе Windows 2003 по умолчанию выполняют пересылки зоны только на серверы, имеющие в этой зоне NS-записи. Поэтому, прежде чем DNS-сервер bigfirm.biz с зоной-заглушкой bigfirm.com сможет обновить информацию о зоне с DNS-сервера bigfirm.com, этот сервер bigfirm.biz должен получить NS-запись в зоне bigfirm.com. Если кто-то захочет настроить свои DNS-серверы на пересылку всех запросов для сайтов microsoft.com на мой DNS-сервер, я не смогу этому помешать. Но вряд ли кто-нибудь сделает это, так как в результате существенно замедлится процесс разрешения имен для данного лица.

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

Зоны, интегрированные с AD в масштабах всего леса

Третий метод, с использованием зон, интегрированных с AD в масштабах всего леса, расширяет возможности DNS-зон, интегрированных с AD, по сравнению с Windows 2000. DNS-зоны, интегрированные с AD, тиражируют информацию DNS между DNS-серверами, которые также должны быть контроллерами домена (DC). Но на серверах Windows 2000 интегрированная с AD информация перемещается только внутри домена; DNS-серверы bigfirm.biz не могут видеть интегрированную с AD зону bigfirm.com, а DNS-серверы bigfirm.com не видят интегрированную с AD зону bigfirm.biz.

В Windows 2003 можно создать интегрированные с AD DNS-зоны, которые выполняют репликацию не только во всем домене, но и во всем лесу. Поэтому можно сначала сформировать bigfirm.biz и bigfirm.com, как описано в статье «Устраняем проблемы DNS», со стандартными первичным и вторичным серверами. Затем, после того как будут сформированы домены и лес AD, можно просто изменить несколько параметров и настроить все DNS-серверы bigfirm.biz и bigfirm.com на хранение информации в лесу. Впоследствии процесс репликации AD обеспечит синхронизацию всех DNS-серверов. Естественно, все DC должны работать на Windows 2003 — по крайней мере, на это указывают проведенные мною эксперименты.

Марк Минаси — редактоp Windows NT Magazine MCSE и автор книги «Mastering Windows NT Server 4.0» (издательство Sybex). С ним можно связаться по адресу: mark@minasi.com