[PMR]

Каждому домену или субдомену ставится в соответствие сервер имен, который является первичным (primary) для зоны, в состав которой входит данный до¬мен или субдомен. Помимо первичного, в сети могут функционировать вторичные (secondary) серверы имен зоны. Вторичные серверы имен содержат копию файла зоны. Изменения можно вносить только в файл зоны, расположенный на первичном сервере имен зоны. Процесс перемещения информации о зоне с одно¬го DNS-сервера на другой DNS-сервер называется трансфертом зоны (zone transfer).
В ходе трансферта зоны один из серверов передает информацию о зоне, а другой принимает эту информацию. Первый сервер называется главным (master), а вто¬рой — подчиненным (slave). На первый взгляд может показаться, что в ходе трансферта главный сервер всегда является первичным, однако это не всегда так. На самом деле в некоторых случаях один вторичный сервер может запросить информацию о зоне у другого вторичного сервера. Таким образом, первый из них будет называться вторичным главным (secondary master), а второй — вторичным подчиненным (secondary slave).
Вторичные серверы DNS, как и резервные контроллеры доменов Windows, слу¬жат для распределения нагрузки и повышения надежности. В отличие от кон¬троллеров доменов Windows, один и тот же сервер DNS может быть одновремен¬но первичным для одной зоны (или нескольких зон) и вторичным для другой зоны (или нескольких зон). В частности, в рассмотренном ранее примере пер¬вичный сервер имен для зоны, включающей в себя домены shazbot.com и sales.shazbot.com, может выполнять функции вторичного сервера имен для зоны, включающей в себя домен support.shazbot.com, и наоборот. С точки зрения кли¬ента первичные и вторичные серверы имен ничем не отличаются, так как и те и другие выполняют разрешение имен. Обслужить запрос клиента может любой из них.
Зона может быть интег¬рирована в каталог Active Directory. При этом каждый из контроллеров доменов Windows 2000, на которых установлена служба DNS, может выполнять функции первичного DNS-сервера зоны. Таким образом, обрабатывать запросы на обнов¬ление файла зоны может любой из контроллеров доменов, на которых работает служба DNS. В случае если зона интегрирована в каталог Active Directory, поня¬тие главного файла зоны (master zone file) теряет смысл, так как информация о зоне хранится не в отдельном файле, а в объектах каталога Active Directory. Зона, интегрированная в Active Directory, может обладать вторичными сервера¬ми имен. Например, вторичные серверы имен могут поддерживаться провайде¬ром Интернета для балансировки нагрузки и повышения надежности. Вторич¬ный сервер зоны также может быть предназначен для обслуживания клиентов, подключающихся к ресурсам внутренней сети из Интернета. Вторичные серверы имен хранят информацию о зоне, интегрированной в Active Directory, в традици¬онных файлах зоны, несмотря на то, что главная копия сведений о зоне содержит¬ся в каталоге Active Directory. Также следует отметить, что контроллер домена, на котором работает служба DNS, может обслуживать как зоны, интегрирован¬ные в Active Directory, так и стандартные, не интегрированные зоны. Информа¬ция о стандартных зонах будет храниться на контроллере домена в виде традици¬онных файлов зоны.

[PMR]

