Изменение типа зоны

На вкладке General (Общие) в поле Туре (Тип) отображается тип зоны. Администратор может в любой момент изменить его, нажав кнопку Change (Изменить). В открывшемся окне (рис. 13.11) администратор должен выбрать новый тип зоны. Обратите внимание, что установленный флажок Store the zone in Active Directory (Хранить зону в Active Directory) свидетельствует о том, что зона интегрирована в Active Directory. Поскольку этот способ хранения не допускает использование дополнительных носителей зон, выбор переключателя Secondary zone (Дополнительная зона) в качестве типа зоны приводит к тому, что данный флажок автоматически снимается и становится недоступным для изменения.

Если зона хранится в Active Directory, администратор может регламентировать доступ к объектам пространства имен DNS на вкладке Security (Безопасность). Эту вкладку имеет каждый объект пространства имен DNS (домены, зоны, ресурсные записи).

Как работает DHCP

Когда новый DHCP-клиент подключается к сети, он запрашивает уникальный IP-адрес у DHCP-сервера. DHCP-сервер выделяет клиенту один адрес из пула адресов. Этот процесс (рис. 13.13) состоит из четырех шагов: 1) клиент DHCP запрашивает IP-адрес (DHCP Discover, обнаружение), 2) DHCP-сервер предлагает адрес (DHCP Offer, предложение), 3) клиент принимает предложение и запрашивает адрес (DHCP Request, запрос) и 4) адрес официально назначается сервером (DHCP Acknowledgement, подтверждение). Адрес клиенту предоставляется на определенный срок, называемый периодом аренды. По истечении половины этого срока клиент должен возобновить аренду. В противном случае, по истечении срока аренды, выделенный клиенту адрес возвращается в пул для повторного использования. В этой ситуации клиент должен инициировать процедуру получения IP-адреса с самого начала.

Конфигурирование зон

Администратор может изменить конфигурацию зоны по своему усмотрению в любой момент. Для выполнения изменений необходимо вызвать окно свойств зоны, выбрав в контекстном меню объекта, ассоциированного с зоной, пункт Properties (Свойства).

Окно свойств (рис. 13.10) обычной зоны состоит из пяти вкладок. В случае зоны, интегрированной в Active Directory, появляется шестая вкладка Security (Безопасность), на которой администратор может ограничить доступ к зоне и ее содержимому.

Механизм постоянных соединений

Инициируя процесс репликации, WINS-сервер устанавливает соединение с другим сервером, в рамках которого осуществляется передача соответствующих изменений. Установка соединения требует затрат определенных системных ресурсов. При этом интенсивные изменения могут снизить общую производительность WINS-сервера.
В Windows Server 2003 реализация службы WINS поддерживает механизм постоянного соединения с партнером по репликации. Данный механизм позволяет устанавливать соединение только один раз, после чего оно сохраняется активным. Любое изменение, осуществляемое в базе данных сервера, будет немедленно реплицировано на другие серверы, с которыми установлено постоянное соединение. Благодаря этому базы данных всех WINS-серверов будут всегда находиться в актуальном состоянии.

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

Методы хранения зоны

Реализация службы DNS в Windows Server 2003 предлагает три метода хранения содержимого зоны:
 хранение зоны в отдельном файле;  хранение зоны в доменном разделе каталога;  хранение зоны в разделах приложений.

Хранение зоны в файле
Этот метод хранения является традиционным и единственным, описанным в спецификации службы DNS. Вся информация о содержимом зоны хранится в специальном текстовом файле. Имя файла образуется из названия зоны, к которому добавляется расширение dns. На DNS-сервере может быть размещено несколько зон. В этом случае каждая зона будет храниться в отдельном файле.

Именно такой метод хранения зоны используется подавляющим большинством реализаций DNS-серверов (в том числе и Windows NT DNS).

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

Для размещения всех файлов, с которыми работает служба DNS (в том числе файлы зоны), используется каталог %SystemRoot%\system32\dns.

Хранение зоны в доменном разделе каталога
В результате интеграции службы DNS со службой каталога стало возможным размещение содержимого зоны в Active Directory. В этом случае зона представляется в виде объекта каталога контейнерного типа, внутри которого размещаются объекты, ассоциированные с ресурсными записями. Зона, содержимое которой хранится в каталоге, получила название зоны, интегрированной в Active Directory (Active Directory-integrated zone). Подобная схема хранения зоны может быть использована только в том случае, если служба DNS устанавливается на контроллере домена.
Для размещения содержимого зоны используется доменный раздел каталога. Совокупность объектов, ассоциированных с зонами DNS, размешается в объекте контейнерного типа MicrosoftDNS в дереве объектов того домена, к которому принадлежит сервер.
Для размещения зоны используется класс объектов каталога dnszone, а для ресурсных записей — класс dnsNode.
Размещение зоны в каталоге позволяет задействовать множество механизмов службы каталога и, в первую очередь, подсистему репликации изменений. Поскольку зона и ресурсные записи рассматриваются в виде объектов, любое их изменение в одной из копий приводит к распространению этих изменений на все остальные копии. Это означает, что изменение зоны может производиться в контексте любого контроллера домена. Другими словами, любой DNS-сервер, установленный на контроллере домена, может выступать в качестве основного носителя для зоны, размещенной в каталоге. Администратор может создать столько носителей зоны, сколько имеется контроллеров домена.
Размещение зоны в доменном разделе каталога имеет один существенный недостаток. Поскольку информация о зоне размещается в доменном контексте каталога, она реплицируется только в пределах домена. Это делает невозможным размещение зоны на DNS-серверах, расположенных в других доменах. Следует также отметить и тот факт, что поскольку зона размещается в доменном разделе, она реплицируется на все контроллеры домена, согласно параметрам по умолчанию. Вы не можете указать, на каких именно контроллерах домена необходима информация о зоне.
От указанных недостатков свободен метод размещения зоны в каталоге в разделах приложений.
Хранение зоны в разделах приложений
Этот метод хранения зоны впервые реализован в Windows Server 2003. Соответственно, он может быть использован только на контроллерах домена, работающих под управлением только этой операционной системы.
Для размещения содержимого зоны могут использоваться разделы приложений (application partitions). (Подробнее разделы приложений описаны в главе 18 "Основные концепции Active Directory".) По умолчанию для размещения содержимого зон в каталоге создаются два раздела приложений:  ForestDnsZones.<имя_DNS_леса> и DomainDnsZones.<имя_DNS_леса>. Однако администратор может создать и другие разделы приложений, которые и будут использоваться для хранения зон.


В табл. 13. 3 кратко описан каждый из этих разделов.
Таблица 13.3. Разделы приложений, по умолчанию используемые для размещения зоны

Мониторинг DHCP-сервера

После того как DHCP-сервер настроен и функционирует, следует периодически осуществлять мониторинг его состояния. Для получения необходимого аналитического материала администратор может активизировать режим протоколирования событий. Для этого на вкладке General (Общие) окна свойств DHCP-сервера нужно установить флажок Enable DHCP audit logging (Разрешить запись журнала DHCP) (рис. 13.20). После этого вся информация, связанная с функционированием сервера DHCP, будет заноситься в текстовый файл журнала.

Мониторинг и оптимизация

В Windows Server 2003 администратор может осуществлять мониторинг DNS-сервера и по его результатам оптимизировать соответствующие параметры настройки. Для этой задачи администратор может использовать следующие инструменты и возможности:
 системный монитор (Performance Monitor); опции протоколирования;  статистика по DNS-серверу;  настройка дополнительных параметров.

Настройка механизма динамической регистрации доменных имен

Если нужно, чтобы регистрация доменных имен выполнялась непосредственно на уровне DHCP-сервера, необходимо в окне свойств объекта, ассоциированного с сервером, перейти на вкладку DNS и установить флажок Enable DNS dynamic updates according to the settings below (Разрешить динамические обновления в DNS в соответствии со следующими настройками) (рис. 13.19). Дополнительно нужно выбрать условия регистрации доменных имен в базе данных DNS. Сервер DHCP будет посылать сообщение службе DNS каждый раз, когда клиенту выдается IP-адрес.

Настройка репликации между WINS-серверами

До настройки репликации нужно тщательно спроектировать топологию репликации WINS. В глобальных сетях это очень важно для успешного развертывания и использования службы WINS.

Настройка сервера

После того как программное обеспечение DNS-сервера было установлено на компьютер, необходимо выполнить его настройку. Фактически процедура начальной настройки DNS-сервера сводится к созданию необходимых зон, которые будут использоваться для хранения ресурсных записей. Если вы устанавливаете DNS-сервер одновременно с созданием первого контроллера домена в корпоративной сети, все операции по конфигурированию соответствующей DNS зоны будут выполнены непосредственно мастером установки Active Directory (Active Directory Installation Wizard). Разумеется, данный метод создания зоны является наиболее предпочтительным. В качестве альтернативы администратор может создать зону самостоятельно.

