Серверная операционная система Microsoft Windows 2003
Серверы 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.
Служба DNS
Служба доменных имен, Domain Name System, DNS, является одним из важнейших компонентов сетевой инфраструктуры Windows Server 2003. Служба доменных имен осуществляет разрешение, или преобразование, символьных имен в IP-адреса. Клиенты доменов на базе Active Directory используют службу DNS для обнаружения контроллеров домена.
Доменная структура каталога отображается на пространство имен DNS. Поэтому процесс проектирования доменной структуры каталога должен происходить одновременно с формированием пространства имен DNS. Ошибки, допущенные при проектировании пространства имен DNS, могут стать причиной недостаточной производительности сети и, возможно, даже привести к ее отказу.
и Windows Server 2003 обладает
Служба DNS в Windows 2000 Server и Windows Server 2003 обладает общими функциональными возможностями, перечисленными ниже.
DNS-сервер, полностью соответствующий стандартам RFC. Служба DNS базируется на открытых протоколах и полностью соответствует промышленным стандартам (RFC). Способность взаимодействия с другими реализациями DNS-серверов. Поскольку служба DNS построена на основе существующих стандартов, она успешно взаимодействует совместно с большинством других реализаций DNS, например, использующих программное обеспечение Berkeley Internet Name Domain (BIND). Поддержка Active Directory. Как уже упоминаюсь ранее, служба DNS является обязательным условием развертывания Active Directory. Служба DNS используется как основной механизм обнаружения ресурсов в Active Directory-доменах. В свою очередь, DNS-серверы могут использовать каталог Active Directory для размещения баз данных зон. При этом процесс репликации зон осуществляется непосредственно средствами Active Directory. Интеграция с другими сетевыми службами Microsoft. Служба DNS обеспечивает интеграцию с другими службами Windows и содержит функции, не описанные в RFC. Это касается интеграции со службами WINS и DHCP. Улучшенные административные инструменты. Для управления DNS-серверами администратор может использовать специальную оснастку с улучшенным графическим интерфейсом. Кроме того, в составе операционной системы имеется целый ряд мастеров конфигурации, позволяющих выполнять повседневные задачи по администрированию сервера. Также имеется ряд дополнительных утилит, помогающих управлять и поддерживать серверы DNS и клиентов в сети. Поддержка протокола динамического обновления в соответствии с RFC. Служба DNS позволяет клиентам динамически обновлять ресурсные записи при помощи динамического протокола обновления DNS (стандарт RFC 2136). Это облегчает администрирование DNS, избавляя от необходимости вносить эти записи вручную. Компьютеры под управлением Windows 2000, Windows XP и Windows Server 2003 могут динамически регистрировать свои доменные имена. Поддержка инкрементных передач зоны между серверами. Передача зоны осуществляется между DNS-серверами в качестве средства синхронизации отдельных экземпляров базы данных зоны. Стандартная процедура передачи зоны предполагает копирование всей базы данных зоны с одного сервера на другой. Инкрементная передача зоны позволяет копировать только сведения об изменениях. Поддержка новых типов ресурсных записей. Служба DNS обеспечивает поддержку нескольких новых типов ресурсных записей (RR): записи SRV (расположение службы) и АТМА (адрес ATM), что значительно расширяет возможности использования DNS в глобальных сетях. Кроме того, реализация службы DNS в Windows Server 2003 имеет несколько новых функциональных возможностей, отличающих ее от реализации в предыдущих версиях Windows (в частности Windows 2000).
Выборочное перенаправление запросов (Conditional forwarding). Данный механизм позволяет осуществлять перенаправление запросов клиентов на различные DNS-серверы, основываясь на информации о доменном имени, содержащемся в запросе. Механизм выборочного перенаправления может быть использован как средство организации взаимодействия двух лесов доменов, реализующих собственные пространства имен DNS. Упрощенные зоны (Stub Zones). Упрощенная зона представляет собой фрагмент зоны, содержащий только те ресурсные записи, что необходимы для нахождения DNS-серверов, являющихся носителями полной версии зоны. Основное назначение упрощенной зоны — идентификация DNS-серверов, которые способны выполнить разрешение доменных имен, принадлежащих к этой зоне. Новые способы хранения базы данных зоны в каталоге Active Directory. В случае, когда DNS-сервер установлен на контроллере домена, для размещения содержимого зоны могут использоваться специальные разделы при/южений (application partitions). При этом указанные разделы приложений могут размещаться только на тех контроллерах домена, которые являются DNS-серверами. Улучшенные механизмы обеспечения безопасности службы DNS. Система доменных имен (DNS) разрабатывалась как открытый протокол, что делает ее достаточно чувствительной к разнообразным атакам. В связи с этим в Windows Server 2003 разработчиками в реализацию службы DNS был добавлен целый ряд функциональных возможностей, направленных на защиту этой службы от различных атак (в том числе и от атак типа "отказ в обслуживании" — Denial of Services, DoS). Расширенные возможности протоколирования событий, связанных с функционированием DNS-сервера. В Windows Server 2003 администратор может получить в свое распоряжение более подробную аналитическую информацию о функционировании DNS-сервера. Эти сведения позволят ему, с одной стороны, получить информацию о режиме работы сервера, а с другой стороны, выявить причины неполадок в случае их возникновения. Поддержка протокола DNSSEC (DNS Security Extensions). Протокол DNSSEC определен в стандарте RFC 2535. Реализованная в Windows Server 2003 поддержка этого протокола позволяет DNS-серверам выступать в качестве дополнительных носителей DNSSEC-совместимых защищенных зон. Поддерживаются ресурсные записи типа KEY, SIG и NXT. Поддержка подписанных зон или ресурсных записей в Windows Server 2003 не реализована. Поддержка механизма EDNSO (Extension Mechanisms for DNS). Механизм EDNSO позволяет использовать UDP-пакеты размером больше 512 октетов. Управление процессом автоматической регистрации серверов имен в базе данных зоны. В Windows Server 2003 администратор может запретить автоматическую регистрацию серверов имен (что фактически равносильно запрещению автоматического создания ресурсных записей NS-типа) в базе данных зоны. Новые групповые политики для управления настройками DNS на клиентских компьютерах и контроллерах домена.
Возможности DNS-клиентов
|
Структура DNS
Для правильного формирования пространства имен DNS администратор должен ясно понимать структуру службы DNS, ее основные компоненты и механизмы. Для начала определимся с используемой терминологией. Службой DNS называется служба, выполняющая преобразование символических доменных имен в IP-адреса в ответ на запросы клиентов. Компьютер, на котором функционирует экземпляр службы DNS, называется DNS-сервером. Компьютер, обращающийся к DNS-серверу с запросом на разрешение имени, называется DNS-клиентом. Клиент DNS функционирует на уровне прикладного программного интерфейса (API), осуществляя разрешение доменных имен прозрачно для пользователей и приложений. Основная задача DNS-клиента заключается в передаче запроса на разрешение доменного имени DNS-серверу. В ответ на свой запрос клиент должен получить либо IP-адрес, либо сообщение о невозможности разрешить предоставленное серверу доменное имя. Клиент DNS передает полученный IP-адрес приложению, инициировавшему процесс разрешения имени.
Рассмотрим более подробно структуру службы DNS. Четкое понимание назначения всех ее компонентов и возможностей позволит администратору выполнить грамотное развертывание этой службы в корпоративной сети.
Пространство имен DNS
Основным компонентом пространства имен DNS являются домены (domain). Домен рассматривается как группа сетевых хостов, объединенных по некоторому логическому признаку. Домены соединяются друг с другом при помощи отношений "родитель-потомок", образуя тем самым некоторую иерархию. Положение домена в этой иерархии определяет уровень домена.
В основании иерархического пространства имен DNS лежит домен, который называется корневым доменом (root domain) (рис. 13.1). Корневой домен является формальным элементом, символизирующим иерархичность пространства доменных имен, выступая в качестве родительского контейнера для всех доменов первого уровня.
Если домены выступают в роли контейнеров или узлов рассматриваемой иерархической структуры, то в качестве листьев выступают сведения о ресурсах этих доменов. Служба DNS определена в рамках стека протоколов TCP/IP, в котором для обозначения любого объекта сети используется понятие хост (host).
Рис. 13.1. Пространство имен DNS
Любой объект пространства имен DNS, будь это домен или хост, имеет имя, уникальное в пределах родительского контейнера. Это имя может быть образовано из символов латинского алфавита, цифр и знака тире ("—"). Некоторые версии DNS (включая реализацию DNS в Windows Server 2003) допускают использование в именах объектов символа подчеркивания ("_"), а также символов в формате UTF-8.
Хотелось бы отметить, что непосредственно к имени хоста в пространстве имен DNS не предъявляется требования уникальности в рамках всего пространства имен. Требуется, чтобы это имя было уникально только в рамках родительского контейнера.
Однако непосредственно имена объектов редко используются для их идентификации. Точно идентифицировать объект можно только при помощи его полного доменного имени (Fully Qualified Domain Name, FQDN). Полное доменное имя объекта образуется из имени объекта и суффикса DNS. Суффикс DNS представляет собой перечисление имен всех контейнеров (фактически доменов), находящихся между объектом и корнем пространства имен.
Единственным объектом пространства имен DNS, не имеющим имени, является корневой домен. Для ссылки на него используют точку ("."). В записи полного доменного имени завершающая точка, обозначающая корневой домен, обычно опускается.
В табл. 13.1 перечислены все элементы, образующие пространство имен DNS.
Таблица 13.1.Элементы пространства имен DNS
|
Элемент пространства имен |
Описание |
Пример |
|
Корневой домен |
Корень — самый высокий уровень доменной иерархии; домен без имени. При использовании в полном доменном имени указывается точкой в конце |
Точка (.) или точка, стоящая в конце имени, например, "sample.mydomain.org." |
|
Домен первого уровня (Тор-Level Domain, TLD) |
Имя, состоящее из двух или трех символов, обычно указывающее страну (Россия — ш, Нидерланды — nl, Украина — иа и т. п.) или тип организации, использующей имя (com — коммерческая, mil — военная и т. д.) |
Суффикс ".com" означает, что имя зарегистрировано фирмой или другой организацией для коммерческого использования в Интернете |
|
Домен второго уровня (Second-Level Domain, SLD) |
Имя произвольной (ограниченной) длины, зарегистрированное частным лицом или организацией для использования в Интернете. Такие имена всегда основаны на домене верхнего уровня, в зависимости от типа организации или географического местоположения |
"mydomain.org." или просто "mydomain.org"— имя домена второго уровня (вымышленное) |
|
Дочерние домены |
Дополнительные домены, которые организация может создавать в пределах домена второго уровня. Применяются для отражения структурной иерархии различных подразделений больших организаций |
"sample.mydomain.org." — дочерний домен домена второго уровня "mydomain. org." |
|
Имя хоста или ресурса |
Листья дерева имен DNS, задают определенный ресурс или хост |
"host.sample.mydomain.org.", где host — имя хоста или какого-либо ресурса в сети |
Схемы запросов
Рассмотрим процесс разрешения доменных имен в 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).
Рис. 13.2. Иерархия DNS-серверов
Существует две схемы запросов, которые могут использоваться для разрешения доменного имени: рекурсивные и итерационные (итеративные) запросы. Рассмотрим каждую из схем в отдельности.
В ответ на рекурсивный запрос (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.
Рис. 13.3. Рекурсивный метод разрешения запросов
В случае получения итерационного запроса (iterative query) DNS-сервер просматривает собственную базу данных и кэш, пытаясь обнаружить в них сведения о запрашиваемом доменном имени. Если доменное имя не может быть разрешено DNS-сервером самостоятельно, клиенту будет возвращена ссылка на вышестоящий DNS-сервер. Клиент должен повторно отправить запрос указанному серверу имен. Тот, в свою очередь, просматривает собственную базу данных и возвращает либо адрес требуемого хоста, либо ссылается на другой сервер имен. На определенном этапе клиент свяжется с сервером имен, который располагает сведениями о запрашиваемом доменном имени. В этом сценарии основная нагрузка по разрешению имени возлагается на DNS-клиента.
Итерационные запросы могут использоваться в ситуации, когда или DNS-сервер, или DNS-клиент не поддерживают рекурсивные запросы (например, администратор может запретить на уровне DNS-сервера применение рекурсивных запросов).
На рис. 13.4 показан пример итерационного разрешения доменного имени. Допустим хост store.khsu.ru должен установить соединение с хостом movies.yahoo.com.
Рис. 13.4.Итерационный метод разрешения запросов
Для разрешения указанного доменного имени клиент предпринимает следующие шаги:
1. Клиент обращается к серверу имен, обслуживающему домен khsu.ru. Этот сервер имен не обладает информацией о запрашиваемом имени и возвращает клиенту ссылку на вышестоящий сервер имен (обслуживающий домен ru).
2. Клиент обращается к серверу имен, обслуживающему домен ru. Этот сервер имен не обладает информацией о запрашиваемом имени и возвращает клиенту ссылку на корневой сервер имен (домен ".").
3. Клиент обращается к корневому серверу имен. Корневой сервер имен обнаруживает, что запрашиваемое доменное имя принадлежит к домену com. Клиенту возвращается ссылка на сервер имен, обслуживающий домен com.
4. Клиент обращается к серверу имен, обслуживающему домен com. Данный сервер имен находит в своей базе данных записи о сервере имен, обслуживающем домен yahoo.com. Ссылка на этот сервер имен возвращается клиенту.
5. Клиент обращается к серверу имен, обслуживающему домен yahoo.com. Сервер имен находит в своей базе данных запись о хосте movies.yahoo.com. Соответствующий этому имени IP-адрес возвращается клиенту.
Зоны
Деление доменного пространства имен между DNS-серверами осуществляется посредством механизма зон (zone). Зона представляет собой базу данных, в которой содержатся записи о соответствии некоторого множества доменных имен IP-адресам. Каждая зона представляет собой фрагмент доменного пространства имен. Следует рассматривать зоны как основной административный элемент, на уровне которого происходит как управление пространством имен в целом, так и управление процессом разрешения имен. Зоны, используемые для размещения содержимого обратных доменов, называются зонами обратного просмотра (reverse lookup zone).
Границы зоны не определяются доменной структурой. Одна зона может включать в себя несколько доменов, в то время как объекты, принадлежащие к одному домену, могут быть размещены в нескольких зонах. Осуществляя разделение доменного пространства имен на зоны, необходимо исходить, в первую очередь, из удобства администрирования.
Зону можно разместить на нескольких серверах. На каждом из вовлеченных DNS-серверов размещается отдельная копия зоны. Для поддержания этих копий в согласованном состоянии используется модель репликации с одним основным участником (single-master replication). Один из DNS-серверов выступает в качестве основного носителя зоны (primary zone). Только основной носитель зоны обладает возможностью вносить изменения в ее содержимое (другими словами, имеет право на запись).
Остальные DNS-серверы располагают копией зоны, доступной только для чтения. Эти серверы называются дополнительными носителями зоны (secondary zone). Изменения, произведенные в копии зоны основным носителем, реплицируются на дополнительные носители. Использование нескольких носителей зоны позволяет, с одной стороны, распределить нагрузку между несколькими серверами, а с другой стороны, реализовать некоторый уровень отказоустойчивости. В случае выхода из строя одного из носителей зоны разрешение имен будет осуществляться остальными носителями зоны.
На каждом DNS-сервере может быть размещено несколько зон. В этом случае каждая зона конфигурируется отдельно. Один и тот же сервер может выступать как основным, так и дополнительным носителем для различных зон.
Ресурсные записи
Зона рассматривается как база данных, содержащая сведения об элементах пространства имен DNS. База данных состоит из записей, которые, согласно терминологии DNS, называются ресурсными записями (resource records). Каждая ресурсная запись имеет следующий синтаксис:
owner TTL class type RDATA
Характеристика полей ресурсной записи приводится в табл. 13.2.
Таблица 13.2. Поля ресурсной записи
|
Имя поля |
Описание |
|
owner |
Имя хоста или домена, к которому принадлежит ресурсная запись |
|
TTL |
32-разрядное число, определяющее интервал времени, в течение которого данная запись будет храниться в кэше DNS-сервера или DNS-клиента, до тех пор пока не будет удалена. Данное поле является необязательным. Если поле не определено, используется значение, определенное на уровне зоны (в записи SOA) |
|
class |
Определяет класс ресурсной записи. В настоящее время в данном поле всегда указывается IN |
|
type |
Указывает тип ресурсной записи. Существующие типы будут перечислены далее |
|
RDATA |
Данные ресурсной записи. Конкретное значение данного поля определяется типом ресурсной записи |
Существует порядка двадцати типов ресурсных записей. Отдельного разговора заслуживает запись типа 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. В данном случае использование этой точки обязательно.
Передача зоны
Процесс синхронизации всех копий зоны, распределенных между множеством носителей, называется передачей зоны (transfer zone). Поскольку изменения могут вноситься только в копии основного носителя, передача зоны
всегда осуществляется по направлению от основного носителя к дополнительному. Основной носитель зоны последовательно передает измененную копию зоны каждому дополнительному носителю по отдельности. Хотелось бы заметить, что базовым считается режим передачи, когда передается вся измененная зона целиком.
Время от времени дополнительные носители зоны обращаются к основному носителю зоны, сравнивая номера версий и выявляя факт изменения зоны. Периодичность этих обращений определяется интервалом обновления (refresh interval). С другой стороны, дополнительные носители могут быть извещены (notify) основным носителем о факте изменения зоны.
После того как обнаружен факт изменения, носители запрашивают передачу зоны. Если передача по каким-либо причинам не начинается, носители повторяют свой запрос через определенные промежутки времени, называемые интервалами повторения (retry interval). Если зона не была обновлена в течение периода, называемого интервалом истечения срока действия (expire interval), зона считается устаревшей и не может быть использована для разрешения имен. Интервал обновления, интервал повторения и интервал истечения срока действия определяются на уровне всей зоны посредством соответствующих параметров записи SOA.
Передача зоны инициируется при следующих обстоятельствах:
истекает интервал обновления зоны;
основной носитель извещает дополнительный носитель о факте изменения зоны;
для зоны определяется новый дополнительный носитель. В этом случае необходимо создать на этом дополнительном носителе копию зоны;
администратор вручную инициирует процесс передачи зоны, используя соответствующий административный инструмент.
Служба DNS, реализованная в Windows Server 2003, позволяет осуществлять передачу не всей зоны целиком, а частично — только произведенные изменения. Этот режим синхронизации получил название инкрементной передани зоны. Использование режима инкрементной передачи зоны позволяет снизить сетевой трафик вызванной репликацией между DNS серверами, поскольку в большинстве случаев изменения сводятся к добавлению или удалению из базы данных зоны одной-двух записей. В этой ситуации нет смысла передавать всю зону.
Использование режима инкрементной передачи зоны возможно только в том случае, если все носители зоны поддерживают его. Если хотя бы один из носителей зоны не поддерживает режим инкрементной передачи, он не
сможет получить сведения об изменениях. Как следствие, актуальность данных на этих серверах очень скоро будет утрачена.
Методы хранения зоны
Реализация службы 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. Разделы приложений, по умолчанию используемые
для размещения зоны
|
Раздел приложения |
Описание |
|
ForestDnsZon.es . <имя DNS леса> |
Раздел приложений, доступный DNS-серверам в рамках всего леса доменов. Реплика раздела автоматически создается при установке DNS-сервера на любом контроллере в лесу. Соответственно, любой такой DNS-сервер будет выступать носителем зоны, размещенной в подобном разделе приложений |
|
DomainDnsZones . <имя DNS леса> |
Раздел приложений, доступный DNS-серверам в рамках домена. Реплика раздела автоматически создается при установке 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 этой зоны.
Выборочное перенаправление запросов
Механизм выборочного перенаправления запросов (conditional forwarding) позволяет осуществлять перенаправление пользовательских запросов на другие DNS-серверы, основываясь на информации о доменном имени, включенном в запрос. Обычный режим перенаправления (forwarding) предполагает перенаправление всех запросов на определенный DNS-сервер или группу серверов. Фактически механизм выборочного перенаправления позволяет выполнять на DNS-сервере сортировку запросов. Некоторую часть запросов сервер способен разрешить сам, другая часть будет перенаправлена различным серверам имен.
Выборочное перенаправление позволяет повысить эффективность разрешения запросов за счет сокращения количества операций. Так же, как и механизм упрощенных зон, выборочное перенаправление может быть использовано как средство организации взаимодействия двух лесов доменов, реализующих собственные пространства имен DNS.
Поскольку механизм выборочного перенаправления способен решать те же задачи, что и упрощенные зоны, очень трудно увидеть различия между ними. Какой из двух механизмов выбрать в той или иной ситуации? Механизм выборочного перенаправления позволяет перенаправить запросы пользователей по разрешению определенного доменного имени на конкретный DNS-сервер. Использование же упрощенных зон для разрешения определенного доменного имени дает ссылку на некоторый набор DNS-серверов, способных выполнить это разрешение. Поэтому, если администратору необходимо контролировать процесс обращения пользователей к корпоративным DNS-серверам (например, с целью управления нагрузкой на серверы или для сокращения нагрузки на линии связи с ограниченной пропускной способностью), он должен использовать механизм выборочного перенаправления.
С другой стороны, использование механизма упрощенных зон позволяет реализовать большую гибкость в управлении DNS-серверами. Изменение списка DNS-серверов, выступающих в качестве носителей полноценной копии зоны (а соответственно, способных выполнить разрешение определенного множества доменных имен), приводит к автоматическому обновлению упрошенной зоны на всех ее носителях. В случае же использования механизма выборочного перенаправления администратору придется вручную изменить конфигурацию всех вовлеченных DNS-серверов.
Динамическая регистрация имен
Стандартный механизм сопровождения зоны предполагает создание администратором вручную статических ресурсных записей. Любое произведенное изменение доменного имени хоста или его IP-адреса администратор должен синхронизировать с базой данных службы DNS, вручную изменяя соответствующие записи. Подобная схема изменения содержимого зоны делает практически невозможным использование в корпоративной сети службы динамического выделения адресов (DHCP).
В спецификации службы DNS определена возможность использования механизма динамической регистрации хостами своих доменных имен. В процессе динамической регистрации клиенты могут создавать и изменять ресурсные записи типа А и PTR. Контроллеры домена могут также динамически регистрировать ресурсные записи типа SRV.
Механизм динамической регистрации доменных имен предполагает тесную интеграцию служб DNS и DHCP. Динамическая регистрация доменных имен может быть осуществлена либо DHCP-клиентом, либо службой сервера DHCP. Такое решение легко объяснимо, учитывая, что в большинстве случаев изменение IP-адреса клиента связано со службой DHCP.
Если клиент находится под управлением операционных систем Windows 2000/XP или Windows Server 2003, он может самостоятельно зарегистрировать свое имя в базе данных DNS-сервера. В этом случае регистрация осуществляется службой клиента DHCP компьютера. Остальные версии Windows (Windows 9.X/NT/ME) не способны динамически зарегистрировать свое доменное имя. В этой ситуации задача регистрации имени может быть
возложена на службу сервера DHCP. Служба сервера DHCP, реализованная в Windows Server 2003, может зарегистрировать доменное имя одновременно с выделением в аренду IP-адреса. В этом случае, регистрация доменного имени происходит без участия клиента и незаметно для них.
Клиент предпринимает попытку зарегистрировать доменное имя в базе данных DNS-сервера в следующих ситуациях:
происходит изменение IP-адреса. Операция динамической регистрации инициируется при любом изменении списка адресов хоста (добавление нового адреса, удаление или модификация существующего);
выполнение утилиты командной строки Ipconfig с ключом /renew. В этом случае инициируется процесс выделения хосту в аренду нового IP-адреса (или набора адресов, если компьютер имеет несколько сетевых адаптеров);
в процессе загрузки системы. Каждый раз при включении компьютера и загрузки системы происходит регистрация доменного имени в базе данных соответствующей зоны;
выполнение утилиты командной строки Ipconfig с ключом /registerdns.
В результате происходит принудительное обновление доменного имени клиента в базе данных DNS-сервера.
Механизм динамической регистрации подразумевает не только регистрацию доменных имен, но и их освобождение. При завершении работы системы ассоциированные с ней ресурсные записи автоматически удаляются из зоны. Если работа системы была завершена некорректно, например, в результате сбоя или зависания компьютера, ресурсные записи могут оставаться в базе данных. Подобные записи называются фантомами. Наличие фантомов в базе данных зоны нежелательно, поскольку клиенты получают в ответ на свои запросы неактуальную информацию.
Параллельно с механизмом динамической регистрацией имен DNS-сервер активизирует механизм очистки (scavenging) базы данных от устаревших ресурсных записей. Рассмотрим, каким образом процесс очистки позволяет удалить фантомы из базы данных записей.
С каждой ресурсной записью ассоциируется временная метка (timestamp), определяющая время ее создания. Ресурсная запись считается актуальной в течение определенного периода времени, называемого периодом стабильности (no-refresh interval). Обновление сведений о ресурсной записи в течение этого периода приводит к обновлению значения временной метки. Временная метка обновляется каждый раз, когда клиент обновляет ресурсную запись. Система ожидает обновления ресурсной записи в течение периода, который называется периодом обновления (refresh interval). Если для ресурсной записи истек период обновления, а она не была обновлена, запись помечается как устаревшая (aging). Все устаревшие ресурсные записи удаляются
в процессе очистки базы. Этот процесс автоматически инициируется системой через определенные промежутки времени.
Безопасная регистрация доменных имен
Для зон, интегрированных в Active Directory, каждая ресурсная запись представляет собой объект каталога. Для таких зон можно задействовать механизм безопасной динамической регистрации (secure dynamic update). Этот механизм позволяет администратору управлять доступом к объектам, ассоциированным с ресурсными записями. Администратор может определить пользователей, которым разрешено изменять отдельные ресурсные записи. Например, администратор может определить группы пользователей, которым разрешено производить какие-либо изменения ресурсных записей.
Развертывание DNS
В данном разделе мы кратко рассмотрим процесс установки и настройки DNS-серверов в корпоративной сети. Этот процесс включает в себя следующие стадии:
планирование;
установка программного обеспечения DNS-сервера;
настройка DNS;
мониторинг и оптимизация.
Планирование
Перед использованием DNS в сети необходимо тщательно спланировать пространство имен DNS. При этом нужно определить, как будет применяться служба DNS и какие цели должны быть достигнуты в ходе ее развертывания. Вот вопросы, которые необходимо решить до установки службы.
Выбор и предварительная регистрация имени домена, используемого в Интернете.
В какой сети будут установлены серверы DNS — в частной сети или в Интернете.
Нужно ли использовать DNS для поддержки работы Active Directory?
Требования к выбору доменных имен для компьютеров.
Установка DNS-сервера
Для установки сервера DNS нужно воспользоваться процедурами, описанными в разд. "Установка дополнительных сетевых компонентов" главы 12.
Можно также воспользоваться Мастером установки компонентов Windows'. для этого необходимо открыть панель управления, запустить утилиту
Add/Remove Programs (Добавить/удалить приложения) и нажать кнопку Add/Remove Windows Component (Добавить/удалить компоненты Windows). В окне мастера (рис. 13.5) следует выбрать компоненты Windows для установки. Администратор может одновременно установить множество компонентов, для этого достаточно установить соответствующие флажки.
Рис. 13.5. Выбор компонентов Windows для установки
Выберите в списке пункт Networking Services (Сетевые службы) и нажмите кнопку
Details (Подробнее). В открывшемся окне (рис. 13.6) установите флажок около компонента
Domain Name System (DNS). Вернитесь в окно выбора устанавливаемых компонентов и щелкните на кнопке
Next (Далее), чтобы приступить к установке. В процессе установки потребуется доступ к дистрибутивным файлам Windows Server 2003.
По окончании работы мастера служба DNS будет установлена на выбранный компьютер. Требуемые файлы будут скопированы на жесткий диск, программное обеспечение сервера можно использовать после перезапуска системы. В группе программ
Administrative Tools (Средства администрирования) появится новый инструмент: оснастка DNS. Однако мастер производит установку на сервер только системных файлов. Чтобы служба DNS-сервера
начала выполнять свои функции, необходимо должным образом ее сконфигурировать.
Рис. 13.6. Выбор сетевых компонентов для установки
Установив сервер DNS, необходимо решить, как будут управляться сервер и файлы зон базы данных DNS. Хотя изменения в файлах базы данных можно вносить и при помощи текстового редактора, этот метод не рекомендуется. Лучше обслуживать сервер DNS и файлы зон базы данных средствами оснастки DNS.
Настройка сервера
После того как программное обеспечение 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) зоны.
Рис. 13.7. Окно оснастки DNS
Установка первого 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.
Рис. 13.8. Конфигурирование механизма перенаправления запросов
Рис. 13.9. Две зоны создаются на DNS-сервере в процессе создания корневого леса доменов
Установка дополнительных DNS-серверов
Установка дополнительных DNS-серверов позволяет повысить надежность корпоративной сети и гарантировать разрешение пользовательских запросов даже в том случае, когда один из DNS-серверов выйдет из строя. Если вы устанавливаете DNS-сервер на контроллере домена, вы можете использовать его в качестве носителя зон, интегрированных в Active Directory. В противном случае сервер может использоваться в качестве дополнительного носителя.
Отдельно следует сказать о конфигурировании DNS-серверов в качестве носителя зон, интегрированных в Active Directory. Для размещения содержимого зоны по умолчанию используется раздел приложений. Реплики раздела приложений создаются администратором на контроллере домена вручную при помощи утилиты Ntdsutil.exe.
Конфигурирование зон
Администратор может изменить конфигурацию зоны по своему усмотрению в любой момент. Для выполнения изменений необходимо вызвать окно свойств зоны, выбрав в контекстном меню объекта, ассоциированного с зоной, пункт
Properties (Свойства).
Рис. 13.10. Окно свойств зоны DNS, интегрированной в Active Directory
Окно свойств (рис. 13.10) обычной зоны состоит из пяти вкладок. В случае зоны, интегрированной в Active Directory, появляется шестая вкладка Security (Безопасность), на которой администратор может ограничить доступ к зоне и ее содержимому.
Изменение типа зоны
На вкладке General (Общие) в поле Туре (Тип) отображается тип зоны. Администратор может в любой момент изменить его, нажав кнопку
Change (Изменить). В открывшемся окне (рис. 13.11) администратор должен выбрать новый тип зоны. Обратите внимание, что установленный флажок
Store the zone in Active Directory (Хранить зону в Active Directory) свидетельствует о том, что зона интегрирована в Active Directory. Поскольку этот способ хранения не допускает использование дополнительных носителей зон, выбор переключателя Secondary zone (Дополнительная зона) в качестве типа зоны приводит к тому, что данный флажок автоматически снимается и становится недоступным для изменения.
Рис. 13.11. Выбор типа зоны
Если зона хранится в Active Directory, администратор может регламентировать доступ к объектам пространства имен DNS на вкладке Security (Безопасность). Эту вкладку имеет каждый объект пространства имен DNS (домены, зоны, ресурсные записи).
Изменение области репликации
В поле Replication (Репликация) вкладки General (Общие) окна свойств зоны указывается область распространения изменений в содержимом зоны. Это поле отображается только для зон, интегрированных в Active Directory. Фактически значение этого поля определяет раздел каталога, в котором хранится содержимое зоны. Соответственно, выбор раздела влияет на область репликации изменений. Нажав кнопку
Change (Изменить), администратор может в открывшемся окне определить новое место хранения зоны (рис. 13.12). Перечень значений, предлагаемых администратору в этом окне, приведен в табл. 13.4.
Рис. 13.12. Изменение области распространения содержимого зоны
Таблица 13.4. Области распространения содержимого зоны
|
Область репликации |
Описание |
|
То all DNS servers in the Active Directory forest |
Зона размещается в разделе приложений, доступном в пределах всего леса |
|
To all DNS servers in the Active Directory domain |
Зона размещается в разделе приложений, доступном в пределах отдельного домена |
|
To all domain controllers in the Active Directory domain |
Зона размещается в доменном разделе каталога. Этот способ размещения зоны необходимо выбирать, если в качестве носителей зоны используется Windows 2000 DNS |
|
To all domain controllers specified in the scope of the following application directory partition |
Зона размещается в разделе приложений, который создается администратором |
Установка режима динамического обновления
Режим динамической регистрации устанавливается посредством параметра Allow dynamic updates (Разрешить динамическое обновление) вкладки
General (Общие) окна свойств зоны. Чтобы разрешить динамическое обновление, установите значение этого параметра в
Yes. Для активизации режима безопасного обновления необходимо установить значение в
Only secure updates (Только безопасное обновление).
Проверка работоспособности DNS-сервера
По окончании процесса установки службы DNS необходимо проверить работоспособность сервера. Следует убедиться в том, что DNS-сервер поддерживает нужные зоны прямого и обратного просмотра, а также в том, что зоны могут динамически обновляться.
Использование утилиты DnsCmd
Подобная проверка может быть осуществлена при помощи стандартной системной утилиты DnsCmd.exe. Утилиту можно запускать непосредственно на DNS-сервере. В этом случае в параметрах утилиты можно не указывать имя сервера.
Для проверки зон можно использовать ключ /EnumZones:
С:\dnscmd /EnumZones Enumerated zone list: Zone count = 3 Zone name Type Storage Properties Cache File _msdcs.khsu.ru Primary AD-Forest Secure khsu.ru Primary AD-Domain Secure Command completed successfully.
Следует заметить, что в приведенном примере зона "." представляет ссылки на корневые серверы пространства имен DNS, загружаемые при запуске DNS-сервера. Поле
Type определяет тип зоны. Поле storage определяет способ хранения зоны и область распространения изменений. Поле Properties позволяет получить информацию о свойствах зоны.
Для получения более подробной информации о зоне необходимо использовать ключ /ZoneInfo. Ниже приводится пример выполнения утилиты с этим ключом:
c:\dnscmd /Zoneinfo khsu.ru Zone query result: Zone info: ptr = 00083140 zone name = khsu. ru zone type = 1 update = 2 DS integrated = 1 data file = (null) using WINS = 0 using Nbstat = 0 aging = 0 refresh interval =168 no refresh = 168 scavenge available = 3520930 Zone Masters NULL IP Array.Zone
Secondaries NULL IP Array, secure sees
rectory partition = AD-Domain flags 00000015 zone DN 4>= DC=khsu.ru,cn=MicrosoftDNS,DC=DomainDnsZones, DC=khsu,DC=ru Command completed successfully.
Для получения информации о ресурсных записях определенной зоны необходимо выполнить утилиту с ключом /EnumRecords. Ниже приводится пример работы утилиты:
c:\dnscmd /EnumRecords khsu.ru _tcp /Type SRV Returned records: _gc [Aging:3520762] 600 SRV 0 100 3268 store.khsu.ru. _kerberos [Aging:3520762] 600 SRV 0 100 88 store.khsu.ru. _kpasswd [Aging:3520762] 600 SRV 0 100 464 store.khsu.ru. _ldap [Aging:3520762] 600 SRV 0 100 389 store.khsu.ru. Command completed successfully.
В приведенном примере отображаются все ресурсные записи типа SRV, содержащиеся в контейнере _tcp зоны khsu. ru.
Использование утилиты Nslookup
Проверка работоспособности не ограничивается только получением информации о параметрах DNS-сервера и его компонентов. Необходимо также проверить способность DNS-сервера обрабатывать запросы, выполняя разрешение доменных имен в IP-адреса. Подобную проверку желательно провести перед процедурой создания любого контроллера домена — это позволит избежать серьезных проблем с доменами в будущем.
Основным диагностическим инструментом, позволяющим проверить способность DNS-сервера обрабатывать запросы, является утилита командной строки Nslookup.exe. Эта утилита является стандартным инструментом диагностики DNS-сервера и может использоваться совместно с любыми реализациями DNS-серверов. Еще более полную информацию может дать утилита NetDiag.exe, а на контроллерах домена — утилита DCdiag.exe.
Утилита может функционировать как в режиме командной строки, так и в интерактивном режиме. В первом случае администратор запускает утилиту с некоторыми параметрами. В этой ситуации команда выполняет только одно действие, определенное использованными параметрами, после чего возвращается в режим командной строки. Интерактивный режим выбирается в том случае, если утилита была запущена без указания каких-либо параметров. В интерактивном режиме утилита выводит приглашение, ожидая команд администратора. Имеется порядка десятка команд, используя которые, администратор может осуществлять тестирование DNS-серверов.
Ниже приводится пример тестирования DNS-сервера — запрашивается адрес хоста main.khsu.ru!
с:\nslookup main.khsu.ru Server:root.khsu.ru Address:192.168.1.1 Name:main.khsu.ru Address: 192.168.1.6
В приведенном примере строка server указывает на DNS-сервер, в контексте которого осуществляется разрешение запросов с помощью утилиты Nslookup.
Управление клиентами
Для клиентов Windows конфигурация DNS при настройке свойств TCP/IP для каждого компьютера включает следующие задачи:
установка имени хоста DNS для каждого компьютера или сетевого подключения;
установка имени родительского домена, которое помещается после имени хоста, чтобы формировать полное (fully qualified) имя домена для каждого клиента;
установка основного DNS-сервера и списка дополнительных DNS-серверов, которые будут использоваться клиентом в ситуации, когда основной сервер недоступен;
установка очередности списка поиска доменов, используемого в запросах для дополнения не полностью заданного имени компьютера.
Мониторинг и оптимизация
В Windows Server 2003 администратор может осуществлять мониторинг DNS-сервера и по его результатам оптимизировать соответствующие параметры настройки. Для этой задачи администратор может использовать следующие инструменты и возможности:
системный монитор (Performance Monitor);
опции протоколирования;
статистика по DNS-серверу;
настройка дополнительных параметров.
Служба 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, что позволяет перемещать компьютер между различными подсетями.
Обзор 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, администратор может определять собственные опции.
Как работает DHCP
Когда новый DHCP-клиент подключается к сети, он запрашивает уникальный IP-адрес у DHCP-сервера. DHCP-сервер выделяет клиенту один адрес из пула адресов. Этот процесс (рис. 13.13) состоит из четырех шагов: 1) клиент DHCP запрашивает IP-адрес (DHCP Discover, обнаружение), 2) DHCP-сервер предлагает адрес (DHCP Offer, предложение), 3) клиент принимает предложение и запрашивает адрес (DHCP Request, запрос) и 4) адрес официально назначается сервером (DHCP Acknowledgement, подтверждение). Адрес клиенту предоставляется на определенный срок, называемый периодом аренды. По истечении половины этого срока клиент должен возобновить аренду. В противном случае, по истечении срока аренды, выделенный клиенту адрес возвращается в пул для повторного использования. В этой ситуации клиент должен инициировать процедуру получения IP-адреса с самого начала.
Рис. 13.13. Схема взаимодействия DHCP-сервера и DHCP-клиента
Понятие области действия
Множество IP-адресов, предназначенных для распределения между DHCP-клиентами одной подсети, рассматривается как единый административный блок, получивший название области действия (scope). Когда DHCP-клиент нуждается в получении адреса, он рассылает по сети широковещательный запрос. Получая этот запрос, DHCP-сервер просматривает имеющиеся области действия, определяя — имеется ли область действия для данной подсети. Если необходимый пул адресов имеется, сервер вступает с клиентом во взаимодействие.
Приступая к настройке службы DHCP, администратор должен создать отдельную область действия для каждой физической подсети. Если в сети имеется несколько DHCP-серверов, необходимо распределить имеющиеся диапазоны адресов между ними. Как правило, для каждой подсети должно быть как минимум два DHCP-сервера, способных выдать необходимый IP-адрес. Для этого имеющиеся диапазоны адресов делятся между двумя DHCP-серверами в некотором соотношении. При этом рекомендуется следующая схема. Для каждой подсети на ближайшем DHCP-сервере размещается 80 процентов имеющихся адресов. Остальные 20 процентов размещаются на одном из оставшихся DHCP-серверов. Этот сервер возьмет на себя обязанности по выдаче адресов для рассматриваемой подсети, если основной сервер выйдет из строя. Применение подобной схемы позволяет гарантировать, что ни один запрос клиента не останется без ответа.
Суперобласти
В службе DHCP, реализованной в рамках Windows Server 2003, разработчиками была реализована возможность создания суперобластей (superscope). Суперобласть представляет собой административное объединение стандартных областей. Использование суперобластей действия оправдано в ситуации, когда для одной подсети имеется несколько несмежных диапазонов IP-адресов. При этом каждый диапазон реализуется в виде отдельной области действия. Суперобласть действия выступает в качестве средства объединения получившихся областей действия.
Суперобласти используются для реализации в пределах одной физической подсети нескольких логических подсетей. Каждая логическая подсеть создается подмножеством адресов, заданных в рамках некоторой области, являющейся частью суперобласти. Согласно терминологии DHCP, в этом случае принято говорить о мультисетях (multinets).
Если физическая подсеть, для которой задается суперобласть, соединяется с другой подсетью при помощи маршрутизатора, внутренний интерфейс маршрутизатора должен быть определен в качестве шлюза по умолчанию для всех хостов всех логических подсетей, входящих в суперобласть. При этом для интерфейса маршрутизатора, подключенного к физической подсети, поделенной на логические подсети, необходимо выделить по одному IP-адресу с каждой из логических подсетей. В противном случае хосты, принадлежащие к логическим подсетям, не смогут взаимодействовать с другими подсетями через данный маршрутизатор.
Понятие опций
На уровне областей действия происходит управление процессом выдачи IP-адресов. Для решения задачи однообразного конфигурирования клиентов DHCP-сервер использует механизм опций (options). Опции позволяют предоставить DHCP-клиентам различную информацию о настройках компонентов стека протоколов TCP/IP. Каждая опция идентифицируется посредством уникального 8-разрядного кода, определяющего назначение опции. В спецификации DHCP определено несколько десятков разнообразных опций, в дополнение к которым корпорация Microsoft предложила несколько собственных.
Опции могут быть определены на уровне всего сервера, отдельной области действия, класса и отдельного клиента. В последнем случае требуется, чтобы на DHCP-сервере для клиента был зарезервирован некоторый адрес. Опции, определенные на уровне сервера, позволяют однообразно конфигурировать всех клиентов, обслуживаемых сервером. Опции, определенные на уровне отдельной области действия, будут использованы для настройки клиентов из одной подсети. Администраторы часто используют такую возможность для
того, чтобы снабдить клиентов одной подсети информацией о существующих маршрутизаторах.
Отдельно стоит сказать о возможности объединения DHCP-клиентов в специальные классы. Класс рассматривается в данном случае, как некая логическая группа компьютеров, объединенных по некоторому признаку. Например, в один класс можно объединить компьютеры, имеющие доступ к Интернету. Сетевые компоненты этих компьютеров могут требовать расширенной настройки. Чтобы отнести хост к некоторому классу, администратор должен использовать утилиту командной строки Ipconfig с ключом /setclassid.
Все четыре уровня различаются по приоритетам. Это дает возможность реализовать переопределение опций, что, в свою очередь, позволяет повысить гибкость и удобство конфигурирования клиентов. Для настройки клиентов будут использоваться опции, имеющие наиболее высокий приоритет. Самый низкий приоритет имеют опции, определенные на уровне сервера. Опции, определенные на уровне клиента, обладают наибольшим приоритетом.
Агент-ретранслятор DHCP/BOOTP
Отдельно следует сказать о специальном агенте ретрансляции ВООТР/ DHCP. Работа протоколов ВООТР и DHCP основана на механизмах широковещания. Маршрутизаторы по умолчанию обычно не ретранслируют широковещательные рассылки, что может создать трудности для получения IP-адресов клиентами, находящимися в другой подсети. Передача широковещательных рассылок DHCP/BOOTP выполняется агентом ретрансляции. Под агентом ретрансляции DHCP понимается хост, который прослушивает подсети на наличие широковещательных сообщений DHCP/BOOTP и переадресовывает их на некоторый заданный DHCP-сервер. Использование агентов ретрансляции избавляет от необходимости устанавливать сервер DHCP в каждом физическом сегменте сети. Агент не только обслуживает прямые локальные запросы клиента DHCP и перенаправляет их на удаленные DHCP-серверы, но также возвращает ответы удаленных DHCP-серверов клиентам.
Установка и настройка DHCP-сервера
Для установки службы DHCP-сервера необходимо воспользоваться процедурами, описанными в разд. "Установка дополнительных сетевых компонентов" главы 12. После установки сервера в меню
Administrative Tools (Администрирование) будет добавлен новый инструмент: оснастка DHCP. Эта утилита используется для настройки DHCP-сервера. Непосредственно после установки службы DHCP-сервера необходимо запустить ее при помощи оснастки
Services (Службы). В случае если DHCP-сервер подключен к нескольким сетям, необходимо отключить привязку службы к тем подключениям, которым не требуется поддержка DHCP.
Компьютер, выбранный на роль DHCP-сервера, должен быть сконфигурирован со статическим IP-адресом.
Авторизация DHCP-сервера
Прежде чем DHCP-сервер сможет приступить к процессу выделения адресов DHCP-клиентам, он предварительно должен быть авторизован. Авторизация DHCP-сервера является обязательным условием его нормального функционирования. Иными словами, в каталоге Active Directory должен быть создан объект, соответствующий установленному DHCP-серверу. Только после этого клиенты смогут работать с данным сервером. Все обязанности по осуществлению контроля над авторизацией DHCP-серверов возложены непосредственно на сами DHCP-серверы. Осуществляется это следующим образом. Служба DHCP-сервера при запуске обращается к Active Directory, чтобы просмотреть список IP-адресов авторизованных серверов. Если она не обнаруживает свой адрес в этом списке, она останавливает свою работу.
Для авторизации DHCP-сервера необходимо запустить оснастку DHCP и в контекстном меню объекта, расположенного в корне пространства имен утилиты, выбрать пункт
Manage authorized servers (Управление авторизованными серверами). Система покажет список уже авторизованных DHCP-серверов. Нажмите кнопку
Authorize (Авторизовать) и укажите имя авторизуемого DHCP-сервера или его IP-адрес. Выбранный сервер будет немедленно добавлен в список авторизованных серверов.
Создание области действия
Приступим к настройке службы DHCP. Для начала определим необходимые области действия. Запустите оснастку
DHCP, которая находится в меню Administrative Tools (Администрирование). В результирующей панели оснастки вызовите контекстное меню объекта, ассоциированного с конфигурируемым DHCP-сервером, и выберите пункт
New Scope (Новая область действия). Будет запущен мастер конфигурирования области действия.
Первое окно мастера традиционно предоставляет информацию о его назначении. Поэтому необходимо сразу же перейти во второе окно, в котором требуется определить имя для создаваемой области действия и дать ей краткое описание. В качестве имени можно использовать IP-адрес подсети. Это поможет вам легко ориентироваться в ситуации, когда на DHCP-сервере
создано множество областей действия. В этом случае вы всегда сможете точно идентифицировать необходимую область.
В третьем окне мастера следует определить пул IP-адресов, для которых создается область действия. Пул задается путем указания начального и конечного адреса диапазона. Потребуется также предоставить информацию о маске подсети (рис. 13.14).
Рис. 13.14. Предоставьте информацию о диапазоне адресов
В следующем окне мастера администратор может определить исключения из только что определенного диапазона. Могут иметься различные причины для этого. Администратор может исключать как отдельные адреса, так и целые диапазоны. Для исключения одиночного IP-адреса необходимо указать его в поле
Start IP address (Начальный IP-адрес). Поле End IP address (Конечный IP адрес) необходимо оставить в этом случае пустым. После нажатия кнопки
Add (Добавить) введенный адрес будет добавлен в список исключенных из диапазона адресов (рис. 13.15).
Перейдя к следующему окну мастера, необходимо определить для создаваемой области действия время аренды IP-адресов. Время аренды может быть определено на уровне дней, часов и даже минут. Хотя в стандарте протокола DHCP определена возможность аренды адреса на неопределенный срок (бесконечная аренда), реализация службы протокола в Windows Server 2003 не допускает сдачу адреса в бесконечную аренду.
Рис. 13.15. Определение исключений из диапазона адресов
Определив время аренды, администратор фактически заканчивает конфигурирование области действия. В ходе работы мастера, однако, администратор может сразу определить опции
DHCP для создаваемой области действия: будет задан вопрос — требуется ли определить опции непосредственно в ходе работы мастера или это будет сделано администратором впоследствии.
Если вы решили воспользоваться помощью мастера в определении опций, вам будет предложено определить несколько наиболее важных опций DHCP.
Адрес шлюза по умолчанию. Шлюз по умолчанию используется для маршрутизации пакетов, адресованных хостам в других подсетях. Если хост не располагает информацией о шлюзе по умолчанию, он не будет способен взаимодействовать с подобными хостами. В данной опции требуется определить адрес маршрутизатора, который будет осуществлять доставку пакетов хостам в других подсетях (рис. 13.16).
DNS-имя домена и адреса DNS-серверов. Эти опции используются для определения DNS-имени домена и DNS-серверов всех хостов, конфигурируемых посредством данной области действия. DNS-сервер может быть представлен как именем, так IP-адресом. Опция допускает указание нескольких DNS-серверов, что позволит обеспечить гарантированное разрешение имен в случае, если один из серверов выйдет из строя (рис. 13.17).
Адреса WINS-серверов. WINS-серверы используются для организации процесса разрешения NetBIOS-имен хостов в IP-адреса этих хостов. Данная опция позволяет снабдить клиента адресами всех действующих в
сети WINS-серверов. Так же, как и в случае с DNS-серверами, можно указать адреса нескольких WINS-серверов (рис. 13.18).
Рис. 13.16. Опция, позволяющая определить адреса шлюзов по умолчанию
Рис. 13.17. Опция, позволяющая определить адреса DNS-серверов и DNS-имени домена
Создаваемые мастером опции определяются на уровне конкретной области действия. Мастер не может создавать опции на других уровнях.
Рис. 13.18. Опция, позволяющая определить адреса WINS-серверов
Разумеется, определяемая мастером информация является только малой частью того, что может быть определено посредством механизма опций. После создания области действия администратор может при необходимости вручную создать дополнительные опции.
На заключительном этапе работы мастера нужно решить, будет ли область действия активизирована сразу после ее создания или нет. Активизация области действия приводит к тому, что IP-адреса, определенные в рамках области, могут быть по требованию сданы в аренду. Поэтому если, например, требуется определить ряд дополнительных опций, процесс активизации области действия следует отложить.
При использовании нескольких областей опции по умолчанию могут быть определены на уровне сервера. В этом случае данные опции будут унаследованы всеми областями. Для этого в контекстном меню контейнера Server Options (Опции сервера) необходимо выбрать пункт Configure Options (Настроить опции) и определить требуемые опции.
Настройка механизма динамической регистрации доменных имен
Если нужно, чтобы регистрация доменных имен выполнялась непосредственно на уровне DHCP-сервера, необходимо в окне свойств объекта, ассоциированного с сервером, перейти на вкладку
DNS и установить флажок Enable DNS dynamic updates according to the settings below
(Разрешить динамические обновления в DNS в соответствии со следующими настройками) (рис. 13.19). Дополнительно нужно выбрать условия регистрации доменных имен в базе данных DNS. Сервер DHCP будет посылать сообщение службе DNS каждый раз, когда клиенту выдается IP-адрес.
Рис. 13.19. Активизация режима автоматической регистрации доменных имен в базе данных DNS
Мониторинг DHCP-сервера
После того как DHCP-сервер настроен и функционирует, следует периодически осуществлять мониторинг его состояния. Для получения необходимого аналитического материала администратор может активизировать режим протоколирования событий. Для этого на вкладке
General (Общие) окна
свойств DHCP-сервера нужно установить флажок Enable DHCP audit logging (Разрешить запись журнала DHCP) (рис. 13.20). После этого вся информация, связанная с функционированием сервера DHCP, будет заноситься в
текстовый файл журнала.
Рис. 13.20. Активизация режима протоколирования DHCP-сервера
Служба 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-сервера.
Рис. 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-сервера.
Посредник 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-посредника.
Рис. 13.22. WINS-серверы
Рис. 13.23. Пример использования WINS-посредника
Хост, функционирующий в режиме b-узла, не подозревает о существовании WINS-посредника. Этот хост рассылает широковещательные запросы, которые принимаются всеми хостами подсети, в том числе и WINS-посредником. WINS-посредник переадресует эти сообщения WINS-серверу, информируя последний о регистрации или освобождении соответствующего имени. Аналогичным образом хост, функционирующий в режиме b-узла, обращается с широковещательным запросом на разрешение имени. Посредник WINS проверяет собственный локальный кэш имен, и если в нем не обнаружено запрашиваемое имя, переадресует запрос WINS-серверу (см. рис. 13.23).
Репликация WINS
Если в сети используется несколько WINS-серверов, для поддержания их баз данных в синхронизированном состоянии администратор может настроить между ними репликацию. Рис. 13.24 иллюстрирует ситуацию, когда репликация настроена между двумя WINS-серверами. В показанном на рисунке примере репликация осуществляется в обе стороны. То есть содержимое базы данных одного WINS-сервера реплицируется на другой WINS-сервер и наоборот. Однако возможны и другие варианты: как однонаправленная репликация, так и сложные топологии репликации (например, образующие кольцо). После настройки механизма репликации между WINS-серверами каждый из них будет располагать сведениями обо всех именах NetBIOS, зарегистрированных в корпоративной сети. Благодаря этому любой клиент будет иметь возможность разрешать NetBIOS-имена независимо от того, на каком из WINS-серверов эти имена были зарегистрированы.
Рис. 13.24. Репликация между WINS-серверами
Участвующие в репликации WINS-серверы называются партнерами по репликации. В зависимости от того, как именно WINS-сервер инициирует процедуру репликации, он может выступать в одном из трех качеств:
передающий партнер (Push Partner). В этом сценарии WINS-сервер инициирует процесс репликации самостоятельно, извещая своих партнеров об изменении своей базы данных путем отправки специального сообщения;
принимающий партнер (Pull Partner). В этом случае WINS-сервер запрашивает репликацию изменений у своего партнера по репликации с определенной периодичностью.
передающий/принимающий партнер (Push/Pull Partner). Этот сценарий предполагает использование обоих вышеописанных методов инициации процесса репликации.
Механизм постоянных соединений
Инициируя процесс репликации, WINS-сервер устанавливает соединение с другим сервером, в рамках которого осуществляется передача соответствующих изменений. Установка соединения требует затрат определенных системных ресурсов. При этом интенсивные изменения могут снизить общую производительность WINS-сервера.
В Windows Server 2003 реализация службы WINS поддерживает механизм постоянного соединения с партнером по репликации. Данный механизм позволяет устанавливать соединение только один раз, после чего оно сохраняется активным. Любое изменение, осуществляемое в базе данных сервера, будет немедленно реплицировано на другие серверы, с которыми установлено постоянное соединение. Благодаря этому базы данных всех WINS-серверов будут всегда находиться в актуальном состоянии.
Механизм постоянных соединений позволяет поддерживать базы данных всех WINS-серверов в актуальном состоянии. Однако этот механизм требует, чтобы коммуникационные линии, соединяющие партнеров по репликации, были доступны постоянно. Как правило, механизм постоянных соединений используется в локальной сети. Если WINS-серверы соединяются по коммутируемым линиям, необходимо использовать обычный способ репликации.
Установка и настройка сервера WINS
Для установки службы WINS-сервера нужно воспользоваться процедурами, описанными в разд. "Установка дополнительных сетевых компонентов" главы 12. После установки службы WINS в меню
Administrative Tools (Администрирование) появится новая оснастка WINS, которая предназначена для настройки и конфигурирования WINS-сервера (рис. 13.25).
Рис. 13.25. Окно оснастки WINS
Компьютер, выбранный на роль WINS-сервера, должен быть сконфигурирован со статическим IP-адресом.
Настройка репликации между WINS-серверами
До настройки репликации нужно тщательно спроектировать топологию репликации WINS. В глобальных сетях это очень важно для успешного развертывания и использования службы WINS.
Настройка статического отображения
Запись, отображающая имя в IP-адрес, может быть добавлена в базу данных WINS двумя способами.
Динамически. Этот тип записей создается в базе данных сервера WINS-клиентами в процессе регистрации локальных NetBIOS-имен.
Статически. Администратор создает записи вручную, определяя статическое отображение (static mapping) NetBIOS-имени на IP-адрес.
Статические отображения используются в ситуации, когда необходимо жестко прописать соответствие "имя-адрес" в базе данных WINS-сервера для хоста, который непосредственно не использует WINS. Например, в некоторых сетях серверы под управлением других операционных систем не могут регистрировать свои NetBIOS-имена непосредственно на WINS-сервере. Наличие в базе данных WlNS-сервера подобных отображений, с одной стороны, препятствует регистрации подобных имен другими хостами, а с другой стороны, позволяет задействовать службу WINS для разрешения этих имен в IP-адреса (что может быть актуально в сети, насчитывающей множество подсетей).
Управление базой данных WINS
После того как в сети установлены WINS-серверы и между ними должным образом настроена репликация, служба WINS требует минимального вмешательства администратора. Тем не менее, существует ряд операций, выполнение которых требует участия администратора:
сжатие базы;
резервное копирование базы;
проверка целостности базы.
Переход от 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.
