Опубликован: 15.10.2008 | Доступ: свободный | Студентов: 3511 / 739 | Оценка: 4.48 / 4.23 | Длительность: 45:21:00
Лекция 3:

Ознакомление с DNS

< Лекция 2 || Лекция 3: 1234 || Лекция 4 >

Параметры безопасности

DNS позволяет делегировать полномочия администрирования и управления пользователям и группам. Определите необходимые вам полномочия и выберите нужный вам уровень безопасности. Чтобы вызвать страницу Security (Безопасность), щелкните правой кнопкой на данном сервере DNS в оснастке DNS и выберите Security на странице свойств.

Интеграция с DHCP

DNS и DHCP могут использоваться совместно. В этой конфигурации клиентам и серверам разрешается обновлять A-записи (записи хостов) и PTR-записи (записи обратного поиска). DHCP будет предоставлять вам аренду и обновлять соответствующим образом записи DNS.

Документы RFC

Чтобы получить более подробную информацию по спецификациям, обратитесь к документам RFC (Request for Comment). Ниже приводятся все документы RFC для системы Windows Server 2003 и ее клиентов.

  • 1034 Domain Names-Concepts and Facilities (Доменные имена – концепции и средства)
  • 1035 Domain Names-Implementation and Specification (Доменные имена – реализация и спецификация)
  • 1123 Requirements for Internet Hosts-Application and Support (Требования к хостам Интернет – применение и поддержка)
  • 1886 DNS Extensions to Support IP Version 6 (Расширения DNS для поддержки IPv6)
  • 1995 Incremental Zone Transfer in DNS (Метод добавочной пересылки зон в DNS)
  • 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) (Механизм уведомлений об изменениях зон)
  • 2136 Dynamic Updates in the Domain Name System (DNS UPDATE) (Динамические обновления в DNS) 2181 Clarifications to the DNS Specification (Уточнения к спецификации DNS)
  • 2308 Negative Caching of DNS Queries (DNS NCACHE) (Отрицательное кэширование запросов DNS)
  • 2535 Domain Name System Security Extensions (DNSSEC) (Расширения безопасности DNS)
  • 2671 Extension Mechanisms for DNS (EDNS0) (Механизмы расширения для DNS)
  • 2782 A DNS RR for Specifying the Location of Services (DNS SRV) (Ресурсная запись [RR] DNS для указания местоположения служб)

Draft-документы интернет для DNS

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

  • Draft-skwan-utf8-dns-02.txt. Using the UTF-8 Character Set in the Domain Name System (Использование набора символов UTF-8 в DNS)
  • Draft-ietf-dhc-dhcp-dns-08.txt. Interaction Between DHCP and DNS (Взаимодействие между DHCP и DNS)
  • Draft-ietf-dnsind-tsig-11.txt. Secret Key Transaction Signatures for DNS (TSIG) (Подписи транзакций с секретными ключами для DNS)
  • Draft-ietf-dnsind-tkey-00.txt. Secret Key Establishment for DNS (TKEY RR) (Использование секретных ключей для DNS)
  • Draft-skwan-gss-tsig-04.txt. GSS Algorithm for TSIG (GSS-TSIG)

Другие спецификации для DNS

Следующие дополнительные спецификации используются для разработки и реализации служб сервера и клиента DNS.

  • af-saa-0069.000.doc. ATM Name System Specification version 1.0 (Спецификация системы имен ATM, версия 1.0). Эта спецификация опубликована ATM Forum. Для получения более подробной информации вы можете загрузить эту спецификацию с FTP-сайта ATM Forum. Его можно посетить по адресу http://www.gmd.de/ftp/mirrors3/atmforum/approved-specs/

WINS

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

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

Как вы можете предполагать, для этого плоского пространства имен требуется сервер WINS, который содержит соответствующие записи. Они существенно отличаются от записей DNS, в том числе форматом базы данных и методом хранения. В WINS нет никакого ASCII-файла. Это база данных Microsoft, известная под названием Jet, которая используется также в Access. Она плохо защищена от повреждений и чувствительна к большому числу факторов. По мере дальнейшего изложения мы увидим несколько параллелей с DNS.