Необходимо помнить о том, что мастер установки Active Directory не создает на DNS-сервере зон обратного просмотра (reverse domain zone). Поэтому по окончании работы мастера администратор должен создать и настроить эту зону вручную. В Windows Server 2003 создание корневого домена леса не приводит к автоматическому созданию корневого домена в пространстве имен DNS. Таким образом, администратор всегда может сконфигурировать первый установленный DNS-сервер для перенаправления запросов к внешнему пространству имен. Информация о вышестоящих серверах указывается на вкладке Forwarders (Перенаправление) окна свойств DNS-сервера. Например, администратор может указать на этой вкладке информацию о DNS-сервере Интернета.

После того как зона создана, администратор может менять следующие общие свойства зоны:
 запрещать или разрешать использование зоны;  изменять способ хранения зоны;  разрешать динамическое обновление зоны.

Также можно настраивать начальные записи зоны (Start Of Authority, SOA), ресурсные записи, делегирование зон, списки оповещения, использование просмотра WINS, а также управлять зонами обратного просмотра (reverse zone).
Все операции по настройке DNS-сервера могут быть выполнены любым из двух инструментов.
 Оснастка DNS (DnsMgmt.msc) (рис. 13.7). Эта утилита предоставляет администратору графический интерфейс для управления DNS-серверами; она располагается в меню Administrative Tools (Администрирование).  Утилита командной строки DnsCmd.exe. Утилита поставляется в составе Windows Server 2003. Утилита может быть использована, например, при создании пакетных файлов сценариев, а также в ситуации, когда администратор конфигурирует DNS-серверы через коммуникационные линии с ограниченной пропускной способностью.

Последующее изменение конфигурации DNS-сервера может понадобиться по разным причинам, например:
 при изменении имени компьютера-сервера;  при изменении имени домена для компьютера-сервера;  при изменении IP-адреса компьютера-сервера;  при удалении сервера DNS из сети;  при изменении основного сервера (primary server) зоны.

Настройка статического отображения

Запись, отображающая имя в IP-адрес, может быть добавлена в базу данных WINS двумя способами.
 Динамически. Этот тип записей создается в базе данных сервера WINS-клиентами в процессе регистрации локальных NetBIOS-имен.  Статически. Администратор создает записи вручную, определяя статическое отображение (static mapping) NetBIOS-имени на IP-адрес.

Статические отображения используются в ситуации, когда необходимо жестко прописать соответствие "имя-адрес" в базе данных WINS-сервера для хоста, который непосредственно не использует WINS. Например, в некоторых сетях серверы под управлением других операционных систем не могут регистрировать свои NetBIOS-имена непосредственно на WINS-сервере. Наличие в базе данных WlNS-сервера подобных отображений, с одной стороны, препятствует регистрации подобных имен другими хостами, а с другой стороны, позволяет задействовать службу WINS для разрешения этих имен в IP-адреса (что может быть актуально в сети, насчитывающей множество подсетей).

Обзор DHCP

Протокол DHCP представляет собой развитие протокола ВООТР (RFC 951 и 1084), позволявшего динамически назначать IP-адреса (в дополнение к удаленной загрузке бездисковых станций). При этом служба DHCP предоставляет все данные для настройки стека протоколов TCP/IP и дополнительные данные для функционирования определенных серверов. Рассмотрим основные понятия протокола DHCP.
 Область DHCP (scope). Под областью DHCP понимается административная группа, идентифицирующая полные последовательные диапазоны возможных IP-адресов для всех DHCP-клиентов в физической подсети. Области определяют логическую подсеть, для которой должны предоставляться услуги DHCP, и позволяют серверу задавать параметры конфигурации, выдаваемые всем DHCP-клиентам в подсети. Область должна быть определена прежде, чем DHCP-клиенты смогут использовать DHCP-сервер для динамической конфигурации TCP/IP.  Суперобласти (superscope). Множество областей, сгруппированных в отдельный административный объект, представляет собой суперобласть. Суперобласти полезны для решения различных задач службы DHCP.  Пул адресов (address pool). Если определена область DHCP и заданы диапазоны исключения, то оставшаяся часть адресов называется пулом доступных адресов (в пределах области). Эти адреса могут быть динамически назначены клиентам DHCP в сети.  Диапазоны исключения (exclusion range). Диапазон исключения — ограниченная последовательность IP-адресов в пределах области, которые должны быть исключены из предоставления службой DHCP.  Резервирование (reservation). Резервирование позволяет назначить клиенту постоянный адрес и гарантировать, что указанное устройство в подсети может всегда использовать один и тот же IP-адрес.  Период аренды (lease). Под периодом аренды понимается отрезок времени, в течение которого клиентский компьютер может использовать выделенный IP-адрес. В момент истечения половины срока действия аренды клиент должен возобновить аренду, обратившись к серверу с повторным запросом. Следует помнить о том, что продолжительность периода аренды влияет на частоту обновления аренды (другими словами, на интенсивность обращений к серверу);  Опции DHCP (option DHCP). Опции DHCP представляют собой дополнительные параметры настройки клиентов, которые DHCP-сервер может назначать одновременно с выделением IP-адреса. Сервер DHCP поддерживает более 30 опций DHCP согласно RFC 2132. В качестве примера опции DHCP можно привести следующие параметры: IP-адреса шлюза по умолчанию, WINS-сервера или DNS-сервера. Опции могут быть определены как для каждой области отдельно, так и глобально для всех областей, размещенных на DHCP-сервере. Кроме стандартных опций, описанных в спецификации протокола DHCP, администратор может определять собственные опции.

Передача зоны

Процесс синхронизации всех копий зоны, распределенных между множеством носителей, называется передачей зоны (transfer zone). Поскольку изменения могут вноситься только в копии основного носителя, передача зоны всегда осуществляется по направлению от основного носителя к дополнительному. Основной носитель зоны последовательно передает измененную копию зоны каждому дополнительному носителю по отдельности. Хотелось бы заметить, что базовым считается режим передачи, когда передается вся измененная зона целиком.
Время от времени дополнительные носители зоны обращаются к основному носителю зоны, сравнивая номера версий и выявляя факт изменения зоны. Периодичность этих обращений определяется интервалом обновления (refresh interval). С другой стороны, дополнительные носители могут быть извещены (notify) основным носителем о факте изменения зоны.
После того как обнаружен факт изменения, носители запрашивают передачу зоны. Если передача по каким-либо причинам не начинается, носители повторяют свой запрос через определенные промежутки времени, называемые интервалами повторения (retry interval). Если зона не была обновлена в течение периода, называемого интервалом истечения срока действия (expire interval), зона считается устаревшей и не может быть использована для разрешения имен. Интервал обновления, интервал повторения и интервал истечения срока действия определяются на уровне всей зоны посредством соответствующих параметров записи SOA.
Передача зоны инициируется при следующих обстоятельствах:
 истекает интервал обновления зоны;  основной носитель извещает дополнительный носитель о факте изменения зоны;  для зоны определяется новый дополнительный носитель. В этом случае необходимо создать на этом дополнительном носителе копию зоны;  администратор вручную инициирует процесс передачи зоны, используя соответствующий административный инструмент.

Служба DNS, реализованная в Windows Server 2003, позволяет осуществлять передачу не всей зоны целиком, а частично — только произведенные изменения. Этот режим синхронизации получил название инкрементной передани зоны. Использование режима инкрементной передачи зоны позволяет снизить сетевой трафик вызванной репликацией между DNS серверами, поскольку в большинстве случаев изменения сводятся к добавлению или удалению из базы данных зоны одной-двух записей. В этой ситуации нет смысла передавать всю зону.
Использование режима инкрементной передачи зоны возможно только в том случае, если все носители зоны поддерживают его. Если хотя бы один из носителей зоны не поддерживает режим инкрементной передачи, он не сможет получить сведения об изменениях. Как следствие, актуальность данных на этих серверах очень скоро будет утрачена.

Переход от WINS к DNS

