Службы серверов WINS, DHCP, DNS должны быть установлены на компьютер со статическим IP-адресом.
Установка и настройка WINS
Установка WINS крайне проста: достаточно указать эту службу в составе устанавливаемых компонентов Windows Server. Какой-либо последующей специальной настройки служба WINS не требует. Вам необходимо при "раздаче" клиентам настроек протокола TCP/IP указать только адрес сервера со службой WINS, после чего системы при старте автоматически будут регистрироваться в базе WINS. В случае необходимости (она возникает крайне редко) соответствующие записи можно занести вручную, если воспользоваться консолью управления WINS (статические записи). Если в системе установлено несколько WINS-серверов, то необходимо настроить синхронизацию их баз данных. Для этого на каждом WINS-сервере следует указать адрес другого WINS-сервера, с которым нужно проводить синхронизацию данных.
Примечание Если маршрутизаторы сети пропускают широковещательные сообщения, серверы WINS можно настроить на автоматическое обнаружение партнеров по синхронизации. Для этого достаточно отметить соответствующую опцию на вкладке дополнительных свойств настройки WINS.
WINS-прокси
Компьютеры используют данные базы WINS только в том случае, если соответствующие настройки определены в их параметрах TCP/IP-протокола. Если вы хотите, чтобы все NetBIOS-компьютеры сети могли воспользоваться WINS для разрешения имен, то следует создать в каждом сегменте сети WINS-прокси. Компьютеры, не использующие WINS, для разрешения имен рассылают широковещательные пакеты. WINS-прокси, обнаружив такой пакет, пытается разрешить имя в своем кэше и при неудаче передает запрос на тот WINS-сервер, который зарегистрирован для данной системы. Если сервер WINS возвращает имя, то WINS-прокси передает эти данные той системе, которая Отправила широковещательный запрос.
Для включения режима прокси необходимо установить в 1 параметр EnableProxy В разделе HKLM\System\CurrentControlSet\Services\NetBT\Parameters реестра компьютера, который предполагается использовать в роли WINS-прокси.
Настройка DHCP
Использование DHCP-сервера требует от администратора обязательного определения ряда параметров. Для установки службы достаточно отметить ее в перечне параметров Windows Server, но после установки необходимо выполнить как минимум следующие действия:
создать и настроить зону;
авторизовать DHCP-сервер
.
Примечание При наличии в сети двух DHCP-серверов клиент "возьмет" настройки IP-протокола от того сервера, ответ от которого будет получен первым.
Создание и настройка зоны
Сервер начнет раздавать адреса только после того, как вы зададите диапазон этих адресов и определите необходимые параметры протокола. Делается это путем создания новой области (scope).
Примечание Название области может быть задано произвольно; диапазон адресов менять в процессе работы допустимо, но значение маски подсети, определенное при создании области, изменить невозможно. Можно только удалить область и создать новую с иным значением.
Для области необходимо определить, как минимум, диапазон распределяемых адресов, маску сети и указать срок аренды IP-адреса. Внутри диапазона адресов некоторые адреса можно исключать (например, если вы предполагаете задать их статически). Срок аренды выбирается исходя из особенностей вашей сети. При малом числе компьютеров он может быть существенно увеличен по сравнению со значением по умолчанию в 8 суток (вплоть до неограниченного значения). Желательно в параметрах DHCP-сервера указать, чтобы он проверял IP-адрес перед его выдачей клиенту. Это позволит предупредить конфликты, возникающие при самостоятельном присваивании IP-адресов у клиентов, а также облегчит ситуацию восстановления сервера (например, после полной очистки его баз).
Примечание Если в сети предприятия есть компьютеры с операционной системой до Windows 2000, то целесообразно установить в настройках DHCP обязательную регистрацию выдаваемого адреса на сервере DNS независимо от того, установлена данная опция у клиента или нет.
Авторизация DHCP-сервера
DHCP-серверы на операционных системах Windows 200х, работающих в составе домена Windows, должны быть авторизованы. Если DHCP-сервер не авторизован в службе каталогов, то он не будет выдавать IP-адреса. Чтобы авторизовать сервер, пользователю с правами администратора предприятия необходимо в меню консоли управления DHCP-сервером выбрать пункт Авторизовать сервер.
Примечание Если в вашей сети имеется DHCP-сервер, работающий на платформе Windows NT 4.0 Server или на другой операционной системе, то он будет обслуживать клиентов независимо от авторизации в службе каталогов.
Настройка параметров области
Для полноценной работы в составе компьютерной сети обычно недостаточно получения только IP-адреса и маски сети. Так, клиентам минимально необходимы адреса DNS-ссрверов и адрес шлюза. Кроме того, могут понадобиться DNS-суффикс существующей сети, адрес WINS-сервера, адрес автоматической конфигурации прокси для доступа в Интернет и т. п. Все эти параметры могут сообщаться DHCP-сервером. Дня этого необходимо определить опции области.
Примечание В последних версиях операционных систем мастер создания области автоматически предлагает заполнить основные параметры. При этом могут быть определены как параметры всего сервера, так и параметры области. Обратите внимание, что в случае конфликта параметров клиентам будут сообщаться параметры не сервера, а области.
Вы можете определить любые параметры области (как минимум, необходимо указать те величины, которые запрашиваются мастером создания новой зоны). а при необходимости — и создать собственные.
Резервирование адресов
DHCP-сервер можно настроить так, чтобы он выдавал клиентам не случайный, а заранее определенный адрес.
Примечание Достаточно часто бывают ситуации, когда все адреса в локальной сети раздавались на основе резервирования. Администраторы осуществляли такую статическую настройку адресов для того, чтобы сочетать закрепление адресов, свойственное статическому распределению, с возможностью легкой смены таких параметров, как адрес DNS-сервера.
Чтобы настроить резервирование адреса, необходимо знать МАС-адрес сетевого адаптера соответствующего клиента. Этот адрес достаточно просто определить, если сначала подключить клиента к сети любым способом (например, назначить адрес вручную или автоматически), после чего воспользоваться утилитой агр . Сам процесс резервирования не представляет сложности: достаточно в оснастке управления DHCP-сервером ввести в окне операции резервирования имя клиента и его МАС-адрес.
Примечание Обратите внимание, что для резервированного клиента DHCP-сервер позволяет установить свои, индивидуальные параметры протокола TCP/IP, отличные от параметров области.
"Подстройка" DHCP под группы клиентов
Очень часто администраторы сети хотели бы, чтобы часть клиентов получала IP-адреса из одного диапазона, а часть — из другого, возможно, с отличающимися параметрами настройки протокола TCP/IP. Если такие компьютеры расположены в одном сегменте Ethernet-сети (отсутствуют маршрутизаторы). то подобную конфигурацию DHCP-сервера выполнить невозможно (исключая случай разделения клиентов, использующих загрузку с сети, и клиентов, получающих адрес после старта операционной системы; такой результат достигается просто установкой двух DHCP-серверов, один из которых настроен на обслуживание только клиентов, загружаемых по сети, а другой — остальных). При получении широковещательного запроса на выделение адреса сервер всегда будет отсылать предложение аренды IP-адреса того сегмента сети, в котором он находится сам.
Примечание Если сервер имеет несколько сетевых адаптеров, подключенных к различным сегментам сети, то будут использованы параметры настройки адаптера, ука- занного первым в меню настройки дополнительных опций сетевого подключения.
Существует всего несколько возможностей "выделить" различных клиентов, но только для получения отличающихся параметров области (scope option). Первая возможность— это резервирование клиентов. Для резервированных клиентов можно определить собственные параметры области. Но для создания такого клиента нужно точио знать его МАС-адрес. Вторая возможность — это разделение клиентов по классам: классу вендоров (vendor class) и классу пользователей (user class). Для клиентов класса адми нистратор может настраивать индивидуальные опции DHCP-сервера. Классы DHCP имеют некоторые отличия определения. В DHCP вендором считается производитель соответствующего программного обеспечения oпe- рационной системы. Например, можно разделить клиентов с операционной системой Windows 2000 и операционной системой предыдущих версий. Правда, вы должны руководствоваться лишь теми параметрами, которые заложили сами вендоры. Например, в DHCP-сервере Windows 2000 для клиентов Microsoft можно настроить раздельно только параметры включения/выключения NetBIOS поверх TCP/IP, необходимости освобождения аренды адреса при выключении и метрику шлюза по умолчанию.
Примечание Администраторы могут добавлять описания классов вендоров в параметры DHCP-сервера, но для этого придется узнать по технической документации необходимые настройки соответствующего производителя.
Использование пользовательских классов доступно в серверах DHCP Microsoft, начиная с версии 2000 и выше. Основное отличие от вендорского класса состоит в том, что устанавливать принадлежность к классу могут сами пользователи (с помощью команды ipconfig /setclassid <имя_подключения> <класс>). Например, можно применить пользовательские классы для осуществления различной настройки TCP/IP протокола мобильных и стационарных компьютеров. Конечно, в больших организациях подобную настройку можно включить в образы операционной системы, которая потом будет тиражироваться раздельно по структурам предприятия (например, простым дисковым копированием или путем установки через Remote Installation Service. Но для малых организаций применение пользовательских классов, на мой взгляд, не имеет практического значения.
Обслуживание DHCP-сервером других сегментов сети
С помощью одного DHCP-сервера администраторы могут раздавать IP-адреса различным сегментам своей сети1. Для этого необходимо на DHCP-сервере создать области с диапазонами адресов, соответствующими этим сегментам, и обеспечить получение DHCP-сервером запросов из другого сегмента сети. Создание областей с различными диапазонами IP-адресов выполняется типовым образом: вы создаете область и определяете для нее любой желаемый диапазон адресов. Однако раздавать из области адреса, не соответствующие диапазону собственной подсети, DHCP-сервер не будет, пока не получит адресованного ему запроса из другого сегмента.
Такие запросы может формировать специальный агент — агент ретрансляции DHCP (DHCP Relay Agent), входящий в состав сервера маршрутизации и удаленного доступа (Routing and Remote Access Server, RRAS). Принцип работы агента ретрансляции DHCP достаточно прост. Агент прослушивает сеть на наличие пакетов запроса аренды адреса. Если такой пакет получен, то агент ожидает некоторое время (на случай, если в данном сегменте сети есть свой DHCP-сервер, который и обслужит клиента). Если запрос клиента остается необслуженным, то агент ретранслирует запрос в соседние сегменты сети. Если в соседних сегментах есть DHCP-сервер, то он получает данный запрос и, поскольку запрос отправлен с адреса другого сегмента сети, предоставляет в аренду адрес именно того диапазона, из которого пришел запрос. Для установки программного агента ретрансляции достаточно в настройках IP-маршрутизации (IP Routing, пункт General) соответствующего сервера RRAS выбрать команду создания нового протокола маршрутизации и указать DHCP Relay Agent. В настройках агента ретрансляции следует указать IP-адрес DHCP-сервера, на который будут ретранслироваться запросы аренды адреса. Далее нужно добавить в агент ретрансляции интерфейс (или несколько интерфейсов, если компьютер подключен к нескольким сегментам сети), через который будут пересылаться запросы аренды. Далее при необходимости следует отрегулировать порог ожидания (boot threshold)— время, в течение которого будет ожидаться ответ локального DHCP-сервера, и hop-count threshold— максимальное количество маршрутизаторов, через которые может пройти этот пакет.
Примечание Агента DHCP Relay следует использовать также в тех случаях, когда сеть разделена маршрутизаторами, не пропускающими широковещательный трафик. Иначе сервер DHCP не сможет получить запрос выделения адреса от клиента, находящегося в другом сегменте локальной сети.
Порядок получения IP-адресов клиентами DHCP
Во многих случаях знание процедуры аренды IP-адреса может помочь в диагностике неисправностей сети.
Первичное получение адреса.
При включении компьютера клиент, настроенный на динамическое получение адреса, передает широковещательную рассылку с запросом IP-адреса. Это сообщение называется DHCPDISCOVER. На этот запрос отвечают все DHCP-серверы сегмента сети, предлагая IP-адрес. Соответствующее сообщение называется DHCPOFFER. Выделяемые для аренды адреса на некоторый период резервируются и не предлагаются другим клиентам. Клиент ждет предложения по адресу от сервера DHCP одну секунду. Если оно не приходит ни от одного сервера, то запрос аренды повторяется еще пять раз (через увеличивающиеся промежутки времени приблизительно в течение 30 секунд). Если ответ от DHCP-сервера так и не получен, то клиент получает адрес по технологии APIPA (см, разд. "Адресация APIPA" ранее в этой главе). На первое полученное предложение от DHCP-сервера клиент отвечает широковещательным сообщением (DHCPREQUEST), в котором содержится IP-адрес сервера, выдавшего это предложение. После получения такого сообщения другие DHCP-серверы освобождают зарезервированные ими IP-адреса, а сервер, предложение которого принято, высылает подтверждение (DHCPACK). Только после получения этого подтверждения клиент полностью инициализирует TCP/IP-протокол своего сетевого адаптера.
Продление аренды.
Запрос на продление аренды IP-адреса высылается после истечения половины периода аренды и при каждой перезагрузке системы. Для этого на сервер, выдавший адрес, отправляется DHCPREQUEST-запрос. Если подтверждение получено (DHCPACK), то клиент продолжает использовать текущие параметры конфигурации. Если ответ не получен, то запросы на данный сервер повторяются. Перед окончанием срока аренды и при отсутствии ответа от выдавшего IP-адрес DHCP-сервера клиент высылает уже широковещательные запросы DHCPDISCOVER, пытаясь получить адрес от любого DHCP-сервера.
Примечание При отказе в аренде DHCP-сервером высылается специальный пакет DHCPNACK
Если срок аренды закончился, а клиент не смог ни получить подтверждения от "своего" DHCP-сервера, ни запросить новый IP-адрес, то текущие настройки IP-протокола освобождаются, а клиент получает адрес по APIPA. Если при перезагрузке операционной системы попытка обновления аренды адреса неудачна и клиент не может установить связь со шлюзом по умолчанию, то текущие настройки IP-адреса также освобождаются.
Диагностика и обслуживание DHCP-сервера
Обычно никаких проблем с использованием DHCP-сервера не возникает. В противном случае следует включить протоколирование его работы (опция на одной из вкладок консоли управления сервером). После выявления причин неисправностей для повышения производительности системы ведение журнала работы DHCP-сервера следует отключить. Сервер проводит фоновую дефрагментацию базы данных клиентов. Ручная (офлайновая) дефрагментация имеет смысл только в случае большой нагрузки на серверы (более 1000 записей клиентов). При меньшем числе клиентов ручную дефрагментацию (она проводится при помощи программы jetpack; которая требует предварительной остановки DHCP-сервера) рекомендуется проводить раз в несколько месяцев или еще реже. При возникновении ошибок в базе достаточно просто исполнить операцию reconcile для соответствующей области или всего сервера. При серьезных проблемах допустимо остановить DHCP-сервер и удалить все файлы баз из его каталога. После старта они будут воссозданы с пустыми значениями, которые потом снова заполнятся по получении запросов.
Примечание Для DHCP-серверов существует возможность переноса их с одного компьютера на другой с сохранением всех настроек (областей и их параметров, реальной базы клиентов). Поможет в этом утилита dhcpexim.exe (ее можно свободно загрузить с сайта разработчика операционной системы — http://www.microsoft.com /windows2000/techinfo/reskit/tools/new/dhcpexim-o.asp), позволяющая сохранить все параметры настройки DHCP-сервера в файл, а потом восстановить эти настройки на другом DHCP-сервере. В случае использования Windows Server 2003 перенос данных DHCP-сервера может быть выполнен при помощи операций экспорта и импорта утилиты netsh.
Отказоустойчивая конфигурация Microsoft DHCP-сервера
При построении отказоустойчивых информационных систем важно обеспечить стабильную работу сетевых служб, в том числе сохранить функционирование службы автоматического присвоения параметров IP-адреса в случае выхода сервера DHCP из строя. Реализация DHCP на основе сервера Microsoft имеет серьезный недостаток, связанный с невозможностью создания горячего резерва данной службы для одного диапазона IP-адресов. Документы Microsoft предлагают для повышения отказоустойчивости два способа. Первый заключается в размещении службы DHCP на серверном кластере. В этом случае база адресов будет храниться на общем диске, а при выходе из строя одного сервера его работу "подхватит" второй сервер кластера. К сожалению, такое решение часто не доступно малым и средним организациям из-за высокой стоимости реализации отказоустойчивого кластера. Второй вариант решения проблемы отказоустойчивости службы DHCP заключается в настройке для организации двух серверов DHCP с различными (неперекрывающимися) частями используемого диапазона адресов организации. В этом случае клиент будет получать параметры адреса от любого сервера (вернее, от того, который ответит раньше), а при выходе из строя одного из серверов второй продолжит обслуживание организации.
DNS
В доменах Windows информация о необходимых для работы систем службах хранит DNS. И основное количество проблем функционирования домена (службы каталогов) связано именно с неверной настройкой администраторами службы DNS. Поэтому стоит рассмотреть сервер DNS более подробно.
Термины DNS
DNS (Domain Name System, система доменных имен) — это служба разрешения имен в сетях на основе протокола TCP/IP.
Зоны DNS.
Зона DNS — это часть пространства имен, для которого DNS-сервер может выполнять операции разрешения имен. Существуют зоны прямого и обратного просмотра, которые на практике для удобства называют прямой и обратной зонами. Прямая зона позволяет по имени системы получать ее IP-адрес, обрат-пая— по IP-адресу "выдает" информацию об имени хоста. Поэтому если нужно по имени компьютера узнать его адрес, то говорят о прямом разрешении имени. Если по IP-адресу хотят получить имя компьютера, то в этом случае происходит обратное разрешение имени. Строго говоря, если в DNS зарегистрировано прямое разрешение имени, то должно быть зарегистрировано и обратное.
Примечание Отсутствие обратного разрешения имени является достаточно частой ошибкой в Интернете. Обычно владельцами прямой зоны данного домена и обратной зоны, которая соответствует этому имени, являются разные люди (организации), поэтому в процессе регистрации новых DNS-записей часто забывают создать соответствующую запись обратной зоны.
Фактически прямые зоны соответствуют доменам некоторого уровня. Например, зона xnets.ru позволяет разрешить все запросы имен, относящихся к домену xnets.ru. Для разрешения обратных имен в домене самого верхнего уровня создана зона in-addr.arpa. Названия зон обратного просмотра формируются добавлением к этому имени слева имени трех октетов адреса сети в обратном порядке. Например, для сети 195.161.192.0/24 имя обратной зоны будет | 192.161.195.in-addr.arpa.
В большинстве случаев отсутствие регистрации в обратной зоне не мешает нормальной работе в Сети. Однако оно может и привести к ошибкам в тех случаях, когда необходимо установить по IP-адресу имя сервера. Например, при обмене почтовыми сообщениями в настоящее время принято проверять принадлежность сервера к тому домену, от имени которого он передает почту. Если обратное разрешение имени не будет проведено, то система может получить отказ в приеме почты.
Первичная и вторичная зоны.
У создаваемых записей DNS должен быть один "хозяин". Чтобы все записи были корректны, их необходимо вносить на одном DNS-сервере. В этом случае говорят, что на таком DNS-сервере расположена первичная зона. Для отказоустойчивости на других серверах можно создать копии этой зоны: такие зоны будут называться вторичными зонами. Вторичная зона содержит те же записи, что и первичная, но в нее нельзя вносить изменения или добавлять новые записи. Эти операции можно делать только для первичной зоны.
Серверы имен зоны.
Для каждой первичной зоны можно создать сколько угодно копий на других серверах. Обычно в настройках DNS-серверов предусматриваются специальные механизмы оповещений, которые обеспечивают синхронность записей первичной зоны и ее копий на вторичных серверах. Но, если это не запрещено настройками DNS-сервера, вы можете создать на своем сервере вторичную зону, обновления которой будут производиться по некоему графику. В результате записи такой копии могут оказаться неактуальны. Поэтому принято для домена определять серверы имен, информация которых "официальна". Такие серверы называют NS-записями соответствующего домена. Обычно для каждого домена создается два или три NS-сервера. Если ответ на запрос разрешения имени получен от NS-сервера, то он считается авторизованным, другие серверы возвращают неавторизованные ответы.
Примечание Это не значит, что в этом случае возвращаются неверные данные. DNS-сервер разрешит запрос клиента на основании данных своей копии только в том случае, если эти данные не устарели. Но если срок жизни записей на сервере имен был установлен, например, равным неделе, то в случае внесения изменений в первичную зону необходимо быть готовым к тому, что еще до недели после смены информации на NS-сервере другие серверы DNS могут возвращать старые значения. То есть вы столкнетесь с ситуацией, когда часть систем уже получила правильные данные об имени, а часть — нет. Поэтому перед предполагаемой сменой записей DNS необходимо уменьшить время их жизни и выждать период, равный старому времени жизни. Это позволит сократить период такой неопределенности в разрешении имен. После выполнения операции настройки следует вернуться к старым величинам, чтобы снизить нагрузку на сеть и DNS-серверы.
Если вы предполагаете, что копия DNS-записей на сервере DNS неактуальна, то следует выполнить операцию очистки кэша для соответствующей зоны. Для этого необходимо в консоли управления сервером включить опцию отображения дополнительных параметров, найти нужную зону среди структуры кэша и выполнить для нее очистку. При следующем запросе данных из этой зоны сервер загрузит копию с того сервера DNS, на который настроена пересылка запросов. Поэтому и эта операция также не гарантирует получение актуальной копии записей. При рассмотрении проблемных ситуаций следует выяснить на официальных ресурсах адреса NS-серверов данного домена и проверить записи с помощью утилиты nslookup, подключаясь к соответствующему NS-серверу.
Примечание Для обновления записей DNS на клиентских компьютерах следует очистить кэш DNS-записей (ipconfig /flushdns).
Передача зон.
Так называется специальная операция копирования всех записей данной зоны с одного DNS-сервера на другой. По соображениям безопасности передача зон обычно разрешается только на заранее определенный администратором системы список IP-адресов DNS-серверов. Если операция передачи зоны запрещена, то вы не сможете создать на своем DNS-сервере вторичную зону для данного домена.
Делегирование зон.
Если на DSN-сервере создана, например, прямая зона для домена test.local, то запись о домене третьего уровня Ievel3.test.local должна содержаться на этом же сервере. Если географически домен level3.test.local удален от основного домена, то поддержание записей в его зоне на DNS-сервере становится не очень удобным. Проще поручить администратору этого домена вносить изменения в DNS-записи самостоятельно, для чего используется процесс делегирования зоны. При делегировании зоны DNS-сервер создает у себя запись, указывающую, что запросы разрешения имени для этой зоны должны перенаправляться на другой DNS-сервер, на который произведено делегирование зоны.
Stub-зона (зона-заглушка).
При делегировании зоны на исходном сервере сохраняется информация о NS-сервере делегированной зоны. Поскольку администратор делегированной зоны может изменять ее DNS-записи, то он может сменить и записи NS-сервера. Если соответствующее изменение не будет внесено на сервер, который осуществляет делегирование, то процесс разрешения имен будет нарушен (основной сервер по-прежнему будет отправлять запросы на уже не существующий адрес, и в результате будет формироваться неверный ответ). Для исправления подобной ситуации в DNS-сервере Windows Server 2003 введены stub-зоны. При создании stub-зоны в ней определяются NS-записи делегированной зоны. Причем если администратор делегированной зоны меняет эти записи, то соответствующие изменения вносятся и в записи stub-зоны. В результате гарантируется целостность процесса разрешения имен.
Зона "точка".
Домен самого верхнего уровня, как уже писалось, принято называть именем "точка". Если в DNS создать зону "точка", то это будет фактически значать, что данный сервер является корневым в структуре DNS, т. е. он должен разрешать самостоятельно любые запросы имен. Если этот DNS-сервер не может разрешить имя, то его ответ будет гласить, что такого хоста не существует.
Примечание При необходимости пересылки запросов DNS на другие серверы зону "точка" следует удалить, после чего появится возможность настройки пересылки запросов DNS.
Порядок разрешения имен в DNS Типы запросов.
Для разрешения имен в DNS предусмотрено два типа запросов: итеративный и рекурсивный. Итеративный запрос служит для получения от DNS-сервера, которому он направлен, наилучшего ответа, который может быть получен без обращения к другим DNS-серверам. Рекурсивный запрос предполагает, что сервер DNS должен выполнить все операции для разрешения имени. Обычно для этой цели необходимо выполнить несколько запросов к различным серверам DNS.
Последовательность разрешения DNS-имен.
Процесс определения имени с использованием итеративных запросов весьма трудоемок. Нужно найти NS-сервер для данного домена и затем запросить от него данные по требуемому имени. Обычно клиенты все эти операции "возлагают" на DNS-серверы, отправляя им рекурсивный запрос. DNS-сервер после получения рекурсивного запроса просматривает собственный кэш имен. Если он находит нужную запись и она еще не устарела, то это значение возвращается клиенту. Если записи нет, то сервер предпринимает попытку поиска сервера имен для домена, содержащегося в запросе. Чтобы найти такой сервер, запрос всегда отправляется на корневой сервер, от него получают информацию по домену первого уровня, запросом на домен первого уровня получают информацию о NS-серверах домена второго уровня и т. д. После этого отправляется итеративный запрос на NS-сервер соответствующего домена. Естественно, что большинство информации от корневых доменов уже кэшировано на данном сервере. В результате запросы "не доходят" до корневых серверов, но сама цепочка разрешения имени всегда выполняется от корня до текущего домена. Обычно администраторы локальных DNS-серверов настраивают свой сервер на пересылку (forwarding) запросов разрешения имен на тот или иной сервер DNS (обычно это DNS-сервер провайдера). Тем самым вся процедура разрешения имен будет выполняться уже другим сервером. Поскольку мощные серверы Интернета обычно имеют существенно больший кэш и лучший канал подключения к глобальной сети, то таким способом достигается уменьшение времени ответа и снижение трафика.
Основные типы записей DNS
При создании первичной зоны для своего домена следует обратить внимание на создание некоторых специальных записей ресурсов (resource records), которые полезны для получения информации общего типа:
SOA (Start of Authority).
Серийный номер зоны. В DNS автоматически увеличивается при любом изменении записей зоны. Используется в операциях переноса зон (если номер изменился, то происходит обновление записей вторичной зоны). На практике принято этот номер формировать на основе даты последнего изменения: год-месяц-день-(время). Например, так: 20050810.
NS (Name Server).
Адреса "официальных" серверов имен данной зоны. Эти серверы возвращают авторизованные ответы.
RP (Responsible Person).
Адрес электронной почты лица, ответственного за внесение изменений в записи зоны. Наличие записи и поддержание ее актуальности желательно, чтобы в случае возникновения каких-либо вопросов по домену организации у специалистов были реальные контактные данные. Обратите внимание, что символ э адреса электронной почты заменяется на точку.
A (Host Address).
Эта запись содержит информацию об имени системы и ее IP-адресе. Именно этот тип записи добавляется в DNS-сервер при регистрации хостов.
PTR (Pointer, указатель).
Так называется запись в обратной зоне. Настройками DNS локальных доменов обычно предусматривается автоматическое создание (изменение) PTR-записи при добавлении А-записи в прямую зону.
CNAME (Canonical NAME).
Записи псевдонима. Используются, если хосту необходимо дать второе DNS-имя.
MX (Mail eXchanger).
Запись хранит IP-адрес сервера электронной почты (SMTP-сервера), который обслуживает данный домен. Чтобы на данный домен можно было отправлять электронную почту, в базе DNS для домена должна быть обязательно создана МХ-запись. В целях резервирования может быть создано несколько МХ-записей, причем каждой записи соответствует определенный вес. По умолчанию почта отправляется на адрес, содержащийся в МХ-записи с наименьшим весом. Если этот сервер не отвечает, то делаются попытки отправить почту на адреса, соответствующие МХ-записям с другими весами в порядке их возрастания.
SRV (Запись службы).
Специальный тип записи, используемый для обнаружения в домене служб (например, службы IP-телефонии и т. п.). Записи о системных службах Windows автоматически создаются службой каталогов. Ручное добавление записей осуществляется при настройке дополнительных продуктов в соответствии с прилагаемой технической документацией.
Примечание Кроме описанных существуют и другие типы записей, предназначенные, например, для DNSSEC, IPv6 и т. п., но мы не будем их касаться в этой статье.
Установка сервера DNS
Сервер DNS можно установить только на компьютер со статическим IP-адресом. При этом удостоверьтесь, что сервер DNS, который предназначается для обслуживания организации, может правильно разрешать неполные имена. То есть он должен сообщить правильный адрес как на запрос для test.mydomain.local, так и для запроса на имя test. Для этого необходимо, чтобы основной DNS-суффикс компьютера, на котором устанавливается сервер DNS, совпадал с суффиксом имени домена организации. Соответствующие настройки выполняются в параметрах TCP/IP-протокола, статически устанавливаемых для сетевого адаптера сервера DNS. Для установки службы DNS-сервера достаточно выбрать соответствующую опцию среди добавляемых компонентов. В целях отказоустойчивости информационная система должна быть настроена на использование нескольких серверов DNS.
Примечание Сетевые адаптеры контроллеров домена, на которых установлены DNS-серверы, следует настроить "перекрестно": в качестве первого сервера DNS для адаптера первого контроллера указывается адрес DNS-сервера второго контроллера и наоборот.
После запуска службы DNS следует уточнить некоторые параметры настройки. Во-первых, если сервер должен разрешать имена сети Интернет, то следу-удалить зону "точка" (если такая создана при установке) и указать IP-адpeca тех серверов DNS, на которые будут пересылаться запросы разреше-ния имен. Обычно в качестве таковых указываются DNS-серверы провайдера.
Примечание DNS-сервер Windows Server 2003 позволяет определить для перенаправления запросов различные внешние DNS-серверы а зависимости от зон. Эту опцию целесообразно использовать при наличии нескольких подключений к Интернету и/или к удаленным офисам.
Далее следует создать на сервере DNS необходимые зоны. Эта операция выполняется при помощи соответствующего мастера. Следует учесть, что если сервер предназначен для разрешения имен домена Windows и является контроллером домена, то оптимальным решением будет создание зоны, интегрированной со службой каталогов. Такой вариант позволит использовать службы Windows для репликации данных между серверами DNS. При этом зона DNS на каждом сервере фактически будет являться первичной (допускать внесение изменений), а сами данные— безопасными (при работе с зоной будет использована действующая в Windows система безопасности). Интегрированная в службу каталогов система имен реплицируется в Windows 200л: по всем контроллерам домена. Начиная с Windows Server 2003, добавлена возможность размещения зоны DNS в собственных разделах каталога. Это позволяет реплицировать интегрированные в службу кзталогов зоны только на серверы DNS либо домена, либо леса, в зависимости от того, какой раздел' вы создаете, исходя из структуры организации. Для зон, обслуживающих домен Windows, обязательно должна быть включена опция динамического обновления. В целях безопасности следует выбрать вариант безопасных динамических обновлений записей. При этом рекомендуется, чтобы служба DHCP была настроена на запуск не от системной учетной записи, а от имени специально созданного для такой цели пользователя. Если вы не хотите регистрировать всех клиентов в DNS, то можно настроить сервер DNS так, чтобы он перенаправлял неразрешенные запросы имени на WINS-сервер. Для этого в настройках DNS-сервера в свойствах зоны на вкладке WINS следует включить опцию пересылки запросов на WINS-сервер и указать соответствующие IP-адреса. После установки и настройки основных параметров DNS-сервера необходимо выполнить его первичную проверку. Для этого следует в свойствах сервера на вкладке мониторинга включить опции проверки как работы самого сервера, так и правильности перенаправления запросов и провести тест, после чего проверить корректность разрешения имен как внутренней сети, так и внешней (если сервер DNS используется и для разрешения имен Интернета) с помощью команды nslookup.
Примечание При создании домена одновременно с установкой DNS прямая зона создается автоматически. Зону обратного разрешения следует создать вручную.
Записи домена Windows
Если на сервере DNS зарегистрирована зона, соответствующая домену Windows, то в этой зоне должны присутствовать специализированные записи, которые определяют нахождение служб каталогов домена. Данные записи создаются автоматически через некоторое время после установки службы каталогов.
Эти записи используются для нахождения служб, отвечающих за функционирование как домена, так и всего леса, поэтому все компьютеры леса должны иметь возможность разрешать имена в зоне _msdсs.<имя_домена>. Поскольку в Windows 2000 интегрированная зона DNS реплицируется только внутри домена, то администратору следует принять меры, обеспечивающие доступность зоны _msds.<имя_домена> во всех доменах организации. Возможный вариант— это замена зоны _msdcs внутри зоны <имя_домена> на делегированную зону, и размещение новой зоны _msdcs.<имя_домена> на этом же сервере DNS с последующей настройкой ее вторичных зон на всех серверах DNS организации.
Разделение DNS
Все большее число сотрудников начинают использовать мобильные компьютеры для доступа к ресурсам организации как изнутри локальной сети, так и из Интернета. В целях сокращения затрат на изменение конфигураций персональных компьютеров следует выполнять настройки программного обеспечения так, чтобы доступ к сетевым ресурсам локальной сети осуществлялся единообразно, независимо от того, выполняется подключение из локальной или глобальной сети. Реализуется такое требование разделением DNS (DNS split).
Технология разделения DNS подразумевает, что разрешение имен локальной сети и Интернета для одного доменного имени настраивается на различные DNS-серверы. Суть решения будет понятна из рассмотрения двух возможных ситуаций.
Примечание Мы не рассматриваем вариант использования ресурсов локальной сети через VPN-подключение, поскольку в этом случае удаленный компьютер фактически становится членом локальной сети.
Одинаковые имена локального домена и домена Интернета.
Если имя домена Windows совпадает с именем домена Интернета, то единственная необходимая операция — это правильная настройка публи- кации внутренних ресурсов в глобальной сети. Когда клиент локальной сети пытается получить доступ к каким-либо ресурсам, он запрашивает их месторасположение у локального, внутреннего сервера DNS. Этот сервер возвращает клиенту внутренний адрес ресурса, к которому и осуществляется подключение . На сервере DNS, обслуживающем домен Интернета этой же организации, необходимо настроить А-запись соответствующего ресурса на внешний адрес брандмауэра данной организации, а на брандмауэре настроить публикацию внутреннего ресурса таким образом, чтобы запрос, приходящий на брандмауэр и адресованный на данное имя, перенаправлялся на локальный адрес ресурса. В результате, независимо от точки подключения, запрос клиента всегда будет доставлен на один и тот же локальный ресурс системы. При использовании технологии разделения DNS клиент локальной сети и компьютер Интернета при разрешении одного и того же имени будут обращаться к различным DNS-серверам. В результате локальный клиент будет обращаться по локальному адресу, а клиент Интернета перешлет запрос на брандмауэр организации, который и перенаправит его на локальный адрес запрашиваемого ресурса.
Различные имена локального домена и домена Интернета.
Если "внутреннее" и "внешнее" имена домена организации не совпадают, то на внутреннем сервере DNS необходимо создать первичную зону для домена с "внешним" именем. Далее в этой зоне следует создать записи, соответствующие именам систем, предоставляющих необходимые службы , причем в качестве IP-адресов этих записей должны быть указаны локальные IP-адреса систем. Таким образом, на внутренних DNS-серверах будет по две зоны: зона, соответствующая "внутреннему" домену Windows (реальные внутренние названия компьютеров локальной сети), и зона с "внешним" именем (фактически содержащая синонимы, вторые имена только для компьютеров, публикующих ресурсы в глобальной сети). Так же, как и в предыдущем примере, следует настроить публикацию внутренних ресурсов на брандмауэре организации. Клиентов необходимо настроить (в том числе и в локальной сети) на подключение к ресурсам по внешним именам. Если клиент обратится к почтовому серверу изнутри организации, то он запросит внутренний сервер DNS об адресе, соответствующем внешнему имени почтовой системы. Поскольку на внутреннем сервере DNS существует одноименная первичная зона, то сервер будет считаться авторизованным для ответов и сообщит клиенту внутренний адрес почтовой системы. Произойдет подключение по локальному адресу системы. А если, например, клиенту необходимо обратиться к этому же почтовому серверу из Интернета, то он запросит внешний сервер DNS, получит от него адрес брандмауэра и отправит запрос на него. Брандмауэр, получив запрос, проанализирует его и перешлет на локальный адрес почтовой системы.
Настройка удаленных офисов.
Возможны различные варианты конфигурации разрешения имен для удаленных офисов. В наиболее часто используемом случае подключения удаленного офиса к основному через Интернет по VPN-каналу можно реализовать следующую настройку DNS. DNS-сервер удаленного офиса настроить на пересылку запросов разрешения имени на DNS-сервер интернет-провайдера, а пересылку запросов на разрешение внутренних имен настроить на DNS-сервер центрального офиса. Такая конфигурация легко реализуется на DNS-серверах Windows Server 2003. В случае использования DNS на базе Windows 2000 можно осуществить передачу внутренней зоны на DNS-сервер удаленного офиса.
Примечание Ресурсом, для которого наиболее часто приходится реализовывать подключение пользователей как изнутри организации, так и снаружи, является почтовая система. Если в организации установлен MS Exchange Server и клиенты применяют MS Outlook (полной версии), то для локального подключения к почтовой системе по умолчанию применяется протокол RPC. Подключение по этому протоколу использует динамическое открытие портов на сервере, что вызывает серьезные сложности в настройке брандмауэра при подключении клиента Outlook из глобальной сети. В результате на практике такое подключение из Интернета фактически не использовалось. Начиная с Windows Server 2003, для реализации всей функциональности полной версии Outlook предназначена специальная технология создания RPC Proxy, которая подробно описана в документах базы данных Microsoft (см. документ "Exchange Server 2003 RPC over HTTP Deployment Scenarios" или KB 833401). Обратите внимание, что одновременно следует настроить и клиента Outlook так, чтобы по умолчанию для подключения к почтовому серверу Exchange использовался вариант RPC over HTTP (статья "Configuring Outlook 2003 for RPC over HTTP").