Чтобы создать рабочую среду DNS, в которой функционирует несколько дубли¬рующих друг друга DNS-серверов, требуется выполнить две задачи. Во-первых, помимо первичного, необходимо создать по крайней мере один вторичный сервер имен. Во-вторых, необходимо сообщить клиентам DNS о существовании нескольких дублирующих друг друга серверов DNS, и о возможности направления запросов к любому из них.
Основная функция вторичного сервера DNS — обслуживание клиентов в случае, если первичный сервер DNS вышел из строя, находится слишком далеко или перегружен. Часто провайдер, обеспечивающий связь между вашей сетью и Интернетом, настраивает один из своих собственных DNS-серверов в качестве вторичного для зоны имен вашей сети. При этом удаленные сетевые узлы, ж обратиться к ресурсам вашей сети, получают возможность использовать для этой цели вторичный DNS-сервер, работающий на стороне вашего провайдера. Одна¬ко такой сервер не в состоянии обслуживать внутренних клиентов вашей сети, расположенных по другую сторону брандмауэров и других механизмов защиты. На случай, если внутренний первичный сервер имен вашей сети выйдет из строя, рекомендуется включить в состав сети внутренний вторичный DNS-сервер.
Вторичный сервер может стать бесценным источником информации в случае, если файлы зоны, расположенные на первичном сервере, безвозвратно утеряны или повреждены и не поддаются восстановлению. В подобной ситуации вы мо¬жете просто скопировать файл зоны, расположенный на вторичном сервере, на первичный сервер. Если важные записи о ресурсах были удалены из файла зоны на первичном сервере относительно недавно, немедленно остановите работу службы DNS на вторичном сервере для того, чтобы предотвратить трансферт зоны. После этого используйте не модифицированный файл зоны вторичного сервера для того, чтобы восстановить утерянные записи.
Как уже упоминалось, для того чтобы клиенты DNS могли воспользоваться ус¬лугами дублирующих друг друга серверов DNS, необходимо сообщить клиентам о существовании этих серверов. Каждый клиент должен быть настроен таким об¬разом, чтобы он знал о существовании по крайней мере двух серверов имен. В случае если один из этих серверов недоступен, клиент сможет воспользоваться Услугами другого сервера имен. На одной из страниц свойств сетевого окруже¬ния любого из клиентов Windows можно ввести несколько IP-адресов серверов Имен. Также можно настроить порядок, в котором будут опрашиваться эти серве¬ры. Прежде всего клиент будет обращаться к первому серверу в списке. Если этот сервер не ответит на запрос, клиент обратиться к следующему в списке. Если клиент сможет установить связь с первым сервером в списке, но при этом Данный сервер не сможет разрешить интересующее клиента доменное имя, клиент прекратит попытки связи. В подобной ситуации другие серверы из списка опрашиваться не будут.
Подобный подход таит в себе проблему. Представьте, что клиент настроен таким образом, что запрос на разрешение доменного имени прежде всего адресуется вторичному серверу и только в случае, если вторичный сервер не ответил, клиент обращается к первичному серверу. Теперь предположим, что новая запись о ресурсе была добавлена в файл зоны первичного сервера, однако трансферта зоны еще не произошло. В подобной ситуации при попытке разрешения доменного имени, зарегистрированного в базе данных DNS, клиент получит сообщение о том, что такого имени не существует. К счастью, данная проблема является временной. Как только произойдет трансферт зоны, содержимое файла зоны на вторичном сервере станет таким же, как исодержимое файла зоны первичного сервера, и клиент сможет разрешить интересующее его доменное имя.

[PMR]