В Windows Server 2003 система доменных имен (DNS) рассматривается как основной способ именования ресурсов. Служба WINS используется исключительно по соображениям сохранения совместимости. Со временем администратор может реализовать полный переход от WINS к DNS, оставив в сети только одну службу имен. Процесс удаления из сети функционирующего WINS-сервера называется отзывом (decommissioning).
После того как в сети развернута иерархия DNS-серверов, каждый клиент настраивается таким образом, чтобы он использовал для разрешения имен службу DNS, а не WINS. При этом для каждого WINS-сервера выполняется процедура отзыва в следующей последовательности:
1. В пространстве имен оснастки WINS выберите WINS-сервер для отзыва. После этого перейдите к контейнеру Active Registrations (Активные регистрации).
2. В меню Action (Действие) выполните команду Show records for the selected owner (Найти по владельцу).
3. В открывшемся окне в списке only for selected owner (только для выбранного владельца) укажите WINS-сервер для отзыва и нажмите кнопку ОК.
4. В окне подробного просмотра выделите все элементы.
5. В меню Action (Действие) выберите команду Delete (Удалить).
6. В диалоговом окне Confirm WINS Record Delete (Подтверждение удаления записей) установите переключатель Tombstone WINS records on all WINS servers (Реплицировать удаление записи на другие серверы) и нажмите кнопку ОК.
7. Подтвердите удаление, нажав кнопку Yes (Да) в окне запроса.
8. В дереве выберите элемент Replication Partners (Партнеры репликации).
9. В меню Action (Действие) выполните команду Replicate Now (Запустить репликацию).
10. После проверки репликации выбранных записей на другие серверы остановите и удалите службу WINS на отозванном сервере.

В процессе перехода может потребоваться настроить разрешение доменных имен DNS через службу WINS.

Планирование

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

Понятие области действия

Множество IP-адресов, предназначенных для распределения между DHCP-клиентами одной подсети, рассматривается как единый административный блок, получивший название области действия (scope). Когда DHCP-клиент нуждается в получении адреса, он рассылает по сети широковещательный запрос. Получая этот запрос, DHCP-сервер просматривает имеющиеся области действия, определяя — имеется ли область действия для данной подсети. Если необходимый пул адресов имеется, сервер вступает с клиентом во взаимодействие.
Приступая к настройке службы DHCP, администратор должен создать отдельную область действия для каждой физической подсети. Если в сети имеется несколько DHCP-серверов, необходимо распределить имеющиеся диапазоны адресов между ними. Как правило, для каждой подсети должно быть как минимум два DHCP-сервера, способных выдать необходимый IP-адрес. Для этого имеющиеся диапазоны адресов делятся между двумя DHCP-серверами в некотором соотношении. При этом рекомендуется следующая схема. Для каждой подсети на ближайшем DHCP-сервере размещается 80 процентов имеющихся адресов. Остальные 20 процентов размещаются на одном из оставшихся DHCP-серверов. Этот сервер возьмет на себя обязанности по выдаче адресов для рассматриваемой подсети, если основной сервер выйдет из строя. Применение подобной схемы позволяет гарантировать, что ни один запрос клиента не останется без ответа.

Понятие опций

На уровне областей действия происходит управление процессом выдачи IP-адресов. Для решения задачи однообразного конфигурирования клиентов DHCP-сервер использует механизм опций (options). Опции позволяют предоставить DHCP-клиентам различную информацию о настройках компонентов стека протоколов TCP/IP. Каждая опция идентифицируется посредством уникального 8-разрядного кода, определяющего назначение опции. В спецификации DHCP определено несколько десятков разнообразных опций, в дополнение к которым корпорация Microsoft предложила несколько собственных.
Опции могут быть определены на уровне всего сервера, отдельной области действия, класса и отдельного клиента. В последнем случае требуется, чтобы на DHCP-сервере для клиента был зарезервирован некоторый адрес. Опции, определенные на уровне сервера, позволяют однообразно конфигурировать всех клиентов, обслуживаемых сервером. Опции, определенные на уровне отдельной области действия, будут использованы для настройки клиентов из одной подсети. Администраторы часто используют такую возможность для того, чтобы снабдить клиентов одной подсети информацией о существующих маршрутизаторах.
Отдельно стоит сказать о возможности объединения DHCP-клиентов в специальные классы. Класс рассматривается в данном случае, как некая логическая группа компьютеров, объединенных по некоторому признаку. Например, в один класс можно объединить компьютеры, имеющие доступ к Интернету. Сетевые компоненты этих компьютеров могут требовать расширенной настройки. Чтобы отнести хост к некоторому классу, администратор должен использовать утилиту командной строки Ipconfig с ключом  /setclassid.
Все четыре уровня различаются по приоритетам. Это дает возможность реализовать переопределение опций, что, в свою очередь, позволяет повысить гибкость и удобство конфигурирования клиентов. Для настройки клиентов будут использоваться опции, имеющие наиболее высокий приоритет. Самый низкий приоритет имеют опции, определенные на уровне сервера. Опции, определенные на уровне клиента, обладают наибольшим приоритетом.

Посредник WINS

В спецификации службы WINS описываются три участника: WINS-сервер, WINS-клиенты, а также посредники WINS (WINS proxy). WINS-сервер обрабатывает запросы на регистрацию имен от WINS-клиентов, регистрирует их имена и соответствующие им IP-адреса, а также отвечает на запросы разрешения имен от клиентов, возвращая IP-адрес по имени, при условии, что это имя находится в базе данных сервера. В сети может быть установлено несколько WINS-серверов. Базы данных всех существующих WINS-серверов синхронизируются в результате процесса репликации (рис. 13.22).
Под посредником WINS понимается специальный WINS-клиент, который может обращаться к WINS-серверу от имени других хостов, не способных обратиться к WINS-серверу самостоятельно (рис. 13.23). WINS-посредники используются для поддержки хостов, осуществляющих разрешение NetBIOS- имен методом широковещательных рассылок. Аналогичным методом (путем рассылки широковещательных сообщений) данный тип хостов информирует другие сетевые хосты о занимаемом им NetBIOS-имени. При этом принято говорить, что данный хост работает в режиме b-узла. Поскольку широковещательные сообщения не ретранслируются маршрутизаторами, для нормальной работы сети возникает необходимость устанавливать WINS-серверы в каждой подсети (либо отказаться от клиентов, работающих в режиме b-узла). В качестве альтернативы администратор может сконфигурировать один из WINS-клиентов в качестве WINS-посредника.

Хост, функционирующий в режиме b-узла, не подозревает о существовании WINS-посредника. Этот хост рассылает широковещательные запросы, которые принимаются всеми хостами подсети, в том числе и WINS-посредником. WINS-посредник переадресует эти сообщения WINS-серверу, информируя последний о регистрации или освобождении соответствующего имени. Аналогичным образом хост, функционирующий в режиме b-узла, обращается с широковещательным запросом на разрешение имени. Посредник WINS проверяет собственный локальный кэш имен, и если в нем не обнаружено запрашиваемое имя, переадресует запрос WINS-серверу (см. рис. 13.23).

Пространство имен DNS

Основным компонентом пространства имен DNS являются домены (domain). Домен рассматривается как группа сетевых хостов, объединенных по некоторому логическому признаку. Домены соединяются друг с другом при помощи отношений "родитель-потомок", образуя тем самым некоторую иерархию. Положение домена в этой иерархии определяет уровень домена.
В основании иерархического пространства имен DNS лежит домен, который называется корневым доменом (root domain) (рис. 13.1). Корневой домен является формальным элементом, символизирующим иерархичность пространства доменных имен, выступая в качестве родительского контейнера для всех доменов первого уровня.
Если домены выступают в роли контейнеров или узлов рассматриваемой иерархической структуры, то в качестве листьев выступают сведения о ресурсах этих доменов. Служба DNS определена в рамках стека протоколов TCP/IP, в котором для обозначения любого объекта сети используется понятие хост (host).

Любой объект пространства имен DNS, будь это домен или хост, имеет имя, уникальное в пределах родительского контейнера. Это имя может быть образовано из символов латинского алфавита, цифр и знака тире ("—"). Некоторые версии DNS (включая реализацию DNS в Windows Server 2003) допускают использование в именах объектов символа подчеркивания ("_"), а также символов в формате UTF-8.

Хотелось бы отметить, что непосредственно к имени хоста в пространстве имен DNS не предъявляется требования уникальности в рамках всего пространства имен. Требуется, чтобы это имя было уникально только в рамках родительского контейнера.

Однако непосредственно имена объектов редко используются для их идентификации. Точно идентифицировать объект можно только при помощи его полного доменного имени (Fully Qualified Domain Name, FQDN). Полное доменное имя объекта образуется из имени объекта и суффикса DNS. Суффикс DNS представляет собой перечисление имен всех контейнеров (фактически доменов), находящихся между объектом и корнем пространства имен.


Единственным объектом пространства имен DNS, не имеющим имени, является корневой домен. Для ссылки на него используют точку ("."). В записи полного доменного имени завершающая точка, обозначающая корневой домен, обычно опускается.

В табл. 13.1 перечислены все элементы, образующие пространство имен DNS.
Таблица 13.1.Элементы пространства имен DNS

Проверка работоспособности DNS-сервера

По окончании процесса установки службы DNS необходимо проверить работоспособность сервера. Следует убедиться в том, что DNS-сервер поддерживает нужные зоны прямого и обратного просмотра, а также в том, что зоны могут динамически обновляться.

