|
|
|
от Dan DiNicolo |
|
|
Добро пожаловать в статью 22 моей серии. Эта статья посвящена разрешению имен узлов и службе DNS в Windows 2000. Сюда включен обзор разрешения имен узлов, связанные с этим процессом утилиты, интеграция со службой WINS и дополнительные настройки службы DNS в Windows 2000. В данную статью входят следующие темы:
Разрешение имен узлов Многие люди путают имена узлов и имена NetBIOS, когда впервые пытаются разобраться в данной концепции. Упрощая, можно сказать, что имя узла является псевдонимом для его IP-адреса (имя проще запомнить, чем 32-битное число). Если у системы нет IP-адреса, она не будет иметь и имени узла и тогда говорить о разрешении имени узла нет смысла. Причиной для некоторой путаницы является то, что традиционно, в Windows-системах имя NetBIOS и имя узла были одинаковыми по умолчанию, хотя могли возникать случаи, в которых они отличались. Процесс получения имени узла и попытки найти связанный с ним IP-адрес называется разрешением имени узла и может быть выполнен при помощи двух главных средств – файла HOSTS и службы DNS. Файл HOSTS является текстовым файлом и находится в директории %systemroot%\system32\drivers\etc на системе, работающей под Windows 2000. Этот статический файл используется локальной системой для разрешения имени узла в связанный с ним IP-адрес. Это исходная точка, в котором система пытается разрешить имя и поэтому очень важно, чтобы оно не содержало неправильных записей. Заметьте также, что, так как этот файл читается сверху вниз, при нескольких записях для одного имени, только первая будет найдена и использована, а остальные – проигнорированы. Пример файла HOSTS показан ниже:
Любая запись, начинающаяся с символа #, является комментарием. Заметьте, что файлы HOSTS являлись главным инструментом разрешения имен в Интернете до создания службы DNS. Вследствие все больших и больших размеров создаваемых файлов этот метод стал не очень удобным, однако простота его использования для разрешения имен делает его пригодным для работы даже сейчас. Служба DNS была создана в основном для упрощения задач, связанных с созданием и поддержкой единого одноуровневого текстового файла для разрешения имен в Интернет. Доменная система имен является распределенной базой данных, поддерживаемой серверами DNS (большинство из распределенных локализованных текстовых файлов называется файлами зон). Так как я уже описал процесс разрешения имен DNS в предыдущей статье, то не стану еще раз повторять его описание. Если вы до сих пор не поняли основ разрешения имен DNS, пожалуйста, посетите серию статей посвященных данному вопросу, по адресу http://windows.2000trainers.com/coursesandarticles/70-240/. Помните, что главной целью службы DNS является определение IP-адреса узла по его имени (или по FQDN – полному имени узла). Служба DNS образует как бы скелет системы именования в Интернете при помощи 13 корневых серверов (.com, .org и т.д.) имен и тысяч других серверов DNS, существующих в настоящее время (смотрите файл cache.dns в папке %systemroot%system32\dns\samples для обзора списка корневых серверов DNS или вкладку Root Hints свойств сервера DNS). Инструменты и утилиты разрешения имен В Windows 2000 существует целый ряд утилит для разрешения имен узлов и вы должны знать о них. Это такие инструменты, как утилита nslookup, вкладка Monitoring окна свойств сервера DNS, утилита ipconfig и netdiag. Утилита nslookup является наиболее используемой утилитой для выявления неисправностей разрешения имен DNS. В сущности, эта утилита является распознавателем командной строки, при использовании которого клиент DNS посылает серверу DNS запросы различного типа и получает на них ответы. Эта утилита предоставляет быстрый и простой путь для тестирования того, может или нет запрос на разрешение имени быть выполнен при помощи службы DNS. Например, для проверки разрешения имени сервером 10.1.1.1., вы можете выполнить команду nslookup 10.1.1.1. 192.168.1.200, которая вернет адрес узла с IP-адресом 192.168.1.200, если имя узла, связанное с IP-адресом 192.168.1.200 настроено корректно в службе DNS. Вкладка Monitoring, находящаяся в окне свойств сервера DNS, также предоставляет быстрый путь для разрешения имен DNS (хотя я готов поспорить, что она менее используема, исходя из опыта работы) при помощи теста простого или рекурсивного запроса. Рисунок, расположенный ниже, показывает все доступные опции, которые включают возможность запускать этот тест по расписанию автоматически.
Простой запрос посылается от локального распознавателя (клиента) к локально настроенному серверу DNS. Рекурсивный запрос является более сложным шагом, при котором клиент просит сервер использовать рекурсию для поиска сервера имен в корневом (“.”) домене. Это помогает убедиться в том, что корневые ссылки (список корневых серверов) и/или адреса пересылающих серверов настроены корректно. Netdiag – хотя этот инструмент может быть использован для тестирования способности к соединению многих сетей и связанных с этим вопросов, он также может быть использован и специально для выявления неисправностей DNS. Когда вы выполняете команду Netdiag /test:DNS, Netdiag проверит, зарегистрирован ли компьютер корректно на перечисленных серверах DNS, а также то, что служба кэша DNS запущена. Когда Netdiag используется с переключателем /fix, она предпринимает попытку заново зарегистрировать узел в службе DNS, если найденная запись является противоречивой. Ipconfig – хотя эта утилита наиболее часто используется для просмотра информации о конфигурации IP-адреса узла, она также имеет 3 переключателя, напрямую связанные с DNS. Переключатель /displaydns позволяет вам увидеть записи DNS недавно разрешенные и сохраненные в кэше на клиенте. Переключатель /flushdns очищает кэш DNS клиента. И, наконец, переключатель /registerdns форсирует попытку регистрации имени и адреса клиента в настроенном сервере DNS. Файл журнала сервера DNS в программе Event Viewer (Просмотр Событий) – находится на сервере Windows 2000 DNS. Этот файл журнала в Event Viewer предоставляет информацию об ошибках и другую, связанную со службой DNS. Это может послужить отправной точкой для поиска неисправностей, связанных с DNS. Журнал System также может быть использован для поиска записей, относящихся к проблемам разрешения на стороне клиента. Ведение журналов DNS – другая возможность для мониторинга ваших серверов DNS – настройка их для ведения журналов DNS, которые фиксируют выборочную информацию о событиях службы DNS (как показано ниже) в файл dns.log в папке %systemroot%system32\dns на сервере. Однако это может привести к снижению производительности сервера. Поэтому должно использоваться только в целях выявления неисправностей.
Взаимодействие служб DNS и WINS Так как многие сети, работающие под NT 4, основываются на WINS, как главной службе разрешения имен, Microsoft предлагает нестандартный метод для интегрирования служб DNS и WINS. Для этого сервера DNS настраиваются при помощи специальных, связанных с WINS записей, которые могут быть использованы для расширения сферы разрешения имен за пределы записей, известных DNS. Короче говоря, если сервер DNS снабжен адресом сервера WINS (при помощи нестандартной записи WINS), то сервер DNS будет пытаться опрашивать сервера WINS для разрешения имен, не найденных в собственной базе данных. Это возможно сделать при помощи переформатирования запроса в формат запроса NetBIOS, который может быть разрешен сервером WINS, если соответствующая запись будет найдена. Этот способ позволяет многим компаниям создать динамическую службу DNS в NT 4, так как клиенты, IP-адреса которых не зарегистрированы в DNS, могут быть все же разрешены службой WINS, так как база данных WINS обновляется динамически. Этот механизм сохраняется и в Windows 2000, хотя служба DNS в этой OS является динамической. Помните, что клиенты, не являющиеся системами с Windows 2000, не могут использовать динамическую службу DNS. Однако многие компании, имеющие большие сети, реализованные на основе WINS и работающие достаточно хорошо, могут надеяться на дальнейшее их использование. Прежде чем рассмотреть, как можно реализовать взаимодействие служб DNS и WINS, напомню, что DNS-запросы могут быть разрешены серверами, полномочными для зон, в которых существует DNS-домен. Так сервер имен, который полномочен для зоны, в которую входит домен company.com, будет отвечать на запрос для узла server12.company.com. Причина, по которой я напоминаю это, состоит в том, что размещение записей WINS основано на принципах, отличных от реализации DNS. Например, представьте, что ваша компания установила DNS для поддержки Active Directory и реализована так, что только записи для контроллеров домена появляются в DNS. Если вы снабдите зону прямого обзора DNS записью, указывающей на сервер WINS, то этот сервер WINS будет обслуживать запрос, если соответствующая запись не будет обнаружена в DNS. И хотя это хорошо реализуется для одной зоны прямого обзора, для компаний со многими доменами, в которых реализована DNS, картина существенно усложняется (вследствие большой многодоменной конструкции Active Directory). В данном случае каждая зона прямого обзора должна быть настроена для разрешения WINS, что может повлечь большие административные затраты. По этой причине Microsoft рекомендует создавать отдельную доменную структуру Active Directory для целей разрешения WINS. Позвольте объяснить, что это означает. На вкладке Advanced свойств протокола TCP/IP системы (на вкладке DNS, как показано на рисунке, расположенном ниже), вы можете контролировать порядок, в котором домены будут обследоваться с целью разрешения имен. По умолчанию исследуются все домены с суффиксами, добавленными к родительскому, начиная с домена, в котором расположена запрашивающая система. Например, представьте себе, что вы выполняете команду ping server3. Если клиентская система, с которой вы выполняете команду, находится в домене west.company.com, то сначала будет произведена попытка разрешить имя server3.west.company.com (заметьте, что имя домена добавляется автоматически, так как вы не используете FQDN). Если эта попытка провалится, будет проведена попытка разрешить имя server3.company.com (отнимая суффиксы от родительского домена – company.com). Если и эта попытка провалится, это означает, что разрешение имени не удалось.
Рассмотрим, что будет происходить, если вы создадите выделенный домен DNS специально для разрешения имен WINS. Вы можете создать такой домен в вашей структуре DNS и назвать его wins.company.com и сделать его вторым доменом, который будет просматриваться в ходе выполнения разрешения имени. В нашем примере, эта установка будет выглядеть так:
Теперь, если клиент попытается выполнить команду ping имени узла, такого как server3, он сначала запросит имя server3.west.company.com, а если имя не будет разрешено – server3.wins.company.com. Для того чтобы этот механизм работал, зона прямого обзора “wins” должна быть снабжена одной (или более) записями WINS (и WINS-R записями для зоны обратного обзора), указывающими на соответствующие сервера WINS, на которых клиенты и сервера зарегистрированы. Эта установка работает хорошо в том случае, если у вас много доменов и/или субдоменов, когда клиенты DNS настроены так, что сначала запрашивают свой собственный домен, а затем специальный домен “wins”, таким образом используя возможности WINS для разрешения имен. Дополнительные настройки DNS Конечно, существует множество возможных ролей, которые может выполнять сервер DNS, включая такие, как роль корневого сервера (для вашей собственной сети, если это необходимо), кэширующего сервера, пересылающего (forwarder) сервера и т.д. Имеется также большое число дополнительных возможностей, в которых вы, возможно, не слишком хорошо разбираетесь. Так как вам и не надо понимать все мельчайшие детали для сдачи экзамена, я использую эту статью для краткого обзора некоторых вещей, которые вы должны знать для понимания работы Windows 2000 DNS. Зона обратного просмотра – существует для целей сопоставления IP-адресов именам узлов. Если FQDN становится более конкретным при движении справа налево (от корня до имени узла), то IP-адрес наоборот – слева направо. Служба DNS была разработана для разрешения доменов, поддоменов и, в заключении, узлов, двигаясь справа (от корня, например, .com) налево (до узла, например, server16). Однако, представьте себе, как было бы трудно найти машину, о которой известно только, что ее IP-адрес заканчивается так: .200! Количество возможных вариантов делает эту задачу невыполнимой. По этой причине создаются зоны обратного обзора и их отличительная черта состоит в том, что сетевая часть IP-адреса переворачивается и к ней присоединяется специальный домен in-addr.arpa, как суффикс. Так, если сетевой адрес для домена company.com – 131.107.0.0., то связанная с ним зона обратного обзора будет иметь имя – 107.131.in-addr.arpa. Этот адрес теперь может быть разрешен как нормальный DNS-адрес, так как существует ограниченное число идентификаторов подсетей (если точно, то 256), номер которых начинается с 131 и, теоретически, только одна начинается с 131.107. (на самом деле она еще может быть разделена провайдером), что делает идентификацию возможной. Но зачем все это нужно? А затем, что многие приложения используют обратный обзор как инструмент безопасности. И хотя ваша служба DNS в основном действует для прямого обзора имен, имеет, все же смысл создавать для каждой зоны связанную с ней зону обратного обзора. Установка символов – иногда вы можете не знать определенных соглашений, какие символы можно использовать при настройке DNS. А это очень важно, особенно если вы используете различные версии DNS от разных производителей и надеетесь, что они смогут бесконфликтно взаимодействовать друг с другом (например, для целей передачи зон). Если одна из них поддерживает символы, которые не поддерживает другая, то передача зоны может провалиться, что очевидно. Причина кроется в том, что именование Microsoft традиционно основывается на протоколе NetBIOS, который допускает использование символов (таких как подчеркивание, например), которые обычно не используются в именах узлов. Есть 3 главных вида кодировки, которые используются в Windows 2000 DNS. Это:
Вид кодировки устанавливается на вкладке Advanced свойств сервера DNS, в окошке “name checking”, как показано на рисунке, расположенном ниже:
Возможность взаимодействия со стандартом BIND – некоторые компании останавливаются на решении использовать уже существующую структуру DNS для поддержки Active Directory в их сетях. Для экзамена вы должны знать возможность взаимодействия с BIND (Berkeley Internet Naming Daemon), который является одной из самых популярных реализаций сервера DNS на сегодня. Не вникая во множество деталей, вы должны знать, что поддерживаются 3 ключевые версии BIND:
Заметьте, что ни одна из версий BIND не поддерживает кодировку UTF8, а также записи ресурсов WINS и WINS-R. Вы должны учитывать это при организации взаимодействия Windows 2000 и сервера BIND. И это все на этой неделе. Спасибо всем, кто поддерживает мою серию. На следующей неделе я планирую рассказать о маршрутизации в Windows 2000 или об удаленном доступе, в зависимости от того, как много времени мне удастся посвятить этой статье. Осталось всего несколько тем и я надеюсь, что мы завершим нашу работу в мае. До следующей недели и успехов в учебе.
Дэн |
