Учебное пособие

Самоучитель системного администратора

       

3.5. Настройка серверов WINS, DHCP, DNS

Службы серверов 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, но после установки необходимо выполнить (в Windows 2008 Server указанные шаги предлагает выполнить мастер установки роли) как минимум следующие действия:

  • создать и настроить зону;
  • авторизовать DHCP-сервер. Примечание

    При наличии в сети двух DHCP-серверов клиент "возьмет" настройки IP-протокола от того сервера, ответ от которого будет получен первым (см. разд. "Порядок получения IP-адресов клиентами DHCP" далее в этой главе).

Создание и настройка зоны

Сервер начнет раздавать адреса только после того, как вы зададите диапазон этих адресов и определите необходимые параметры протокола. Делается это путем создания новой области (scope).

    Примечание

    Название области может быть задано произвольно; диапазон адресов менять в процессе работы допустимо, но значение маски подсети, определенное при создании области, изменить невозможно. Можно только удалить область и создать новую с иным значением.

Для области необходимо определить, как минимум, диапазон распределяемых адресов, маску сети и указать срок аренды IP-адреса. Внутри диапазона адресов некоторые адреса можно исключать (например, если вы предполагаете задать их статически). Срок аренды выбирается исходя из особенностей вашей сети. При малом числе компьютеров он может быть существенно увеличен по сравнению со значением по умолчанию в 8 суток (вплоть до неограниченного значения).

Желательно в параметрах DHCP-сервера указать, чтобы он проверял IP-адрес перед его выдачей клиенту. Это позволит предупредить конфликты, возникающие при самостоятельном присваивании IP-адресов у клиентов, а также облегчит ситуацию восстановления сервера (например, после полной очистки его баз).

    Примечание

    Если в сети предприятия есть компьютеры с операционной системой до Windows 2000, то целесообразно установить в настройках DHCP обязательную регистрацию выдаваемого адреса на сервере DNS независимо от того, установлена данная опция у клиента или нет.

Авторизация DHCP-сервера

DHCP-серверы на операционных системах Windows 200х, работающих в составе домена Windows, должны быть авторизованы. Если DHCP-сервер не авторизован в службе каталогов, то он не будет выдавать IP-адреса. Чтобы авторизовать сервер, пользователю с правами администратора предприятия необходимо в меню консоли управления DHCP-сервером выбрать пункт Авторизовать сервер. Индикатор, свидетельствующий об авторизации сервера, выдает статус с некоторой (обычно до 5 мин) задержкой. Поэтому после авторизации сервера следует выдержать незначительный промежуток времени и открыть консоль управления снова, чтобы убедиться в полной работоспособности сервера.

Если в вашей сети установлен DHCP-сервер на другой операционной системе, например на платформе Windows NT 4.0 Server или на Linux, то он будет обслуживать клиентов независимо от авторизации в службе каталогов.

Настройка параметров области

Для полноценной работы в составе компьютерной сети обычно недостаточно получения только IP-адреса и маски сети. Так, клиентам минимально необходимы адреса DNS-серверов и адрес шлюза. Кроме того, могут понадобиться DNS-суффикс существующей сети, адрес WINS-сервера, адрес автоматической конфигурации прокси для доступа в Интернет и т. п. Все эти параметры могут сообщаться DHCP-сервером.

Для этого необходимо определить опции области.

    Примечание

    В последних версиях операционных систем мастер создания области автоматически предлагает заполнить основные параметры. При этом могут быть определены как параметры всего сервера, так и параметры области. Обратите внимание, что в случае конфликта параметров клиентам будут сообщаться параметры не сервера, а области.

Вы можете определить любые параметры области (как минимум, необходимо указать те величины, которые запрашиваются мастером создания новой зоны), а при необходимости — и создать собственные. Описание дополнительных параметров обычно включаются в документацию прикладного программного обеспечения, которому необходимы дополнительные настройки DHCP.

Резервирование адресов

DHCP-сервер можно настроить так, чтобы он выдавал клиентам не случайный, а заранее определенный адрес.

    Примечание

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