Развертывание DNS

В данном разделе мы кратко рассмотрим процесс установки и настройки DNS-серверов в корпоративной сети. Этот процесс включает в себя следующие стадии:
 планирование;  установка программного обеспечения DNS-сервера;  настройка DNS;  мониторинг и оптимизация.

Репликация WINS

Если в сети используется несколько WINS-серверов, для поддержания их баз данных в синхронизированном состоянии администратор может настроить между ними репликацию. Рис. 13.24 иллюстрирует ситуацию, когда репликация настроена между двумя WINS-серверами. В показанном на рисунке примере репликация осуществляется в обе стороны. То есть содержимое базы данных одного WINS-сервера реплицируется на другой WINS-сервер и наоборот. Однако возможны и другие варианты: как однонаправленная репликация, так и сложные топологии репликации (например, образующие кольцо). После настройки механизма репликации между WINS-серверами каждый из них будет располагать сведениями обо всех именах NetBIOS, зарегистрированных в корпоративной сети. Благодаря этому любой клиент будет иметь возможность разрешать NetBIOS-имена независимо от того, на каком из WINS-серверов эти имена были зарегистрированы.

Участвующие в репликации WINS-серверы называются партнерами по репликации. В зависимости от того, как именно WINS-сервер инициирует процедуру репликации, он может выступать в одном из трех качеств:
 передающий партнер (Push Partner). В этом сценарии WINS-сервер инициирует процесс репликации самостоятельно, извещая своих партнеров об изменении своей базы данных путем отправки специального сообщения;  принимающий партнер (Pull Partner). В этом случае WINS-сервер запрашивает репликацию изменений у своего партнера по репликации с определенной периодичностью.  передающий/принимающий партнер (Push/Pull Partner). Этот сценарий предполагает использование обоих вышеописанных методов инициации процесса репликации.

Ресурсные записи

Зона рассматривается как база данных, содержащая сведения об элементах пространства имен DNS. База данных состоит из записей, которые, согласно терминологии DNS, называются ресурсными записями (resource records). Каждая ресурсная запись имеет следующий синтаксис:  owner TTL class type RDATA
Характеристика полей ресурсной записи приводится в табл. 13.2.

Таблица 13.2. Поля ресурсной записи

Существует порядка двадцати типов ресурсных записей. Отдельного разговора заслуживает запись типа SOA (Start of Authority). Каждая зона имеет одну запись этого типа. Запись формируется непосредственно в момент создания зоны и определяет все ее параметры, в том числе и те, что регламентируют процесс распространения произведенных изменений между всеми ее носителями. Рассмотрим эти параметры.
Одним из важнейших параметров является номер версии (serial number) зоны. Номер версии позволят обнаружить факт изменения содержимого зоны. Дополнительные носители зоны периодически сверяют номер версии собственной копии с номером версии зоны основного носителя. Поэтому от номера версии требуется, чтобы он последовательно увеличивался с каждым изменением. Критическим является тот факт, что значение номера версии после изменения больше, чем до изменения. Величина разброса между номерами версии не имеет никакого значения.
Ниже приводится пример записи SOA для домена ayan. ru:

ayan.ru. IN SOA root.ayan.ru. administrator.ayan.ru.(

2002082000 ; номер версии

86400 ; интервал обновления (1 день) 86400 ; интервал повторения (1 день) 604800 ; истечение срока действия (7 дней) 86400 ); время жизни записей (1 день)

В этом примере запись SOA начинается с имени определяемого домена — ayan.ru. Доменное имя после ключевого слова SOA определяет основной сервер имен для данного домена root.ayan.ru. Следующее доменное имя (administrator.ayan.ru) определяет адрес электронной почты человека, отвечающего за администрирование зоны. В случае возникновения ошибок в работе DNS-сервера и процессе разрешения имен будет отправлено соответствующее сообщение по указанному адресу. Обратите внимание, что при записи адреса электронной почты не используется символ "@".

Обратите внимание на точку, которой оканчивается каждое доменное имя. Эта точка обозначает корневой домен пространства имен DNS. В данном случае использование этой точки обязательно.

Серверы DHCP, DNS и WINS

Службы DNS и DHCP являются ключевыми сетевыми службами в любой корпоративной сети, построенной на базе стека протоколов TCP/IP. Более того, в среде Windows Server 2003 наличие службы DNS является одним из обязательных условий развертывания службы каталога Active Directory. Служба DNS осуществляет разрешение символических доменных имен в соответствующие им IP-адреса. Удобным дополнением к службе DNS в среде Windows Server 2003 является служба DHCP, упрощающая процесс конфигурации сетевых хостов (в том числе выделение хосту IP-адреса). Кроме того, в среде Windows многими администраторами традиционно используется служба WINS, осуществляющая разрешение символических NetBIOS-имен в соответствующие IP-адреса. Хотя роль этой службы в Windows Server 2003 была значительно уменьшена за счет реализации механизма динамической регистрации доменных имен, служба WINS может по-прежнему использоваться для организации процесса разрешения имен (например, в процессе перехода с Windows NT на Windows Server 2003).
Данная глава посвящена рассмотрению практических вопросов развертывания и настройки трех основных сетевых служб: DNS, DHCP и WINS. В рамках Windows Server 2003 указанные службы могут работать в тесном взаимодействии, обеспечивая простой и эффективный способ конфигурации хостов, а также разрешения символических имен в IP-адреса. Начнем же наш разговор со службы DNS.

Схемы запросов

Рассмотрим процесс разрешения доменных имен в IP-адреса, определенный в рамках спецификации службы DNS (RFC 1034 и RFC 1035). Процесс разрешения доменного имени предполагает строго регламентированное взаимодействие DNS-клиента и цепочки DNS-серверов. Взаимодействие начинается с момента, когда пользователь или приложение используют доменное имя для ссылки на некоторый хост. Соединение с любым хостом осуществляется только на уровне IP-адресов. Поэтому DNS-клиент должен выполнить разрешение доменного имени.
Всю работу по разрешению доменного имени выполняет DNS-сервер. В зависимости от обстоятельств, в процесс разрешения имени может быть вовлечен один сервер или несколько DNS-серверов.

Изначально для разрешения доменных имен использовался специальный текстовый файл, в котором перечислялись IP-адреса и соответствующие им имена компьютеров. Этот файл, получивший название HOSTS (хосты), помещается на сервере. Каждый клиент копировал этот файл и использовал его для разрешения имен. При необходимости разрешения имени клиент просматривает файл HOSTS с целью обнаружения интересующего имени. Подобная схема разрешения имен подходит для небольших статичных сетей. В большой динамичной сети поддержание файла HOSTS в актуальном состоянии на всех клиентах представляет собой трудно решаемую проблему. Служба DNS явилась альтернативой механизму разрешения имен посредством файла HOSTS.

Информация об объектах пространства имен DNS может быть распределена между множеством DNS-серверов. В этом случае DNS-серверы образуют иерархию, подобную иерархии пространства имен (рис. 13.2). В самом простом случае иерархия DNS-серверов может полностью повторять иерархию доменных имен. Каждый DNS-сервер хранит информацию только о части общего пространства имен. Это значит, что сервер самостоятельно способен разрешить только некоторую часть доменных имен. Если сервер не способен разрешить доменное имя самостоятельно, он передает этот запрос дальше, вверх по иерархии.
Каждый DNS-сервер имеет собственный кэш, в который помещаются сведения обо всех доменных именах, разрешенных данным сервером в результате выполнения обращений к другим DNS-серверам. К этому кэшу DNS-сервер обращается всякий раз, когда он не в состоянии выполнить разрешение доменного имени самостоятельно. Только если информация о доменном имени не будет обнаружена в кэше, сервер направит запрос выше по иерархии. Использование кэша позволяет повысить эффективность разрешения имен и снизить нагрузку на коммуникационные линии.
Допускается ситуация, когда DNS-сервер вообще не используется для хранения информации о доменном пространстве имен. Однако он включен в иерархию DNS-серверов. Для разрешения доменных имен этот сервер применяет собственный кэш и запросы к вышестоящим DNS-серверам. Подобный тип DNS-серверов принято называть кэширующими DNS-серверами (caching DNS servers).