Имена NetBIOS

Имена 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 и Multihomed.

LMHOSTS

Если широковещательное сообщение NetBIOS не дает результата, то следующая альтернатива – это обращение к файлу LMHOSTS на локальном компьютере. Пример этого файла можно увидеть в папке %systemroot%\system32\drivers\... В отличие от файлов HOSTS файлы LMHOSTS имеют дополнительные опции для разрешения имен, включая, в частности, следующие средства.

  • #PRE. Запись, перед которой указывается это ключевое слово, будет заранее загружаться в кэш при загрузке компьютера.
  • #DOM [имя_домена]. Это ключевое слово требуется для проверки домена через маршрутизатор, а также для навигации в домене и синхронизации учетных записей.
  • #INCLUDE <путь>. Тег #INCLUDE позволяет вам получать доступ к файлу LMHOSTS, находящемуся в каком-либо месте, отличном от местоположения по умолчанию.
Типы разрешения

Настройка клиента в разрешении имен WINS/NetBIOS будет определять его поведение. Имеются четыре метода разрешения, которые называются типами узлов. Они действуют следующим образом.

  • B-узел. Напомним, что B означает Broadcast (широковещательное сообщение). Это обычно то, что вы использовали бы, если бы у вас был один сетевой сегмент, поскольку в нем распространяются широковещательные сообщения, которые требуют ответа других клиентов, а большинство маршрутизаторов не пропускают широковещательные сообщения.
  • P-узел. Этот тип вы использовали бы при наличии сервера WINS; он не передает широковещательных сообщений, но обращается непосредственно к серверу WINS для своего разрешения имен.
  • M-узел. Это смешанный режим, поскольку для него используется комбинация B- и P-узлов. По умолчанию он действует как B-узел; если он не получает никакого ответа (нужный ему ресурс находится в другой подсети), то он переходит в режим P-узла и запрашивает сервер WINS.
  • H-узел. Его называют "гибридным" узлом. Фактически это обратная версия M-узла. Сначала он запрашивает сервер WINS и если не получает никакого ответа, то переходит в режим B-узла и передает широковещательное сообщение. Это узел по умолчанию.
Регистрация, обновление и освобождение имен

При своем запуске клиенты 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.

Репликация типа "hub and spoke"

Рис. 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 (Монитор производительности, см. "Настройка и оптимизация производительности" ) показывал проблемы операций записи, а после замены дисковой подсистемы на SCSI RAID 0 производительность резко повышалась.

Проблемы производительности возникают также в тех случаях, когда сервер WINS перегружен за счет того, что он размещен на компьютере, выполняющем много других функций. Один из характерных случаев, с которыми я сталкивался, это программа сканирования вирусов от сторонней компании в большой корпоративной сети, которая очень часто опрашивает клиентов WINS, чтобы проверить, требуются ли обновления. Такие программы обычно имеют консоль конфигурирования, и пользователь сконфигурировал ее для проверки клиентов каждые 20 минут. Причиной проблемы было то, что этот сервер имел 5000 клиентов, поэтому программа сканирования вирусов фактически связывала циклы разрешения имен WINS, то есть опрашивала всех клиентов! Это настолько перегружало сервер, что нормальное разрешение имен становилось невозможным и функционирование сети фактически прекращалось. Здесь возникал эффект, эквивалентный атаке на отказ обслуживания.

Автоматическое резервное копирование

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

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

  1. Удалить этот файл, прекратить работу WINS и снова запустить WINS; в результате будет создана новая база данных. Но в этом случае всем компьютерам потребуется перерегистрация. Это обычно означает перезагрузку.
  2. Перезагрузить резервную копию базы данных WINS, и восстановление потребуется только для тех машин, которым требуется обновление, что лучше отключения всей системы.

Основные утилиты для поиска и устранения проблем – это NBTSTAT и JETPACK.

< Лекция 2 || Лекция 3: 1234 || Лекция 4 >