Систему доменных имен DNS (Domain Name System) разработал Пол Мокапетрис (Paul Mokapetris), который на заре интернета (в начале 1980-х) задался вопросом, как работать в системе (она стала со временем называться DNS), которая преобразует Web-адрес в состоящий из четырех октетов IP-адрес, который используется сетевыми машинами для связи через TCP/IP (см. лекцию 1). Мокапетрис разработал иерархическое пространство имен, которое позволяло присваивать машинам понятные (дружественные) пользователям имена и связывать эти имена с IP-адресами. Эти группы машин разбивались на домены, и в каждом домене предусматривалось свое собственное управление
DNS можно также использовать для поиска элементов, хранящихся в базе данных
LDAP. DNS – это клиент/
Создается впечатление, что эта интеграция с AD является обязательной, но это не так, если вы не планируете создавать домены и леса (более подробно об этом см. в лекции 10). И даже в этом случае она не является обязательной, но вам следует объединить эти два компонента, если вы хотите свести к минимуму администрирование. Возможно, у вас есть UNIX-станции; можно использовать DNS на Microsoft-станциях в стандартной (классической) конфигурации с первичным (primary) и вторичным (secondary) серверами DNS, если вам не нужен или вы не хотите использовать домен в своем окружении. Однако предпочтительно использовать конструкции леса/домены с контроллерами доменов через Active Directory.
Цель этой лекции – способствовать пониманию разрешения имен в целом, и, в частности, DNS, с выделением отличий между Windows 2000 и 2003. Вы также узнаете о прежней форме разрешения имен, которая применялась фирмой Microsoft: разрешение имен NetBIOS, которое происходило с помощью службы WINS (Windows Internet Naming Service).
Все началось с файлов HOSTS. Это "плоские" текстовые файлы ASCII, содержащие построчный набор записей. Эти записи только представляли связь IP-адреса с именем машины, например, 192.168.1.1 Trucker.Truckstp.com. Идея состояла в том, что Trucker – это легко запоминаемое имя машины, а resolver (клиентский компонент, состоящий из программной части и библиотек на клиентском компьютере) читает этот файл, находит имя машины, извлекает ее IP-адрес и выполняет поиск по этому адресу.
Вы можете все еще использовать файлы HOSTS; обычно они находятся в подпапке %SYSTEMROOT\system32\drivers\... Вы можете редактировать такой файл с
помощью Блокнота (Notepad) и добавлять в него любую машину, если у вас есть
имя и IP-адрес этой машины, и вы знаете об изменениях в сети, которые могут повлиять
на эти записи. Использование файла HOSTS сопряжено с ошибками, например,
возможно дублирование имен или адресов. Этот подход не позволяет поддерживать
масштабирование; достаточно представить себе, сколько затруднений
может вызвать поддержка этих файлов для крупного предприятия. На каждой машине!
Без каких-либо средств безопасности!
Файлы HOSTS – это опасное средство, а разрешение имен должно реализоваться надежным образом. Ответом на эту задачу стала DNS. Вместе со своей базой данных и инструментами, а также благодаря своей распределенной природе подходящая структура DNS обеспечивает разрешение имен, избыточность, согласованность и точность. В любой сети, содержащей более одного сегмента, существует некоторая форма разрешения имен. Если локальная сеть состоит только из одного сегмента без разрешения имен, то используются широковещательные сообщения. Широковещательные сообщения используются компьютерами в сети для поиска других компьютеров. К сожалению, исходный компьютер не знает местоположения целевого компьютера, поэтому исходный компьютер должен отправлять для его поиска широковещательное сообщение (это похоже на поиск приятеля в заполненном людьми помещении, когда нужно громко выкрикнуть его имя). Все люди в помещении услышат ваше сообщение; то же самое произойдет с компьютерами данного сегмента, но только целевой компьютер ответит на ваше широковещательное сообщение. После установления связи между исходным и целевым компьютерами последующий обмен информацией происходит посредством направленных дейтаграмм.
Компьютеры делают это также в небольших немаршрутизируемых локальных сетях. Но локальные сети разрастаются: широковещательные сообщения являются одной из причин, по которым они становятся маршрутизируемыми. Разрешение имен почти всегда предусматривает связь между IP-адресом и именем машины с намерением поиска и подсоединения к некоторой службе, которая предоставляется этой машиной. В среде TCP/IP соединение создается с машиной и, тем самым, с портом в стеке протоколов, которому направлено сообщение (например, с портом 80 для посещения веб-сайта). Все это позволяет вам иметь легко запоминаемое имя машины, например, www.skillet.com. Рассмотрим процесс разрешения пути к машине http://www.skillet.com.
Вам нужна новая сковородка (skillet). Вы подсоединены к сети, поэтому запускаете браузер и вводите имя www.skillet.com, которое передается клиентскому компоненту (resolver), задачей которого является поиск сервера Skillet. Resolver – это набор библиотек, которому передается имя http://www.skillet.com, после чего происходит обращение к серверу DNS. Resolver выполняет операции в определенном порядке. Он всегда начинает с локального поиска (то есть с поиска на вашем компьютере), и если у вас есть что-либо в файле HOSTS, он будет обработан (независимо от последствий).
Затем resolver анализирует вашу конфигурацию TCP/IP, определяет, какая машина является предпочтительным сервером DNS, и затем запрашивает этот сервер. Ваши клиенты более ранних версий Windows действуют иным образом; продукты на основе Windows 9x (DOS) сначала выполняют поиск среди имен NetBIOS. Они обращаются к DNS, если не удается поиск NetBIOS, но в некоторых случаях ожидание, пока не истечет период тайм-аута для NetBIOS, может вызывать ощутимую задержку. Причина очевидна: эти системы были созданы для работы в первую очередь с разрешением имен NetBIOS, которое происходило с помощью службы WINS. Со временем появилась DNS, и порядок поиска этих операционных систем теперь устарел, поскольку не отражает разрешение хост-имен сетью TCP/IP.
NT4 тоже выполняет разрешение имен таким способом, если имя NetBIOS не превышает 15 символов, и в нем нет точек. В противном случае NT4 обращается сначала к DNS. Но вернемся все же к Skillet.com.
Напомним, что resolver запрашивает у первичного (primary) сервера DNS, может ли он преобразовать данное имя в IP-адрес. Этот сервер DNS проверяет свою зону и кэш, не находит соответствия и, тем самым, не может выполнить разрешение имени. Затем этот сервер DNS ищет другой сервер DNS и обращается к нему. Сервер DNS обычно устанавливается на "границе" сети компании, и все, что он делает, это пересылка запросов какому-либо серверу DNS снаружи. Этот тип сервера DNS называется сервером перенаправления запросов (forwarder). Внутренний сервер DNS запрашивает сервер перенаправления запросов, который сначала проверяет, может ли он сам выполнить разрешение имени. Если нет, то он передает данный запрос другим серверам DNS в интернете, пока не будет найдено соответствие или не произойдет отказ запроса. Успешно разрешенное имя возвращается в кэш локального сервера DNS, поэтому при повторных попытках посещения вебсайта Skillet разрешение будет происходить быстрее.
Итак, нам удалось заказать сковородку (skillet); благодаря DNS мы нашли путь к Skillet.com, а также увидели за это время, как выполняется процесс разрешения имени. DNS – превосходная система, и она использует для поиска средства, которые называются запросами. Она использует следующие типы запросов.
Используя эти методы, сервер DNS последовательно ищет IP-адрес, начиная с URL (Uniform Resource Locator) вашего браузера, передаваемого в resolver. В результате вы получаете один из двух ответов: то, что вы ищете, или сообщение об ошибке.
Чтобы понять, как действует DNS, полезно ознакомиться с окружением, в котором
выполняет свою работу эта служба. Начнем с иерархии DNS. Корневой домен известен
просто как ".". Верхний домен находится на один уровень ниже, и на этом
уровне находится целый ряд доменов DNS. Вы знаете все эти суффиксы: .COM (коммерческие),
.GOV (правительственные), .EDU (образование), .INT (международные),
.ORG (организация), .NET (Net-провайдеры, ISP [Провайдеры услуг Интернет]
и т.д.) и .MIL (военные). Достаточно интересно, что
На следующем уровне обычно находится домен, поддерживаемый частной фирмой;
я буду использовать для своих примеров корпоративный домен .COM, но для
этого можно было бы использовать любой из только что перечисленных доменов.
Вы можете рассматривать домены DNS аналогично структуре папок на жестком
диске в смысле разбиения пространства имен DNS. Домен "." аналогичен корневой
папке; далее идет верхний уровень (.COM), и на следующем уровне находится "папка",
представляющая корпоративный объект некоторого рода (частный или общественный).
Имя верхнего уровня (.COM) и корпоративная "папка", например,
Microsoft, совместно образуют доменное имя. Пространство имен Microsoft может
разбиваться на меньшие домены ("подпапки") Active Directory/DNS, представляющие
в компании Microsoft различные подразделения или службы, например,
accounting.microsoft.com (бухгалтерский учет). Такой домен обычно недоступен из
Internet в отличие от microsoft.com; однако имеются исключения, например,
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto
представляет службы поддержки Microsoft. Здесь находится
Это обычное пространство DNS, известное как зона прямого поиска (forward
lookup zone). Существует также зона обратного поиска (
IP-адреса организованы таким образом, что их "старшинство" повышается слева
направо, а в доменных именах "старшинство" снижается слева направо. Но IP-адреса
в домене in-addr.
А теперь предположим, что нам известен хост внутри домена. Вернемся к примеру субдомена accounting в Microsoft. Домен внутри другого домена называется дочерним доменом, а microsoft.com в данном случае является родительским доменом. Если имя хоста – Syscrusher, то полностью это выглядит как syscrusher.accounting.microsoft.com. Любое хост-имя, выраженное таким способом, называется полностью уточненным доменным именем (FQDN – fully qualified domain name).
Теперь пришло время поговорить о зонах. Каждый домен является объектом со своей собственной политикой. Если посмотреть, как устроен один из серверов DNS внутри Microsoft, мы увидим в оснастке DNS определенные зоны. Зона может содержать домен, часть домена или ряд доменов; каждый из них может иметь сервер или серверы DNS, отвечающие за эти зоны. Должен существовать хотя бы один сервер DNS, поддерживающий каждую зону. Каждая зона имеет набор записей. Они называются ресурсными записями. Сервер DNS, который работает с определенной зоной, называют "руководящим" ("authority") для этой зоны. Он отвечает на любые запросы по этой зоне. Чтобы понять это, мы рассмотрим существующие виды зоны. Сюда относится их хранение, доступ и репликация, но не их содержимое (то есть записи – мы скоро увидим, как они устроены). Классические зоны DNS в Windows хранились и продолжают храниться в текстовых файлах с расширением .dns.
Первая зона называется первичной (primary) зоной. Эта зона создается на первичном (основном) сервере и является только доступным для записи экземпляром базы данных. Эта зона должна содержать хотя бы две записи – запись SOA (Start of Authority) и NS (name server). В классической DNS файл этой зоны должен был редактироваться вручную, но последующие версии DNS (в Windows 2000 и 2003) позволяют выполнять защищенное и незащищенное динамическое обновление. Большинство записей – это "A"-записи, представляющие хосты, добавленные вручную или зарегистрированные ими самостоятельно; но существует также много других типов записей. Вскоре мы рассмотрим наиболее употребительные типы записей. Классическая DNS в Windows Server 2003 позволяет выбрать один из двух вариантов: запрет динамических обновлений или разрешение защищенных и незащищенных обновлений.
Вторичная (secondary) зона извлекается из первичной и доступна только по чтению. Соответствующий сервер должен находиться в другой подсети и создается в небольших окружениях для избыточности; в более крупных окружениях это позволяет распространять вторичные серверы DNS в удаленные сайты для повышения производительности.
Эта версия зоны находится в Active Directory на каждом контроллере домена. Главная копия базы данных DNS реплицируется на каждый контроллер домена, и в нее может вносить изменения каждый контроллер домена (конечно, при соответствующих полномочиях). Нужно следить, сколько записей/зон используется в Active Directory (AD); слишком большое количество может вызывать снижение производительности.
Это новый тип зоны, появившийся в Windows 2003. Это копия дочерней зоны с записями, идентифицирующими дочерний сервер имен, который является "руководящим" для этой дочерней зоны. Она содержит SOA-запись, NS-запись и связывающую A-запись. Это известно как делегирование. Сервер родительской зоны может получать обновления от дочерней зоны, которые будут сохраняться в кэше сервера родительской зоны. Записи в такой зоне не изменяются. Ее назначение – это "склеивание" двух пространств имен, чтобы обеспечивать правильность ссылок из родительской зоны в дочернюю зону.
Конечно, делегирование не является чем-то новым. Stub-зоны позволяют исправить ситуацию, которая возникала в связи с делегированием, я объясню это сейчас. У нас имеется родительский домен – microsoft.com. У нас имеется также дочерний домен – accounting.microsoft.com. При первом делегировании этой дочерней зоны в зоне accounting был только один "руководящий" сервер DNS. Но поскольку со временем пространство имен accounting разрослось, администраторы решили установить два новых сервера для этого дочернего домена.
Однако сервер DNS, содержащий родительскую зону (microsoft.com), остается "в неведении" об их существовании и продолжает "упорно" обращаться к исходному (руководящему) серверу DNS по поводу accounting.microsoft.com. Чтобы справиться с этой ситуацией балансирования нагрузки, родительский сервер конфигурируется, чтобы хранить stub-зону для дочернего домена, и при обновлении этой зоны он обращается к руководящему серверу этой зоны, что позволяет ему узнать о двух новых серверах DNS и выполнять рекурсивный опрос всех этих серверов.
Продолжим наш пример. Родительская зона (microsoft.com) имеет дочернюю зону (accounting.microsoft.com), и управление этой дочерней зоной называют делегированием от родительской зоны. Делегирование, которое позволяет передавать управление в разделенном пространстве имен, можно осуществлять по целому ряду причин, например, необходимость для другого отдела управлять отдельной зоной или балансирование нагрузки и отказоустойчивость. Дочерняя будет руководящей для самой себя. Важно помнить, что можно создавать дочерние зоны без делегирования для них. В этом случае управление остается за родительской зоной.
В DNS имеется много типов записей, но из-за недостатка места, времени, а также ввиду несущественности в нашем случае некоторых записей мы рассмотрим только наиболее употребительные типы записей.
Myhost.mycompany.com IN A 192.168.0.1
IN AAAA 1234:1:2:3:4:567:89cd
Microsoft имеет несколько особых записей для собственных целей; эти записи используются для связи с различными окружениями WINS. Это следующие записи:
Серверы DNS реплицируют свои зоны. Они делают это по целому ряду причин в зависимости от структуры сети, но две наиболее важные причины – это отказоустойчивость и производительность. В начале использования DNS существовали первичный и вторичный серверы DNS. Оба содержали идентичные копии своих зон, и вторичный сервер обычно помещали в другую сеть, чтобы выход из строя первичной сети или отказ соответствующего сервера не приводили к потере функции разрешения имен. Они реплицировались по какому-либо событию, например, загрузка серверов или обновление зон первичного сервера, поэтому в случае появления "магического номера" в записи Start of Authority (SOA-записи) вторичный сервер обнаруживал это и извлекал базу данных, если были отличия.
"Магический номер" относится к терминологии BIND DNS. Это последовательный номер, который наращивается каждый раз, как вносятся изменения в какую-либо первичную зону. За этим номером следят вторичные серверы, и если он изменяется, то происходит запуск репликации зон. Это называется пересылкой зон.
Изменения могли вноситься только на первичном сервере; все вторичные системы были копиями первичной, что снижало риск повреждения базы данных. Это характерный тип конфигурации для среды UNIX, но ее можно создавать и с помощью Windows 2003. Как я уже говорил выше, предпочтительный метод – это использование лесов и доменов. Репликация происходит здесь в другом смысле; в домене, работа которого основывается на Active Directory (AD) и DNS, нет понятия первичных и вторичных серверов. В AD имеются только зоны AD.
В этой конфигурации, которая называется репликацией с несколькими основными
контроллерами ( multimaster-репликацией ), зоны DNS хранятся на контроллерах
доменов, и зоны реплицируются через Active Directory. Здесь действует определенный
"симбиоз": AD требуется служба DNS для
Раздел приложений (
Это дает вам селективную форму multimaster-репликации: все или некоторые
контроллеры домена содержат копии зоны и могут выполнять разрешение имен,
обеспечивая при этом безопасность зоны. Какой вид безопасности? Вы можете вносить
изменения в список контроля доступа (ACL) для защиты
Если вы добавляете к домену контроллер домена, то зона реплицируется в него без каких-либо дополнительных усилий. Вы можете также выбирать между репликацией всей зоны и части зоны, что не было доступно в прежних DNS!
DNS состоит из набора файлов. Ниже приводится список этих файлов и описывается их назначение.
Имеется также исполняемый файл DNS.EXE и клиентский компонент (resolver), который запускается на клиентской машине.
Теперь поговорим о новых возможностях. Имеется довольно много отличий, которые вы увидите в DNS 2003. Вот их список.
HKLM\System\CurrentControlSet\Services\DNS\Parameters\DoNotRoundRobinTypesREG_DWORDdnscmd Имя-вашего-сервера /CreateDirectoryPartition ваш-контроллер-домена.ваш-домен.com
Вы должны использовать здесь полностью уточненное доменное имя (
dnscmd Имя-вашего-сервера /EnlistDirectoryPartition ваш-контроллер-домена.ваш-домен.com
И, наконец, если вы решили использовать разделы AD, то все объекты DNS удаляются из Глобального каталога (Global Catalog). DNSCMD не устанавливается по умолчанию; это должны сделать вы:
В результате будут запрошены текущие серверы DNS, указанные в сетевых настройках, обновлены корневые подсказки, сконфигурированы серверы перенаправления запросов (forwarders) с помощью предпочтительных и альтернативных серверов DNS, заданы настройки DNS с адресом "обратной связи" 127.0.0.1 и затем сконфигурированы все предыдущие предпочтительные и альтернативные серверы DNS. Если все это проходит успешно, то в Event Viewer (Просмотр событий) записывается соответствующий журнал.
DoNotUseGroupPolicyForDisableDynamicUpdateHKLM\SYSTEM\CurrentControlSet\Services\Tcpip\ParametersREG_DWORD0x0 (использовать групповую политику) и 0x1 (использовать локальные настройки)0x0Ниже приводится более подробный список записей реестра клиентской стороны
Эта настройка политики определяет, включено ли динамическое обновление.
Компьютеры, сконфигурированные для динамического обновления, автоматически
регистрируют и обновляют свои
Имя: RegistrationEnabled
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: 0x0 (отключено) и 0x1 (включено)
Групповая политика для списка поиска суффиксов DNS важна для будущего перехода к свободной от NetBIOS среде. Если вы включаете эту настройку, то пользователь направляет запрос поиска имени с одной меткой (например, "widgets"), а клиент локальной DNS присоединяет суффикс (например, "microsoft.com"), что дает в результате запрос поиска "widgets.microsoft.com", прежде чем отправить этот запрос какому-либо серверу DNS.
Имя: SearchList
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_SZ
Допустимый диапазон: разделенные запятой строки суффиксов DNS
Эта настройка политики определяет, будет ли клиент DNS выполнять передачу первичного суффикса DNS в процессе разрешения имени. Если клиент направляет запрос имени с одной меткой (например, "mybox"), то локальный клиент DNS присоединяет суффикс (например, "skillet.com"), что дает в результате запрос "mybox.skillet.com", прежде чем отправить этот запрос серверу DNS.
Первичный суффикс DNS передается до тех пор, пока не будет разрешен запрос или суффикс DNS не будет иметь две метки (например, "skillet.com"). Первичный суффикс DNS не может быть передан менее чем двум меткам.
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: 0x0 (отключено) и 0x1 (включено)
Эта настройка политики разрешает или запрещает клиенту регистрировать PTR-записи. В состоянии по умолчанию клиенты DNS, сконфигурированные для выполнения динамической регистрации DNS, пытаются выполнить регистрацию ресурсной PTR-записи, только если они успешно зарегистрировали соответствующую ресурсную A-запись. Чтобы включить эту политику, выберите Enable (Включить) и выберите одно из следующих значений.
Имя: RegisterReverseLookup
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: 0x0 (отключено), 0x1 (включено)
Эта настройка политики определяет интервал обновления регистрации ресурсных A- и PTR-записей для компьютеров. Эту настройку можно применять только к компьютерам, которые используют динамическое обновление. Если ресурсные записи DNS регистрируются в зонах с включенной очисткой, то значение этой настройки должно быть не больше, чем Refresh Interval (Интервал обновления), заданный для этих зон. Задание величины Registration Refresh Interval, превышающей Refresh Interval этих зон DNS может вызывать преждевременное удаление ресурсных A- и PTR-записей, что может вызвать определенную проблему.
Имя: RegistrationRefreshInterval
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: больше или равно 1800 (секунд)
Эта настройка политики определяет, будет ли клиент DNS, который пытается зарегистрировать свою ресурсную A-запись, замещать существующие ресурсные A-записи, содержащие конфликтные IP-адреса. Во время динамического обновления зоны, которая не использует Secure Dynamic Update (Защищенное динамическое обновление), клиент может обнаружить, что существующая ресурсная A-запись связывает DNS-имя хоста данного клиента с IP-адресом другого компьютера. Согласно конфигурации по умолчанию этот клиент DNS попытается заместить эту существующую A-запись той A-записью, которая связывает DNS-имя с IP-адресом клиента.
Имя: RegistrationOverwritesInConflict
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: 0x0 (отключено) и 0x1 (включено)
Эта настройка политики определяет, может ли компьютер, выполняющий динамическую регистрацию, регистрировать свои ресурсные A- и PTR-записи путем конкатенации своего имени (Computer Name) и суффикса DNS для конкретного соединения (в дополнение к регистрации этих записей путем конкатенации своего имени и первичного (Primary) суффикса DNS.
Имя: RegisterAdapterName
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: 0x0 (отключено), 0x1 (включено)
Эта настройка политики указывает значение для поля TTL (time-to-live) ресурсных A- и PTR-записей, регистрируемых в компьютерах, к которым относится эта настройка.
Имя: RegistrationTTL
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: 0-4294967200 (секунд)
По умолчанию: 600
Эта политика указывает, какой вид обновлений для регистрации DNS-записей будут использовать компьютеры, к которым применяется эта настройка, – защищенные динамические обновления или стандартные динамические обновления. Чтобы включить эту настройку, выберите вариант Enable и выберите одно из следующих значений.
Имя: UpdateSecurityLevel
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: 0 (UnsecureFollowedBySecure), 16 (OnlyUnsecure), 256 (OnlySecure)
Эта настройка политики указывает, могут ли компьютеры, к которым применяется эта политика, отправлять динамические обновления зонам, имя которых содержит одну метку (т.е. зонам доменов верхнего уровня, например, "com").
По умолчанию клиент DNS, сконфигурированный для выполнения динамических
обновлений, будет отправлять динамические обновления зоне или зонам DNS,
которые является руководящими для его
Если включить эту политику, то компьютеры, к которым применяется эта политика, будут отправлять динамические обновления любой зоне, которая является руководящей для его ресурсных записей, за исключением корневой зоны.
Имя: UpdateTopLevelDomainZones
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Значения: 0x0 (отключено) и 0x1 (включено)
Важно отметить, что Windows Server 2003 не полностью поддерживает стандарт
Эта служба использует с помощью
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\
Parameters
Добавьте EnableDnsSec в поле DWORD.
Этому полю передается одно из трех значений в зависимости от того, что вы хотите сделать.
0x0. Исключение ресурсных записей (RR) 0x2. Включение ресурсных записей (RR) 0x1 (или пустое поле). Если вам нужно, чтобы записи Возможны случаи, когда у вас имеется сервер DNS с несколькими адаптерами
(
Исходная спецификация для DNS ограничивала размер пакета 512 октетами. EDNS0 (RFC 2671) позволяет передавать пакеты большего размера. Когда сервер DNS получает запрос (используется протокол UDP), он ищет ресурсную OPT-запись клиента и изменяет свой ответ, чтобы можно было передать столько ресурсных записей, сколько указано этим клиентом в OPT-записи (размер UDP указывается в OPT-записи).
Возможности ведения журналов DNS не изменились после Windows 2000, но работать
с ними стало удобнее за счет использования графического интерфейса (GUI),
который включен как часть оснастки Event Viewer. Вы можете задавать фильтрацию
по пользователям, по компьютерам, по идентификаторам событий, по категориям
или источникам событий от первого до последнего события и в соответствии с типами
событий (обычная информация, предупреждения или ошибки). Ведение журнала
DNS (DNS logging) представлено в оснастке DNS или в оснастке Event Viewer,
включенной в окно Administrative Tools (Администрирование). Для выбора опций
ведения журнала событий и отладки щелкните правой кнопкой на сервере в оснастке
DNS и выберите пункт Properties. Появятся вкладки журнала отладки (Debug
logging) и журнала событий (
Windows Server 2003 содержит много встроенных инструментальных средств, которые можно использовать для мониторинга, управления и устранения проблем DNS. Эти средства описываются в следующих разделах.
Эта утилита командной строки позволяет запрашивать пространство имен DNS и
позволяет вам устранять наиболее распространенные проблемы DNS. Она предусматривает
Nslookup -Команда хост-имя | -Сервер
Сервер – это указанный вами сервер, но по умолчанию используется сервер DNS, указанный на вашей странице свойств TCP/IP Properties.
Эту утилиту можно применять только при условии, что ваш компьютер использует
также DHCP. Она имеет три параметра, относящихся к DNS: /registerdns, /flushdns
и /displaydns.
Параметр /registerdns обновляет аренду DNS и вынуждает клиента выполнить
перерегистрацию с помощью сервера DNS. Параметр /flushdns выполняет очистку
кэша клиентского компонента (resolver), /displaydns показывает, что содержится в
кэше resolver.
Это утилита TCP/IP, и она должна использоваться в первую очередь, чтобы выяснить, действует ли соединение между клиентом и сервером. Если не действует, то нет смысла в устранении проблемы DNS, поскольку это проблема более низкого уровня. Кроме того, для быстрой проверки PTR-разрешения вы можете направить ping по IP-адресу, что позволит вам удостовериться в наличии соединения и хост-имени.
Эта утилита командной строки предоставляет много возможностей. Большинство вещей, которые вы можете делать с помощью оснастки DNS, можно делать и с помощью DNSCMD, включая скрипты, создание разделов Active Directory (AD), вывод списка этих разделов, создание и конфигурирование серверов DNS, а также управление. DNSCMD не устанавливается по умолчанию; это должны сделать вы:
Перейдите на свой дистрибутивный CD, войдите в папку support\tools и щелкните
на suptools.msi. Произойдет запуск программы установки, после чего будут установлены
средства поддержки (Support tools). Это очень мощное средство – ввод DNSCMD в командной строке даст вам представление об этом, но если говорить о
реальных возможностях, то почти все (а, может быть, и все) функции, которые вы
получаете с помощью GUI, доступны также с помощью DNSCMD.
Эта утилита применяется не только к DNS, поскольку она имеет много других сетевых
функций; однако она позволяет справиться с целым рядом "таинственных"
проблем и дает вам отчет о состоянии для записей DNS, которые обнаружила в регистрациях.
Чтобы увидеть, что сообщит NETDIAG по определенному вопросу,
перейдите в окно командной строки и вводите netdiag /fix для всех сетевых функций,
которые хотите проверить, или введите netdiag /DNS. Чтобы узнать, что может
делать эта утилита, перейдите в
Эта утилита позволяет переименовывать домены в Windows 2003. Она имеет также очень нужную "побочную" функцию, позволяя проверять целостность домена путем поиска необходимых записей-локаторов контроллеров домена (DC Locator Source) на руководящих серверах DNS. Это нужно, чтобы убедиться в том, что репликация и аутентификация будут происходить должным образом после переименования. Ее легко использовать для переименования записей-локаторов контроллеров домена на сервере DNS, который является руководящим для данной зоны, и последующей проверки целостности домена. Если определенная запись отсутствует, утилита может сообщить, какая это запись, что облегчает устранение проблем.
Это утилита командной строки, которая охватывает большинство задач диагностики
DNS. Ее можно использовать для диагностирования наиболее распространенных
проблем разрешения имен DNS. Она имеет три основные функции: dnslint /ql (проверка
определенных пользователем записей на сервере DNS), dnslint /ad (проверка
записей, относящихся к активному домену [dnslint /d (проверка
"неверного делегирования"). Вы можете загрузить это средство с веб-сайта Microsoft.
Установка DNS зависит от того, что вы планируете делать с пространством имен и Active Directory (AD). Предпочтительный метод – это их интеграция, которая требует установки AD и интегрированных с AD зон. Это существенно отличается от установки классической DNS на контроллере домена, работа которого основана на Active Directory. Вам нужно выполнить необходимые шаги во время установки или с помощью утилиты DCPROMO, вызванной из меню Start/Run (Пуск/Выполнить). Прежде чем сделать это, проследите, чтобы данный компьютер был сконфигурирован со статическим IP-адресом, иначе у вас не будет SRV-записей. Они создаются в вашей зоне AD, а остальные контроллеры домена ищут их во время присоединения к домену.
В Windows 2003 сначала появляется новое диалоговое окно, где говорится, что возможны проблемы операционной системы с этим контроллером домена, если у вас есть машины, работающие под управлением Windows 95 либо NT4 версии SP3 или более ранних версий. Причиной этого может быть подписание блоков SMB (Server Message Block – Блок серверных сообщений) и более защищенное соединение, относящееся к контроллеру домена и его клиентам. Блоки SMB обеспечивают разделяемое использование принтеров и файлов, администрирование и аутентификацию входа для операционных систем Windows. SMB изменился в Windows 2003. Он стал несовместим с более ранними формами протокола Session Message Block Protocol и не позволяет клиентам более ранних версий Windows аутентифицироваться для домена. Помните об этом предупреждении!
Было также изменено одно из диалоговых окон для DNS, встроенных в диалоговый процесс DCPROMO. Оно используется, чтобы сообщить, что не может быть установлен контакт с сервером DNS для этого домена. Мастер спросит, хотите ли вы установить и сконфигурировать DNS для этого сервера или сделаете это позже вручную. Теперь оно вызывается окном диагностики регистрации DNS. В нем описывается, какая запись не найдена (SRV), предлагаются действия для данной ситуации и предоставляются для выбора три следующих варианта:
DCPromo будет действовать как мастер, запрашивая у вас информацию, создавая для вас зоны DNS и выполняя конфигурирование некоторых настроек. Мастер получает от вас информацию, запускает процесс, и вскоре у вас появляется контроллер домена, работающий с AD DNS. Это позволяет осуществлять динамические обновления и дает вам также зоны прямого и обратного поиска.
Это несложный процесс. Вот как он выполняется.
Ниже описывается, как установить DNS с помощью мастера Manage Your Server Wizard (Управление вашим сервером).
Чтобы сконфигурировать зону прямого поиска, выполните следующие шаги.
После этого вы можете добавлять записи, но чтобы сделать это непосредственно, нужно сконфигурировать зону, чтобы она разрешала динамические обновления, и сконфигурировать клиентов, чтобы они могли регистрировать самих себя. Если вам нужно добавить запись вручную, щелкните правой кнопкой на только что созданной зоне, выберите пункт Add A Record (Добавить запись) и выполните прокрутку списка, пока не найдете нужную вам запись.
Чтобы проверить правильность конфигурации зоны прямого поиска, выполните следующие шаги.
DNS позволяет делегировать полномочия администрирования и управления пользователям и группам. Определите необходимые вам полномочия и выберите нужный вам уровень безопасности. Чтобы вызвать страницу Security (Безопасность), щелкните правой кнопкой на данном сервере DNS в оснастке DNS и выберите Security на странице свойств.
DNS и DHCP могут использоваться совместно. В этой конфигурации клиентам и серверам разрешается обновлять A-записи (записи хостов) и PTR-записи (записи обратного поиска). DHCP будет предоставлять вам аренду и обновлять соответствующим образом записи DNS.
Чтобы получить более подробную информацию по спецификациям, обратитесь к документам RFC (Request for Comment). Ниже приводятся все документы RFC для системы Windows Server 2003 и ее клиентов.
Следующие draft-документы интернет содержат спецификации, используемые для разработки и реализации сервера и клиентских служб DNS.
Следующие дополнительные спецификации используются для разработки и реализации служб сервера и клиента DNS.
WINS используется для имен NetBIOS таким же образом, как DNS для хост-имен; основное отличие заключается в структуре пространств имен. WINS – это распределенная база данных или может быть такой базой данных. WINS отображает IP-адреса на имена NetBIOS. WINS – это "плоское" пространство имен, в то время как DNS – это иерархическая структура; в WINS нет никакой явно или неявно выраженной иерархии. В то время как машина, находящаяся в accounting домена skillet.com будет представлена в DNS как myhost.skillet.com, ее доменное имя NetBIOS будет SKILLET.
WINS была предназначена для разрешения имен NetBIOS в немаршрутизируемой сети. Без WINS компьютеры просто отправляли бы широковещательные сообщения через сеть. Это создает проблему использования NetBIOS, поскольку широковещательные сообщения переполняют большую сеть и "съедают" значительную долю пропускной способности. NetBIOS нельзя маршрутизировать, и выполнение происходит поверх TCP/IP.
NetBIOS – это уровень представления (см. модель OSI) интерфейса прикладного
программирования (API), разработанный IBM в 1983 г. Он позволяет программам
задавать инструкции нижележащим сетевым протоколам; несмотря на его "возраст",
именно поэтому он все еще используется. Унаследованные приложения и
многочисленные средства сетевого администрирования все еще используют этот API
и не могут выполнять обмен информацией без разрешения имен NetBIOS. Напомним,
что в примере разрешения имен DNS мы ссылались на браузер, который передает
запрос имени клиентскому компоненту DNS (resolver) для разрешения имени.
NetBIOS работает почти так же: приложение, которому требуется найти службу,
работающую на другом компьютере (
Два непосредственных примера – это навигация, а также
Как вы можете предполагать, для этого плоского пространства имен требуется сервер WINS, который содержит соответствующие записи. Они существенно отличаются от записей DNS, в том числе форматом базы данных и методом хранения. В WINS нет никакого ASCII-файла. Это база данных Microsoft, известная под названием Jet, которая используется также в Access. Она плохо защищена от повреждений и чувствительна к большому числу факторов. По мере дальнейшего изложения мы увидим несколько параллелей с DNS.
Имена NetBIOS могут быть уникальными или являться частью группы. Это 16-байтовые адреса, и они имеют одну позицию, зарезервированную для типа службы, которую они представляют. Если имя короче 16 символов, то остальные байты заполняются до 16-го символа. Это важно знать, если вы редактируете файл LMHOSTS (см. ниже раздел "LMHOSTS"). Запись для службы рабочей станции (Workstation) может выглядеть следующим образом:
Machinename <00> UNIQUE
Это представление записи компьютера в WINS для службы Workstation. Вы передаете информацию с помощью суффикса (<##>), содержащего алфавитно-цифровые символы. Вы можете также встретить запись Machinename <00> GROUP, и это также допустимо. Уникальные имена (UNIQUE) используются для доступа к службам на отдельных компьютерах; группы (GROUP) используются для групп компьютеров. Существуют типы записей (их очень много), и этот список не является полным. И нет способа его упорядочить, поскольку поставщики сторонних фирм имеют свои собственные суффиксы, которые регистрируются их собственными приложениями. Чтобы увидеть их, посмотрите две самые последние записи для Irmalan и Lotus Notes.
<computername> 00 U Workstation Service <computername> 01 U Messenger Service <\\—__MSBROWSE__> 01 G Master Browser <computername> 03 U Messenger Service <computername> 06 U RAS Server Service <computername> 1F U NetDDE Service <computername> 20 U File Server Service <computername> 21 U RAS Client Service <computername> 22 U Microsoft Exchange Interchange (MSMail Connector) <computername> 23 U Microsoft Exchange Store <computername> 24 U Microsoft Exchange Directory <computername> 30 U Modem Sharing Server Service <computername> 31 U Modem Sharing Client Service <computername> 43 U SMS Clients Remote Control <computername> 44 U SMS Administrators Remote Control Tool <computername> 45 U SMS Clients Remote Chat <computername> 46 U SMS Clients Remote Transfer <computername> 4C U DEC Pathworks TCPIP service on Windows NT <computername> 42 U mccaffee anti-virus <computername> 52 U DEC Pathworks TCPIP service on Windows NT <computername> 87 U Microsoft Exchange MTA <computername> 6A U Microsoft Exchange IMC <computername> BE U Network Monitor Agent <computername> BF U Network Monitor Application <username> 03 U Messenger Service <domain> 00 G Domain Name <domain> 1B U Domain Master Browser <domain> 1C G Domain Controllers <domain> 1D U Master Browser <domain> 1E G Browser Service Elections <INet~Services> 1C G IIS <IS~computer name> 00 U IIS <computername> [2B] U Lotus Notes Server Service IRISMULTICAST [2F] G Lotus Notes IRISNAMESERVER [33] G Lotus Notes Forte_$ND800ZA [20 U DCA IrmaLan Gateway Server Service
Именно эти виды записей вы можете встретить в базе данных WINS. (Другие
называются "статическими записями".) Большинство регистраций WINS являются
динамическими и ведут себя аналогично аренде DHCP. Статическая запись используется
для таких систем, как UNIX (которые не поддерживают NetBIOS). Кроме
случаев поиска источника проблем никогда не используйте их для поддерживающих
NetBIOS клиентов, поскольку они будут пытаться регистрировать себя и будут
отклонены. Это обычно означает, что клиент не получит регистрации, а вы получите
сообщение: Duplicate name on network! (Дублированное имя в сети). Статические
записи можно использовать для систем, которые не могут регистрировать имя
NetBIOS, а записи, которые можно добавлять вручную, имеют такие же типы, как и
те, что обычно вводятся динамически поддерживающим NetBIOS клиентом: Unique,
Group, Domain Name, Internet Group и
Если широковещательное сообщение NetBIOS не дает результата, то следующая альтернатива – это обращение к файлу LMHOSTS на локальном компьютере. Пример этого файла можно увидеть в папке %systemroot%\system32\drivers\... В отличие от файлов HOSTS файлы LMHOSTS имеют дополнительные опции для разрешения имен, включая, в частности, следующие средства.
Настройка клиента в разрешении имен WINS/NetBIOS будет определять его поведение. Имеются четыре метода разрешения, которые называются типами узлов. Они действуют следующим образом.
При своем запуске клиенты WINS обращаются к серверу WINS и регистрируют свои имена и IP-адреса. Если соответствующее имя не используется (WINS не "заботится" об IP-адресах; вы можете дублировать их сколько угодно), то сервер разрешает клиенту регистрировать его службы на сервере WINS. Клиент получит сообщение POSITIVE NAME REGISTRATION RESPONSE (положительный ответ на запрос регистрации имени). Минимально компьютер, который подключился, не имея ничего, кроме операционной системы, обычно регистрирует записи <00> (служба Workstation), <20> (служба Server) и <03> (служба Messenger). Если соответствующее имя уже используется, то сервер отправляет "вызов" последнему компьютеру, который зарегистрировал это имя (чтобы он "защитил" свое имя). Сервер делает это три раза через заранее определенные интервалы времени, и если получен ответ на вызов, то клиенту отправляется сообщение NEGATIVE NAME REGISTRATION RESPONSE (отрицательный ответ на запрос имени).
Пользователь увидит всплывающее окно с текстом "Duplicate name on network" (Дублированное имя в сети). Но если ответ на вызов не получен, то клиенту разрешается регистрация. Эти регистрации ограничены по времени, то есть им присваивается значение TTL (срок действия). Клиенты должны обновлять регистрацию имени. При обновлении имени, когда клиенту отправлен "вызов" (как только что было описано) и он не ответил на этот вызов, считается, что этот клиент отказался от своего имени, передав его для использования другому компьютеру. По истечении 50% времени его аренды, клиент отправляет запрос подтверждения имени (обновления аренды). Этот запрос содержит IP-адрес и имя NetBIOS компьютера, которому требуется подтверждение, и сервер WINS отправляет ему сообщение с новой арендой времени. Это происходит в нормальной ситуации.
Но если клиент не может обнаружить сервер, то сервер пытается подтвердить имя каждые 10 минут в течение часа на первичном сервере WINS. Затем он пытается перейти на вторичный сервер WINS и снова пытается получить подтверждение с 10-минутными интервалами. Если обновление по-прежнему не получено, он возвращается на первый сервер и повторяет свои попытки. Все это продолжается, пока не закончится срок аренды; если за это время не было попыток обновления имени (другим клиентом), то имя освобождается. Еще один способ освобождения имени – это отключение компьютера; нельзя просто выключить компьютер, а должен быть отправлен соответствующий запрос на сервер WINS. Сервер WINS просмотрит базу данных, и если обнаружена соответствующая запись, то сервер возвратит положительный ответ об освобождении имени со значением TTL, равным нулю. Если не найдено соответствия для IP-адреса/имени, то отправляется отрицательный ответ.
Когда клиенту требуется разрешение имени NetBIOS, он ищет его сначала локально. Он просматривает свой кэш в поисках соответствующего имени/адреса. Если имя не разрешено, то клиент запрашивает непосредственно сервер WINS. Он ищет этот сервер, повторяя попытки три раза, и если не получает ответа, то обращается к вторичному серверу и повторяет этот процесс. Если один из этих серверов разрешает запрос, то клиент получает сообщение об успешном результате и ему передается IP-адрес для запрошенного имени NetBIOS. Если ни один из серверов не может разрешить данное имя, то клиенту отправляется сообщение "requested name does not exist" (запрошенное имя не существует). После это клиент начинает применять широковещательные сообщения.
Серверы WINS реплицируют свои базы данных, и, как и в случае DNS, это определяется вашими опциями конфигурации. Напомним, что WINS – это "плоское" пространство имен, поэтому топология его репликации выглядит очень просто. Я встречался со многими пользователями, которые пытались использовать иерархию в пространстве имен WINS. Для репликации базы данных обычно имеется одна схема, которая хорошо работает и требует небольших расходов на обслуживание. Реальная схема репликации называется push/pull ("выталкивание/извлечение"), и мы ознакомимся с ней чуть ниже. На рис 3.1 показана рекомендуемая топология сети, в которой происходит репликация серверов WINS.
(рис 3.1) Репликация типа "hub and spoke"Ее называют звездообразной схемой репликации ( hub and spoke ). Группа серверов WINS выполняет репликацию с центральным первичным сервером; та же схема используется со вторичным сервером, а первичный и вторичный реплицируются друг с другом. Они делают это с помощью метода push/pull. Рассмотрим этот процесс подробнее.
Pull-партнер – это сервер WINS, который запрашивает реплики от своих push-партнеров. Push-партнеры знают, что реплицировать, поскольку номер версии должен быть больше того, что получил pull-партнер в предыдущем сеансе репликации. Push-партнер – это сервер WINS, который отправляет запрос репликации своим pull-партнерам, сообщая им, что его база данных была обновлена. После этого они извлекают реплики. При репликации типа push/pull вам следует учитывать два основных фактора: скорость вашего канала глобальной сети (WAN) и какие компьютеры должны соединяться с какими сайтами.
Предположим, что ваш компьютер – это Remote Site 1 (Удаленный сайт 1, см. рис 3.1), осуществляющий репликацию методом push/pull с сервером Home Office. При необходимости обмена данными с компьютером Remote Site 2, осуществляющим репликацию с сервером Corporate Office, ваш компьютер никогда не получит необходимые для этого записи, если эти записи не являются частью реплики, которая извлекается из Remote Site 1 на сервер Corporate Office и затем реплицируется на сервер Home Office. Реплика – это копия записей WINS, которые реплицированы от партнера push/pull. Поскольку сервер Home Office реплицируется на свой Remote Site 1, эти записи являются частью сервера WINS в службах Remote Site 1.
WINS не является сложной технологией (хотя она плохо масштабируется), и если использовать здравый подход, то обычно WINS действует достаточно хорошо. Большинство проблем возникает в тех случаях, когда разработчики пытаются делать сложные вещи с тем, что не представляет особых сложностей. При хорошей пропускной способности предпочтительно использовать между всеми серверами репликацию типа push/pull, поскольку все записи будут реплицироваться во все точки. Всегда конфигурируйте сервер WINS, чтобы он указывал для разрешения на самого себя.
WINS может обнаруживать и настраивать своих партнеров репликации автоматически, если ваша сеть поддерживает групповые сообщения (multicast). WINS рассылает групповые сообщения приблизительно каждые полчаса по IP-адресу 224.0.1.24. Любой найденный сервер WINS конфигурирует сам себя как партнера push/pull.
Мощность WINS планируется из расчета один сервер на 10000 клиентов. Это вполне достижимая цифра, но в большинстве случаев не учитываются определенные факторы, например, WINS помещают на компьютер, который одновременно является контроллером домена, сервером печати и сервером приложений. Это снижает производительность, а если WINS работает недостаточно хорошо, то возникают проблемы соединений. Если вы планируете использовать WINS в конфигурации от 1 до 10000, не нагружайте данный компьютер другими процессами, убедитесь, что он имеет каналы с достаточной пропускной способностью, используйте высокоскоростные соединения локальной сети (избегайте узких мест), не устанавливайте несколько адаптеров на этот сервер и убедитесь, что этот сервер имеет высокопроизводительную дисковую подсистему. Это кажется странным, но самые сложные проблемы в этих конфигурациях возникали из-за переполнения дисковой подсистемы запросами записи. В этих случаях Performance Monitor (Монитор производительности, см. лекцию 16) показывал проблемы операций записи, а после замены дисковой подсистемы на SCSI RAID 0 производительность резко повышалась.
Проблемы производительности возникают также в тех случаях, когда сервер WINS перегружен за счет того, что он размещен на компьютере, выполняющем много других функций. Один из характерных случаев, с которыми я сталкивался, это программа сканирования вирусов от сторонней компании в большой корпоративной сети, которая очень часто опрашивает клиентов WINS, чтобы проверить, требуются ли обновления. Такие программы обычно имеют консоль конфигурирования, и пользователь сконфигурировал ее для проверки клиентов каждые 20 минут. Причиной проблемы было то, что этот сервер имел 5000 клиентов, поэтому программа сканирования вирусов фактически связывала циклы разрешения имен WINS, то есть опрашивала всех клиентов! Это настолько перегружало сервер, что нормальное разрешение имен становилось невозможным и функционирование сети фактически прекращалось. Здесь возникал эффект, эквивалентный атаке на отказ обслуживания.
WINS можно сконфигурировать для резервного копирования ее базы данных в выбранном вами месте. Выбор соответствующего каталога (Directory) происходит в оснастке WINS, и после этого WINS выполняет резервное копирование баз данных каждые три часа. Это звучит убедительно, но на практике эксплуатируемая база данных может быть повреждена по какой-либо причине и проблема, возможно, не будет разрешена за три часа (до следующего цикла резервного копирования), то есть резервная копия тоже будет поврежденной.
Более подходящим, хотя и более трудным методом, может стать использование утилиты Jetpack, которая проверяет целостность базы данных, прежде чем выполнять ее копирование. Jetpack обладает возможностью придавать целостность базе данных или восстанавливать целостность, если файл базы данных не слишком поврежден. После этого выполните резервное копирование вручную. Вы можете задаться вопросом, зачем нужно резервное копирование. В основном это нужно для быстрого восстановления в случае ... повреждения базы данных! В случае повреждения WINS остается две возможности, если Jetpack не может восстановить файл.
Основные утилиты для поиска и устранения проблем – это NBTSTAT и JETPACK.
Систему доменных имен DNS (Domain Name System) разработал Пол Мокапетрис (Paul Mokapetris), который на заре интернета (в начале 1980-х) задался вопросом, как работать в системе (она стала со временем называться DNS), которая преобразует Web-адрес в состоящий из четырех октетов IP-адрес, который используется сетевыми машинами для связи через TCP/IP (см. лекцию 1). Мокапетрис разработал иерархическое пространство имен, которое позволяло присваивать машинам понятные (дружественные) пользователям имена и связывать эти имена с IP-адресами. Эти группы машин разбивались на домены, и в каждом домене предусматривалось свое собственное управление
DNS можно также использовать для поиска элементов, хранящихся в базе данных
LDAP. DNS – это клиент/
Создается впечатление, что эта интеграция с AD является обязательной, но это не так, если вы не планируете создавать домены и леса (более подробно об этом см. в лекции 10). И даже в этом случае она не является обязательной, но вам следует объединить эти два компонента, если вы хотите свести к минимуму администрирование. Возможно, у вас есть UNIX-станции; можно использовать DNS на Microsoft-станциях в стандартной (классической) конфигурации с первичным (primary) и вторичным (secondary) серверами DNS, если вам не нужен или вы не хотите использовать домен в своем окружении. Однако предпочтительно использовать конструкции леса/домены с контроллерами доменов через Active Directory.
Цель этой лекции – способствовать пониманию разрешения имен в целом, и, в частности, DNS, с выделением отличий между Windows 2000 и 2003. Вы также узнаете о прежней форме разрешения имен, которая применялась фирмой Microsoft: разрешение имен NetBIOS, которое происходило с помощью службы WINS (Windows Internet Naming Service).
Все началось с файлов HOSTS. Это "плоские" текстовые файлы ASCII, содержащие построчный набор записей. Эти записи только представляли связь IP-адреса с именем машины, например, 192.168.1.1 Trucker.Truckstp.com. Идея состояла в том, что Trucker – это легко запоминаемое имя машины, а resolver (клиентский компонент, состоящий из программной части и библиотек на клиентском компьютере) читает этот файл, находит имя машины, извлекает ее IP-адрес и выполняет поиск по этому адресу.
Вы можете все еще использовать файлы HOSTS; обычно они находятся в подпапке %SYSTEMROOT\system32\drivers\... Вы можете редактировать такой файл с
помощью Блокнота (Notepad) и добавлять в него любую машину, если у вас есть
имя и IP-адрес этой машины, и вы знаете об изменениях в сети, которые могут повлиять
на эти записи. Использование файла HOSTS сопряжено с ошибками, например,
возможно дублирование имен или адресов. Этот подход не позволяет поддерживать
масштабирование; достаточно представить себе, сколько затруднений
может вызвать поддержка этих файлов для крупного предприятия. На каждой машине!
Без каких-либо средств безопасности!
Файлы HOSTS – это опасное средство, а разрешение имен должно реализоваться надежным образом. Ответом на эту задачу стала DNS. Вместе со своей базой данных и инструментами, а также благодаря своей распределенной природе подходящая структура DNS обеспечивает разрешение имен, избыточность, согласованность и точность. В любой сети, содержащей более одного сегмента, существует некоторая форма разрешения имен. Если локальная сеть состоит только из одного сегмента без разрешения имен, то используются широковещательные сообщения. Широковещательные сообщения используются компьютерами в сети для поиска других компьютеров. К сожалению, исходный компьютер не знает местоположения целевого компьютера, поэтому исходный компьютер должен отправлять для его поиска широковещательное сообщение (это похоже на поиск приятеля в заполненном людьми помещении, когда нужно громко выкрикнуть его имя). Все люди в помещении услышат ваше сообщение; то же самое произойдет с компьютерами данного сегмента, но только целевой компьютер ответит на ваше широковещательное сообщение. После установления связи между исходным и целевым компьютерами последующий обмен информацией происходит посредством направленных дейтаграмм.
Компьютеры делают это также в небольших немаршрутизируемых локальных сетях. Но локальные сети разрастаются: широковещательные сообщения являются одной из причин, по которым они становятся маршрутизируемыми. Разрешение имен почти всегда предусматривает связь между IP-адресом и именем машины с намерением поиска и подсоединения к некоторой службе, которая предоставляется этой машиной. В среде TCP/IP соединение создается с машиной и, тем самым, с портом в стеке протоколов, которому направлено сообщение (например, с портом 80 для посещения веб-сайта). Все это позволяет вам иметь легко запоминаемое имя машины, например, www.skillet.com. Рассмотрим процесс разрешения пути к машине http://www.skillet.com.
Вам нужна новая сковородка (skillet). Вы подсоединены к сети, поэтому запускаете браузер и вводите имя www.skillet.com, которое передается клиентскому компоненту (resolver), задачей которого является поиск сервера Skillet. Resolver – это набор библиотек, которому передается имя http://www.skillet.com, после чего происходит обращение к серверу DNS. Resolver выполняет операции в определенном порядке. Он всегда начинает с локального поиска (то есть с поиска на вашем компьютере), и если у вас есть что-либо в файле HOSTS, он будет обработан (независимо от последствий).
Затем resolver анализирует вашу конфигурацию TCP/IP, определяет, какая машина является предпочтительным сервером DNS, и затем запрашивает этот сервер. Ваши клиенты более ранних версий Windows действуют иным образом; продукты на основе Windows 9x (DOS) сначала выполняют поиск среди имен NetBIOS. Они обращаются к DNS, если не удается поиск NetBIOS, но в некоторых случаях ожидание, пока не истечет период тайм-аута для NetBIOS, может вызывать ощутимую задержку. Причина очевидна: эти системы были созданы для работы в первую очередь с разрешением имен NetBIOS, которое происходило с помощью службы WINS. Со временем появилась DNS, и порядок поиска этих операционных систем теперь устарел, поскольку не отражает разрешение хост-имен сетью TCP/IP.
NT4 тоже выполняет разрешение имен таким способом, если имя NetBIOS не превышает 15 символов, и в нем нет точек. В противном случае NT4 обращается сначала к DNS. Но вернемся все же к Skillet.com.
Напомним, что resolver запрашивает у первичного (primary) сервера DNS, может ли он преобразовать данное имя в IP-адрес. Этот сервер DNS проверяет свою зону и кэш, не находит соответствия и, тем самым, не может выполнить разрешение имени. Затем этот сервер DNS ищет другой сервер DNS и обращается к нему. Сервер DNS обычно устанавливается на "границе" сети компании, и все, что он делает, это пересылка запросов какому-либо серверу DNS снаружи. Этот тип сервера DNS называется сервером перенаправления запросов (forwarder). Внутренний сервер DNS запрашивает сервер перенаправления запросов, который сначала проверяет, может ли он сам выполнить разрешение имени. Если нет, то он передает данный запрос другим серверам DNS в интернете, пока не будет найдено соответствие или не произойдет отказ запроса. Успешно разрешенное имя возвращается в кэш локального сервера DNS, поэтому при повторных попытках посещения вебсайта Skillet разрешение будет происходить быстрее.
Итак, нам удалось заказать сковородку (skillet); благодаря DNS мы нашли путь к Skillet.com, а также увидели за это время, как выполняется процесс разрешения имени. DNS – превосходная система, и она использует для поиска средства, которые называются запросами. Она использует следующие типы запросов.
Используя эти методы, сервер DNS последовательно ищет IP-адрес, начиная с URL (Uniform Resource Locator) вашего браузера, передаваемого в resolver. В результате вы получаете один из двух ответов: то, что вы ищете, или сообщение об ошибке.
Чтобы понять, как действует DNS, полезно ознакомиться с окружением, в котором
выполняет свою работу эта служба. Начнем с иерархии DNS. Корневой домен известен
просто как ".". Верхний домен находится на один уровень ниже, и на этом
уровне находится целый ряд доменов DNS. Вы знаете все эти суффиксы: .COM (коммерческие),
.GOV (правительственные), .EDU (образование), .INT (международные),
.ORG (организация), .NET (Net-провайдеры, ISP [Провайдеры услуг Интернет]
и т.д.) и .MIL (военные). Достаточно интересно, что
На следующем уровне обычно находится домен, поддерживаемый частной фирмой;
я буду использовать для своих примеров корпоративный домен .COM, но для
этого можно было бы использовать любой из только что перечисленных доменов.
Вы можете рассматривать домены DNS аналогично структуре папок на жестком
диске в смысле разбиения пространства имен DNS. Домен "." аналогичен корневой
папке; далее идет верхний уровень (.COM), и на следующем уровне находится "папка",
представляющая корпоративный объект некоторого рода (частный или общественный).
Имя верхнего уровня (.COM) и корпоративная "папка", например,
Microsoft, совместно образуют доменное имя. Пространство имен Microsoft может
разбиваться на меньшие домены ("подпапки") Active Directory/DNS, представляющие
в компании Microsoft различные подразделения или службы, например,
accounting.microsoft.com (бухгалтерский учет). Такой домен обычно недоступен из
Internet в отличие от microsoft.com; однако имеются исключения, например,
http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto
представляет службы поддержки Microsoft. Здесь находится
Это обычное пространство DNS, известное как зона прямого поиска (forward
lookup zone). Существует также зона обратного поиска (
IP-адреса организованы таким образом, что их "старшинство" повышается слева
направо, а в доменных именах "старшинство" снижается слева направо. Но IP-адреса
в домене in-addr.
А теперь предположим, что нам известен хост внутри домена. Вернемся к примеру субдомена accounting в Microsoft. Домен внутри другого домена называется дочерним доменом, а microsoft.com в данном случае является родительским доменом. Если имя хоста – Syscrusher, то полностью это выглядит как syscrusher.accounting.microsoft.com. Любое хост-имя, выраженное таким способом, называется полностью уточненным доменным именем (FQDN – fully qualified domain name).
Теперь пришло время поговорить о зонах. Каждый домен является объектом со своей собственной политикой. Если посмотреть, как устроен один из серверов DNS внутри Microsoft, мы увидим в оснастке DNS определенные зоны. Зона может содержать домен, часть домена или ряд доменов; каждый из них может иметь сервер или серверы DNS, отвечающие за эти зоны. Должен существовать хотя бы один сервер DNS, поддерживающий каждую зону. Каждая зона имеет набор записей. Они называются ресурсными записями. Сервер DNS, который работает с определенной зоной, называют "руководящим" ("authority") для этой зоны. Он отвечает на любые запросы по этой зоне. Чтобы понять это, мы рассмотрим существующие виды зоны. Сюда относится их хранение, доступ и репликация, но не их содержимое (то есть записи – мы скоро увидим, как они устроены). Классические зоны DNS в Windows хранились и продолжают храниться в текстовых файлах с расширением .dns.
Первая зона называется первичной (primary) зоной. Эта зона создается на первичном (основном) сервере и является только доступным для записи экземпляром базы данных. Эта зона должна содержать хотя бы две записи – запись SOA (Start of Authority) и NS (name server). В классической DNS файл этой зоны должен был редактироваться вручную, но последующие версии DNS (в Windows 2000 и 2003) позволяют выполнять защищенное и незащищенное динамическое обновление. Большинство записей – это "A"-записи, представляющие хосты, добавленные вручную или зарегистрированные ими самостоятельно; но существует также много других типов записей. Вскоре мы рассмотрим наиболее употребительные типы записей. Классическая DNS в Windows Server 2003 позволяет выбрать один из двух вариантов: запрет динамических обновлений или разрешение защищенных и незащищенных обновлений.
Вторичная (secondary) зона извлекается из первичной и доступна только по чтению. Соответствующий сервер должен находиться в другой подсети и создается в небольших окружениях для избыточности; в более крупных окружениях это позволяет распространять вторичные серверы DNS в удаленные сайты для повышения производительности.
Эта версия зоны находится в Active Directory на каждом контроллере домена. Главная копия базы данных DNS реплицируется на каждый контроллер домена, и в нее может вносить изменения каждый контроллер домена (конечно, при соответствующих полномочиях). Нужно следить, сколько записей/зон используется в Active Directory (AD); слишком большое количество может вызывать снижение производительности.
Это новый тип зоны, появившийся в Windows 2003. Это копия дочерней зоны с записями, идентифицирующими дочерний сервер имен, который является "руководящим" для этой дочерней зоны. Она содержит SOA-запись, NS-запись и связывающую A-запись. Это известно как делегирование. Сервер родительской зоны может получать обновления от дочерней зоны, которые будут сохраняться в кэше сервера родительской зоны. Записи в такой зоне не изменяются. Ее назначение – это "склеивание" двух пространств имен, чтобы обеспечивать правильность ссылок из родительской зоны в дочернюю зону.
Конечно, делегирование не является чем-то новым. Stub-зоны позволяют исправить ситуацию, которая возникала в связи с делегированием, я объясню это сейчас. У нас имеется родительский домен – microsoft.com. У нас имеется также дочерний домен – accounting.microsoft.com. При первом делегировании этой дочерней зоны в зоне accounting был только один "руководящий" сервер DNS. Но поскольку со временем пространство имен accounting разрослось, администраторы решили установить два новых сервера для этого дочернего домена.
Однако сервер DNS, содержащий родительскую зону (microsoft.com), остается "в неведении" об их существовании и продолжает "упорно" обращаться к исходному (руководящему) серверу DNS по поводу accounting.microsoft.com. Чтобы справиться с этой ситуацией балансирования нагрузки, родительский сервер конфигурируется, чтобы хранить stub-зону для дочернего домена, и при обновлении этой зоны он обращается к руководящему серверу этой зоны, что позволяет ему узнать о двух новых серверах DNS и выполнять рекурсивный опрос всех этих серверов.
Продолжим наш пример. Родительская зона (microsoft.com) имеет дочернюю зону (accounting.microsoft.com), и управление этой дочерней зоной называют делегированием от родительской зоны. Делегирование, которое позволяет передавать управление в разделенном пространстве имен, можно осуществлять по целому ряду причин, например, необходимость для другого отдела управлять отдельной зоной или балансирование нагрузки и отказоустойчивость. Дочерняя будет руководящей для самой себя. Важно помнить, что можно создавать дочерние зоны без делегирования для них. В этом случае управление остается за родительской зоной.
В DNS имеется много типов записей, но из-за недостатка места, времени, а также ввиду несущественности в нашем случае некоторых записей мы рассмотрим только наиболее употребительные типы записей.
Myhost.mycompany.com IN A 192.168.0.1
IN AAAA 1234:1:2:3:4:567:89cd
Microsoft имеет несколько особых записей для собственных целей; эти записи используются для связи с различными окружениями WINS. Это следующие записи:
Серверы DNS реплицируют свои зоны. Они делают это по целому ряду причин в зависимости от структуры сети, но две наиболее важные причины – это отказоустойчивость и производительность. В начале использования DNS существовали первичный и вторичный серверы DNS. Оба содержали идентичные копии своих зон, и вторичный сервер обычно помещали в другую сеть, чтобы выход из строя первичной сети или отказ соответствующего сервера не приводили к потере функции разрешения имен. Они реплицировались по какому-либо событию, например, загрузка серверов или обновление зон первичного сервера, поэтому в случае появления "магического номера" в записи Start of Authority (SOA-записи) вторичный сервер обнаруживал это и извлекал базу данных, если были отличия.
"Магический номер" относится к терминологии BIND DNS. Это последовательный номер, который наращивается каждый раз, как вносятся изменения в какую-либо первичную зону. За этим номером следят вторичные серверы, и если он изменяется, то происходит запуск репликации зон. Это называется пересылкой зон.
Изменения могли вноситься только на первичном сервере; все вторичные системы были копиями первичной, что снижало риск повреждения базы данных. Это характерный тип конфигурации для среды UNIX, но ее можно создавать и с помощью Windows 2003. Как я уже говорил выше, предпочтительный метод – это использование лесов и доменов. Репликация происходит здесь в другом смысле; в домене, работа которого основывается на Active Directory (AD) и DNS, нет понятия первичных и вторичных серверов. В AD имеются только зоны AD.
В этой конфигурации, которая называется репликацией с несколькими основными
контроллерами ( multimaster-репликацией ), зоны DNS хранятся на контроллерах
доменов, и зоны реплицируются через Active Directory. Здесь действует определенный
"симбиоз": AD требуется служба DNS для
Раздел приложений (
Это дает вам селективную форму multimaster-репликации: все или некоторые
контроллеры домена содержат копии зоны и могут выполнять разрешение имен,
обеспечивая при этом безопасность зоны. Какой вид безопасности? Вы можете вносить
изменения в список контроля доступа (ACL) для защиты
Если вы добавляете к домену контроллер домена, то зона реплицируется в него без каких-либо дополнительных усилий. Вы можете также выбирать между репликацией всей зоны и части зоны, что не было доступно в прежних DNS!
DNS состоит из набора файлов. Ниже приводится список этих файлов и описывается их назначение.
Имеется также исполняемый файл DNS.EXE и клиентский компонент (resolver), который запускается на клиентской машине.
Теперь поговорим о новых возможностях. Имеется довольно много отличий, которые вы увидите в DNS 2003. Вот их список.
HKLM\System\CurrentControlSet\Services\DNS\Parameters\DoNotRoundRobinTypesREG_DWORDdnscmd Имя-вашего-сервера /CreateDirectoryPartition ваш-контроллер-домена.ваш-домен.com
Вы должны использовать здесь полностью уточненное доменное имя (
dnscmd Имя-вашего-сервера /EnlistDirectoryPartition ваш-контроллер-домена.ваш-домен.com
И, наконец, если вы решили использовать разделы AD, то все объекты DNS удаляются из Глобального каталога (Global Catalog). DNSCMD не устанавливается по умолчанию; это должны сделать вы:
В результате будут запрошены текущие серверы DNS, указанные в сетевых настройках, обновлены корневые подсказки, сконфигурированы серверы перенаправления запросов (forwarders) с помощью предпочтительных и альтернативных серверов DNS, заданы настройки DNS с адресом "обратной связи" 127.0.0.1 и затем сконфигурированы все предыдущие предпочтительные и альтернативные серверы DNS. Если все это проходит успешно, то в Event Viewer (Просмотр событий) записывается соответствующий журнал.
DoNotUseGroupPolicyForDisableDynamicUpdateHKLM\SYSTEM\CurrentControlSet\Services\Tcpip\ParametersREG_DWORD0x0 (использовать групповую политику) и 0x1 (использовать локальные настройки)0x0Ниже приводится более подробный список записей реестра клиентской стороны
Эта настройка политики определяет, включено ли динамическое обновление.
Компьютеры, сконфигурированные для динамического обновления, автоматически
регистрируют и обновляют свои
Имя: RegistrationEnabled
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: 0x0 (отключено) и 0x1 (включено)
Групповая политика для списка поиска суффиксов DNS важна для будущего перехода к свободной от NetBIOS среде. Если вы включаете эту настройку, то пользователь направляет запрос поиска имени с одной меткой (например, "widgets"), а клиент локальной DNS присоединяет суффикс (например, "microsoft.com"), что дает в результате запрос поиска "widgets.microsoft.com", прежде чем отправить этот запрос какому-либо серверу DNS.
Имя: SearchList
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_SZ
Допустимый диапазон: разделенные запятой строки суффиксов DNS
Эта настройка политики определяет, будет ли клиент DNS выполнять передачу первичного суффикса DNS в процессе разрешения имени. Если клиент направляет запрос имени с одной меткой (например, "mybox"), то локальный клиент DNS присоединяет суффикс (например, "skillet.com"), что дает в результате запрос "mybox.skillet.com", прежде чем отправить этот запрос серверу DNS.
Первичный суффикс DNS передается до тех пор, пока не будет разрешен запрос или суффикс DNS не будет иметь две метки (например, "skillet.com"). Первичный суффикс DNS не может быть передан менее чем двум меткам.
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: 0x0 (отключено) и 0x1 (включено)
Эта настройка политики разрешает или запрещает клиенту регистрировать PTR-записи. В состоянии по умолчанию клиенты DNS, сконфигурированные для выполнения динамической регистрации DNS, пытаются выполнить регистрацию ресурсной PTR-записи, только если они успешно зарегистрировали соответствующую ресурсную A-запись. Чтобы включить эту политику, выберите Enable (Включить) и выберите одно из следующих значений.
Имя: RegisterReverseLookup
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: 0x0 (отключено), 0x1 (включено)
Эта настройка политики определяет интервал обновления регистрации ресурсных A- и PTR-записей для компьютеров. Эту настройку можно применять только к компьютерам, которые используют динамическое обновление. Если ресурсные записи DNS регистрируются в зонах с включенной очисткой, то значение этой настройки должно быть не больше, чем Refresh Interval (Интервал обновления), заданный для этих зон. Задание величины Registration Refresh Interval, превышающей Refresh Interval этих зон DNS может вызывать преждевременное удаление ресурсных A- и PTR-записей, что может вызвать определенную проблему.
Имя: RegistrationRefreshInterval
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: больше или равно 1800 (секунд)
Эта настройка политики определяет, будет ли клиент DNS, который пытается зарегистрировать свою ресурсную A-запись, замещать существующие ресурсные A-записи, содержащие конфликтные IP-адреса. Во время динамического обновления зоны, которая не использует Secure Dynamic Update (Защищенное динамическое обновление), клиент может обнаружить, что существующая ресурсная A-запись связывает DNS-имя хоста данного клиента с IP-адресом другого компьютера. Согласно конфигурации по умолчанию этот клиент DNS попытается заместить эту существующую A-запись той A-записью, которая связывает DNS-имя с IP-адресом клиента.
Имя: RegistrationOverwritesInConflict
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: 0x0 (отключено) и 0x1 (включено)
Эта настройка политики определяет, может ли компьютер, выполняющий динамическую регистрацию, регистрировать свои ресурсные A- и PTR-записи путем конкатенации своего имени (Computer Name) и суффикса DNS для конкретного соединения (в дополнение к регистрации этих записей путем конкатенации своего имени и первичного (Primary) суффикса DNS.
Имя: RegisterAdapterName
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: 0x0 (отключено), 0x1 (включено)
Эта настройка политики указывает значение для поля TTL (time-to-live) ресурсных A- и PTR-записей, регистрируемых в компьютерах, к которым относится эта настройка.
Имя: RegistrationTTL
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: 0-4294967200 (секунд)
По умолчанию: 600
Эта политика указывает, какой вид обновлений для регистрации DNS-записей будут использовать компьютеры, к которым применяется эта настройка, – защищенные динамические обновления или стандартные динамические обновления. Чтобы включить эту настройку, выберите вариант Enable и выберите одно из следующих значений.
Имя: UpdateSecurityLevel
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Допустимый диапазон: 0 (UnsecureFollowedBySecure), 16 (OnlyUnsecure), 256 (OnlySecure)
Эта настройка политики указывает, могут ли компьютеры, к которым применяется эта политика, отправлять динамические обновления зонам, имя которых содержит одну метку (т.е. зонам доменов верхнего уровня, например, "com").
По умолчанию клиент DNS, сконфигурированный для выполнения динамических
обновлений, будет отправлять динамические обновления зоне или зонам DNS,
которые является руководящими для его
Если включить эту политику, то компьютеры, к которым применяется эта политика, будут отправлять динамические обновления любой зоне, которая является руководящей для его ресурсных записей, за исключением корневой зоны.
Имя: UpdateTopLevelDomainZones
Раздел: HKLM\Software\Polices\Microsoft\Windows NT\DNSClient
Тип: REG_DWORD
Значения: 0x0 (отключено) и 0x1 (включено)
Важно отметить, что Windows Server 2003 не полностью поддерживает стандарт
Эта служба использует с помощью
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\
Parameters
Добавьте EnableDnsSec в поле DWORD.
Этому полю передается одно из трех значений в зависимости от того, что вы хотите сделать.
0x0. Исключение ресурсных записей (RR) 0x2. Включение ресурсных записей (RR) 0x1 (или пустое поле). Если вам нужно, чтобы записи Возможны случаи, когда у вас имеется сервер DNS с несколькими адаптерами
(
Исходная спецификация для DNS ограничивала размер пакета 512 октетами. EDNS0 (RFC 2671) позволяет передавать пакеты большего размера. Когда сервер DNS получает запрос (используется протокол UDP), он ищет ресурсную OPT-запись клиента и изменяет свой ответ, чтобы можно было передать столько ресурсных записей, сколько указано этим клиентом в OPT-записи (размер UDP указывается в OPT-записи).
Возможности ведения журналов DNS не изменились после Windows 2000, но работать
с ними стало удобнее за счет использования графического интерфейса (GUI),
который включен как часть оснастки Event Viewer. Вы можете задавать фильтрацию
по пользователям, по компьютерам, по идентификаторам событий, по категориям
или источникам событий от первого до последнего события и в соответствии с типами
событий (обычная информация, предупреждения или ошибки). Ведение журнала
DNS (DNS logging) представлено в оснастке DNS или в оснастке Event Viewer,
включенной в окно Administrative Tools (Администрирование). Для выбора опций
ведения журнала событий и отладки щелкните правой кнопкой на сервере в оснастке
DNS и выберите пункт Properties. Появятся вкладки журнала отладки (Debug
logging) и журнала событий (
Windows Server 2003 содержит много встроенных инструментальных средств, которые можно использовать для мониторинга, управления и устранения проблем DNS. Эти средства описываются в следующих разделах.
Эта утилита командной строки позволяет запрашивать пространство имен DNS и
позволяет вам устранять наиболее распространенные проблемы DNS. Она предусматривает
Nslookup -Команда хост-имя | -Сервер
Сервер – это указанный вами сервер, но по умолчанию используется сервер DNS, указанный на вашей странице свойств TCP/IP Properties.
Эту утилиту можно применять только при условии, что ваш компьютер использует
также DHCP. Она имеет три параметра, относящихся к DNS: /registerdns, /flushdns
и /displaydns.
Параметр /registerdns обновляет аренду DNS и вынуждает клиента выполнить
перерегистрацию с помощью сервера DNS. Параметр /flushdns выполняет очистку
кэша клиентского компонента (resolver), /displaydns показывает, что содержится в
кэше resolver.
Это утилита TCP/IP, и она должна использоваться в первую очередь, чтобы выяснить, действует ли соединение между клиентом и сервером. Если не действует, то нет смысла в устранении проблемы DNS, поскольку это проблема более низкого уровня. Кроме того, для быстрой проверки PTR-разрешения вы можете направить ping по IP-адресу, что позволит вам удостовериться в наличии соединения и хост-имени.
Эта утилита командной строки предоставляет много возможностей. Большинство вещей, которые вы можете делать с помощью оснастки DNS, можно делать и с помощью DNSCMD, включая скрипты, создание разделов Active Directory (AD), вывод списка этих разделов, создание и конфигурирование серверов DNS, а также управление. DNSCMD не устанавливается по умолчанию; это должны сделать вы:
Перейдите на свой дистрибутивный CD, войдите в папку support\tools и щелкните
на suptools.msi. Произойдет запуск программы установки, после чего будут установлены
средства поддержки (Support tools). Это очень мощное средство – ввод DNSCMD в командной строке даст вам представление об этом, но если говорить о
реальных возможностях, то почти все (а, может быть, и все) функции, которые вы
получаете с помощью GUI, доступны также с помощью DNSCMD.
Эта утилита применяется не только к DNS, поскольку она имеет много других сетевых
функций; однако она позволяет справиться с целым рядом "таинственных"
проблем и дает вам отчет о состоянии для записей DNS, которые обнаружила в регистрациях.
Чтобы увидеть, что сообщит NETDIAG по определенному вопросу,
перейдите в окно командной строки и вводите netdiag /fix для всех сетевых функций,
которые хотите проверить, или введите netdiag /DNS. Чтобы узнать, что может
делать эта утилита, перейдите в
Эта утилита позволяет переименовывать домены в Windows 2003. Она имеет также очень нужную "побочную" функцию, позволяя проверять целостность домена путем поиска необходимых записей-локаторов контроллеров домена (DC Locator Source) на руководящих серверах DNS. Это нужно, чтобы убедиться в том, что репликация и аутентификация будут происходить должным образом после переименования. Ее легко использовать для переименования записей-локаторов контроллеров домена на сервере DNS, который является руководящим для данной зоны, и последующей проверки целостности домена. Если определенная запись отсутствует, утилита может сообщить, какая это запись, что облегчает устранение проблем.
Это утилита командной строки, которая охватывает большинство задач диагностики
DNS. Ее можно использовать для диагностирования наиболее распространенных
проблем разрешения имен DNS. Она имеет три основные функции: dnslint /ql (проверка
определенных пользователем записей на сервере DNS), dnslint /ad (проверка
записей, относящихся к активному домену [dnslint /d (проверка
"неверного делегирования"). Вы можете загрузить это средство с веб-сайта Microsoft.
Установка DNS зависит от того, что вы планируете делать с пространством имен и Active Directory (AD). Предпочтительный метод – это их интеграция, которая требует установки AD и интегрированных с AD зон. Это существенно отличается от установки классической DNS на контроллере домена, работа которого основана на Active Directory. Вам нужно выполнить необходимые шаги во время установки или с помощью утилиты DCPROMO, вызванной из меню Start/Run (Пуск/Выполнить). Прежде чем сделать это, проследите, чтобы данный компьютер был сконфигурирован со статическим IP-адресом, иначе у вас не будет SRV-записей. Они создаются в вашей зоне AD, а остальные контроллеры домена ищут их во время присоединения к домену.
В Windows 2003 сначала появляется новое диалоговое окно, где говорится, что возможны проблемы операционной системы с этим контроллером домена, если у вас есть машины, работающие под управлением Windows 95 либо NT4 версии SP3 или более ранних версий. Причиной этого может быть подписание блоков SMB (Server Message Block – Блок серверных сообщений) и более защищенное соединение, относящееся к контроллеру домена и его клиентам. Блоки SMB обеспечивают разделяемое использование принтеров и файлов, администрирование и аутентификацию входа для операционных систем Windows. SMB изменился в Windows 2003. Он стал несовместим с более ранними формами протокола Session Message Block Protocol и не позволяет клиентам более ранних версий Windows аутентифицироваться для домена. Помните об этом предупреждении!
Было также изменено одно из диалоговых окон для DNS, встроенных в диалоговый процесс DCPROMO. Оно используется, чтобы сообщить, что не может быть установлен контакт с сервером DNS для этого домена. Мастер спросит, хотите ли вы установить и сконфигурировать DNS для этого сервера или сделаете это позже вручную. Теперь оно вызывается окном диагностики регистрации DNS. В нем описывается, какая запись не найдена (SRV), предлагаются действия для данной ситуации и предоставляются для выбора три следующих варианта:
DCPromo будет действовать как мастер, запрашивая у вас информацию, создавая для вас зоны DNS и выполняя конфигурирование некоторых настроек. Мастер получает от вас информацию, запускает процесс, и вскоре у вас появляется контроллер домена, работающий с AD DNS. Это позволяет осуществлять динамические обновления и дает вам также зоны прямого и обратного поиска.
Это несложный процесс. Вот как он выполняется.
Ниже описывается, как установить DNS с помощью мастера Manage Your Server Wizard (Управление вашим сервером).
Чтобы сконфигурировать зону прямого поиска, выполните следующие шаги.
После этого вы можете добавлять записи, но чтобы сделать это непосредственно, нужно сконфигурировать зону, чтобы она разрешала динамические обновления, и сконфигурировать клиентов, чтобы они могли регистрировать самих себя. Если вам нужно добавить запись вручную, щелкните правой кнопкой на только что созданной зоне, выберите пункт Add A Record (Добавить запись) и выполните прокрутку списка, пока не найдете нужную вам запись.
Чтобы проверить правильность конфигурации зоны прямого поиска, выполните следующие шаги.
DNS позволяет делегировать полномочия администрирования и управления пользователям и группам. Определите необходимые вам полномочия и выберите нужный вам уровень безопасности. Чтобы вызвать страницу Security (Безопасность), щелкните правой кнопкой на данном сервере DNS в оснастке DNS и выберите Security на странице свойств.
DNS и DHCP могут использоваться совместно. В этой конфигурации клиентам и серверам разрешается обновлять A-записи (записи хостов) и PTR-записи (записи обратного поиска). DHCP будет предоставлять вам аренду и обновлять соответствующим образом записи DNS.
Чтобы получить более подробную информацию по спецификациям, обратитесь к документам RFC (Request for Comment). Ниже приводятся все документы RFC для системы Windows Server 2003 и ее клиентов.
Следующие draft-документы интернет содержат спецификации, используемые для разработки и реализации сервера и клиентских служб DNS.
Следующие дополнительные спецификации используются для разработки и реализации служб сервера и клиента DNS.
WINS используется для имен NetBIOS таким же образом, как DNS для хост-имен; основное отличие заключается в структуре пространств имен. WINS – это распределенная база данных или может быть такой базой данных. WINS отображает IP-адреса на имена NetBIOS. WINS – это "плоское" пространство имен, в то время как DNS – это иерархическая структура; в WINS нет никакой явно или неявно выраженной иерархии. В то время как машина, находящаяся в accounting домена skillet.com будет представлена в DNS как myhost.skillet.com, ее доменное имя NetBIOS будет SKILLET.
WINS была предназначена для разрешения имен NetBIOS в немаршрутизируемой сети. Без WINS компьютеры просто отправляли бы широковещательные сообщения через сеть. Это создает проблему использования NetBIOS, поскольку широковещательные сообщения переполняют большую сеть и "съедают" значительную долю пропускной способности. NetBIOS нельзя маршрутизировать, и выполнение происходит поверх TCP/IP.
NetBIOS – это уровень представления (см. модель OSI) интерфейса прикладного
программирования (API), разработанный IBM в 1983 г. Он позволяет программам
задавать инструкции нижележащим сетевым протоколам; несмотря на его "возраст",
именно поэтому он все еще используется. Унаследованные приложения и
многочисленные средства сетевого администрирования все еще используют этот API
и не могут выполнять обмен информацией без разрешения имен NetBIOS. Напомним,
что в примере разрешения имен DNS мы ссылались на браузер, который передает
запрос имени клиентскому компоненту DNS (resolver) для разрешения имени.
NetBIOS работает почти так же: приложение, которому требуется найти службу,
работающую на другом компьютере (
Два непосредственных примера – это навигация, а также
Как вы можете предполагать, для этого плоского пространства имен требуется сервер WINS, который содержит соответствующие записи. Они существенно отличаются от записей DNS, в том числе форматом базы данных и методом хранения. В WINS нет никакого ASCII-файла. Это база данных Microsoft, известная под названием Jet, которая используется также в Access. Она плохо защищена от повреждений и чувствительна к большому числу факторов. По мере дальнейшего изложения мы увидим несколько параллелей с DNS.
Имена NetBIOS могут быть уникальными или являться частью группы. Это 16-байтовые адреса, и они имеют одну позицию, зарезервированную для типа службы, которую они представляют. Если имя короче 16 символов, то остальные байты заполняются до 16-го символа. Это важно знать, если вы редактируете файл LMHOSTS (см. ниже раздел "LMHOSTS"). Запись для службы рабочей станции (Workstation) может выглядеть следующим образом:
Machinename <00> UNIQUE
Это представление записи компьютера в WINS для службы Workstation. Вы передаете информацию с помощью суффикса (<##>), содержащего алфавитно-цифровые символы. Вы можете также встретить запись Machinename <00> GROUP, и это также допустимо. Уникальные имена (UNIQUE) используются для доступа к службам на отдельных компьютерах; группы (GROUP) используются для групп компьютеров. Существуют типы записей (их очень много), и этот список не является полным. И нет способа его упорядочить, поскольку поставщики сторонних фирм имеют свои собственные суффиксы, которые регистрируются их собственными приложениями. Чтобы увидеть их, посмотрите две самые последние записи для Irmalan и Lotus Notes.
<computername> 00 U Workstation Service <computername> 01 U Messenger Service <\\—__MSBROWSE__> 01 G Master Browser <computername> 03 U Messenger Service <computername> 06 U RAS Server Service <computername> 1F U NetDDE Service <computername> 20 U File Server Service <computername> 21 U RAS Client Service <computername> 22 U Microsoft Exchange Interchange (MSMail Connector) <computername> 23 U Microsoft Exchange Store <computername> 24 U Microsoft Exchange Directory <computername> 30 U Modem Sharing Server Service <computername> 31 U Modem Sharing Client Service <computername> 43 U SMS Clients Remote Control <computername> 44 U SMS Administrators Remote Control Tool <computername> 45 U SMS Clients Remote Chat <computername> 46 U SMS Clients Remote Transfer <computername> 4C U DEC Pathworks TCPIP service on Windows NT <computername> 42 U mccaffee anti-virus <computername> 52 U DEC Pathworks TCPIP service on Windows NT <computername> 87 U Microsoft Exchange MTA <computername> 6A U Microsoft Exchange IMC <computername> BE U Network Monitor Agent <computername> BF U Network Monitor Application <username> 03 U Messenger Service <domain> 00 G Domain Name <domain> 1B U Domain Master Browser <domain> 1C G Domain Controllers <domain> 1D U Master Browser <domain> 1E G Browser Service Elections <INet~Services> 1C G IIS <IS~computer name> 00 U IIS <computername> [2B] U Lotus Notes Server Service IRISMULTICAST [2F] G Lotus Notes IRISNAMESERVER [33] G Lotus Notes Forte_$ND800ZA [20 U DCA IrmaLan Gateway Server Service
Именно эти виды записей вы можете встретить в базе данных WINS. (Другие
называются "статическими записями".) Большинство регистраций WINS являются
динамическими и ведут себя аналогично аренде DHCP. Статическая запись используется
для таких систем, как UNIX (которые не поддерживают NetBIOS). Кроме
случаев поиска источника проблем никогда не используйте их для поддерживающих
NetBIOS клиентов, поскольку они будут пытаться регистрировать себя и будут
отклонены. Это обычно означает, что клиент не получит регистрации, а вы получите
сообщение: Duplicate name on network! (Дублированное имя в сети). Статические
записи можно использовать для систем, которые не могут регистрировать имя
NetBIOS, а записи, которые можно добавлять вручную, имеют такие же типы, как и
те, что обычно вводятся динамически поддерживающим NetBIOS клиентом: Unique,
Group, Domain Name, Internet Group и
Если широковещательное сообщение NetBIOS не дает результата, то следующая альтернатива – это обращение к файлу LMHOSTS на локальном компьютере. Пример этого файла можно увидеть в папке %systemroot%\system32\drivers\... В отличие от файлов HOSTS файлы LMHOSTS имеют дополнительные опции для разрешения имен, включая, в частности, следующие средства.
Настройка клиента в разрешении имен WINS/NetBIOS будет определять его поведение. Имеются четыре метода разрешения, которые называются типами узлов. Они действуют следующим образом.
При своем запуске клиенты WINS обращаются к серверу WINS и регистрируют свои имена и IP-адреса. Если соответствующее имя не используется (WINS не "заботится" об IP-адресах; вы можете дублировать их сколько угодно), то сервер разрешает клиенту регистрировать его службы на сервере WINS. Клиент получит сообщение POSITIVE NAME REGISTRATION RESPONSE (положительный ответ на запрос регистрации имени). Минимально компьютер, который подключился, не имея ничего, кроме операционной системы, обычно регистрирует записи <00> (служба Workstation), <20> (служба Server) и <03> (служба Messenger). Если соответствующее имя уже используется, то сервер отправляет "вызов" последнему компьютеру, который зарегистрировал это имя (чтобы он "защитил" свое имя). Сервер делает это три раза через заранее определенные интервалы времени, и если получен ответ на вызов, то клиенту отправляется сообщение NEGATIVE NAME REGISTRATION RESPONSE (отрицательный ответ на запрос имени).
Пользователь увидит всплывающее окно с текстом "Duplicate name on network" (Дублированное имя в сети). Но если ответ на вызов не получен, то клиенту разрешается регистрация. Эти регистрации ограничены по времени, то есть им присваивается значение TTL (срок действия). Клиенты должны обновлять регистрацию имени. При обновлении имени, когда клиенту отправлен "вызов" (как только что было описано) и он не ответил на этот вызов, считается, что этот клиент отказался от своего имени, передав его для использования другому компьютеру. По истечении 50% времени его аренды, клиент отправляет запрос подтверждения имени (обновления аренды). Этот запрос содержит IP-адрес и имя NetBIOS компьютера, которому требуется подтверждение, и сервер WINS отправляет ему сообщение с новой арендой времени. Это происходит в нормальной ситуации.
Но если клиент не может обнаружить сервер, то сервер пытается подтвердить имя каждые 10 минут в течение часа на первичном сервере WINS. Затем он пытается перейти на вторичный сервер WINS и снова пытается получить подтверждение с 10-минутными интервалами. Если обновление по-прежнему не получено, он возвращается на первый сервер и повторяет свои попытки. Все это продолжается, пока не закончится срок аренды; если за это время не было попыток обновления имени (другим клиентом), то имя освобождается. Еще один способ освобождения имени – это отключение компьютера; нельзя просто выключить компьютер, а должен быть отправлен соответствующий запрос на сервер WINS. Сервер WINS просмотрит базу данных, и если обнаружена соответствующая запись, то сервер возвратит положительный ответ об освобождении имени со значением TTL, равным нулю. Если не найдено соответствия для IP-адреса/имени, то отправляется отрицательный ответ.
Когда клиенту требуется разрешение имени NetBIOS, он ищет его сначала локально. Он просматривает свой кэш в поисках соответствующего имени/адреса. Если имя не разрешено, то клиент запрашивает непосредственно сервер WINS. Он ищет этот сервер, повторяя попытки три раза, и если не получает ответа, то обращается к вторичному серверу и повторяет этот процесс. Если один из этих серверов разрешает запрос, то клиент получает сообщение об успешном результате и ему передается IP-адрес для запрошенного имени NetBIOS. Если ни один из серверов не может разрешить данное имя, то клиенту отправляется сообщение "requested name does not exist" (запрошенное имя не существует). После это клиент начинает применять широковещательные сообщения.
Серверы WINS реплицируют свои базы данных, и, как и в случае DNS, это определяется вашими опциями конфигурации. Напомним, что WINS – это "плоское" пространство имен, поэтому топология его репликации выглядит очень просто. Я встречался со многими пользователями, которые пытались использовать иерархию в пространстве имен WINS. Для репликации базы данных обычно имеется одна схема, которая хорошо работает и требует небольших расходов на обслуживание. Реальная схема репликации называется push/pull ("выталкивание/извлечение"), и мы ознакомимся с ней чуть ниже. На рис 3.1 показана рекомендуемая топология сети, в которой происходит репликация серверов WINS.
(рис 3.1) Репликация типа "hub and spoke"Ее называют звездообразной схемой репликации ( hub and spoke ). Группа серверов WINS выполняет репликацию с центральным первичным сервером; та же схема используется со вторичным сервером, а первичный и вторичный реплицируются друг с другом. Они делают это с помощью метода push/pull. Рассмотрим этот процесс подробнее.
Pull-партнер – это сервер WINS, который запрашивает реплики от своих push-партнеров. Push-партнеры знают, что реплицировать, поскольку номер версии должен быть больше того, что получил pull-партнер в предыдущем сеансе репликации. Push-партнер – это сервер WINS, который отправляет запрос репликации своим pull-партнерам, сообщая им, что его база данных была обновлена. После этого они извлекают реплики. При репликации типа push/pull вам следует учитывать два основных фактора: скорость вашего канала глобальной сети (WAN) и какие компьютеры должны соединяться с какими сайтами.
Предположим, что ваш компьютер – это Remote Site 1 (Удаленный сайт 1, см. рис 3.1), осуществляющий репликацию методом push/pull с сервером Home Office. При необходимости обмена данными с компьютером Remote Site 2, осуществляющим репликацию с сервером Corporate Office, ваш компьютер никогда не получит необходимые для этого записи, если эти записи не являются частью реплики, которая извлекается из Remote Site 1 на сервер Corporate Office и затем реплицируется на сервер Home Office. Реплика – это копия записей WINS, которые реплицированы от партнера push/pull. Поскольку сервер Home Office реплицируется на свой Remote Site 1, эти записи являются частью сервера WINS в службах Remote Site 1.
WINS не является сложной технологией (хотя она плохо масштабируется), и если использовать здравый подход, то обычно WINS действует достаточно хорошо. Большинство проблем возникает в тех случаях, когда разработчики пытаются делать сложные вещи с тем, что не представляет особых сложностей. При хорошей пропускной способности предпочтительно использовать между всеми серверами репликацию типа push/pull, поскольку все записи будут реплицироваться во все точки. Всегда конфигурируйте сервер WINS, чтобы он указывал для разрешения на самого себя.
WINS может обнаруживать и настраивать своих партнеров репликации автоматически, если ваша сеть поддерживает групповые сообщения (multicast). WINS рассылает групповые сообщения приблизительно каждые полчаса по IP-адресу 224.0.1.24. Любой найденный сервер WINS конфигурирует сам себя как партнера push/pull.
Мощность WINS планируется из расчета один сервер на 10000 клиентов. Это вполне достижимая цифра, но в большинстве случаев не учитываются определенные факторы, например, WINS помещают на компьютер, который одновременно является контроллером домена, сервером печати и сервером приложений. Это снижает производительность, а если WINS работает недостаточно хорошо, то возникают проблемы соединений. Если вы планируете использовать WINS в конфигурации от 1 до 10000, не нагружайте данный компьютер другими процессами, убедитесь, что он имеет каналы с достаточной пропускной способностью, используйте высокоскоростные соединения локальной сети (избегайте узких мест), не устанавливайте несколько адаптеров на этот сервер и убедитесь, что этот сервер имеет высокопроизводительную дисковую подсистему. Это кажется странным, но самые сложные проблемы в этих конфигурациях возникали из-за переполнения дисковой подсистемы запросами записи. В этих случаях Performance Monitor (Монитор производительности, см. лекцию 16) показывал проблемы операций записи, а после замены дисковой подсистемы на SCSI RAID 0 производительность резко повышалась.
Проблемы производительности возникают также в тех случаях, когда сервер WINS перегружен за счет того, что он размещен на компьютере, выполняющем много других функций. Один из характерных случаев, с которыми я сталкивался, это программа сканирования вирусов от сторонней компании в большой корпоративной сети, которая очень часто опрашивает клиентов WINS, чтобы проверить, требуются ли обновления. Такие программы обычно имеют консоль конфигурирования, и пользователь сконфигурировал ее для проверки клиентов каждые 20 минут. Причиной проблемы было то, что этот сервер имел 5000 клиентов, поэтому программа сканирования вирусов фактически связывала циклы разрешения имен WINS, то есть опрашивала всех клиентов! Это настолько перегружало сервер, что нормальное разрешение имен становилось невозможным и функционирование сети фактически прекращалось. Здесь возникал эффект, эквивалентный атаке на отказ обслуживания.
WINS можно сконфигурировать для резервного копирования ее базы данных в выбранном вами месте. Выбор соответствующего каталога (Directory) происходит в оснастке WINS, и после этого WINS выполняет резервное копирование баз данных каждые три часа. Это звучит убедительно, но на практике эксплуатируемая база данных может быть повреждена по какой-либо причине и проблема, возможно, не будет разрешена за три часа (до следующего цикла резервного копирования), то есть резервная копия тоже будет поврежденной.
Более подходящим, хотя и более трудным методом, может стать использование утилиты Jetpack, которая проверяет целостность базы данных, прежде чем выполнять ее копирование. Jetpack обладает возможностью придавать целостность базе данных или восстанавливать целостность, если файл базы данных не слишком поврежден. После этого выполните резервное копирование вручную. Вы можете задаться вопросом, зачем нужно резервное копирование. В основном это нужно для быстрого восстановления в случае ... повреждения базы данных! В случае повреждения WINS остается две возможности, если Jetpack не может восстановить файл.
Основные утилиты для поиска и устранения проблем – это NBTSTAT и JETPACK.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.