Существует две схемы запросов, которые могут использоваться для разрешения доменного имени: рекурсивные и итерационные (итеративные) запросы. Рассмотрим каждую из схем в отдельности.
В ответ на рекурсивный запрос (recursive query) клиента DNS-сервер должен возвратить либо IP-адрес, соответствующий запрашиваемому доменному имени, либо сообщение об ошибке, если это имя не может быть разрешено. В процессе разрешения запроса DNS-сервер рекурсивно предпринимает попытки обнаружить так называемые "ближайшие" серверы ("closest known" name servers). "Ближайшим" считается сервер, являющийся носителем зоны, в которой размещается домен, близкий к запрашиваемому. При этом поиск начинается от корневого сервера имен. Корневой сервер имен предоставляет ссылку на другой сервер имен, который, по его мнению, должен располагать сведениями о запрашиваемом хосте (или домене). Тот, в свою очередь, может предоставить ссылку на другой сервер имен и т. д. В конечном итоге будет найден сервер имен, располагающий сведениями о требуемом доменном имени.
Для пояснения рассмотрим пример (рис. 13.3). Допустим, сервер должен выполнить разрешение доменного имени www.ayan.ru. Первоначально DNS-сервер пытается обнаружить в собственной базе данных сведения о домене ауаn. ru. В случае если сведения о данном домене отсутствуют, DNS-сервер пытается обнаружить серверы имен для данного домена (при этом поиск осуществляется как в собственной базе данных, так и в кэше имен). Если соответствующие серверы имен не могут быть обнаружены, предпринимается аналогичная попытка для домена ru. В определенный момент DNS-сервер обратится к серверам корневого домена. Серверы имен корневого домена не располагают информацией о запрашиваемом домене. Но поскольку запрашиваемый домен располагается внутри домена ru, будет возвращена ссылка на серверы имен домена ru. Обращение к DNS-серверам домена ru даст информацию о серверах имен домена ayan.ru. Обратившись к серверу имен домена ayan.ru, DNS-сервер получит информацию об IP-адресе хоста www.ауаn.ru.

В случае получения итерационного запроса (iterative query) DNS-сервер просматривает собственную базу данных и кэш, пытаясь обнаружить в них сведения о запрашиваемом доменном имени. Если доменное имя не может быть разрешено DNS-сервером самостоятельно, клиенту будет возвращена ссылка на вышестоящий DNS-сервер. Клиент должен повторно отправить запрос указанному серверу имен. Тот, в свою очередь, просматривает собственную базу данных и возвращает либо адрес требуемого хоста, либо ссылается на другой сервер имен. На определенном этапе клиент свяжется с сервером имен, который располагает сведениями о запрашиваемом доменном имени. В этом сценарии основная нагрузка по разрешению имени возлагается на DNS-клиента.

Итерационные запросы могут использоваться в ситуации, когда или DNS-сервер, или DNS-клиент не поддерживают рекурсивные запросы (например, администратор может запретить на уровне DNS-сервера применение рекурсивных запросов).

На рис. 13.4 показан пример итерационного разрешения доменного имени. Допустим хост store.khsu.ru должен установить соединение с хостом movies.yahoo.com.

Для разрешения указанного доменного имени клиент предпринимает следующие шаги:
1. Клиент обращается к серверу имен, обслуживающему домен khsu.ru. Этот сервер имен не обладает информацией о запрашиваемом имени и возвращает клиенту ссылку на вышестоящий сервер имен (обслуживающий домен ru).
2. Клиент обращается к серверу имен, обслуживающему домен ru. Этот сервер имен не обладает информацией о запрашиваемом имени и возвращает клиенту ссылку на корневой сервер имен (домен ".").
3. Клиент обращается к корневому серверу имен. Корневой сервер имен обнаруживает, что запрашиваемое доменное имя принадлежит к домену com. Клиенту возвращается ссылка на сервер имен, обслуживающий домен com.
4. Клиент обращается к серверу имен, обслуживающему домен com. Данный сервер имен находит в своей базе данных записи о сервере имен, обслуживающем домен yahoo.com. Ссылка на этот сервер имен возвращается клиенту.
5. Клиент обращается к серверу имен, обслуживающему домен yahoo.com. Сервер имен находит в своей базе данных запись о хосте movies.yahoo.com. Соответствующий этому имени IP-адрес возвращается клиенту.

Служба DHCP

Каждому хосту, подключенному к сети на базе TCP/IP, должен быть назначен уникальный IP-адрес. Протокол DHCP (Dynamic Host Configuration Protocol, протокол динамической конфигурации хоста) был разработан как средство динамического выделения хостам IP-адресов. Протокол DHCP является открытым промышленным стандартом, упрощающим управление сетями на базе TCP/IP. Этот протокол может быть использован для централизованного управления процессом настройки стека протокола TCP/IP на клиентских машинах (речь идет о таких параметрах, как адрес шлюза по умолчанию или адрес DNS-сервера).
В спецификации протокола DHCP определяются два участника: DHCP-сервер и DHCP-клиенты. Служба клиента DHCP запрашивает у DHCP-сервера параметры для настройки стека протоколов TCP/IP. Служба сервера DHCP обрабатывает клиентские запросы, осуществляя выдачу в аренду IP-адреса из некоторого диапазона. Каждый адрес выделяется на определенный срок. По окончании этого срока хост должен либо продлить срок аренды, либо освободить адрес. Все удовлетворенные запросы пользователя фиксируются службой сервера DHCP в собственной базе данных. Подобное решение позволяет предотвратить выделение одного IP-адреса двум хостам. Одновременно с выдачей IP-адреса DHCP-сервер может также предоставить клиенту дополнительную информацию о настройках стека протоколов TCP/IP, такую как маска подсети, адрес шлюза и адреса серверов DNS и WINS.
Кажется совершенно очевидным, что поддержка этого протокола была реализована в операционной системе Windows Server 2003. В составе Windows Server 2003 реализован как DHCP-клиент (который устанавливается по умолчанию), так и DHCP-сервер (который может быть установлен и сконфигурирован администратором при необходимости). Реализованная в Windows 2000 Server поддержка протокола DHCP обладает характеристиками, перечисленными ниже.
 Интеграция с DNS. DNS-серверы обеспечивают разрешение имен для сетевых ресурсов и тесно связаны со службой DHCP. DHCP-серверы и DHCP-клиенты могут осуществлять динамическую регистрацию выдаваемых IP-адресов и ассоциированных с ними доменных имен в базе данных DNS-сервера. При этом в базе данных DNS-сервера создаются ресурсные записи типа PTR (указатель) и А (адрес).  Улучшенное управление и мониторинг. Новая возможность обеспечивает уведомление об уровне использования пула IP-адресов. Оповещение производится при помощи соответствующего значка либо при помощи передачи сообщения. Сервер DHCP поддерживает SNMP и MIB, что обеспечивает графическое представление статистических данных. Это помогает администратору отслеживать состояние сети, например, число доступных и занятых адресов, число арендных договоров, обрабатываемых за секунду, и т. п.  Распределение групповых адресов. DHCP-сервер может быть использован для выделения клиентам групповых (multicast) адресов. В последнее время появляется большое количество корпоративных приложений, требующих использования групповых адресов (например, видео- или аудио-конференции).  Защита от подмены серверов. Одним из обязательных условий функционирования DHCP-сервера является требование его авторизации в каталоге Active Directory. При каждом запуске служба DHCP-сервера пытается обнаружить в каталоге запись, подтверждающую авторизацию службы. Если подобная запись не найдена, служба сервера не запускается.  Автоматическая настройка клиентов. Служба DHCP-клиента в случае отсутствия в сети DHCP-сервера может выполнить необходимую настройку самостоятельно. Используя для работы временную конфигурацию стека протоколов TCP/IP, клиент продолжает попытки связаться с DHCP-сервером в фоновом режиме каждые 5 минут. При этом автоматическое назначение адреса всегда прозрачно для пользователей. Адреса для такого рода клиентов выбираются из диапазона частных сетевых адресов TCP/IP, которые не используются в Интернете.  Новые специализированные опции и поддержка классов опций. Администратор может создавать собственные классы DHCP (используемые для конфигурации клиентов) в соответствии с необходимостью. Механизм пользовательских классов позволяет применять DHCP в заказных приложениях для сетей масштаба предприятия. Классы поставщиков (vendor classes) могут использоваться для настройки различных функций сетевого аппаратного обеспечения.

Следует также отметить функциональные возможности, которые были впервые добавлены в реализацию службы DHCP в Windows Server 2003.
 Возможность резервного копирования базы данных DHCP. В базе данных DHCP-сервера хранится информация о выданных клиентам IP-адресах, включая информацию о времени окончания аренды. Регистрация этой информации позволяет избежать повторного выделения уже выданных адресов. Повреждение этой базы данных может привести к тому, что работоспособность сети окажется под угрозой. Администратор может выполнять резервное копирование базы данных DHCP-сервера. Созданная резервная копия может использоваться впоследствии для восстановления работоспособности DHCP-сервера.  Возможность задания альтернативной конфигурации DHCP-клиемта. Для DHCP-клиента может быть задана альтернативная конфигурация TCP/IP, что позволяет перемещать компьютер между различными подсетями.

Служба DNS