Служба имен Интернета, используемая Windows (Windows Internet Name Service), обслуживает динамическую базу данных, обращаясь к которой клиенты могут регистрировать собственные имена, а также определять IP-адреса других сетевых узлов, исходя из их символьных имен. Динамическая природа WINS позволяет в каждый момент времени предоставлять клиентам корректную информацию о со¬ответствии между IP-адресами и именами систем, работающих в сети и настро¬енных на использование WINS. Точно так же, как и DNS, служба WINS хранит в своей базе данных сведения о соответствии между символьными именами и IP-адресами и сообщает эти сведения своим клиентам в ответ на их запросы. Од¬нако в отличие от DNS символьные имена, хранящиеся в базе данных WINS, не являются именами сетевых узлов. На самом деле служба WINS хранит информа¬цию об именах стандарта NetBIOS. Эти имена служат для идентификации поль¬зователей и служб, использующих те или иные IP-адреса.
Формат имен NetBIOS отличается от формата имен DNS. Имена NetBIOS име¬ют фиксированную длину (16 символов). Внутри каждого имени содержится код, сообщающий, ресурсу какого типа соответствует данное имя. Если для иден¬тификации ресурса используется менее 15 символов, неиспользуемые символы заполняются пробелами. Шестнадцатый по счету символ любого имени NetBIOS всегда содержит код типа ресурса.
Например, компьютер Akira может зарегистрировать в базе данных WINS сле¬дующее имя:
AKIRA [OOh]
В процессе начальной загрузки клиент WINS регистрирует в базе данных WINS имя компьютера, а также может зарегистрировать одну или несколько работаю¬щих на этом компьютере служб. Например, клиент Windows 95, который предо¬ставляет удаленным сетевым пользователям доступ к своим файлам через сеть, помимо своего собственного имени должен зарегистрировать в базе данных WINS дополнительное имя, идентифицирующее службу сервера, а контроллер домена должен зарегистрировать в WINS дополнительное имя, идентифицирую¬щее его как контроллер домена. Как правило, система, оснащенная Windows 2000 Professional, регистрирует в WINS службу Server, службу Workstation, а также службу Messenger, имя которой отображается на имя пользователя, подключен¬ного к системе в данный момент.
Если другой компьютер пытается зарегистрировать имя, которое в настоящий момент уже зарегистрировано, сервер WINS ответит ему отказом. Клиенты WINS регистрируют собственные имена в процессе начальной загрузки, а при за¬вершении работы они освобождают эти имена. Если клиент освободил исполь¬зуемое им имя, это имя сохраняется в базе данных WINS, однако если при этом кто-нибудь другой попытается зарегистрировать это имя, сервер не будет ему от¬казывать.

Записи в базе данных WINS создаются не только для компьютеров и пользовате¬лей, но также и для групп. Записи компьютеров и пользователей называются уникальными (unique), в то время как записи групп называются групповыми (group). Групповая запись регистрируется в WINS в момент, когда представи¬тель или глава этой группы регистрирует себя в WINS. Примером групповой записи является запись, которая позволяет клиентам Active Directory найти под¬ходящий для них контроллер, чтобы аутентифппировать себя в каталоге. Груп¬повая запись содержит в себе список IP-адресов ее членов. Благодаря этому кли¬енты могут узнать IP-адреса компьютеров, обратившись к одному из которых можно выполнить ту или иную задачу. Например, групповая запись, используе¬мая клиентами Active Directory для аутентификации, может содержать в себе символьное имя, идентифицирующее домен Windows 2000, и список, включаю¬щий в себя до 25 IP-адресов контроллеров этого домена. Клиент, обратившийся к WINS для того, чтобы найти подходящий для аутентификации контроллер доме¬на, в ответ получит список адресов, относящихся к его домену. После этого он может выбрать один из контроллеров, расположенных в рамках его локальной подсети. Если в локальной подсети клиента не существует ни одного контролле¬ра, для аутентификации клиент может использовать любой другой IP-адрес из полученного им списка.

[PMR]

До появления динамической DNS (Dynamic DNS, DDNS) для разрешения имен в рабочей среде с динамически изменяющимися IP-адресами можно было ис¬пользовать комбинацию DNS, DHCP и WINS. Клиенты DHCP автоматически становились клиентами WINS, а служба DNS была настроена таким образом, чтобы при отсутствии возможности разрешить доменное имя на основании све¬дений, извлекаемых из файла зоны, она обращалась за помощью к службе WINS. Операционная система Windows 2000 Server содержит в себе службу DNS, кото¬рая позволяет регистрировать доменные имена динамически, однако эту систему по-прежнему можно настроить таким образом, чтобы при необходимости DNS обращалась для разрешения имени к WINS. Этот механизм называется WINS Lookup (поиск в WINS). Таким образом, в процессе разрешения имен сервер DNS может обращаться к базе данных WINS, что существенно расширяет воз¬можности системы разрешения имен.