Чтобы настроить резервирование адреса, необходимо знать MAC-адрес сетевого адаптера соответствующего клиента, причем для новых сетевых адаптеров MAC-адрес может быть определен по их упаковке (вторая часть адреса — это серийный номер адаптера). Этот адрес достаточно просто определить, если сначала подключить клиента к сети любым способом (например, назначить адрес вручную или автоматически), после чего воспользоваться утилитой arp (см. разд. "Протокол ARP” ранее в этой главе).

Сам процесс резервирования не представляет сложности: достаточно в оснастке управления DHCP-сервером ввести в окне операции резервирования имя клиента и его MAC-адрес.

    Примечание

    Обратите внимание, что для резервированного клиента DHCP-сервер позволяет установить свои, индивидуальные параметры протокола TCP/IP, отличные от параметров области.

"Подстройка" DHCP под группы клиентов

Очень часто администраторы сети хотели бы, чтобы часть клиентов получала IP-адреса из одного диапазона, а часть — из другого, возможно, с отличающимися параметрами настройки протокола TCP/IP.

Существует всего несколько возможностей "выделить" различных клиентов, но только для получения отличающихся параметров области (scope option).

Первая возможность — это резервирование клиентов. Для резервированных клиентов можно определить собственные параметры области. Но для создания такого клиента нужно точно знать его MAC-адрес.

Вторая возможность — это разделение клиентов по классам: классу вендоров (vendor class) и классу пользователей (user class). Для клиентов класса администратор может настраивать индивидуальные опции DHCP-сервера. Например, в DHCP вендором считается производитель соответствующего программного обеспечения операционной системы. В результате можно разделить клиентов с операционными системами разных версий и вендоров.

    Примечание

    Администраторы могут добавлять описания классов вендоров в параметры DHCP-сервера, но для этого придется узнать по технической документации необходимые настройки соответствующего производителя.

Использование пользовательских классов доступно в серверах DHCP Microsoft, начиная с версии 2000 и выше. Основное отличие от вендорского класса состоит в том, что устанавливать принадлежность к классу могут сами пользователи (с помощью команды ipconfig /setclassid <имя_подклкчения> <класс>). Например, можно применить пользовательские классы для осуществления различной настройки TCP/IP-протокола мобильных и стационарных компьютеров.

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

Обслуживание DHCP-сервером других сегментов сети

С помощью одного DHCP-сервера администраторы могут раздавать IP-адреса различным сегментам своей сети. Для этого необходимо на DHCP-сервере создать области с диапазонами адресов, соответствующими этим сегментам, и обеспечить получение DHCP-сервером запросов из другого сегмента сети.

    Примечание

    Для соединения сегментов могут использоваться RFC-1542-совместимые маршрутизаторы, которые имеют возможность пропускать пакеты с запросом аренды адреса. Однако обычно такая настройка достаточно трудоемка, требует внимательного анализа конфигурации сети и нечасто применяется на практике.

Создание областей с различными диапазонами IP-адресов выполняется типовым образом: вы создаете область и определяете для нее любой желаемый диапазон адресов. Однако раздавать из области адреса, не соответствующие диапазону собственной подсети, DHCP-сервер не будет, пока не получит адресованного ему запроса из другого сегмента.

Такие запросы может формировать специальный агент — агент ретрансляции DHCP (DHCP Relay Agent). Обычно используется агент ретрансляции, установленный на коммутационном оборудовании. Но можно задействовать и агент, входящий в состав сервера маршрутизации и удаленного доступа (Routing and Remote Access Server, RRAS).

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

Для установки программного агента ретрансляции достаточно в настройках IP-маршрутизации (IP Routing, пункт General) соответствующего сервера RRAS выбрать команду создания нового протокола маршрутизации и указать DHCP Relay Agent. В настройках агента ретрансляции следует указать IP-адрес DHCP-сервера, на который будут ретранслироваться запросы аренды адреса.

Далее нужно добавить в агент ретрансляции интерфейс (или несколько интерфейсов, если компьютер подключен к нескольким сегментам сети), через который будут пересылаться запросы аренды. Затем при необходимости следует отрегулировать порог ожидания (boot threshold) — время, в течение которого будет ожидаться ответ локального DHCP-сервера, и hop-count threshold — максимальное количество маршрутизаторов, через которые может пройти этот пакет.

Порядок получения IP-адресов клиентами DHCP

Во многих случаях знание процедуры аренды IP-адреса может помочь в диагностике неисправностей сети.

Первичное получение адреса

При включении компьютера клиент, настроенный на динамическое получение адреса, передает широковещательную рассылку с запросом IP-адреса (запрос идет от адреса 0.0.0.0 с маской 255.255.255.255). Это сообщение называется 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-сервер и удалить все файлы баз из его каталога. После старта они будут воссозданы с пустыми значениями, которые потом снова заполнятся по получении запросов.

DNS

В доменах Windows информация о необходимых для работы систем службах хранит DNS. И основное количество проблем функционирования домена (службы каталогов) связано именно с неверной настройкой администраторами службы DNS. Поэтому стоит рассмотреть сервер DNS более подробно.

Термины DNS

DNS (Domain Name System, система доменных имен) — это служба разрешения имен в сетях на основе протокола TCP/IP.

- Зоны DNS.

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

Прямая зона позволяет по имени системы получать ее IP-адрес, обратная — по IP-адресу "выдает" информацию об имени хоста. Поэтому если нужно по имени компьютера узнать его адрес, то говорят о прямом разрешении имени. Если по IP-адресу хотят получить имя компьютера, то в этом случае происходит обратное разрешение имени. Строго говоря, если в DNS зарегистрировано прямое разрешение имени, то должно быть зарегистрировано и обратное.

    Примечание

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

Фактически прямые зоны соответствуют доменам некоторого уровня. Например, зона ask.ru позволяет разрешить все запросы имен, относящихся к домену ask.ru.

Для разрешения обратных имен в домене самого верхнего уровня создана зона in-addr.arpa. Названия зон обратного просмотра формируются добавлением к этому имени слева имени трех октетов адреса сети в обратном порядке. Например, для сети 195.161.192.0/24 имя обратной зоны будет 192.161.195.in-addr.arpa.

В большинстве случаев отсутствие регистрации в обратной зоне не мешает нормальной работе в Сети. Однако оно может и привести к ошибкам в тех случаях, когда необходимо установить по IP-адресу имя сервера. Например, при обмене почтовыми сообщениями в настоящее время принято проверять принадлежность сервера к тому домену, от имени которого он передает почту. Если обратное разрешение имени не будет проведено, то система может получить отказ в приеме почты.

- Первичная и вторичная зоны.

У создаваемых записей DNS должен быть один "хозяин". Чтобы все записи были корректны, их необходимо вносить на одном DNS-сервере. В этом случае говорят, что на таком DNS-сервере расположена первичная зона. Для отказоустойчивости на других серверах можно создать копии этой зоны: такие зоны будут называться вторичными зонами. Вторичная зона содержит те же записи, что и первичная, но в нее нельзя вносить изменения или добавлять новые записи. Эти операции можно делать только для первичной зоны. В случае домена Windows 200х и использования зоны DNS, интегрированной со службой каталогов, изменения можно вносить на любом DNS-сервере такой зоны.

- Серверы имен зоны.

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

    Примечание

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

Если вы предполагаете, что копия DNS-записей на сервере DNS неактуальна, то следует выполнить операцию очистки кэша для соответствующей зоны. Для этого необходимо в консоли управления сервером включить опцию отображения дополнительных параметров, найти нужную зону среди структуры кэша и выполнить для нее очистку. При следующем запросе данных из этой зоны сервер загрузит копию с того сервера DNS, на который настроена пересылка запросов. Поэтому и эта операция также не гарантирует получение актуальной копии записей. При рассмотрении проблемных ситуаций следует выяснить на официальных ресурсах адреса NS-серверов данного домена и проверить записи с помощью утилиты nslookup, подключаясь к соответствующему NS-серверу (см. разд. "Обслуживание и диагностика неисправностей DNS-сервера" далее в этой главе).

    Примечание

    Для обновления записей DNS на клиентских компьютерах следует очистить кэш DNS-записей (ipconfig /flushdns).

- Передача зон.

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

- Делегирование зон.

Если на DSN-сервере создана, например, прямая зона для домена test.local, то запись о домене третьего уровня level3.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 автоматически увеличивается при любом изменении записей зоны. Используется в операциях переноса зон (если номер изменился, то происходит обновление записей вторичной зоны). На практике принято этот номер формировать на основе даты последнего изменения: год-месяц-день-(время). Например, так: 20110810.

- 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 для домена должна быть обязательно создана MX-запись. В целях резервирования может быть создано несколько MX-записей, причем каждой записи соответствует определенный вес. По умолчанию почта отправляется на адрес, содержащийся в MX-записи с наименьшим весом. Если этот сервер не отвечает, то делаются попытки отправить почту на адреса, соответствующие MX-записям с другими весами в порядке их возрастания.

- SRV (Запись службы).

Специальный тип записи, используемый для обнаружения в домене служб (например, службы IP-телефонии и т. п.). Записи о системных службах Windows автоматически создаются службой каталогов. Ручное добавление записей осуществляется при настройке дополнительных продуктов в соответствии с прилагаемой технической документацией.

    Примечание

    Кроме описанных существуют и другие типы записей, предназначенные, например, для DNSSEC, IPv6 и т. п., но мы не будем их касаться в этой книге.

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

Сервер DNS можно установить только на компьютер со статическим IP-адресом. При этом удостоверьтесь, что сервер DNS, который предназначается для обслуживания организации, может правильно разрешать неполные имена. То есть он должен сообщить правильный адрес как на запрос для test.mydomain.local, так и для запроса на имя test. Для этого необходимо, чтобы основной DNS-суффикс компьютера, на котором устанавливается сервер DNS, совпадал с суффиксом имени домена организации. Соответствующие настройки выполняются в параметрах TCP/IP-протокола, статически устанавливаемых для сетевого адаптера сервера DNS.

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

После запуска службы DNS следует уточнить некоторые параметры настройки. Во-первых, если сервер должен разрешать имена сети Интернет, то следует удалить зону "точка" (если такая создана при установке) и указать IP-адреса тех серверов DNS, на которые будут пересылаться запросы разрешения имен. Обычно в качестве таковых указываются DNS-серверы провайдера.

Далее следует создать на сервере DNS необходимые зоны. Эта операция выполняется при помощи соответствующего мастера. Следует учесть, что если сервер предназначен для разрешения имен домена Windows и является контроллером домена, то оптимальным решением будет создание зоны, интегрированной со службой каталогов. Такой вариант позволит использовать службы Windows для репликации данных между серверами DNS. При этом зона DNS на каждом сервере фактически будет являться первичной (допускать внесение изменений), а сами данные — безопасными (при работе с зоной будет применена действующая в Windows система безопасности).

Интегрированная в службу каталогов система имен реплицируется в Windows 200х по всем контроллерам домена. Начиная с ОС Windows Server 2003, добавлена возможность размещения зоны DNS в собственных разделах каталога. Это позволяет реплицировать интегрированные в службу каталогов зоны только на серверы DNS либо домена, либо леса, в зависимости от того, какой раздел вы создаете, исходя из структуры организации. Создание такого раздела выполняется из оснастки управления DNS-сервером (соответствующая команда меню сервера).

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

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

После установки и настройки основных параметров DNS-сервера необходимо выполнить его первичную проверку. Для этого следует в свойствах сервера на вкладке мониторинга включить опции проверки как работы самого сервера, так и правильности перенаправления запросов и провести тест, после чего проверить корректность разрешения имен как внутренней сети, так и внешней (если сервер DNS используется и для разрешения имен Интернета) с помощью команды nslookup (см. разд. "Обслуживание и диагностика неисправностей DNS-сервера" далее в этой главе).

    Примечание

    При создании домена одновременно с установкой DNS прямая зона создается автоматически. Зону обратного разрешения следует создать вручную.

Записи домена Windows

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

Разделение DNS

Все большее число сотрудников начинают использовать мобильные компьютеры для доступа к ресурсам организации как изнутри локальной сети, так и из Интернета. В целях сокращения затрат на изменение конфигураций персональных компьютеров следует выполнять настройки программного обеспечения так, чтобы доступ к сетевым ресурсам локальной сети осуществлялся единообразно, независимо от того, выполняется подключение из локальной или глобальной сети. Реализуется такое требование разделением DNS (DNS split).

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

- Одинаковые имена локального домена и домена Интернета.

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

Рис. 3.11.
Разделение DNS

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

В результате, независимо от точки подключения, запрос клиента всегда будет доставлен на один и тот же локальный ресурс системы.

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

- Различные имена локального домена и домена Интернета.

Если "внутреннее" и "внешнее" имена домена организации не совпадают, то на внутреннем сервере DNS необходимо создать первичную зону для домена с "внешним" именем. Далее в этой зоне следует создать записи, соответствующие именам систем, предоставляющих необходимые службы (естественно, что изменение записей этой зоны должно выполняться только вручную), причем в качестве IP-адресов этих записей должны быть указаны локальные IP-адреса систем. Таким образом, на внутренних DNS-серверах будет по две зоны: зона, соответствующая "внутреннему" домену Windows (реальные внутренние названия компьютеров локальной сети), и зона с "внешним" именем (фактически содержащая синонимы, вторые имена только для компьютеров, публикующих ресурсы в глобальной сети). Так же, как и в предыдущем примере, следует настроить публикацию внутренних ресурсов на брандмауэре организации.

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

А если, например, клиенту необходимо обратиться к этому же почтовому серверу из Интернета, то он запросит внешний сервер DNS, получит от него адрес брандмауэра и отправит запрос на него. Брандмауэр, получив запрос, проанализирует его и перешлет на локальный адрес почтовой системы.

Настройка DNS в удаленных офисах

Возможны различные варианты конфигурации разрешения имен для удаленных офисов. В наиболее часто используемом случае подключения удаленного офиса к основному через Интернет по VPN-каналу можно реализовать следующую настройку DNS. DNS-сервер удаленного офиса настроить на пересылку запросов разрешения имени на DNS-сервер интернет-провайдера, а пересылку запросов на разрешение внутренних имен настроить на DNS-сервер центрального офиса. Такая конфигурация легко реализуется на DNS-серверах Windows Server 2003/2008.

    Примечание

    Ресурсом, для которого наиболее часто приходится реализовывать подключение пользователей как изнутри организации, так и снаружи, является почтовая система. Если в организации установлен MS Exchange Server и клиенты применяют MS Outlook (полной версии), то для локального подключения к почтовой системе по умолчанию применяется протокол RPC. Подключение по этому протоколу использует динамическое открытие портов на сервере, что вызывает серьезные сложности в настройке брандмауэра при подключении клиента Outlook из глобальной сети. В результате на практике такое подключение из Интернета фактически не использовалось. Начиная с Windows Server 2003, для реализации всей функциональности полной версии Outlook предназначена специальная технология создания RPC Proxy, которая подробно описана в документах базы данных Microsoft (см. документ "Exchange Server 2003 RPC over HTTP Deployment Scenarios" или КВ 833401). Обратите внимание, что одновременно следует настроить и клиента Outlook так, чтобы по умолчанию для подключения к почтовому серверу Exchange использовался вариант RPC over HTTP (статья "Configuring Outlook 2003 for RPC over HTTP").

Обслуживание и диагностика неисправностей DNS-сервера

Самый простой способ проверить работоспособность сервера — включить опции мониторинга на соответствующей вкладке консоли управления. Вы должны получить положительную диагностику при тестировании самого сервера и ответа от сервера, на который настроена пересылка запросов.

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

Универсальная утилита, которую можно использовать для получения данных с любого DNS-сервера (и, соответственно, проверки его работоспособности), — это nslookup, которая вызывается одноименной командой. Она по умолчанию присутствует среди утилит в системах с установленным протоколом TCP/IP.

Утилита nslookup позволяет вручную получить от сервера DNS такую же информацию, какую системы получают в автоматическом режиме при разрешении имен. Поэтому она часто используется при диагностике систем.

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

Рассмотрим пример использования программы nslookup (строки, вводимые пользователем, в начале строки отмечены знаком >).

    Примечание

    После запуска программа выдала сообщение, что подключена к DNS-серверу ack с IP-адресом 192.168.0.10.

    Примечание

    В окне программы nslookup была введена команда подключения к DNS-серверу ns.unets.ru. В ответ программа сообщила, что подключилась к этому серверу и сообщила его IP-адрес.

    Примечание

    Пользователь ввел запрос на разрешение имени uzvt.ru. Утилита сообщила, что сервер ns.unets.ru предоставил неавторизованную информацию (Non-authoritative answer) об этом имени. Из того, что сервер "вернул" данные NS-записей, следует, что uzvt.ru — это домен Интернета, что его серверы имен — ns.e-burg.ru и ns.isp.ru.

    Примечание

    Следующими командами пользователь определил, что ему нужна информация о почтовых серверах (set type=mx), и вновь указал в запросе тот же домен (uzvt.ru). Утилита вернула от сервера DNS ответ, что для домена зарегистрированы два почтовых сервера с разными приоритетами (mail.uzvt.ru, приоритет 10 и relay.utnet.ru, приоритет 50), и сообщила их адреса. Поскольку mail.uzvt.ru имеет меньший приоритет, то именно по этому адресу и будет направляться электронная почта для домена uzvt.ru.

Для проверки разрешения имен DNS почтового сервера MS Exchange используется специальная утилита, которую необходимо загрузить с сайта Microsoft — dnsdiag. Эта программа должна быть запущена на компьютере почтового сервера из папки информационного сервера (IIS) с помощью команды dnsdiag.

Выходная информация программы полностью соответствует тем данным, которые получает почтовый сервер в процессе разрешения имен. Эта информация может помочь в диагностике проблемных ситуаций.

Рассмотрим пример использования утилиты dnsdiag.

    Примечание

    В примере вызова утилиты после параметра v стоит цифра 1. Это номер виртуального сервера, соответствующего почтовому серверу (может быть иным в зависимости от конфигурации системы).

Утилита сообщила параметры MX-записи для домена mail.ru и необходимую дополнительную информацию.

Перенос записей зон

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

 

 

 

Top.Mail.Ru
Top.Mail.Ru