Служба доменных имен, Domain Name System, DNS, является одним из важнейших компонентов сетевой инфраструктуры Windows Server 2003. Служба доменных имен осуществляет разрешение, или преобразование, символьных имен в IP-адреса. Клиенты доменов на базе Active Directory используют службу DNS для обнаружения контроллеров домена.
Доменная структура каталога отображается на пространство имен DNS. Поэтому процесс проектирования доменной структуры каталога должен происходить одновременно с формированием пространства имен DNS. Ошибки, допущенные при проектировании пространства имен DNS, могут стать причиной недостаточной производительности сети и, возможно, даже привести к ее отказу.

Служба WINS

Служба WINS (Windows Internet Name Service) обеспечивает поддержку распределенной базы данных для динамической регистрации и разрешения NetBIOS-имен. Служба WINS отображает пространство имен NetBIOS и адресное пространство IP друг на друга и предназначена для разрешения NetBIOS-имен в маршрутизируемых сетях, использующих NetBIOS поверх TCP/IP. Следует напомнить, что NetBIOS-имена используются ранними версиями операционных систем Windows как основной способ именования сетевых ресурсов. Служба WINS была разработана с целью упрощения процесса управления пространством имен NetBIOS в сетях на базе TCP/IP.
Основное назначение службы WINS заключается в разрешении NetBIOS-имен в IP-адреса. Процесс разрешения строится на основе базы данных WINS-сервера, содержащей отображения пространства NetBIOS-имен на пространство IP-адресов. Входя в сеть, клиент регистрирует свое имя в базе данных WINS-сервера. При завершении работы клиент отправляет сообщение WINS-серверу, извещая его об освобождении им зарегистрированного имени. На рис. 13.21 показан процесс взаимодействия WINS-клиента и WINS-сервера.

Реализация службы WINS в Windows Server 2003 характеризуется функциональными возможностями, перечисленными ниже.
 Постоянные соединения. Каждый WINS-сервер может быть настроен на обслуживание постоянного соединения с одним или большим количеством партнеров репликации. Это увеличивает скорость репликации и снижает затраты на открытие и завершение соединений.  Управление "захороненными" записями. "Захороненными" (tombstoning) называются записи в базе данных WINS, которые были помечены для удаления. Информация о "захороненных" записях реплицируется между WINS-серверами, что позволяет синхронно удалить эти записи из всех копий базы данных WINS. Реализованный механизм управления позволяет администратору вручную удалять произвольные записи из базы данных WINS.  Улучшенная утилита управления. Для управления WINS-сервером используется специальная утилита WINS, реализованная в виде оснастки ММС.  Расширенная фильтрация и поиск записей. Улучшенная фильтрация и новые поисковые функции помогают находить записи, показывая только записи, соответствующие заданным критериям. Эти функции особенно полезны для анализа очень больших баз данных WINS.  Динамическое стирание записей и множественный выбор. Эти особенности упрощают управление базой данных WINS. При помощи оснастки WINS можно легко манипулировать с одной (или более) записью WINS динамического или статического типа.  Проверка записей и проверка правильности номера версии. Указанный механизм осуществляет проверку последовательности имен, размещенных в базах данных WINS-серверов. Проверка записей сравнивает IP-адреса, возвращаемые по запросу NetBIOS-имени с различных серверов WINS. Механизм проверки правильности номера версии проверяет номер владельца таблицы отображения "адрес-версия".  Возможность экспорта базы данных WINS. При экспорте содержимое базы данных WINS-сервера сохраняется в текстовом файле с запятыми в качестве разделителей. Можно импортировать этот файл в различных форматах (в том числе и в формате Microsoft Excel).  Динамическое обновление клиентов. Для возобновления регистрации локальных NetBIOS-имен не требуется перезапускать WINS-клиента. Обновление информации о зарегистрированных именах администратор может использовать утилиту Nbtstat.exe с параметром -гг.  Консольный доступ только для чтения к оснастке WINS. Эта возможность предоставляется группе WINS Users (Пользователи WINS), которая автоматически создается в момент установки WINS-сервера. Добавляя членов к этой группе, можно предоставить доступ только для чтения к информации о WINS. Это позволяет пользователю, являющемуся членом указанной группы, просматривать (но не изменять!) параметры и содержимое базы данных WINS-сервера.

Создание области действия

Приступим к настройке службы DHCP. Для начала определим необходимые области действия. Запустите оснастку DHCP, которая находится в меню Administrative Tools (Администрирование). В результирующей панели оснастки вызовите контекстное меню объекта, ассоциированного с конфигурируемым DHCP-сервером, и выберите пункт New Scope (Новая область действия). Будет запущен мастер конфигурирования области действия.
Первое окно мастера традиционно предоставляет информацию о его назначении. Поэтому необходимо сразу же перейти во второе окно, в котором требуется определить имя для создаваемой области действия и дать ей краткое описание. В качестве имени можно использовать IP-адрес подсети. Это поможет вам легко ориентироваться в ситуации, когда на DHCP-сервере создано множество областей действия. В этом случае вы всегда сможете точно идентифицировать необходимую область.
В третьем окне мастера следует определить пул IP-адресов, для которых создается область действия. Пул задается путем указания начального и конечного адреса диапазона. Потребуется также предоставить информацию о маске подсети (рис. 13.14).

В следующем окне мастера администратор может определить исключения из только что определенного диапазона. Могут иметься различные причины для этого. Администратор может исключать как отдельные адреса, так и целые диапазоны. Для исключения одиночного IP-адреса необходимо указать его в поле Start IP address (Начальный IP-адрес). Поле End IP address (Конечный IP адрес) необходимо оставить в этом случае пустым. После нажатия кнопки Add (Добавить) введенный адрес будет добавлен в список исключенных из диапазона адресов (рис. 13.15).
Перейдя к следующему окну мастера, необходимо определить для создаваемой области действия время аренды IP-адресов. Время аренды может быть определено на уровне дней, часов и даже минут. Хотя в стандарте протокола DHCP определена возможность аренды адреса на неопределенный срок (бесконечная аренда), реализация службы протокола в Windows Server 2003 не допускает сдачу адреса в бесконечную аренду.

Определив время аренды, администратор фактически заканчивает конфигурирование области действия. В ходе работы мастера, однако, администратор может сразу определить опции DHCP для создаваемой области действия: будет задан вопрос — требуется ли определить опции непосредственно в ходе работы мастера или это будет сделано администратором впоследствии.
Если вы решили воспользоваться помощью мастера в определении опций, вам будет предложено определить несколько наиболее важных опций DHCP.
 Адрес шлюза по умолчанию. Шлюз по умолчанию используется для маршрутизации пакетов, адресованных хостам в других подсетях. Если хост не располагает информацией о шлюзе по умолчанию, он не будет способен взаимодействовать с подобными хостами. В данной опции требуется определить адрес маршрутизатора, который будет осуществлять доставку пакетов хостам в других подсетях (рис. 13.16).  DNS-имя домена и адреса DNS-серверов. Эти опции используются для определения DNS-имени домена и DNS-серверов всех хостов, конфигурируемых посредством данной области действия. DNS-сервер может быть представлен как именем, так IP-адресом. Опция допускает указание нескольких DNS-серверов, что позволит обеспечить гарантированное разрешение имен в случае, если один из серверов выйдет из строя (рис. 13.17).  Адреса WINS-серверов. WINS-серверы используются для организации процесса разрешения NetBIOS-имен хостов в IP-адреса этих хостов. Данная опция позволяет снабдить клиента адресами всех действующих в сети WINS-серверов. Так же, как и в случае с DNS-серверами, можно указать адреса нескольких WINS-серверов (рис. 13.18).

Создаваемые мастером опции определяются на уровне конкретной области действия. Мастер не может создавать опции на других уровнях.

Разумеется, определяемая мастером информация является только малой частью того, что может быть определено посредством механизма опций. После создания области действия администратор может при необходимости вручную создать дополнительные опции.
На заключительном этапе работы мастера нужно решить, будет ли область действия активизирована сразу после ее создания или нет. Активизация области действия приводит к тому, что IP-адреса, определенные в рамках области, могут быть по требованию сданы в аренду. Поэтому если, например, требуется определить ряд дополнительных опций, процесс активизации области действия следует отложить.
При использовании нескольких областей опции по умолчанию могут быть определены на уровне сервера. В этом случае данные опции будут унаследованы всеми областями. Для этого в контекстном меню контейнера Server Options (Опции сервера) необходимо выбрать пункт Configure Options (Настроить опции) и определить требуемые опции.

Структура DNS

Для правильного формирования пространства имен DNS администратор должен ясно понимать структуру службы DNS, ее основные компоненты и механизмы. Для начала определимся с используемой терминологией. Службой DNS называется служба, выполняющая преобразование символических доменных имен в IP-адреса в ответ на запросы клиентов. Компьютер, на котором функционирует экземпляр службы DNS, называется DNS-сервером. Компьютер, обращающийся к DNS-серверу с запросом на разрешение имени, называется DNS-клиентом. Клиент DNS функционирует на уровне прикладного программного интерфейса (API), осуществляя разрешение доменных имен прозрачно для пользователей и приложений. Основная задача DNS-клиента заключается в передаче запроса на разрешение доменного имени DNS-серверу. В ответ на свой запрос клиент должен получить либо IP-адрес, либо сообщение о невозможности разрешить предоставленное серверу доменное имя. Клиент DNS передает полученный IP-адрес приложению, инициировавшему процесс разрешения имени.
Рассмотрим более подробно структуру службы DNS. Четкое понимание назначения всех ее компонентов и возможностей позволит администратору выполнить грамотное развертывание этой службы в корпоративной сети.

Суперобласти

В службе DHCP, реализованной в рамках Windows Server 2003, разработчиками была реализована возможность создания суперобластей (superscope). Суперобласть представляет собой административное объединение стандартных областей. Использование суперобластей действия оправдано в ситуации, когда для одной подсети имеется несколько несмежных диапазонов IP-адресов. При этом каждый диапазон реализуется в виде отдельной области действия. Суперобласть действия выступает в качестве средства объединения получившихся областей действия.
Суперобласти используются для реализации в пределах одной физической подсети нескольких логических подсетей. Каждая логическая подсеть создается подмножеством адресов, заданных в рамках некоторой области, являющейся частью суперобласти. Согласно терминологии DHCP, в этом случае принято говорить о мультисетях (multinets).
Если физическая подсеть, для которой задается суперобласть, соединяется с другой подсетью при помощи маршрутизатора, внутренний интерфейс маршрутизатора должен быть определен в качестве шлюза по умолчанию для всех хостов всех логических подсетей, входящих в суперобласть. При этом для интерфейса маршрутизатора, подключенного к физической подсети, поделенной на логические подсети, необходимо выделить по одному IP-адресу с каждой из логических подсетей. В противном случае хосты, принадлежащие к логическим подсетям, не смогут взаимодействовать с другими подсетями через данный маршрутизатор.

Управление базой данных WINS

После того как в сети установлены WINS-серверы и между ними должным образом настроена репликация, служба WINS требует минимального вмешательства администратора. Тем не менее, существует ряд операций, выполнение которых требует участия администратора:
 сжатие базы;  резервное копирование базы;  проверка целостности базы.

Управление клиентами

Для клиентов Windows конфигурация DNS при настройке свойств TCP/IP для каждого компьютера включает следующие задачи:
 установка имени хоста DNS для каждого компьютера или сетевого подключения;  установка имени родительского домена, которое помещается после имени хоста, чтобы формировать полное (fully qualified) имя домена для каждого клиента;  установка основного DNS-сервера и списка дополнительных DNS-серверов, которые будут использоваться клиентом в ситуации, когда основной сервер недоступен;  установка очередности списка поиска доменов, используемого в запросах для дополнения не полностью заданного имени компьютера.

Упрощенные зоны

Упрощенная зона (stub zone) представляет собой копию зоны, содержащую только те ресурсные записи, которые необходимы для локализации DNS-серверов, являющихся носителями полной версии зоны. Основное назначение упрощенной зоны — идентификация DNS-серверов, которые способны выполнить разрешение доменных имен, принадлежащих к этой зоне.
Любая упрощенная зона состоит из следующих элементов:
 записи типа SOA, определяющей параметры зоны;  записей типа NS, указывающих доменные имена DNS-серверов, выступающих носителями полной версии зоны;  записей типа А, определяющих адреса DNS-серверов.

Упрощенные зоны позволяют облегчить и сократить процесс разрешения доменного имени. Рассмотрим пример. Допустим, на DNS-сервере, обслуживающем домен ayan.ru, содержится упрощенная зона для домена khsu.ru. В этом случае при поступлении запроса на разрешение имени www.khsu.ru DNS-сервер не будет использовать рекурсивный запрос на разрешение этого имени. Вместо этого запрос будет напрямую отправлен некоторому серверу имен домена khsu.ru, адрес которого будет извлечен из упрощенной зоны. Разрешение имени посредством рекурсивных запросов потребовало бы больше шагов, чем в случае использования упрощенной зоны. Следует обратить внимание на то, что в процесс разрешения доменного имени не вовлекаются корневые серверы DNS. Это имеет одно очень важное и полезное следствие.
Упрощенные зоны можно использовать для организации взаимодействия двух лесов доменов, реализующих собственные пространства имен DNS. В этом сценарии в каждом из лесов имеются собственные корневые серверы. Посредством упрощенных зон администратор может создавать ссылки на домены, расположенные в другом пространстве имен DNS.

С упрощенными зонами связано одно ограничение. Упрощенная зона не может располагаться на DNS-сервере, который одновременно выступает в качестве носителя полной версии зоны.

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

Установка DNS-сервера

Для установки сервера DNS нужно воспользоваться процедурами, описанными в разд. "Установка дополнительных сетевых компонентов" главы 12.
Можно также воспользоваться Мастером установки компонентов Windows'. для этого необходимо открыть панель управления, запустить утилиту Add/Remove Programs (Добавить/удалить приложения) и нажать кнопку Add/Remove Windows Component (Добавить/удалить компоненты Windows). В окне мастера (рис. 13.5) следует выбрать компоненты Windows для установки. Администратор может одновременно установить множество компонентов, для этого достаточно установить соответствующие флажки.

Выберите в списке пункт Networking Services (Сетевые службы) и нажмите кнопку Details (Подробнее). В открывшемся окне (рис. 13.6) установите флажок около компонента Domain Name System (DNS). Вернитесь в окно выбора устанавливаемых компонентов и щелкните на кнопке Next (Далее), чтобы приступить к установке. В процессе установки потребуется доступ к дистрибутивным файлам Windows Server 2003.
По окончании работы мастера служба DNS будет установлена на выбранный компьютер. Требуемые файлы будут скопированы на жесткий диск, программное обеспечение сервера можно использовать после перезапуска системы. В группе программ Administrative Tools (Средства администрирования) появится новый инструмент: оснастка DNS. Однако мастер производит установку на сервер только системных файлов. Чтобы служба DNS-сервера начала выполнять свои функции, необходимо должным образом ее сконфигурировать.

Установив сервер DNS, необходимо решить, как будут управляться сервер и файлы зон базы данных DNS. Хотя изменения в файлах базы данных можно вносить и при помощи текстового редактора, этот метод не рекомендуется. Лучше обслуживать сервер DNS и файлы зон базы данных средствами оснастки DNS.

Установка дополнительных DNS-серверов

Установка дополнительных DNS-серверов позволяет повысить надежность корпоративной сети и гарантировать разрешение пользовательских запросов даже в том случае, когда один из DNS-серверов выйдет из строя. Если вы устанавливаете DNS-сервер на контроллере домена, вы можете использовать его в качестве носителя зон, интегрированных в Active Directory. В противном случае сервер может использоваться в качестве дополнительного носителя.
Отдельно следует сказать о конфигурировании DNS-серверов в качестве носителя зон, интегрированных в Active Directory. Для размещения содержимого зоны по умолчанию используется раздел приложений. Реплики раздела приложений создаются администратором на контроллере домена вручную при помощи утилиты Ntdsutil.exe.

Установка и настройка DHCP-сервера

Для установки службы DHCP-сервера необходимо воспользоваться процедурами, описанными в разд. "Установка дополнительных сетевых компонентов" главы 12. После установки сервера в меню Administrative Tools (Администрирование) будет добавлен новый инструмент: оснастка DHCP. Эта утилита используется для настройки DHCP-сервера. Непосредственно после установки службы DHCP-сервера необходимо запустить ее при помощи оснастки Services (Службы). В случае если DHCP-сервер подключен к нескольким сетям, необходимо отключить привязку службы к тем подключениям, которым не требуется поддержка DHCP.
Компьютер, выбранный на роль DHCP-сервера, должен быть сконфигурирован со статическим IP-адресом.

Установка и настройка сервера WINS

Для установки службы WINS-сервера нужно воспользоваться процедурами, описанными в разд. "Установка дополнительных сетевых компонентов" главы 12. После установки службы WINS в меню Administrative Tools (Администрирование) появится новая оснастка WINS, которая предназначена для настройки и конфигурирования WINS-сервера (рис. 13.25).

Компьютер, выбранный на роль WINS-сервера, должен быть сконфигурирован со статическим IP-адресом.

Установка первого DNS-сервера

Приступая к развертыванию службы DNS в корпоративной сети, администратор должен принять решение о том, будет ли служба DNS создана до установки Active Directory, либо развертывание обеих этих служб будет проходить одновременно. В первом случае необходимо помнить, что до тех пор, пока не установлена служба каталога, вы сможете использовать только один метод хранения содержимого зоны — в виде текстового файла. Как следствие, часть функциональных возможностей будет недоступна. Поэтому рекомендуется осуществлять развертывание службы DNS и службы каталога Active Directory одновременно.
Если вы устанавливаете DNS-сервер одновременно с созданием первого контроллера домена в корпоративной сети, все операции по настройке DNS зоны будут выполнены мастером установки Active Directory (Active Directory Installation Wizard). Этот мастер будет подробно описан в главе 19 "Проектирование доменов и развертывание Active Directory". Если на момент запуска мастера DNS-сервер уже существует, администратору сначала придется вручную создать зону и произвести ее конфигурирование.
Рассматриваемый мастер автоматически создает в пространстве имен DNS все дочерние домены, потребность в которых возникает при создании доменов Active Directory. Однако перед созданием в лесу доменов нового дерева доменов администратор должен вручную создать на DNS-сервере соответствующую зону.

Мастер установки Active Directory не создает на DNS-сервере зон обратного просмотра (reverse domain zone). По окончании работы мастера администратору необходимо вручную создать эту зону и сконфигурировать ее. После этого, администратор должен выполнить регистрацию адресов и имен хостов в этой зоне (либо вручную, либо используя на хостах утилиту Ipconfig с ключом /registerdns).

В Windows 2000 при создании корневого домена леса Active Directory на автоматически устанавливаемом и конфигурируемом DNS-сервере создается зона "" корневого домена пространства имен DNS. Таким образом, создается изолированное пространство имен DNS, т. к. все запросы клиентов замыкаются на корневом DNS-сервере. Другими словами, клиенты не могут, используя этот DNS-сервер, разрешить запросы ко внешним пространствам имен (например, к Интернету).
В Windows Server 2003 зона корневого домена "." автоматически не создается. Таким образом, все запросы к Интернету могут разрешаться через корневые серверы, указанные на вкладке Root Hints (Корневые ссылки) в окне свойств DNS-сервера. Более того, администратор всегда может сконфигурировать первый установленный DNS-сервер для перенаправления запросов к внешнему пространству имен. Информация о вышестоящих серверах указывается на вкладке Forwarders (Перенаправление) окна свойств DNS-сервера. Например, администратор может указать на этой вкладке информацию о DNS-сервере Интернета (рис. 13.8). Позднее мы еще вернемся к рассмотрению этого вопроса.
В ходе создания корневого домена леса мастер установки Active Directory создает на DNS-сервере две зоны: зона для корневого домена леса и зона _msdcs. <имя_DNS_леса>. Обе создаваемые зоны по умолчанию являются интегрированными в Active Directory. Первая зона размещается в разделе приложений DomainDnsZones.<имя_DNS_леса>, а вторая в разделе приложении ForestDnszones.<HMH_DNS_лeca>. Таким образом, информация о первой зоне может реплицироваться на все DNS-серверы в домене, в то время как информация о второй зоне может реплицироваться на все DNS-серверы в лесе. Для примера на рис. 13.9 показано содержимое DNS-сервера после создания корневого домена леса khsu.ru.

Установка режима динамического обновления

Режим динамической регистрации устанавливается посредством параметра Allow dynamic updates (Разрешить динамическое обновление) вкладки General (Общие) окна свойств зоны. Чтобы разрешить динамическое обновление, установите значение этого параметра в Yes. Для активизации режима безопасного обновления необходимо установить значение в Only secure updates (Только безопасное обновление).

Возможности DNS-клиентов

В составе Windows Server 2003 имеется служба DNS-клиента. DNS-клиент осуществляет взаимодействие с DNS-сервером с целью разрешения доменных имен в IP-адреса. При этом реализация DNS-клиента в Windows Server 2003 характеризуется следующими возможностями:
 клиентское кэширование. Ресурсные записи (RR), полученные как ответы на запросы, добавляются в клиентский кэш. Эта информация хранится в течение заданного времени и может использоваться для ответа на последующие запросы;  кэширование отрицательных ответов. В дополнение к кэшированию положительных ответов на запросы от серверов DNS, служба DNS также кэширует отрицательные ответы на запросы. Отрицательный ответ приходит, если ресурсная запись с запрошенным именем не существует. Кэширование отрицательных ответов предотвращает повторные запросы для несуществующих имен, снижающие производительность клиентской службы;  блокировка неотвечающих серверов DNS. Клиентская служба DNS использует список поиска серверов, упорядоченных по предпочтению. Этот список включает все серверы DNS, настроенные для каждого из активных сетевых подключений в системе. Система способна перестраивать этот список, основываясь на следующих критериях: предпочтительные серверы DNS имеют высший приоритет, а остальные серверы DNS чередуются. Неотвечающие серверы временно удаляются из списка.

и Windows Server 2003 обладает

Выборочное перенаправление запросов

Механизм выборочного перенаправления запросов (conditional forwarding) позволяет осуществлять перенаправление пользовательских запросов на другие DNS-серверы, основываясь на информации о доменном имени, включенном в запрос. Обычный режим перенаправления (forwarding) предполагает перенаправление всех запросов на определенный DNS-сервер или группу серверов. Фактически механизм выборочного перенаправления позволяет выполнять на DNS-сервере сортировку запросов. Некоторую часть запросов сервер способен разрешить сам, другая часть будет перенаправлена различным серверам имен.
Выборочное перенаправление позволяет повысить эффективность разрешения запросов за счет сокращения количества операций. Так же, как и механизм упрощенных зон, выборочное перенаправление может быть использовано как средство организации взаимодействия двух лесов доменов, реализующих собственные пространства имен DNS.
Поскольку механизм выборочного перенаправления способен решать те же задачи, что и упрощенные зоны, очень трудно увидеть различия между ними. Какой из двух механизмов выбрать в той или иной ситуации? Механизм выборочного перенаправления позволяет перенаправить запросы пользователей по разрешению определенного доменного имени на конкретный DNS-сервер. Использование же упрощенных зон для разрешения определенного доменного имени дает ссылку на некоторый набор DNS-серверов, способных выполнить это разрешение. Поэтому, если администратору необходимо контролировать процесс обращения пользователей к корпоративным DNS-серверам (например, с целью управления нагрузкой на серверы или для сокращения нагрузки на линии связи с ограниченной пропускной способностью), он должен использовать механизм выборочного перенаправления.
С другой стороны, использование механизма упрощенных зон позволяет реализовать большую гибкость в управлении DNS-серверами. Изменение списка DNS-серверов, выступающих в качестве носителей полноценной копии зоны (а соответственно, способных выполнить разрешение определенного множества доменных имен), приводит к автоматическому обновлению упрошенной зоны на всех ее носителях. В случае же использования механизма выборочного перенаправления администратору придется вручную изменить конфигурацию всех вовлеченных DNS-серверов.

Зоны

Деление доменного пространства имен между DNS-серверами осуществляется посредством механизма зон (zone). Зона представляет собой базу данных, в которой содержатся записи о соответствии некоторого множества доменных имен IP-адресам. Каждая зона представляет собой фрагмент доменного пространства имен. Следует рассматривать зоны как основной административный элемент, на уровне которого происходит как управление пространством имен в целом, так и управление процессом разрешения имен. Зоны, используемые для размещения содержимого обратных доменов, называются зонами обратного просмотра (reverse lookup zone).
Границы зоны не определяются доменной структурой. Одна зона может включать в себя несколько доменов, в то время как объекты, принадлежащие к одному домену, могут быть размещены в нескольких зонах. Осуществляя разделение доменного пространства имен на зоны, необходимо исходить, в первую очередь, из удобства администрирования.
Зону можно разместить на нескольких серверах. На каждом из вовлеченных DNS-серверов размещается отдельная копия зоны. Для поддержания этих копий в согласованном состоянии используется модель репликации с одним основным участником (single-master replication). Один из DNS-серверов выступает в качестве основного носителя зоны (primary zone). Только основной носитель зоны обладает возможностью вносить изменения в ее содержимое (другими словами, имеет право на запись).
Остальные DNS-серверы располагают копией зоны, доступной только для чтения. Эти серверы называются дополнительными носителями зоны (secondary zone). Изменения, произведенные в копии зоны основным носителем, реплицируются на дополнительные носители. Использование нескольких носителей зоны позволяет, с одной стороны, распределить нагрузку между несколькими серверами, а с другой стороны, реализовать некоторый уровень отказоустойчивости. В случае выхода из строя одного из носителей зоны разрешение имен будет осуществляться остальными носителями зоны.
На каждом DNS-сервере может быть размещено несколько зон. В этом случае каждая зона конфигурируется отдельно. Один и тот же сервер может выступать как основным, так и дополнительным носителем для различных зон.

---