Книга
← К списку книгЗагрузка разделов…
активнаАктивные записи участвуют в каталоге и синках. Неактивная книга скрыта, но не удалена из базы.
Книга
Служба DNS
в Windows0 2000
Роджер Абель
Герман Найф
Эндрю Даниэльс
Джеффри Грэхем
ББК32.973.26-018.2я75
А14
УДК681.3.07
Издательский дом ''Вильямс"
Перевод с английского и редакция А В. Высоцкого
По общим вопросам обращай гесь в Издательский дом ' Вильямс"'по адресу: infb@williainspublishing.com, http://x\w\i.williamspublishing.com
Абель, Роджер. Найф. Герман. Даниэл ьс. Эндрю. Грэхем, Джеффри.
Л14 Служба DNS в Windows 2000. : Пер. с англ, : Уч. пос — М. : Ичлагслнекий зом "Вильями", 2001. —496 с. : ил. — Парал. тит. англ,
ISBN 5-8459-0147-2 (рус)
Эта книга, делая упор на таких к.]ючевых вопросах, как проектирование и зашита служб DNS. планирование взаимодействия с др\ тми службами и системами, установка и испо.н.зование служб DHCP и WINS, представляет собой полное руководство по новейшей версии системы доменных имен Microsoft. Ашоры дают практические советы, показывают рациональные приемы работы и рассказывают о стратегиях, которыми надо руководствова;ься при проектировании и обслуживании DNS. чя)6ь【достичь 01иима.'1ьной производитеiwiocth систем Windows 2000 в малмх и средних орЕЭиизациях.
ББК32.973.26-018.2я75
Все названия программных продуктов являются зарегистрированными торговыми марками соответствующих фирм
Никакая часть настоящего издания ни в каких целях не може, быть воспрошвсдсиа в какой бы то ни было форме и какими бы то ни было средствами. б>;ш то электронные пли механические, включая фотокопирование и запись на магнитный Hocineih. если на это пег письменного разрешения издательства New Riders Publishing.
Authorized translation from the English language edition published by Neu Riders Publishing. Copyright © 2000
All rights reserved. No part of this book may be reproduced or transmitted in any form or b) any means, electronic or mechanical including photocopying, recording or by any information siorage retrieval system, without permission fronHhe Publisher
ISBN 5-8459-0147-2 (pyc.)ISBN 0-7357-0973-4 (англ.)ISBN 5-8459-0147-2 (pyc.)ISBN 0-7357-0973-4 (англ.).Russian language edition published b\ Williams Publishing House according to the Agreement with R&I Enterprises Internationa!. Cop>right &丿 200]
ISBN 5-8459-0147-2 (pyc.)
ISBN 0-7357-0973-4 (англ.)
ISBN 5-8459-0147-2 (pyc.)
ISBN 0-7357-0973-4 (англ.)
© Pi3jaie;ii.CKnii дом "Вильямс", 2001
© Nev Riders Publishme. 2000
Оглавление
Введение22
ЧАСТЬ I. ЧТО ТАКОЕ СИСТЕМА ДОМЕННЫХ ИМЕН 25
Глава 1. Введение в систему доменныхимен26
Глава 2. Как работает DNS44
Глава 3. Типы серверов имен66
「лава 4. Подробная информация о домене80
「лава 5. Анализ запросов имен106
Глава 6. Работа с провайдерами118
ЧАСТЬ II. ИСПОЛЬЗОВАНИЕ WINDOWS 2000 DNS
SERVER127
Глава 7. Динамическая DNS и ActiveDirectory128
Глава 8. Работа с серверами BIND159
Глава 9. Проектирование служб DNS166
Глава 10. Проблемы безопасности184
Глава 11. Настройка Windows DNS Server200
ЧАСТЬ III. ПОДДЕРЖКА СЛУЖБ DNS В WINDOWS 231
Г^ава 12. Средства поиска неисправностей232
Глава 13. Рациональные методы работы и обслуживания271
Глава 14. Настройка и разрешение клиентов Windows 308
Глава 15. Службы DHCP в Windows343
Глава 16. WINS: традиционные службы имен и разрешение370
Глава 17. NetBIOS: традиционные службы имен и разрешение397
ЧАСТЬ IV. ПРИЛОЖЕНИЯ423
Приложение А. Файлы LMHOSTS и HOSTS424
Приложение Б. Документы RFC по DNS430
Приложение В. Домень】 Internet верхнего уровня436
Приложение Г. Регистрация адресов в Internet447
Приложение Д. Примеры трассировки разрешения DNS 451
Приложение Е. Записи ресурсов и файл кэша InterNIC 459
Приложение Ж. Использование IPv6472
Приложение 3. Многосетевые серверы Windows477
Предметнный указатель480
Содержание
Введение22
Для кого предназначена эта книга23
Структура книги23
ЧАСТЬ I. ЧТО ТАКОЕСИСТЕМА ДОМЕННЫХ ИМЕН25
Глава 1. Введение в систему доменных имен ^26
Регистрация, разрешение и распределение имен28
Имена узлов и IP-адреса29
Регистрация имен узлов29
Записи ресурсов адресов узлов31
Разрешение имен узлов32
Обратный поиск34
Распределение имен узлов36
Частные серверы DNS .37
Характеристики имен узлов38
Имена узлов IP39
RFC 1035: рекомендации по именованию узлов40
Имена компьютеров Windows (NetBIOS)41
Полностью уточненные доменные имена41
Выбор доменного имени42
Резюме43
Глава 2. Как работает DNS44
Иерархия узлов и доменов45
Субдомены48
Делегирование49
Домены и зоны50
Основные серверы DNS,52
Дополнительные серверы DNS52
Перемещение данных с основных серверов DNS на дополнительные53
Разрешение запросов клиентов55
Прохождение запроса клиента57
Пример запроса адреса узла，59
Обзор инструментальных средств63
Резюме65
Глава 3. Типы серверов имен66
Основные серверы имен67
Хранение данных начальной конфигурации DNS Windows 68
Данные конфигурации и домены69
Дополнительные серверы имен71
Серверы имен, предназначенные только для кэширования73
Прохождение запросов: узлы пересылки и подчиненные
х серверы74
Определение типа DNS77
Резюме79
Глава 4. Подробная информация о домене80
Записи ресурсов в базе данных81
Синтаксис записей ресурсов83
Записи SOA85
Записи серверов имен (NS)88
Записи PTR и обратный поиск90
Записи адресов (А)92
Записи почтовых обменников (MX)94
Записи CNAME95
Записи SRV97
Записи серверов имен Internet для Windows (WINS)99
Обратные записи серверов имен Internet для Windows
(WINS-R)101
Файл кэша102
Доступ к серверам корневого уровня через файл кэша104
Делегирование104
Резюме105
Глава 5. Анализ запросов имен106
Итеративные и рекурсивные запросы106
Отправка запроса DNS107
、Ответ в кэше найден111
Ответ в кэше не найден111
TTL112
Процесс запроса113
Рекурсивные запросы DNS113
Итеративные запросы DNS115
Обратные запросы DNS115
Запросы за работой116
Резюме117
Глава 6. Работа с провайдерами118
Как заявить о себе в Internet118
Общие соображения по использованию ISP для службы имен 120
Как выйти в Internet и настроить серверы121
Как внести изменения в сервер имен123
Резюме125
ЧАСТЫ1. ИСПОЛЬЗОВАНИЕ WINDOWS 2000 DNS SERVER 127
Глава 7. Динамическая DNS и Active Directory128
DDNS129
Что такое DDNS130
Использование DDNS клиентами Windows 2000131
В чем проблемы131
Влияние служб133
Функции очистки записей ресурсов DNS]34
Что делает очистка134
Как и когда производится очистка135
Интеграция зон DNS в Active Directory137
Как это работает137
Возможности интеграции138
Зависимость Active Directory от записей SRV149
Служба обнаружения домена149
Структура записей SRV150
Записи SRV без DDNS151
Попробуем представить Active Directory и DNS как единое целое153
Топология Active Directory и DNS154
Согласование топологии серверов DNS с размещением контроллеров домена154
Стандартные группы в доменном окружении155
Доступность данных зоны DNS155
Навигация в службах каталогов и нагрузка на DNS156
Нагрузка при обновлении DDNS157
Резюме158
Глава 8. Работа с серверами BIND159
Сообщение между серверами имен160
Связь с BIND версии 4.9.4 и младше160
Связь с BIND 8161
Переход с BIND на Windows 2000 DNS162
Работа BIND в Windows164
Другие различия в загрузочных файлах и файлах зон164
Резюме165
Глава 9. Проектирование служб DNS166
Емкость сервера DNS167
Сколько нужно доменов и зон169
Сколько нужно серверов DNS171
Доступность, надежность и избыточность171
Эмпирические правила выбора количества серверов DNS 172
Примеры разработки-173
Настройка домена с одним или несколькими субдоменами 173
0 123467782222 3 46923 3 о 0000000011111111222 22222222222222222220 123467782222 3 46923 3 о 0000000011111111222 2222222222222222222
0 123467782222 3 46923 3 о 000000001111111122
2 2222222222222222222
0 123467782222 3 46923 3 о 000000001111111122
2 2222222222222222222
Использование Intemet-проваидера для основного сервера DNS174
Использование Internet-провайдера для дополнительных серверов DNS176
Защита основного сервера DNS от несанкционированного доступа177
Как большой сайт может создать большойкэшзапросов 178
Установка организационной DNS, скоординированной с внешней DNS179
Анализ использования Windows 2000 и ActiveDirectory180
Построение закрытых сетей180
Защита и совместное использование пространства имен 181
Размещение службы DNS182
Использование доп алнительн ых серверов182
Резюме183
Глава 10. Проблемы безопасности184
Обманные запросы имен186
Отказ от обслуживания188
Использование DNS с брандмауэрами189
Объявление служб193
Динамическая DNS (DDNS)194
Безопасность почты: SMTP, POP, IMAP и Exchange195
Безопасность WWW196
Безопасность FTP197
Резюме198
Глава 11. Настройка Windows DNS Server
Прежде чем начать...
Установка Windows DNS Server
Процедура установки
Консоль управления DNS Server
Настройка сервера DNS
Свойства сервера DNS: Интерфейсы Свойства сервера DNS: Пересылка Свойства сервера DNS: Дополнительно Свойства сервера DNS: Корневые ссылки Свойства сервера DNS: Ведение журнгита Свойства сервера DNS: Наблюдение Свойства сервера DNS: Безопасность
Создание зоны, субдомена и записи ресурсов Создание зон
Передачи зон и другие свойства Делегирование и субдомены
Интеграция в Active Directory Типы серверов
Использование пересылки
Серверы только для кэширования
Подчиненные серверы
Авторитетнее подчиненные серверы
Итеративные запросы
Чистота зоны
Поддерживаемые функции
Ведение журнала
Статистика и наблюдение
Записи DNS Server в реестре
Резюме
ЧАСТЬ IIL ПОДДЕРЖКА СЛУЖБ DNS В WINDOWS
Глава 12. Средства поиска неисправностей
nslookup
Команда help (?)
Команда exit
Команда finger
Команда server
Команда Iserver
Команда root
Команда Is
Команда set
Сообщения об ошибках nslookup
dig
dnscmd
Ping
pathping
tracert (traceroute)
Net Lab
Host
ipconfig
winipcfg
netdiag
netstat
nbtstat
Системный монитор
netmon
Резюме
Глава 13. Рациональные методы работы и обслуживания
Совершенствование серверов DNS
Текущий контроль сервера DNS
Эффективное использование консоли управления Microsoft
334445 5 690 1 2 4577888996791234 5 688088900 1 2 5 5 7 7 1— 2 222222223 3 3 33333 33334445 5 55555 5 666677 7 77777.— 2222222222 工久 2222222222222222222222222222222334445 5 690 1 2 4577888996791234 5 688088900 1 2 5 5 7 7 1— 2 222222223 3 3 33333 33334445 5 55555 5 666677 7 77777.— 2222222222 工久 2222222222222222222222222222222Статистика сервера DNS и информация о настройке Контроль производительности сервера DNS
334445 5 690 1 2 4577888996791234 5 688088900 1 2 5 5 7 7 1— 2 222222223 3 3 33333 33334445 5 55555 5 666677 7 77777.— 2222222222 工久 2222222222222222222222222222222
334445 5 690 1 2 4577888996791234 5 688088900 1 2 5 5 7 7 1— 2 222222223 3 3 33333 33334445 5 55555 5 666677 7 77777.— 2222222222 工久 2222222222222222222222222222222
Журнал событий DNS как средство обнаружения проблем 280
Как предотвратить смешение настройки282
Изменение IP-адреса зарегистрированного сервера DNS285
Изменение регистрации286
Изменение конфигурации IP DNS в Windows 2000287
Изменение конфигурации IP DNS в Windows NT 4289
Увеличение емкости за счет нового сервера DNS291
Добавление основной зоны291
Добавление дополнительной зоны293
Изменение свойств зоны293
Обслуживание данных зоны294
Очистка в динамически обновляемых зонах295
Управление несколькими зонами296
Перемещение файлов зон с одного сервера на другой299
Проблемы при работе с серверами DNS в Windows NT 4306
Резюме307
Глава 14. Настройка и разрешение клиентов Windows308
Свойства TCP/IP клиента309
Настройка клиентов для использования DHCP310
Настройка клиентов для использования DNS312
Установка имени узла и доменного имени для DNS313
Список суффиксов DNS314
Включение DNS315
Указание настроек DNS в реестре317
Настройка клиентов для использования WINS320
Поддерживаемые клиенты320
Настройка клиента WINS320
Область NetBIOS323
Как клиент использует распознаватель Windows324
Введение в распознаватель Windows324
Методы разрешения Windows325
Поведение распознавателя Windows326
Другая информация о поддержке клиента328
Прокси-серверы WINS329
MS DOS и драйвер TCP/IP-32330
Параметры TCP/IP в реестре330
Параметры клиента DNS в реестре332
Параметры NetBT (NetBIOS через TCP/IP) в реестре335
Резюме342
Глава 15. Службы DHCP в Windows343
Что такое DHCP344
Что DHCP может предложить клиенту345
Как клиент настраивается через DHCP346
Установка Windows DHCP Seiver349
Требования и необходимые полномочия349
Установка349
Интерфейс управления Windows DHCP Server350
Авторизация Windows DHCP Server351
Агенты ретрансляции DHCP352
Настройка Windows DHCP Server354
Определение областей356
Установка обновления DDNS для области359
Резервирование клиента360
Параметры DHCP361
Настройка клиентов для использования DHCP365
DHCP в сравнении с ВООТР366
Резюме368
Глава 16. WINS: традиционные службы имен
и разрешение370
Возможности WINS371
Что ожидает WINS и NetBIOS в будущем372
Задачи и ограничения WINS373
Как работает WINS374
Имя и характеристики базы данных в системах WINS377
Преимущества и проблемы сочетания WINS и DNS379
Установка серверов WINS382
Настройка DNS с интеграцией WINS385
Как работает интеграция386
Настройка DNS для использования WINS391
Резюме396
Глава 17. NetBIOS: традиционные службы имен и разрешение 397
История и характеристики NetBIOS398
Краткая история NetBIOS399
Службы NetBIOS400
Регистрация имен NetBIOS402
Имена NetBIOS и коды ресурсов403
Плоское пространство имен и области NetBIOS403
Характеристики имен NetBIOS404
Коды ресурсов в именах NetBIOS404
Разрешение имен NetBIOS408
Методы разрешения имен408
Типы узлов NetBIOS411
Редкие типы узлов: p-узел и т-узел411
Разрешение Ь-узла412
Разрешение h-узла412
Просмотр: служба обнаружения NetBIOS414
С вами говорит NetBIOS418
Проблемы, возникающие при использовании NetBIOS418
NetBIOS по TCP/IP и другим транспортным протоколам 420
Блоки серверных сообщений (SMB) и Общая файловая системаInternet (CIFS)420
Резюме421
ЧАСТЬ IV. ПРИЛОЖЕНИЯ423
Приложение А. Файлы LMHOSTS и HOSTS424
Файл LMHOSTS425
①айл HOSTS428
Приложение Б.Документы RFCпо DNS430
Приложение В, Домены Internet верхнего уровня436
Приложение Г.Регистрация адресоввInternet447
Приложение Д. Примеры трассировки разрешения DNS451
Трассировка запроса DNS: прохождение запроса452
Трассировка запроса DNS Windows NT 4: DNS с интеграцией
WINS454
Трассировка запроса DNS Windows 2000: DNS с интеграцией
WINS456
Приложение Е. Записи ресурсов и файл кэша InterNIC 459
Записи ресурсов459
Записи адреса (A) (RFC 1035)460
Записи Quad А (АААА) (RFC 1886)460
Записи базы данных файловой системы Andrew (AFSDB)
(RFC 1183) — экспериментальные460
Записи канонического имени (CNAME) (RFC 1035)460
Записи переадресации домена (DNAME) (RFC 2672)461
Кодировка DNS географического местоположения — записи глобального позншюнирования (RFC 1712) — устаревшие461
Записи информации узла (HINFO) (RFC 1035)461
Записи цифровой сети интегрального обслуживания
(ISDN) (RFC 1183) — экспериментальные461
Записи KEY (RFC 2535, устаревши兑 RFC 2065)462
Записи обмена ключей (КХ) (RFC 2230)— информационные462
Записи информации о местоположении (LOC) (RFC 1876) 462
Записи почтового я шика (MB) (RFC 1035)— экспериментальные463
Записи назначения почты (MD) (RFC 1035) — устаревшие 463
Записи пересылки почты (MF) (RFC 1035) — устаревшие 463
Записи почтовой группы (MG) (RFC 1035)— экспериментальные463
Записи информации почтового ящика (MINFO)
(RFC 1035) — экспериментальные463
Записи переименования почтового яшика (MR)
(RFC 1035) — экспериментальные464
Записи почтового обменника (MX) (RFC 1035)464
Записи сервера имен (NS) (RFC 1035)464
Записи точки доступа к сетевому сервису (NSAP)
(RFC 1348, 1637 и 1706)465
Записи NSAP-PTR (RFC 1348 — уст叩евшие)465
Записи NULL (RFC 1035) — экспериментальные465
Записи несушествования (NXT)
(RFC 2535, устаревший RFC 2065)465
Записи указателя (PTR) (RFC 1035)465
Записи указателя на Х.400 (РХ) (RFC 1664)466
Записи ответственного лица (RP)
(RFC 1183 — экспериментальные)466
Записи промежуточной маршрутизации (RT)
(RFC 1183 —экспериментальные)466
Записи цифровой подписи (SIG)
(RFC 2535, устаревший RFC 2065)467
Начальная запись зоны (SOA) (RFC 1035)467
Записи служб (SRV) (RFC 2052 — экспериментальные) 467
Записи TXT (RFC 1035)468
Записи известных служб (WKS) (RFC1035)468
Записи WINS468
Записи WINS-R469
Записи адресации Х.25 (Х25)
(RFC 1183 — экспериментальные)469
Файл кэша InterNIC469
Приложение Ж. Использование IPv6472
Что такое IPv6472
Чем отличается IPv6473
Структура адресов IPv6474
Использование IPv6 с DNS474
Приложение 3. Многосетевые серверы Windows477
Многосетевая адресация серверов DNS478
Многосетевая адресация в NetBIOS478
Предметнный указатель480
Об авторах
Роджер Абель (Roger Abell) занимается компьютерами настолько давно, что первый компьютер, который ему разрешили включить и выключить, занимал целую комнату, использовал перфокарты и управляющую программу под названием "монитор", от которой произошли первые операционные системы. Сейчас Роджер ——обладатель сертификатов Microsoft MSCEf MCP+I, MCDBA и МСТ — работает аналитиком- координатором технологической поддержки в Университете штата Аризона. Он работал над проектами Windows начиная с 1996 года. В его послужном списке — администрирование мэйнфреймов IBM, многопользовательских систем под управлением UNIX в том числе системы с массовым параллелизмом, состоящей из 4096 процессоров, м доменов Windows NT, а также программотехника, проектирование систем, разработка прилсокенм访 и программирование. Все это время Роджер преподавал языки и методы программирования в университете и местных колледжах нескольким тысячам студентов. Когда появляется возможность, он любит уходить в поход по малонаселенным местам американского Юго-Запада, занимается там любительской геологией, изучает природу и просто отдыхает.
Герман Найф (Herman Knief) в настоящее время руководит группой информационных и сетевых технологий в компании Auction Walch.com, Inc., где отвечает за корпоративную инфраструктуру компании и архитектуру сети. Auction WaSch.com — ведущий портал Intemet-аукционов, продемонстрировавший головокружительный рост со времени своего основания в 1999 г. Герман также занимает посты директора технических служб в компании Taos (The SysAdmin Company) и архитектора сети GTE в Пентагоне. Кроме того, он является соавтором книги Windows NT DNS, вышедшей в издательстве Macmillan, и написал несколько статей на такие разные темы, как ''Виртуальное частные сети" и "Безопасность в смешанных операционных средах" для журнала Security Advisor.
Эндрю Даниэльс (Andrew Daniels) работает менеджером операций в компании NetLedger, Inc., бухгалтерской фирме, предлагаюшей услуги дагя малого бизнеса. В качестве менеджера операций Эндрю отвечает за несколько тысяч единиц аппаратуры и операционные системы, а его отдел занимается поддержкой приложений и сети. Эндрю работает с компьютерными системами более 10 лет; он участвовал в реализации нескольких больших проектов электронной коммерции и в обслуживании сайтов таких компаний, как £еу/ Strauss (Levi's, Dockers、Slates), Walgreens Pharmacy, Logitech и Eckerd Pharmacy. Эндрю продолжает заниматься системами корпоративного уровня, сетями, безопасностью и администрированием систем. В настоящее время он живет в Силиконовой долине в Калифорнии и в свободное время увлекается туризмом и чтением. Адрес его электронной ПОЧТЫ — bitshark@hotraail. coin.
Джеффри А. Грэхем (Jeffrey A. Graham) — главный системный администратор, руководит операциями в Auction Watch.com. Джеффри имеет сертификаты администратора Windows NT и UNIX. В его обязанности входит наблюдение за группой системных администраторов, которые обслуживают сайт Auction Watch.com, составление технических условий для платформ и систем, реализация проектов и решение всех возникающих проблем. Джеффри занимался разработкой, внедрением и управлением системами DNS, Sendmail™, LDAP, средствами безопасности и другими корпоративными службами в малых, крупных и корпоративных сетях.'
О рецензенте
Нил Растон (Neil Ruston) работает в компании Perot Systems (в лондонском офисе большого швейцарского банка). Он трудится в сфере JT уже 10 лет, свою деятельность начинал с проектирования и развертывания сетей NetWare 2/3/4. Нил Растон — обладатель сертификата CNE 4. Нил проектировал сети для NT и получил сертификат MSCE, участвовал в проекте Microsoft Joint Development Program (JDP), разрабатывал и развертывал технологию Active Directory и топологию DNS в рамках программы JDP. Он использует Windows 2000 начиная с версии Beta 2.
Тем, кто может выдумать новые информационные технологии, и особенно тем, кто обладает пониманием, умением и смелостью для того, чтобы запустить 〃х е производство, когда они появятся. Роджер Абель
Эди, моей любящей и терпеливой жене, к Кекоа и Каиноа, лучшим сыновьям, о которых их отец мог только мечтать.
Герман Найф
Моим близким друзьям, которые направляли, поддерживачи, учили “ заставляли меня сохранять рассудок, отправляя домой, когда я работал больше, чем следовало. Все вы знаете,。ком я говорю. Эндрю Даниэльс
Женщинам моей жизни: Тэмми Уэбб за то, что она была здесь, к за всю помощь, когда я писал эту книгу (и от всех нас — спасибо за еду); Нэнси Грэхем за то, что она принесла меня в этот мир; w, наконец, Джоне Янчевской за первый толчок в этом направлении. Спасибо всем вам за «ю, чем вы были для меня.
Джеффри А. Грэхем
Благодарности
Роджера Абеля
Я признателен моим родителям, Мэрджори и Дэну Леннону, и всей моей семье за то, что они с пониманием относились к моим долгим отлучкам во время работы над книгой. Нил Растон предоставил ценную рецензию, за которую я хотел бы поблагодарить его, И особо мне хотелось бы отметить многих сотрудников издательства New Riders за их веру в этот проект и большую поддержку при его осушествлении.
Германа Найфа
Я хочу поблагодарить всех сотрудников издательства New Riders за их терпение и понимание, когда мы снова и снова возобновляли работу над этим проектом (прежде всего из-за постоянных изменений кода Microsoft). Большое спасибо моим соавторам и редакторам, сделавшим эту книгу реальностью, даже при том, что бывали моменты, когда я думал, что это вообще никогда не случится. И наконец, спасибо рецензентам за их участие и выдержку^ проявленную в ситуациях, когда материал вновь и вновь возвращался к ним бесчисленное количество раз.
Джеффри А. Грэхема
Работа нал этой книгой широко открыла мне глаза на то, как трудно, оказывается, создать что-то, что было бы полезным для читателя, Я надеюсь, что эта книга принесет некоторую помощь в улаживании проблем многим собратьям ^сисадминамВсе мы также понимаем, сколько веса можно набрать, когда ешь во время работы. (Привет, Тэмми!)
От издательства
Вы, читатель этой книги, и есть главный ее критик и комментатор. Мы пеним ваше мнение и хотим знать, что было сделано нами правильно, что можно было сделать лучше и что еще вы хотели бы увидеть изданным нами. Нам интересно услышать и любые другие замечания, которые вам хотелось бы высказать в наш адрес.
Мы ждем ваших комментариев и надеемся на них. Вы можете прислать электронное письмо или просто посетить наш Web-сервер, оставив свои замечания. — одним словом, любым удобным для вас способом дайте нам знать, нравится или нет вам эта книга, а также выскажите свое мнение о том, как сделать наши книги более подходящими для вас.
Посылая письмо или сообщение, не забудьте указать название книги и ее авторов, а также ваш e-mail. Мы внимательно ознакомимся с вашим мнением и обязательно учтем его при отборе и подготовке к изданию последующих книг. Наши координаты:
E-mail:info@williamspublishing com
WWW:http://www.williamspublishing com
Введение
Система доменных имен (domain name system, DNS) уже более десяти лет служит чем-то вроде клея, соединяющего сети мира в единую коммуникационную решетку. Однако DNS не остановилась на достигнутом, она продолжает изменяться, чтобы удовлетворить новым потребностям и вызовам, неизбежным при взрывном росте сети Internet и во вновь появляющихся областях ее применения.
В своей основе DNS — огромный индексный указатель, который позволяет средствам коммуникации связывать любые точки во всемирной сети, используя осмысленные имена. В этом отношении она очень похожа на телефонную книгу, за исключением того, что это распределенная система, т.е. раздел телефонной книги на букву Л находится в Фениксе, на букву 8 — в Лондоне, на букву С — в Токио и т.д.
Начиная с середины 90-х DNS расширялась во многих направлениях. Были добавлены методы более эффективного распределения данных, определены методы автоматического ввода и обновления данных. Рост использования сетевых систем, особенно для критичных целей, вызвал к жизни новые способы зашиты доступа к данным DNS и управления самими данными. Многие новые области применения Internet привели к формированию новой записи данных ресурсов, так что службы DNS теперь могут служить для локализации новых типов сетевых ресурсов.
В этой книге рассказывается о DNS, о том, как она построена и как правильно запустить ее, чтобы она взаимодействовала с тысячами других серверов DNS во всем мире. Подробно рассматриваются практические проблемы, связанные с планированием служб DNS, и средства, с помощью которых можно воздействовать на работу DNS.
В этой книге вы узнаете также об использовании DNS в Windows 2000 и о сервере DNS, который поставляется с Windows 2000. В новейшей версии Windows DNS находится в самом центре ее архитектуры. Windows 2000 полагается на DNS в такой степени и использует ее таким способом, которых никогда раньше нельзя было найти в коммерческой операционной системе. Новая версия DNS, поставляемая с Windows 2000, зна-
чительно отличается и сушественно усовершенствована по сравнению с версией, которая была в Windows NT; она поддерживает весомую часть последних изменений в DNS. Кроме того. Active Directory предлагает новые методы применения DNS и возможностей взаимодействия сетевых служб в Windows 2000. Материал, включенный в эту книгу, призван помочь вам сделать верный выбор среди всех этих вариантов и дать советы по поддержанию "здоровья" средств развертывания.
Для кого предназначена эта книга
Те, кто первый раз попал в ситуацию, когда надо запустить DNS, найдут здесь подробное введение в систему доменных имен. Рассмотрены и исчерпывающе документированы использование DNS клиентом, множество серверов DNS. межсерверные операции и информация, обрабатываемая DNS.
Те, кто имеет опыт работы с DNS, либо в системе UNIX, либо в Windows NT, получат здесь сведения, необходимые для расширения опыта на область применения DNS на платформе Windows 2000. Насколько распространен сервер DNS Windows 2000 (с учетом многих последних изменений в DNS), какие изменения слишком новы и как все это выглядит в сравнении с новейшими уровнями службы BIND ——все это рассмотрено с целью помочь в планировании взаимодействия серверов.
Те, кто намеревается использовать DNS для поддержки Windows 2000 и ее составляющей Active Directory, найдут здесь информацию, соответствую ш\то начальной версии. В книге описаны сушествуюшие варианты и их использование и указано, где можно ожидать новые разработки. В отличие от многих доступных теперь источников, право делать выводы предоставлено читателю, и основное внимание направлено на возможно более полное его информирование.
Те, кто администрирует развертывание доменов Windows и поддерживает клиенты Windows, получат "полную картину". Windows использует больше чем простую DNS для служб имен, и взаимодействие между ними иногда может быть довольно запутанным. Эта книга поможет вам разобраться в указанных вопросах; она охватывает не только DNS, но и службы WINS и DHCP, и их согласование с DNS.
Структура книги
Темы в этой книге рассматриваются последовательно в три этапа. В первых главах даны основные принципы DNS без отступлений от промышленного стандарта DNS, который имеется на всех серверах. Вторая часть книги охватывает проблемы, которые встают перед администратором при проектировании и защите служб DNS, при планировании межсерверных операций и при осмыслении требований и функций, уникальных для Windows 2000 в сравнении с другими серверами DNS
(приводится пример для BIND). Эта часть завершается подробным обзо- - ром Windows 2000 DNS Server, его установкой и настройкой и обзором л инструментальных средств, утилит, методик и обычных задач, связанных х с работой DNS вообще и в Windows 2000 в частности. Завершающие гла- - вы нацелены на проблемы клиентской части и дополнительные службы в в Windows 2000, которые могут быть связаны с DNS. Эти главы включают т вопросы настройки конфигураций клиентов Windows и того, как эти н конфигурации влияют на использование NetBIOS и DNS системами н Windows, описаны также установка и работа со службами DHCP и WINS..
I
Что такое система доменных имен
В этой части...
Введение в систему доменных имен
Как работает DNS
Типы серверов имен
Подробная информация о домене
Анализ запросов имен
Работа с провайдерами
Введение в систему доменных имен
В этой главе...
Регистрация, разрешение и распределение имен. Система доменных имен (DNS) прежде всего является каталогом зарегистрированных имен компьютеров и адресов Internet ProtocoJ (IP), которые могут быть немедленно локализованы. В этой части представлен обзор процессов разрешения имени сервера, которое является важнейшей частью записей DNS, и распределения имен компьютеров. Серверы DNS также могут служить для расположения служб в домене таким образом, что они будут авторитетными для него. Если эта функция реализована, можно послать запрос к службе в домене, а не к системе, и все равно получить IP-адрес. Примечание, Windows 2000 требует использования записей Service (SRV) (см. ниже).
Характеристики имени узла. Правила именования узлов DNS необходимо учитывать и в том случае, если требуется выбрать только одно имя, и тогда, когда надо присвоить имена тысячам компьютеров. В этой части изложены необходимые правила и советы по выбору имен.
Полностью уточненные доменные имена. Все компьютеры в Internet являются членами домена. В этой части описываются доменные имена, полностью уточненные доменные имена (имена узлов) и порядок их формирования.
Эта книга посвяшсна системе доменных имен (DNS) и предназначена как для новичков, так и для опытных администраторов DNS. В ней также рассказывается о новом сервере DNS в Windows 2000 и об использовании DNS в Windows. Никакие первоначальные знания в области DNS не являются необходимыми, но те, кто ими обладает, вполне возможно, откроют для себя много нового. Это сказано не потому, что мы убеждены в качестве предлагаемой здесь информации или в том, что в знаниях читателя есть пробелы.
Система Windows 2000 использует DNS так. как ни один более ран* ний продукт Microsoft, — фактически, как ни один продукт до этого. Хотя эта книга начинается с описания и разбора DNS "как есть'1, в качестве мирового стандарта, завершается она довольно полным обзором особенностей Windows 2000. Кроме того, здесь описывается использование BIND для Windows 2000, Windows 2000 DNS для окружения, отличного от Windows, новые особенности и характеристики DNS и обычные методы DNS с новыми интерфейсами.
Windows 2000 отводит DNS одну из самых важных ролей за счет поддержки доменного окружения Active Directory. Спросите сто профессионалов, имеющих опыт в развертывании Windows 2000, какие 10 вещей наиболее важны для того, чтобы "сделать все правильно", и примерно в ста ответах из тысячи будет фигурировать DNS. Начиная со стадий проектирования Active Directory вплоть до большинства рутинных ежедневных действий пользователя жизненные характеристики Windows 2000 тем или иным способом связаны с DNS.
Этот обзор начинается с DNS как таковой, ее определения, с того, как она работает, как используется в любой системе, будь то традиционная версия BIND или версия Windows 2000. Затем будут показаны особенности этой новой версии и рассмотрено большое число проблем и вариантов их решения в среде Windows,
Настоящая глава представляет DNS без каких-либо предположений об уровне вашей подготовки. Мы лишь допускаем, что вы что-то знаете о том, как компьютер работает и как он взаимодействует с Internet. Тем, кто хочет получить базовые сведения или обновить свои познания о DNS и серверах DNS, будет полезно прочесть эту главу. Здесь в общих чертах и в меньшей степени в подробностях объясняется, что такое DNS и как DNS заставляет серверы работать для миллионов пользователей компьютеров дома и в офисах по всему миру.
Регистрация, разрешение и распределение имен
Связь между компьютерами по протоколу управления переда- чей/протоколу Internet (Transmission Control Protocol/Internet Protocol, TCP/IP) осуществляется с использованием их IP-адресов. По этой причине IP-адрес необходим каждому компьютеру в Internet для его однозначной идентификации.
DNS де-факто является методом регистрации имен компьютеров и их 】Р-апресов. Сообщество Internet разработало DNS, чтобы дать любому компьютеру возможность определять местонахождение других по осмысленным именам, а не по зашифрованным IP-адресам. DNS — это развивающаяся служба, которая постоянно обновляется путем предложений в материалах Проблемной группы проектирования Internet (Internet Engineering Task Force, IETF) — проектах и документах Request for Comments (RFC) . В главах этой книги вы найдете указания о том, где можно найти эту информацию.
Не путайте сервер DNS с системой DNS самой по себе. Серверы DNS — это лишь инструменты системы доменных имен (или ее роботы, так сказать), которые выполняют повседневную работу, необходимую для функционирования доменной системы имен. В этой главе описываются и система доменных имен, и серверы DNS. Важно запомнить различие между ними.
Серверы DNS обеспечивают клиентам (отдельным пользователям, серверам приложений и даже другим серверам DNS) возможность сохранять и считывать имена узлов и IP-адреса других узлов. Узел (host) — это другое название компьютера или сети как единого целого, а имя узла — имя компьютера, под которым он фигурирует в системе доменных имен. Еше одна важная концепция ——понятие пространства имен (namespace). Пространство имен — это все пространство в Internet, составленное из уникальных и понятных для человека имен этих узлов.
Каждое имя узла и его IP-адрес хранятся на одном или нескольких серверах DNS, что позволяет любому человеку в мире, имеющему доступ к Internet, узнать IP-адрес узла просто по имени. Чтобы сделать это, серверы DNS должны надежно связаться друг с другом, чтобы соединить все ветви дерева доменных имен Internet в сложное дерево. Дерево доменных имен — это каркас пространства имен, по которому могут "лазать" серверы DNS. В главе 2, "Как работает DNS", подробно описано действие DNS и точно разъяснено, что такое пространство имен.
Возможно, самые важные понятия службы имен, которые вы должны уяснить, — регистрация и разрешение. Это необходимое условие для понимания имен DNS и серверов DNS. Но сначала кратко рассмотрим то, что мы будем регистрировать и разрешать: имена узлов и IP-адреса.
Имена узлов и IP-адреса
В файлах данных DNS имена ставятся в соответствие числам. Службы телефонных справочников напоминают DNS в том отношении, что они также являются системами, в которых записываются имена, соответствующие числам для идентификации абонентов.
Даже при том, что в записях DNS есть другие части и сама DNS устроена несколько сложнее, наиболее основная сфера использования DNS м ее самое важное значение для большинства пользователей — это способность находить соответствие между именами узлов и числовыми IP- адресами, с которыми они связаны, и по требованию выдавать эту информацию.
Регистрация имен узлов
Имена узлов и их IP-адреса должны быть зарегистрированы. Регистрация заключается в простом внесении имени и IP-адреса в каталог или список. Методы регистрации могут быть ручными или автоматическими, статическими или динамическими. В прошлом серверы DNS осуществляли первоначальную регистрацию узлов путем ввода вручную, т.е. узлы должны были быть записаны, или зарегистрированы, на сервере DNS человеком, который набирал данные на клавиатуре. Последняя тенденция — динамическая регистрация узлов, с обновлениями, которые инициируются протоколом динамической конфигурации узла (Dynamic Host Configuration Protocol, DHCP) или выполняются непосредственно самими узлами при динамическом обновлении DNS.
Регистрация DNS является ручной и статической, если не используется динамическая DNS наподобие той, которая имеется в Windows 2000. Обычно, если какие-то данные узла изменились, запись узла обновляется вручную. На рис. 1.1 показаны отдельные узлы, зарегистрированные на сервере DNS. К счастью, самая важная информация на сервере DNS — это просто имя и IP-адрес. (В главе 4, ''Подробная информация о домене", рассмотрены некоторые важные исключения.)
На рис. 1.1 не показано, как именно регистрируются имена узлов, поскольку это делается не одним способом. Регистрация вручную наиболее распространена, и сушествует несколько способов автоматической регистрации имен. Один из способов автоматической регистрации для DNS Server — обращение к серверу службы имен Internet для Windows (Windows Internet Naming Service, WINS). Взаимодействие DNS и WINS будет упоминаться на протяжении всей книги, а в главе 16, "WINS: традиционные службы имен и разрешение*', описываются сложные нюансы этого метода регистрации.
Другой метод автоматической регистрации выполняется, когда сервер DHCP регистрирует имена на серверах DNS, способных поддерживать динамическую DNS (DDNS). Серверы DHCP автоматически выдают имя IP и информацию адреса клиентам, когда они запускаются. Это самый
простой способ использования почти любого сервера DNS, поскольку он наиболее полно проверяется и поддерживается. После завершения регистрации (особенно в том случае, если разрешено уведомление) все серверы DNS получают эти регистрационные данные.
Рис. 1.1. Регистрация отдельных узлов на сервере DNSРис. 1.1. Регистрация отдельных узлов на сервере DNS
Рис. 1.1. Регистрация отдельных узлов на сервере DNS
Рис. 1.1. Регистрация отдельных узлов на сервере DNS
Большинство компьютеров вручную регистрируется на одном сервере DNS, который обычно находится в том же здании, университете или по крайней мере в той же организации. Средние и крупные организации всегда имеют собственные серверы DNS. Часто быстрее и проше отредактировать ваш собственный список узлов, чем каждый раз вызывать кого-то другого, например lntemet-провайдера (Internet Service Provider, ISP), чтобы внести изменение, В Windows 2000 или UNIX, если у вас есть внутреннее окружение, вы, скорее всего, будете вести DNS у себя,
Узлы должны быть зарегистрированы на одном "Ьервере DNS — основном. Дополнительные серверы автоматически получают все данные от основного сервера DNS. Администраторам это дает резервные копии и позволяет помешать серверы с одинаковыми базами данных в различных местах. Главный офис, например, может иметь основной сервер DNS; каждый из удаленных филиалов может иметь локальный дополнительный сервер для быстрого поиска и для зашиты от сбоев в сети, которые
могут сделать основной сервер недоступным. Это позволяет всем серверам находить узлы, имена которых были зарегистрированы, и делать это рядом с клиентами, которые будут использовать эти имена. Если DNS в вашей сети вышла из строя, то, будь то Windows 2000 или что-то другое, последствия будут ката строф и чес к им и в плане доступности ваших узлов. Вероятнее всего, вы захотите установить несколько серверов DNS. Вы также получите определенное выравнивание нагрузки, если определение IP-адресов некоторых компьютеров будет производиться дополнительными серверами.
Записи ресурсов адресов узлов
Основная цель регистрации имени, независимо от того, как она производится, —записать имя узла и его IP-адрес на место, доступное другим компьютерам, которым необходима эта информация. Такая запись называется записью ресурсов (resource record, RR). RR могут быть многих разновидностей, которые более подробно описаны в главе 4.
На рис. 1.2 показаны записи узлов нескольких компьютеров в том виде, в каком они отображаются на консоли управления DNS Windows 2000,
')20 7 33 46 =')20 7 33 46 =I jJMcneTuep chcicmh иоменных имен.臼回电¥I jJMcneTuep chcicmh иоменных имен.臼回电¥DNS Внд^^Ларанетры £лревк&：DNS Внд^^Ларанетры £лревк&：Рис. 1.2. Вид записей адресов узлов (А)Рис. 1.2. Вид записей адресов узлов (А)
')20 7 33 46 =
')20 7 33 46 =
I jJMcneTuep chcicmh иоменных имен.臼回电¥
I jJMcneTuep chcicmh иоменных имен.臼回电¥
DNS Внд^^Ларанетры £лревк&：
DNS Внд^^Ларанетры £лревк&：
Рис. 1.2. Вид записей адресов узлов (А)
Рис. 1.2. Вид записей адресов узлов (А)
Если используется UNIX DNS Server с текстовыми файлами конфигурации, записи узлов могут выглядеть как показано ниже (IN означает Internet, а А — адрес). В случае Windows 2000 DNS информацию также можно хранить в таких файлах, но это необязательно, В первом столбце записаны имена узлов, во втором — тип записи (в данном случае Internet), в третьем — тип записи ресурсов (А — адрес), и в четвертом столбце — 1Р-адрес.
hostlINА207.33.46.51
host2INА207.33.46.52
host3INA2c7.33.46.S3
hostflINA207.33.46.54
Разрешение имен узлов
После регистрации имя узла должно быть проанализировано, или разрешено. Разрешение — это клиентский процесс поиска зарегистрированного имени или службы для определения их IP-адреса. После того как клиент получит IP-адрес узла назначения, он может связаться с ним напрямую в локальной сети или через один или несколько маршрутизаторов в сети удаленного доступа.
Может показаться очевидным, что для множества зарегистрированных узлов обычно используется один сервер DNS. Однако не имеет значения, как этот факт влияет на сущность разрешения других узлов, также зарегистрированных на этом сервере. В организациях с тысячами узлов всегда имеется лишь несколько серверов DNS.
На рис. 1.3 показано, как клиент DNS разрешает имена других узлов, записанных на сервере DNS, на котором зарегистрирован он сам.
Распознаватели
Из описаний запросов имен в этой главе может показаться, что серверы DNS выполняют всю работу по разрешению имен. Давайте проясним этот момент. В действительности главное действующее лицо здесь — невидимая программа-распознаватель, которая действует на всех компьютерах с поддержкой DNS, использующих TCP/IP. Распознаватели преобразуют совместимые описания путей, включающие доменные имена узлов в сети, в запросы. Распознаватели даже могут запоминать найденные ранее узлы, что ускоряет соединение.
Распознаватели присутствуют везде, при локальном и при удаленном доступе, на клиентах и на серверах DNS. Серверы DNS применяют распознаватель для запросов других серверов DNS, когда обращаются к ним, что бывает довольно часто. Если клиент DNS действует как клиент, используется его распознаватель. Если сервер DNS действует как клиент, используется его распознаватель. Если сервер DNS действует как сервер, он отвечает на запрос распознавателя клиента, при этом клиент может быть другим сервером DNS.
RFC
Международные органы стандартизации и добровольные регламентирующие организации контролируют Internet совместно. Эти организации используют RFC и рабочие комитеты для открытого исследования идей новых стандартов, поступающих от профессионалов и предпринимателей. Некоторые RFC становятся стандартами Чтобы просмотреть RFC, посетите Каталог ресурсов служб доменных имен (Domain Name Services Resource Directory) на www.dns.net/dnsrd/.
Право устанавливать стандарты для DNS, протоколов Internet и самой Internet имеют следующие организации.
Архитектурный совет Internet (Internet Architecture Board, IAB).
Агентство по выделению имен и уникальных параметров протоколов Internet (Internet Assigned Numbers Authority, IANA), www. iana. org.
Исполнительный комитет IETF (Internet Engineering Steering Group, 1ESG), www .ietf.org/iesg. html.
Проблемная группа проектирования Internet (Internet Engineering Task Force, IETF), www.ietf.org.
Общество Internet (Internet Society, ISOC), www.isoc.org
Информационный центр сети Internet (Internet Network Information Center, InterNIC), www.internic.net
Рис. 1.3. Клиент DNS запрашивает сервер DNS для разрешения имени узла
RFC 1034 "Доменнме имена: понятия и характеристики" определяет, что распознавателям необходим доступ по крайней мере к одному серверу имен, чтобы получить информацию напрямую или произвести запрос, используя направления на другие серверы имен. RFC 1034 (стр. 5 и 6) гласит: ''С точки зрения распознавателя система домена состоит из неиз-
вестного количества серверов имен. Каждый сервер имен занимает один или более участков на дереве данных домена''.
Распознаватели, как правило, должны возвращать после запроса один из следующих результатов.
Одну или несколько записей ресурсов (RR), содержащих требуемые данные. В этом случае распознаватель возвращает ответ в соответствующем формате.
Ошибку имени (name error, NE). Это происходит, если запрашиваемого имени не существует. Например, пользователь ввел имя узла с ошибкой.
Ошибку "Данные не найденьГ (data not found). Это случается, если запрашиваемое имя существует, но данных соответствующего типа нет.
Распознаватели помешаются на том же компьютере, что и программа, которая к нмм обращается, но могут обращаться к серверам имен на других узлах. RFC 1034 (стр. 28) гласит: 11 Поскольку распознаватель может потребовать обращения к нескольким серверам имен или может хранить запрашиваемую информацию в локальном кэше, время, затрачиваемое распознавателем для завершения своей работы, может значительно варьироваться — от миллисекунд до нескольких секунд.,?
Обратный поиск
До сих пор наши рассуждения касались того, как DNS отображает имена на IP-адреса. Но она может также отображать IP-адреса на DNS. Поскольку файлы данных на серверах DNS автоматически упорядочиваются, или индексируются, для быстрого поиска имен, обратный поиск по IP-адресам также требует особого упорядочения базы данных по IP- адресам. Обратный поиск иногда называют обратным запросом.
База данных, которую серверы DNS используют для обратного поиска, называется зоной in~addr.arpa, или зоной адресов Internet в домене агра. Внимательно взглянув на рис. 1.2, внизу области, относящейся к серверу имен, можно увидеть зону 4 6.33.2 07 . in-addr. агра. Эта зона in-addr содержит базу данных IP-адресов, отображаемых на имена, которые сервер может использовать при поиске имени по IP-адресу. В главе 4, где рассматриваются записи указателей на адреса (PTR), рассказано, как построено такое обратное отображение.
Обратный поиск не настолько полезен, как прямой, но иногда он встречается. В основном обратный поиск выполняется для определения имени локального узла, если пользователь, например системный администратор, уже знает его IP-адрес. На практике обратный поиск служит для определения полностью уточненного доменного имени (fully qualified domain name, FQDN) известного IP. Серверы протокола передачи файлов (File Transfer Protocol, FTP) иногда прибегают к обратному поиску дня проверки того, действительно ли соединяющиеся узлы те, за которые они себя вы-
дают. В другом случае для реализации функции обратного поиска служат такие утилиты, как nslookup (см. главу 12, "Средства поиска неисправно- сте认")• Эта методика — лишь еше один способ выявления обмана или других противоправных действий со стороны подключающегося компьюте- g. Она помогает ослабить (но не устранить) попытки проникновения.
Порядок просмотра серверов DNS
Можно определить, какой сервер клиент DNS должен просматривать в первую очередь, во вторую и так далее для разрешения имени. На рис. 1.4 показан порядок просмотра, используемый клиентом Windows 95. Первый сервер DNS, указанный в списке, 192.168.1.24, — тот, на котором зарегистрирован сам клиент как член домена example. net. Если клиенту не удается получить ответ от первого сервера в списке, он запрашивает второй и затем третий серверы. Настройки клиента Windows 2000 позволяют внести в этот список значительно больше серверов. В главе 14, "Настройка и разрешение клиентов Windows", довольно подробно описано конфигурирование различных версий клиентов.
Сервер DNS, на котором должны быть зарегистрированы ваши клиенты, —основной сервер для их домена, и многие администраторы устанавливают для сервера просмотра своих клиентов IP-адрес этого же сервера. Но нет никакой причины, по которой просматриваемый сервер Должен быть тем же, что и основной сервер или сервер регистрации. Фактически дополнительные серверы, как правило, специально предназначены для использования клиентами. Если при динамической регист- 承иин DNS клиент пытается зарегистрироваться на дополнительном сервере, последний направляет его на основной для этого клиента, так что
вреда от этого нет. Существует много стратегий для типов серверов, предназначенных для различных целей, как показано ниже.
Порядок просмотра целиком предоставляется на ваше усмотрение. Серверы DNS, которые компьютер запрашивает для разрешения, и серверы DNS. на которых он зарегистрирован, могут быть не одними и теми же. Второй и третий просматриваемые серверы также могут быть любыми, даже серверами из другого домена, серверами имен Intemet-провайдера или любыми другими, которые будут быстро отвечать на запросы. Просмотр списка останавливается, как только сервер возвращает ответ.
Распределение имен узлов
Имена всех узлов на свете хранить на одном сервере DNS невозможно. Расстояние между вами и этим главным сервером DNS, если бы он существовал, было бы слишком большим, а размер базы данных — невообразимым. Представьте себе мощность компьютера и пропускную способность каналов, которые потребовались бы, чтобы единственный центральный сервер DNS работал для всей Internet. К тому же: если главный сервер DNS вышел из строя, вся Internet по всему миру также выйдет из строя! Вместо этого имена узлов распределяются среди множества серверов DNS.
Распределение имен решает одну, но создает другую проблему для клиентов. Как клиенту узнать, какой сервер DNS следует запрашивать? Система доменных имен решает м эту задачу, используя нисходящую структуру дерева имен узлов, в которой каждый узел — это лист на какой-нибудь ветви и каждая ветвь носит имя домена. Важно понять, что каждый компьютер, который будет у вас. связан с доменом.
В таком случае, сколько же нужно серверов DNS? Хотя фактическое количество неизвестно и меняется исходя из практических потребностей, теоретический минимум — один сервер DNS на каждую ветвь дерева доменных имен.
Если клиенту требуется IP-адрес другого узла, он обычно сначала запрашивает свой сервер DNS ——если это первый сервер по порядку просмотра. Если на этом сервере нет записи для искомого узла, как часто бывает, запрос передается вверх по иерархии серверов DNS, так сказать, высшему серверу. В конечном счете находится сервер, который может ответить на запрос. Для полного понимания этой взаимозависимости доменов и серверов DNS полезно представлять само дерево доменов как иерархию имен, показанную на рис. 1.5.
Каждый сервер DNS, если он по какой-то особой причине не изолирован, помешается где-нибудь в обшей иерархии доменов Internet между другими серверами. Ни один сервер DNS (как и человек) не является островом. Каждый их них выполняет обязанности службы доменных имен, пусть даже только для имен, относящихся к малой организации или к какой-то части большой.
Сервер DNS супердомена аСервер DNS супердомена аСервер DNS доменаbСервер DNS доменаbСервер DNS домена сСервер DNS домена сСервер DNS доменаdСервер DNS доменаdСервер DNSдоменааСервер DNSдоменааСервер DNSдоменаеСервер DNSдоменаеСервер DNS субдомена аСервер DNS субдомена аСервер DNS субдомена bСервер DNS субдомена bСервер DNS субдомена сСервер DNS субдомена с
Сервер DNS супердомена а
Сервер DNS супердомена а
Сервер DNS доменаb
Сервер DNS доменаb
Сервер DNS домена с
Сервер DNS домена с
Сервер DNS доменаd
Сервер DNS доменаd
Сервер DNSдоменаа
Сервер DNSдоменаа
Сервер DNSдоменае
Сервер DNSдоменае
Сервер DNS субдомена а
Сервер DNS субдомена а
Сервер DNS субдомена b
Сервер DNS субдомена b
Сервер DNS субдомена с
Сервер DNS субдомена с
Рис. 1.5. Все серверы имеют свое место в структуре имен
Частные серверы DNS
Серверы DNS могут работать в частных сетях, не соединенных с Internet. Можно даже физически соединить серверы с Internet, но не разрешить им выходить в общее пространство имен. Если частные серверы не изолированы, это может вызвать серьезные конфликты. Номера IP распределяются (см. главу 6, uРабота с провайдерами"), а доменные имена должны быть зарегистрированы (см. приложение Г, 11 Регистрация адресов в Internei").
Для создания частной сети надо изолировать ее от обшей сети и зарезервированные номера IP применять только для внутреннего пользования. Если вы используете номера IP, которые подвергаются маршрутизации и не присвоены вам, и затем пытаетесь соединиться с Internet, вам
придется преодолеть много проблем. Эти проблемы рассматриваются в RFC 1597, "Размещение адресов для частных ceтeй^^. Как и для обшей сети, для частных сетей также необходимы корневые серверы имен. Что такое RFC и как их получить, рассказано в приложении Б, "Документы RFC по DNS". Корневые серверы общего доступа описаны в RFC 2010, uКритерии работоспособности для корневых серверов имен1', а строение корневого сервера — в RFC 1034, 11Доменные имена: понятия и характеристики?,. Корневой сервер — это сервер, фактически находящийся или искусственно помешенный на вершину пространства имен DNS.
Характеристики имен узлов
В соответствии с наиболее строгими рекомендациями RFC Internet имена узлов домена (например, присвоенные компьютерам UNIX) могут содержать до 24 символов. Учтите, что компьютеры Windows могут носить два имени — имя сети Windows (NetBIOS) и имя DNS. На рис. 1.4 показана вкладка Конфигурация DNS свойств TCP/IP для Windows 95, на которой можно ввести имена узла и домена, но имя компьютера Windows здесь не фигурирует. Оно вводится во вкладке Идентификация и не может быть длиннее 15 символов. Имена Windows коротки и просты, например:
hostone hosttwo hostthree
Они могли бы быть длинными н сложными, как следующие, но тогда они не были бы восприняты вкладкой Идентификация, на которой отображается пространство имен NetBIOS.
hostl-ol2s-3t4n5a6m7e8-l host2-o23s-4t5n6a7m8е9-2 host3-o37s-8L9nQalm2e3-3
Наилучший способ разрешить эту дилемму — выбрать имя, которое удовлетворяет критериям как пространства имен домена, так и пространства имен NetBIOS. Это означает, что имя должно быть коротким, 15 символов или менее, и содержать только символы, разрешенные в обоих пространствах имен. Если присвоить имя длиннее 15 символов, Windows 2000 сократит его для использования в NetBIOS.
Для серверов м других часто используемых узлов следует выбирать имена, которые легко запоминаются. Простые, функциональные имена — наилучший вариант. Перед тем как строить DNS, можно составить интуитивное соглашение об именах для рабочих станций пользователей, например tcarter-pc для персонального компьютера Трента Картера, hknief- ws для рабочей станции Германа Найфа и т.д. Серверы также должны следовать этому соглашению для имен. Сначала можно выбрать круг понятий, из которого будут выбираться имена. Таким образом создаются ассоциации для легкого запоминания всех подобных узлов, например titanic,
enterprise и mayflower — по названиям судов или paris, munich и seattie — по названиям городов. Пользователи нового узла были восхн- ^ены, когда я дал их новым принтерам имена вулканов. Это прекрасно для небольшой организации, но, если она вырастает и вам все еще приходится делать эту работу, потребуется создать субдомены (и чем больше размер сети, тем вероятнее, что придется перейти на стандартное соглашение об именах, которые станут непонятными для пользователей).
Кстати, InterNIC, или NIC, как ее иногда называют, — организация, управляющая регистрацией доменных имен. В приложении Г рассказано, как зарегистрировать новый домен в NIC.
Имена узлов IP
Сообщество Internet выработало определенные правила именования узлов. Если вы не будете тщательно следовать им, это может создать проблемы для пользователей и приложений, которые попытаются получить доступ к вашим компьютерам. RFC 952 — это обязательный стандарт, определяющий правильные имена узлов и указывающий, что делает имена правильными или допустимыми. Документ RFC 1035 "Реализация и спецификация доменов" также обязателен. Ниже приведены некоторые практические правила именования, взятые из RFC 952.
Имя ——это текстовая строка длиной до 24 символов, которые могут быть буквами латинского алфавита (A—Z), цифрами (0—9). знаком "минус" (—) и точкой (.). Точки разрешаются лишь для разделения компонентов имен вида доменов; это означает, что нельзя ставить ючки внутри фактического имени узла. Учтите, что ограничение длины 24 символами взято из RFC 952 и не является требованием Windows. Если не изменить условия, принятые по умолчанию, DNS нечувствительна к регистру.
В имени не допускаются пробелы.
Прописные и строчные буквы не различаются.
Первый символ должен быть буквой.
Последний символ не может быть знаком "минус" или точкой.
Имена из одного символа не допускаются.
Некоторые имена не удовлетворяют этому стандарту. Например, 3com.com явно нарушает правило, согласно которому первый еммвол не может быть цифрой- Хотя имеются некоторые противоречия между документами RFC и реально существующими отступлениями от стандартов, лучше соблюдать их настолько строго, насколько это возможно. Имена доменов в основном следуют тем же правилам.
RFC 1035: рекомендации по именованию узлов
RFC 1035 ^Реализация и спецификация доменов" предлагает очень полезные правила именования доменов, если вам знаком формальный синтаксис компьютерных языков. Ниже приведена выдержка со стр. 6 и 7 этого документа.
2.3. Соглашения
В системе доменов существует несколько соглашений, касающихся проблем низкого уровня, но фундаментальных. Хотя разработчик может нарушать эти соглашения в своей системе, он должен следовать им во всех отношениях, соблюдаемых другими узлами.
Рекомендуемый синтаксис имен
Спецификации DNS для построения доменных имен составлены как можно более общими. Идея состоит в том. что название любого существующего объекта может быть выражено в доменном имени с минимальными изменениями.
В то же время при назначении доменного имени объекту предусмот- рительнь(й пользователь выберет такое имя, которое удовлетворяет как правилам системы доменов, так и любым существующим правилам для объекта, независимо от того, опубликованы ли они или подразумеваются в существующих программах.
Например, при именовании домена почты пользователь должен соблюдать как данные правила, так и правила, оговоренные в RFC-822. При создании имени нового узла надо следовать старым правилам для HOSTS. TXT. Это позволит избежать проблем при преобразовании старого программного обеспечения для работы с доменными именами.
Следующий синтаксис создаст меньше проблем со многими приложениями, использующими доменные имена (такими как почта и Telnet).
<domain> ：：= <subdomain> I ? ?
<subdomain> ::= <label> | <subdomain> ?.? <label>
<label> ::= <letter> [[ <ld"-slr> ] <let-dig> ]
<ldh-str> ::= <let-d丄g-hyp> | <let-dig-hyp> | <ldh-str>
<let-dig-hyp> ：：= <let-dig> I ?-?
<let-dig> ::= 〈letter〉 | <digit>
<letter> ::= любая из 52 букв латинского алфавита:
A-Z в верхнем регистре и a-z в нижнем
<digit> ::= любая из цифр 0-9
Учтите, что, поскольку в доменных именах разрешены как прописные, так и строчные буквы, регистру не придается никакого значения. Иными словами, два имени с одним и тем же написанием, но в разном регистре рассматриваются как одинаковые.
Более подробные сведения о правилах создания допустимых доменных имен можно найти в RFC 1123 и 1912. Хорошие источники по всем документам RFC Internet — www. isi . edu/rfс-editor/ и www.merseyworld.com/techwatch/standarts/.
Имена компьютеров Windows (NetBIOS)
Имена компьютеров Windows должны содержать до 15 символов, что- 6м удовлетворять ограничению длины NetBIOS. Регистр не влияет на уникальность имен: Host-One, HOST-ONE и host-one эквивалентны для компьютеров Windows и UNIX. Имена компьютеров Windows могут содержать символы, недопустимые в DNS.
Возникают проблемы, если имена с недопустимыми символами регистрируются в DNS — вручную или с помощью автоматической функции WINS, описанной в главе 16. Компьютеры Windows должны использовать только допустимые для DNS символы, тогда никаких сложностей не возникнет. Ниже приведены имена, правильные для WINS, но недопусти- мме для большинства серверов DNS.
lisAnuiriber (начинается с цифры, что не разрешается в DNS) under_score (знак подчеркивания не разрешается в DNS) space ghost (пробел не разрешается в DNS).
Хороший совет: используйте для компьютеров Windows только допустимые в DNS символы. При передаче/обновлении данных может понадобиться держать в памяти две разные схемы именования, но можно попытаться избежать этого.
Полностью уточненные доменные имена
Имена узлов не являются по-настояшему завершенными, если они не включают домен, к которому относится узел. Конечно, если вы используете компьютер в том же домене, что н узел, который вы ишете, ваш распознаватель, вероятно, прибавляет доменное имя на основе полезного предположения, что вы находитесь в том же домене. Если же искомый компьютер находится в другом домене и DNS не может найти его, возможно, вы используете неуточненное доменное имя, которое не содержит данных о принадлежносги к домену. Многие операционные системы предоставляют средства, позволяющие настроить для себя ход этого процесса предположений и добавлений.
FQDN ——это имя узла плюс полный путь, в котором перечисляется принадлежность ко всем доменам. Доменные имена объединяются в перечень, чтобы точно показать логическое местонахождение узла. Иными словами, FQDN — полностью выраженные имена узлов, не оставляющие ничего недосказанным. FQDN отражают направления, ведущие на самый Верх дерева доменов, откуда "растут" все домены и узлы. Например, FQDN Web-сервера фирмы acmecompany может быть www. acmecompany. con, Или, если узел www располагается в субдомене отдела продаж (sales), его FQDN может быть www. sales. acmecompany. ссгг.. Имена наподобие acmeccmpany, а не acmecompany. иногда относительны, и, строго говоря, только форма с завершающей точкой (.) является именем FQDN. Это различие очень важно для понимания и управления процессом разрешения. Завершающая точка фактически обозначает самый корень дерева доменов.
Имена FQDN удобны в работе. Например, электронная почта использует полностью уточненные доменные имена в адресе получателя. Так, janicejonesGacmecompany. сот содержит имя адресата, 21 anice j ones, за которым вводится символ 0. За @ следует FQDN или псевдоним почтового сервера, в данном случае название домена организации, в котором находится почтовый сервер, а за ним — его домен верхнего уровня: . сот. Домен . сот означает, что acmecompany является коммерческой организацией.
Выбор доменного имени
Выбор доменного имени может быть трудной задачей. С ростом популярности Internet в последние годы некоторые лица извлекают большую прибыль, спекулируя доменными именами. Эти люди зарегистрировали на себя много доменных имен в надежде, что кто-нибудь менее удачливый создаст компанию и попытается законно зарегистрировать такое же доменное имя. Если это доменное имя уже зареги стр и рова но, ему придется выбрать другое или попытаться утоворить владельца этого имени ...обычно с выгодой для последнего. Готовясь к регистрации доменного имени, найдите время, чтобы подумать о нескольких хороших именах, предпочтительно таких, которые имеют значение для предполагаемого применения. Попытайтесь остаться в границах, установленных для доменов верхнего уровня (top-level domain, TLD), Использование доменов , com для коммерческих организаций, . net ——для организаций, связанных с сетью, или провайлеров, н . org — для некоммерческих или общественных организаций уже практически не ограничивается. При грамотном применении TLD у организаций появляется много возможностей использовать схожие имена, оставаясь при этом достаточно отличными друг от друга в соответствии со своей целью или назначением. Регистрировать домены _edu для образовательных организаций, .gov и .mil для правительства или военных могут только установленные организации. Дополнительные TLD, такие как . law, .inc, .mail, .games, . learn и так далее, дают еше больший простор для выбора, тем более что спекулянты еше не израсходовали их все. Использование акронимов — хороший вариант для доменных имен. Однако не забывайте, что чем короче доменное имя, тем больше вероятность, что кто- то уже зарегистрировал его.
Во многих отношениях регистрация домена похожа на попытку получить персональный номерной знак для автомобиля. Надо быть гибким и иметь некоторые способности к творчеству, чтобы придумать что-то уникальное. Если вы готовы к регистрации доменного имени, InterNIC имеет множество доступных средств, которые помогут в определении уникальных имен и процессе регистрации. Подробнее об InterNIC см. на www. internic. net. Также существует множество новых TLD, если вы этим интересуетесь. Рамки книги не позволяют заняться их перечислением. но эта информация свободно доступна в Internet.
I
IP-адреса
Каждый компьютер в Internet имеет 1Р-адрес. IP-адрес — это четыре числа в диапазоне 0-255, отделенных друг от друга точками, например 123.21,99.1 или 10.1.1.3. Индивидуальные IP-адреса могут присваиваться автоматически или вручную. Во многих случаях для DNS не имеет значения, каким способом они присваиваются. Может быть реализован новый стандарт IPv6; подробнее о нем вы прочтете в следующих главах этой книги.
Резюме
Данная глава представляет фундаментальные понятия DNS и некоторые правила именования. Остальная часть этой книги содержит информацию, необходимую для настройки и администрирования сервера DNS.
2
Как работает DNS
В этой главе...
Как работают серверы DNS, как они взаимодействуют друг с другом и как отвечают на запросы имен.
Иерархия узлов и доменов. В этом разделе показано, что пространство доменных имен похоже на дерево (иерархия имен компьютеров, относящихся к организациям). Мы познакомим вас также с тем, как субдомены делят пространство имен на поддающиеся управлению блоки и как делегирование определяет порядок запросов от одного сервера другим, если необходимо.
Домены и зоны. Взаимосвязь между доменом и сервером DNS может изменяться; не всегда каждому домену соответствует один сервер. Серверы DNS используют файлы зон, точно определяющие, какими доменами и узлами они управляют. Зоны обеспечивают администраторам DNS достаточную гибкость для того, чтобы заставить один сервер DNS обслуживать один или несколько доменов. части одного или нескольких доменов или их сочетания, В этом разделе представлены данные зон, лежащие в основе администрирования DNS.
Примечание. Некоторые серверы не используют файлов зон для хранения информации о зоне; дополнительные серверы могут просто держать в памяти динамическую копию данных, а серверы Windows могут хранить информацию о зоне в Active Directory-
Разрешение запросов клиентов. Что происходит, когда клиент посылает запрос имени? В этом разделе подробно рассматривается процесс разрешения запроса клиента с использованием примера запроса, а также рекурсивные и итеративные режимы запросов, которые могут использовать серверы DNS. На примере показано, как запрос поднимается по дереву имен DNS к корневому серверу и спускается по другой ветви, чтобы выполнить требование клиента.
Обзор инструментальных средств. В этом разделе описаны основные средства, позволяющие устранять проблемы, связанные с DNS, включая сбор данных, поиск неисправностей и т.д. Предлагается небольшой начальный набор средств для работы с DNS и ее изучения.
DNS ~ это удобное хранилище и расчетный центр для имен узлов и доменов в сети, рассматривающий каждое имя узла как символьный адрес, поскольку имена более привычны и легче запоминаются, чем числа.
Свойства клиента DNS наиболее сильно проявляются на уровне взаимодействия приложения и сетн, где, например, имена унифицированных указателей pecypcoB(URL) используются в броузерах для быстрого доступа к Web-страницам из любого места. На более низком уровне, уровне транспортировки, информация передается через сеть. Клиенты и серверы DNS применяют не требующий прямого соединения протокол передачи дейтаграмм пользователя (User Datagram Protocol, UDP) через порт 53 для запросов и ответов и протокол управления передачей (Transmission Control Protocol, TCP) через порт 53 для межсерверных соединений. Причина, по которой клиенты и серверы DNS используют не требующий прямого соединения UDP, проста. Поток данных, передаваемый по UDP, не требует определенного ответа; если коммуникатор не принимает необходимую информацию, распознаватель посылает ее снова, пока не получит ответ (см. раздел ''Разрешение запросов клиентов" ниже в этой главе). Напротив, для межсерверной связи мо杵т использоваться только протокол, ориентированный на соединение, как TCP, поскольку эти серверы должны ретранслировать важные данные записи ресурсов (RR) и упорядоченную информацию, которая лишь повторяется время от времени. Без этой информации серверы выпадают из синхронизации друг с другом и не могут надежно выполнять свою функцию.
Иерархия узлов и доменов
Когда Internet (которая первоначально называлась ARPAnet) была небольшой, для выполнения поиска узлов по сети распространялся один- единственный общий файл hosts. txt. С ростом Internet старая модель распространения файла узлов стала неадекватной. Архитектура DNS была разработана для замены старого, основанного на файле метода поиска узлов. DNS установила распределенную модель данных, напоминающую Дерево файловой системы, как показано на рис. 2.1. С точки зрения архитектуры DNS является распределенной, иерархической системой Управления базой данных клиент/сервер.
c：\
Рис. 2.1. Дерево DNS, как и дерево файловой системы, требует, чтобы имена на каждом уровне были уникальными
Древовидная модель является распределенной, поскольку каждый зарегистрированный домен предоставляет для поддержки общей архитектуры свои списки данных, как показано на рис. 2.2.
Рис. 2.2. Иерархия дерева имен DNS начинается с корневого домена
На вершине иерархии находится корень дерева доменов (обычно обозначаемый точкой “.")，состоящий из серверов имен корневого уровня, серверы имеют начальные указатели, ведущие вниз к доменам первОго уровня или доменам верхнего уровня (TLD), таким как . com, .org, 加土 1 и ■ edu. Кроме них, существует еще более 200 географических TLD, И'этот список продолжает расти. Первоначально TLD управлялись Агент- 0ТВОМ по выделению имен и уникальных параметров протоколов Internet (IANА), однако несколько TLD было передано для управления таким организациям, как Информационный центр сети Internet (InterNIC). InterNIC управляет остальными . com. .org、. net и .edu. Пространство доменов верхнего уровня расширяется вследствие большого количества регистраций в 80-х и 90-х гг. и продолжает изменяться. Мы попытались Представить широкий диапазон этих TLD в приложении В, "Домены Internet верхнего уровня".
Узлы в иерархии доменных имен могут существовать на любом уровне ниже корневого. Поскольку дерево имен является иерархическим, а не одноуровневым, имена узлов должны быть уникальными только на каждой небольшой ветви домена. Например, www может быть именем узла нескольких Web-серверов в одной и той же компании, если каждый компьютер находится на отдельной ветви в иерархии доменов. Так, www.xyz . com, www. corp. xyz . com и www.eng.xyz.com— допустимые имена, которые корректно разрешаются до уникальных узлов, хотя имена всех этих узлов одинаковы. Этот основной принцип также предусматривает единообразие в соглашениях об нменах для FTP-сайтов, Web-сайтов, серверов имен и т.д-
Серверы DNS корневого уровня очень похожи на серверы, используемые в корпорациях и образовательных учреждениях по всему миру, но отличаются тем, что располагаются на самом привилегированном в Internet месте, т.е. даже выше доменов первого уровня, таких как . сот и .org. В табл. 2.1 показаны важнейшие первые уровни в иерархии доменных имен.
Таблица 2.1. Иерархия доменных имен
Доменное имя
Положение в иерархии
Корневой уровень — домен без имени, обозначаемый завершающей точкой, которая обычно не изображается
♦ net
TLD — доменное имя первого уровня
example.net
SLD — доменное имя второго уровня
test-example net
Имя субдомена — организационного домена в другом домене
Есть простой способ запомнить уровни DNS: уясните, что корневой уровень обозначается только точкой (.), TLD имеют одно имя, а домены Второго уровня (second-level domain, SLD) — два имени.
Главное различие между серверами имен корневого уровня и уровня организаций состоит в том, что серверы корневого уровня указывают вниз, на все зарегистрированные SLD. например example.net или college. edu.
SLD бывают организационными или географическими, в зависимости от суффикса, или последней части доменного имени. Например, microsof t. com принадлежит корпорации Microsoft. Большинство доменных суффиксов прямо указывает на то, каким организациям они принадлежат.
■ Примечание
Домены первого уровня фактически находятся на втором уровне по отношению к корневому, хотя и называются TLD. Корневой домен часто не представляют как домен, несмотря на то, что в техническом смысле он является таковым. Относительно небольшое количество элементов домена корневого уровня существует исключительно для поддержки дерева имен и его функций.
Напротив, тип организации не всегда легко определить по суффиксу. Для примера возьмем домены .net и .org. Они не определены так однозначно, как коммерческий домен .сот. Домен .net, хоть и предназначался первоначально для Intemet-провайдеров (ISP) и других сетевых организаций, предоставлен большому числу научно-исследовательских проектов, таких как handle. net и giga. net.
Домен .org был выделен для использования некоммерческими и федеральными научно-исследовательскими организациями, однако применяется и такими государственными организациями, как Центр высокопроизводительных вычислительных систем (High Performance Computing Center, hpc.org) и Integration Technology Office (ito.org).
Субдомены
Домен, подчиненный другому домену, называется субдоменом, так что даже TLD фактически являются субдоменами корневого домена. Количество же субдоменов, подчиненных доменам второго уровня, огромно. Поскольку здесь располагается большинство субдоменов, "субдоменом" часто называют домен, находящийся в любом месте ниже SLD.
Организации создают субдомены для внутреннего пользования. East. isi. edu — субдомен isi . edu для Восточного (east) отделения Института информационных наук (Inibrmation Services Institute, IS1). Компании часто создают субдомены в соответствии с внутренней структурой корпорации. На рис. 2.3 в разделе 11 Домены и зоны" приведен пример такого подхода — выделение по одному субдомену для технического отдела (Engineering — eng), отделов маркетинга (Marketing — mkt), сбыта (Sales) и кадров (HR). Подобное разделение домена может повысить производительность почтовых серверов, серверов имен и других служб за счет распределения нагрузки между несколькими компьютерами во
внутренней сети компании. Выбор структуры ваших субдоменов целиком ^^доставляется на ваше усмотрение. Цель такого разделения — сниже- нне обшего трафика в сети и удовлетворение запросов независимо от тог®，откуда они поступают. Для Windows 2000 не является чем-то необычным использование структуры, подобной расположению контроллеров домена, и по подобным же причинам. Вам может понадобиться определить домены в границах локальной сети (LAN), чтобы минимизировать трафик в глобальной сети (WAN) или по крайней мере установить сервер имен для кэширования в каждой области LAN.
Домены в сравнении с субдоменами
Строго говоря, все домены под корневым доменом следует называть субдоменами, поскольку все они подчиненные. Однако такое понимание этого термина слишком широко и недостаточно выделяет верхние уровни. Обычно администраторы называют субдоменом любой домен ниже второго уровня, т е. такой, который содержит три или более имен, разделенных точками. Это позволяет отличить TLD, которые более постоянны, от доменов третьего, четвертого и низших уровней
Практически к доменам корневого, первого и второго уровней относят твердо установленные домены наверху дерева имен, а к субдоменам — домены ниже второго уровня.
Делегирование
Таким образом, мы подходим к вопросу о назначении делегирования — формального метода распределения нагрузки между несколькими серверами в домене, например между родительским доменом н его дочерними доменами, или субдоменами. Основной сервер (или серверы) имеет высшие полномочия (Start of Autority, или SOA в терминах DNS) для домена. Он наделен исключительным правом отвечать на все запросы для своего домена или делегировать некоторые из своих полномочий другим серверам.
Каждый TLD фактически является небольшой частью корневого домена и, в свою очередь, делится на SLD. Делегирование — это метод, используемый серверами корневого уровня для разделения ответственности со всеми остальными серверами имен. В результате распределяются полномочия для всех опубликованных в Internet имен узлов. Такое распределение реализует ключевую концепцию DNS. Ни один отдельный Сервер не может вызвать сбой. Серверов корневого уровня может быть не меньше, а возможно, и столько же, сколько серверов верхнего уровня, Включая и ваш домен.
Если один сервер DNS не в состоянии ответить на запрос, он может автоматически направить клиента к другому серверу, который был делегирован соответствующим доменом. Субдомены часто рассматриваются Как делегированные серверы. Делегирование определяет, какие серверы имеют приоритет для запрашиваемого имени, а также какие серверы за-
прашиваются во вторую очередь, если необходимо. Если авторитетный для вашего домена сервер не дает ответа на запрос, то этого ответа либо не сушествует в вашем домене, либо он существует еше где-то в другом домене; в этом случае необходимо указание, куда послать запрос (это может быть вышестоящий уровень в дереве). Делегирование объявляет авторитетные серверы имен для домена; однако в действительности большую часть запросов надо послать от клиента только на один сервер. Если клиент (распознаватель) получает авторитетный ответ, указывающий, что узла или домена не существует, он немедленно прекращает поиск. Распознаватель больше не использует делегирование, и не имеет значения, со сколькими серверами из своего списка просмотра он связывался до этого.
Делегирование может происходить в направлении от серверов корневого уровня, находящихся на вершине DNS, вниз к серверам верхнего уровня DNS. Серверы субдоменов DNS регистрируются в родительском домене с помощью записей серверов имен (Name Server, NS). Организации регистрируют свои SLD и серверы DNS в InterNIC для делегирования серверами TLD. Как было показано выше, ваш SLD может делегировать на несколько уровней вниз.
Делегирование может быть направлено в сторону или вниз. Делегирование в сторону определяет другие серверы того же уровня, разделяющие полномочия на одном уровне домена, а делегирование вниз определяет субдомены (см. приложение В). Любой общий сервер DNS может быть делегирован сервером DNS верхнего уровня как один из его многочисленных субдомеиов.
Делегирование сервера имен производится с помощью записи NS. (В главе 4, ^Подробная информация о домене", рассмотрены записи NS и показано, как с ними работать.) Записи NS определяют список авторитетных серверов для домена. Например, чтобы задать субдомены для организации, следует выполнить делегирование от родительского домена субдоменам. Если не сделать этого, никакой внешний компьютер не сможет разрешить эти субдомены.
С точки зрения распознавателя клиента DNS все выглядит так, как если бы все зарегистрированные адреса узлов были локальными для своего сервера DNS. Но это только видимость. Делегирование сообщает локальному серверу DNS, как найти узлы, не принадлежащие ему, что делает возможным разрешение адресов за пределами их домена.
Домены и зоны
Осмысление различия между зонами и доменами может потребовать некоторых умственных усилий. Дерево имен доменов DNS имеет ветвь, соответствующую именам домена, и листья, соответствующие именам узлов. На этом дереве субдомены и узлы являются составными частями всех доменов над ними.
Зоны логически объединяют части структуры DNS, определяя имена, поддерживаемые каждым сервером DNS, Зона вашего сервера DNS определяет имена, которые он охватывает на дереве имен, его область или Те домены (не один домен!), в отношении которых он имеет полномочия.
На рис. 2.3 口оказан сервер, имеющий зону полномочий, которая включает домены mkt и sales. Сервер DNS может также иметь один домеН В одной зоне. Домен eng на рис. 2.3 — пример зоны, содержащей Один домен, хотя этот домен имеет два субдомена. Поскольку зоны Windows 2000 служат для размещения непрерывной ветвя, для которой М(?*ет потребоваться, чтобы домены mkt и sales находились в разных зонах, общие правила разбиения на зоны несколько другие.
Рис .2.3. Зоны определяют доменные имена, которыми управляет сервер DNS
Зоны и делегирование необходимы для возможности взаимодействия Между серверами и клиентами DNS, поскольку зоны определяют, где хранятся имена (т.е. какой сервер DNS их содержит) и по какому пути клиенты и серверы должны соединяться с другими серверами DNS.
Зона может содержать записи для домена, части домена, одного или нескольких субдоменов или сочетания родительского и дочерних доменов. Записи для нескольких доменов особенно полезны для особого класса зон обратных адресов, применяемых для разрешения имен по IP- адресам. Зоны обратных адресов описаны в главе 4 в разделе Записи указателей (PTR) и обратный поиск".
Зоны дают серверу DNS, так сказать, выборку имен, которыми он должен управлять, а делегирование сообщает серверу DNS, где надо нс- йать, если запрос не относится к его зоне. Ни зоны, ни делегирование не определяют, какой сервер DNS имеет полномочия быть первоначальным Источником записей домена и какие серверы являются резервными. Назначение сервера SOA основным, или SOA, дает ему эти полномочия, а Назначение сервера дополнительным, или NS, делает его резервным по Отношению к основному серверу.
Основные серверы DNS
Как было показано выше, основной сервер DNS (сервер SOA) имеет приоритет для имен в своем домене и является единственным, из которого извлекается информация об именах в этом домене. Когда основной сервер запускается, он получает данные зоны из локальных данных в файлах (или в Active Directory) на узле, на котором он работает. Сервер DNS может быть основным сервером для нескольких доменов одновременно. Типы серверов DNS подробно рассматриваются в главе 3, "Типы серверов имен". Только серверы DNS могут быть основными, поскольку сервер DNS, по определению, является авторитетным источником имен домена.
Настройку иерархии доменов для организации лучше всего начать с настройки основного сервера для всего домена. Зона, которой управляет ваш сервер, должна содержать все имена доменов для этой зоны. Если сервер не содержит всех записей для этого домена, следует делегировать полномочия субдоменам (example. net разделяется на sales . example. net, ops . example . net, eng . example . net и Т.Д.).
Выбор варианта с субдоменами повышает гибкость. Кроме того, увеличивается возможный объем работы, поскольку каждый субдомен мо*е【 иметь высшие полномочия; поэтому каждый раз при совершении изменений их надо Производить на назначенном основном сервере. Microsoft иногда применяет термин "зона" не по смыслу. Как разработчик, вы должны быть осторожны с его употреблением.
Дополнительные серверы DNS
Дополнительные серверы получают данные от основных серверов. Когда дополнительный сервер запускается, он в первую очередь соединяется с сервером, от которого получает данные зоны, а затем сравнивает его версию данных с первоначальной. Если необходимо, дополнительный сервер выполняет передачу зоны, копируя данные зоны с основного сервера к себе. Дополнительный сервер "знает" свой основной, поскольку его имя записано в файлах вместе с записями ресурсов SOA и NS. Дополнительный сервер представлен только записью NS и не несет ответственности SOA, поскольку эту роль может играть только основной сервер. Конечно, если дополнительный сервер еще не имеет данных зоны, он должен использовать команды в своем файле инициализации, чтобы определить свой главный сервер, от которого он должен получить данные.
Подобно основным серверам DNS, дополнительные серверы авторитетны при поиске доменных имен. Различие между ними в том, что основные серверы являются первоисточником доменных имен для остальных серверов DNS, которым необходим импорт файлов зоны, тогда как дополнительные серверы лишь выполняют резервные функции и поддерживают запросы.
Перемещение данных с основных серверов DNS на дополнительные
Теперь, когда вы получили некоторое представление о доменах, зонах й делегировании, можно перейти к рассмотрению распределенной модеЛИ базы данных, по которой построена DNS. Файлы зон, по существу, являются таблицами базы данных имен DNS, а основной сервер хранит исходный файл (или файлы) зоны для своего домена (или доменов).
Вспомните, что серверы имен субдоменов могут играть роль основ- ННХ, эффективно разбивая большой список имен домена на меньшие чаСти в отдельных файлах зон. Если большая организация установит свои серверы имен в одном большом домене без субдоменов, файлы зон также будут большими. Большие, одноуровневые пространства имен создают и дфугую проблему: неразделенная ветвь DNS не может поддерживать два одинаковых имени узлов. Не разделяя домены, крупная организация может быстро создать для них ту же проблему, которая встала перед ARPAnet, когда в ней попытались создать архитектуру DNS. С другой стороны, та же большая организация может разделить свое пространство имен на субдомены, используя лишь один файл зоны, как показано на рис. 2.3. Это решает только одну из двух проблем.
Разделение доменов также может повысить производительность за счет сохранения малого размера и управляемости файлов зон. Серверу имен не придется анализировать огромный файл зоны. Хотя другие факторы тоже имеют значение, в общем справедливо, что чем меньше файл зоны, тем быстрее сервер имен отвечает на запрос. В то же время создание субдоменов представляет собой практическую проблему. Делегирование решает часть проблем, согласуй взаимоотношения между родительскими и дочерними доменами (субдоменами). Как дополнительный сервер имен получает данные из первоисточника — главного сервера имен? Ответ на этот вопрос — перенос файла зоны соответс гвуюшего сервера. Этот процесс также называется передачей зоны (zone transfer). Передача зоны может быть частичной или полной, в зависимости от потребности и Времени, истекшего после последней полной передачи зоны. Разбиение больших файлов зон на меньшие зоны также ускоряет передачу зон Это Лишь несколько причин, по которым следует избегать больших, одно- Й>овневых пространств имен.
Когда основной сервер имен начинает работать, он лишь должен начать отвечать на запросы службы имен. Когда же запускается дополнительный сервер, он должен найти на главном сервере (часто это основной сервер) авторитетные данные; затем он получает путь и имя файла, в котором он Должен сохранить свою локальную копию данных после их получения. Эти Сведения содержатся в данных инициализации сервера, которые описаны в Главе 4. Если дополнительный сервер имен запускается в первый раз или Кто-то очистил его каталог данных, дополнительный сервер посьыает своему главному серверу запрос на копию файла зоны.
Передача зоны очень похожа на копирование файла в Windows (NT или 2000) или копирование в этих системах данных службы имен Internet для Windows (Windows Internet Naming Service, WINS) между партнерами службы имен. Если дополнительный сервер имеет копию файла зоны основного сервера, он также может начать выдавать авторитетные ответы на запросы имен. Но что происходит, если файл зоны основного сервера изменяется или обновляется? Запись ресурсов SOA содержит информационные поля, определяющие, как часто дополнительные серверы должны запрашивать основной об изменениях. Эти поля устанавливают срок действия, лимит времени и частоту обновления данных. Запись SOA также имеет номер версии, или серийный номер. Подробнее о записях ресурсов SOA см. в главе 4.
Дополнительный сервер периодически запрашивает у основного файлы зон, которые подлежат обновлению, если серийный номер (автоматически увеличивающийся индикатор версии базы данных) изменился. Если это так, дополнительный сервер знает, какие данные в зоне изменились, и начинает передачу (частичную либо полную) требуемой информации Частичные передачи — это добавочные передачи, описанные в RFC 1995. при которых передаются только изменения, а не вся зона.
Дополнительный сервер выполняет передачу зоны, только если серийный номер увеличился. Если по какой-то причине серийный номер уменьшился, дополнительный сервер считает, что его копия зоны более новая, и продолжает использовать локальную копию, пока не кончится срок действия зоны. Если же по какой-то причине серийный номер обнуляется, локальный файл зоны на дополнительном сервере удаляется и дополнительный сервер начинает перенос всего файла данных зоны с главного сервера. Дополнительный сервер может получить данные зоны от основного или от другого дополнительного сервера, но во всех случаях говорится о получении данных от главного сервера.
Как Windows 2000 DNS Server, так и BIND версии 8 имеют возможность уведомления (notify), инициирующего передачу. Механизм уведомления описан в RFC 1996. Его идея состоит в том, что главный сервер немедленно извещает дополнительные серверы об изменениях, чтобы ускорить распространение новой информации. Уведомление увеличивает безопасность, поскольку все передачи зон может начинать основной сервер. Поскольку администратор основного сервера публикует список уведомляемых дополнительных серверов, их круг ограничивается только надежными узлами. Если сделать так, чтобы все процессы переноса данных инициировались основными серверами, а не дополнительными, можно уберечь файл зоны домена от несанкционированной передачи. Таковы убедительные причины, по которым следует использовать уведомление. С другой стороны, некоторые серверы BIND 8.1.1 известны тем, что сбрасывают свое ядро при принятии передачи от Windows 2000 DNS; поэтому при использовании таким способом дополнительных серверов BIND их версия должна быть не ниже 8.1.2.
Организации, которым необходимо быстрое выполнение запросов DNS В глобальном окружении, могут устанавливать дополнительные сер- 8cpM в различных географических точках, даже помешать некоторые свои зонм на серверах, принадлежащих сотрудничающим с ними организа- дуями. В таком случае ускоряется выполнение локальных запросов и добавляется избыточная мощность, что позволит вам выйти из положения, когда доступ через Internet к вашему сайту станет невозможным.
Дополнительные серверы DNS могут сохранить возможность разрешения запросов при сбое, хотя узлы назначения могут быть недоступны. Для служб, подобных Sendmail™, это полезно; поскольку Sendmail1M в состоянии разрешить узел, но не создать сеанс передачи сообщения, она иросто помешает сообщение в очередь и предпринимает попытку позже. Если же Sendmail™ не может разрешить узел, она снимает сообщение и возвращает ошибку 'Неизвестный узел".
，，Windows 2000 выходит за пределы стандартного разграничения основных и дополнительных серверов DNS, предусматривая интеграцию данных зоны в Active Directory как третью категорию зоны. При интеграции остаются стандартные дополнительные зоны, но также может сушество- 開ть несколько равных основных серверов, использующих копирование в Active Director}1, Эта особенность описана в главе 7, "Динамическая DNS и Active Directory'', где рассматривается множество вопросов, связанных етехнологией Active Directory в DNS.
До сих пор в этой главе речь шла о пространстве и серверах доменных имен. В оставшейся части главы исследуются клиенты, запросы клиентов и взаимодействие серверов DNS для выполнения запросов.
Разрешение запросов клиентов
Если клиент хочет связаться с удаленной системой (например, когда пользователь шелкаег на ссылке на Web-сайт), надо пройти несколько этапов, прежде чем начнется фактическое соединение с удаленной сис- ТСМО員.Первый этап ——определение по имени удаленной системы ее IP- афеса. К,тиенты при этом действуют как распознаватели. Чтобы разре- ИШТЬ имя удаленной системы, клиент посылает запрос на один из своих Серверов DNS. В конфигз'рации клиента указан по крайней мере один е^)вер DNS. Порядок просмотра серверов DNS клиента отражен на вкладке Конфигурация DNS его диалогового окна Свойства TCP/IP (рис. 2-4). В начальном разделе главы 14, 11 Настройка и разрешение клиентов Windows", даны указания, как найти это диалоговое окно в разных клиентах Windows.
- На рис. 2.5 показано, что в список, указывающий распознавателю- клиенту, где искать адреса имен узлов, могут быть внесены один или Дольше IP-адресов серверов DNS. Клиент запрашивает первый сервер Имен в списке. Если распознаватель не получает подтверждения за ука- 编Иное время, он запрашивает следующий сервер в списке, пока сервер КМен не примет запрос.
Рис. 2.4. Параметры DNS в свойствах TCP/IP клиента Windows 95/98Рис. 2.4. Параметры DNS в свойствах TCP/IP клиента Windows 95/9811poполннтепьные параметры TCP/IP11poполннтепьные параметры TCP/IP:.Лср№о7ры Р .由NS —]wiNS I Парометрн 卜:.Лср№о7ры Р .由NS —]wiNS I Парометрн 卜Рис. 2,5, Расширенная конфигурация DNS клиента Windows 2000Рис. 2,5, Расширенная конфигурация DNS клиента Windows 2000
Рис. 2.4. Параметры DNS в свойствах TCP/IP клиента Windows 95/98
Рис. 2.4. Параметры DNS в свойствах TCP/IP клиента Windows 95/98
11poполннтепьные параметры TCP/IP
11poполннтепьные параметры TCP/IP
:.Лср№о7ры Р .由NS —]wiNS I Парометрн 卜
:.Лср№о7ры Р .由NS —]wiNS I Парометрн 卜
Рис. 2,5, Расширенная конфигурация DNS клиента Windows 2000
Рис. 2,5, Расширенная конфигурация DNS клиента Windows 2000
Если сервер имен принимает запрос клиента, обычно клиент останавливается и ждет ответа, в то время как сервер пытается найти в своих файлах зон или на других серверах DNS IP-адрес, соответствующий имени узла, полученному в запросе. Если первый сервер DNS принимает за-
оос но не может разрешить его локально или через другие серверы, он возврашает ответ "Name error" (NE), указывающий, что доменного име- ^ не сушествует. В этом случае клиент не перенаправляет запрос другому серверу DNS.
Если имя узла включает имя домена узла, сервер DNS использует дополнительную информацию для ускорения поиска, возможно, даже направляет запрос непосредственно другому серверу DNS или сообщает клиенту адрес другого сервера DNS, чтобы послать запрос ему (см. полностью уточненные доменные имена (FQDN) в главе 1, "'Введение в систему доменных имен"). Если имя домена не указано, сервер DNS может допустить, что запрос относится к узлу в его собственном файле зоны.
Прохождение запроса клиента
Ниже приводится подробный пример, который поможет вам понять эвристику разрешения запроса. По этому процессу следует пройти достаточно медленно, чтобы усвоить, что происходит на каждом этапе, поскольку этот пример иллюстрирует реальную работу DNS.
Из предыдущих рассуждений (о FQDN и домене корневого уровня) можно вспомнить, что завершающая точка означает, что имя узла является полностью уточненным, т е. считается, что все необходимые указания принадлежности к доменам присутствуют в этом имени. Если имя узла, которое надо разрешить, заканчивается точкой (.), сервер DNS клиента не делает дальнейших предположеним о принадлежности к доменам. Он сразу начинает работу с запросом, посылая его непосредственно на сервер корневого уровня, от которого он должен направиться по кратчайшему пути вниз по дереву DNS до сервера, авторитетного для домена искомого узла. Если имя относительное (т.е. без завершающей точки), сервер DNS делает ряд предположений в попытке реконструировать полностью уточненное имя узла.
Поведение распознавателей несколько различается в зависимости от Происхождения кода, используемого для его библиотек. Следует заметить, что многие стандартные распознаватели обрабатывают запрос в несколько этапов исходя из того, что получает распознаватель (клиент) от Обслуживаемого им приложения- Если запрашивается имя узла www, доменное имя добавляется по умолчанию. Если запрашивается имя узла Www.isi.edu, распознаватель сразу пытается разрешить www.isi.edu. Если сервер не может найти www.isi.edu, он пробует добавить доменное имя и рассматривает запрос снова.
Другие распознаватели отличают FQDN от имени узла, определяя по Виду всей строки, выглядит ли заданное имя как www. example .net, тори это FQDN, или как www — тогда это лишь локальное имя узла_
Для примера поместим наш клиент в домен cnri . reston. vs . ns n потребуем от него найти Web-сайт www. isi. edu. Если доменное имя искомого узла не указано полностью (не уточнено), сервер пытается восстано-
вить полное имя. Поскольку клиент сначала запрашивает свой собственный сервер DNS в домене cnri. reston. va .us и не использует FQDN. исходная строка, которую пытается найти сервер DNS, выглядит так:
www.isi.edu.cnri.reston.va.us
Заметьте, что сервер DNS добавляет свое доменное имя cnri . reston - va. us к имени искомого узла. Серверы DNS считают, что имя узла не является полностью уточненным, если запрос не содержи! завершающей точки. Только завершающая точка удостоверяет, что доменное имя полностью уточнено. Другой способ запомнить это — прел- ставить, что www.：si.edu— это относительное имя, как www, которое может быть разрешено в текущем домене, а может н не быть Поскольку здесь нет завершающей точки, распознаватель может принять, что это имя относительное, и предоставить серверу DNS классифицировать его С первоначальным доменом поиска cnri . reston. va . us сервер имен не может разрешить полученную комбинацию имен узла и домена. Если реконструкция FQDN искомого узла не удалась, при следующем запросе сервер предполагает, что этот узел расположен на вышестоящем уровне Тогда второй запрос будет выглядеть так:
www.isi.edu.example.NET
Заметьте, что часть cnri из первого запроса исчезла. Если сервер имен, выполняющий поиск для клиента, не является основным ни для домена reston.va、ни для домена cnri, он посылает запрос другому серверу. Но если сервер имен основной, и попытка определить 1Р-адрсс при втором запросе не удалась, сервер DNS снова изменяет запрос, уда ■ ляя другую часть локального доменного имени в предположении. 1по следующий по высоте уровень сможет разрешить его. Это третья попытка сервера DNS.
产 Примечание
*：； Распознаватели могут работать по-разному в зависимости от своих алгоритмов и конфигураций. Примеры, приведенные в этой главе, показывают :& основные принципь| работы распознавателей Факторы, специфические для каждого распознавателя, могут изменять используемые ими методы, но это Н редко влияет на окончательные результаты.
.й.1' Некоторые распознаватели, например, предполагают, что доменное имя, содержащее точки (.), является полностью уточненным, и передают такие имена серверу DNS без изменений Так обстоит дело при первой попытке в “ Windows 2000 Другие считают, что, если имя не содержит завершающей точки, оно не может быть полностью уточненным; следовательно, распозна- " ватель добавляет к имени доменное имя клиента перед передачей его сер
веру DNS. Оба предположения могут быть неверными. К счастью, распознаватели клиентов совместно с серверами DNS могут успешно проанализировать и разрешить большинство имен
Если третья попытка также не удается, то четвертая в данном случае будет несколько иной. Поскольку в действительности домена us не существует (он обрабатывается на корневом уровне), четвертый запрос Фактически выходит на сервер корневого уровня в поиске www. isi . edu. Сервер имен получает от сервера корневого уровня не ответ на запрос о у^ i5i . edu. а ссылку на авторитетный сервер имен для isi . edu. Затем сервер DNS отправляет запрос о www.isi.edu непосредственно на сервер имен isi . edu.
Поскольку www.Lsi.edu— реально существующий узел в домене j_si.edu, сервер имен isi. edu возвращает IP-адрес www.isi.edu. Затем локальный сервер имен направляет ответ клиенту, что позволяет ему начать следующий этап — загрузку Web-страницы путем соединения с Web-сервером по указанному IP-адресу. В следующем разделе процесс запроса адреса узла рассматривается более подробно.
Выше был приведен пример рекурсивного запроса сервера имен. Также могут быть установлены итеративные, или нерекурсивные, сервера имен, и результат итеративного запроса фактически такой же, как у сервера имен, запрашивающего корневой сервер. Корневые серверы не выполняют запросов для клиентов; они лишь дают ссылку, или указание, где можно найти больше информации.
Серверы DNS могут работать в рекурсивном или итеративном режиме. В рекурсивном режиме сервер DNS становится агентом клиента, соединяясь, если необходимо, с другими серверами DNS, чтобы получить ответ, пока клиент ожидает. При обработке запроса рекурсивный сервер DNS сам становится распознавателем, или клиентом DNS, для других серверов DNS. В режиме по умолчанию сервер DNS Windows 2000 принимает от клиента рекурсивные запросы, но передает другим серверам DNS, исключая отправителя, итеративные запросы.
В итеративном режиме сервер DNS выдает предположение относитель- тю того, какой сервер может ответить на запрос. Обычно этот ответ является ссылкой на другой сервер DNS, к которому может обратиться распознаватель первоначального клиента или другого сервера DNS. Эти ссылки представляют собой ряд поеледо вате л ь н ы х ступеней, которые все ближе ИОДводят к окончательной цели. Это освобождает сервер DNS от дальнейшей работы над запросом, так как клиент продолжает эту работу сам,
Пример запроса адреса узла
Программа nslookup, используемая в следующем примере, описана ниже, в разделе “Обзор инструментальных средств", и более подробно — В Главе 12, "Средства поиска неисправностей".
Листинг 2.1 представляет собой реальный текст, выведенный про- тммой nslookup при выполнении запроса адреса узла www.isi.edu Основным сервером имен домена enri . reston. va. us. В нем показаны соединения, которые происходят между клиентами и серверами при разрешении запроса DNS. На рис. 2.6 представлена диаграмма запроса в листинге 2.1.
Порядок событий
Клиент cnri посылает запрос о www.isi.edu серверу DNS в cnri.reston.va.us.
Сервер DNS в домене cnri запрашивает сервер DNS reston.va.us,
По ссылке сервер DNS в домене cnri запрашивает сервер DNS va.us.
По ссылке сервер DNS в домене cnri запрашивает корневой сервер DNS, который является первичным для доменов .us и .edu. '
По ссылке сервер DNS в домене cnri запрашивает сервер DNS isi.edu.
Сервер DNS в isi.edu возвращает адрес www.isi.edu.
Сервер DNS в домене cnri возвращает адрес www.isi.edu клиенту.
Рис, 2.6. Запрос имени, следуя делегированиям, пересекает дерево DNS
Листинг 2.1, Пример рекурсивного запроса, выполненного nslookup ns.cnri.reston.va.us:/:IS nslookup Default Server: localhost Address :127.0.0.1
> , set debug //Initial Query to CNRI Server (#1) > . www.isi.edu Server : ns . cnri. restor.. va . us Address：132.151.1.1
;;res_mkquery(0, www.i=i.edu.cnri.reston.va.us, 1, 255)
Got answer:
HEADER:
opcode = QUERY, id = 4, rcode = NXDOMAIN
header flags:
responce, auth. answer, want recursion, recursion questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
www.isi.edu.cnri.reston.va.us, type = ANY, class = AUTHORITY RECORDS:
,> cnri.reston.va.us
- ttl = 3600 (1 hour)
origin = cnri.reston.va.us mail addr = action.cnri.reston.va.us serial = 199712220 refresh = 3600 (1 hour) retry = 300 (5 mins) expire = 3600000 (41 days 16 hours) minimum ttl = 3600 (I hour)
//Referral By CNRI.Reston.Va.US to Reston.Va.US (#2) //which Triggers Next Query
；； res_mkquery(0, www.isi.edu.reston.va.us, 1, 255)
Got answer： HEADER: opcode = QUERY, id = 5, rcode = NXDOMAIN header flags: responce, auth. answer, want recursion, recursion questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
www.isi.edu.reston.va.us, type = ANY, class =: AUTHORITY RECORDS: _.>'reston.va.us
ttl = 21600 (6 hours) origin = Gala.NameTamer.com mail addr = hostmaster.NameTamer.com serial = 1997091912 refresh = 21600 《6 hours) retry = 7200 (2 hours) expire = 3600000 |41 days 16 hours) minimum ttl = 259200 (3 days)
//Referral By Reston.Va.US to va.US (#3) //which Triggers Next Query
；； res_mkquery(0, www.isi.edu.va.us, 1, 255)
Got answer:
HEADER:
opcode = QUERY, id = 6, rcode = NXDOMAIN
header flags:
responce, auth. answer, want recursion, recursion questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
www.isi.edu.va.us, type = ANY, class = IN
AUTHORITY RECORDS:
ttl - 86400 11 dav)
origin VENERA.Kl.EDU
mail addr = us.domain.ISI.EDU serial = 971219 refresh = 43200 (12 hours) 二etry = 3600 !1 hour) expire = 1209600 (14 days) minimum ttl = 86400 (1 day)
//Referral By Va.US through "root" to 工SI.EDU (#4,5) //which Triggers Next Query
;; res_mkquery(0, www.isi.edu, 1, 255)
Got answer:
HEADER:
opcode = QUERY, id = 7, rcode = NOERROR
header flags:
responce, want recursion, recursion avail.
questions = i, answers = 1, authority records - 3, additional - 4
QUESTIONS:
www.isi.edu, type = ANY, class = IN
ANSWERS:
www. j. si . edu
internet address = 128.9.176.20
ttl = 25234 (7 hours 34 secs)
AUTHORITY RECORDS：
_.> ISI.EDU
~ nameserver = VENERA.ISI.EDU
ttl = 130797 (1 day 12 hours 19 mins 57 secs)
_.> ISI.EDU
nameserver - NS.ISI.EDU
ttl = 130797 11 day 12 hours 19 mins 57 secs) > ISI.EDU
nameserver = NOC.HPC.ORG
ttl = 130797 (1 day 12 hours 19 mins 57 secs) ADDITIONAL RECORDS:
VENERA.ISI.EDU
internet address = 128.9.0.32
ttl - 20381 (5 hours 39 mins 4]. secs) > VENERA.ISI.EDU
internet address = 128.9.176.32
ttl - 20381 15 hours 39 mins 41 secs) > MS.ISI.EDU
internet address = 128.9.128.127
ttl = 20381 ( 5 hours 39 mins 41 secs) > NOC.HPC.ORG
internet address = 192.187.8.2
ttl = 145775 (1 day 16 hours 29 mins 35 secs)
//Answer to Query by ISI.EDU for CNRI.Reston.Va.US (#6) //which ls Returned to Client (#7)
Non-autoritative answer： www.isi.edu
internet address = 126.9.176.20 ttl 25234 (7 houLS 34 secs 1
Authoritative answers can be found from：
nameserver = ttl = 130797ISI.EDU nameserver = = 130797ISI-EDUnameserver = ttl = 130797ISI.EDU nameserver = = 130797ISI-EDUVENERA.ISI.EDU (1 day 12 hours 19VENERA.ISI.EDU (1 day 12 hours 19NS.ISI.EDU (1 day 12 hours 19NS.ISI.EDU (1 day 12 hours 19nameserver = ttl = 130797 VENERA.ISI.EDUnameserver = ttl = 130797 VENERA.ISI.EDUNOC.HPC.ORG (1 day 12 hours 19NOC.HPC.ORG (1 day 12 hours 195757internet address = 128.9.0.32 ttl l 20381 (5 hours 39 rains 41VENEPA.ISI.EDUinternet address - 128.9.176.32internet address = 128.9.0.32 ttl l 20381 (5 hours 39 rains 41VENEPA.ISI.EDUinternet address - 128.9.176.3220381 {5 hours 39 ms 4120381 {5 hours 39 ms 41NS.ISI.EDU internet adctess = 128.9.. 12"?ttl = 20361 {5 hours 39 mins 41 secs)NOC.HPC.ORGNS.ISI.EDU internet adctess = 128.9.. 12"?ttl = 20361 {5 hours 39 mins 41 secs)NOC.HPC.ORGinternet addres； ttl = 145775 (1internet addres； ttl = 145775 (1day 16 hours 29 mins 35day 16 hours 29 mins 35
nameserver = ttl = 130797
ISI.EDU nameserver = = 130797
ISI-EDU
nameserver = ttl = 130797
ISI.EDU nameserver = = 130797
ISI-EDU
VENERA.ISI.EDU (1 day 12 hours 19
VENERA.ISI.EDU (1 day 12 hours 19
NS.ISI.EDU (1 day 12 hours 19
NS.ISI.EDU (1 day 12 hours 19
nameserver = ttl = 130797 VENERA.ISI.EDU
nameserver = ttl = 130797 VENERA.ISI.EDU
NOC.HPC.ORG (1 day 12 hours 19
NOC.HPC.ORG (1 day 12 hours 19
57
57
internet address = 128.9.0.32 ttl l 20381 (5 hours 39 rains 41
VENEPA.ISI.EDU
internet address - 128.9.176.32
internet address = 128.9.0.32 ttl l 20381 (5 hours 39 rains 41
VENEPA.ISI.EDU
internet address - 128.9.176.32
20381 {5 hours 39 ms 41
20381 {5 hours 39 ms 41
NS.ISI.EDU internet adctess = 128.9.. 12"?
ttl = 20361 {5 hours 39 mins 41 secs)
NOC.HPC.ORG
NS.ISI.EDU internet adctess = 128.9.. 12"?
ttl = 20361 {5 hours 39 mins 41 secs)
NOC.HPC.ORG
internet addres； ttl = 145775 (1
internet addres； ttl = 145775 (1
day 16 hours 29 mins 35
day 16 hours 29 mins 35
-' В листинге 2.1 и на рис. 2-6 можно видеть, как запросы серверов имен поднимаются по дереву DNS до верхнего уровня и затем спускаются по другой ветви. Может также показаться интересным, что сервер имен "№NERA. IS1. EDU обнаруживается в разных местах. Ссылка на VENERA. ISI. EDU имеется на уровне va.us запроса. VENERA, isi. EDU —
один из серверов имен для домена va. us. Также можно заметить, что сервер из фа(!ла кэша корневого уровня, venera. isi . edu, раньше был ^Цним из серверов DNS корневого уровня. Корневой сервер, поддерживаемый 1SI, теперь называется b. root-servers .ret.
§6зор инструментальных средств
' С различными аспектами DNS связано множество инструментальных Ирираммных средств. Эти средства могут облегчить понимание того, что происходит и что может быть не в порядке.
Для эффективного применения этих средств необходимо понять прин- ^*ПЫ их работы. В этом разделе мы уделим внимание следующим средст- Domain Internet Groper (dig), icconfig, netlab, nslcok-jp, piny, traceroute (trscert). netsrac н nbstat. Здесь приводится лишь кратче описание этого набора программ； подробнее о них см. в главе 12. Ни- 期 По отдельности рассматривается работа с каждым из этих средств.
aig— инструмент, который лучше nslookup. Эта программа oi спежнвает больше информации и проще в использовании di」 также применяет распознаватель для выполнения запросов в распределенной базе данных DNS. Программа имеет множество параметров, обеспечивающих большую гибкость в командной строке
ipconfig отображает информацию о сетевых настройках системы, воючая IP, сервер DNS, данные маршрутизации, сетевую маску и т.д. ipconfig также позволяет обновлять или отключать все пли отдельные адаптеры и выводить данные в таазанный файл.
При выпуске Windows 2000 корпорация Microsoft добавила в ipconfig некоторые дополнительные функции. Две из них мо「\т помочь при работе с кэшем распознавателя клиента.
/dispiaydns позволяет показать содержимое кэша распознавателя, если в нем есть какие-нибудь элементы.
/flushdns позволяет очистить кэш, что может быть очень полезно при повреждении и перезагрузке информации.
netlab — свободно распространяемая программа, состоящая из множества функций, пегко доступных через графический мнтер- фейс. Это позволяет свободно переходить от функций лчя отслеживания проблем с сетью к функциям, предоста вл яющи м информацию о параметрах сети neiLab объединяет функции для облегчения доступа и делает возможным обращение к таким обслуживаюшим программам, как finger, whois, rime, quo:. ping, trace, DNS, scanner H info, finger может работать В режимах user@host и host- (В режиме 」ser@host эта программа выдает информацию о конкретном пользователе на этом узле, а в режиме hose — о том, кто зарегистрировался в системе.) who.， выводит информацию из базы данных whois о конкретном домене; можно запросить разные типы серверов who二s для получения прямой или обратной информации, time включает две функции'. daytime выводит в удобном для чтения формате дату и время, соответствующее географическому расположению удаленного сервера, a clock synchronization синхронизирует системные часы пользователя с эталонными, quote соединяет с сервером "Цитага дня"——забавной функцией, предлагаемо» некоторыми службами ping проверяет доступность узлов, как описано ниже; раздел ping имеет графический интерфейс, что улучшает контроль над командой ping. DNS выполняет простые запросы DNS. scanner позволяет сканировать сеть и контролировать параметры сканирования (сканирование портов и т.д.). i二Ео выдает информацию о версиях стека и имени системы.
nslookup выполняет запросы DNS к различным серверам. При запуске nslookup запрашивает сервер имен, заданный по умолил-
нию, если не указан другой сервер, ns lookup можно запустить в двух основных режимах: интерактивном и неинтерактивном. В интерактивном режиме можно выполнить несколько запросов н установить множество параметров, что позволяет контролировать, как nslookup запрашивает базу даннь!х. nsiookup использует для запросов свой собственный распознаватель
ping ——это программа, работа которой основана на протоколе 1 контроля сообщений в сети Internet (Internet Control Message Protocol, 1CM P) icmp посылает на указанный в виде параметра адрес запрос отк.чика (ICMP echo_REQ!JEST), pina имеет несколько опций, управляющих его поведением. рз，д служит прежде всего для проверки чувствительности компьютера в сети.
tracert (иногда также называемая traceroute) — программа, - которая посылает пакеты UDP на указанный адрес. Обычно посылаются группы из трех пакетов и каждая группа получает увеличенный на единицу срок жизни (tinie-to-live, TTL). Параметр TTL используется, чтобы определить, следует ли считать пакет сетевого трафика недоставленным. Если пакет помечен как недоставленный, назад на исходный узел передается сообшение TIME_E；XCEEDr,D, Это позволяет отслеживать каждый uiar прохождения сетевого трафика на пути к назначению. После того как адрес назначения достигнут, tracert прекращает передачу наборов пакетов.
netstat отображает статистику журнала и текущих сетевых подключений TCP/IP. Несколько опций позволяют управлять отобра- - жением данных. Для получения списка всех опций введите netstat /7.
■ ■ nbtscat отображает статнстнку с использованием NetBIOS поверх *' TCP/IP (NetВТ). Для nbtstat также имеется несколько опций.
Чтобы получить список всех опций, введите nbtstat /?.
Резюме
Эта глава завершает вводное рассмотрение работы DNS. Следующие Йесколько глав охватывают типы серверов DNS, их назначение и взаимодействие серверов различных типов, а также подробную информацию о 费йлах зон DNS. В главе 5, "Анализ запросов имен"、мы вернемся к ис- ^Ледованию разрешения имени клиента и дадим исчерпывающее 06bqe- Хение итеративных и рекурсивных запросов.
Типы серверов имен
В этой главе...
Основные серверы имен. Основные серверы имен имеют право oi- вечать на запросы в своей зоне, и от их расположения отсчитываются данные всех адресов зоны. В этом разделе описываются признаки, которые делают основной сервер особенным. Учтите, что иногда основной сервер имен также называют главным (master). Это название перешло из файлов конфигурации BIND версии 8. Везде, где в этой главе встречается термин "основной", его можно заменить термином главный.
Дополнительные серверы имен. Дополнительные серверы имен являются резервными. Исходные данные зоны хранятся не в них, однако они имеют поиномочня отвечать на запросы домена. Дополнительные серверы обычно получают свои данное зоны от основного сервера DNS домена Учтите, что дополнительные серверы также могут называться подчиненными (slave).
Серверы имен только для кэширования. Как следует из названия, эти серверы кэширую! данные адресов. Кэширование могут выполнять многие серверы. Серверы только для кэширования не заняты ничем, кроме кэширования запросов- Они не имеют файл'! зоны, содержащего множество узлов, и не могут переносить зоны с
，‘ других серверов DNS’ Серверы имен только для кэширования отвечают на запросы, но неавторитетно. В этом разделе описываются “ серверы только для кэширования и объясняется, зачем они нужны.
.Прохождение запросов: узлы пересылки и подчиненные серверы. Узлы пересылки л подчиненные серверы — это серверы DNS, очень специфическим образом совместно взаимодействующие с ) другими серверами DNS для разделения обязанностей по обработ- :ке запросов. В этом раз工e:ie от(сываются узлы пересылки и под
' чиненные серверь( н объясняется, какие возможности управлять сетью они дают администратору. Учтите, что подчиненные серверы, описываемые здесь, — не то же самое, что подчиненные (дополнительные) серверы, упомянутые выше; здесь этот термин обозначает режим работы, а не тип сервера.
Определение типа DNS. Если неизвестно, какую роль играет данный сервер DNS. этот раздел поможет объяснить рачличия между основными, дополнительными, пересылочными, подчиненными серверами и серверами кэширования.
Сервер доменных имен может играть одну или несколько ролей сразу. В，этой главе предлагается обзор возможных назначений, которые может выполнять сервер. Важно также отметить, что один сервер DNS может поддерживать несколько доменов одновременно, выполняя разные обязанности для каждого домена. Некоторые роли, например, кэширование, неизбежно подчиняют весь сервер. Кроме того, тип сервера DNS определяется при выборе его конфигурации и конфигураций для каждого домена, которые он будет поддерживать.
Кроме разбора потенциальных ролей сервера DNS, в этой главе рассматриваются некоторые варианты архитектуры, что позволяет проиллюстрировать различия между основными, дополнительными, пересылоч^ Нымн, подчиненными серверами н серверами кэширования. Разобраться В них легче в контексте практических проблем и приложений. Единственное четко установленное правило — то, что в каждом домене какой- нибудь сервер должен бь(ть основным. Все остальное предостакчяется на ваше усмотрение.
Основные серверы имен
Основные (или главные) серверы — это пвнштепн DNS, стимулирующие распространение и поиск данных имен по Internet. Основные ^брверы всегда являются первоисточниками данных адресов. Они имеют первостепенные полномочия для имен в своем домене, и, поскольку они 串Вляются первоисточниками файлов зон при передаче, основные серверы Сами по себе могут определять информацию, которая публикуется для 察ех и каждого сервера, нуждающегося в ней. Дополнительный сервер Шже может быть ''главным'' при передаче зоны для другого дополни-
г гг г
г г
г г
тельного сервера, но главные файлы помешаются на основном сервере Эта путаница в терминологии разъясняется в RFC 2136, гле приводикя различие между подчиненными, главными и основными главными серверами.
■ Подчиненный сервер. Авторитетный сервер, который принимав данные при передаче зоны и обозначается в зоне записью NS.
■ Главный сервер. Авторитетный сервер, сконфигурированный как источник при передаче зоны для одного или более подчиненных серверов.
■ Основной главный сервер. Главный сервер в корне графа, опрелс- ляюшего зависимость при передаче зоны. Основной главный сервер обозначается в зоне начальной записью (Start of Authority, SOA). По определению, в каждой зоне существует только один основной главньЕй сервер.
Процесс публикации начинается, когда администратор создает загр\- зочный файл конфигурации вручную, копирует его из реализации DNS BIND ^я системы UNIX или, что более вероятно, вводит все данные начальной конфигураиии, необходимые для сервера, через интерфс!1с управления сервером DNS Сервер DNS Windows 2000 автоматически помешает все файлы конфнгураинн в папку ?windir% \system32\dr.s.
Ниже представлен перечень важнейших данных, необходимых, чтобы сконфигурировать DNS вручн\то.
Имя помеха (оно должно быть предварительно утверждено R InterNIC. если предполагается разрешение этого имени за прел с- ламп органн jauiin).
IP-адрес и имя каждого сервера, для которого предполагается pai- решение.
■ Имена узлов и адреса самих серверов DNS.
■ Имена узлов и адреса всех остальных компьютеров, которые буд\ г включены в зону сервера DNS.
См. в паве 11, "Настройка Windows DNS Server", поэтапные hhci- рукции по установке и настройке Windows 2000 DNS Server.
Хранение данных начальной конфигурации DNS Windows
Данные начальной кон()жгураиш4 DNS Windows можно хранить ра>- личными способами: в загрузочном файле или в реестре. По умолчанию DNS загружается из регистра. Чтобы использовать загрузочный фант конфигурации, а не реестр, следует установить метод загрузки, выбрав элемент Из файла в списке Загрузить зону при старте. Этот список находится во вкладке Дополнительно диалогового окна Свойства сервера DNS.
%• В отличие от предыдущих программ DNS Server, Windows 2000 DNS Server автоматически обновляет реестр и загрузочный файл при выборе изменении метода загрузки. (В предыдущих версиях синхронизация ■ - j^na довольно трудоемкой задачей, причем часто более трудной, чем по- ^ряной.) Раздел реестра называется HKLM\System\CurrentControlSeL\ i嘉rvices'DNS. В главе 11 рассматривается эффект изменения метода чванен ия.
;■ В Windows 2000 также возможен вариант с использованием зон, ин- 龜рмрованных в Active Directory, но только для основных зон. Поскольку дополнительные серверы не изменяют данных, им не нужно обращаться ^основным данным непосредственно; они лишь выполняют передачу ■ж)НЬ1 обычным порядком. Для основных зон интеграция в Active 'directory означает. что данные зоны хранятся в каталоге. Это обеспечи- ；麻仃 лучшие возможности для хранения и репликации (переноса) дан- Ш1Х. При использовании зон, интегрированных в Active Directory, не- ^олько доменных контроллеров могут быть главными для информации '|^новной зоны. Такая интеграция также позволяет контролировать лю- t曲 доступ ко всей памяти вплоть до отдельной записи ресурсов (RR), о является допол ни тел ьным способом зашиты данных зоны.
Данные конфигурации и домены
k‘ Microsoft DNS Server может использовать файлы конфигурации, огра- ,Ш«енно совместимые с файлами конфигурации BIND стиля UNIX, :就Й*де всего для облегчения переноса данных в Microsoft DNS Server. По :^Иолчанию файл кэша в Windows 2000 носит имя CACHE. DNS.
^：. Данные конфигурации не только указывают каталог, в котором сервер ，^Йет хранить такие данные, как файлы зоны и кэш, но к содержат спи- ，^!^! доменов, которые сервер будет поддерживать, и директиву, указы- (■^ющую, какого типа должен бь(ть сервер для каждого домена: основной, ^)полнительный или для кэширования. Если сервер использует Active г directory, данные зоны будут храниться в нем. Если сервер является ос- ?^ОВнмм, загрузочная конфигурация включает исходный файл зоны для '^^аждого указанного домена, Еслн он является дополнительным, конфи- грация включает IP-адрес главного сервера, чтобы сервер "знал", откуда Опрашивать обновления.
{* Во время работы основного сервера администратор может выполнять 'фйкие изменения, как добавление илн упаленне узлов, субдоменов, поч- :渺вмх обменников, серверов имен и т.д. При использовании за грузом- 4①ого файла конфискации для настройки и запуска сервера изменения производятся только в исходных файлах основного сервера. Загрузочные fфайлы серверов имен имеют структуру, подобную приведенной ниже. 標Строки комментариев, которые начинаются с точки с запятой [;], встав- ；城ешя для описания элементов файла.)
;каталог, 1 ;резервные diLectory;каталог, 1 ;резервные diLectory;Директивы для Тип сервера primary;используется , primary;используется , primary，-используется ,;Директивы для Тип сервера primary;используется , primary;используется , primary，-используется ,сервера имен:example.netсервера имен:example.netИсточник данных hosts.dbИсточник данных hosts.dbдля пррмсго псксха (IР-йдреса по имени； 1,168.192.in-addr,arpa nosts.revдля обратного поиска (тлени по IP-адресу)для пррмсго псксха (IР-йдреса по имени； 1,168.192.in-addr,arpa nosts.revдля обратного поиска (тлени по IP-адресу)0.0.127.^n-addr.агра для внутреннего сообщения0.0.127.^n-addr.агра для внутреннего сообщенияhosts.localhosts.local,■ файл корневого кэша (имена и IP-адреса,■ файл корневого кэша (имена и IP-адресакорневого уровня)корневого уровня)
;каталог, 1 ;резервные diLectory
;каталог, 1 ;резервные diLectory
;Директивы для Тип сервера primary
;используется , primary
;используется , primary
，-используется ,
;Директивы для Тип сервера primary
;используется , primary
;используется , primary
，-используется ,
сервера имен:
example.net
сервера имен:
example.net
Источник данных hosts.db
Источник данных hosts.db
для пррмсго псксха (IР-йдреса по имени； 1,168.192.in-addr,arpa nosts.rev
для обратного поиска (тлени по IP-адресу)
для пррмсго псксха (IР-йдреса по имени； 1,168.192.in-addr,arpa nosts.rev
для обратного поиска (тлени по IP-адресу)
0.0.127.^n-addr.агра для внутреннего сообщения
0.0.127.^n-addr.агра для внутреннего сообщения
hosts.local
hosts.local
,■ файл корневого кэша (имена и IP-адреса
,■ файл корневого кэша (имена и IP-адреса
корневого уровня)
корневого уровня)
в котором cins.exe будет хранить :файлы;
с- ： \wini;t\system32\dns
Форма предыдущего примера знакома администраторам UNIX, Windows 2000 DNS игнорирует директиву directory в этом примере. Учтите, что файлы, включая 巾айл кэша, обычно имеют в системах Windows расширение .DNS. если не указано другое. Пока что параметры конфигурации не имеют особого значения для нас. В главе 11, где описана инсталляция, дается информация, необходимая для понимания смысла параметров и их выбора. К счастью, многие параметры устанавливаются автоматически.
Директива cache указывает на корневой домен (.), а файл кэша содержит адреса основных серверов корневого уровня. Файл корневого кэша поста аляется с Windows 2000 DNS. однако всегда можно взять его последнюю версию в InterNIC по адресу ftp: //rs.iriternic.net/doTnairz named, root. Обязательно переименуйте этот файл в cache. (Не nyraRie также фа(1л корневого кэша с серверами только для кэширования.) FTP- сайт —самый простой способ получить эту информацию. Единственный случай, когда потребуется обновить файл корневого кэша — если оргаим управления Internet добавят новый сервер корневого уровня (что маловероятно), или если данный сервер DNS будет использоваться для поддержки изолированной частной сети. Эти файлы нужны, только если вы собираетесь использовать сервер открыто для поиска в Intemet. Некоторые компании применяют внутреннюю и внешнюю настройки для внутреннего разрешения и для адресов Intemet; это часто бывает, если для внутреннего и внешнего серверов выделены разные компьютеры.
В приведенном выше примере структуры загрузочного файла сервера имен файл hosts. db содержит текстовую таблицу для домена example , net. Файл hosts . rev содержит текстовую таблицу для домена 1.168.192. in-addr. агра — домена, включающего отображения Internet-адресов (in-addr) на имена узлов для сети 192.168.1.0. Команда directory, которая в Windows игнорируется, в UNIX сообщает серверу имен BIND, что фа；Ъ1Ы размешаются в каталоге <с：\winnr\system32\dns.
Дополнительные серверы имен
Дополнительный сервер содержит авторитетные данные адресов для ломена, но получает их от дополнительного сервера путем передачи зо- 蟲 Дополнительные серверы отлично подходят для резервирования дан- ды1 и снижают нагрузку основного сервера, отвечая на запросы. В BIND всрснн 8 дополнительные серверы называются подчиненными.
Дополнительные серверы являются авторитетными, поскольку содержат локальные копии файлов зоны, полученные от основных серверов при передаче зоны. Функции дополнительных серверов имен заключают- ея в следующем.
Распределение нагрузки между несколькими компьютерами. Поскольку запросы домена обрабатывают несколько машин, время разрешения запроса уменьшается. Распределение нагрузки происходит вследствие того, что распознаватели отслеживают, какие серверы они использовали и каково время ответа этих серверов для каждого запроса.
В зависимости от географического положения, маршрутизации и так далее одни серверы работают лучше, чем другие. Интеллектуальный распознаватель использует эту информацию, чтобы выбирать серверы имен для разных запросов.
Избыточность. С дополнительными серверами имен домен может разрешать запросы, даже если основной сервер выходит из строя и становится недоступным. Особенно полезно размешать дополнительные серверы в физически различных сетях, даже в разных районах страны.
Разрешение методом обратной петли для домена обратных адресов и кэшированного корневого домена
Директивы и содержимое файлов для домена 0.0127 . in-addr. агра и корневого кэша обычно одни и те же на всех машинах, так как каждый компьютер имеет порт обратной петли с адресом 127.0.0.1. Обратная петля (loopback), часто называемая localhost, служит для внутренних соединений сетевых служб
Сервер имен может разрешать имена, вызывая сам себя по адресу localhos-, что ускоряет работу, поскольку соединение в этом случае проходит не через сеть, вызывающую некоторую задержку
Конечно, если внимательно взглянуть на этот список, можно заметить, что модель зоны, интегрированной в Active Directory, с несколькими главными серверами, может удовлетворить всем этим требованиям и без дополнительных серверов.
Работа электронной почты ——хороший пример, доказывающий необходимость избыточности. Допустим, что копания xyz.com имеет основной сервер имен в Сан-Хосе, Калифорния, Администраторы решили по-
местить дополнительный сервер в другую подсеть, но в том же здании. Если xyz.com теряет связь с Internet, она сразу же утрачивает способность отвечать на внешние запросы DNS в своем домене Если кто- нибудь попытается послать электронное письмо, например, на xyz. сог,, это письмо вернется обратно, возмо*но, с сообщением об ошибке "Узел неизвестен".
Теперь допустим, что xvz . сот решила создать второй дополиитель~ ный сервер имен на Восточном побережье США, на узле abc.corr. Теперь, если xyz.com потеряет связь с Internel, возможность разрешать запросы сохранится за счет дополнительного сервера на abc. сот?,. Кроме того, xyz.com может ускорить выдачу ответов при разрешении запросов на внешние узлы, поскольку теперь смогут обрабатываться запросы и) разных частей страны. Электронное письмо на xyz.com в этом случае будет просто снова поставлено в очередь вследствие проблемы при доставке, а не вернется обратно.
Следующий пример показывает, как может выглядеть загрузочнып файл для дополнительного сервера имен.
,■ Каталог, в котором drib .ехе будет мекать пен хранить
;резервные файлы；
directory с：\winnt\sysLem32\dns
Дмректмвы для сертЕра “мен:Дмректмвы для сертЕра “мен:Tzn сервера secondary secondaryTzn сервера secondary secondaryexample.net1 . 165 . 1Q2 .二r.-addr , arpa0 , C-127.工n-addr.arpaexample.net1 . 165 . 1Q2 .二r.-addr , arpa0 , C-127.工n-addr.arpaИСТОЧНИК ДаНН=1Х 192.1G8.l.?20 192.168.1,220 hosts.localИСТОЧНИК ДаНН=1Х 192.1G8.l.?20 192.168.1,220 hosts.localРезерв hosts.db hosts.revРезерв hosts.db hosts.rev
Дмректмвы для сертЕра “мен:
Дмректмвы для сертЕра “мен:
Tzn сервера secondary secondary
Tzn сервера secondary secondary
example.net
1 . 165 . 1Q2 .二r.-addr , arpa
0 , C-127.工n-addr.arpa
example.net
1 . 165 . 1Q2 .二r.-addr , arpa
0 , C-127.工n-addr.arpa
ИСТОЧНИК ДаНН=1Х 192.1G8.l.?20 192.168.1,220 hosts.local
ИСТОЧНИК ДаНН=1Х 192.1G8.l.?20 192.168.1,220 hosts.local
Резерв hosts.db hosts.rev
Резерв hosts.db hosts.rev
Заметьте, чго в этом примере данные для домена исходят с узла 192.16b . 1,220, а сервер имен хранит резервную копию файла зоны по i названием hosts. db. Дополнительный сервер имен имеет такую же директиву cache, как и основной. Учтите, что сервер имен является основным для домена 0.0.127 . in-addr. агра, поскольку адрес обратной петли локгыьный для каждого компьютера, и поэтому каждый компьютер является основным сервером для сети своей обратной петли.
Дополнительный сервер не является необходи\(ым для хранения резервной копии информации домена, но рекомендуется. Локальное резервирование означает, что сервер имен запускается быстрее, поскольку нс должен при запуске соединяться с основным сервером для получения данных зоны, и, если данные имеют самую новую версию, лишь проверяет, не появилась ли новая информация зоны. Это не гарантирует, что исходный набор данных имеет самую новую версию, но сервер имен по крайней мере может начать отвечать на запросы, основываясь на те\ данных, которые он имеет.
Серверы имен, предназначенные только для кэширования
Серверы, выделеннь|е только для кэширования, способны повысить производительность серверов DNS в локальной сети. Там, где запросы DNS касаются одних и тех же мест, сервер имен, предназначенный только для кэширования, может ускорить выдачу ответов на запросы, не сталкиваясь с адм11нистративными проблемахн основного пли дополнительного сервера имен и не вызывая перегрузку сети за счет передачи зоны. Серверы только для кэширования не требуют больших усилий в плане настройки и работы, как показано в следующем примере.
； Каталог, в котором dns.exe Судет искать или хранить
；резервные файлы：
directoryс : \winnt\systет32 \ dr.s
；Директивы для сервера имен:
；Тип сервереДеменKctoyhhf данных
primary0 . О . 12"?. in -addr . arpa hosts.local
cache.caclie
В файле конфигурации сервера, предусмотренного только для кэиш- рования, должны быть лишь злементм для каталога, домена обратной петли 0 . О ..丄匸-adar . агра и директива cauhe.
Единственное требование к такому серверу — правильный файл корневого кэша, включаюши11 сам сервер имен. Поскольку выделенный для кэширования сервер не может бь(ть авторитетным, он не может быть делегирован для домена. Указанные серверы могу! быть настроены так, чтобы перенаправлять запросы и затем кэшировать результаты для использования при ответах на будущие запросы.
Предназначенные только для кэширования серверы отлично подходят для организации, основные уелхги DNS которым предоставляет Inlernct- Провайдер и которые хотят повысить производительность, а также лля поддержки удаленных узлов с мелпеннммн каналами связи. Для настрЗ- КИ подобного сервера в Windows следует сначала установить и запустить Службы DNS. Кэш и обратная пет”兄 генерируются автоматически, как только инсталлирован новый сервер. Затем надо лишь обеспечить, чтобы служба запускалась после каждой перезагрузки сервера Windows или Другого перерыва в работе системы. Большая часть организашп! не будет Использовать услуги Inteniet-npoeaiuepa (Internet Service Provider. ISP) Для поддержки доменного окружения Windows, но локальное кзшнрова- Ние внешних имен из открытого пространства имен \ Iniernet- Провайдера или из вн\треннего сервера имен дает много преимушеств.
Главное преимущество — повым1ение производительности для многих Пользователе!!, которые в противном случае чрезмерно загрузили бы °ДИн сервер. Сервер перекладывает груз запросов на машину, предназначенную для этой пели. Недостаток, хотя н небольшой, состоит в том, что
сервер, выделенны11 только для кэширования, не всегда имеет точнхю информацию. Можно задать срок жизни (tiine-to-live, TTL), чтобы определить. как долго сервер будет хранить данные кэша. В Windows 2000 DNS реализовано кэширование типа NCACHE, или с отрицательным «т- ветом. Обычно это не создает трудностей, однако иногда может привести к некоторой путанице, особенно для администратора DNS, который вносит изменения и проверяет работу системы.
Прохождение запросов: узлы пересылки и подчиненные серверы
Сервер DNS может назначить другой сервер своим узлом пересылки (forwarder), определяя этим, куда он будет пересылать запросы, если не сможет на них ответить. Подчиненность (slave) делает сервер зависимым от своих пересылок при ответах на запросы, ограничивая его активность, т.е. це допуская, чтобы ом был клиентом у любого другого сервера DN、 В двух словах, главное различие между пересылающим и полчиненным серверами таково.
Пересылающий сервер. Посылает запросы определенной машине, своему узлу пересылки, ожидает некоторое малое время и затем начинает искать ответ сам.
Подчиненный сервер. Посылает запросы определенной машине, своему узлу перссьыки, и ожидает ответа. Подчиненны11 сервер нс пытается разрешить запросы сам.
Узел пересылки — машина, предназначенная для обработки запросов (рис 3.1).
Клиент DNS
Рис. 3,1. Узел пересылки обрабатывает запросы по требо* ванию другого сервера DNS
Клиенты, включая другие серверы DNS, после отправки запроса уз.】\ пересылки ожидают некоторое малое время и затем, если они нс подчи ненные, могут сами приступить к псшску ответа, если отклик от узла пересылки не прише.1- Поскольку через пересылающие серверы может пе-
\оедаваться огромное количество данных, они накапливают большой кэш Ноесов. Это полезно, если вы хотите накопить кэш д.1Я множества поль- артелей, имеющих партнеров с хорошим сетевым досчупом
рис. 3.1 иллюстрирует следующий процесс.
Клиент посылает запрос локальному серверу DNS
Локальный сервер DNS направляет запрос узлу пересылки и ожидает.
Узел пересылки пытается разрешить запрос локально и, если не может этого сделать, посылает запрос серверу имен в Internet и ожидает.
Если ответ не полнен, локальны<1 сервер DNS передает запрос серверу имен в hiternet.
Как пересылочный, так и локальный сервер DNS могут получить от- pgr и увеличить кэш на обоих серверах DNS.
Если сервер имен клиента имеет назначенный узел пересылки и подучает запрос, но не может найти ответ в своих локальных файлах зоны или в кэше, он не начинает рекурсивный поиск ответа. (Рекурсивные запросы описаны в славе 5, "Анализ запросов имен1'.) Вместо этого сервер Имен направляет запрос своему узлу пересылки. Этот узел производит поиск и выдает ответ. Если он нс возвращает ответа, сервер начинает рекурсивный поиск сам.
Существует много практических пр!(менени(1 пересылочных серверов. Одно из них — направление запроса нескольким серверам DNS с учетом, что все они работают и что при этом каждый нлиденньп! адрес узла кэшируется; этот кэ(и затем будет полезен при последующих запросах этого щш другого клиента. Однако более часто пересылки используются при работе двойных серверов DNS через брандмауэр. Организациям, подключенным к Internet, нужно разрешать имена узлов в Internei, однако они, возможно, по соображениям безопасност и не хотя г сами открывать свою сеть для Internet. В этом случае внутренний сервер DNS направляет все запросы об именах за пределами домена организации на внешний гсервер DNS для разрешения. Можно назначить узел пересылки так, что
Внутренний сервер получит разрешение раньше внешнего.
Подчиненные — это серверы, которые обязаны использовать пересылку (рис. 3.2). Подчиненные серверы посылают запросы одной или нескольким назначенным пересылочным машинам и ожидают ответа, ол- Нако не могут пытаться разрешить запрос сами, если пересылочный сервер не ответит достаточно быстро. Такой порядок особенно эффективен в Очестве меры безопасности, поскольку все запросы обязаны проходить П。одному маршруту от подчиненного сервера до пересылочного. В этом случае брандмауэр преодолевают санкционированные, предсказуемые исходящие запросы DNS, и, следовательно, можно реализовать надежную безопасность.
Клиент DNS
Рис. 3.2. Подчиненный сервер должен ожидать ответа от пересылочного
Рис. 3.2 иллюстрирует следующий процесс,
Клиент посылает запрос локальному серверу DNS.
Локальный сервер DNS направляет запрос узлу пересылки и ожидает
Узел пересылки пытается разрешить запрос локально и, если не может этого сделать, посылает запрос серверу имен в Internet к ожидает.
Если ответ не получен, подчиненный сервер (в данном случае локальный сервер DNS) не начинает собственного понска.
Как пересылочный, так и локальный сервер DNS могут получшъ ответ и увеличить кэш на обоих серверах DNS.
Подчиненные — это серверы DNS, предназначенные для работы с пересылочными серверами, с одним ограничением: подчиненные серверы принимают ответы только от установленных серверов имен, которым они направляют запросы. При таком порядке, возвращаясь к приведенному выше примеру, внутренний сервер выполняет разрешение все\ имен для внутренних узлов, так как обращается к внутренним серверам только для разрешения. Это позволяет контролировать, проходит ли разрешение на серверы Internet.
Внешний сервер выполняет разрешение всех внешних имен для за- шишенных узлов и для открытых узлов организации. Сервер DNS внутри брандмауэра должен обслуживать остальную часть внутреннею домена, чтобы закрытые имена и адреса не стали известны. Вспомните, что любую информацию в DNS можно раскрыть, просто послав запрос' Windows 2000 с интеграцией в Active Directory позволяет контролировать доступ с помощью списков контроля доступа (access control list, ACL),
Для настройки пересылочного сервера его загрузочный файл должен содержать директиву, указывают™ пересылку, или же можно ввести эти данные во вкладке Пересылка, шелкнув на ярлычке Пересылка диалогового окна Свойства сервера. Чтобы открыть его. просто выберите пункт Свойства из контекстного меню сервера. Если установить флажок Не использовать рекурсию, сервер будет настроен как подчиненный.
В любом случае надо указать адреса Inteniet Protocol (IP) компьюте- которым сервер будет передавать запросы. Ниже показаны пример- $ элементы загрузочного файла. Учтите, что directory соответствует Смешению, предусмотренному по умолчанию, Windows 2000. Однако М рекомендуем указывать эти данные, так как вы можете забыть о них.
I 夕 Каталог, в котором cns.exe букет хранить
.резервные файлы:
directorydirectory■ ■ L:\wir.nt\systen3 2\dns
directory
directory
Серверы имен, которые будут пересьшочными： forwarders132.168.3.72192.168.1.24
.гарантия, что сервер имен не будет сам отвечать
.на нелокальные для него запроси：
.или, в зависимости от версии:
option forwara-cr.lv
• Директивы для；Тип сервераprimary primary primary• Директивы для；Тип сервераprimary primary primaryИсточник данных hosts.db hosts.rev hosts.localИсточник данных hosts.db hosts.rev hosts.localсервера имен：
• Директивы для
；Тип сервера
primary primary primary
• Директивы для
；Тип сервера
primary primary primary
Источник данных hosts.db hosts.rev hosts.local
Источник данных hosts.db hosts.rev hosts.local
Домен
example.net
1.168.152.in—addr.arpa
0.0.12"? . i n—addr . arpa
Определение типа DNS
Ниже приведен список различных типов серверов DNS, что может помочь при выборе типа создаваемого сервера.
Основной или главный. Авторитетный для одной или нескольких зон. Зона — это данные для одного или нескольких доменов или же данные для части домена.
Дополнительный или подчиненный. Также авторитетный, но действует как резерв для основного сервера имен. Получает все данные зоны от основного сервера путем передачи.
Пересылочный. Сервер DNS, назначенный другим сервером для обработкл всех его запросов.
Подчиненный. Сервер DNS. настроенный для работы только с пересылочным. Должен использовать пересылку для всех запросов. Учтите, , что подчиненный и дополнительный серверы — не одно и то же.
Только для кэширования. Сервер, который накапливает кэи, адре- сов, когда обрабатывает запросы. Такой сервер не имеет данных своей зоны и лишь выполняет запросы для клиента.
、 Сервер DNS Windows 2000 может использоваться в любой из этих ро- 券货；интересным вариантом представляется подчиненный сервер、за ис- ^йоненнем того, что он в этой системе также является авторитетным для ■'Зной или нескольких зон. В главе 11 настройка серверов этих типов 1Ййесматривается более подробно.
Чтобы определить, сервер какого типа работает в сушествуюшеН системе, могут потребоваться права администратора; лалее、можно просмог- рсть загру ючкыи файл или реестр ilth просмотреть свойства сервера DNS и зоны, используя консоль управления DNS. Назначение сервера DNS объясняется в загрузочном файле систем UNIX. Там же описаны действия сервера имен, начиная с его назначения. Для Windows в этом файле содержится информация обо всех зонах, которые имеются на этом сервере, н об источниках ;ыя файла кэша. Если сервер имен запускаенн через реестр (его можно запуствь либо через реестр, либо через за门)у- зочный фа(1.1 конфигурации), загрузочный файл содержи г только упоминания обо всей этой информации.
Если используется консоль управления сервером DNS, шелкнитс пра- noli кнопке)!! мыши на олнаи из перечисленных зон. чтобы открыть диалоговое окно Свойства зоны. На рис. 3.3 показана вюазка Общие этого окна, в Koiopoii приводится ин(|юрмация о зоне, указывающая, основной этот сервер или дополнительны)! Если в списке нет ни оано订 зоны (кроме 12/. in-addr. arcej, то эю сервер для кэширования и, возможно, подчиненный. Чтобы определи гь, какой именно, проверьте файл к)- 山а или посмотрите на вклейку Корневые ссылки свойств сервера.
Рис. 3.3, Основные серверы ссылаются на файл зоны, в котором хранятся их данные
Если \ вас нет нрав администратора на это(1 машине, но вы знаете ” IP-адрес, можно запросить сервер jemch проверить запись SOA или _1К» бой из ес доменов. Если элемент источника в SOA указывает на эту же машину, можно с уверенностью утверждать, что этот компьютер оснои- ной для домена.
Дополнительный сервер может давать ав'1 оритстные данные для лю- М зоны, которую он получает при передаче от основного сервера. На с 3.3 показан。、как конфигурируется дополнительный сервер，В спи- IP-адрес перечисляются указанные для него главные серверы. Допол- Хтельный сервер можно поместить в локальную сеть (LAN) или в сег- ^рТ LAN, чтобы получить специализированный сервер для локальных запросов, уменьшить трафик в глобальной сеги (WAN) и повысить безо- Ясность. Также может понадобиться установить пересылающий сервер 風貝 кэширования на медленно работающем канале связи, поскольку он уменьшает требуемую пропускную способность, кэшируя ответы на запросы локально.
Если данная машина не имеет зон, она может быть сервером только ддд кэширования или дополнительным сервером, который еше не был делегирован для домена.
Резюме
Различные типы серверов DNS помогают создавать системы, разре- цщюшие проблемы и удовлетворяющие потребности службы имен. Основные серверы являются источниками данных, дополнительные — резервными, которые могут брать на себя час гь запросов; серверы только для кэширования мшхт снизить нагрузку сети, не создавая проблем с администрированием; пересылочные и подчиненные серверы повышают безопасность и помогают реализовать преимущества кэширования.
В главе 4、 uПодробная информация о ломене”、описывается, как построены записи DNS, каково их значение и как использовать записи ресурсов для определения взаимоотношений между серверами DNS.
Подробная информация о домене
В этой главе...
Записи ресурсов в базе данных. Из записей ресурсов (resource records. RR) складывается содержимое файлов зоны, и, как таковые, они составляют основу DNS. Как следует из названия, каждая запись ресурсов содержит информацию о ресурсе, важную для DNS. В чис^е этих ресурсов — другие серверы DNS и узлы, а также объявленные службы. В этом разделе речь пойдет о главных типах записей ресурсов и об их использовании.
Файл кэша (корневые ссылки) идентифицирует серверы имен домг- на корневого уровня, так что любой сервер DNS может легко найти корень дерена системы доменных имен. В этом разделе описывается фай^т кэша, его назначение и использование.
Делегирование. Регистрация основного сервера DNS в одном из центров InterNIC позволяет клиентам нз-за пределов домена получить доступ к списку имен вашего ломена. Дополнительные серверы надо опубликовать самостоятельно、используя записи серверов имен (Name Server, NS). В этом разделе приводятся причины, но которым следует публиковать дру,не авторитетные серверы.
,', Если бы DNS была живым существом, одни веши она делала бы ин- Сщнктивно. а другие осваивала бы только после обучения. В этой главе кццсываются основные функции, для которых была разработана DNS и йрторые она выполняет почти инстинктивно (на основе информации о ре- %)сах из своих файлов зон), и различные типы записей ресурсов, которые .^^но использовать, чтобы заставить DNS выполнять более сложные зада- ^^па ваших конкретных н\жп. (маршрутизацию почты, поиск информа- 而城门 размещении спужб и расширение инфраструктуры безопасности за ^^ обмена ключами). Мы воздержались от рассмотрения способности '◎NS к динамическому обновлению, которая появилась недавно.
Записи ресурсов в базе данных
$" Подобно любой реляционной базе данных, архитектура DNS склады- 糞ется из таблиц, каждая из которых содержит некоторое число записей. Таблицы базы данных DNS называются файлами зон. Бг)льи1ая часть за- 細се» имеет особое значение, поскольку они устанавливают местополо- 诵нне ресурсов и даже могут быть связаны с записями в других таблицах. Возможные типы записей ресурсов включают начальные записи зоны (Start 0f Authority, SOA), записи адресов (Address. А) и записи указателей (Pointer, PTR). Подробное описание наиболее часто применяемых типов записей приводится ниже в этой главе. В приложении Е, "Заинсн ресур- /Ё&В И файл кэша InterNIC'1, приведен полный список записей ресурсов.
' Какие записи присутствуют в файле зоны, зависит от нескольких обстоятельств. К какой зоне относится этот файл? Зоны прямого и обрат- чюго поиска, например, вместе содержат записи очень немногих типов, гракже содержимое файла зоны зависит от того, какую информацию хочет или должен опубликовать администратор DNS. Ниже вы нашлете Полную информацию о самых важных типах записей. О них и об их использовании следует знать все.
丿『 Если настроить Windows DNS для сохранения данных зоны в файлах, ■#1и будут помешены в каталог %windir%\system32\dns. В подкаталоге 八samples находятся файлы шаблонов, представляющие примеры фор- Шта файлов.
Windows DNS Server может хранить данные конфигурации и зоны в ?рех местах. Данные конфигурации всегда хранятся в реестре, а также 4(ргут храниться в совместимом с BIND загрузочном файле (как в снсте- #е UNIX). Данные зоны могут храниться в файлах зоны или в Active Uirectory. В реестре загрузочная конфигурация зоны находится в разделе JlKLM\System\CurreiitConsolSet\Services\DNS\Zones; файл называется BOOT. В отличие от файла UNIX NAM ED. BOOT, в Windows DNS Server Допускаются ТОЛЬКО директивы primary, secondary и cach^ На рис. 4.1 доказана вкладка Дополнительно свойств рядового сервера в Windows 'DNS Server.
DEMO1 - свойстваDEMO1 - свойстваГ7ППГ7ППРис. 4.1. Диалоговое окно Свойства Windows DNS Server, в котором можно задать параметр загрузкиРис. 4.1. Диалоговое окно Свойства Windows DNS Server, в котором можно задать параметр загрузки
DEMO1 - свойства
DEMO1 - свойства
Г7ПП
Г7ПП
Рис. 4.1. Диалоговое окно Свойства Windows DNS Server, в котором можно задать параметр загрузки
Рис. 4.1. Диалоговое окно Свойства Windows DNS Server, в котором можно задать параметр загрузки
Если в списке Загрузить зону при старте выбрано значение Из файла, на основании информации из реестра создается загрузочный файл. Если выбрать значение Из реестра, первонача.!1ьный загрузочный файл перемешается в катаю г .\Ьаск】；р. В любом случае в реестр всегда записывается текущая информация. Изменение происходит немедленно, ес.т шелкнупь на кнопке Применить,
Может ввес[Н в заблуждение ют факт, что данные зоны всегда хранятся в фа!1_1ах, если только не используется Active Directory, Вопреки названию этого параметра на рис. 4,1, данные зоны (т.е. текущие записи ресурсов) хранятся не в реестре. Если информация зоны хранится в Active Directory, записи зоны преобразуются в объекты каталога, которые можно просматривать с помошыо облегченного протокола службы каталогов (Lightweight Directory Access Protocol, LDAP), и на основном сервере vxe не осгается файла зоны, хотя такие факзы сохраняются на дополнительных. Поэтому загрузки Из файла здесь нет.
Форматы файлов зоны в Windows DNS соответствуют требованиям RFC, и поэтому примеры в эюй главе равным образом пригодны и д.1я файлов зоны BIND, и для файлов зоны Windows DNS. Во всяком случае, здесь содержится бсльше “нформаинн, нем можно увидеть в интерфсцсе управления Windows DNS. Просто представьте, что в действительности сохраняемая структура сложнее, чем это видно, поскольку консоль управ к ния упрошает картнну. отбирая изображаемые данные и разумно устанавливая значения по молчанию для некоторых настраиваемых параметров
RFC 1035. RFC 1183, RFC 1164, RFC 1886, RFC 2052, RFC 2181, RFC 七535 и RFC 2672 (доступные в Internet на www. isi. edu) являются наибо- \ee авторитетными документами, описывающими формат записей ресур- Хв. Windows DNS автоматически форматирует записи при использова- $м консоли управления Windows DNS, Напротив, в случае загрузочного фЪла, например для перемещения данных из Windows DNS в BIND илн ^атно, необходимо точно знать, как форматировать записи в текстовом редакторе и как сделать фзм приемлемым для Windows. В Windows DNS Йсть хорошая функция, которая позволяет создавать конфигурацию с помощью консоли управления DNS Server, а затем сохранять ее в загрузои- HUM файле. Конечно, это полезно, если вы перемешаете данные из Windows DNS в систему на базе UNIX/BIND, а не наоборот.
Синтаксис записей ресурсов
В следующем фрагменте из RFC 1035 (стр. 32-34), напнеанном По- 4PM Мокапетрисом (Paul Mockapetris), описывается синтаксис записей ресурсов.
формат этих файлов представляет собой последовательность записей. Записи, как правило, занимают одну строку, хотя круглые скобки могут Использоваться для продолжения списка элементов на другой строке, а текстовые литералы мо】ут содержать концы строк. Любая комбинация Муляторов и пробелов рассматривается как разделитель между элемен- 叩乩 cocтaвляю[llи^ш запись. Любая строка [лавного файла может за- _ канчиваться комментарием. Комментарий начинается с ； (точки с запятой). Определены следующие записи-
<про6е”>[<ксмментарий>]
$ORIGIN <доменное имя> [<комментарий>]
$INCLUDE <> [<имя файлг>] [<доменное ммв>][〈комментарий〉) 」 〈доменное ш.：я'»< г г> [<комментарий>]
<про6ел><гг> [ "-юм1-1ентйрий> j
Пустые строки, с комментариями или без, допускаются в любом мес- ТС файла. Определены две управляющие записи: $orig：N и $ INCLUDE. За $ ORIGIN следует доменное имя, которое будет исходным пунктом для Относительных доменных имен. $ include вставляет указанный файл в текущий файл и может указывать доменное имя как исходный пункт для Относительных доменных имен во вставленном файле. Учтите, что MNCLUDE не изменяет исходный пункт в родигсльском файле, независима от изменений исходного пункта для относительных имен во вставленном файле.
Последние две формы соответствуют записям ресурсов (RR). Если за- ^Ись, содержащая RR, начинается с пробела, RR считается принадлежащей последнему \становленному доменному имени. Если запись RR наЧИнается с доменного имени, она устанавливает принадлежность к этому Имени. Содержимое <гг> может иметь одну из следующих форм.
[<TTL>] (<класс>) <тип> <RDATA>
(<класи>] [<TTL>] <тип> <RDATA>
RR начинается с необязательных полей срока жизни (time-to-live, TTL) и класса, за которыми следуют поле типа и поле RDATA, соотве” ствующее типу и классу. Поля класса и типа используют стандартную мнемонику, TTL представляет собой десятичное число. Опушенные значения класса и TTL соответствуют последним явно указанным значениям. Поскольку мнемоники типа и класса различны, при синтаксическом анализе они не смешиваются. (Учтите, что этот порядок отличается от используемого в примерах или в реальных RR; данный порядок облегчает синтаксический анализ и расстановку значений, предусмотренных по умолчанию.)
Доменные имена составляют значительную часть данных в главном файле.
Метки в доменном имени изображаются строками символов и отделяются друг от друга точками. Соглашения по выделению допускают присутствие в доменных именах произвольных символов. Доменные имена, которые заканчиваются точкой, называются абсолютными и рассматриваются как полные. Доменные имена, в конце которых ие стоит точка, называются относительными; фактически доменное имя является объединением относительной части и исходного пункта, указанного в записях SORIGIN, SINCLUDE или в аргументе процедуры, загружающей главный файл. Если исходный пункт недоступен, относительное имя производит ошибку.
Строки символов изображаются одним из двух способов: как непрерывный набор символов без внутренних пробелов, либо как строка, которая начинается и заканчивается символом ?. Внутри этой строки допускаются любые символы. Символ ? как таковой в строке должен быть выделен символом \ (обратной коъсой чертой),
Поскольку эти файлы являются текстовыми, для включения произвольных данных необходимы некоторые специальные коды, в частности следующие.
Корневой уровень
@ Свободно расположенный @ обозначает текущий исходный пункт
\х где X— любой символ, кроме цифр (0-9), служит для выделения символа так, чтобы его специальное значение не использовалось Например, ?\ . ? можно применять для включения в метку точки
\dddd где каждое D — цифра, означает октет, соответствующий десятичному числу, записанному цифрами dddd Получившийся в результате октет рассматривается как текст, и его специальное значение не учитывается
() Скобки служат для группировки данных, выходящих за пределы строки. В результате концы строк в скобках не учитываются
; Точка с запятой отмечает начало комментариев; оставшаяся часть строки игнорируется
^V' Синтаксис и примеры отдельных типов RR, приведенных ниже в этой 'Алаве, также описаны в RFC 1035 и RFC 2052. Эти документы являются ,-^горитетнммн источниками для форматов главного файла. Однако сле- 'Хет сделать несколько замечаний.
'-К. Записи RR анализируются без учета регистра, поэтому записи "“ hostname, HOSTNAME, HoSTNAme равнозначны.
二. ■ Имена в RR могут содержать до 63 символов на каждую метку и до 255 символов на FQDN.
‘：：’■ Символы подчеркивания в RR служб (Service) в текущей версии RFC 2052 предназначены (возможно, временно) для указания по- _： лей службы и протокола. Последний проект RFC 2052bis, призван- J иый заменить RFC 2052, — draft-ietf-ansind-rfc2052bis- r 05.txt от 16 ноября 1999 г.
*' ■ В целях глобализации в RFC 2044 была добавлена станлартизован- f ная поддержка расширенных наборов символов. Вместо этого до- ■' кумента теперь действует RFC 2079, Принятый в RFC 2079 стандарт UTF-8, который не является специфическим для DNS, встро- А . ен в поддержку RR в Windows 2000 DNS,
「Использование символа подчеркивания
? Подчеркивание обычно применяется в схемах именования Windows NT, но . 8здает проблему при отображении имен NetBIOS на пространство имен DNS.
',.Администраторы Windows должны знать, что символ подчеркивания в настоя- 二■',.• щее время не допускается в именах узлов и доменов DNS Хотя некоторые "серверы имен только "ругаются" на использование подчеркиваний, другие воз- •； вращают ошибку или отклоняют запрос в целом В Windows 2000 зто обычно ■ . 8здает меньше трудностей, так как пространства имен DNS и Windows должны ■ бьпъ тесно связаны. Однако обратите внимание на тот факт, что использова- U ' ние в именах UTF-8 или таких специальных символов, как подчеркивание, 丿：；представляет проблему при взаимодействии серверов DNS.
Записи SOA
^; Запись SOA должна быть первой во всех файлах прямых и обратных .^^i-addr. агра) зон. Записи SOA (определенные в RFC 1035) содержат ТЖЯСНейшую информацию, необходимую каждому домену. Прежде всего, ?^№Ись SOA указывает, како兑 сервер имен является источником автори- _^^Н°й информации для домена. На рис. 4.2 показано диалоговое окно ^^Ойства зоны, раскрытое на вкладке Начальная запись (SOA). До ^^°йств зоны можно добраться, выделив значок зоны в списке на левой ^^С〃Н консоли управления сервером DNS и выбрав в контекстном ме- ^^> (щелчок правой кнопкой мыши) пункт Свойства.
Рис. 4,2. В свойствах зоны Windows DNS Server отображается информация записи ресурсов SOA
Записи SOA крайне важны. (Некоторые из их компонентов показаны на рис. 4.2,). В следуюшем списке перечислены все возможные параметры этих записей (но не точно в том виде, в каком они отображаются на консоли управления Windows DNS Server). Шаблон записи ресурсов SOA выглядит так.
<владелец> <ttl> IN SOA <источник файла зонн> <почтовый адрес〉 Ксерийный номер〉 〈интервал обновления> <повтор>
〈срок действия>
<m-ttl>}
владелец указывает на исходный пункт зоны, или на то, какой домен представляет файл зоны. В Windows DNS владельцы — доменные имена, которые отображаются в списке серверов под именами серверов и автоматически вносятся в базу данных.
ttl. По умолчанию для TTL домена задан минимальный срок жизни (см. последний злемент в списке, m-ttl). Если значение TTL указано, оно используется для данной записи вместо значения. предусмотренного по умолчанию (m-ttl).
класс. По умолчанию для SOA установлен класс in (Internet).
тип. Присутствие букв SOA в колонке типа записи ресурсов означает, что эта запись показывает, какой DNS обладает наивысшими полномочиями для домена.
источник файла зоны ——имя узла основного сервера DNS для домена, В Windows DNS этот элемент создается автоматически, ес- дк применяется консоль управления,
почтовый адрес ——имя DNS почтового яшика ответственного дица. Почтовый яшик — элемент, который обычно указывает на адрес электронной почты администратора “омена. Записывается в формате с точкой, т.е., например, action. cnri . reston. va . us, что преобразуется в action@cnri . reston. va . us. action — возможный почтовый адрес системного администратора CNRI.
серийньда номер обеспечивает контроль версий. Если в файле зоны производятся изменения и серийный номер увеличивается, подчиненный сервер принимает эти изменения, Если номер не увеличился, подчиненный сервер считает, что правильны его данные, и не начинает переноса обновленных данных. Подчиненный сервер запрашивает серийный номер у главного и сравнивает его с номером своих данных. Если оказывается, что номер главного сервера больше, подчиненный сервер инициирует передачу зоны. В случае, когда
номера главного и подчиненного серверов одинаковы, передачи не происходит. Если серийный номер у главного сервера меньше, чем у подчиненного, передачи зоны не происходит и подчиненный сервер записывает сообщение об этом в свой журнал ошибок.
■ интервал обноиления сообщает подчиненному серверу, как часто он должен производить обновление зоны. Интервал обновления также можно назвать циклом обновления. Когда время обновления подчиненного сервера истекает, проверяется серийный номер и определяется, произоцьчи ли изменения, требующие передачи зо- ♦ иы. Если изменение было сделано и серийный номер увеличился, подчиненные серверы перезагружают зону и записывают новый 'V серийный номер, В главе 5, "Анализ запросов имен", рассказывается о добавочных и полных передачах зон.
'■ повтор. Интервал повтора указывает, как скоро дополнительные серверы должны начинать новую попытку обновления зоны, если :предыдущая нс удалась.
■ срок действия указывает, как долго дополнительный сервер может выдавать авторитетные ответы, если все попытки обновления j， ие удались. В случае, если обновление не выполняется из-за непо- ；' ладок с основным сервером, дополнительные серверы продолжают :' отвечать на запросы, пока срок действия зоны не кончится- Если '? основной сервер возвращается в строй, дополнительные серверы .；, производят обновление и все снова в порядке. Если срок действия ' зоны истекает без обновления, дополнительные серверы прекращают отвечать на запросы по этому домену.
■ m-ttl — минимальный срок жизни (minimum time-to-live, M-TTL)； определяет по умолчанию, в течение какого срока (TTL) ответ может считаться пригодным, если значение TTL для него не указано. Когда клиент запрашивает сервер DNS, он получает информаиню TTL вместе с ответом, чак что ему известно, какое время он мо人ет использовать (держать в кэше) этот ответ, не проверяя его заново. Если данные меняются не часто, TTL может быть больше. Это 泯一 лает кэш более стабн/ьннм и уменьшает количество запросов. Малые значения TTL вызывают более быстрое устаревание кэша к_И!- ента. что ведет к увеличению частоты запросов одних и тех же записей. Указывать значения TTL в записях ресурсов не принято； обычно используется унаследованное значение TTL, заданное как М-TTL в записи ресурсов SOA для этого домена-
Вот как выглядит типичная запись SOA:
example.net. IN199912250001С8С036006Q480086400)example.net. IN199912250001С8С036006Q480086400)root.example.netroot.example.netSOA ns.example.net сер：1йньй номер интервал обновления повтор срок действия
example.net. IN
19991225000
1С8С0
3600
6Q4800
86400)
example.net. IN
19991225000
1С8С0
3600
6Q4800
86400)
root.example.net
root.example.net
Текущий исходный пункт (в данном случае example. пе【.)также может обозначаться символом ?. Поэтому приведенная выше запись SOA может выглядеть так:
IN SOA ns . exainple . r.et. root. example . net.IN SOA ns . exainple . r.et. root. example . net.1999122500019991225000604800604800cep”氏нМ номер интервал обневленнн повторсрок действияcep”氏нМ номер интервал обневленнн повторсрок действия
IN SOA ns . exainple . r.et. root. example . net.
IN SOA ns . exainple . r.et. root. example . net.
19991225000
19991225000
604800
604800
cep”氏нМ номер интервал обневленнн повтор
срок действия
cep”氏нМ номер интервал обневленнн повтор
срок действия
@ означает длинную форму: example. i^.et. Как было сказано выше, лоле ttl обычно игнорируется, так как по умолчанию значение m-LcL принимается для всех записей в зоне. Учтите, что все значения времени
указаны в секундах.
Записи серверов имен (NS)；
Записи серверов имен сообщают системе DNS, какие серверы являются делегированными для домена ил» для его субдоменов. Делегировав 1 ние дает серверу потпюмочмя отвечать на запросы. Это похоже на назна-' чение начальником своих заместителей. Сервер имен может делегировать всю ответственность за субдомен другим серверам, или же основной сер- I вер может делегировать дополнительным право отвечать на запросы.二а-, же если они не являются первоисточниками данных адресов. В р;п;к'ле , ■tДe,^eгиpoвaниe,^ ниже в этой главе делегирование описывается 6()】ее подробно. На рис. 4.3 показано диалоговое окно Свойства зоны, открытое на вкладке записей NS.
I example net - свойстваI example net - свойствамнумну|j Добавить"^| ■ Е»«миг4 [ Ипвпить|j Добавить"^| ■ Е»«миг4 [ Ипвпить
I example net - свойства
I example net - свойства
мну
мну
|j Добавить"^| ■ Е»«миг4 [ Ипвпить
|j Добавить"^| ■ Е»«миг4 [ Ипвпить
1
Отнень :卜 Пр^ени” J j
Рис, 4 3. Информация о записи ресурсов NS в свойствах зоны Windows ONS Server
Записи NS используются в файлах как прямых, так и обратных зон и М^кют следующий формат:
<владелец> < ttl> I:i NS <уэел .ломен>
■" Первое поле записи — зладепец： оно указывает домен, для которого 蜂вер имен является авторитетным. За ним следует поле ttl. которое Обычно пусто, так как администраторы, как правило, полагаются на зна- ЧШие m-ttl в записи SOA. Следующее поле — класс, который почти веВДДа 工N (Internet), Затем идет указание типа записи — NS. Наконец, 竊聽13T поле узел. домен сервера имен, состоящее из полностью уточненного доменного имени для любого сервера, который может давать авторитетные ответы по домену. Оно содержит завершающую точку, чтобы 触познавателм воспринимали его как полностью уточненное доменное ^я (FQDN). Можно заметить сходство межд\- записями NS и SOA. Обе ^И содержат поля владелец, ttl и класс, которые могут быть одина- I^^mh в обеих записях.
.Для каждого делегированного сервера имен существует запись NS и '^Язующие" записи от родительских или корневых серверов, которые 嬲ЗЫВают иа делегированный сервер имен. Используя запись NR, мож- 鳖？Указать в домене дополнительные серверы имен, но они должны ис- 饗呼оваться только для внутренних клиентов. Внешним организациям ^^т известны только серверы имен, зарегистрированные в InterNIC и ^^^рованные для зоны.
Вероятно, следует заметить, что мы говорим о делегировании обычным способом. На консоли управления Windows 2000 DNS делегирование используется несколько по-иному. Здесь можно создать запись NS. выбрав либо команду Создать новую зону, либо команду Создать делегирование. В первом случае создается новая зона с записями NS н SOA на базе данного сервера. Во втором случае создаются субдомен в этой точке зоны и запись NS. Хотя документация Microsoft Windows 2000 довольно последовательна в использовании этих терминов, надо быть осторожным, так как делегирование часю имеет довольно определенное значение, используемое в этой главе,
Запись NS может выглядеть так:
example.net.INNSVENERA.ISI.EDU.
Или, более вероятно:,
INNSNS1.ISI.EDU.
INNSNS1.USC.EDU.
Поскольку первой записью в файле зоны является SOA м владелец объявлен в SOA, в записях NS в этом примере владелец не указан. Принимается, что владелец — текущий исходный пункт example. net.
Заметьте, что в этих записях не указано TTL и что серверы имен , NS1. ISI .EDU. hns1.USC.edu. ухазаны с помошью FQDN с завершаю-, шей точкой. Не требуется, чтобы делегированный сервер имен находился | в том же домене, что является одним из достоинств архитектуры DNS. В данном примере серверы имен имеют разные суффиксы доменов.
Записи PTR и обратный поиск
Записи PTR необходимы для обратного разрешения адресов. Если ib- вестен IP-адрес узла и необходимо узнать, каково имя этого узла, надо использовать обратное разрешение имен по адресам. Записи PTR сост л<- ляют большую Часть файла зоны домена [перевернутый номер с, ти) . in-addr. агра. На рис. 4.4 показано диалоговое окно Свойства DNS для записей PTR.'
Шаблон PTR выглядит так (см, также рис. 4.4):；
<впадепеи> <ttl> IN PTR <уэел.домен>
Например, записи в файле зонье на основном сервере имен домена 1.168.192. in—addr . агра могут иметь следующий вид:
@工NSOA ns.example.net.
hostmaster. example .net. (2C0002 17000 86400 3600 6OS-5OO 864UC：
INNS ns.example.net.
IMPTR ns.example,net.
IN PTR machine.example.net.
Прежде всего обратите внимание на завершающую точку после имен узлов, которая гарантирует, что никакой дополнительной информации ,пя этих имен не нужно. Это полностью уточненные доменные имена. Если завершающая точка не указана, к именам узлов добавляется исходный пункт домена. Ввиду того что этот исходный пункт — 工.二.168 .192 . addr .агра. результат получился бы довольно некрасивым.
Г7Т^
a«oserenbEPTR-Foiraer!-|
Подсеть
Шта№1 времени зепкси
2 - свойства
|Р41Онврцзла
Нга изпа
&юк жизни CTTU зегевд!
Отмена
Рис, 4,4. Свойства записи PTR в Windows DNS Server
.' Поскольку этот файл зоны представляет обратное отображение адре- Ёов, к цифрам в записях PTR добавляются цифры 1.168.192. Следова- 1%льно, обратный адрес ns . example. net — 1.168.192. Поставив эти ^сла в обратном порядке, получим настоящий IP-адрес: 192.168.1.1.
В этом примере используется нотация сети класса С. Файл зоны in- 壑dr может быть другим для сети класса В. Для примера используем сеть *2.10.0.0. с доменным именем xyz.com. Запись в загрузочном файле 期忘 такой зоны in-addr может выглядеть так:
primary10,132.in-addr.агpa132.10.inaddг.arpa.dns
Файл зоны может иметь следующий вид:
@ INSOA ns.xyz.com
root.xyz.com (2000021700186400 3600 608400 86400)
1.1
■ . 1.2
，2.4
ns.xyz.com.
ns.xyz.com.
www.xyz.com.
mailhost.хуг.com
чтобы
же для
настройки
разделить файл по доменам:
зоны можно использовать оператор $origin,
@INSOA
rQOt.xyz.com (2000021^001 86400
SORIGIN 1.10.132.in-addr.arpa.
1INPTR
^ORIGIN 2.10.132.in—adar.arpa.
ns . xyz.com
3600 608400 8&00) ns . >:yz . com.
'.】♦INPTRwww.xyz.com.
« SORIGIN 4.10.132.in-addr.arpa.
■1 2INPTR mailhost.xyz.com.
Разбиение зон на логические разделы может значительно упростить работу с большими файлами зон. Оператор SORIGIN задает доменное имя для всех последующих записей ресурсов. Оператор $ INCLUDE позволяет еще больше упростить работу. Он дает возможность поместить записи PTR для каждого исходного пункта в отдельные файлы и затем вставить эти файл* в основной файл зоны в точке, где стоит s工NCLUDE. В результате файл зоны может выглядеть так:
@INSOA ns.xyz.com
root.xyz.com (2000021700186400 3600608400 86400)
INNS ns.xyz.corn.
$ORTGIN 1,10.132.in-addr.arpa.
SINCLUDE sub-net1.db
1INPTR ns.xyz.com.
SORIGIN 2.10.132.in-addr.arpa.
SINCLUDE sub-net2.db
1 - INPTR www.xvz.com
SORIGIN 4.10.132.in-addr.arpa.
$INCLUDE sub—net4. db
В этом примере три файла $INCLUDE для зон in-addr содержат записи PTR лчя соответствующих подсетей и узлов.
Иногда наличие доменов in-addr.агра, делегированных в границах обычной подсети полными октетами, не дает нужного эффекта. Один интересный подход к обратному поиску при использовании бесклассовой маршрутизации доменов Internet (classless internet domain routing, CIDR} основан на записях CNAME и делегировании субдоменов in-addr. m t 三а. Подробнее об этом см. в RFC 2317.
专 Ввод FQDN с завершающей точкой
Для Windows NT 4 в статье #Q154555 базы знаний Microsoft указывалось, 1Г когда следует, а когда не следует вводить FQDN с завершающей точкой на | консоли управления DNS. FQDN с завершающей точкой надо использовать 一 для имен серверов в полях DATA в записях (сервера имен NS, канонического имени CNAME, основного сервера имен SOA, сервера почты MX и т д ) В । этих полях указываются серверы, которые могут находиться и в домене, и за его пределами, и поэтому должны быть полностью уточнены. Не надо использовать FQDN с завершающей точкой для других имен, например расположенных на сервере (имени узла А. псевдонима для CNAME, домена для SOA или NS) Они уточняются в своем домене по логике других записей данных. На консоли Windows 2000 DNS Server, скорее всего, применяется похожий метод анализа, и условия, при которых можно вводить точки, если они не требуются, иногда не зависят от того, что записано в файле зоны.
Записи адресов (А)
Записи А отображают имена узлов на IP-адреса версии 4, Эти записи используются в файлах зон прямого просмотра и в файлах корневого кэша. Для 1Р версии 6 применяются соответствующие этим записям записи Quad А (АААА). По формату запись А подобна записи NS; она содержи1" поля владельца, класса, ttl, тип ресурса А и адрес узла. Порядок распо〕。-
жения полей ttl и класса может меняться. Если ttl стоит перед классом, .^1a запись также правильного формата. Несколько записей А для одного того же узла могут содержать разные IP-адреса; Windows 2000 DNS &rver циклически переходит от одной записи к другой.
Шаблон записи А выглядит так (см. также рис. 4.5):
<зладелец> <ttl> IN А <адрес>
,Запись А может иметь следующий вид:
, fslIN А 192.168.1.2
В записи А владелец — узел, названный в самой записи. Поскольку исходным пунктом SOA является example .net, владельцем в предыдущем примере фактически будет fsl. example . net, так как fsl написано '砧 завершающей точки. В подобном случае DNS автоматически добав- 奶ет к имени ресурса исходный пункт. В результате запросы на 4в1. example . net адресуются к этой записи и возвращается указанный в 曲材 IP-адрес. На рис. 4.5 показано диалоговое окно Свойства записи А 理 консоли управления DNS Server.
Рис. 4.5. Свойства записи А 8 Windows DNS Server
Как в предыдущих примерах, значение TTL определяется по значе- >ю M-TTL в записи SOA. В записях А могут использоваться операторы ^ORIGIN и $ INCLUDE. Если основной сервер домена обслуживает еще и ^бдомены, можно использовать $OR工GHN, чтобы задать исходный пункт ；^W последующих записей, относящихся к субдоменам. Операторы ^NCLUDE, как и в записях PTR, могут упростить файлы зон за счет их .разбиения на более удобные группы.
Записи почтовых обменников (MX)
Записи MX содержат информацию о том, как может передаваться почта для членов домена. По формату запись MX подобна записи Ns. Она содержит поля владельца, ttl, класса и собственно ресурс. Кроме того, поле предпочтения позволяет установить порядок каждого узла са- значения, который может получать почту. Наличие записи MX, указывающей на какой-нибудь компьютер, не настраивает этот компьютер :心& пол^ения почты! На рис. 4.6 показана вкладка Свойства записи MX на консоли управления DNS Server.
[examp1e.net - свойства
Лотовый Обненник (М^ I
£шциелы>лй донен-
{e®ff¥*SJ«l
доменудомену“ Cmpesnow почтц, адоессеонк^ цквае(хэтсазпват、ремепьсьиа допек асл
домену
домену
■ поитоаому сереерд. определенному нижа.：
Узпумшломвну
LM?14 “о：：“，《>2(>1*|“，m“，，“
■ПЕИтваый бреер：
Г%и«Ч：ите1 почгавага sepaafie:
Ш'шш времени аолисм
СрдааРиямСГТУяв™^ : fi ^ ° °
Рис. 4.6, Свойства записи MX в Windows DNS Server
Шаблон записи MX выглядит так:
<владелец> <tti> IM MX <лредпочтенле> <обменн；4К ,домен>
Запись MX может иметь следующий вид (см. также рис. 4.6):
example.netIN MX 10 miilhub- example.net.
IN MX 10 ma丄Ihub.example.net.
Последняя строка иллюстрирует две особенности. Во-первых, если запись SOA — последняя запись в файле, задающая исходный пункт. MX автоматически становится обменником для почты, поступающей в домен example, net, который был указан в этой SOA. Внимание: порядок записей (то, что не посредствен но предшествует записи MX) имеет рещаюшее влияние, так что если непосредственно перед MX стояла запись типа А. а
SOA (например, secondfiddler IN A 152,168.1.32), to mailhub '^^^пЕ почтовым обменником для узла seccndf iddler. а не для домена '1Ple.net! Если владелец не указан, DNS считает, что владелец это；1 ~^^си — последний, который был указан в предыдущих записях.
'Поле предпочтения можно применять для использования в домене ‘^^мьких записей MX с разными обменниками. Это поле гарантирует, ^^д0ЧТа будет доставлена, а также позволяет создать избыточность для ^йчтового обмена. Значение предпочтения — число от 0 до 65535; мень- ЧИслу соответствует более высокий приоритет.
^Следующий пример демонстрирует использование поля предпочте-
^и чИсла 10, 20 и 30 обозначают предпочтения, причем приоритет 10 ■Ете. чем 20, а 20 — выше, чем 30.
@ IN ；-20000217001@ IN ；-2000021700111 - тм оса пз . example .net.root. example . net.(
@ IN ；
-20000217001
@ IN ；
-20000217001
1090010203010900102030360060480086400)
10900
10
20
30
10900
10
20
30
mailhub.example.net. mailhub2.example.net.
mailhub3,example,net,
尸・ В этом примере все три записи MX используются в домене '載号mple.net. Предпочтение показывает, что приоритетным почтовым Сменником является mailhub.
и mailhub2 не могу г отве-и mailhub2 не могу г отве-Г Если mailhub недоступен или слишком занят, почта может быть на-
и mailhub2 не могу г отве-
и mailhub2 не могу г отве-
Ц^влена на mailhucZ. Если же и mailhub, Йть, в действие вступает mailhubs.
Создание циклов почтовыми программами
Следует принять меры предосторожности против создания программами почтового обмена, такими как Sendmail, циклов, которые сделают доставку ,почты невозможной В цикле почта пересылается по кругу, не достигая окончательного назначения Это происходит, например, если почтовый агент (mail Iransfer agent, МТА) посылает почту на один компьютер, который передает ее на другой, а последний компьютер — опять на исходную машину Некоторые почтовые программы предотвращают образование циклов, не используя записи MX для локальных узлов или других машин с одинаковым или более ■ низким предпочтением
Записи CNAME
,В двух словах, запись CNAME создает псевдоним. Псевдоним 鯉as) — это имя, которое указывает или ссылается на apyroii узел. 礫АМЕ можно использовать, например, для работы основного сервера ^•ен DNS и почтового узла на одной н той же машине. На рис. 4.7 по- ^ано диалоговое окно Свойства запнен CNAME на консоли управления WS Server. '
У Рассмотрим следующий сценарий. Организация регистрирует ^™txyz.com как основной сервер DNS для своего домена. Однако почто- •期я программа может потребовать, чтобы использовалось специальное
имя компьютера, например mailhosc. Чтобы разрешить эту проблему, настоящим именем компьютера можно сделать ns.xyz.com и добавить запись CNAME, которая будет направлять трафик для mailhost на ns.xyz.com. Разберем и другой сценарий. Организация использует ftp.xyz.com в качестве основного сервера для трафика по протоколу передачи файлов (FTP) в своем домене. Эта же организация намерена запустить Web-сервер, который должен называться www.xyz.com, но помешаться на той же машине, что и сервер FTP. В этом случае можно добавить запись CNAME, которая будет направлять WWW-трафик на f tp. х у z , с от.
mailhost - свойства
£оаига1ьский анен
Цмадонют (если не указан иелпяьзуется зга роалонажц
Попное ама ктечного уз паПопное ама ктечного уз па厄厄
Попное ама ктечного уз па
Попное ама ктечного уз па
厄
厄
•й1тамп»ремвниавписй
фок4Изни<ГТ1Д записи
■ Отмена I I■ Отмена I I
■ Отмена I I
■ Отмена I I
Рис. 4.7. Свойства записи CNAME в Windows DNS ServerРис. 4.7. Свойства записи CNAME в Windows DNS ServerДля выполнения этого примера записи в такими.Для выполнения этого примера записи в такими.файле зоны должны бытьфайле зоны должны быть
Рис. 4.7. Свойства записи CNAME в Windows DNS Server
Рис. 4.7. Свойства записи CNAME в Windows DNS Server
Для выполнения этого примера записи в такими.
Для выполнения этого примера записи в такими.
файле зоны должны быть
файле зоны должны быть
2000021700120000217001mailhost ftpmailhost ftpiSOA10800:INSICNAMEiSOA10800:INSICNAMEns . xyz . coir3600 一 604800ns.xyz.com.132.165.23.1； ns.工yz.com.132.165.23.2； f гр . :-:yz . coirns . xyz . coir3600 一 604800ns.xyz.com.132.165.23.1； ns.工yz.com.132.165.23.2； f гр . :-:yz . coir:oot.xyz.com (86400}:oot.xyz.com (86400}
20000217001
20000217001
mailhost ftp
mailhost ftp
iSOA
10800:
INS
ICNAME
iSOA
10800:
INS
ICNAME
ns . xyz . coir3600 一 604800
ns.xyz.com.
132.165.23.1
； ns.工yz.com.
132.165.23.2
； f гр . :-:yz . coir
ns . xyz . coir3600 一 604800
ns.xyz.com.
132.165.23.1
； ns.工yz.com.
132.165.23.2
； f гр . :-:yz . coir
:oot.xyz.com (86400}
:oot.xyz.com (86400}
будут разрешаться правнль-будут разрешаться правнль-Имена mailhost, xyz . com
будут разрешаться правнль-
будут разрешаться правнль-
но, давая в результате один и тол же 1Р-а」рес: то же относится к именам ftp И WWW.
加加рассмотрим другой, более простой пример указания адресов длярассмотрим другой, более простой пример указания адресов дляЬдасб FTP而 ServeriЬдасб FTP而 ServeriИ WWW.И WWW.С NAMECNAMEС NAMECNAME10.1Э.10.10ServeriServeri10.1Э.10.10ServeriServeri
加
加
рассмотрим другой, более простой пример указания адресов для
рассмотрим другой, более простой пример указания адресов для
Ьдасб FTP
而 Serveri
Ьдасб FTP
而 Serveri
И WWW.
И WWW.
С NAME
CNAME
С NAME
CNAME
10.1Э.10.10
Serveri
Serveri
10.1Э.10.10
Serveri
Serveri
также можно применять для любых других служб,также можно применять для любых других служб,^ Записи CNAME
также можно применять для любых других служб,
также можно применять для любых других служб,
^пример TFTP. FTP и HTTPS. CNAME позволяют обозначать узлы, на ^^•OpHY размешаются эти службы, по любому удобному соглашению об ■』енах. Кроме того, они облегчают физическое изменение компьютеров I做 остановок в работе служб. В число практических преимуществ входят возможность обновления серверов без перерыва служб и повышения ■^юизводительности за счет ввода новых машин. Запись ресурсов
&NAME можно просто перенацелить на новый узел, и никто из окру- 瓚出0mНХ не будет об этом знать. Примечание. Указанное преимушество Появляется и при использовании записей SRV.
[
Указание на несуществующий узел
Записи MX или NS не могут указывать на узел, который реально не существует, т.е. назван только в записи CNAME. Все узлы, обозначенные в записях NS, также должны иметь запись А в том же файле зоны, чтобы они разрешались правильно. Если не выполнить одного из этих правил, сервер имен не прекратит работу, но будет выдавать сообщения об ошибках
Записи SRV
* С технической точки зрения запись ресурсов SRV является экспсри- I ментальной. Microsoft захотела создать фонд служб на базе записей SRV для локализации узлов, предоставляющих требуемые службы, чтобы отказаться от традиционных служб NetBIOS. В старых системах (NT 4 и Ниже) узлы, предоставляюшие различные службы, делали их доступными Ч^)ез объявления NetBIOS. В новых системах (Windows 2000) это произ- вещится с помошью записей SRV. Клиент должен быть осведомлен о :銀V, чтобы найти узлы, которые предоставляют требуемые службы через ®®И записи. Иными словами, если клиент не знает, что запросить у DNS. 评 не получит ответа. Если же клиент может запросить тип службы, то, ^ли ответ найден, он получит ]Р-адрсс (или адреса) требуемой службы.
" Пример — клиентская машина и пользователь, который хочет зарегн- #РИроваться. Чтобы пользователь мог это сделать, клиентская машина ^^жна идентифицировать его с использованием правильного контролле- 触 Домена. Другими словами, клиентская машина должна "знать", куда 5℃латъ запрос на идентификаиию. Клиент передает запрос DNS относи- ，爭ЛЬн。серверов, которые являются контроллерами домена для регметра- 醪И. Хотя зтот процесс в действительности более сложен м после опреде- 總叫! контроллеров домена вовлекает другие узлы, процесс идентифика- 峭*И Пользователя может продолжаться.
Записи SRV создаются процессом NETLOGON при изменении струк- тлры Active Directory, если разрешено динамическое обновление DNS. В противном случае надо создать вручную некоторое количество записей SRV. Ниже приведены примеры служб, для которых необходимы записи SRV. Записи SRV можно использовать для объявления других служб, кроме требуемых. На рис. 4.8 показан процесс создания записи SRV. объявляюшей сервер HTTP на узле fsl. example .net.
НИНИгй^ан：гй^ан：Запись нового ресурса
НИ
НИ
гй^ан：
гй^ан：
Г^ю，око&
；®ЙОрИгеТ<
Нойер порта.
.узвлэ1ойсли*6ы?
：|tEl e-omple，后t
Г ^йшигь “у эа»«а>, когда о“а устарей 色Г ^йшигь “у эа»«а>, когда о“а устарей 色.ffitewn времени,звт«^|.ffitewn времени,звт«^|Рис. 4,8. Создание записи SRV для объявления_http._Lcp . example, net на узле flРис. 4,8. Создание записи SRV для объявления_http._Lcp . example, net на узле flбок ^ани (THJ записибок ^ани (THJ записи
Г ^йшигь “у эа»«а>, когда о“а устарей 色
Г ^йшигь “у эа»«а>, когда о“а устарей 色
.ffitewn времени,звт«^|
.ffitewn времени,звт«^|
Рис. 4,8. Создание записи SRV для объявления
_http._Lcp . example, net на узле fl
Рис. 4,8. Создание записи SRV для объявления
_http._Lcp . example, net на узле fl
бок ^ани (THJ записи
бок ^ани (THJ записи
Записи SRV имеют следующий формат:
<с〃у*6а>.〈протокол〉 <ttl> <кпасс> <приоситет> <вес> <порт>
Учтите, что между обозначениями службы и протокола необходима точка. Значение <приоритет> действует подобно значению предпочтения в записи MX: указывает приоритетного провайдера на основе наименьшего значения этого поля. Значения могут находиться в пределах от 0 до 65535. Значения <вес> используются, когда присутствует несколько записей с одинаковым приоритетом для одно；! и той же службы. Вес может находиться в пределах от 1 до 65535; ответы на запросы выдаются в пропорции весов, что обеспечивает более разумное распределение нагрузки, чем при простом циклическом переборе. Значение веса 0 надо использовать, если распределения нагрузки не нужно. В поле <иель〉может стоять точка, показывающая, что служба, указанная в этой записи, недоступна в домене.
Запись SRV может выглядеть так:
.__ldap._tcp ；Н SRV О О 389 г ds е г ver . example . net.
Ниже приведены некоторые типы объявленных в SRV служб, от которых зависит Active Directory.
' Idap._tcp.<доменнсе ммн>
позволяет клиентам наноать серверы LC^p для указанного домена Idap._tcp.<имя узла>._site$.〈доменное имя>
二 позволяет клиентам находить сервера Ldap для домена, наил/чшле для указанного узла
' _gc , _tcp . <игля леса>
позволяет клиентам находить серверы Гло&ального каталога ■ с помощью корневого домена Active Directory
_gc._tcp-<имя узка〉..sites.vhmh леса>
позволяет клиентам находить наилучшие для данного узла серверы Глобального каталога
. с помощью корневсго 二омена Active Directory
_kerberos.一tcp.<доменное имя>
позволяет клиентам нахолмть слу;кбы
. Центра распространения ключей Kerberos
г (Kerberos Key Distribution Center, KDC) для данного домена
_kerberos. udp.<доменное имн>
то же самое, но с испольэоаанием протокола UDP, а не TCP _kerberos-_tcp.<имя узла>._sites.<доменное имя>
позволяет клиентам находить серверы KDC для домена, наилучшие для указанного узла
_kpasswd. tcp.<доменное нм兌〉
-позволяет клиентам находить е домене
службы изменения паролей Kerberos
наилучшие для указанно?1。узла
_kpasswd._\.dp.〈доменное ммн>
-то же самое, но с использованием протокола UDP, а не TCP
Также следует заметить, что некоторое число записей SRV с первым спецификатором _mscds перед доменным именем или именем леса используется для структуризации поддающегося запросам дерева категорий контроллеров домена и их служб, которое позволяет клиентам и службам .Active Directory определять их местоположение путем простых, а не поСЛедовательно связанных запросов. Это похоже на использование _sites Для создания выборки лучших местоположений служб для конкретных ■ узлов в Active Directorv.
Записи серверов имен Internet для
Windows (WINS)
Записи типа WINS поддерживаются в Microsoft DNS Server и в некото- .рых других серверах DNS, созданных специально для Windows 20OO/NT. :Эти записи ресурсов не соответствуют требованиям RFC. По формату за- ._ПИси WINS похожи на другие записи, с несколькими незначительными ^.Дополнениями. Подробнее о WINS и их роли, очень похожей на действия
Пересылочньш серверов в DNS, см- в главе 16., "WINS: традиционные службы имен и разрешение". В двух словах, если имеются клиенты, зарегистрированные на сервере WINS, но не зарегистрированные в DNS записями А. запись WINS позволяет DNS отвечать на запросы по таким клиентам с именами NetBIOS прм условии, что они находятся в доменах, зона которых содержит на корневом уровне зту запись WINS.
Использование WINS и записи WINS в DNS порождает массу проблем, почему им и л освящена целая глава. Здесь же надо упомянуть, что эта запись должна опускаться при передаче зоны на серверы DNS, не являющиеся разработками Microsoft (за очень немногими исключениями). Она является частным расширением RFC. Поэтому только сервера DNS Microsoft знают, что делать с записью WINS. Очень вероятно, чго ваш lnteniet-провайдер не может предложить такой услуги.
Теоретически дополнительные серверы домена Windows также могул вести DNS Windows (не DNS на базе узлов UNIX), так что записи WINS могут распространяться на все серверы, для которых они необходимы Это удовлетворяет требованию, согласно которому основные и дополнительные серверы должны не только быть авторитетными, но и иметь одинаковый доступ ко всей информации. Если лишь некоторые серверы имен разрешают адреса WINS для домена, для клиентов работа DNS будет выглядеть неустойчивой,
В наиболее общем виде формат записи WINS выглядит так:
<ис:<одный пункт〉IN WIKS <LCCAL>
<L время поиска〉<С время кэш;-：рования> <1Р-адреса серверов WINS>
Здесь необязательное значение <L врем* поиска> — время, в течение которого DNS ожидает отклика от сервера WINS; по умолчанию в Windows 2000 — 2 секунды. Необязательное значение <С время кэширования> — срок, в течение которого DNS будет кэшировать отклик WINS; по умолчанию в Windows 2000 — 15 мин\т (указывается в секундах). Перед этими значениями, если они используются, должен стоять префикс L juiM С. Необяза|ельнь(й параметр LOCAL управляет распространением записи при передаче зоны. Если он указан, запись WINS не передается. Учтите, что управляющее значение М-TTL из записи SOA не действует на запись WINS, так как срок сохранения данных в DNS фактически указывает параметр <С времч кэшированяя>.
Таков прнмернмй вид записи WINS：
@ IN WINS LOCAL L 10 С 600 10.52.120.42
Самый простой способ воспользоваться преимуществами понска WINS — конечно, прибегнуть к помощи консоли управления Windows DNS, чтобы добавить в файл зоны запись WINS. Для этого выделите правильный корневой узел зоны на консоли управления DNS, шелкните правой кнопкой мыши и выберите из контекстного меню команду Свойства. В диалоговом окне Свойства зоны перейдите на вкладку WINS. Здесь можно добавить запись WINS, введя IP-адреса серверов WINS, каК показано на рис. 4.9.
,@ • Вводите адреса только высоконадежных серверов WINS и помните, 1 У 叨0, поскольку DNS должна связываться с WINS, если серверу DNS при- I дется просматривать все перечисленные серверы WINS, объем работы Сбудет слитком велик для него. Как сказано выше, данная запись должна фосодиться в корневой части зоны. Это означает, что WINS допускается ^я всех субдоменов под корневым доменом зоны Поэтому одно- ^инственное имя NetBIOS, распознанное WINS, может появиться как йзсколько полностью уточненных имен DNS. В связи с этим часто реко- ■修ндуется создавать и использовать исключительно для этой цели от- ；Л6ЛЬНМЙ домен, как показано на рисунке, где задействован новый домен hW；.example. net. На консоли управления Windows DNS Server этот до- (頁ен должен быть создан как новая зона.
|examp1c.net - свойства
：Овщие|Ночс1В.наязеписьзоны!Сврвгры.инен -WINS |nepeaew
.Мо»«о использовать 'AWJS иля разрвпешя инен, на найд&нньк по запросу к прЖ1рвнс!ву DHS
Р Испольаоееи.[ЗИ1мсйпроена1р ЛМЕ
Г Иевыпппняи.рнлпике1И1вэ5о0запи131 — -、。「
：1Р-эдрас-. .. .. ■
rl9：i Ibii 1 ＜；ll ~I
ДспошяцепьиоДспошяцепьиоС(зокжизни (ГП) эалмЕи р I и
Дспошяцепьио
Дспошяцепьио
I OK I Отнтне | Принени'ь
Рис, 4.9. Настройка прямого поиска WiNS для зоны
^ратные записи серверов имен Internet для ^ndows (WINS-R)
ДпЗаписн W1NS-R представляют собой вторую половину функций ^S. Эти записи ресурсов используются для доменов ： r.-adar. агра и иводяют DNS выполнять обратный поиск имен NetBIOS Формат за~ И WINS-R точно такой же, что у записи WINS; единственное отли- 以—файл зоны, где хранятся эти записи, и последний параметр.
Запнсь W1NS-R, в которой параметры local и времени играют ту же роль, что и в запнсм WINS, имеет следующий вид:
<домен владельца> IN WHNS-R <LOCAL>
<L время полска> <С время ь-эшироьани°> <пр>1бсьл.чемое доменнсе имя>
На консоли управления Windows DNS Server запись WINS-R создается в диалоговом окне Свойства зоны домена in-addr. агра (рис. 4.10). Чтобы использовать эту функцию, перейдите на вкладку WINS-R и укажите доменное имя, которое должно прибавляться к именам NetBIOS. Здесь также имеется флажок, указываюший, что запись WINS-R не должна передаваться при передаче зоны, если дополнительные серверы DNS не распознают записи этого типа.
Рис, 4,10. Настройка зоны обратного поиска in- addr.arpa для использования WINS-RРис, 4,10. Настройка зоны обратного поиска in- addr.arpa для использования WINS-R
Рис, 4,10. Настройка зоны обратного поиска in- addr.arpa для использования WINS-R
Рис, 4,10. Настройка зоны обратного поиска in- addr.arpa для использования WINS-R
Файл кэша
Файл кэша хранит адреса и имена серверов имен корневого уровня. Иногда этот файл называют файлом ссылок, поскольку он дает серверу
ссылки на те места, где надо искать, если сервер не может разрешить запрос сразу- Файл кэша не следует путать с кэшем сервера имен, который накапливается в ходе разрешения запросов. В отличие от него, файл кз- ша, как правило, содержит имена u IP-aupeca серверов корневого уровня.
卜 I >^лементы файла кэша для Internet постоянны (если InterNIC не добавит :* ровый сервер корневого уровня) и дают серверу последнюю возможность I 抬击айти ответ, если он не может определить местонахождение узла через I Т：стандартные делегирования. В документации Microsoft этот файл часто I <^азывается файлом корневых ссылок. В Windows 2000/NT он поставляет-
:臧 п°п названием cache, dns. На рис. 4.11 показано содержимое файла '^ша DNS Server. Откровенно говоря, оно не очень полезно в смысле :；.^формации, но без него DNS не сможет работать! DNS Server считает, :дю записи в файле кэша представляют реально существующие и дости- ' ^мые узлы. Если DNS не достигнет серверов корневого уровня при '•.( физрешении запросов, может образоваться безвыходны ji цикл.
'■■Рис. 4.11. Отображение файла корневых ссылок丁:；cache, dns в диалоговом окне Свойства сервера DNS'■■Рис. 4.11. Отображение файла корневых ссылок丁:；cache, dns в диалоговом окне Свойства сервера DNS
'■■Рис. 4.11. Отображение файла корневых ссылок
丁:；cache, dns в диалоговом окне Свойства сервера DNS
'■■Рис. 4.11. Отображение файла корневых ссылок
丁:；cache, dns в диалоговом окне Свойства сервера DNS
Й；( \ Изменять файл кэша можно, только если ваш сервер нс подключен к 'internet, если используется режим ""разделенного мозга" (split-brain) DNS "Y&Cjver, или если InlerNIC изменяет данные серверов корневого домена, 、产© бывает редко. Файл корневого кэша можно загрузить непосредствен- I1 Йо в InterNIC через FTP по адресу
। [佚tp：//rs.incernic.neI/doma丄n/named/root.
Заполнение файла кэша
Убедитесь, что файл кэша заполнен. Если ни один из серверов корневого уровня не указан, ваш сервер DNS может войти в бесконечный цикл. Поскольку не существует способа выйти из такой ситуации, вы не сможете раз- ]решить ни одного узла
Доступ к серверам корневого уровня через файл кэша
Серверы имен должны отвечать на запросы наилучшим возможным образом, даже если они не имеют локальной информации, необходимой для быстрого и непосредственного ответа. При рекурсивных запросах сервер DNS должен получить ответ из любого дру1ого места. Если подняться вверх по дереву поменов не удается, файл кэша позволяет серверу DNS обратиться прямо к корневому серверу на вершине дерева, где можно будет найти ссылки вниз по дереву, к авторитетному серверу DNS для домена указанного узла.
Если DNS не подключена к Internet нлм используется в режиме "разделенно】о мозга", файл кзша все равно должен указывать на сервер корневого домена. Если оказывается, что сервер имен корневого домена находится на верху дерева доменов частной сети, директива cache в загрузочной конфигурации заменяется на директиву primary, указываю- шую на файл зоны, который содержит имя и IP-адрес самого сервера имен, как имеющего полномочия корневого домена. Это законно и прекрасно работает. Запрос, на который такая машина не сможет самостоятельно ответить, даст такой же результат, что н для несуществующего домена. Если сервер имен может обратиться к машине, которую он считает корневым сервером, разрешение запроса будет продолжено ло успешного результата. Microsoft рекомендует альтернативный вариант — использовать отредактированный файл кэша, который должен содержать только "."или только те серверы, которые должны функционировать как корневые серверы в конкретном частном варианте DNS.
Делегирование
Делегирование обозначает процедуру назначения сервера имен. Первый и обязательный способ установить авторитетный сервер для домена второго уровня — зарегистрировать его в InterNIC. Обязательный способ определения авторитетного сервера для субдомена — делегирование из родительского домена. При делегировании основное и дополнительные серверы ^тпя домена/субдомеиа объявляются в Internet как авторитетные. Для делегирования сервера используется запись NS, с тем условием, что сервер имен должен быть связан с правильной записью А. Процелура регистрации домена в InterNIC фактически заключается в просьбе InterNIC делегировать полномочия для вашего домена серверам, которые указаны в регистрационной форме.
Если сервер имен имеет делегированные полномочия для домена, клиенты и другие серверы имен за пределами домена могут найти его и использовать для своих запросов. Как минимум два сервера имен, основной н дополнительный, должны быть определены как делегированные
'для домена. Однако это “с означает, что делегировать необходимо все дополнительные серверы. Делегированы должны быть только серверы имен, которые предполагается открыть для внешнего мира.
Дополнительные серверы также могут быть внутренними по отноше- I нию к домену, так что только узлы, непосредственно настроенные ипя ,работы с ними, будут посылать запросы на эти дополнительные серверы. Если дополнительный сервер делегирован, узлы могут обнаружить его с помощью запросов NS. Если сервер имен делегирован для иомена, но не настроен как дополнительный для этого домена, узлы. которые будут запрашивать домен через этот сервер, получат сообщение об ошибке ^Неправильное делегирование1'.
I
Следует еше раз подчеркнуть, что в документации по Microsoft DNS Server термин “иелс「нрованне" иногда употребляется в другом значении. Например, на консоли управления команда Создать делегирование создает не только запись NS, но н субдомен. В этой ситуации фактически делегируется новый субдомен.
t Резюме
» В этой славе описывается, какую информацию хранит DNS, и подробно рассматриваются наиболее важные записи ресурсов Кроме того, мы уделили внимание вопросам делегирования и принятия полномочий, а также файлу кэша (или корневым ссылкам).
Анализ запросов имен
В этой главе...
Вначале мы рассмотрим подробности запроса, а затем и весь процесс запроса.
Итеративные и рекурсивные запросы. Клиенты DNS могут использовать запросы двух типов: итеративные и рекурсивные. В этом разделе мы уясним разницу между ними.
Отправка запроса DNS. Здесь речь идет о сообщениях, которыми обмениваются клиенты и серверы DNS.
Срок жизни. Срок жизни сообщает клиенту, как долго ответ может считаться заслуживающим доверия, и определяет срок кэширования результата.
Процесс запроса. В зтом разделе ранее рассмотренные вопросы ихча- гаются в контексте всего процесса выполнения запроса клиента DNS,
Итеративные и рекурсивные запросы
Итеративные и рекурсивные запросы — это два типа запросов, которые могут быть направлены на сервер имен. Рекурсивные запросы чаше всего посылаются клиентами на свои локальные серверы имен. Когда
локальный сервер имен принимает рекурсивный запрос, он сначала пытается найти ответ сам, а клиент ожидает, пока сервер имен не закончит работу. Если локальный сервер еше не имеет ответа, он начинает искать ответ по ветвям дерева доменов. В главе 2、"Как работает DNS", приведен пример протокола поиска, вьщаваемого программой ^slookup.
При рекурсивном запросе сервер DNS продолжает поиск, пока не найдет ответа. Ответом может быть адрес узла Internet Protocol (IP) или сообщение, что такого узла не существует- В любом случае сервер имен возвращает ответ клиенту.
Сервер имен, настроенный для работы с пересылкой, направляет рекурсивный запрос серверу DNS, который назначен его узлом пересылки. Узел пересылки выполняет рекурсивный поиск, как и для любого другого запроса. Если локальный сервер имен не является подчиненным, спустя некоторое время он может сам начать работу над запросом, даже если ожидает ответа от пересылочного сервера. Если локальный сервер имен настроен как подчиненный по отношению к пересылочному, процесс несколько иной. Клиент может послать рекурсивный запрос локальному серверу имен； однако, если этот сервер имен подчиненный, он не работает над запросом сам, а направляет его узлу пересылки и ждет ответа от него. По сути, он становится агентом клиента и подчиненным пересылочного сервера. Подробное описание пересылочных н подчиненных серверов содержится в главе 3, ,ьТипы серверов нмен".
Итеративные вопросы обрабатываются несколько по-иному. Лучший пример итеративного запроса — когда локальный сервер имен запрашивает сервер корневого уровня. Если локальньн^ сервер и мен организации посылает запрос корневому серверу, последний необязательно берет на себя ответственность за предоставление ответа на запрос. Иными словами, корневой сервер не принимает рекурсивного запроса. В действительности сервер корневого уровня может выполнить только один этап разрешения запроса — направить локальный сервер имен за ответом в другое место. Обычно это называется направлением (referral) и является ответом на итеративный запрос. Например, если к корневому серверу поступает запрос на www.isi.edu, он не обращается к серверу имен IS] за адресом узла www. Вместо этого корневой сервер возвращает указание, куда должен обратиться локальный сервер имен.
Сервер имен дает на итеративный запрос '"обоснованный ответ" на базе своих данных. Итеративные и рекурсивные запросы подробно рассмотрены ниже в этой главе.
От叩авка запроса DNS
Пользователь начинает запрос службы имен, когда он пытается получить доступ к ресурсам в сети. Эти ресурсы могул находиться на другом компьютере в локальной сети или в любой точке мира. Как правило, пользователь вводит имя удаленного узла в командной строке либо ис-
пользует соответствующее приложение, например Netscape или Internet Explorer. Пользователь не знает, да и не может знать, где находится узел, на котором есть это имя. Введенное каким-либо способом, оно должно быть преобразовано в IP-адрес. Кроме того, пользователю не нужно знать, какую работу для него выполняет система доменных имен.
В зависимости от конфигурации локальной машины пользователя имя может быть разрешено несколькими способами. Один из способов разрешения имени узла — поиск в файле локального компьютера. Это файл не охватывает особенно большой области, почему в свое время и была создана система DNS. Если для разрешения имен удаленных узлов выбран метод DNS, локальный узел обращается к библиотеке своего распознавателя, чтобы определить, был ли выбран домен, используемый по умолчанию, установлен ли путь для поиска и каковы IP-адреса серверов имен. В Windows NT и 2000 эти данные задаются во вкладке DNS диалогового окна Свойства TCP/IP, как показано на рис. 5.1. (Установка этих параметров в клиентах рассматривается в главе 14, "Настройка и разрешение клиентов Windows''.)
|Сво“ства，Протокоп Мнтег|Сво“ства，Протокоп Мнтег(TCP/IP)(TCP/IP)Г7ШГ7Ш
|Сво“ства，Протокоп Мнтег
|Сво“ства，Протокоп Мнтег
(TCP/IP)
(TCP/IP)
Г7Ш
Г7Ш
ОВщие Г
Порвнетри1рнснх|1назнанатксчаетоматичеа-квс<исе1Ь
： .пйдлер*мванг згу ваэяо»иОС1к. В противном слйЧаа педамигвв；!?но*наполуить.у сетевого администратора ：'
1 Qoiufnm, IP^npec автоиатичаом
“ Цслосазозетьбвдующм" 1р*ш^ес
|р-плрас
Ывска подсети
i»i»Зснааной щаоз；
i»
i»
Пдешичигоемым DtiS-cepsaR
Альтврнвгывныи Dffi^cepssp..
Дополнительно..
Опека . IОпека . I
Опека . I
Опека . I
Рис. 5.1. Вкладка DNS диалогового окна Свойства TCP/IP
После того как эта информация корректно введена, узел может использовать DNS для разрешения имен узлов. После получения IP-адреса сервера имен локальный компьютер может послать серверу имен запрос на IP-адрес удаленного узла. IP-пакет, отправляемый на сервер имен, содержит пять разделов, как показано на рис. 52
ЗаголовокЗапросАвторитетный серверДополнительная информацияЗаголовокЗапросАвторитетный серверДополнительная информация—Запрос на этот сервер
Заголовок
Запрос
Авторитетный сервер
Дополнительная информация
Заголовок
Запрос
Авторитетный сервер
Дополнительная информация
—Записи ресурсов, содержащие ответ
—Записи ресурсов, указывающие на авторитетный сервер
—Записи ресурсов, содержащие дополнительную информацию
Рис. 5.2. Содержимое IP-лакета, отправляемого на сервер имен
Сообщения DNS (запросы или ответы) содержат определенные порции данных. Раздел заголовка, который присутствует всегда, содержит информацию о пакете, в том числе о том, какие разделы входят в состав пакета, запрос это или ответ, тип запроса (стандартный, обратный, статус сервера и т.〃.)и является ли ответ авторитетным. Формат заголовка по-
RFC 1035
RFC 1035 и дополнения к нему в последующих RFC содержат более под- К робную и достоверную информацию о содержимом сообщений DNS и его ко- 广 дировании.
Раздел Запрос пакета, показанного на рис. 5.2, включает три порции информации: доменное имя, которого касается запрос, тип запроса и его класс. Доменное имя может быть на самом Пеле именем узла, но это зависит от типа отправленного запроса. Если пользователь хочет зайти в Web-броузере на узел www.isi.edu. этот запрос будет запросом адреса. Пакет может содержать имя узла www. isi .edu в разделе Запрос, тип запроса изображается кодом записи адреса (А), а класс — кодом класса Internet (IN). На рис. 5.4 показан формат раздела Запрос пакета.
QNAME
QTYPE
CLASS
Рис, 5,4. Поле "Запрос" сообщения DNS
Разделы пакета Ответ, Аттор/теонЗ сересо и Допсл-ительная информация, как видно на рис. 5.2. одинаковы по своему формату. В состав этих разделов пакета входят поля имени, типа, класса, ttl, длины (указывает длину поля ресурсов) и сами данные ресурса. Поля имени, класса и типа в запросе и ответе должны быть идентичны. Поле ttl содержит срок жизни данных полученной записи, a RData представляет сам ответ.
В предыдущем примере поле имени включает www.isi.edu, а поле RData — IP-адрес узла. На рис. 5,5 показан формат полей Ответ, Авторитетный сервер и Дополнительная информация, одинаковый для всех них.
Рис. 5.5. Поля Ответ, Авторитетный сервер И Дополнительная информация сообщения DNS
Итак, клиент посылает запрос на свой локальный сервер имен. Сервер имен принимает запрос и приступает к поиску ответа. Для данного случая допустим, что все данные зоны, как авторитетные от делегированных самим сервером узлов, так и неавторитетные из обработки предыдущих запросов, загружаются в память и, таким образом, "кэшируются" при запуске сервера имен. Если в кэше сервера имен есть информация и срок ее жизни (TTL) не истек, сервер имен непосредственно вьшает эту информацию клиенту. В этом случае ответ возвращается спустя очень небольшое время. Если возвращаемый ответ не авторитетный, флаг ДА в заголовке не установлен.
Если в кэше сервера имен нет ответа, локальный сервер имен начина* ет опрашивать другие серверы, поднимаясь по дереву имен вверх до корня и спускаясь по другой ветви в поисках ответа. В этом случае, если локальный сервер имен наконец получает ответ для клиента.巾лаг АД устанавливается, подтверждая, что ответ пришел с авторитетного сервера. В конце концов, имея информацию, клиент может установить соединение с удаленным узлом.
При получении ответа от сервера имен клиент обычно интересуется авторитетностью ответа — т.е. тем, есть ли проблема с доступом к разрешенному узлу. Проблема возникает, если сервер лас】 неавторитетный ответ по домену, для которого он является авторитетным. Обычно это означает. что в данных зоны допущена ошибка.
В следующих разделах, "Ответ в кэше найден" и "Ответ в кэше не найден'', процесс кэширования результатов рассматривается более подробно.
Ответ в кэше найден
Если ответ на запрос клиента находится в локальном кэше сервера имен, выполняется последовательность действий, показанная на рис. 5.6.
Рис. 5 6. Клиент получает ответ на свой запрос из локального кэша сервера имен
Последовательность этих действий такова.
Клиент посылает запрос на сервер имен.
Сервер имен проверяет свой локальный кэш.
Если в локальном кэше имеется ответ, сервер имен непосредственно отправляет его клиенту.
Ответ в кэше не найден
Если ответа на запрос клиента в локальном кэше сервера имен нет, выполняется последовательность действий, показанная на рис. 5.7.
Последовательность этих действий такова.
Клиент посылает запрос на сервер имен.
Сервер имен проверяет свой локальный кэш. Если в локальном кэше ответа нет, сервер имен должен найти информацию в другом месте.
Сервер имен (в зависимости от его конфигурации) посылает запрос серверу корневого уровня и получает направление на авторитетный для запрашиваемого домена сервер.
После того как локальный сервер клиента получит ответ от авторитетного сервера, он помешает ответ в свой кэш и отвечает клиенту.
Сервер--------►Кзш
Рис, 5,7. Клиент получает ответ на свой запрос от авторитетного сервера
TTL
TTL — это временной индикатор, сообщающий серверу имен, как долго ответ может считаться пригодным после его получения от авторитетного сервера. Как показано в главе 4, ''Подробная информация о домене", TTL может быть установлен для каждой записи отдельно или принят по умолчанию по значению минимального срока жизни (М-TTL) в записи SOA. Если TTL отдельной записи отличается от принятого по умолчанию М-TTL. все последующие записи принимают это значение TTL, пока в какой-нибудь записи оно не будет явно изменено на M-TTL. Если TTL имеет нулевое значение, клиент не может кэшировать запись.
Использование TTL очень просто. Когда локальный сервер имен пользователя получает рекурсивный запрос на информацию, которой еще не имеет, локальный сервер имен должен получить ответ от авторитет-
ного сервера имен запрашиваемого домена, пройдя некоторую последовательность этапов. После того как локальный сервер имен получил ответ, он кэширует его на случай поступления от локальных узлов других запросов на ту же информацию. TTL указывает, как долго локальный сервер имен может сохранять полученный ответ в кэше. Если время TTL истекло, сервер удаляет информацию из кэша и должен обратиться к авторитетному серверу опять, если поступит другой запрос. Если TTL имеет нулевое значение, ответ не кэшируется и данные считаются пригодными только для текущего запроса. Если значение TTL не равно нулю, информация кэшируется и используется для неавторитетных ответов.
Процесс запроса
Здесь мы рассмотрим весь процесс разрешения запроса снова, но как одно целое, не сосредоточиваясь на значении сообщений или действиях и полномочиях серверов DNS.
Рекурсивные запросы DNS
При рекурсивных запросах сервер DNS берет на себя всю работу по получению авторитетного ответа для клиента. На рис. 5.8 показано, как клиент pc.acme.com посылает рекурсивный запрос серверу DNS acme. com.
На рис. 5.8 сервер DNS acme. com становится итеративным клиентом DNS/распознавателем для четырех других серверов DNS после того, как принимает рекурсивным запрос от pc.acme.com.
Если сервер DNS bigcorr.pany. com возвращает авторитетный ответ, acme . com направляет его клиенту Dc.acme.com, что полностью разрешает запрос. Если по какой-то причине возвращается неавторитетный ответ, разрешения не происходит, пока запрос клиента не будет выполнен, В любом случае, кроме получения авторитетного ответа, клиент может использовать другие запросы, возможно, другим серверам DNS, указанным в его конфигурации.
Если acme.com отючоняет рекурсивный запрос от pc.acme.com, pc. acme, com может сам выполнить все итеративные запросы, обращаясь по очереди к каждому серверу DNS, как это делает acme. com на рис. 5.8. Распознаватели клиентов почти всегда выдают рекурсивные запросы, но иногда они отклоняются.
Единственный отклик, который клиент принимает от сервера DNS в ответ на рекл'рсивный запрос, — это сообщение об удаче или неудаче поиска. Пока оно не пришло, клиент просто ожидает. Если в результате поиска приходит не авторитетный IP-адрес искомого узла, а ссылка или направление на другой сервер DNS, клиент обращается по указанному адресу за авторитетным ответом.
Рис. 5.8. Для разрешения некоторых клиентских запросов необходимы как рекурсивные, так и итеративные запросы
Рекурсия означает, что сервер DNS продолжает работать с запросом клиента, пока он не будет разрешен. Сервер DNS использует свой собственный распознаватель, постоянно переходя от роли сервера к роли клиента и обратно, пока он или другой сервер не сможет предложить авторитетный ответ. По иронии судьбы, сервер, который обрабатывает запрос клиента, обычно направляет другим серверам DNS именно итеративные запросы и по их указаниям передвигается вверх и вниз по дереву имен DNS, пока не найдет сервер с соответствуюшим запросу именем или пока не будет выполнено условие конца поиска, например превышение заданного времени или ошибка.
Рекурсия происходит только при выполнении следующих условий.
Клиент требует рекурсии.
Сервер DNS принимает рекурсивные запросы (это делают почти все серверы, за исключением корневых).
Сервер клиента DNS не может найти ответ в своем кэше или базе данных.
Если сервер клиента DNS находит ответ в своем кэше или базе данных, он отвечает немедленно и авторитетно для данных своей зоны, отменяя необходимость дальнейших запросов.
Большинство распознавателей сначала посылает рекурсивный запрос. Если сервер отклоняет рекурсивные запросы и не может возвратить свой адрес из своего кэша или файлов данных, клиенты обычно продолжают попытки с итеративными запросами.
Итеративные запросы DNS
Итеративные запросы позволяют серверу DNS возвращать предположительные указания, называемые также ссылками или направлениями. Итеративный запрос, в отличие от рекурсивного, может не возврашать окончательный результат. Он может возвратить частичный результат или предложение, где проводить дальнейший поиск. Клиент (распознаватель) исполыует итеративные запросы, чтобы приблизиться к ответу, итеративно запрашивая другие серверы DNS вплоть до окончательного ответа (разрешения), ошибки или истечения заданного времени. Итерация в меньшей степени загружает серверы DNS, но требует большей загрузки клиентов, в том числе серверов DNS, которые действуют как клиенты для серверов DNS, расположенных выше.
На рис. 5.8 второй запрос, адресованный ns.myisp.com、возвращает ссылку, направляюшую acme.com на сервер DNS корневого домена. Это повторяется, пока на четвертый запрос не будет получен авторитетный ответ от сервера DNS bigccmpany.corr..
Если первый итеративно запрашиваемый сервер не может возвратить адрес, он сообщает клиенту, какой сервер DNS лучше всего запросить следующим. Этот наилучший сервер обычно находится выше на дереве имен, ближе к корню DNS, или же это может быть сервер корневого уровня. После того как будет достигнут сервер корневого уровня, обычно требуется очень немного запросов для прохождения вниз по дереву имен до сервера, авторитетного для искомого домена. Этот сервер возврашает желаемый адрес или ошибку, что закрывает исходный запрос.
Обратные запросы DNS
Обратные запросы — совершенно другое дело. Рекурсивные и итеративные запросы являются прямыми, т.е. они содержат доменное имя и возвращают IP-адрес. Обратный запрос действует наоборот: он получает от клиента значение 1Р и возвращает полностью уточненное доменное имя (FQDN). В пространстве доменных имен для этой цели был создан специальный домен, используюший обращенные IP-адреса, а не имена. Все за- регнстрированные IP-адреса включены в субдомен in-addr домена агра.
Как правило, повторение имен узлов допустимо, поскольку спецификаторы доменных имен надежно разделяют их на домены и субдомены.
Поскольку никакие два узла в Internet не могут иметь один и тот же зарегистрированный IP-адрес, они могут быть членами одного субдомена, но только при использовании IP-адресов, а не имен. По этой схеме уникальные номера имен заменяют имена узлов в иерархии доменных имен. В домене in-addr.arpa узел host2.acmecompany.com может иметь запись указателя (PTR) такого вида:
2.1.1.10.in—addг.arpaIN PTRhost2.acmecompany.com
Соответствующая этой записи PTR запись адреса в субдомене acmecompany. com может быть такой:
host2.acmecompany.com IN А 10.1.1.2
В этом примере 1Р-адрес host2 хранится в домене in-addr.arpa в общем порядке всех остальных зарегистрированных узлов Internet. Для обратного запроса host2 (по IP-адресу) надо только поставить несколько чисел в обратном порядке. Полностью уточненное доменное имя для host2 можно узнать, просто запросив его обращенный IP-адрес в субдомене in-addr. агра, где все зарегистрированные узлы можно отыскать по их IP-адресу, а не по доменному имени.
Запросы за работой
В любом случае тип запроса, используемый клиентом или даже сервером DNS, более важен для администраторов, чем для пользователей. Если возникают проблемы с производительностью или разрешением, можно попробовать изменить настройки, принятые по умолчанию. Клиенты почти всегда начинают с рекурсивных запросов. По умолчанию Windows 2000 DNS Server также посылает рекурсивные запросы, если они направлены узлу пересылки, но любому другому серверу DNS он передает итеративные запросы. В главе 11, *1Настройка Windows DNS Server", рассматриваются особенности Windows 2000 DNS Server, в том числе как заставить его посылать только итеративные запросы.
Как было сказано выше, при нормальной работе любой процесс должен быть прозрачным для клиента. Ниже приведен пример протокола обратного поиска имени, запускаемого командой PING -а [1Р-адрес]
С：＞ Ping -а 198.25.40.20
DNS: 0x1:Std Qry for 20.40.25.198.in-addr.arpa of type
Dom. name ptr on class INET addr.
DNS： Query Identifier = 1 (0x1)
DNS： DNS Flags = Query, OpCode-Std Qry,
RD Bits Set, Rcode-NoError
DNS： Question Entry Count = 1 (0x1)
DNS: Answer Entry Count = 0 (0x0)
DNS： Additional Records Count = 0 (0x0)
DNS： Question Section： 20.40.25.198.in—addr.arpa of type
Dom. name ptr on class INET addr
DNS: Question Name: 20.40.25.198.in—addr.arpa
DNS: Question Type = Domain name Pointer
DNS: Question Class - Internet address class
Можно заметить, что имя запроса (Question name) представляет собой обращенный 1Р-адрес, 20.40.25.198. in-addr.агра типа PTR.
DNS: 0x!:Std Qry Resp for 20.40.25.198.in-addr.arpd cf type
Dom. name ptr on class INET addr.
DNS: Query Identifier = 1 (0x1)
DNS: DNS Flags = Responce, OpCode-Std Qry,
AA RD RA Bits Set, Rcode-NoError
DNS: Question Entry Count = 1 (0x1)
DNS: Answer Entry Count = 1 (0x0)
DNS: Name Server Count = 0 (0x0)
DNS: Additional Recoids Court = 0 (0x0)
DNS: Question Section: 20.40.25.198.in—addr.arpa of type
Dom. name ptr on class 工NET addr
DNS: Question Name: 20.40.25.198.in—addr.arpa
DNS: Question Type = Domain name Pointer
DNS: Question Class = Internet address class
DNS: Answer Section; 20.40.25.198.in—addr.arpa of type
Dom. name ptr on class INET addr
DNS: Resource Name: 20.40.25.198.in-addr.arpa
DNS: Resource Type - Domain name Pointer
DNS: Resource Class = Internet address class
DNS: Time To Live = 86400 (0x15180)
DNS: Resource Data Length - 23 (OxJ 7)
DNS: Pointer: frenchy.example.net
Эта команда посылает IP-адрес на сервер DNS и запрашивает имя узла, связанного с этим адресом. Как можно видеть, вся закулисная работа скрыта от клиента. Вспомните, что, если сервер DNS не содержит этого имени в своих таблицах и кэше, он выполняет всю работу по поиску ответа, который показан в конце этого протокола и который только и хочет знать (и видит) клиент. В этом случае все события происходят скрыто от клиента. Имя, соответствующее IP-адресу в данном рекурсивном запросе, —это имя NetBIOS, зарегистрированное в WINS. Следовательно, в этом случае сервер DNS, разрешающий запрос, должен быть указан в записи W1NS-R (см. главу 4). Затем этот сервер приобретает статус адаптера IP-адреса, вместо того чтобы обращаться к WINS или искать информацию на своих делегированных узлах in-addr.агра. Для клиента в этом случает также не имеет значения, сколько и какой работы надо выполнить для разрешения рекурсивного запроса.
Резюме
В этой главе описано действие стандартных запросов DNS. Процесс запроса также рассматривается в главах 2 и 3, но не столь подробно, как здесь.
Работа с провайдерами
В этой главе...
Как заявить о себе в Internet. Выбор и регистрация доменного имени.
Общие соображения по использованию Internet-провайдеров (ISP) для службы имен. Могут ли 1SP предоставить необходимые услуги для вашей организации.
Как выйти в Internet и настроить серверы. Когда вы получили все нужные детали, как собрать из них то, что вам нужно?
Как внести изменения в сервер имен. Жизнь не стоит на месте, например компании могут менять IntemcJ-провайдеров, что, как правило, приводит к изменению IP-адресов.
Как заявить о себе в Internet
Первое, над чем надо подумать перед подключением организации к Internet, — как об этой компании можно будет узнать и найти ее? Хорошие и значимые доменные имена должны быть легко найдены теми, кому они адресованы. Многие организации используют для доменных имен свои сокращенные названия или подбирают с,юва, имеющие отношения
к их деятельности. В связи с наблюдаемым в последние годы Internet- бумом задача найти еше не зарегистрированное доменное имя стала настоящим трюком. Вообще, при выборе имени целесообразно начать с определения нескольких подходящих имен, прежде чем обращаться к записям WHO1S в InterNIC. Для тех, кто не имеет опыта работы с базой данных WHOIS, InterNIC предоставляет механизм проверки доступности доменных имен перед отправкой запроса на регистрацию. В основном на запрос в базу данных WHO1S возвращается один из двух возможных ответов. Первый ответ содержит подробную информацию о владельце запрашиваемого доменного имени. Конечно, этот ответ не для тех, кто надеется зарегистрировать новый домен. Во втором ответе может быть сказано, что для запрашиваемого имени соответствий не найдено, т.е. это доменное имя доступно для регистрации. Тогда вы должны быстро ззре- зервнрбвать или зарегистрировать его. Не так давно поиск уникального имени несколько облегчился благодаря вводу семи новых общих доменов верхнего уровня (generic top-level domain, gTLD). Это домены . сс, .arts, .firm, . nom, . info, .rec. .web и .shop. В дополнение к уже существующим .gov, .edu, . org, .com и .net они несколько увеличивают возможности выбора1.
В прошлом можно бь!ло только зарегистрировать домен, и он принадлежал вам 90 дне(1, даже если вы ничего не платили за это. Если вы собирались использовать зарегист[Л1ровацный домен, надо было заплатить взнос, и все. В настоящее время мо水но выбрать несколько вариантов регистрации. Можно, конечно, зарегистрировать домен через Network Solutions, как часто делалось раньше, или выбрать одного нз альтернативных регистраторов. В любом случае процесс не особенно изменяется, но появляется возможность зарезервировать (также говорят — припарковать) доменное имя, и при этом не нужно предоставлять информацию о сервере имен. По сути это дает возможность забронировать доменное имя до тех пор, пока вы не решите использовать его. Права парковки домена обычно стоят несколько больше, чем простая регистрация, из-за дополнительных расходов со стороны регистратора, который фактически регистрирует домен и обладает админисфативными правами на него, пока вы не решите его активизировать. Говорят, что в некоторых районах (в Великобритании) можно парковать домены, не платя дополнительных Взносов, но лично нам не приходилось сталкиваться с подобной практикой. Другое изменение — то, что некоторые регистраторы теперь требуют Предоплаты за регистрацию или парковку доменного имени. Подробнее о процессе регистрации см. в приложении Г, 1'Регистрация адресов в Internet".
/ 8 настоящее время существует несколько десятков новых доменов верхнего 'уровня, хотя еще далеко не все “з них разрешены для испо.1ьи>вания. Полный [ список новых TL D можно найти на www.icann.org/tlds — Прим. ред.
Общие соображения по использованию ISP для службы имен
Internet-провайдеры (Internet service providers, ISP) — это посредники, через которых к Internet подключается подавляющее большинство организаций. В прошлом многие организации, особенно те, что не имели в своем составе службы информации или не могли себе позволить этого, должны были обращаться к ISP за базовыми услугами серверов имен (за плату). В случаях, когда lnteniei-провайдср выполняет функции сервера DNS, организация может установить дополнительный сервер локально. Это делает авторитетную информацию локально доступной и дает организации возможность убедиться (поскольку дополнительный сервер будет иметь копию данных зоны), что ISP публикует правильную информацию и своевременно производит изменения. Организация может также просто установить сервер имен только для кэширования, чтобы повысить производительность в ответах на часто поступающие запросы за счет создания локального кэша. Любое из этих решений освобождает организацию от некоторых адм ин истрати вн ых проблем и расходов, но в то же время делает ее зависимо" от ISP в вопросах безопасности и при выполнении изменений.
Без особого труда организация может запустить свой собственный сервер имен, а в Windows 2000 это становится необходимым для правильной работы служб Windows. В этом случае ISP может предоставить дополнительный сервер имен для повышения избыточности. Это дает множество преимуществ. Во-первых, организация может производить какие угодно изменения, не вовлекая в это Internet-провайдера. Также это позволяет внешним пользователям разрешать имена узлов в домене организации, даже если соединение с Internet пропадает. Это особенно важно для таких служб, как электронная почта, которая, возможно, не сможет доставить сообшения, если сервер недоступен, но поместит их на некоторое время в очередь и периодически будет пытаться доставить. Даже если только ваш почтовый сервер не может быть разрешен, почта вернется обратно к отправителю с сообщением, что пользователь и/или домен 1'нeизвecтны,,.
В идеальном случае ISP может назначить и делегировать организации полномочия на блок сетевых адресов. Здесь термин делегировать означает присвоение домена IN-ADDR (адресов Internet) для блока сетевых адресов организации. Тогда организация будет свободна в настройке своей сети, создании серверов имен и публикации доменных имен, которые она собирается зарегистрировать. Если организация достаточно велика, ей может потребоваться зарегистрировать номера сети в Американском реестре номеров Internet (American Registry for Internet Numbers. ARIN) и завершить регистрацию домена IN-ADDR без привлечения ISP.
Однако все приведенные выше сценарии не обходятся без проблем. В первую очередь, если ваши серверы имен находятся у Internet- провайдера, какне меры ISP примет для зашиты ваших данных зоны? Даже если серверы DNS стоят у вас, как ограничить количество информации. доступной для внешнего мира? При использовании Windows 2000 оказывается, что через DNS надо опубликовать массу секретной информации, например имена и адреса вашего Active Directory и контроллеров домена для одних только стартовых программ. Действительно ли это та информация, которую вы хотите сделать доступной для каждого? Нет, если бы это была моя сеть! Главы 9, 11 Проектирование служб DNS" и 10, 4tПроблемы безопасности'' ответят на многие из этих вопросов.
Конечно, все это зависит от структуры вашей организации и правил, установленных Internet-провайдером. Позвольте предложить вам совет. Если вы должны управлять какими-то ресурсами — сохраняйте как можно более полный контроль над службами своей сети. Если вы контролируете сеть, у вас будет меньше проблем с изменениями и вы сможете устанавливать свои правила относительно безопасности и допустимости данных. Вы можете встретить сопротивление со стороны Inteniet- провайдеров; некоторые из них не желают делегировать блоки IP-адресов и разрешать вам строить собственную DNS- Если это имеет место, следует поискать другого провайдера.
Как выйти в Internet и настроить серверы
Теперь, когда вы зарегистрировали свой домен, имеете соединение с Internet и некоторые обшие идеи по архитектуре сети, время начать настройку серверов. Следует надеяться, что вы решили все вопросы с Internet-провайдером по поводу вашей собственной службы имен, что означает настройку основного (или главного) сервера. Также следует решить, надо ли настраивать локальные дополнительные (или подчиненные) серверы или же удаленные дополнительные серверы. Первый шаг в определении этих требований — пересмотр организационной структуры и архитектуры сети, которая служит для передачи данных. Сколько будет серверов имен и где они будут расположены — ответы на эти вопрось( также могут быть усложнены конкретными требованиями к безопасности сети. Должны ли серверы имен работать через брандмауэр? Сколько маршрутизаторов или каналов глобальной сети (WAN) будет использоваться в сети? Каковы скорости этих каналов WAN? Все ли они предоставляются по требованию? И наконец, какого размера организация и сколько субдоменов надо создать?
Можно рекомендовать следующий порядок действий.
Заключите контракт на обслуживание с ISP.
Получите доступ к Internet.
Получите IP-адреса.
Настройте сеть и проверьте основные функции подключения (маршрутизацию и протоколы).
Убедитесь, что вы можете выйти в Internet, путем проверки IP- адресов командой ping.
Убедитесь, что возможен доступ к удаленным узлам через Telnet/FTP, и проверьте скорость загрузки.
Создайте свою службу имен с основным сервером DNS и хотя бы одним дополнительным (или несколькими основными — при использовании Active Directory).
Зарегистрируйте узлы для новых серверов имен.
Зарегистрируйте домен для своей организации, включая вновь зарегистрированные У3.1Ы.
Заполните базы данных (зоны) своего сервера требуемы- мн/желаемыми данными
Проверыс всю систему с целью убедиться, что она работает, л^- ше всего через удаленный узел. (Выберите удаленный сервер имен и пошлите ему запросы на ваш домен.)
Не забыва11те о безопасности, поскольку теперь вы находитесь "в Сети".
Для небольиюй. только что начавшей работу компании отлично подойдет один домен (в том числе и по причине легкости в управлении}. Если организация имеет большие размеры и рассредоточена географически, лучше всего создать субдомены — либо по подразделени ям, либо по регионам. Для узлов с брандмауэрами учтите проблемы работы брандмауэра. Должна ли в нем быть "дыра" для прохождения трафика сервера имен? Надо пн создать и настроить два отдельных сервера имен (BiieujHHH перед брандмауэром л внутренний за ним), или внешний сервер имен должен быть дополнительным для домена? При структуре DNS с ''разделенным мозгом" (называемой так из-за основных серверов имен по обеим сторонам брандма)эра) внешний основной сервер раскрывает только узлы, предназначенные организацией для этой цели. Внутренний основной сервер содержит таблицу соответствий для всех узлов в домене, но настроен так. чтобы направлять внешнему серверу DNS запросы на все узлы, внешние по отношению к домену (зоне) сервера имен. Кроме того, внутренний основной сервер может быть настроен как подчиненный для внешнего, оставаясь таким образом скрытым от Internet. Если
вы решили предоставить lntemet-провайдеру некоторую часть DNS, целесообразно сделать сервер 1SP основным для домена, но опубликовать только открытые узлы, что уменьшит необходимость в управлении несколькими отдельными основными узлами на месте.
Географически рассредоточенные организации часто хотят иметь несколько протрассированных соединений с разными офисами. Если система Windows 2000 развернута на всю организацию, для службы серверов имен подходят удаленные контроллеры домена. Использование Active Directory значительно упрощает управление удаленными серверами имен, так как все серверы имен публикуют одну и ту же общую информацию, доступную в Active Directory. Если же Windows 2000 не развернута на всю организацию, надо исследовать модели организационного трафика, чтобы определить, какая доля сетевого трафика идет в направлении внутренних узлов в сравнении со внешними узлами. Если основная часть сетевого трафика идет в направлении внутренних узлов, в удаленных офисах рекомендуется разместить дополнительные серверы. При дополнительных серверах в каждом удаленном офисе большая часть запросов службы имен может быть локализована на серверах данного офиса. В главах 9 и 10 такой подход и его реализация рассматриваются подробно.
Как внести изменения в сервер имен
IP-адрес сервера имен не должен изменяться. Однако иногда это необходимо. Например, может измениться lnternct-провайдер, используемый для открытой DNS. Само изменение IP-адреса узла — очень простое действие, но ему должно предшествовать надлежащее планирование, чтобы избежать сбоев в работе службы. Чтобы изменить IP-адрес сервера имен, надо выполнить несколько простых, но крайне важных действий. Если сервер имен зарегистрирован в InterNIC, информация о новом IP- адресе должна быть направлена в InterNIC в форме модификации узла (modification template). Если сервер имен является основным, форма модификации становится намного более важной. При перемещении на новое место следует обновить контактную информацию и дескриптор NIC (NIC Handle), а также данные об узле. При простом изменении провайдера необходима только форма модификации, которая также надлежа- шим образом обновляет базу данных WHO1S. Рекомендации по изменению IP-адреса сервера имен можно найти в главе 13, "Рациональные методы работы и обслуживания", а формы и подробные сведения по регистрации и модификации — в приложении Г.
К счастью, только основные и дополнительные серверы имен являются по-настояшему ответственными деталями этого процесса, и вы можете облегчить себе жизнь, предприняв некоторые действия. Если только это возможно, надо, чтобы новые IP-адреса (и, возможно, новое соединение)
были настроены и готовы до того, как вы отправите информацию об изменениях в InterNIC. Имея доступ к новому узлу и новому соединению, можно потратить достаточно времени для проверки новых настроек, перед тем как произвести какие-то серьезные изменения. При перемещении на новый узел, если используется интеграция в Windows 2000 Active Directory, создание нового сервера имен заключается всего лишь в добавлении в список нового компьютера как копии основного сервера. Если изменяется только Internet-провайдер, рекомендуется присвоить второй IP-адрес серверу имен и запустить обе сети IP одновременно. Это также дает возможность проверить службы перед внесением изменений. Если все работает нормально, отправьте форму модификации и ожидайте подтверждения изменении. После получения подтверждения можно просто отключить интерфейс или удалить старый 1Р-адрес.
Для изменения IP-адресов сервера (или серверов) имен можно рекомендовать следующий порядок действий.
Зарегистрирован®) ли сервер(ы) имен в InterNIC?
Если нет, можно просто изменить IP-адреса, обновить локальные данные зоны, и этого будет достаточно.
Если да, перейдите к п.2,
Изменяется ли просто IP-алрес или же Internet-npoBaiiiiep?
■ Если изменяется ISP, запланируйте некоторое перекрытие по времени, когда оба провайдера будут работать одновременно.
Присвойте новый IP-адрес (или адреса) выбранному серверу (или серверам) имен.
■ Легче всего это сделать, присвоив второй адрес сетевому интерфейсу.
Обновите данные зоны для сервера имен в соответствии с новыми IP-адресами.
Обновите регистрацию узла для выбранных серверов имен.
Проконтролируйте изменения и проверьте разрешение сервера
Удалите/отключите старые IP-адреса и подключение к ISP.
Конечно, содержимое файлов (зон) вашего домена находится всецело под вашим контролем и может быть изменено в любой момент. Единственная хитрость при внесении изменений — значения срока жизни (time- to-live, TTL), которые выдаются распознавателям при запросах на ваш домен. Иногда эти значения могут быть довольно большими. Если предполагается переместить группу компьютеров или внести серьезные изменения в архитектуру сети, целесообразно уменьшить значение TTL по умолчанию, перед тем как проводить изменения. Это увеличит объем трафика на сервере имен на период проведения изменений, однако ока-
жет большую помощь при переходе на новые 1Р-апреса и так далее, не приводя к слишком большой потере посетителей вашего узла во время перехода. Многие сайты коммерческого направления не могут позволить себе потерять потенциальных клиентов из-за невозможности доступа к сайту. В нормальных условиях поддержание связи и обеспечение разрешаем ости и достижимости узлов представляют собой немалую задачу. При изменениях эта задача становится просто огромной.
Резюме
В этой главе вновь показано, какую важную роль для успешной установки и модификации DNS играет планирование. При работе с Intemet- провайдером можно гарантировать, что любой пользователь Internet сможет достичь узлов в вашем домене и что изменения данных и передачи зон можно выполнить наиболее эффективным способом.
II
Использование Windows 2000 DNS Server
В этой части...
Динамическая DNS и Active Directory
Работа с серверами BIND
Проектирование служб DNS
Проблемы безопасности
Настройка Windows DNS Server
77
7
7
Динамическая DNS и Active Directory
В этой главе...
Динамическая DNS (DDNS). Приводится краткий обзор новой функции динамического обновления DNS с точки зрения администратора Windows и DNS. Коротко излагаются сопутствующие вопросы безопасности и очистки файла зоны и подробно рассматривается очистка данных в Windows 2000.
а Интеграция зон DNS в Active Directory. Описывается использование Active Directory для хранения данных зоны DNS. причины, по которым была введена эта функция, что она дает, и соображения, по которым можно ее использовать. Подробно рассматривается пре- нмушество безопасности динамического обновления, обеспечиваемое Active Directory.
Зависимость Active Directory от записей служб (SRV). Рассматривается использование записей SRV в среде домена Windows 2000. Из всех новь1Х функций DNS, поддерживаемых в Windows 2000, это единственная, которую следует рекомендовать для поддержки Active Direclory.
Попробуем представить Active Directory и DNS как единое целое.
Этот раздел обобщает большое количество факторов, учет которых необходим для принятия обоснованных решений по применению этой технологии.
Active Direclory в Windows 2000 реализует облегченный протокол службы каталогов (Lightweight Directory Access Protocol, LDAP). В то *e время, чтобы объяснить, что это такое, необходим краткий исторический экскурс. Исходная спецификация службы каталогов Х.500 прекратила свое существование, не воплотившись в полноценных коммерческих реализациях по многим причинам. В частности, слишком большая сложность этой спецификации привела к появлению реализаций ее подмножеств. Результатом таких попыток и стал LDAP.
Хотя особенностью LDAP является его продолжающееся развитие, Windows 2000 использует тот факт, что прежние реализации LDAP, как правило, не давали возможности идентификации во всемирном масштабе в том смысле, как это делает DNS. Первоначальная цель Х.500 состояла именно в создании такой возможности — устанавливать местонахождение структур каталогов и затем перемешаться по ним. Однако до настоящего времени реализации LDAP были больше нацелены на работу со структурами каталогов, чем на их отыскание.
Механизм Active Directory основан на сушествуюших способностях обнаружения DNS и доводит их до совершенства за счет тесной связи между пространствами имен DNS и Active Directory. В результате верхние уровни объектов Active Directory выступают в виде доменов DNS. Объясняется это тем, что используемые здесь объекты контроллеров доменов (DC) представляют границы доменов Windows 2000, и в начальной версии Windows 2000 предполагалось, что они будут называться по именам доменов и субдоменов DNS с одинаковой структурой.
Этот факт имеет многочисленные следствия. В данной главе рассматриваются некоторые возможности, взаимосвязи и недостатки, вытекающие из такой концепции и из использования некоторых новейших функций DNS для ее поддержки.
DDNS
В RFC 2136 подробно описаны операция динамического обновления (соответствующая новому коду операции DNS) и формат сообщений, которые могут использоваться клиентом DNS для требования изменений в доменах DNS. Как мы уже видели, данные домена должны исходить от основного сервера домена, следовательно, DDNS устанавливает, что требование обновления при его получении дополнительным сервером передается основному серверу для обработки. Хотя все это выглядит незамысловато и просто, на этом дело не заканчивается. Обновление действительно не представляет трудности, но его последствия сложны.
При динамическом обновлении клиент, определив местоположение авторитетного сервера имен своего домена (путем запроса записей серверов имен [NS]), может объявить о своем присутствии, потребовав регистрации записи (или записей) адреса (А) и, возможно, указателя (PTR). Фактически клиенты Windows 2000 запрашивают начальные записи зоны (SOA), а не NS, и затем регистрируются прямо на основном сервере своего домена. После того как компьютер сделает это, его можно будет разрешить по имени и, возможно, идентифицировать по IP-адресу, как если бы эти записи ресурсов (RR) были введены вручн\то.
Если бы такие веихи проходшги без неприятных последствий, это было бы просто находкой для любого администратора. Однако, как известно, не бывает таких новинок, которые приносили бы выгоду без всякого риска. Иначе они бы давно уже появились.
Что такое DDNS
Способность динамического обновления DNS описана в RFC 2136, где в язык DNS вводится новое сообщение обновления (Update). Используя формат сообщения обновления, клиенты могут добавлять записи ресурсов (RR), удалять их, проверять или добавлять входные условия.
В RFC подробно описывается применение наборов RR — например, наборов записей с одним и тем же именем как нескольких записей А для узлов WWW в домене. Обновление может затрагивать отдельную запись, набор записей или несколько наборов. В случае динамического обновления происходит добавление и удаление записей или их наборов.
Записи можно проверять на соответствие определенным' критериям — например, имеется ли запись А 瓜ля fs2.hq.example.net. Такое соответствие может быть предпосылкой для обработки требования на обновление или *е простым входным условием без последующих действий. Такие входные условия, использующие возможность сообщения обновления задавать проверку без последующих действий, представляют собой простое средство узнать, содержатся ли в базе данных DNS определенные записи или их наборы-
Сервер DNS информирует клиента о результате проверки или обновления. Если с проверкой связаны действия по обновлению и предпосылки выполняются, сервер DNS производит это обновление. Обновление выполняется по принципу "все или ничего'1, т.е. является неделимым.
Сообщения обновления не имеют ограничений в простых действиях добавления или удаления отдельных записей. Могут удаляться целые наборы записей. Вследствие того что использование групповых символов (wildcards) ограничено, действия по обновлению должны быть определены конкретно.
RFC 2136 предусматривает соблюдение безопасности, соответствующей конкретной реализации или стандарту RFC, в продолжение всего процесса, но не определяет его механизм. В RFC 2137 представлена первая спецификация безопасного динамического обновления DNS. Безо-
пасность динамического обновления продолжает совершенствоваться; большинство ее методов согласно стандарту DNS требует поддержки инфраструктуры открытых ключей, В начальной версии Windows 2000 реализован метод безопасности, использующий технологию Kerberos (см. ниже в этой главе).
Использование DDNS клиентами Windows 2000
Как было сказано выше, клиенты Windows 2000 обращаются с обновлениями DNS непосредственно на основной сервер DNS, что имеет смысл, поскольку именно на сервере с наивысшими полномочиями (SOA) должны производиться любые изменения в данных домена. По умолчанию в начальной версии Windows 2000 клиенты выдают требования на регенерацию своих данных DNS каждые 24 часа.
Как будет показано в следующих разделах, бесполезные обновления вызывают ненужную загрузку, так что без них вся система только выиграла бы. Поэтому клиенты Windows 2000 ведут себя более разумно, чем требуется. При регистрации они сначала проверяют, правильны ли имеющиеся в DNS данные с точки зрения клиента. Если это так, они не требуют обновления. Если клиенту не требуется обновления, при неудаче в регистрации он попытается зарегистрироваться на любом другом основном сервере, который может сушествовать в зоне при условии, что она интегрирована в Active Directory. Если клиенту все равно не удается зарегистрироваться, процесс возобновляется после 5-минутного, а затем после 10-минутного ожидания. В случае новой неудачи следующая попытка регистрации производится через 50 минут. Компьютер под управлением Windows 2000, настроенный для динамического обновления DNS, настойчиво пытается заявить о себе.
В главе 15, 14Службы DHCP в Windows", рассматривается способность сервера Windows 2000 DHCP регистрировать клиентов по их требованию. Этого можно добиться различными способами, но по умолчанию для клиента Windows 2000 обслуживаются записн А, а для сервера протокола динамической конфип'рации узла (Dynamic Host Configuration Protocol) — запись PTR. Сервер DHCP в Windows NT не обладает этой способностью. DHCP может быть настроен для регистрации записей обоих типов, а также для регистрации клиентов, которые не работают в Windows 2000. Все это действует благодаря безопасности обновления и очистке регистрационных данных (см. ниже).
В чем проблемы
Если DDNS может освободить администраторов DNS от работ по обслуживанию файла зоны и определена в RFC начиная с апреля 1997 года, почему до сих пор она используется так мало? Или, иными словами, о чем нужно помнить, садясь на этот поезд?
Безопасность
Ответ на этот вопрос можно выразить одним словом — безопасность. Множество способов несанкционированного доступа сделали почти тривиальной регистрацию — все равно, записи адреса для отдельного узла или даже целого сервера имен. Без какого-либо контроля, кто и на каком компьютере и какие записи может обновлять, DDNS становится чем-то вроде экстремального спорта — только для смелых.
Microsoft постаралась обеспечить безопасность процесса динамического обновления зон за счет их интеграции в Active Directory. Сущность такой интеграции рассматривается в следующем разделе этой главы.
Объявление служб
После разрешения динамического обновления зоны можно заметить появление новых записей служб (SRV). Active Directory зависит от использования записей SRV, определяющих местонахождение его основных служб. Например, _http._tsp, _ftp._tsp в дальнейшем могут быть зарегистрированы своими службами. Это может создать проблему для снс- темы, поэтому следует помнить, что Windows 2000 поставляется в совершенно готовом виде и способна использовать записи SRV в самом полном объеме.
Чистота зоны
Другая сторона безопасного обновления — конфликты при обновлении и чистота зоны. Если обновления, в том числе операции удаления, которые должны быть разрешены, отклоняются, записи становятся "бесхозными". Если клиенту не удается удалить зарегистрированные записи при том, что он имеет право это сделать, и затем его доступ запрещается, например, механизмами безопасности, сможет ли кто- нибудь вообще удалить эти записи?
Допустим, что сервер DNS отклоняет обновление в записи А имени, если оно или связанный с ним протокол Internet (IP) уже используется в домене. Что же должен почувствовать клиент DHCP, который пытается зарегистрироваться, когда его имя уже присутствует или когда какое-то другое имя разрешается в !Р-адрес, под которым он зарегистрировался?
Можно привести массу примеров по проблемам, связанным с просроченными записями. Если же к процессу обновления меры безопасности не применяются, эти проблемы исчезают. Когда клиент пытается зарегистрироваться, ему это удается. Затем клиент может производить запросы и обновления для очистки потенциально конфликтных и устаревших записей, чтобы обеспечить надежную работу.
Сообщество DNS сделало явный выбор: безопасность за счет ухудшения чистоты данных. Однако проблемы просроченных записей могут плохо повлиять на характеристики всей машины.
По умолчанию в Windows 2000 удаление записей разрешено администраторам и клиентским машинам, которые первоначально создали эти записи. Следовательно, если клиент, который зарегистрировал запись, оставляет ее, эта запись сохраняется в базе данных DNS, пока не будет предпринято действие по ее удалению. Один из стимулов в использовании DHCP для регистрации — ответственность за очистку может быть передана серверу DHCP, ведущему себя более надежно. Все-такм клиенты могут менять свое поведение и часто это делают.
Влияние служб
Использование DDNS оказывает сильное влияние на поведение зоны. Оно также открывает новые пути решения разных задач. Например, регистрация клиентов DHCP записями DNS представляет собой соответствующую стандартам замену для прежней интеграции DNS в службе имен Internet для Windows (Windows Internet Naming Service, WINS). Кроме того, в сочетании с записями типа SRV DDNS дает возможность объявлять службы, что прежде было доступно для систем Windows только с использованием имен NetBIOS.
Динамическая зона, по крайней мере потенциально, претерпевает непрерывные изменения. Это не только загружает механизм передачи зоны, но и создает некоторые новые сложности. Как передачи могут обеспечить непротиворечивое копирование зоны? Как сможет администратор отредактировать зону вручную и загрузить ее, если невозможно предсказать серийный номер? Можно, конечно, сказать, что редактировать вручную уже не надо, ведь DDNS обязана освободить администратора от подобной работы. Но как тогда быть с очисткой зоны?
Windows 2000 пытается предупредить возникновение подобных проблем. Сервер DNS зашишает зону от изменений на время передачи. Тем не менее, использовать уведомление для добавочных передач (IXFR) просто необходимо. Иной выход — спроектировать зону так, чтобы полные передачи были как можно более короткими (чтобы зона блокировалась на возможно меньшее время). Размер протокола изменений сервера DNS таков, что некоторые требования частичной передачи (IXFR) могут вызывать полную передачу (AXFR), если требуемое частичное изменение уже не помешается в протокол. Интеграция зон в Active Directory снимает эту проблему при передачах между основными серверами, но не при передачах на дополнительные серверы.
Новая забота администратора ——то, что придется начать с изучения возможностей новых инструментальных средств, поставляемь(х с Windows 2000. Особое внимание надо уделить DNSCMD.EXE (см. главы 12, 11 Средства поиска неисправностей", и 13, ^Рациональные методы работы и обслуживания1'). Объект системного монитора DNS содержит множество новых счетчиков, за которыми надо следить (см. главу 11, ''Настройка Windows DNS Server"); они позволяют узнать, насколько хорошо работают функции динамического обновления. В самом интерфейсе управления DNS также есть функция протоколирования, если администратор согласен потратить время на разбор какого-нибудь процесса.
Функции очистки записей ресурсов DNS
С помошью функций очистки Windows 2000 пытается противостоять тенденции динамических зон к загромождению старыми данными. Без интеграции Active Directory функция динамического обновления DDNS в Windows 2000 не охвачена мерами безопасности. Интеграция Active Directory позволяет защитить обновления, что делает необходимой очистку. Функции безопасности рассматриваются в разделе 11 Интеграция зон DNS в Active Directory'' этой главы. Данный раздел касается функций очистки, которые позволяют контролировать последствия применения мер безопасности.
Стратегия очистки Windows 2000 — не самая простая для понимания вещь. Однако это та функция, уяснить работу которой жизненно важно для ее использования. Целесообразно воздержаться от применения очистки, пока вы не уясните, как она работает и каковы ее последствия в данной конфигурации сервера.
Что делает очистка
Очистка может удалять устаревшие записи, независимо от того, были ли они созданы динамически или статически, в соответствии с настраиваемыми интервалами. Ее действие распространяется как на устаревшие записи, так и на используемые, но соответствующие определенным критериям, благодаря чему она рассматривает их как устаревшие. Поэтому вы должны знать, что делаете, прежде чем запускать очистку. Удаление используемых записей, естественно, создает проблемы. После того как запись удалена, динамическое обновление может позволить любой машине зарегистрировать запись, заняв это место.
Очистка удаляет записи, которые не являются текущими, т.е. недавно регенерированными. Регенерация вызывается требованием обновления (Update) DDNS, в котором для данных записи ресурсов не указано никаких изменений по сравнению с существующей записью. Это означает, что записи, введенные статически, могут быть удалены при ошибке, потому что они не регенерировались. Как было сказано выше, если Windows 2000 настроена для динамического обновления, она пытается регенерировать записи каждые 24 часа.
Для основных зон очистка может быть разрешена независимо от того, стандартные ли они или интегрированы в Active Directory. При интеграции в Active Directory атрибуты объекта, в котором содержатся записи, служат для хранения штампа времени. Если зона стандартная, формат файла зоны изменяется для добавления штампа времени. Штамп времени удаляется из ответов DNS и передач, т.е. это изменение в содержимом запнен используется только сервером DNS внутренним образом. Однако его надо учитывать при редактировании или перемещении файла зоны вручную.
Записи, которые добавляются в стандартную зону, когда очистка отключена, не имеют штампа времени. В результате такие записи не очищаются, даже если зону с ними переместить в Active Directory и разрешить очистку. Утилита dnscmd.exe позволяет поместить штамп времени на такие записи.
Как и когда производится очистка
В процессе очистки применяется несколько параметров временных интервалов. Два из них на уровне сервера имеют стандартное значение семь дней. Обратите внимание, что семь дней — это также период аренды (по умолчанию) для DHCP, и это не случайно. Имеется еше два интервала на уровне зоны, причем по умолчанию для настроек уровня зоны используются значения уровня сервера. Настройки уровня сервера можно вызвать, выбрав команду Установить свойства очистки для всех зон из контекстного меню сервера или меню Действие. На уровне зоны настройки вызываются щелчком на кнопке Очистка на вкладке Общие диалогового окна свойств зоны. Расположение этих команд и возможные параметры описываются в главе 11. На рис. 7.1 показано диалоговое окно Свойства очистки для зоны для настроек уровня зоны. Диалоговое окно уровня сервера называется Свойства очистки для сервера и не содержит даты и времени очистки зоны, но в остальном идентично первому диалоговому окну.
Ниже описаны интервалы процесса очистки.
Интервал блокирования. Этот параметр устанавливает время, на протяжении которого требования регенерации записи отклоняются. Запись может быть обновлена, но обновление без изменений (регенерация) не производится. Это запрешение ограничивает объем бесполезной работы, которая иначе бы выполнялась при репликации данных зоны, и позволяет не полагаться на то, что клиент будет вести себя разумно и не допустит излишней регенерации. Уменьшение этого значения может отрицательно повлиять на скорость передачи зоны и репликации Active Directory.
Интервал обновления.1 Этот параметр устанавливает время после интервала блокирования, на протяжении которого запись можно регенерировать, но не очищать. Запись может быть регенерирована в любой момент после того, как ее штамп времени покажет, что она старше, чем интервал блокирования. Если, согласно штампу времени, запись старше, чем сумма двух этих интервалов, она становится доступной для очистки.
8 интерфейсе русской версии DNS Wind(m-＜； 2000 обновлением записи ресурсов называются два разных процесса： собственно обновление (update), при котором могут изменяться данные зоны, “ регенерация (refresh), при которой “ишь устанавливается новый штамп времени. Параметры очистки зо〃“ относятся к этому последнему процессу — Прим. ред.
I Свойства очистки для зоны
Инх^вап йпоычхиа»*** Р |лн
Промежуток мехоу сшын ранним еренрнвм йСшепени* атанпа； ерене»»( 3№«кн и самым реннмс временем ночаоващигки；?：；；;?：?. записи Ин(арввп обноелвния дол>ген Сыть больше, чем лериэд ： - «wee явим накав1вльн0йэ«1иси
Йвмошгать кажвые|ан二'
Зонасгвнетаост^№<м_м>| Очистки
12000 9 00 0012000 9 00 00
12000 9 00 00
12000 9 00 00
Рис. 7.1. Настройки очистки в диалоговом окне Свойства очистки для зоны
Когда запись регенерируется или очищается, она получает новый штамп времени. В зонах, доступных для очистки, для записей, не созданных при динамическом обновлении (т.е. введенных вручную), скорее всего, нет никакого штампа времени, хотя в документации Microsoft говорится. что применяется штамп времени со значением нуль. Алгоритм очистки не затрагивает записи ресурсов с нулевым штампом времени. Однако в диалоговом окне свойств отдельной записи имеется флажок под названием Удалить эту запись, когда она устареет, который можно использовать для применения к ней очистки.
Очистка никогда не производится до истечения льготного периода. Это дополнительное условие к логике интервалов. Чтобы очистка могла начаться, зона должна быть непрерывно доступна для динамического обновления в течение времени, равного интервалу регенерации. Это гарантирует, что клиенты имеют полную возможность обновить свои записи перед тем, как они будут очищены. Очистку можно запланировать во вкладке Дополнительно диалогового окна свойств сервера (см. в нижней части рис. 11.4) или запустить вручную из контекстного меню сервера.
Очистка может начаться в какой-то момент после льготного периода, если она разрешена на уровне сервера. Очистка охватывает основные зоны, для которых разрешены как очистка, так и динамическое обновление. В таких зонах удаляются записи с ненулевым штампом времени, ко* торый показывает, что они не были недавно (два настраиваемых интервала назад) регенерированы.
Интеграция зон DNS в Active Directory
Слушая апостолов маркетинга, можно поверить, что Active Directory — это чудодейственное средство, способное помочь везде и всюду. Возможно, его собирались сделать таким, но, скорее всего, это был только план, который реализовался в стратегии зашиты динамических обновлений в Windows 2000. Спецификация безопасного динамического обновления DNS (RFC 2137) вышла в тот же день, что и специфи' кация динамического обновления. Но исследования продолжались, и новые их результаты показывают, как в Windows 2000 может применяться шифрование открытыми ключами. Во всяком случае Microsoft выбрала методику обеспечения безопасности динамического обновления DNS, которая показывает, что должно прийти на место Active Directory. Если обратить внимание на проекты в приложении Б, "Документы RFC по DNS", выяснится, что развивается подход к функциям безопасности, намеченный в свое время в GCC-AP1 (RFC 2078).
Как оказывается, интеграция данных зоны в Active Directory не дает практически приемлемого решения дилеммы "безопасность против чистоты данных'', однако выявляет некоторые другие точки приложения усилий.
Как это работает
Способ, которым данные зоны интегрируются в Active Directory, с одной стороны, весьма прост. Данные зоны всего лишь преобразуются в объекты каталога. Все, что содержится в каталоге, является объектами, так что это делается просто для того, чтобы можно было хранить данные в каталоге. После того как зона интегрирована, администратор может просматривать ее в режиме только для чтения (за исключением разрешенных для записи дескрипторов безопасности) на консоли Active Directory— пользователи и компьютеры (должен быть включен режим Дополнительно), на которой записи ресурсов отображаются в составе узла MicrosoftDNS (рис. 7.2).
Чтобы произвести такую интеграцию, надо всего лишь выбрать соответствующий пункт в списке в свойствах сервера. Этот список показан на рис. 11.4, а изменение формы хранения зоны с файла на Active Directory кратко описано в главе 11. Режим хранения отдельных основных зон можно изменить, щелкнув на кнопке Изменить во вкладке Общие диалогового окна Свойства зоны (см. рис. 11.7). Первое изменение режима хранения основной зоны на Active Directory вызывает изменение свойств сервера. Для изменения режима хранения не нужно больше ничего, по крайней мере, ничего, что администратор должен или может сделать.
修 Ative Uwectory - попьзоватепн ч компьютеры修 Ative Uwectory - попьзоватепн ч компьютеры,^Jf ItoHco/b -Qw® £n>»®；,^Jf ItoHco/b -Qw® £n>»®；? ■ ДайпЕиг :: бид . Светим j2 Acnve Dtectory - т 承 examptenetЛ _J computers、& Doman cw-jFwagTSeo.-SystemAdmmSti Crts-Coef_J FrlsLmks* .JIPSecuri 三 _j Microsot? ■ ДайпЕиг :: бид . Светим j2 Acnve Dtectory - т 承 examptenetЛ _J computers、& Doman cw-jFwagTSeo.-SystemAdmmSti Crts-Coef_J FrlsLmks* .JIPSecuri 三 _j Microsot“宀:©田:总总匾色 «ffii&v^ r“宀:©田:总总匾色 «ffii&v^ r«хапчЛеля.лвшт.：-1 一gc _tcp Detaull-FirsT-Sile-Name _s"es^kerteros _tcp一kerbees」co de 一msdes1 ^Kerberos _tco Detauf-FirsbSne-tJome srtes dc_msacs _Kemegs_udp1 -kpssswdjcp_kpess*d_gp@ Jdap jep«хапчЛеля.лвшт.：-1 一gc _tcp Detaull-FirsT-Sile-Name _s"es^kerteros _tcp一kerbees」co de 一msdes1 ^Kerberos _tco Detauf-FirsbSne-tJome srtes dc_msacs _Kemegs_udp1 -kpssswdjcp_kpess*d_gp@ Jdap jep_1 Polices_} RAS and_1 Polices_} RAS and二后1^1上电必二后1^1上电必d”sZode SsZode SsZ。。© d-sHcde CasZode dcsZcde OnstJcae dnsZcae fln^fiode d”sNoded”sZode SsZode SsZ。。© d-sHcde CasZode dcsZcde OnstJcae dnsZcae fln^fiode d”sNode；-l Jdap_icp 1338169-b36HB6t-b7d9-dete3d3c56fi _n>scfc; dnsNode；-l Jdap_icp 1338169-b36HB6t-b7d9-dete3d3c56fi _n>scfc; dnsNode:T Jdap Jcp Oc^msdcs可 Jdep jcp DMaWFusSie-Zome _s«es1 Jdap jcp Deleuh-First-Site-Neme _s"es fle 一msdesal Jdep jcp Delaufi-FirSt-Site-NBme sues “一msftzs1 Jdap jcp gc_m;dcsJdap pc _rti9dcs1 demot:T Jdap Jcp Oc^msdcs可 Jdep jcp DMaWFusSie-Zome _s«es1 Jdap jcp Deleuh-First-Site-Neme _s"es fle 一msdesal Jdep jcp Delaufi-FirSt-Site-NBme sues “一msftzs1 Jdap jcp gc_m;dcsJdap pc _rti9dcs1 demotdnsNode dnsNode dnsNcde cnsZodec”，U8e dnsNodednsNode dnsNode dnsNcde cnsZodec”，U8e dnsNode
修 Ative Uwectory - попьзоватепн ч компьютеры
修 Ative Uwectory - попьзоватепн ч компьютеры
,^Jf ItoHco/b -Qw® £n>»®；
,^Jf ItoHco/b -Qw® £n>»®；
? ■ ДайпЕиг :: бид . Светим j
2 Acnve Dtectory - т 承 examptenet
Л _J computers
、& Doman cw
-jFwagTSeo.
-System
AdmmSt
i Crts-Coef
_J FrlsLmks
* .JIPSecuri 三 _j Microsot
? ■ ДайпЕиг :: бид . Светим j
2 Acnve Dtectory - т 承 examptenet
Л _J computers
、& Doman cw
-jFwagTSeo.
-System
AdmmSt
i Crts-Coef
_J FrlsLmks
* .JIPSecuri 三 _j Microsot
“宀:©田:总总匾色 «ffii&v^ r
“宀:©田:总总匾色 «ffii&v^ r
«хапчЛеля.лвшт.：-
1 一gc _tcp Detaull-FirsT-Sile-Name _s"es
^kerteros _tcp
一kerbees」co de 一msdes
1 ^Kerberos _tco Detauf-FirsbSne-tJome srtes dc_msacs _Kemegs_udp
1 -kpssswdjcp
_kpess*d_gp
@ Jdap jep
«хапчЛеля.лвшт.：-
1 一gc _tcp Detaull-FirsT-Sile-Name _s"es
^kerteros _tcp
一kerbees」co de 一msdes
1 ^Kerberos _tco Detauf-FirsbSne-tJome srtes dc_msacs _Kemegs_udp
1 -kpssswdjcp
_kpess*d_gp
@ Jdap jep
_1 Polices
_} RAS and
_1 Polices
_} RAS and
二后1^1上电必
二后1^1上电必
d”sZode SsZode SsZ。。© d-sHcde CasZode dcsZcde OnstJcae dnsZcae fln^fiode d”sNode
d”sZode SsZode SsZ。。© d-sHcde CasZode dcsZcde OnstJcae dnsZcae fln^fiode d”sNode
；-l Jdap_icp 1338169-b36HB6t-b7d9-dete3d3c56fi _n>scfc; dnsNode
；-l Jdap_icp 1338169-b36HB6t-b7d9-dete3d3c56fi _n>scfc; dnsNode
:T Jdap Jcp Oc^msdcs
可 Jdep jcp DMaWFusSie-Zome _s«es
1 Jdap jcp Deleuh-First-Site-Neme _s"es fle 一msdes
al Jdep jcp Delaufi-FirSt-Site-NBme sues “一msftzs
1 Jdap jcp gc_m;dcs
Jdap pc _rti9dcs
1 demot
:T Jdap Jcp Oc^msdcs
可 Jdep jcp DMaWFusSie-Zome _s«es
1 Jdap jcp Deleuh-First-Site-Neme _s"es fle 一msdes
al Jdep jcp Delaufi-FirSt-Site-NBme sues “一msftzs
1 Jdap jcp gc_m;dcs
Jdap pc _rti9dcs
1 demot
dnsNode dnsNode dnsNcde cnsZode
c”，U8e dnsNode
dnsNode dnsNode dnsNcde cnsZode
c”，U8e dnsNode
Рис. 7.2. Данные зоны в Active Directory
Возможности интеграции
После того как данные зоны преобразованы в объекты каталога, немедленно проявляется несколько последствий. Некоторые из них вытекают непосредственно из природы постоянного хранения, используемого в Active Directory, например наличие атрибутов безопасности, а некоторые последствия вызываются тем, что данные теперь находятся в виде, пригодном для работы вспомогательных служб Active Directory, например технология репликации. Ниже приводится краткий обзор этих двух функций, а затем начинается довольно долгое и непростое изложение особенностей безопасности данных зоны, включая защиту процесса динамического обновления и ее поведение, предусмотренное по умолчанию.
Репликация
Active Directory использует архитектуру с несколькими главными серверами. в которой каждый DC (контроллер домена) во многих отношениях равен всем остальным в домене. Поскольку DC удалены друг от друга, при распространении изменений объекта, который хранится в каталоге, неизбежна задержка прохождения данных. В стандартной инсталляции суммарная задержка ограничена 15 минутами в пределах узла; однако между узлами она сильно зависит от того, как соединены узлы.
Задержка означает, что обновления на двух DC могут быть противоречивыми, поскольку изменения производятся не одинаково для всех узлов, а отдельно для каждого узла、который считает, что его данные самые свежие.
Эта архитектура поддерживается технологией репликации, основанной на алгоритме ^последняя запись выигрывает1' со стратегиями разрыва связей для противоречивого разрешения. По существу, имеется тесно связанная система, все компоненты которой постепенно приближаются к одинаковому состоянию. Контролеры домена в системе действуют не просто как равные, но, во многих случаях, как если бы они были идентичными копиями, что усиливает связь между ними. В то же время вследствие независимых изменений и алгоритмов репликации содержимое Active Directory непрерывно приближается к одинаковому для всех узлов состоянию (конвергирует), однако, поскольку любые частные изменения вновь нарушают это состояние, конвергенция является слабой. Все, что хранится в Active Directory, благодаря этой технологии автоматически реплицируется на все DC в домене. Следовательно, как и при обычных передачах зон, при использовании зон, интегрированных в Active Directory, существует период, в течение которого два разных сервера DNS, авторитетных для зоны, могут дать разные ответы на запросы об этой зоне.
Несколько основных серверов
Поскольку все данные зоны —— это всего лишь содержимое Active Directory (реплицированное на все DC), естественно, что на сервере DNS надо сделать лишь немного изменений, чтобы максимально реализовать все его возможности, В результате DNS может работать в режиме с несколькими главными машинами, если ее данные интегрированы в Active Directory. Данные зоны могут присутствовать в нескольких равноправных основных версиях DNS, каждая из которых помешается на DC (так как только DC содержат Active Directory).
В такой схеме возможны и стандартные дополнительные узлы. Ее отличие лишь в том, что основных серверов несколько. Конечно, для некоторых операций только один из них выбирается как "основной". Например, как может внешний пользователь определить, что это тот самый основной сервер? Или при очистке было бы очень неразумно и непрактично удалять устаревшие записи всем серверам DNS (если только они не выполняют свою часть общей задачи), так что один из них производит удаление, которое затем передается остальным.
Некоторые из этих вопросов преждевременны, если расценивать их с учетом доступной информации. Другие, например об инициаторе очистки, решаются внутренним образом, через соответствующие настройки в реестре. Достаточно сказать, что можно получить выгоду от применения нескольких основных серверов, если данные DNS хранятся в Active Directory. Основной результат — устранение главного недостатка стандартной архитектура DNS, когда основной сервер является единственной критической точкой системы. Другое преимущество — то, что динамические изменения, которые должны выполняться основным для зоны сервером DNS, не направляются на единственную машину, возможно, удаленную.
Безопасность
Прежде чем перейти к этой теме, вспомните, что динамическое обновление в Windows 2000 не охватывается зашитой, если зона DNS не интегрирована в Active Directory. Зашита обновлений DDNS — сложная задача для любого окружения. Это справедливо м для реализации и использования функции безопасного динамического обновления, как она именуется в интерфейсах Windows 2000, Цель безопасности — контролировать, кому или какому компьютеру позволено регистрироваться в DNS или изменять и удалять существующую регистрацию.
Процесс безопасного обновления DDNS
Клиент Windows 2000 вначале согласовывает контекст безопасности с сервером DNS. Сервер DNS, в свою очередь, использует этот контекст безопасности при попытке записи в базу данных DNS. Согласование происходит с помощью ключа обмена, который пробует использовать Kerberos в качестве провайдера безопасности. Если это удается, для фактической передачи подписанного требования на обновление серверу DNS и результатов клиенту используется подпись TS1G. Сам сервер применяет для об- новичения метод LDAP с установленным контекстом безопасности.
Клиенты Windows 2000 могут быть настроены так, чтобы посылать только незащищенные обновления, только зашишенные или сначала пытаться произвести обновление без зашиты, а потом, если необходимо,—- с зашитой. Последний режим принят для них по умолчанию. Таким образом, по умолчанию процесс динамического обновления состоит из следующих логических стадий.
Клиент предпринимает попытку незашишенного обновления.
Если она не удалась, клиент согласовывает метод защиты.
После того как провайдер безопасности Kerberos согласится, клиент согласовывает свое удостоверение с сервером DNS.
С этим удостоверением клиент требует обновления.
Сервер DNS устанавливает сеанс LDAP, используя удостоверение клиента.
Используя методы LDAP, сервер DNS пробует произвести требуемое обновление базы данных DNS.
Провайдер LDAP возвращает результаты серверу DNS
Сервер DNS возвращает результаты клиенту.
В действительности процесс более сложный и включает приложение подписи к требованию обновления и возвращаемым результатам для обеспечения их подлинности. Интерес представляет использование Kerberos как провайдера безопасности и тот факт, что сервер DNS прибегает для обновления Active Directory к обычным методам LDAP. Сервер производит обновление через LDAP как клиент, что позволяет существующим механизмам безопасности Active Directory проводить те меры безопасности, которые соответствуют этому клиенту.
Поскольку от клиентов Windows 2000 ожидается использование этого метода безопасного динамического обновления, они могут согласовывать безопасные обновления DDNS только с Windows 2000 DNS Server. Если для поддержки Windows 2000 применяются другие серверы DNS, очень вероятно, что они не поддерживают этот метод безопасного динамического обновления. В начальной версии Windows 2000 не предусматривается настройка клиентов для использования методов, совместимых с RFC 2137 и 2535. Использование DDNS без Windows 2000 DNS Server на данный момент означает, что процесс обновления нельзя защитить внутренними средствами, а только извне, на основе, например, таких технологий, как соединение IPsec.
'，TSIG и TKEY
TSIG и TKEY нельзя найти в документах RFC, но можно обратиться к проекту draft-skwan-gss-tsig-o* .txt за информацией о них, об их отношении к RFC 2078 и отличии от RFC 2535. Справочная информация приведена в конце приложения Б.
Настройки уровня контроля доступа
Для администрирования DNS реальная проблема при использовании Windows 2000 DNS для зашишенного обновления заключается в успешном обновлении записей DNS через LDAP. Надо разбираться в работе стандартных механизмов разрешения и владения Windows, поскольку именно от них зависит успех или неудача обновления. Поэтому тот, кто понимает значение стандартных настроек для безопасности зон и данных зоны и разбирается в их регулировке, сможет управлять защитой динамического обновления и за пределами ее стандартной конфигурации. В этой главе мы попытались представить это как можно в более простом виде, с учетом того, что у читателя есть начальный опыт в вьшеупомяну- тых областях и общие представления о принципах безопасности в Windows, включая знакомство со списками контроля доступа (ACL) и понятиями владения.
Стандартная настройка позволяет любому члену группы Прошедшие проверку создавать записи, например А и PTR, в любой зоне. Если запись существует, она может быть прочитана членом группы Все, но изменена только пользователем с учетной записью владельца, который создал эту запись, или разными категориями администраторов, или caMoit системой. Во многих случаях ограничение доступа к изменению и удалению записей после их создания дает желаемые результаты, но в то же время создает проблемы и устаревшие записи. На рис. 7.3 показаны принятые по умолчанию настройки интегрированной зоны. Учтите, что на рис. 7.3 изображена зона, а не запись.
Выделив группу Все, можно показать, что этой группе предоставлено специально настроенное разрешение, а расположенной над ней группе Прошедшие проверку — разрешение создавать все дочерние объекты (что
в данном случае означает записи ресурсов). Специальное разрешение, предоставленное группе Все, обеспечивает доступ для чтения к самой зоне, включая разрешение на просмотр списка записей. На рис. 7,4 показана та же зона, но на консоли управления DNS Server, а не на консоли Active Directory — пользователи и компьютеры, как на рис. 7.3. На рис. 7.4 редактор открыт на параметрах безопасности, присвоенных группе Все. Этот уровень детализации доступен в любом интерфейсе управления.
Рис. 7,3. Настройки контроля доступа зоны в Active Directory
Прежде чем углубляться в изучение этих параметров, обратите внимание на группу под названием Администраторы домена на рис. 7.3. Это предварительно настроенная группа в Active Directory. Как можно догадаться. сделав пользователя членом этой группы, администратор предоставляет ему права администратора DNS. Член группы Администраторы домена может настраивать и запускать DNS на всех серверах DNS в домене, находящихся на контроллерах домена, но не имеет административной властм на口 другими функциями предприятия, если она не передана ему независимо через другие группы.
Следовательно, смысл предыдущего абзаца в том, что любой клиент может согласовать сеанс безопасности с DNS, как идентифицированный пользователь (член группы Прошедшие проверку) может создавать записи ресурсов- Если обновление без зашиты согласовано, сервер DNS предоставляет контекст для этого обновления. На рис. 7.5 показаны параметры безопасности записи А, установленные по умолчанию, причем группа Все имеет разрешение на чтение. Если опуститься на два уровня ниже, как показано на рис. 7.4, можно увидеть тот же набор разрешений, только для запнсн ресурсов.
Рис. 7.4. Параметры безопасности Рис. 7.5. Параметры безопасности записи А для группы Все в зоне
Следует обратить внимание на то, что прошедший проверку пользователь, как показано выше, может создавать объекты в зоне. Хотя возможные типы этих объектов ограничены, на способ, каким они могут быть созданы, ограничений нет. Может оказаться, что сервер DNS вообше не будет принимать в этом участия, если пользователь, как член группы Прошедшие проверку, применит прямые методы LDAP. Иными словами, любой допущенный пользователь может создавать в домене записи, причем любыми способами.
Чтобы изменить набор разрешений, применяемых при создании новых записей, можно изменить наследуемые разрешения контейнера Active Directory, т.е. зоны. В принципе, требования для этого довольно сложны; существуют также разрешения прототипа, или класса объекта в схеме для типа изменяемого объекта, которые также можно применить при создании объекта из прототипа. Как для зон, так и для записей классы схемы dnsZone и dnsNode предоставляют разрешения для вновь создаваемых экземпляров (при стандартных настройках). На рис. 7.6 показаны исходные параметры безопасности класса dnsNode, который применяется для записей. Класс dnsZone подобен ему, но дополнительно дает разрешение пользователям, прошедшим проверку, создавать дочерние объекты.
Если повнимательнее посмотреть на этот рисунок и на рис. 7.5 (где показаны параметры записи), можно обнаружить, что разрешение на чтение для группы Все встречается в обоих случаях、как и на рис. 7.4. Так и должно быть, поскольку параметры на рис. 7.6 являются исходными для остальных. Это разрешение не унаследовано от ACL зоны, и большая часть изменений в ACL зоны не отменяет разрешения для группы Все на чтение новых записей,
Попробуем подвести итог. При согласовании определяется контекст безопасности, который сервер DNS использует при обновлениях DDNS. Любой прошедший проверку пользователь может создавать новые записи. Любой член группы Все может читать записи. После создания запись может изменить только администратор, или система, или учетная запись, которая эту запись создала. Изменение стандартных разрешений, которые даются новой записи при ее создании, возможно путем изменения разрешений содержащей их зоны или объекта схемы dnsNode. Давайте подробнее разберем этот последний метод ~ как задать параметры безопасности ACL, которые будут использоваться для новых записей ресурсов, появляющихся в результате DDNS.
Когда создается любой новый объект Active Directory без явного указания ACL, он получает набор наследуемых разрешений от своего контейнера и стандартный дескриптор безопасности прототипа этого объекта, если только в контейнере не имеется по крайней мере одного более специфичного разрешения. Если такое специфическое разрешение присутствует, разрешения прототипа не используются. Следовательно, если при создании новой записи ресурсов нет запрета на разрешения прототипа, она получает разрешения dnsNode и все применимые наследуемые разрешения зоны, в которой она создается. Теперь рассмотрим специфические разрешения, которые запрещают использование разрешения прототипа. Если контейнер имеет любые наследуемые разрешения, специфичные для класса создаваемого объекта, стандартный дескриптор безопасности прототипа класса не добавляется и новый объект получает только наследуемые разрешения контейнера. Иными словами, если зона получила наследуемое разрешение, применяемое к записям ресурсов (объектам класса dnsNode), новые записи в этой зоне будут получать только унаследованные от нее разрешения.
ЕЭС,ЕЭС,dnsNcde - свойства
ЕЭС,
ЕЭС,
№Ыи I От MHuannt j! Arfu6>m>> J 6»«»tH0Crs j
С3со：дд1рпь
й?，OMTW"flf 也 SOMEHt flPtaiHW! ГИЯ
О >1jTEM
{3 '"I Orwyg I Optjgf J
Рис. 7.6, Параметры безопасности, предусмотренные по умолчанию для новых записей ресурсов
Этот метод подмены исходных параметров безопасности, получаемых объектом Active Directory от своего класса, описан в Руководстве программиста по Active Directory, подготовленном корпорацией Microsoft, которое можно найти в текущей библиотеке MSDN. Однако запрет исходных параметров безопасности из dnsNode и dnsZone в настоящее время невозможен, так как в начальной версии Windows 2000 не заложена возможность сделать это из интерфейса администратора. Недоступны разрешения, специфичные для зоны или объектов записей. Если отмена параметров безопасности прототипа была бы возможна (или станет возможной позже), надо было бы помнить об этом факте, как используя его, так и стараясь его избежать. В любом случае учтите: после создания зоны изменение ее разрешений может повлиять на применение исходного дескриптора безопасности (из прототипа dnsNode) к вновь создаваемым записям. В одних случаях это желательно, в других нет. Если исходные параметры безопасности прототипа не применяются, надо убедиться, что в зоне есть наследуемые разрешения, которые могут заменить отменяемые разрешения прототипа.
Итак, разрешения контейнера (зоны) управляют мерами безопасности, применяемыми к создаваемым в этом контейнере объектам (записям ресурсов); их следует изменять с осторожностью; и надо учитывать два фактора: наследуемые разрешения контейнера (зоны) и стандартные или исходные разрешения прототипа (dnsNode). Мы еще не говорили, что изменение параметров безопасности прототипа dnsNode (например, если разрешение чтения для группы Все кажется слишком либеральным)— действие, которое влияет на каждый домен в Active Directory. Эта мера не только будет слишком суровой для группы Все, но следует также понимать причины, по которым эта группа получила это разрешение, и почему это сделано таким трудно отменимым способом. Если последствия будут приемлемы для вас, изменение разрешений для dnsNode — самый простой способ произвести подобные изменения. Но никаких действий на уровне схемы не следует предпринимать, не обдумав.
После того как зона создана, добавление разрешений, наследуемых всеми дочерними объектами, изменяет параметры безопасности будущих записей в этой зоне Поскольку классы dnsNode и dnsZone дают группам Все н Прошедшие проверку разрешения читать данные зоны и создавать новые записи, то, как было показано раньше, для добавления новых разрешений остается очень немного возможностей. И наоборот, изменение параметров безопасности прототипов может быть целесообразно, если стандартные настройки не подходят для вашего окружения. Это, в свою очередь, делает необходимым глубокое понимание механизма разрешений классов схемы и способов восстановления желаемых разрешений либо нз прототипа, либо из зоны.
Если всё это кажется вам чересчур трудным, не волнуйтесь. После небольшой практики все станет на свои места. Так зачем же мы все это описываем? Если Microsoft или сторонний разработчик путем расширений сделает возможным определение разрешений, специфических для зон или записей, вы будете готовы к этому.
Описанный метод отмены исходного дескриптора безопасности работал в бета-цикле, подготовительном перед выходом окончательной версии Windows 2000. Однако в этой окончательной версии, кажется, что-то изменилось, хотя еше не документировано. Экзематяры классов, для которых раньше это удавалось, теперь ведут себя по-другому. Поскольку безопасность — серьезная проблема, и уровень ее сложности тоже не мал, вероятно, что новая информация и, возможно, методы появятся с развитием Windows 2000. Надо ждать от Microsoft уточненной информации об изменении параметров безопасности данных зоны. На этот момент, если надо отрегулировать стандартные значения безопасности прототипа, возможный метод — оставить без изменения минимально необходимый набор параметров прототипа и добавлять наследуемые разрешения для тех зон, где этого минимального набора недостаточно. Изменения в классы схемы можно внести с помощью консоли управления Active Directory: схема (SCHMMGMT.MSC), а изменения в зонах — через консоль управления Active Directory: пользователи и компьютеры (DSA.MSC)или консоль управления DNS Server (dnsmgmt . MSC).
Теперь обратимся к другой стороне безопасности данных DNS ——к аудиту. На рис.7.7 видно, что исходные параметры безопасности делают записи, создаваемые в зоне, доступными для аудита.
Рис. 7.7. Аудит ACL записи А
Флажки на этом рисунке показывают, какие действия будут вызывать аудит. Они закрашены серым, поскольку эти настройкн унаследованы от высшего уровня. Когда аудит включен, эти настройки разрешают все действия, кроме чтения записи, которое вызывает запись в журнал аудита.
Если вернуться к рис. 7.4, можно заметить, что разрешение чтения для группы Все отображалось пустым квадратиком. Причина тому — то,
что разрешение применяется непосредственно к записи ресурсов исходя из класса dnsZone. Его применение означает, что, если требуется изменить назначенное таким способом, без наследования, разрешение, лучший способ — установка параметров перед созданием любых объектов. После того как они созданы, изменение этого, но только этого, разрешения требует работы с каждой записью отдельно.
Группы доступа: DNSUpdateProxyDHCP и группа DNSUpdateProxy
Чтобы уменьшить сложность всех этих операций, Microsoft составила предварительный план для использования в DHCP. Вместо того чтобы позволить клиентам становиться владельцами записей и поэтому зависеть от их поведения при очистке, администратор может позволить DHCP производить регистрацию. После этого DHCP становится владельцем записей и может модифицировать и очищать их. Все это хорошо, но возникают некоторые небольшие проблемы.
Если используется стандартное поведение DHCP, клиенты Windows перестают владеть своими записями A, a DHCP владеет записями PTR для их IP-адресов. Это допустимо, так как клиент владеет именем, а DHCP — IP-адресами. Но если клиент меняет свое имя или вновь присоединяется к домену, он оставляет свою запись в зоне. Для клиентов не Windows 2000 DHCP может регистрировать как имя, так и IP, и владеть обеими записями. Это создает сложности, если серверы DHCP настроены для разделения ответственности в подсети, поскольку изменить запись А может только один из серверов, несмотря на то, что аренду мог дать любой из них (обычно каждый сервер единолично владеет набором IP, поэтому с PTR такой проблемы не возникает).
Для решения этих проблем в Windows 2000 создана особая группа DnsUpdateProxy. Если компьютер, сделанный членом этой группы, создает новую запись DNS, эта запись имеет семантику, несколько отличную от рассмотренной до сих пор. Создатель не становится автоматически владельцем записи, но запись, созданная членом группы DnsUpdateProxy, поступает во владение первой учетной записи, которая первой успешно проведет ее обновление или регенерацию.
Хотя это и решает некоторые проблемы, но создает новые. Следует указать на одно очень важное обстоятельство: все записи, динамически созданные компьютерами, членами этой группы, получают эту новую семантику. Если такой компьютер регистрирует запись, все равно, через DHCP для клиента или сам для себя, она также приобретает это новое поведение. Это немаловажно, если компьютер, например контроллер домена, производит много динамических обновлений. (См. в этой связи рассмотрение Netlogon в следующем разделе.)
Группа DnsUpdateProxy предназначена для того, чтобы иметь в своем составе серверы DHCP. Это позволяет им регистрировать записи А для клиентов и передавать владение этими записями клиентам, когда они будут обновлять записи. Любые записи, динак1ически зарегистрированные ма-
шиной, на которой работает DHCP, включая ее собственные записи или записи SRV, созданные в Netlogon при условии, что она также контроллер домена, могут быть объектами нападения, если машина входит в группу DnsUpdateProxy. Выход — отказаться от этого метода для контроллеров домена и вносить записи DNS для членов DnsUpdateProxy вручную.
Подведение итогов безопасности DNS
В этом разделе изложены некоторые основы. Интеграция в Active Directory позволяет использовать методы безопасности для контроля за доступом к данным DNS и обновлять их. Без этой интеграции Windows 2000 не предусматривает мер безопасности для DNS.
Обновления защищаются посредством методов Microsoft, которые являются модификациями методов, предусмотренных в RFC 2078. На сегодняшний день эти методы специфичны для Microsoft. Клиенты Windows 2000 нуждаются в расширении, чтобы использовать серверы DNS сторонних разработчиков и методы безопасности, описанные в RFC 2137 и 2535. Процесс безопасного динамического обновления предусматривает поддержку в Windows 2000 Kerberos как провайдера безопасности. Сам же сервер DNS использует при обновлении данных DNS по требованию клиента методы LDAP.
При хранении в Active Directory данные DNS подлежат обычным разрешениям ACL, Стандартные настройки дают группе Прошедшие проверку возможность создавать записи, а группе Все — просматривать список записей зоны и читать записи ресурсов. Эти разрешения исходят от объектов схемы dnsZone и dnsNode и в начальной версии Windows 2000 могут быть изменены только здесь или в записи после ее создания.
После создания запись ресурсов переходит во владение создавшей ее учетной записи, если только эта учетная запись не является членом группы DnsUpdateProxy. В этом случае владельцем становится первая учетная запись, которой удалось обновить или регенерировать новую запись.
Итак, теперь вы получили представление о стратегии Microsoft в безопасном динамическом обновлении для зон DNS, интегрированных в Active Directory. У нее есть хорошие стороны, но и некоторые недостатки, Прежде чем критиковать ее, подумайте, что эта методика — первая в области DDNS. Не будет преувеличением сказать, что ни одна из коммерческих операционных систем не продвинулась так далеко по пути безопасности и ее реализации в DDNS. Многое из того, что реализовано, явилось компромиссом между необходимостью соблюдения временных рамок выхода продукта и его требуемой функциональностью, с одной стороны, и вновь появляющимися RFC, которые либо уже стали стандартами, либо станут ими когда-нибудь. Самые последние документы RFC по защите данных и обновлений DNS базируются на инфраструктуре открытых ключей, которая сейчас только создается, но для участия в которой Windows 2000 уже в значительной степени готова.
Зависимость Active Directory от записей SRV
Эффективная работа Active Directory частично зависит от способности клиентов и служб сервера быстро определять местонахождение основных служб в доменах, составляющих Active Directory. DNS служит для решения большинства таких задач.
Когда компьютер, входящий в домен, например, загружается, он должен связаться с контроллером своего домена, или, возможно, другим контроллером домена, если первый не поддерживает Глобальный каталог. Или, если клиент на одном компьютере посылает запрос на ресурс в другом домене в лесу Active Directory, контроллер этого домена участвует в принятии решения, разрешить запрос клиента или отклонить.
При потребности в ресурсах, которые уже были обнаружены, например, если клиент открывает папку общего доступа в своем домене, в услугах DNS нет необходимости. Однако очень часто на первом этапе такие услуги по обнаружению нужны, и DNS активно используется для этого в архитектуре Windows 2000.
Для максимальной эффективности этого процесса Windows 2000 поддерживает довольно сложный набор записей SRV и CNAM Е. Отвечает за это процесс Netlogon в контроллерах домена, который использует динамические обновления для создания этого набора и его очистки от записей, которые признаны недействительными.
Служба обнаружения домена
Клиент Windows 2000 может предпринимать поиск контроллера домена, используя три типа информации о домене: доменное имя (и, следовательно, домен DNS в начальной версии), глобально уникальный идентификатор (globally unique ID, GUID). который является внешним и уникальным именем домена, и идентификатор сайта. При определении местонахождения контроллера (а. как будет показано, большая часть основных служб размешается на контроллерах) клиент передает эти данные, если они ему известны, в службу обнаружения домена.
Active Directory может быть разделен между сайтами, которые используются для представления топологии сети. Один домен может быть представлен на нескольких сайтах, а сайт может входить в несколько доменов —т.е. на сайте могут быть машины из нескольких доменов. Сайты позволяют облегчить передачу сообщений в сети, направляя их на "локальнее" машины, если это возможно для запрашиваемой службы.
Служба обнаружения домена Windows 2000 использует информацию всех трех типов, которую может предоставить клиент, чтобы определить IP-адрес с максимально возможной эффективностью. Если клиент знает, на каком сайте он находится, и запрашивает конкретную службу, например службу LDAP в конкретном домене, поиск может начаться с запроса
записи SRV _ldap._tcp, специфической для запрашиваемого домена и сайта. Если служба обнаружения уже знает контроллер этого домена, она также может послать запросы LDAP для проверки информации, которая будет возврашена клиенту.
Служба обнаружения использует сведения об именах, присутствующих в базе данных DNS, Как было сказано, служба Netlogon на контроллерах домена накапливает эти сведения в ходе динамических обновлений. Если динамическое обновление запрещено, это становится невозможно и поддержание эффективности процесса поиска целиком возлагается на клиента (к несчастью для него). Однако если топология контроллеров доменов и сайтов мало меняется и имеет высокую степень доступности, эта задача не так уж трудна.
Структура записей SRV
Netlogon регистрирует множество различных уровней записей. На рис. 7.8 показана в развернутом виде часть очень небольшого Active Directory с одним доменом, в котором есть только один контроллер. Иными словами, это выглядит так же просто, как делается. '
-Овйствк「ВИД「6，「& 圃，户卤乌〔偉-Овйствк「ВИД「6，「& 圃，户卤乌〔偉vCtpiwhm|vCtpiwhm|I hq example eetI hq example eet44：：^ Крксл ®w Ор«кв •_15|_I
-Овйствк「ВИД「6，「& 圃，户卤乌〔偉
-Овйствк「ВИД「6，「& 圃，户卤乌〔偉
vCtpiwhm|
vCtpiwhm|
I hq example eet
I hq example eet
4
4
Рис. 7.8. Прхтой набор записей SRV, поддерживаемый Netlogon
Первый факт, который надо запомнить, — то, что в обширной системе может быть несколько записей с разными IP-адресами, но одинаковыми остальными данными для множества регистраций. Если клиент запрашивает конкретное имя, возвращаемые IP-адреса определяют все записи с таким именем. Чем больше система, тем больше записей можно получить для каждого домена и тем больший набор записей выстраивается под доменом, который находится в корне Active Directory (под корневым доменом леса).
Рис. 7.8, с изображением консоли управления DNS Server, дает представление о структуре субдомена. Фактически структура создается в поле Имя, а не в поле домен записей SRV (см. листинг 7.1).
Во-вторых, заметьте, что в структуре присутствуют записи для служб LDAP, GC, Kerberos и Kpasswd. LDAP используется для служб LDAP, которые в Windows 2000 всегда размешаются на контроллерах домена. GC применяется для служб Глобального каталога, которые также всегда находятся на контроллерах домена, но не на всех. В Windows 2000 серверы Kerberos н серверы изменения пароля Kerberos (Kpasswd) также всегда бывают на контроллерах домена.
Во всех записях указан протокол TCP, кроме двух служб Kerberos, которые также доступны через протокол передачи дейтаграмм пользователя (UDP). Это показывают обозначения _ТСР и _UDP в части протокола записей SRV.
Записи со спецификатором сайта в имени служат для классификации служб по их расположению в топологии Active Directory. Поскольку для каждого сайта указан индивидуальный контроллер домена, необязательно, чтобы компьютер физически находился на этом сайте или даже был логически определен в топологии сайтов Active Directory как член этого сайта. Если сайт не имеет локального провайдера для конкретной службы, Netlogon регистрирует его предположение о наилучшем контроллере домена, у которого член этого сайта у первого будет запрашивать данную службу. Каким образом Netlogon определяет это, базируясь на топологии сайта, не входит в круг вопросов DNS и не рассматривается в этой книге. Важно только запомнить, что Active Directory работает более эффективно, если Netlogon может использовать динамические обновления DNS для настройки своих записей SRV.
Затем эта структура дополняет доступные службы записями, которые имеют спецификатор _msdcs. В этом наборе записей содержатся определенные объявления, например запись со спецификатором pdc, которая представляет контроллер, выполняющий эмуляцию NT 4 PDC для доменов нижнего уровня. Весь набор записей повторяется в каждом домене. Также добавляются под доменом вверху иерархии Active Directory записи для поиска в Active Directory, в котором известен только корневой домен.
Если необходимо отредактировать эту структуру вручную, рекомендуется найти всю доступную информацию. Производительность вашей работы выиграет, если структура будет точно отображать Active Directory.
Записи SRV без DDNS
Если обновление DDNS не разрешено, обратитесь к ручным методам управления данными зоны. Они должны охватывать не только записи обычных типов ( A, PTR. CNAME, NS и т.д-), но и записи SRV и CNAME, которыми при DDNS занимается Netlogon. Как уже было сказано, записи SRV образуют самую основу службы обнаружения домена в архитектуре Active Directory и являются необходимыми.
Хотя минимальный набор записей SRV создается в виде файла NETLOGON. DNS (см. листинг 7.1) и сохраняется в каталоге %windir%\System32\config при работе утилиты dcprom。， которая формирует контроллер домена, один взгляд на этот листинг может дать представление о трудности работы с записями SRV вручную.
Листинг 7.1. Пример файла NETLOGON.DNS
hq.example.net.600 IN A 169.25^,101,113
_ldap._tcp.hq.example.net. 600 IN SRV 0100 389
del.hq.example.net.
_ldap,_tcp.pdc,_msdcs.hq.example,net,600 IN SRV
0 100 389 del.hq,example.net.
_ldap._tcp.855aa338-2137-^ad5-9fdc-790S14150512.
domains._msdcs,hq,example.net.600 IN SRV 0 100 389
del.hq.example.net.
(53506455-54 59-4 564-a4 fl-ebb484 c2 fc3c. _msdcs . hq. example - net
600 IN CNAME dcl.hq.example.net.
_kerberos._tcp.de._msdcs.hq.example.net.
600INSRV010088 del-hq.example.net.
_ldap._tcp.de._msdcs.hq.example.net,
600INSRV0100389 del.hq,example.net.
_kerberos,_tcp,hq._msdcs.hq.example.net.
600INSRV010088dcl.hq.example.net.
_kerberos._udp.dc._msdcs,hq,example.net.
600INSRV010088dcl.hq.example.net.
一kpasswd._tcp.hq,_msdcs.hq.example.net,
600INSRV0100464del.hq.example.net,
_kpasswd._udp,hq,_msdcs.hq.example,net.
600INSRV01004^4del.hq,example.net.
_ldap,_tcp.HQ-Site._sites.de,_msdcs.hq.example.net.
600INSRV0100389del.hq,example.net.
_kerberos._tcp.HQ-Site._sites.de._msdcs.hq,example.net.
600INSRV010088dcl.hq.example.net.
_ldap. tep.gc._msdcs.hq.example.net.
一 600 -IN SRV- 0100 3268 dcl.hq.example.net,
gc._msdcs.hq.example.net.600 IN A 169.254.101.113
_gc._tcp.hq.example,net,600 IN SRV 0 100 3268
del.hq.example.net
_ldap._tcp.HQ-Site,_sites.gc,_msdcs,hq.example.net.
600INSRV01003268dul.hq.example.net.
_gc,_tcp.HQ-Site._sites.hq.example.net.
600INSRV01003268del.hq.example.net.
_ldap,_tcp.Remotel-Site._sites,hq.example.net.
600INSRV0100389 del.hq.example.net.
_ldap._tcp.Remotel-Site,_sites.gc._msdcs,hq,example.ner.
600INSRV01003268 del•hq,example.net.
_kerberos.一tep.Remotel-Site,_sites.dc._rasdcs.hq.example.net.
600INSRV010088 dcl.hq.example.net.
_ldap._tcp.Remotel-Site._sites.dc._msdcs.hq,example.net.
600INSRV0100389 del -hq.example.net.
_kerberos._tcp.Remotel-Site._sites,hq.example.net.
600INSRV010088 del.hq.example.net.
_gc,_tcp.Remotel-Site._sites,hq.example.net.
600INSRV01003268 dcl.hq.example.net.
При изучении этого файла можно прийти к выводу, что он представляет логическую структуру, которую надо корректно создать. Это менее трудная задача, так как указанные записи содержат полную спецификацию и могут быть вставлены непосредственно в файл зоны,
Легко обнаружить, что запрещение службе Netlogon управлять структурами SRV в DNS ciLibHO влияет на общую производительность. Эта структура помогает клиентам, и, если угодно, всей системе быстро и эффективно находить основные службы. Благодаря этой структуре SRV цепочки последовательных запросов заменяются прямыми запросами. Она также используется для указания "нанлучшнх" и **самых близких" провайдеров для различных служб на основе информации, в каком домене и особенно на каком сайте они находятся.
Без динамических обновлений эта структура требует постоянной регулировки в соответствии с изменениями системы; иными словами, она не обеспечивает оптимальную производительность. Это в особенности касается записей, в полях имени которых стоят идентификаторы GUID (длинные 128-битовые метки, не поддающиеся расшифровке), используемые службами для оптимальных, прямых запросов. Там, где правила предприятия допускают, рекомендуется делегировать зоны в DNS на Windows 2000, где разрешено динамическое обновление, чтобы такие структуры могли поддерживаться автоматически. Если весь домен DNS не может быть делегирован, подумайте о делегировании _msdcs, _sites, _tsp и _udp при условии, что вашу DNS изначально можно заставить поддерживать символы подчеркивания (_).
Попробуем представить Active Directory и DNS как единое целое
До этого момента очень немногие темы этой главы рассматривались подробно. Если вы думаете, что это из-за того, что длинное изложение задачи приводило к простому ответу, вы недалеки от истины. Стандартная конфигурация доменной системы Windows 2000 предназначена для исходной точки развертывания системы, в которой Microsoft DNS играет главную роль. Последующее развертывание может включать DDNS и интеграцию в Active Directory; применение DHCP для обслуживания клиентов; безопасное динамическое обновление; и наконец, защиту Active Directory брандмауэром. Продвижение от исходной точки по любому из этих направлений требует разрешения новых проблем.
В следующих разделах собраны замечания, призванные помочь в решении этих проблем, как новые, так и высказанные ранее, объединенные по крайней мере по некоторым из этих направлений.
Топология Active Directory и DNS
В первой версии Windows 2000 практически вся открытая документация написана исходя из предположении об однозначном соответствии между структурой домена Active Directory и той, которая используется в DNS. По сути, Microsoft и множество ее партнеров поработали над тем, чтобы сделать это строго однозначное соответствие между двумя пространствами имен в большей степени удобством для развертывания новых систем, чем требованием для всех систем.
Допускается отличие тождества DNS клиентов и серверов от доменного имени Active Directory. Хотя при этом возможна нормальная работа, она не всегда достигается без трудностей. В период между выходом версии Beta 2 и фиксацией окончательного кода для последующих версий бьгло сделано немало изменений, призванных облегчить такую независимость пространств имен. Однако, как и в случае с независимостью от имен NetBIOS, в этом направлении еще многое предстоит сделать.
Другое обстоятельство — то, что непосредственно перед фиксацией кода документ RFC 2672 "Неокончательная переадресация имен DNS", где была определена запись DNAME, задал новый стандарт. 3ia запись разрешает подстановку ветви пространства имен DNS так, чтобы она была известна под другим доменным именем DNS. При этом создается псевдоним ветви доменной системы, подобно тому, как CNAME позволяет создавать псевдонимы для обычных имен узлов. С помошью DNAME можно отобразить xyz.com на существующую ветвь DNS, например corp.com, так что ее разветвления, в частности corpwoke .corp, com, будут известны под новыми доменными именами, т.е, corpwoke.xyz.com.
В этом году следует ожидать появления многих документированных вариантов решений в этой области. В настоящий момент наиболее прямой путь изоморфизма пространств имен — единственный, для которого максимально проверен процесс развертывания и существует писаное руководство. Легко доступно, не создает проблем и хорошо документировано производителем прежде всего развертывание Windows 2000 Active Directory в крупных существующих инфраструктурах TCP/IP. На данный момент, если вы хотите или должны следовать по этому пути, не теряйте контакта со службами консультации Microsoft н будьте готовы к тому, что кое-где придется выполнять настройку вручную.
Согласование топологии серверов DNS с размещением контроллеров домена
За исключением загрузки данных сети при передачах зон и загрузки компьютера, интеграция DNS в Active Directory, скорее всего, потребует некоторых трудоемких операций, которых, однако, можно избежать, решив, где на предприятии необходимо разместить контроллер домена.
Предпосылки к этому решению примерно соответствуют соображениям по размещению служб DNS.
Будет ли тот или иной режим серверов кэширования (см. главу 11) достаточным, остается трудным вопросом, даже если было установлено, что для сайта требуется контроллер домена. Однако если размещение контроллеров определяется требованиями доступности доменного окружения Windows 2000 даже при сбоях в работе сети, будет целесообразным также расположение на этих местах копий зоны.
Очень важно определить, куда клиенты DHCP будут посылать обновления. Если DNS не интегрирована, все они сосредоточиваются на одном основном сервере зоны, где бы он ни находился. Если основные серверы локально доступны на контроллерах домена, это лишь повышает нагрузку машин за счет репликации. Но поскольку контроллеры домена и так уже несут солидную нагрузку, вследствие поддержки LDAP и Kerberos, а также репликации, не лишним было бы предусмотреть локальные дополнительные серверы или серверы только для кэширования, на которые будут направляться клиенты. В случае, когда эти локальные дополнительные серверы получают передачи от своих локальных контроллеров, основные зоны DNS на контроллерах домена автоматически становятся своего рода ^передовыми укреплениями" между сайтами. Эти контроллеры несут только дополнительную нагрузку от DNS, возникающую при регистрациях и регенерациях и перенаправляют репликацию и передачи зоны на дополнительные серверы. Дополнительные серверы несут нагрузку DNS в виде запросов клиентов и кэширования ответов, полученных от пересылочных серверов.
Стандартные группы в доменном окружении
При работе в домене сетевых служб Windows 2000 компьютер-сервер является участником Active Directory. Это означает, что для использования доступно несколько стандартных, изначально определенных групп. В начальной версии Windows 2000 не слишком многие из них связаны непосредственно с сетевыми службами, как это можно видеть в табл, 7.1. Приняв во внимание эти группы, можно облегчить делегирование административной ответственности или, в случае DnsUpdateProxy, уменьшить проблемы, которые возникают при использовании DHCP для динамического обновления DNS.
Доступность данных зоны DNS
При интеграции данных зоны в Active Directory эта информация становится доступной для запросов LDAP. От самого Active Directory используется только механизм безопасности, который контролирует обновления и доступ к чтению. Поскольку по своей природе данные зоны обязаны быть доступными, записи ресурсов имеют разрешение на чтение для всех пользователей. В настоящее время, кажется, в системе не суще-
ствует ничего, что помешало бы любому пользователю, который может получить контекст безопасности, разрешающий сеанс LDAP, пересчитать весь набор данных зоны. Размер таких возможностей, доступных при пустом контексте безопасности, зависит от ограничений, наложенных на группу Все и на пустые, или анонимные, подключения LDAP. Реализация последних в предварительных версиях Windows 2000 подвергалась некоторым изменениям, В настоящий момент наиболее хорошо разработанное решение — это использование брандмауэра, но оно, по- видимому, разрешает пересчитывать данные зоны всем допустимым пользователям Active Directory. Хотя это и выходит за рамки рассматриваемой темы, с подобными же проблемами связана и возможность для любого члена группы Прошедшие проверку создавать записи ресурсов и затем владеть ими.
Таблица 7.1. Стандартные группы сетевых служб в Active Directory
Название группы
Описание
DnsUpdateProxy
Члены этой группы не становятся автоматически владельцами записей ресурсов, которые они создали в динамической DNS
DnsAdmins
Локальная группа домена, члены которой могут администрировать серверы DNS в домене
Администраторы DHCP
Локальная группа домена, члены которой могут администрировать серверы DHCP в домене. Учтите, что для авторизации сервера DHCP необходимо членство в группе Администраторы предприятия
Пользователи DHCP
Локальная группа домена, члены которой могут проверять конфигурацию сервера DHCP в домене
Пользователи WINS
Локальная группа домена, члены которой могут проверять конфигурацию сервера WINS в домене
Навигация в службах каталогов и нагрузка на DNS
В начале этой главы говорилось, что DNS была встроена в верхний уровень Active Directory. Однако не было сказано, что в традиционной системе LDAP навигация по структуре служб каталогов происходит путем перенаправлений. Если клиент, находящийся на четвертом сверху уровне, пытается получить доступ к ресурсу на втором сверху уровне в другой ветви структуры каталога, он итеративно поднимается вверх по дереву структуры, от одного узла к другому, а затем спускается по ветви, на которой находится ресурс. На каждом этапе совершается путешествие туда и обратно: запрос LDAP и перенаправляющий ответ от каждого последующего сервера LDAP. Это традиционный процесс перенаправлений LDAP, в котором каждый узел знает своих соседей и может перенаправить к ним клиента, который снова будет запрашивать у них. и т.д.
Чтобы использовать доступность информации DNS и совместимость структуры каталога со структур。访 DNS, Microsoft изменила способ навигации. В последней версии Windows 2000 клиенты (если только они имеют достаточно информации, например благодаря поиску в Глобальном каталоге, о том, в каком домене находится ресурс) запрашивают ссылки непосредственно в DNS. Если клиенту нужны, например, службы L:DAP в домене, он может запросить в DNS записи SRV _ldap._tcp, имеющиеся в домене. При этом клиент получает прямой путь к службам LDAP для конечного домена, избегая долгих перемещений по дереву LDAP. Это также увеличивает использование (и пользу от) DNS.
Выше было рассказано, как Netlogon использует DNS и записи SRV. И можно ожидать в будущем роста применения SRV для определения местонахождения служб, например _http._tcp. Все эти факторы добавляют нагрузку на DNS.
Нагрузка при обновлении DDNS
В этом разделе собраны в основном советы и замечания по влиянию DDNS на производительность сервера. Любую конкретную систему надо проанализировать, исследовав ее поведение-
При использовании DDNS файлы зоны находятся в постоянном изменении. Разные системы Microsoft различаются по своему стандартному поведению: от четырех попыток обновить дерево DNS в час до одной в день для Windows 2000 Professional и до одной в семь дней для аренды DHCP. Параметр очистки — интервал блокирования, рассмотренный выше в этой главе, — имеет крайне важное значение для уменьшения количества частых и бесполезных репликаций или передач зоны.
Но нельзя уйти от того обстоятельства, что изменяемые зоны требуют постоянных передач. Если характеристики зон стандартны, используется уведомление и подчиненные серверы запрашивают добавочные передачи IXFR, нагрузка минимальна. При хранении в Active Directory эти изменения распространяются последовательно. Однако небольшие изменения вызывают относительно трудоемкие сопутствующие операции в технологии репликации Active Directory.
Active Directory, являясь слабо конвергентным, допускает много возможностей для одновременного получения различных авторитетных ответов от разных серверов. Однако это весьма вероятно и при обычных передачах зоны.
Конечно, все это ——спорный вопрос, поскольку единственная альтернатива состоит в том, чтобы не использовать динамическое обновление. Просто учитывайте эти факторы при планировании системы DNS. Там, где достаточно кэширующих серверов, имеется еще один небольшой довод за их использование: благодаря им предотвращается нагрузка, возникающая вследствие постоянных передач зоны.
Резюме
В этой главе рассматриваются важнейшие результаты, которые возникают нз (иногда естественного, а иногда и нет) соприкосновения между Active Directory и DNS. Самое заметное из них — DDNS и последствия, которые вытекают из свойств Active Directory. Microsoft расширила область этого соприкосновения, чтобы воспользоваться им для обслуживания записей SRV и динамических обновлений. О том, насколько им это удалось, предоставляется судить читателю.
Работа с серверами BIND
В этой главе...
Сообщение между серверами имен. При связи сервера имен со старыми серверами имен на базе BIND могут возникать проблемы, хотя и разрешимые. В этом разделе предложены некоторые предупредительные меры при связи с серверами имен этих типов.
Переход с BIND на Windows 2000 DNS. В этом разделе описаны действия, необходимые при интеграции или замене серверов имен на базе BIND (версий 4 и 8) на Microsoft DNS.
Работа BIND в Windows. Хотя этот способ еше не доступен для доменной системы Windows 2000, в этом разделе сообщается о возможном ограниченном переносе BIND на Windows.
Другие различия в загрузочных файлах и файлах зон. Переход от BIND и ее интеграция в Microsoft DNS требуют внимания к нескольким особенностям файлов зоны и конфигурации, которые здесь описаны.
Сообщение между серверами имен
Все серверы имен должны быть способны общаться друг с другом. Если они не делают (или не могут) этого, имена узлов Internet не смогут разрешаться и от World Wide Web будет столько же пользы, сколько от древнего Commodore VIC 20 на чердаке у моих родителей. Microsoft DNC соответствует требованиям RFC в смысле сообщения с другими серверами имен. Типы общения, которые должны понимать серверы имен, включают запросы, ответы на запросы и передачи зон. Запросы и ответы не требуют пояснений, поскольку это базовые компоненты разрешения имен. Клиенты делают запросы, которые, в свою очередь, могут заставлять серверы выдавать дополнительные запросы, пока ответ нс будет найден и возвращен клиенту. Передачи зон — это механизмы, которые позволяют главным серверам распространять информацию среди подчиненных серверов и таким образом увеличивают возможности "распределенной" системы. Формат сообщений и пакеты запросов имеют одинаковую структуру и одинаковое побитовое выравнивание, Windows 2000 DNS Server принимает и соответствующим образом отвечает как на итеративные, так и на рекурсивные запросы. Даже при том, что Windows 2000 DNS Server соответствует стандартам, следует быть осторожным с возможностями, которые предлагают альтернативные системы.
Использование Active Directory налагает определенное ограничение на выбор служб DNS. Требуется поддержка записей ресурсов (SRV). Если поддерживаются динамические обновления, очень рекомендуется использовать добавочные передачи и уведомление. Самая ранняя версия BIND, которая удовлетворяет этим требованиям, — 8.1.2.
Прежде чем обращаться к конкретным версиям, следует запомнить, что использование разработанных Microsoft записей службы имен Internet для Windows (WINS) и обратных записей службы имен Internet для Windows (W1NS-R), а также запрет исключать их из передач зоны на серверы DNS, не являющиеся разработками Microsoft, может вызвать проблемы.
Связь с BIND версии 4.9.4 и младше
В принципе, использование BIND 4-Х оказывается нежелательным для любых целей, исключая некоторые очень специфические случаи. Если доменное окружение уже установлено, Active Directory требует, чтобы DNS поддерживала записи SRV. В некоторых случаях может поддерживаться взаимодействие между серверами; если это так, необходимо учесть эти проблемы.
Главная причина для беспокойства при работе Windows 2000 DNS Server совместно с версиями серверов имен на базе BIND 4.9.4 и младше — это сообщения, которые посылаются при передаче зоны. Хотя они и зафиксированы в RFC, старые версии BIND и их производные могут испытывать затруднения с сообщениями, содержащими несколько запи-
сей ресурсов. В подобных случаях администратор должен таким образом настроить Windows 2000 DNS Server, чтобы при передачах зоны на дополнительные серверы BIND посылались сообщения только с одной записью. Это устраняет множество проблем, непосредственно связанных с передачами зоны, а также защищает остальные серверы имен в сети.
В NT 4.0 это можно осуществить, раскомментировав строку BindSecondaries в файле загрузки, или, во всех версиях, изменив значение раздела BindSecondaries в реестре, или, в Windows 2000, установив флажок Дополиительные службы BIND во вкладке Дополнительно диалогового окна Свойства сервера. В Windows 2000 на передачи между двумя серверами DNS Windows 2000 этот параметр не действует. Он распространяется в пределах сервера, воздействуя на все передачи зоны на дополнительные серверы.
В NT 4.0, если администратор хочет добиться изменения путем редактирования загрузочного файла и если система серверов имен загружается из реестра, он должен выполнить следующие действия.
Изменить значения в реестре так, чтобы загрузка происходила из файла, а не из реестра.
Создать загрузочный файл, соответствующий текущей конфигурации.
Запустить панель управления DNS и выполнить команду Обновить файлы данных сервера из меню DNS.
Раздел реестра, который воздействует на этот режим, содержит двоичный оператор. Значение раздела BindSecondaries — просто единица или нуль. Двоичное значение 1 соответствует состоянию "истина", что подразумевает использование дополнительных серверов BIND, а 0 означает состояние "ложь''.
Недостаток NT 4.0 — отсутствие инструмента, позволяющего создать загрузочный файл в соответствии с настройками реестра — исправлен в версии Windows 2000. Этот инструмент необходим, так как переключение из режима загрузки из файла в режим загрузки из реестра и обратно может создать проблемы и само оказаться проблематичным, поскольку настройки конфигурации могут потеряться при переходах. Поэтому администратор должен уделять очень большое внимание каждой детали, когда он вносит эти изменения и, если угодно, любые другие. Windows 2000 решает эти проблемы, поскольку реестр и загрузочный файл поддерживаются в одинаковом состоянии, если сервер загружается из файла.
Связь с BIND 8
При работе с BIND 8 уже не надо беспокоиться о количестве записей ресурсов на сообщение. Взамен этого у BIND 8 появилось множество других особенностей. Если BIND 8 используется для главного сервера, администратор Microsoft DNS должен следить за тем. чтобы главный сервер опрашивался соответствуюшим образом. Иначе говоря. BIND 8 может фильтровать запросы, адресованные на или поступившие от опреде- Глава 8. Работа с серверами BIND 161
ленных адресов и портов. Допустим, система, в которой работает BIND 8, имеет двойное назначение и предоставляет данные зоны как для внешней, так и для внутренне兑 сети. Сервер BIND 8 может быть настроен так, чтобы давать различные ответы на запросы в зависимости от интерфейса, на который поступил запрос, или даже от номера порта, используемого для связи. BIND 8 позволяет администраторам определять, кто может производить передачи зоны, а также кто может запрашивать систему, или даже номера портов, разрешенных для клиентских запросов. Если сервер Microsoft DNS работает как дополнительный, следует убедиться, что все настройки контроля доступа установленье так, чтобы разрешить передачу зоны дополнительным сервером и что дополнительный сервер направлен на правильный интерфейс.
Как мы уже отмечали, BIND 8.1.2 поддерживает минимальные требования Active Directory, Таким образом, использовать реализацию BIND начиная с версии 8.1.2 как дополнительный сервер не только возможно, но и не чревато проблемами. С другой стороны, очень вероятно, что в будущем BIND 8.1.2 или старше сохранит свои позиции во многих системах, и даже делегирование полномочий на исходные данные в Windows 2000 DNS Server может быть за пределами возможного. В этом случае придется преодолеть множество проблем.
Если BIND служит как основной сервер, надо учесть, что здесь не имеется возможности защитить процесс динамического обновления, который понимают и используют клиенты Windows 2000, по крайней мере в начальной версии. Это означает, что нельзя применять механизмы безопасности, которые в другом случае были бы поступнм. В конечном результате, не исключено, что придется отказаться от динамического обновления. Это, в свою очередь, означает, что надо будет вручную обслуживать не только записи обычных типов, т.е. адресов (А), указателей (PTR) и так далее, но и записи SRV н их структуры. Некоторое представление об этом дает глава 7, ''Динамическая DNS и Active Directory''. Если добавляются только первоначальные записи NETLOGON. DNS, пути доступа Windows 2000 Active Directory не будут оптимизированы, как это было бы при обновлении записей SRV, например _Sites, процессом Neilogon.
Переход с BIND на Windows 2000 DNS
Администратор, который работает с BIND и намерен реализовать решение Windows 2000 DNS, прежде всего должен ответить на несколько вопросов.
■ Будет ли система Windows 2000 DNS работать в сочетании с BIND? Если да, то будет ли она основной или дополнительной? И какая версия BIND используется?
■ Послужит ли система Windows 2000 DNS для полной замены BIND, или она будет работать только в делегированной части домена (субдомене)?
Если Windows 2000 DNS Server будет использоваться в сочетании с BIND, необходимо знать, какая версия BIND уже применяется. В случае совместного использования BIND 8 и Windows 2000 DNS проблемы встраивания Windows 2000 DNS будут минимальны при условии, что Windows 2000 DNS будет дополнительной системой и домены DNS не используются для Active Directory. Администратор должен настроить Windows 2000 DNS для работы только с дополнительными доменами. Надо сделать немного, если только машннЗ Windows 2000 DNS не будет также и главным дополнительным сервером, т.е. остальные дополнительные серверы будут получать свои зоны от нее. Для основной системы все проблемы фактически сводятся к настройке сервера. Файлы конфигурации BIND 8 не могут загружаться на сервере DNS Windows 2000. Это означает, что настройку Windows 2000 DNS надо выполнить вручную или с помощью переделанного файла конфигурации. Подробнее о ручной настройке см. в главе i 1, "Настройка Windows DNS Server".
Надо надеяться, что теперь, когда рабочие группы DNSSEC и DNS1ND объединились, их усилия достичь согласия по пересмотру стандартов с целью поддержки безопасного обновления принесут плоды, от чего вышрают многие промышленные системы. Но до тех пор серверы DNS, использующие собственные средства для защиты работы с кодом операции обновления (Update), будут ограничены в плане взаимодействия. Стандарт безопасного динамического обновления RFC 2137 не поддерживается в реализации DNS Windows 2000, что ограничивает выбор, но все же не так, как если бы было много реализаций DNS, которые поддерживают этот RFC.
Если нужно поддерживать Active Directory, надо изучить материалы предыдущего раздела и сделать выбор. Самый простой выход — делегировать полномочия исходных данных в Windows 2000, чтобы она нспот- зовала их для своих услуг DNS.
Если сервер Microsoft DNS должен быть основным, также потребуются исходиые данные для файла зоны. Файлы зон, если они исходят с существующего сервера, могут быть просто скопированы оттуда. Поскольку они представляют собой лишь форматированный текст, для этого не надо давать никаких особых предупреждений. Единственной проблемой могут быть недавно добавленные записи ресурсов, тип которых не поддерживается в Microsoft DNS, Microsoft утверждает, что такие записи просто пропускаются и что работа над поддержкой записей всех типов в Windows 2000 вскоре будет завершена.
При переходе учтите случай, когда Windows 2000 DNS берет на себя роль основной системы для узла BIND. В доказательство рассмотрим процесс настройки Windows 2000 DNS для участия в Active Directory, в который будут интегрированы записи DNS. Для начала надо установить операционную систему и сервер DNS для Windows 2000 DNS Server (см. главу 11). После этого можно перемешать данные зоны на новый сервер. Простейший и рекомендуемый способ для этого — выполнить следующие действия.
Первоначально настроить сервер DNS Windows 2000 как дополнительный, создав дополнительные зоны в интерфейсе управления DNS.
Убедиться, что новый **подчиненный,' сервер имеет права на выполнение передач зоны из BIND.
Запустить новый сервер или вручную начать передачу, вызвав команду Передача с главного сервера в контекстном меню дополнительной зоны (или зон). В течение нескольких секунд (как правило) файлы зоны переносятся на новый сервер.
Убедиться, что новый сервер настроен на загрузку из файла (на вкладке Дополнительно свойств сервера).
Убрать новый сервер имен из сети, чтобы перенастроить его как основной (в пп. 6-8).
Удалить элементы конфигурации зоны (в загрузочном файле) для только что переданных дополнительных зон; однако это не означает удаления самих файлов зон.
Создать новые элементы конфигурации зоны, используя директиву primary и переданные файлы зон как исходные данные для доменов.
Изменить IP-адрес нового сервера, чтобы он совпадал с адресом существующего сервера, который до этого был основным.
Отключить существующий основной сервер и ввести новый сервер DNS Windows 2000.
Изменить режим хранения на интеграцию в Active Directory, если необходимо.
Работа BIND в Windows
Еше одна возможность построить сервер имен на базе NT — перенести BIND на NT. Обратная сторона этого подхода — то, что он базируется на версии BIND 4.9.7. Сейчас эту версию применять не рекомендуется, и подлерживать ее никто не собирается. Другое обстоятельство, которое может отвернуть пользователей от такого переноса — то, что он предназначен для NT 4.0. Для Windows 2000 эта система в лучшем случае проблематична. Если ваше намерение — запустить BIND, не следует прибегать к такому варианту; лучше применить решение на базе UNIX.
Другие различия в загрузочных файлах и файлах зон
Первое, о чем следует помнить при настройке Microsoft DNS Server, — это интеграция WINS. Поскольку WINS не поддерживается стандартами RFC для DNS и ее применение становится нерекомендуе-
мым, а в дальнейшем она будет служить главным образом для поддержки традиционных операционных систем и приложений, эта проблема сохранится еше несколько лет. При поддержке клиентов NetBIOS с помошью WINS (см. главу 16, "WINS: традиционные службы имен и разрешение,4) и использовании псевдозаписей WINS надо обязательно удалять такие записи при любой передаче зоны на серверы DNS, не являющиеся разработками Microsoft.
Windows 2000 DNS Server обрабатывает в своем загрузочном файле только директивы cache, primary и secondary. Другие данные могут вызвать проблемы или будут проигнорированы.
Последнее заслуживающее внимания различие — директива BIND XFRNETS. По существу, эта директива не поддерживается в Microsoft DNS и генерирует сообщение об ошибке в журнале событий, но не препятствует работе сервера имен. Он просто отмечает недопустимую директиву и идет дальше.
Резюме
В этой главе собраны замечания по возможному взаимодействию BIND и Microsoft DNS. Показано, что выбор возможных решений зависит от цели и особенно от поддерживаемых функций DNS, которые либо необходимы, либо рекомендуются для использования Active Directory. Если поддержки Active Directory не требуется, BIND 8,1.2 n Windows 2000 DNS можно назвать полностью взаимозаменяемыми и взаимодействующими, за исключением некоторых специфических для BIND особенностей конфигурации.
Проектирование служб DNS
В этой главе...
Емкость сервера DNS. В этом разделе рассматриваются некоторые из факторов, определяющих емкость сервера DNS.
Сколько нужно доменов и зон. Этот раздел поможет решить, сколько доменов должно быть в системе, как они должны быть разделены на зоны и где зти зоны разместить.
Сколько нужно серверов DNS. В этом разделе оп!(сывается роль, которую играет сервер DNS при обслуживании нескольких и единственного домена, что поможет определить, сколько серверов DNS потребуется в данной ситуации.
Примеры разработки. Здесь представлено несколько иллюстративных примеров разработки DNS, которые позволят админпелратору составить представление о том. как спроектировать собственную DNS.
Анализ использования Windows 2000 и Active Directory. В зто» разделе представлен обзор дополнительных вопросов, возникающих при использовании доменного окружения Active Directory. Речь идет также об особенностях сервера Windows 2000. которые можно эффективно использовать при разработке системы.
В этой главе представлена информация, которая будет полезна при принятии ключевых решений, например при определении, сколько серверов DNS и сколько доменов потребуется. Если используется доменное окружение Active Directory, многие из этих решений уже не являются проблемами администрирования DNS. Однако остаются необходимыми решения по размещению этих доменов на различных серверах или в различных зонах, на которые делятся домены. В разделе "Прммерн разра- боткн" приводятся пояснения, позволяющие ясно увидеть, каковы эти проблемы и как разные варианты структуры системы могут воздейст во- вать на результаты принимаемых решений. Поскольку версию DNS Windows 2000 можно использовать и без поддержки Active Directory и она является альтернативой любому серверу DNS стандарта RFC, ее можно применять в самых разных вариантах, например в домене NT 4.0, или как изолированный автономный сервер, или как рядовой сервер в составе домена Windows 2000, или же с интеграцией Active Directory на контроллерах домена. Поэтому описание всех возможных вариантов разработки является сложной задачей. Итак, в следующем разделе вначале рассматриваются критерии выбора серверов. Затем приводится несколько часто применяемых вариантов разработки, при годных для небольшого офиса или в виде элементов крупной организации. В основном они предстамены в традиционной форме, пригодной для применения в UNIX, NT 4.0 или любой другой стандартной системе TCP/IP и до того, как буд\т выдвинуты особые требования к планируемой системе. Попутно приводятся некоторые замечания, специфические для серверов DNS или доменного окружения Windows 2000, но большая их часть рассматривается после того, как все элементы разработки будут проанализированы.
Емкость сервера DNS
Емкость сервера при обработке принимаемь(х запросов (как внешних, так и внутренних, изменяется в зависимости от следующих факторов:
количества доменов, для которых сервер является приоритетным:
количества и скорости подсетей, с которыми сервер непосредственно соединен через виртуальные интерфейсы 1Р либо отдельные физические интерфейсы;
количества клиентских запросов, которое сервер фактически будет обслуживать;
степени активности динамического обновления и объема передач зон;
аппаратуры, которая была выбрана для сервера.
Лучший способ определить емкость серверов на данном сайте — использовать системный монитор (или монитор производительности, если вы предпочитаете название NT 4.0). Системный монитор может дать отчет о суммарной производительности базового сервера, а также много показателей, специфических для сервера DNS. Внимание следует обра- 「лава 9. Проектирование служб DNS167
тить прежде всего на производительность сети, производительность диска, выделение памяти и использование процессора. Для сервера DNS можно считывать более 60 показателей (см. табл. 11.3) в реальном времени, некоторые из них — как параметры скорости, например обновлений в секунду или запросов в секунду, а некоторые — как интегральные величины. Системный монитор может служить для протоколирования активности системы за определенный период и последующего анализа записанных показателей, что может занять некоторое пространство на диске. Периодическое выполнение такой операции — хороший способ отслеживать интенсивность работы сервера по сравнению с изначально установленным уровнем.
Хотя сама по себе работа служб» DNS — не очень обременительный процесс, большое количество приходящих запросов, которые порождают нагрузку сервера DNS, может тормозить работу. Если сервер также используется для других служб, надо позаботиться о сохранении малого времени отклика службы DNS. В принципе, единственный сервер DNS может обслуживать порядочное количество доменов и удовлетворять поток запросов. Если сервер DNS слишком долго задерживает ответ, запрашивающий клиент или рекурсивный сервер могут покинуть его. сводя таким образом на нет наличие сервера DNS. Если это допустимо, Windows DNS Server может быть настроен так, чтобы отклонять рекурсивные запросы, что повышает его емкость. В больших системах, где важными факторами являются динамическое обновление и инициируемые уведомлениями передачи, возможным решением будет выделение для этой задачи основного сервера и назначение подчиненных серверов для клиентских запросов. По этим соображениям, если сайт, обслуживаемый контролером домена (DC), имеет много клиентов и этот DC поддерживает DNS, интегрированную в Active Directory, 〃yu【ue всего предоставить для использования клиентами локальные дополнительные серверы. В общем, установленная аплара^ра не должна обнаруживать интенсивного использования диска, за исключением обновлений.
Следующая проблема — управление информацией зоны на отдельном сервере. Для /шепгег-провайдеров (1SP), предоставляющих услуги размещения DNS, серверы должны быть достаточно мощными в смысле производительности процессора. В Windows 2000 предусмотрена полдержка ATM и Gigabit Ethernet, если пропускной способности существующей сети недостаточно. Серверы DNS должны иметь как можно больше памяти, но довольно скромный объем диска. На диске должны помешаться лишь операционная система и файлы зон для доменов. Если файлы зон являются текстовыми, размер отдельных зон. как правило, невелик; аналогичным образом при использовании Active Directory влияние на дисковую подсистему поддержки NTDS. DIT также незначительно. Часто бывает необходимо поместить несколько IP-адресов на плату интерфейса, однако иногда это делается н без необходимости. Если нет реальной потребности такого виртуального присутствия в сети, в результате происходит только увеличение нагрузки на стек TCP/IP.
Объем памяти имеет большое значение, так как при операциях кэширования сервер имен использует системную память. Большая память гарантирует быструю работу сервера и позволяет создавать довольно большой кэш. Для обычной организации, которой требуется обслуживать информацию только своего домена, очень скромные машины могут сделать довольно много. Для большинства систем достаточное количество памяти в системе — возможно, самое серьезное препятствие и ключ к повышению производительности серверов имен.
Вот некоторые рекомендации для построения системы на базе оптимальных требований к серверу DNS. Используйте по крайней мере минимально необходимую аппаратуру для данной версии Windows 2000 Server и добавьте по 8 Мбайт оперативной памяти на каждые 64 Кбайт (65536 байт) записей ресурсов, которые будут опубликованы, включая записи домена и узлов. При этом принимается, что на этом компьютере не будут работать и требовать для себя ресурсов никакие другие службы. Далее, постепенно повышайте скорость и версию процессора, начиная с минимально необходимых для системы, в зависимости от количества клиентских запросов. Если предполагается, что на компьютере будут работать дополнительные службы, увеличьте ресурсы до выполнения требований этих программ. Учтите также скорость сетевого интерфейса и пропускную способность, доступную для запросов и ответов. Скорость жесткого диска не особенно важна, если имеется достаточно памяти, чтобы сервер не делал страничную подкачку данных.
； Максимальное количество записей ресурсов и зон
При использовании сервера DNS NT 4.0 надо помнить об одной его особенности. Сервер DNS с 65553 записями ресурсов в каждой из 1000 зон мо- '； жет обслуживать более 65 миллионов записей! Однако здесь есть ограниче- ' ния: диспетчер DNS зависает, если в зоне больше 65553 записей или больше 1000 зон. Эти ограничения зафиксированы соответственно в статьях Q172477 и Q170518 базы знаний Microsoft. Последнее из них указано как устраненное в NT 4.0 Service Pack 4; первое представляло проблему в диспет- k мере DNS NT 4,0.
Сколько нужно доменов и зон
Количество доменов, которые будут установлены на одном сервере, фактически является вопросом управления. Типичный сервер имен теоретически может обслуживать почти бесконечное количество доменов, но кто захочет управлять таким чудовищем? Единоличная ответственность за тысячи (или сотни тысяч) доменов — не та задача, за которую можно взяться легко*. Вспомним также, что один сервер DNS может обслуживать много доменов и один домен может обслуживаться несколькими серверами DNS.
ла, который единолично поддерживает домен, фактически означает потерю домена до тех пор, пока служба не будет восстановлена. Если домен обслуживают несколько машин, администратор может быть уверен, что на запросы по домену будут выдаваться ответы. Можно воспользоваться каким-нибудь аппаратным средством распределения нагрузки, чтобы увеличить период доступности и надежность.
Наличие нескольких машин означает, что загрузка запросами сможет распределяться между машинами. Если одна из них выходит из строя, это может создать трудности в получении разрешенных имен, например задержку или превышение допустимого времени. Устаревшая информация из кэша, указывающая на неисправный компьютер, также может вызвать некоторые сбои в краткосрочном разрешении. Но работа службы продолжается, пусть даже на более низком уровне. Кроме того, иногда можно временно присваивать IP-адрес неисправного компьютера одной из оставшихся машин, чтобы клиент даже не мог заметить появления проблемы, пока она устраняется. Избыточность ——самый простой способ содействовать поддержанию надежности. Избыточность помогает не только при выходе из строя отдельных машин, но м позволяет, например, избежать последствий плохого управления, которое действует на все машины.
Другая потребность в избыточности связана с размещением служб. Когда все серверы имен физически находятся в одном и том же месте, при разрнве соединения с lntemet-провайдером весь домен становится недоступным. По умолчанию чем больше число серверов, поддерживающих службу имен, и чем лучше они разнесены территориально, тем лучше доступность и надежность службы имен. Каждую систему, действительно распределенную в нескольких различных сетях, можно расценивать как два сервера, что достаточно для регистрации, но не для всех аспектов избыточности. Если один из сетевых каналов выходит из строя, другой остается доступным; но если выходит из строя машина, теряются оба.
Общие соображения, которые следует принимать в расчет при определении архитектуры серверов имен, включают количество местоположений, требующих поддержки, тип сетевых соединений, которые будут установлены между ними, число клиентов в каждом местоположении, характер текущих операций между ними, а также природу и тип связи организации с Internet.
Эмпирические правила выбора количества серверов DNS
Для каждой организации нужны два сервера DNS. Однако если услуги службы имен предоставляет Internet-провайдер, ни один из этих серверов вам не придется настраивать или управлять им. Малые организации часто предоставляют все управление Internet-провайдеру, но некоторые выбирают для управления один сервер DNS, основной или дополнительный, оставляя другой internet-провайдеру. По приведенным выше сооб-
ражениям, это хорошая и безопасная практика. Небольшие организации, применяющие Active Directory для внутреннего пользования, наиболее часто организуют внутреннее, закрытое пространство имен и одним из описанных способов реализуют общее пространство имен со своим Internet-провайдером. При выборе провайдера используйте факторы доступности. надежности и избыточности для анализа качества предлагаемых услуг.
Организациям среднего размера требуется только два сервера DNS, однако они могут добавить по одному серверу на каждый территориальный сайт, чтобы облегчить прохождение дальних запросов. (Эти серверы могут служить только для кэширования). Или же они могут превратить географически разнесенные серверы DNS в дополнительные, чтобы повысить независимость сайтов для локальных запросов. При динамическом обновлении локальные серверы сайтов могли бы пересылать обновления на основной сервер, если они дополнительные. В одних случаях это нежелательно, но в других приемлемо к в зависимости от распределения Windows 2000 и других факторов.
Большие организации могут иметь очень сложную структуру DNS, включающую несколько доменов и субдоменов. В следующем разделе, ■'Примеры разработки", показаны некоторые из множества вариантов, компонуя которые, можно сделать большие системы настолько сложными, насколько требуется. Необходимость компромисса между емкостью, быстротой реакции и надежностью делает простые эмпирические правила непригодными для разработки служб DNS в большой организации.
Примеры разработки
В следующих разделах представлены отдельные примеры, которые позволят вам определить, какая струю ура лучше всего подойдет для вашей системы.
Настройка домена с одним или несколькими субдоменами
Технические организации часто нуждаются в очень динамичных системах для своих экспериментов, поэтому целесообразно выделить их из главного домена корпорации. Цель — дать техническому подразделению контроль над своим субдоменом и возможность производить изменения независимо от остальной компании. На рис. 9.1 показана структура DNS, которую можно использовать для домена xyz . com.
Корпоративный домен с основным и дополнительными серверами DNS имеет делегированный субдомен. Главный домен корпорации xyz. com делегирует полномочия основного сервера для субдомена Engineering серверам DNS в eng.xyz.com. По этому сценарию измене-
ния, вносимые в eng. xyz. com, не будут действовать на корпоративный домен xyz. com, и Engineering может производить на своих узлах любые изменения, не беспокоя системного администратора корпорации. Единственный случай, когда Engineering должен обратиться к службам корпо- раш<и — если【Р-аарес(а) его сервера (или серверов) имен изменится.
Рис. 9.1. Корпоративный домен с основным и дополнительными серверами DNS, делегированными в субдомен
Использование Internet-провайдера для основного сервера DNS
В очень малых организациях и даже в домах часто рекомендуется поручить службу основного сервера DNS Internet-провайдеру, как показано на рис, 9.2.
Можно установить собственный кэширующий сервер для повышения производительности или дополнительный сервер для избыточности. Если у вас нет дополнительного сервера, Internet-провайдер может предоста-
вить его. По этому сценарию ваше открытое пространство имен DNS управляется Internet-провайдером и вашей организации не нужно беспокоиться об этом, за исключением изменения самого провайдера. Для внутренних целей может быть достаточно простой конфигурации служб DNS, если используется Active Directory. В этом случае каждое изменение открытых имен требует контакта с провайдером, который должен соответственно изменить файл зоны. Недостаток этого метода в том, что изменения иногда требуют большого времени. Иногда задержка может достигать 72 часов и более, в случае выходных и т.д. Ваши внутренние службы имен могут легко быть настроены на пересылку запросов для разрешения серверам DNS у провайдера. Для небольших организаций установка Active Directory предоставляет уже подготовленные шаблонные службы DNS с локальными именами и адресами, приемлемыми для этой схемы после того, как в пересылающем сервере DNS будет настроено направление на провайдера.
Рис. 92 Internet-провайдер предоставляет услуги основного сервера DNS для данного домена
Если подключение к провайдеру постоянное, для разрешения общих имен прекрасно подходит пересылочный узел или даже сервер, выделенный только для кэширования. Если подключение производится по телефонному номеру или по предоставляемой по требованию линии любого рода, может оказаться лучше установить дополнительный сервер DNS, поскольку тогда можно будет производить локальный поиск, не подключаясь к провайдеру для каждого запроса. Дополнительный сервер также позволяет легко проверять изменения, просматривая локальную копию файла зоны, которая периодически обновляется при передачах с основного сервера Internet-провайдера.
Использование Internet-провайдера для дополнительных серверов DNS
На рис, 9.3 организация сама содержит свой основной сервер DNS, но дополнительный сервер находится у Internet-провайдера или какой-то другой внешней организации. Вспомните, что два сервера, один основной и один дополнительный или два дополнительных, должны быть зарегистрированы в InterNIC.
сервера DNS для данного домена
Эта схема может повысить производительность всей системы за счет распределения обработки запросов DNS на несколько машин в разных местах. Кроме того, она обеспечивает избыточность. Например, если xyz.com потеряет связь, попытка соединения с ним будет безуспешной, но его узлы останутся разрешимыми для внешних систем. Важно, чтобы DNS всегда имелась в вашем домене, и по этой причине не следует помешать все основные и дополнительные серверы DNS домена на невыделенной линии (например, на телефонной).
Если задачи основного сервера выполняются в пределах организации, существует риск, что открытые дополнительные серверы прекратят разрешать имена для вашего домена. Это может произойти в нештатной ситуации, когда дополнительные серверы не смогут принимать передачи зоны и вследствие этого срок действия зоны может истечь. По этой причине необходима хорошая связь и, возможно, настройка срока действия зоны.
Защита основного сервера DNS от несанкционированного доступа
Можно повысить безопасность системы, зарегистрировав в InterNIC не основной и дополнительный серверы, а два дополнительных, как показано на рис. 94
Рис. 9.4. Дополнительные серверы обслуживают внешние запросы к домену, оставляя основной сервер имен скрытым
При этой схеме машина, на которой находятся данные зоны, остается скрытой от хакеров. Когда основной сервер предоставляет данные зоны для домена, он передает авторитетные данные дополнительным серверам. Хотя все серверы могут отвечать авторитетно, только дополнительные серверы будут отвечать на запросы, приходящие извне.
Учтите также, что наделение правом производить передачи зоны только тем дополнительным серверам, которые указаны в списке уведомления, может предотвратить получение содержимого зоны недобросовестными людьми. При этой настройке хакеры не смогут получить доступ к машине, где хранятся исходные данные зоны. Для блокировки доступа к основному серверу извне организации также можно использовать маршрутизаторы.
Как большой сайт может создать большой кэш запросов
Чтобы уменьшить число запросов имен, которые должны разрешаться за пределами организации, например на серверах DNS у провайдера, можно создать кэш, охватывающий весь сайт, как показано на рис. 9.5.
Рис. 9,5. Сервер DNS только для кэширования в пределах всего сайта может выдавать ответы быстрее, чем при направлении отдельных запросов к внешним серверам
Сервер только для кэширования в пределах всего сайта устанавливается путем пересылки всех запросов от серверов имен на один или несколько кэширующих серверов. Учтите, что это серверы DNS, которые обращаются к серверу, выделенному только для кэширования, а не к клиентам непосредственно. Таким образом, все запросы и ответы кэшируются на одной или нескольких машинах, которые будхт запрашиваться всеми остальными серверами имен в компании. Это устраняет необходимость для сервера западного филиала (см. рис. 9.5) в обращении за пределы организации для всех запросов, которые уже были кэшированы любыми клиентами в компании.
Установка организационной DNS, скоординированной с внешней DNS
DNS с "разделенным мозгом", как она иногда называется, использует несколько основных серверов для повышения безопасности домена (рис. 9.6). Обычно одно из этих пространств имен находится перед брандмауэром, а другое — за ним, причем в открытом пространстве имен основной сервер часто помешается за пределами ''демилитаризованной зоны" (DMZ). Практическое значение такой структуры для больших организаций огромно. DNS с ''разделенным мозгом" позволяют предоставлять услуги DNS внутренним клиентам для внутренних адресов, не давая возможности увидеть все адреса внешним клиентам DNS. Администраторы могут точно определить, какие внутренние узлы должны быть показаны на внешних серверах DNS и какие должны быть видны только на внутренних серверах DNS.
Рис. 9.6. DNS с 11 разделенным мозгом" обеспечивает заданную степень безопасности данных зоны
Внешний основной сервер содержит в своем файле зоны только те записи, которые вы решили сделать доступными для внешнего мира; внутренний основной сервер содержит записи для всех узлов в домене. Внутренние серверы имен настроены так, чтобы пересылать на внешний основной сервер имен все запросы, на которые они не могут ответить непосредственно; там эти запросы могут кэшироваться. Внутренние серверы также являются подчиненными для внешних, т.е. они не могут сами предпринимать разрешение. Это позволяет внутренним серверам
быть скрытыми от внешнего мира, что оставляет меньше шансов хакерам. Чаще всего связь между внутренней и внешней сетями происходит через брандмауэр, который может быть фильтрующим маршрутизатором, а не просто маршрутизатором, как показано здесь.
Безопасность является серьезной проблемой для крупных корпораций, а серверы DNS содержат важные данные: информацию о каждой машине в вашем домене! По этой причине рекомендуется реализовать схему, которая ограничивает доступ к основным серверам DNS, поскольку они предназначены для передачи авторитетных данных дополнительным серверам. Хакеры знают об этом и о том, как использовать эту особенность для своих целей. Этот вариант можно реализовать также с помощью Internet-провайдера, предоставляющего 11 внешние11 службы. Такая схема в отношении брандмауэров рассматривается ниже, в главе 10, ''Проблемы безопасности''.
Анализ использования Windows 2000 и Active Directory
Windows 2000 приносит с собой множество новых задач разработки и вариантов их решения. Иногда это функции, включенные в операционную систему, а не характеристики DNS как таковой, что можно эффективно использовать для удовлетворения требований разработки DNS.
Построение закрытых сетей
Возможности тонкой настройки характеристик сетей в Windows 2000 Server огромны. Эти функции объединены в службе Маршрутизация и удаленный доступ, которая в состоянии обеспечить всеобъемлющий контроль исходных параметров соединения в многосетевых компьютерах. Также можно использовать свойства TCP/IP для фильтрования пакетов в зависимости от протокола или порта TCP и UDP, что ограничивает доступность служб, связанных с интерфейсами машины, как показано на рис. 9.7 (в ненастроенном состоянии, которое разрешает любую связь по TCP/IP).
Если посмотреть на вкладку Параметры диалогового окна Дополнительные параметры TCP/IP, можно убедиться, что в Windows 2000 реализована поддержка безопасности IPsec. Ее использование требует определения политики безопасности по каждому домену и довольно значительной работы по подготовке инфраструктуры открытых ключей. Однако там, где применяются соединения типа экстрасеть или приложения высокой безопасности, вы, весьма вероятно, захотите воспользоваться этим альтернативным вариантом. IPsec может использоваться с программным кодированием или, лучше, с интерфейсными платами, которые уменьшают загрузку процессора, что может быть даже более важно для DNS и других серверов, чем для клиентов.
[еипьтбациа TCF[еипьтбациа TCFРис. 9.7. Параметры безопасности в диалоговом окне Свойства TCP/IP \Mndows 2000Рис. 9.7. Параметры безопасности в диалоговом окне Свойства TCP/IP \Mndows 2000
[еипьтбациа TCF
[еипьтбациа TCF
Рис. 9.7. Параметры безопасности в диалоговом окне Свойства TCP/IP \Mndows 2000
Рис. 9.7. Параметры безопасности в диалоговом окне Свойства TCP/IP \Mndows 2000
Защита и совместное использование пространства имен
При использовании Active Directory природа информации, доступной в DNS путем запросов записей служб (SRV) и других типов становится Предметом заботы для системных администраторов. По этой, а также по другим хорошо известным причинам рекомендуется размещение Active Directory за брандмауэром или в каком-то другом месте вне общего пространства имен Internet. Для этой цели обычно применяется тот или иной вариант структуры с "разделенным мозгом", связывающий два пространства имен через перссылочнЕге сервсрьг, и изменение данных кор- невых ссылок.
Открыгое доменное имя и внутреннее доменное имя необязательно должны совпадать. Внутреннее имя может быть зависимым, как дочернее имя официально зарегистрированного имени, или отдельным, частным именем, возможно, даже незарегистр1фованнь!М, В последнем случае принимается, что выбранное имя никогда не станет открытым. Если это неприемлемо, установите такой контроль над внутренним именем, как если бы это было открытое имя.
В некоторых случаях, например при разрастании сети со временем, в открытой сети желательно использовать технологии Active Directory. На- пример, компании, предоставляющей своим клиентам услуги через приложение, использующее каталоги, может понадобиться открытая структура домена Windows 2000. В этом случае компания, вероятно, выделит эту структуру только для общего пользования и оставит Active Directory изолированным, как было описано вьгше. Со временем службь( метакатзло- гов. которые предоставляют унифицированный доступ ко многим службам каталогов и в некоторых случаях дают администратором унифицированные способы управления ими, сделают подобное ситуации более удобными н управляемыми,
Разнообразие способов поддержки виртуальных частных сетей (virtual private networking, VPN) в Windows 2000 можно эффективно использовать для предоставления возможностей экстрасети и, в сочетании со службами удаленного доступа, при поддержке малых периферийных офисов через Internet. Хотя характер взаимодействия в экстрасети вашей организации с другими компаниями находится вне сферы DNS, это может потребовать поддержки большего количества зон. Возможно, ваша компания имеет изолированный главный Active Directory для чисто внутреннего использования и еще один для работы с другими организациями. Этот последний, вероятно, будет находиться в DMZ и, конечно, он будет иметь отдельное пространство доменных имен, но в остальном рекомендации по поддержке DNS остаются теми же.
Размещение службы DNS
Если Active Directory используется в рассредоточенной системе или даже в большом университетском городке, значительная часть разработки уже реализована за счет размещения контроллеров домена. Данный факт можно использовать для DNS. Это справедливо в случае стандартных зон, но также и для зон, интегрированных в Active Directory. Если зоны стандартные, размещение контроллеров определяет, где потребуется локальное размещение DNS. Проблемы связи, рассматриваемые в отношении контроллеров домена, пропускной способности, непрерывности работы и так далее, имеют значение для передач DNS. Вопросы количества клиентов, необходимости независимой работы при сбоях в сети и тому подобное определяют, что в данном месте должны присутствовать как контроллер домена, так и служба DNS.
Если зоны интегрированы, их данные автоматически распространяются на все контроллеры с учетом домена. Это происходит независимо от того, используются данные или нет. Поэтому применение этих данных за счет установки другого сервера DNS больше влияет на загрузку сервера DNS, чем на что-либо другое, В этом случае должны быть Предусмотрены локальные основные ссрверы-
Поскольку на сайте с безопасной внутренней сетью можно выбрать динамическое обновление за счет соответствующей функции Microsoft, для регистрации обновлений могут быть установлены основные зоны на контроллерах домена. Если используется динамическое обновление без Active Directory, регистрации и обновления направляются на единственный основной сервер зоны. Тогда размещение основной зоны становится основной задачей разработки.
Использование дополнительных серверов
Применение интеграции в Active Directory несколько увеличивает нагрузку на контроллеры домена и их механизмы репликации. Обновления базы данных DNS загружают механизм репликации. Эту загрузку
можно уменьшить, установив интервал блокировки очистки (подробнее см, в главе 7, "Динамическая DNS и Active Directory"). Там, где размер сайта позволяет, желательно предусмотреть локальные дополнительные серверы для использования клиентами, поручив службе DNS на контроллерах домена только обработку изменений.
Хотя для большинства задач этим дополнительным серверам DNS нужны только зоны для локального сайта, а не для какого-либо вышележащего домена, следует учитывать и другие факторы. Если эти дополнительные серверы используют свои корневые ссылки для разрешения внешних узлов, большое количество адресов, пропускаемых через брандмауэр. в меньшей степени поддается контролю. Если, с другой стороны, эти дополнительные серверы настроены для использования пересылочных узлов, например специально назначенных серверов DNS в DMZ или у Intегпеt-провайдера, у этих дополнительных серверов должны быть все внутренние зоны. Сервер DNS будет пересылать запрос, если он не сможет дать авторитетный ответ. Если представлены не все внутренние зоны. дополнительный сервер может дать направление или обработать запрос рекурсивно, но он не будет иметь авторитетного ответа в своих данных. Перед рекурсивной обработкой запроса он перешлет его, что было бы нежелательно для внутренних имен. Очень большие сайты могут позволить себе пропускать клиентов в Internet через подчиненные дополнительные серверы. Но все серверы организации должны помнить, что такое использование пересылки является не просто удобным для безопасности пропускным пунктом, но и потенциальным узким местом и источником сбоев.
Резюме
В этой главе показано, даже без учета влияния Active Directory, что существует столько же вариантов разработки служб DNS, сколько и предъявляемых к ним требований. Тщательный учет требований и факторов нагрузки, характеристик каналов, потребностей в связи и требований безопасности является первым этапом в более объемной разработке. Затем, применение элементов разработки, различными способами обеспечивающих эти требования, может быстро сузить диапазон приемлемых вариантов. Основательный анализ их рабочих характеристик, принятых маршрутов, распределения нагрузки и так далее еше больше совершенствует разработку.
В этой главе приводится практическая информация, которую можно использовать для разработки собственной системы DNS. Глава 11, ''Настройка Windows DNS Server", охватывает следующий этап — настройку сервера DNS и его запуск.
Проблемы безопасности
В этой главе...
Обманные запросы имен. В результате обманного запроса (спуфинга) ваш сервер DNS может принять за настоящий дополнительный сервер ложный узел, который выдает себя за него. Недобросовестные хакеры используют этот метол для получения копий файла зоны; а если внутренние адреса ваших компьютеров известны, вы уязвимы для прямого нападения.
Отказ от обслуживания. Затопление машины потоком запросов, чтобы она не могла работать по своему назначению, может быть первым этапом в некоторых формах нападения. Защита в такой ситуации — поддержание высокой степени доступности служб. Несколько специфических для DNS настроек могут помочь в достижении этой цели.
Использование DNS с брандмауэрами. Брандмауэры — это специально выделенные устройства или компьютеры, на которых работают особые программы, призванные ограничить прохождение через них с целью защиты одной или нескольких сетей от не*е.ча~ тельного доступа. Реализации брандмауэров варьируются от специальных программ, схем маршрутизации и групповых настроек машин до отдельной машины, использующей одну или не-
сколько сетевых карт. Там, где нужны подключение к Internet и внутренняя сеть или демилитаризованная зона (DNZ). DNS требует специальной конфигурации, зависящей от требований разрешения и присутствия в открытой сети,
Объявление служб. Если хакер больше знает о цели своего нападения, это помогает ему в поиске слабых мест. Вопросы, связанные с зашитой компьютера и объявлением служб в пространствах имен, публикуемых современными системами, обычно решаются за счет ограничения доступа к такой публнкацнн. Известными проблемами являются пространства имен DNS и NetBIOS, однако появились и новые факторы — записи служб (SRV) и службы LDAP.
Динамическая DNS (DDNS). Новая функция много обещает, по и приносит много опасностей. В этом разделе кратко обобщены проблемы, специфические для Windows 2000 при использовании динамического обновления.
Безопасность почты: SMTP, POP, IMAP и Exchange. Почтовые серверы подвержены самым разнообразным атакам. В этом разделе описано несколько "дыр" в безопасности и даны советы по использованию записей почтовых обменников (MX) в DNS для уменьшения незаишшенности.
Безопасность WWW. С ростом мощности и популярности Web- серверов и броузеров в них появляется все болыле возможностей для создания "дыр'' и нарушения через них безопасности. В этом разделе описываются некоторые проблемы безопасности Web и возможные методики зашиты.
Безопасность F1P. Серверы FTP полезны, когда надо выложить для загрузки программное обеспечение и электронные докуменгн； также они используются для дополнения Web-серверов функциями загрузки и публикгшии. Они создают некоторые проблемы безопасности. огшеаннме в этом разделе.
Настоящая глава не охватывает всех вопросов безопасности, которые надо учитывать при настройке сети, подключенной к Internet. Ее назначение — помочь в понимании некоторых вопросов, наиболее тесно связанных со службами DNS. Как было уже отмечено, безопасность начинается (или должна начинаться) с проектирования. Если безопасность не планируется с самого начала, она часто реализуется методом "заплат", накладываемых на уязвимые места, или требует новой перепланировки системы. Истина заключается в том, что безопасность в сети — это не отдельный вопрос, а суммарны■負 вклад, вносимый всеми аспектами разработки. Эта глава рассматривает DNS в плане необходимости связи с обшей сетью и возникающего при этом риска. В основном следует обратить внимание на риск ви\три системы. Например, не имеет смысла фильтровать все порты, кроме избранных, если кто-то внутри системы может установить сервер FTP или Telnet именно на эти порты- Большие Глава 10. Проблемы безопасности185
системы могут выиграть от внутреннего логического разбиения по уровням безопасности, н в таком случае некоторые из решений проблем, возникающих при работе с внешней сетью, могут быть применены внутри окружения.
Как обычно, при решении вопросов безопасности вы должны хорошо разбираться во всей новой информации по этому вопросу, в появляющихся программных заплатах и исправлениях ошибок. Кроме производителей, предупреждения и объявления, связанные с безопасностью, выпускают многие организации, необязательно спеииализируюшиеся на DNS. Две из ннх、CERT и SANS (www.cert.org и www.sans.org), можно считать отличными, независимыми от производителей источниками регулярной информации.
Обманные запросы имен
Обманный запрос DNS, или снуфине、— это процесс, посредством которого хакеры проникают в систему и изменяют соответствие между узлами и IP-адресами, чтобы они указывали на ложный сервер. Это возможно, хотя 11 довольно трудно реализуется. Самая большая проблема при атаке на сервер DNS — это целостность информации зоны и возможная переадресация запросов на альтернативные узлы. Хорошая сторона во всем этом — то, что атаки такого рода легко обнаруживаются и отражаются.
Утилиты nslookup. pir.g и rracert (tracercute) могут идентифицировать машины, адреса которых бьпи изменены (особенно на IP-адрес, не принадлежащий сайту iliji домену). В случае проблем запросите другие авторитетные серверы и проверьте результаты, Если атака произошла некоторое время назад, информация могла быть кэширована через Сеть, но устарела, что позволяет вернуться к нормальной работе. Если вы не уверены, показывает ли ваш сервер неверную информацию, проверьте его ответы с помощью итеративных запросов через nslookup. Чтобы определить, исходят ли поврежденные данные из кэша или онм стали данными зоны, можно проверить это и а консоли управления DNS в режиме Расширенный или использовать DNSCMD.EXE. Если дело в кэше, можно очиегшь кэш сервера любым средствам, например, остановив и перезапустив зону или сервер н заставив их вновь считать информацию зоны. Однако все эго возможно лишь после того, как вы определите место повреждения.
Конечно, это ситуации, которые не должны случаться. Если они происходят, их следует устранять немедленно. Регулярный контроль, особенно больших зон, нетривиален. Однако если возможно раннее обнаружение, след атаки остается свежим л шансы на отражение будущих атак возрастают. В некоторых случаях контроль можно сделать более успешным, если отслеживать необычные параметры производительности сервера и сети, а не повреждение данных зоны ил» неправильные ответы. Не забудьте, что DNSCMD. EXE позволяет планировать передачи данных зоны и периодически сравнивать их с эталонным набором данных.
Трудность заключается в первую очередь в определении, как и где хакер получил возможность сделать изменения в системе. Программы обнаружения проникновения и аудита могут помочь в выслеживании заподозренного хакера. Существует большое количество других книг и ресурсов, в которых конкретно рассматриваются эти вопросы,
Выгода в манипулировании зонами для хакера заключается в том. что он может прибегнуть к переадресациям, чтобы направить пользователя к машинам, которые он контролирует. Затем хакер может использовать это для получения от ничего не подозревающих пользователей информации об их регистрационных данных или почтовых учетных записях я даже получить доступ к другим узлам в удаленной сети. Если хакер может выдать ложную машину за авторитетный для домена сервер, он портит кэш для других серверов имен в Internet, перехватывая запросы и отвечая на них. Вспомните, что в Windows 2000 DNS Server можно установить зашиту кэша, что является одной из мер, предотвращающих подобные действия.
Один из способов уменьшения опасности такого рода атак — это использование обратного просмотра для подтверждения. Если узел вьщает себя за другой сервер, обратный просмотр помогает проверить, действительно ли IP-адрес отображается на имя этого узла. Некоторые серверы FTP и HTTP фактически выполняют указанную процедуру, прежде чем разрешить загрузку или подключение. Чтобы облегчить эту операцию в вашем окружении, служба DNS должна иметь настроенную зону (или зоны) обратного просмотра.
Лучшая политика в настройке сервера имен — стремление сделать его как можно более безопасным. Не используйте машину, на которой регистрируется много пользователей или которая поддерживает другие интерактивные услуги. Многие эксперты по безопасности советуют запускать на каждой машине только одну службу, если позволяет уровень трафика. Некоторые заходят так далеко, что рекомендуют либо запретить, либо жестко контролировать весь удаленный доступ, используя только шифрованный доступ через шифрованную закрытую сеть или другой подобный механизм контролируемого доступа.
Другой предмет беспокойства — хакер, производящий передачу зоны с вашего сервера имен, чтобы получить адреса в ней. Лучший способ уменьшить риск передачи данных на любой нежелательный дополнительный сервер ——перечислить все допустимые серверы DNS во вклалке Передачи зон диалогового окна свойств зоны на консоли управления DNS. Установите флажок Разрешить передачи зон, как показано на рис. 10.1, а затем выберите переключатель только на серверы из этого списка и добавьте в список IP-адреса серверов. Затем во вкладке Уведомление можно установить уведомление для серверов, которые его поддерживают (см. рис. 11.8). Это хороший способ даже в тех окружениях, информация которых не считается секретной. Он повышает производительность и обеспечивает безопасность даже во внутренней сети, где тоже может встретиться неаккуратный или недобросовестный работник. Это действительно очень плохо, что проблема безопасности так часто показывает людей не с самой хорошей стороны или, скорее, показывает, что такую возможность нельзя не учитывать.
hq example net - c»oMci»;i
Qh [ Отмене ] Прмценн-ь [ !
Рис. 10.1. Разрешение передавать зону только опре- деленным машинам
Отказ от обслуживания
Атаки, вызывающие отказ от обслуживания, иногда используются при попытках спуфинга, а иногда даже без злого умысла. Этот метод основан на известных недостатках реализации стека TCP/IP на сервере или даже просто ограниченной емкости машины. Путем отправки неправильно составленных, специально устроенных или просто очень большого количества пакетов сервер делается невосприимчивым или вообще выводится из строя. Это дает возможность спуфинга путем подстановки, если маршрутизаторы или машина в соответствующей подсети оказались раскрыты.
Наиболее очевидная мера защиты — техническое обслуживание и использование лишь минимально необходимых служб. Для серверов DNS имеется несколько специфических мер. которые можно использовать в определенных случаях. Если нет причин не делать этого, заставьте службу DNS отклонять рекурсивные запросы (см. главу 11, ''Настройка Windows DNS Server"), как это обычно можно сделать с серверами DNS, используемыми для открытого пространства имен. Это не только увеличивает емкость машины, но и ограничивает количество путей доступа к серверу DNS. Атаки, вызывающие отказ от обслуживания, которые базируются на знании операционной системы и уровня установленных служб, обнаружить не так легко, если они задействуют только один или несколько специально построенных пакетов. Если признаки таких атак известны и поддаются контролю, "дмрм" можно заткнуть. С другой стороны, атака путем затопления имеет характернее признаки.
Также здесь следует упомянуть о том, что основной сервер не обязан находиться в открытом пространстве имен, чтобы обеспечивать присутствие в сети, и поэтому лучше его поместить в закрытой части сети или в DMZ. Легко настраиваемый метод контроля — периодическая проверка "здоровья'' служб DNS. Проверка доступности машины командой ping, конечно, не является достаточным основанием для уверенности в целостности служб DNS. Похожая функция присутствует во вкладке Наблюдение свойств сервера DNS. за тем исключением, что она должна достичь конкретных удаленных серверов через открытые интерфейсы и затем в случае необходимости выдать сообщения.
Использование DNS с брандмауэрами
Если DNS применяется с брандмауэрами или через них. надо учитывать два фактора: политику безопасности сайта млн организации и тип брандмауэра, который предполагается использовать. Следует проанализировать политику безопасности, чтобы определить, какой трафик будет допустим для прохождения через брандмауэр. Тип брандмауэра, в свою очередь, определяет, какие данные проводят между закрытой сетью, DMZ и Internet.
Брандмауэры могут иметь разные возможности, включая фильтрацию и "проксировпиис'1 пакетов с выдачей предупреждений относительно инспекции состояния. Инспекция состоянии (slateful inspection) — это механизм, который анализирует информацию во входящих и выходящих из брандмауэра пакетах с целью определения состояния сеанса. На основании состояния агент инспекции определяет, можно лн пропустить пакеты через брандмауэр.
Сочетание идентификации, шифрования и высоких уровне；彳 аудита обеспечивает некоторые мощные инструменты зашиты. Многие брандмауэры непосредственно поддерживают DNS или имеют шаблоны, позволяющие легко настроить прохождение или проксирование запросов службы имен с одной стороны на другую. Администратор, который отвечает за разработку политики безопасности, может руководствоваться по крайней мере двумя разными подходами.
Сделать доступным все и гарантировать хорошее резервирование.
Ограничить доступ к каждой машине и разрешить в сети только абсолютно необходимый трафик.
По первому сценарию сайт может даже не использовать базовые фильтры на маршрутизаторе, который выполняет роль его ворот в Internet. Во второй ситуации разрешаются лишь некоторые порты и протоколы и лишь для немногих специально указанных машин, а эти машины, в свою очередь, зашишаются друг от друга в той же сети.
Зашита компьютеров друг от друга влечет за собой, как минимум, настройку отдельных учетных записей администраторов с разными пароля-
ми для каждого. Цель этих мероприятий — сделать машины как можно более независимыми, чтобы хакер, получивший доступ к одной из них, не мог использовать ее учетные записи для доступа к остальным системам в DMZ. Это похоже на раздельное размещение самолетов и топлива на военном аэродроме, чтобы минимизировать повреждения при поражении одной из целей. Использование разных учетных записей делает невозможным воздействие на несколько машин сразу, как на костяшки дом14но. Доверительные отношения между этими машинами также должны быть ограничены как можно более строго, если не устранены вообше. Это означает, что линия безопасности может проходить за пределами леса Active Directory, что, в свою очередь, ограничивает его дружественность к допустимым пользователям. Помните, что доверяемая машина при необходимости может проверять структуру групп и учетных записей доверяющего домена.
Способов поддержки DNS столько же, сколько способов настройки брандмауэров. Самое главное, о чем следует помнить, — то, что авторитетный сервер имен должен быть достижим для внешнего мира с целью разрешения любого открытого узла на локальном сайте, а внешние серверы имен должны быть достижимы (через некоторые механизмы, такие как пересылочные узлы и прокси) для внутренних узлов с целью проведения поиска в других доменах.
Лучший способ зашиты сервера имен — обеспечить регулярное резервирование зоны и данных конфигурации. Надо также гарантировать, что эта информация будет доступна при необходимости восстановления файлов. Концепция полного закрытия домена от внешнего мира, безусловно, хороша в смысле безопасности, но она дает пользователям внутри сети мало возможностей проникнуть во внешний мир.
Один мз методов резервирования информации зоны — создание специального резервного сервера DNS, который записан как допустимый дополнительный на основном сервере для каждой зоны этого основного сервера, и сохранение копии иомена на этом дополнительном сервере. Этот метод обычно применяется на высокозагруженном основном сервере с целью сокращения времени, необходимого для его восстановления. В некоторых системах UNIX эта методика также позволяет заполнить зону с дополнительного сервера, не переметан файлы вручную и т』.
Можно так настроить домен, чтобы основной сервер имен находился внутри брандмауэра (где он в безопасности), а дополнительный — вне его. чтобы выполнять поиск для внешних узлов. Это хорошее решение, если только администратор не возражает против того, чтобы внешнему миру был виден весь его домен. Но мало кто из администраторов согласится показать весь свой домен в Internet. Поэтому существует концепция DNS с ''разделенным мозгом", с двумя версиями домена — одной обшедоступной и одной для внутреннего пользования в организации. Можно сделать еше один шаг и фактически запустить два набора серверов DNS с дополнительными серверами для общего использования в открытой сети. Не забудьте тщательно изучить настройку этих дополни-
тельных серверов, чтобы устранить любой возможный риск, например возможность передачи главной зоны.
Сегодня в большинстве организаций пользователям узлов необходим выход в Internet, как минимум, для Web и электронной почты. В таких ситуациях тотальное закрытие домена не является осуществимой идеей. Если необходима безопасность и администратор хочет ограничить видимость домена извне, возможно, наилучшее решение — DNS с ''разделенным мозгом" или другой метод ограничения количества опубликованных узлов. Описание и схему такой DNS вы найдете в главе 9, *ьПроектирование служб DNS".
В традиционной DNS с "разделенным мозгом” применяется два основных сервера: один за брандмауэром и один перед ним. Наружный основной сервер имен, который находится перед брандмауэром, содержит в своих файлах зоны минимум записей, как правило, записи MX для домена, узлы WWW и FTP. В зависимости от типа брандмауэра могут использоваться некоторые записи для обратного просмотра внешними компьютерами в сеансах, установленных внутренней сетью.
Некоторые брандмауэры применяют трансляцию адресов для переназначения предварительно запанного списка IP-адресов. Чтобы эти IP- адреса были полезны для конкретных операций, может потребоваться обратный просмотр для определения правильного имени узла. Эти имена узлов могут обрабатываться наружным основным сервером имен, поскольку внутренний сервер не даст разрешения для них. На внутреннем основном сервере DNS могут содержаться записи для каждого узла в домене (включая наружные узлы). Внутренний сервер DNS также может быть настроен так, чтобы пересылать запросы наружному серверу DNS или быть его подчиненным для внешних имен. Внешние пересылочные серверы могут быть теми, которые представляют ваш домен в сети, или отдельными серверами, специально выделенными как пересылочные, в зависимости от ваших возможностей, финансов и принципов политики безопасности.
В результате получится внутренняя служба имен, которая при невозможности найти у себя ответ на присланный распознавателем клиента запрос будет пересылать этот запрос наружному серверу имен. Поскольку внутренний сервер имен настроен как подчиненный для наружного сервера, он не будет пытаться разрешить запрос сам, а должен будет ждать, пока наружный сервер не даст ответ. Брандмауэр, позволяющий прохоДить запросам сервера имен только между этими двумя узлами, не будет пропускать запросы от внешних узлов к внутреннему серверу имен. Должна ли внутренняя пересылающая машина быть исключительно подчиненным сервером для кэширования, или она может содержать внутренние данные зоны — еше один предмет для анализа. Если она не имеет внутренне订 информации, не имеет клиентов, а работает только с другими вашими серверами DNS, следует использовать ее непосредственно. Если она содержит данные внутренней зоны, она должна применять все внутренние данные зоны только для имен Internet. Пересылающая ма-
шина будет передавать все запросы, для которых у нее не будет авторитетного ответа, даже в том случае, если она сможет обеспечить прямое направление на другой внутренний сервер DNS. По этой причине она должна иметь полные данные зоны, что, в свою очередь, ведет к необходимости помешеиия ее в более зашишенное место. Таким образом, ваш выбор определяют финансовые возможности, величина сети и ее загрузка, а также степень безопасности. Помните, что пересылочные серверы —это удобные точки контроля, но также и узкие места.
Поскольку внутренний и наружный серверы имен используют разные данные зоны, передача зоны через брандмауэр не нужна. Трудность такой схемы в том, что администратор должен обслуживать два разных набора файлов зоны, ие говоря уже о дополнительном обслуживании, которое понадобится, если в системе есть еше дополнительные серверы по каждую сторону брандмауэра. Это также порождает возможность человеческой ошибки и конфликта имен, поскольку внутренний и наружный домены выглядят одинаково. Использование разных имен для внутреннего и наружного доменов может решить эту проблему, но и налагает ограничения на дальнейшее развитие пространств имен.
Основные этапы настройки сервера DNS для работы через брандмауэр таковы.
Постройте внутреннее пространство имен DNS и его основной и дополнительные серверы.
Постройте наружное пространство имен DNS и его основной и дополнительные серверы.
Определите, какие узлы будут опубликованы в зонах.
Определите, как внутренние клиенты будут разрешать внешние имена и соответственно настройте внутренние службы.
Зарегистрируйте наружные узлы в InterNIC (поскольку это именно те узлы, которые будут ''видны").
Разрешите использование службы имен через брандмауэр только для выбранных серверов.
Проверьте систему и убедитесь, что она работает так, как ожидается.
Последний этап очевиден, однако никогда нелишне проверить, как функционирует система (особенно с внешнего узла), чтобы подтвердить, что доступна только та информация, которую администратор хотел опубликовать. Необходима и проверка изнутри, чтобы гарантировать, что брандмауэр настроен правильно и внешние домены могут разрешаться пользователями изнутри брандмауэра. Увеличение до необходимых пределов емкости и надежности разрешения внешних доменов может потребовать организации параллельных каналов.
Еше одна замечательная схема работы DNS через брандмауэр — наличие основного сервера для наружного пространства имен за брандмауэром или в DMZ и дополнительного сервера перед ним. При необходимости наружный сервер может считаться основным, поскольку различие
основного и дополнительного серверов только в том, кто имеет главные файлы зоны. Все операции обслуживания можно проводить на внутреннем сервере, а наружный будет обновлять свои файлы зоны, когда необходимо. Это может потребовать работы трех серверов, но определенно будет более безопасно, чем разрешение доступа к основному серверу из внешнего мира. Кроме того, если зона повреждается, ее можно восстановить, оставаясь за брандмауэром. Убедитесь, что, если вы собрались использовать эту методику, брандмауэр будет открываться только для связи между основным и дополнительным серверами. Некоторые эксперты считают, что для дополнительной безопасности следует ограничить эту связь каким-нибудь неиспользуемым портом с большим номером, а не использовать стандартный порт DNS 53. Здесь мы коснулись лишь некоторых вариантов построения DNS и некоторых характеристик брандмауэров. Эга тема очень обширна, и следует принять во внимание дополнительные источники, имеюшие прямое отношение к типу брандмауэра и его возможностям.
Объявление служб
Сообщество Windows некоторое время назад признало, что хорошей мерой предосторожности является фильтрация портов NetBIOS внутри и за пределами сети. В основе этого лежали те же соображения, по которым большинство администраторов DNS не видят необходимости давать каждому возможность принимать передачи зоны. Знание — сила, или. по крайней мере в этом случае, указание. 1де можно эту силу получить. Информация, доступная в файле зоны DNS, с самого начала качественно отличалась от доступной в базе данных WINS. Обе они дают довольно хорошее отображение машин, имеющихся на сайте, а также кос-какие данные об их организации и структуре. Однако имена NetBIOS могут нести информацию о том, какие службы работают на различных машинах, какие из них — контроллеры домена, какие представляют службы Web, базы данных и т.д. Это слишком большая "сила", чтобы давать ее в руки кому-нибудь.
После введения записей SR.V данные DNS соответствуют, если не превосходят, данным NetBIOS по возможностям широкого обьявлення служб путем указания местонахождения их узлов. Это достигнуто благодаря многим аспектам Windows 2000, с помошью службы обнаружения домена (которая понимает структуру записей SR.V Windows 2000).
Ни использование записи SRV, ни пространство имен NetBIOS не являются плохими сами по себе. Трудность в том, что объявление заставляет системных администраторов укреплять защиту машин. Безопасность достигается путем дополнительных усилий. Иногда для этого приходится скрывать данные, которые иначе должны были быть широко известны. Однако мало того, что сокрытие не дает реальной безопасности, оно еше и довольно трудоемко. Основной момент заключается в том, что, если
структура записи SR.V не должна обязательно быть открытой, не раскрывайте ее. Это приводит к схемам двойных имен и "разделенного мозга". Ведь именно вследствие ограждения от внешнего мира внутренняя сеть может оставаться наполненной этой информацией.
Не следует забывать и о не связанной непосредственно с DNS, но имеющей отношение к пространству имен способности программ LDAP собирать немало информации о конфигурации машины под управлением Windows н ее службах, группах и учетных записях, будь то обновленная NT 4.0 или Windows 2000. Дополнительный уровень вносит Active Directory со своими службами каталогов, которые, по определению, предназначены помогать компетентному клиенту в обнаружении и, следовательно, в доступе к службам. И в этом случае такая возможность доступа неплоха сама по себе. Все сводится к правильному определению "компетентности'' клиента, и к диапазону мер защиты, от укрепления до сокрытия, со всеми промежуточными вариантами.
Динамическая DNS (DDNS)
Безопасность — это всегда компромисс между предоставляемыми возможностями и желаемым уровнем зашиты. Способность динамического обновления в DNS представляет собой беспрецедентную возможность захвата имен, что, в свою очередь, делает возможным спуфинг и атаку на систему "изнутри”，а также простое злонамеренное ее разрушение. Это необязательно должно быть так, но не исключено. Коша промышленные провайдеры DNS разрешат использование этой технологии и будет развита соответствующая поддержка обмена ключами, динамическое обновление в открытом пространстве имен станет более безопасным. Следует знать пределы возможностей безопасности, доступных в реализации динамического обновления в Windows 2000, и пределы возможностей клиента в сравнении с другими методами безопасности. Обратитесь к главе 7, ^Динамическая DNS и Active Directory", где рассматриваются доступные в начальной версии Windows 2000 конфигурации динамического обновления.
Для большинства систем нет необходимости динамического обновления в открытом пространстве имен. Если в вашей системе предусмотрены приложения с доступом к каталогам и службы открытой сети, следует тщательно и с учетом конкретной системы проанализировать варианты применения динамического обновления и меры безопасности, если оно будет использоваться.
Для большинства применений общего доступа к системе динамическое обновление в полной мере не нужно. Альтернативой может бьпъ использование экстрасети с технологиями закрытых сетей, в том числе через открытую сеть, что позволит расширить технологию Active Directory за пределы огражденной системы. Здесь ие сказано, но подразумевается, что до внедрения стратегий, позволяющих изолировать динамическое обновление до
желаемой степени при сохранении его преимуществ, эту технологию лучше всего рассматривать как предназначенную исключительно для внутреннего использования и для доверенных пользователей.
В сушествуюшей версии Windows 2000 динамическое обновление нельзя защитить, если данные зоны не интегрированы в Active Directory, В исходном состоянии клиенты Windows не могут выдавать защишенные требования обновления, совместимые со стандартами RFC, на серверы DNS, не являюшиеся разработками Microsoft. При работе совместно с Windows 2000 DNS Server новые записи по умолчанию может создавать любой член группы Прошедшие проверку. После того как запись создана, сформировавшая ее учетная запись становится ее владельцем и одна, за исключением администратора и системы, обладает правом изменять или удалять запись. Также существует специально определенная группа DnsUpdateProxy с другим поведением. Если запмсь DNS создается машиной, являющейся членом этой группы, она переходит во владение не создавшей ее учетной записи, а первой учетной записи, которая модифицирует или обновит эту запись. По определению, механизмы безопасности Windows 2000 для любого объекта Active Directory могут изменять это стандартное поведение, однако оио является разумным компромиссом между торможением или замедлением процесса динамического обновления и его безопасностью.
Безопасность почты:
SMTP, POP, IMAP и Exchange
Рекомендации по безопасности полны предупреждений о недопустимости использования Sendmail™, Exchange, серверов IMAP и т.п. То, как почта обрабатывается в домене, сильно зависит от настройки серверов имен и брандмауэров. Как правило, службы POP и IMAP следует держать за пределами брандмауэра в целях зашиты почты, каталогов и особенно паролей пользователя от внешних сил, которые могут использовать эту информацию для проникновения в систему. Имейте в виду, что протокол POP (если только это не АРОР) посылает пароли в открытом виде, так что пю- бой, кто способен внедриться в маршрутизатор между клиентом и сервером, может наблюдать за трафиком через него и получать имена пользователей и пароли. Лучше предусмотреть какой-нибудь серверный процесс идентификации, чем посылать пароли открытым текстом.
Фактически лучше всего ретранслировать почту на главный сервер с сервера, который находится за пределами брандмауэра. Это может быть как простой сервер, так и сервер обмена. Для большей безопасности можно запустить программу наблюдения, которая будет проверять, что на внешнем сервере не изменилось ничего важного, а в случае изменений восстанавливать информацию с сервера-источника данных, с компакт-диска или любого другого надежного источника.
При работе с сервером Exchange вам не придется предпринимать ничего, кроме обычных предосторожностей, так как он похож на любой другой почтовый сервер. Можно установить наблюдение за портом 25, если требуется знать, кто подьслючается к вашему серверу.
Вообше говоря, можно использовать любой узел в DMZ в качестве ретранслятора как для входящей, так и для исходящей почты. При использовании ретранслятора для входяшей почты накопитель почты фактически может находиться за брандмауэром и при этом быть настроен так, чтобы принимать почту только от узла в DMZ. Таким же образом можно использовать ретранслятор для исходящей почты, чтобы скрыть внутренние машины. Этот ретранслятор может применять особые правила, по которым для всей исходящей почты предусмотрен обратный адрес user@domain. Это облегчает получателям почты ответы на нее и позволяет скрыть настоящий компьютер отправителя.
Конечно, просмотрев полный заголовок письма, можно восстановить маршрут его прохождения, однако узел-отправитель скрыт за брандмауэром и не может быть разрешен через наружный сервер DNS организации, поэтому это не опасно. Если маршрут прохождения все же надо скрыть, можно использовать программы переотправки почты. Лучший вариант такой программы — специально написанный для вашего окружения. Перед переотправкой может понадобиться убрать из письма все заголовки, если вы хотите скрыть его происхождение.
Записи MX на внутренних серверах имен могут использоваться для направления почты, адресованной на любой нелокальный компьютер, с внутренних узлов на ретранслятор. Ретранслятор, получив почтовые сообщения, производит новый поиск (с помощью внешних серверов имен) и направляет почту ло месту ее назначения в Internet. Также ретранслятор может быть настроен для пересылки всей входяшей почты для домена на определенный узел за брандмауэром, который будет отвечать за распределение почты внутренним пользователям и субдоменам через почтовые псевдонимы. Записи MX также могут использоваться для распределения почты внутри домена.
Безопасность WWW
В наше время, вероятно, почти у любого есть свой Web-сайт. Вся хитрость в том, чтобы сделать Web-сайт безопасным и защитить его содержимое. Ведь присутствие в Web означает, что этот компьютер должен быть виден всем и каждому. (В конце концов, если компьютер недоступен для всех, какой смысл помешать на нем Web-сервер?) Исключение составляют сайты в Intranet, предназначенные только для персонала организации.
Существует огромное количество программ и методик, позволяющих защитить информацию на ваших машинах. Вероятно, самое распространенное решение — это фильтрация пакетов. Администратор может защитить Web-сервер, поместив перед ним фильтр, который пропускает на сервер только Web-трафнк и ничего более. Блокировка доступа к машине для таких вещей, как Telnet, FTP н почта, ограничивает возможные типы атак на нее.
Прокси-серверы также могут быть полезна для защиты Web-сайта, поскольку удаленные пользователи фактически приходят не на настоящий Web-сервер. Запросы удаленного пользователя перехватываются прокси-серверами, которые затем запрашивают Web-сервер. После этого прокси-серверы передают информацию обратно удаленному пользователю, который ее запрашивал.
Также можно реализовать большое число схем переадресации, в которых имя Web-сервера разрешается в виртуальный IP-адрес через DNS. Когда запросы HTTP приходят на виртуальный IP-адрес, они могут быть переадресованы на настоящий сервер. В этом случае удаленный пользователь получает информацию с настоящего Web-сервера, но его действительный IP-адрес скрыт от пользователя. Эти схемы переадресации также могут обеспечивать значительную гибкость в распределении нагрузки и обеспечивать высокую доступность.
DNS часто используют для выравнивания нагрузки или по крайней мере вероятности трафнка в системе (“ферме") либо Web-серверов, либо их прокси-серверов. Когда требуется предоставить более динамичную службу или более прямой доступ к службам приложений и данных, возникает множество трудностей. Они заставляют удаляться от простых решений с фильтрацией пакетов, но все требуют координации между DNS, '*фермой" Web н администраторами брандмауэров.
В дополнение к уже упомянутым атакам DNS ваша система может стать объектом атаки "изнутри". Если хакер может переадресовать все запросы на определенный Web-anpec своей мап1ины и имеет на этой машине модифицированный сервер, он может использовать эту машину для обслуживания запросов ваших Web-клиентов и наблюдать за всем, что делается на сайте. Это одна из причин, по которым важно иметь безопасный сервер, не подверженный атакам DNS.
Безопасность FTP
У серверов FTP есть свои уязвимые места, но для них существует способ защиты с использованием обратного просмотра. Многие серверы FTP протоколируют в журнале подключения, произведенные удаленными узлами, и записывают их имена и IP-адреса. Обратный просмотр позволяет удостовериться, что имя узла и IP-адрес, используемые для под-
ключения, соответствуют друг другу. Хотя в смысле безопасности это не выглядит особенно значительным, журналы по крайней мере показывают настояшие IP-адреса и имена узлов, если ожидается проникновение через сервер FTP. Кстати, многие серверы HTTP также записывают в журнал информацию, найденную при обратном просмотре.
Назначение обратного просмотра — гарантировать, что 1 P-адрес и имя узла так или иначе соответствуют друг другу. В противном случае сервер FTP разрывает соединение при попытке клиента произвести загрузку. Наряду с обратным просмотром можно также использовать фильтры, чтобы запретить трафик любого другого типа с узлом FTP. Подобная защита даже надежных, внутренних серверов FTP очень полезна и требует лишь поддержки обратного разрешения в DNS и пригодного для этого сервера FTP.
Ошибка, которую часто допускают администраторы при настройке анонимного узла FTP, — разрешение анонимным пользователям записывать даннь[е в каталоги, В результате узел становится уязвимым для хакеров, которые пытаются заполнить файловую систему до отказа и сделать систему нестабильной или генерируют множество запросов на регистрацию, что может привести к перегрузке процессора и памяти. Атаки такого рода могут вызвать отказ от обслуживания как на сервере, так и в сегменте сети, к которой он подсосдинен,
Наличие анонимных FTP очень полезно и в некоторых ситуациях необходимо, однако ограничение количества допустимых сервером FTP соединений и запрет на запись для анонимных пользователей могут уберечь администратора от многих неприятностей. Анонимные FTP также создают проблему открытой пересылки паролей, которые может перехватить любой с помощью программы слежения за сетевым трафиком.
Главное соображение, которое надо учитывать, — то, что сервер FTP должен работать в полностью изолированном отсеке в DMZ. Также следует обеспечить, чтобы пароли для этого отсека не соП，“2&“ с паролями для других машин в сети. Таким образом, если пароль раскрыт, это повлияет только на сервер FTP, но не на остальные машины в сети. Отсек, как и другие отсеки в DMZ, должен иметь как можно меньше или вообще не иметь доверительных отношений с окружением узлов вашей сети.
Резюме
Эта глава не охватывает всех проблем безопасности, которые надо учитывать при настройке сети, подключенной к Internet. В ней рассматриваются лишь вопросы, наиболее тесно связанные со службами DNS. Ниже мы перечислим несколько хороших книг по безопасности, к которым вы можете обратиться за помошью при создании безопасной системы для DNS и других служб.
Firewalls Complete, Marcus Goncalves, McGraw-Hill. ISBN: 0-0702- 4645-9.
Windows AT Security: A Praciieal Guide to Security Windows NT Servers and Workslaiions, Charles B. Rutstein, McGraw-Hill. ISBN: 0-0705- 7833-8.
Internet Firewalls and Network Security、Karanjit S. Siyan and Chris Hare, New Riders Publishing. ISBN: 1-5620-5437-6.
tnlemei Security: Professional Reference, Second Eition, Derek Atkins, et. al. Tom Sheldon, Tim Petro, Joel Snvder, Chris Hare, New Riders Publishing. ISBN: I-5620-5760-X.'
Maximum Security: A Hacker 3 Guide ro Protecting your Internet Site and Network, Anoninious (an experienced hacker). Sams Publishing. ISBN: 0-6723-1341-3,
NT Network Security、Matthew Strebe, Charles Perkins, and Michael G. Moncur, Sybex. ISBN: 0-7821-2006-7.
Windows NT Securitv Guide, Stephen A. Sutton, Addison-Weslev. ISBN: 0-201-41969-6.
Windows NT Securhv Handbook, Toe Sheldon, Osborne McGraw-Hill. ISBN: 0-07-882240-8.
Настройка Windows DNS Server
В этой главе...
Описывается установка и настройка сервера DNS Windows 2000. Приводятся некоторые разъяснения, когда к зачем можно млн следует использовать различные функции, но основное внимание__уделяется ознакомлению с сервером, в предположении, что разработка и планирование системы проведены раньше.
Перед тем, как начать. Приводится краткое напоминание о подготовительных этапах, которые делают настройку служб DNS значительно более последовательной.
Установка Windows DNS Server. Охватывает минимально необходимые этапы настройки DNS в Windows 2000.
Настройка сервера DNS. Обзор свойств сервера.
Создание зоны, субдомена и записи ресурсов (RR). Кратко излагается процесс заполнения локального сервера,
Интеграция в Active Directory. Обзор настроек и эффектов хранения данных в Active Direclory.
Типы серверов. Настройка сервера в сравнении с другими серверами.
Чистота зоны. Краткое описание процесса очистки.
Поддерживаемые функции. Некоторые инструменты управления и анализа работы сервера.
Назначение этой главы — приумножить и обосновать информацию, представленную в предыдущих главах. DNS, безусловно, — самая популярная служба управления пространством имен. Роль, которая отводится DNS в Windows 2000, вероятно, значительнее, чем где бы то ни было, по крайней мере чем в любой предыдущей версии Windows.
В свое время одной из главных целей внедрения DNS было лишь облегчить пользователю и администратору идентификацию своей системы. DNS впервые появилась потому, что единственный файл hosts.txt, который использовался в старом методе, стал слишком большим и затруанял поиск имен для машин. При файле hosts . тхт пространство имен было плоским, одноуровневым, и поэтому мог существовать только один узел с определенным именем, а популярные имена были быстро разобраны.
Представьте, что в вашем распоряжении 300 безымянных машин в нескольких рахшчных подсетях, и вы быстро поймете, в чем ценность службы имен. Попробуйте только запомнить три сотни телефонных номеров без справочника! В настоящее время многие службы ожидают от клиента имени, а в некоторых случаях даже требуют его; следовательно, неизбежно должен существовать инструмент управления пространством имен.
Предположим, что в рассредоточенной защищенной системе кли- ент/сервер находится 300 сложных клиентских систем, каждая из которых регулярно ишет ресурсы и обращается к ним. Пусть также эти ресурсы появляются и исчезают, объявляя о своем присутствии, когда они доступны, и снимая свои объявления, когда доступность прекращается. Это поможет вам уяснить, какое отношение центральная служба DNS имеет к новой архитектуре Windows.
Прежде чем начать...
К этому моменту вы уже должны иметь четкое представление о своей сети и своих задачах в ней. Также вы должны спланировать структуру Active Directory как логически, определив границы пространства имен, так и физически, путем размещения серверов и присвоения им зон. Настройка службы DNS Microsoft — достаточно простой процесс. Установка также очень легка, но пусть это не вводит вас в заблуждение. Если у вас не получится правильно разработать и настроить службу, вам в лучшем случае придется вернуться к началу и проделать все заново или все время сражаться с ошибками.
Вы уже должны немало знать не только о своей сети м задачах, но и о проблемах связи и о том, как они влияют на разработку. Их число бесконечно. но следует обратить внимание прежде всего на использование
брандмауэров, специальных параллельных и/или трассированных сетей, каналы к удаленным узлам, нагрузку от клиентов и порядок доступа. Другие вопросы, которые должны быть выяснены к этому моменту, включают использование Active Directory, динамической DNS и их настройку, если они будут применяться.
Эта глава написана для тех. кто уже имеет подготовку н четкий план действий. Она охватывает настройку Windows 2000 DNS в системе с неограниченным сетевым доступом, будь то полноценный выход в Internet или связь с другими частями вашей площадки. Соображения по планированию и разработке, по защите пространства имен и другим возникающим проблемам были изложены в главах 7, ^Динамическая DNS и Active Directory", 9, ^Проектирование служб DNS" и 10, "Проблемы безопасности". Наибольшей проблемой для вас будет (или, скорее, было) соответственное планирование домена в смысле делегирования или его отсутствия и размещение серверов и зон. Для этого у вас уже должен быть составлен четкий план расположения каждого сервера и клиента в сети.
Что касается установки DNS, теперь самое время приступить к ней.
Установка Windows DNS Server
Если что в Windows 2000 и производит впечатление незамысловатого, то это установка различных сетевых служб. Она сделана настолько простой, что можно поверить, будто работа этих служб так же проста. Несложный запуск установленных служб лает хорошее представление о том, что именно установлено, и обеспечивает довольно хорошую настройку.
Предварительные условия такие же, как и для установки большинства программ. Надо, чтобы была установлена операционная система Windows 2000 Server и настроен протокол TCP/IP. Если сервер еше не использует статически присвоенный IP-адрес, позаботьтесь об этом. Имя узла должно быть постоянным； после объявления его клиентам изменение имени или JP-адреса будет гораздо менее удобным и легким. Вы должны зарегистрироваться в системе с правами администратора; кроме того, надо учесть еше некоторьге обстоятельства. Сами по себе программы невелики, и сервер уже выбран. Следует предпочесть большой объем памяти, поскольку DNS будет стремиться кэшировать свою базу данных для увеличения производительности, пользуясь тем объемом памяти, который вы можете предоставить, Конечно, требуемый объем памяти возрастает с увеличением зоны, как и объем, необходимый для системного раздела; или, если используется Active Directory, в любом случае необходимо место для хранения NTDS . DIT,
Что нужно для службы сервера DNS
Любой компьютер, на котором работает служба сервера DNS, должен иметь статически присвоенный IP-адрес Имя и адрес, которые будут исполь- 3； зоваться для машины, должны быть выбраны так, чтобы менять их приходи- ；? лось как можно реже, или даже никогда.
Процедура установки
Процесс установки, как уже было сказано, очень похож на установку других сетевых служб, а основная работа заключается в настройке после установки. На рис. 11.1 показано диалоговое окно Сетевые службы, в котором установкой DNS управляет простой флажок. Можно использовать мастер настройки сервера или последовательно выполнить следующие действия.
Рис. 11,1. Выбор DNS в диалоговом окне Сетевые службыРис. 11,1. Выбор DNS в диалоговом окне Сетевые службы
Рис. 11,1. Выбор DNS в диалоговом окне Сетевые службы
Рис. 11,1. Выбор DNS в диалоговом окне Сетевые службы
Откройте панель управления.
Выберите команду Установка/удаление программ.
Щелкните на значке Установить/удалить компоненты Windows слева и запустите мастер компонентов Windows.
Прокрутите список и выберите Сетевые службы.
Щелкните на кнопке Состав, чтобы открыть список сетевых служб.
Прокрутите список и установите флажок напротив пункта DNS.
Теперь просто завершите работу мастера компонентов Windows, сделав щелчок на кнопке Далее и/или Готово в зависимости от того, надо ли установить в мастере еще какие-то параметры.
Как и везде в Windows 2000, по интерфейсу можно перемешаться несколькими способами- В этом случае для этапов 1-3 есть быстрая альтернатива.
Вызовите контекстное меню (щелчок правой кнопкой мыши) значка Мое сетевое окружение и выберите команду Свойства. Откроется окно проводника в папке Сеть и удаленное подключение.
В главном меню откройте выпадающее меню Дополнительно и выберите команду Дополнительные сетевые компоненты.
Когда DNS установлена, можно начинать работу, Имеется в виду, конечно, ваша работа. Только в том случае, если устанавливается сервер, предназначенный только для кэширования, работа близка к завершению.
Итак, что же произошло? DNS Server установлен и уже должен работать. Но имело место еще несколько друтих событий. Появился новый пункт в меню Пуск и новые элементы во многих встроенных приложениях консоли управления Microsoft. Появилась структура подкаталогов в %windir%\system32\dns, где по умолчанию будут храниться данные DNS Server. Кроме того, информация для DNS Server записана в раздел реестра HKLM\System\CurrentControlSet\Services\DNS. Наконец, в системный монитор добавлена поддержка некоторых новых счетчиков, и в недрах системы выполнено большое количество других настроек.
Консоль управления DNS Server
В первую очередь вы должны получить доступ к главному инструменту —консоли управления DNS Server. Ее можно найти в меню Пуск в папке Администрирование. Просто поищите пункт DNS. Также ее можно запустить в меню Выполнить или в командной строке, введя dnsmgmt. msc. Этот инструмент будет основным для большинства операций администрирования DNS, хотя нельзя упускать из виду и DNSCMD.EXE для управления из командной строки (см, главы 12, ''Средства поиска неисправностей11 и 13, uРациональные методы работы и обслуживания").
На консоли управления можно управлять несколькими серверами DNS, либо одним локальным и остальными удаленными, либо всеми удаленными. Установка административных инструментов Windows 2000 на вашей рабочей станции (вернее, на вашей профессиональной рабочей станции) позволит вам управлять этими службами н не присутствуя на сервере. Это можно сделать, найдя ADM工NSPAK.MS工 на инсталляционном CD Windows 2000 в каталоге .\i3 8 6 либо на установленном сервере в каталоге ¥,windir%\systeTn32 и установив его на выбранную машину.
Чтобы зарегистрировать сервер DNS для управления, щелкните на самом верхнем узле под названием DNS. Затем откройте контекстное меню этого узла либо меню Действие и выберите команау Подключение к компьютеру. Сначала вид консоли управления может показаться вам несколько странным. Заметьте, что действия зависят от того, на каком элементе консоли находится фокус. Очень часто сначала нужно щелкнуть на узле, чтобы раскрыть его на правой панели (панели содержимого), и после этого пункты меню будут соответствовать новому положению фокуса.
Откройте консоль управления DNS и выберите команду меню Вид. В этом меню можно настроить параметры (команда Настроить), но, скорее всего, вам придется выбрать команду Расширенный, чтобы отображение стало более подробным. В этом режиме также можно проверить кэшированные записи в появившемся новом узле Кэшированные просмотры.
Два наиболее обычных пути доступа к интерфейсу управления DNS — через настраиваемые консоли или с консоли Управление компьютером. Первые предварительно надо созаать Для доступа ко второй вызовите из контекстного меню Мой компьютер команду Управление или введите в командной строке compmgmt.msc. На открытой консоли DNS находится в составе узла Службы и приложения. Эта консоль удобна тем, что позволяет обращаться к журналу событий и подобным службам, таким как DHCP, WINS и DNS, в одном и том же интерфейсе.
Немного осмотритесь в интерфейсе управления, чтобы чувствовать в нем себя как дома. Мы собираемся дать обзор функций DNS, ио сначала хотели бы привлечь ваше внимание к некоторым переключателям и командам. Посмотрите на рис. 11.2; там показано контекстное меню узла сервера.
；0,КСНСОЛЬ,Дейстаие аиа 6"広)日为宙0^；0,КСНСОЛЬ,Дейстаие аиа 6"広)日为宙0^^Z1^Z1■Cwrr«>a|■Cwrr«>a|少 Конфигурация DNS-сервера少 Конфигурация DNS-сервераНастроить «peep,* ,ОжатъЕОЕявляетсяУспитьсесйствахе для всех» ания, используемомУдалить устаревоме тки，：：「F”sx 貶WOB ВОбнсвлен* файлов д»««к»ера「как службаСчистить；мена доменов■Это позволяетНастроить «peep,* ,ОжатъЕОЕявляетсяУспитьсесйствахе для всех» ания, используемомУдалить устаревоме тки，：：「F”sx 貶WOB ВОбнсвлен* файлов д»««к»ера「как службаСчистить；мена доменов■Это позволяетняое огмо отсюданяое огмо отсюда% просмотра.% просмотра.ОбновитьОбновитьм49^ 0k^м49^ 0k^Рис. 11.2. Меню узла сервера в интерфейсе DNS ServerРис. 11.2. Меню узла сервера в интерфейсе DNS Server
；0,КСНСОЛЬ
,Дейстаие аиа 6"広)日为宙0^
；0,КСНСОЛЬ
,Дейстаие аиа 6"広)日为宙0^
^Z1
^Z1
■Cwrr«>a|
■Cwrr«>a|
少 Конфигурация DNS-сервера
少 Конфигурация DNS-сервера
Настроить «peep,* ,
ОжатъЕОЕявляется
Успитьсесйствахе для всех» ания, используемом
Удалить устаревоме тки，：：「F”sx 貶WOB В
Обнсвлен* файлов д»««к»ера「как служба
Счистить；мена доменов
■Это позволяет
Настроить «peep,* ,
ОжатъЕОЕявляется
Успитьсесйствахе для всех» ания, используемом
Удалить устаревоме тки，：：「F”sx 貶WOB В
Обнсвлен* файлов д»««к»ера「как служба
Счистить；мена доменов
■Это позволяет
няое огмо отсюда
няое огмо отсюда
% просмотра.
% просмотра.
Обновить
Обновить
м49^ 0k^
м49^ 0k^
Рис. 11.2. Меню узла сервера в интерфейсе DNS Server
Рис. 11.2. Меню узла сервера в интерфейсе DNS Server
Пункт меню Все задачи, в свою очередь, включает команды Стоп, Пуск, Пауза и Продолжение для соответствующих действий над сервером. В основном меню команда Очистить кэш позволяет освободить кэш распознавателя DNS. Поскольку в Windows 2000 DNS Server реализована спецификация NCACHE, когда кэшируются отрицательньге ответы, очишать кэш будет необходимо несколько чаше, особенно на проверочных этапах перед развертыванием системы. Также в этом меню имеется команда Обновление файлов данных сервера, которая позволяет синхронизировать версию данных конфигурации и зоны, находящуюся в памяти, с версией на диске. Две команды, связанные с очисткой (Установить свойства очистки для всех зон и Удалить устаревшие записи), дают возможность заметить, что на консоли предусмотрена максимально безбо-
лезненная поддержка динамической DNS (DDNS), Команаа Настроить сервер запускает мастер (см. ниже), а задача, выполняемая командой Создать новую зону, будет первой, к которой мы приступим после рас- смотрения параметров настройки сервера.
Настройка сервера DNS
Прежде чем идти дальше, следует познакомиться с элементами управления уровня сервера, доступными в Windows 2000 DNS Server. На рис, 11.3. показано диалоговое окно Свойства сервера, открытое на вкладке Пересь|лка.
DEMO1 - свойстваDEMO1 - свойстваКорневые ссыпки I Ввашчхвюнала J НвйРКорневые ссыпки I Ввашчхвюнала J НвйРПвресыА«1-ПвресыА«1-зпюмниа I Бв»опво<осг4>;:I Досолннтепемсзпюмниа I Бв»опво<осг4>;:I ДосолннтепемсП«рк5ллкялом!1гвв1 наши результат да<Ии^ зиязм* * 0NS. который «янпйпвнданнынсареерон VП«рк5ллкялом!1гвв1 наши результат да<Ии^ зиязм* * 0NS. который «янпйпвнданнынсареерон V
DEMO1 - свойства
DEMO1 - свойства
Корневые ссыпки I Ввашчхвюнала J НвйР
Корневые ссыпки I Ввашчхвюнала J НвйР
ПвресыА«1-
ПвресыА«1-
зпюмниа I Бв»опво<осг4>;:
I Досолннтепемс
зпюмниа I Бв»опво<осг4>;:
I Досолннтепемс
П«рк5ллкялом!1гвв1 наши результат да<Ии^ зиязм* * 0NS. который «янпйпвнданнынсареерон V
П«рк5ллкялом!1гвв1 наши результат да<Ии^ зиязм* * 0NS. который «янпйпвнданнынсареерон V
■Jstwayr nBfieasflHM^ceKj■Jstwayr nBfieasflHM^ceKjОтменаОтмена! 169 254 IOCS'! 169 254 IOCS'ПриданнтаПриданнта
■Jstwayr nBfieasflHM^ceKj
■Jstwayr nBfieasflHM^ceKj
Отмена
Отмена
! 169 254 IOCS'
! 169 254 IOCS'
Приданнта
Приданнта
i? Роэр®чыт1,пяпя(ал>1у; ：-；「
Для лобпвления*омпьк>1врк пересыпки» вавш<те：： fp-адаес* нажните KHonity "аавввитУ.
IPaweu
Рис, 113 Вкладка Пересылка диалогового окна
Свойства сервера DNS Windows 2000
Чтобы открыть диалоговое окно Свойства сервера DNS, выполните следующие действия.
Откройте интерфейс управления DNS Server.
Щелкните на нужном сервере в списке серверов под верхним узлом DNS.
Вызовите меню Действие или контекстное меню выбранного сервера (выделите л щелкните правой кнопкой мыши).
Выберите пункт Свойства.
Совершим небольшое путешествие по параметрам и настройкам, доступным в этом диалоговом окне. Это настройки уровня сервера, т.е, они действуют на весь сервер. Свойства уровня зоны и записи будут рассмотрены ниже.
Свойства сервера DNS: Интерфейсы
Взглянув на вкладку Интерфейсы, вы увидите, что здесь можно управ- Л5пъ сетевыми интерфейсами, по которым сервер DNS бупет принимать запросы и отвечать. Можно выбрать либо все интерфейсы, либо вручную настраиваемый список IP-адресов. Поскольку эти настройки действуют на уровне сервера, видно, что по умолчанию сервер DNS девает все зоны доступными на всех разрешенных интерфейсах.
Чтобы введенные здесь изменения подействовали, сервер DNS надо остановить и перезапустить. Чтобы сделать это, обратитесь к подменю Все задачи в контекстном меню сервера.
Свойства сервера DNS: Пересылка
Во вкладке Пересылка можно разрешить использование узлов пересылки (см. рис. 11.3). Вспомните, что узел пересылки — это сервер DNS, на которь由 пересылающий сервер (т.е. тот, который вы сейчас настраиваете) будет посылать запросы, полученные от распознавателя клиента Сначала пересылающий сервер проверяет, может ли он сам ответить на запрос, и пересылает его, если это невозможно, Об этой особенности работы пересылки часто забывают. Пересылке подвергается все, на что сервер не может ответить полностью. Если иересьглочные узлы служат для связи внутреннего пространства имен DNS с открытым, пересылающая машина должна быть авторитетной для всех внутренних зон, чтобы запросы о внутренних мменах не попадали на внешний сервер DNS.
Узлы пересылки настраиваются путем установки флажка Разрешить пересылку и создания списка серверов DNS. Для этого надо последовательно вводить IP-адреса серверов и щелкать на кнопке Добавить. Учтите, что порядок узлов пересыпки в списке можно изменять так, чтобы наиболее производительные и доступные серверы DNS значились в списке первыми.
Ваш сервер DNS будет посылать запросы на машины, перечисленные в списке. Значение Тайм-аут пересылки (сек) определяет, какое время сервер DNS будет ожидать ответа, прежде чем другими средствами попытается удовлетворить запрос клиента.
Внизу диалогового окна, если пересылка разрешена, имеется флажок Не использовать рекурсию. Заметьте, что этот элемент управления и Тайм-аут пересылки взаимно исключают друг друга. Если флажок Не использовать рекурсию установлен, сервер DNS становится подчиненным пересьыочных узлов. Он уже не может самостоятельно пытаться рекурсивно разрешить запрос, а должен полагаться на работу пересылочных серверов. Это название может показаться неверным, ведь здесь не идет
речь о втором типе запросов — итеративных запросах, которые адресуются серверам корневого уровня в корневых ссылках. Может быть, название Не начинать разрешение лучше подходило бы по смыслу. Параметр Не использовать рекурсию делает ваш сервер DNS подчиненным сервером, выполняющим только пересылку на указанные узлы.
Свойства сервера DNS: Дополнительно
Г7ШГ7ШНа рис. 11.4 показана вкладка Дополнительно диалогового окна Свойства сервера DNS. Хотя обычно у нас иет возможности рассказывать обо всех параметрах настройки, в этом случае мы даднм довольно много информации.
Г7Ш
Г7Ш
DI - свойства
Корневые саижи ]：；;бядадаеж5^тга：ж：Нв«й1ОДв«ио：;；Ь；5взоаасмость,-
Интерфейсы I ПересильДолопнч>влм<о
nepeneipxсервера: ■■ ..:.：:. - ：.•
• nocoesef е "y“6z BIND Ознбке as” gi“e ср“ ззгруз»е з。” повре*де“н
“В，п*“” ааЕв>ое«у с。anpeoj
Проверке iptertПроверке iptert[MH0'^5oiro5bin!UTFg)[MH0'^5oiro5bin!UTFg)3ww*a“ гону пристав3ww*a“ гону пристав；Мз Agve О”9bby “ реестре；Мз Agve О”9bby “ реестреГ рвэрештцргомагиивское ^aanet«« чстаревш>« зелисейГ рвэрештцргомагиивское ^aanet«« чстаревш>« зелисей三三
Проверке iptert
Проверке iptert
[MH0'^5oiro5bin!UTFg)
[MH0'^5oiro5bin!UTFg)
3ww*a“ гону пристав
3ww*a“ гону пристав
；Мз Agve О”9bby “ реестре
；Мз Agve О”9bby “ реестре
Г рвэрештцргомагиивское ^aanet«« чстаревш>« зелисей
Г рвэрештцргомагиивское ^aanet«« чстаревш>« зелисей
三
三
Рис, 11.3. Вкладка Дополнительно диалогового окна Свойства сервера DNS Windows 2000
Сравнив рис. 11.3 и рис. 11.4, можно заметить дополнительную вкладку под названием Безопасность. Рис. 11.3 относится к рядовому серверу, а рис. 11.4— к серверу DNS на контроллере домена, настроенному для хранения данных зоны в Active Directory.
Проверка имен
Раскрывающийся список Проверка имен управляет алгоритмом синтаксического анализа меток в именах DNS при проверке их допустимости. При выборе значения Строго RFC (ANSI) имена должны полностью удовлетворять требованиям Request for Comments (RFC). По умолчанию
выбрано значение Многобайтовый (UTF-8); это развивающийся стандарт поддержки глобализации (подробнее о нем см. в приложении Б, “Документм RFC по DNS"). Остальные два значения. Не RFC и Все имена, предназначены для нестрогой проверки имен и различаются тем, что в последнем случае проверка вообще отключена, а в предьщушем требуется только, чтобы имена были составлены из символов набора ANSI. Для полноценного взаимодействия со всемирной DNS надо использовать Строго RFC (ANSI).
Хранение файлов конфигурации и зоны
Возможно, первое, на что надо обратить внимание, — это настройка способа, которым сервер будет Загружать зону при старте. Возможны три варианта: Из файла, Из реестра и Из Active Directory и реестра.
Именно здесь настраивается интеграция DNS в Active Directory. Эта интеграция — сложный процесс, но запускается простым выбором значения в списке. Как точно выразился мой рецензент, это 41 простое изменение с большими последствиями". Поскольку анализу наиболее важных из этих последствий посвящена глава 7, "Динамическая DNS и Active Directory1', здесь рассмотрение ограничивается настройкой сервера DNS.
Если выбран вариант Из файла, для определения загружаемой зоны используется загрузочный файл, находящийся в каталоге %windir%\ system32\dns. Это расположение, скорее всего, изменить невозможно; директива directory в загрузочном файле игнорируется, а использование полных путей к файлам зоны тоже не дает эффекта. К настоящему времени нет документированной информации по разделам реестра, которые управляют этим расположением.
Если выбран вариант Из реестра, загружаемые зоны определяются значениями разделов реестра, но сами данные зон по-прежнему находятся в файлах зон, как в случае Из файла, в допушении, что имена файлов зон в соответствующих разделах реестра не изменились. Только при хранении в Active Directory эти файлы зон перестают использоваться.
Если режим хранения изменяется с файла на реестр, существуют”诉 загрузочный файл копируется в подкаталог (. \backup), который при необходимости создается. При переходе вновь к хранению в файле создается новый загрузочный файл по информации из реестра. Во время хранения данных в файле загрузочные данные конфигурации в реестре и файле синхронизованы.
Если установлен режим Из Active Directory и реестра, загрузочные данные конфигурации хранятся в реестре, а данные зоны ——в Active Directory. После перехода к этому режиму данные зоны преобразуются в объекты Active Directory и становятся доступными через инструментальные средства LDAP, что включает их присутствие (только для чтения) на консоли Active Directory: пользователи и компьютеры, dsa .тзс. При этом загрузочный фай Ji опять помешается в .'backup, а в boot . TXT остается только сообщение об этом.
В табл. 11.1 приведены места хранения данных при различных настройках.
Что касается файлов, не следует забывать о выполнении команды Обновление файлов данных сервера. Перед редактированием файла, загрузочного нли зоны, эта команда заставляет сервер DNS фиксировать все кэшированные изменения на диске. Она показана на рис. 11.2.
Таблица 11.1. Хранение данных конфигурации DNS и зоны
РежимДанные конфигурацииДанные зоны
Из файлаТекстовый файлиреестрТекстовый файл
Из реестраРеестрТекстовый файл
Active DirectoryРеестрActive Directory
Отключить рекурсию
Флажок Отключить рекурсию не надо путать с элементом похожего названия на вкладке Пересылка. Здесь этот элемент управляет типом запросов, которые будут приниматься. Если флажок Отключить рекурсию установлен, сервер DNS действует как сервер корневого уровня, т.е. принимает только итеративные запросы. По умолчанию Windows 2000 DNS Server принимает рекурсивные запросы.
Дополнительные службы BIND
Этот флажок не действует на передачи зон между двумя серверами DNS Windows 2000. Если зона передается на сервер BIND или неизвестного типа, этот флажок включает менее эффективный, но более совместимый способ передачи. Этот элемент управления был в NT 4 DNS Server. Убедитесь, что он установлен, если предполагаются передачи на серверы BIND версии младше 4.9.4, которые не принимают более одной записи ресурсов в сообшении. По умолчанию этот флажок установлен.
Ошибка, если данные при загрузке зоны повреждены1
Название этого флажка говорит само за себя. В случае, если он установлен, зона не загружается при условии, что она содержит поврежденные данные. Если флажок сброшен (как по умолчанию), сервер DNS лишь вьщает сообщение об ошибке, но загружает зону, игнорируя неко* торые данные. Рекомендуется вспомнить, какова установка этого параметра, прежде чем редактировать зону, ведь вы можете допустить синтаксические ошибки!
'Неточный перевод при локализации. Этот флажок скорее должен называться "Не загружать зону, если ее данные повреждены ” — Прим. ред.
Что касается файлов, будьте осторожны: как показано на рис. 11.5, редактирование файлов зоны и данных не всегда бывает успешным. И еше раз напоминаем: не забывайте сначала обновить файлы и проверьте, включено ли динамическое обновление.
|консот> управпАнка Micros。"
Нет^зязагщститьивдвоу Micra*ofl DNS Ssaat hoDEMO!-
Ошибка 9ЯЙ・ Зоне DNS и*асц«ествуеи-- ■;
广我口
Рис. 11.5. Сообщение информирует, что редактирование загрузочного файла или файла зоны было не совсем успешным
Включить циклическое обслуживание
Этот флажок позволяет серверу DNS циклически переключаться между iP-адресамм нескольких записей А одного узла. Это ничего не дает в смысле разумного выравнивания нагрузки, но позволяет распределять ее случайным образом. Сервер DNS замечает, какой IP-адрес ответил первым на последний запрос, и перебирает список iP-адресов до успешного ответа.
Включить расстановку по адресу
Эта функция Windows 2000 DNS Server разрешает серверу отдавать предпочтение определенным IP-адресам при ответах на запросы. Если узел имеет несколько записей А, то при условии, что сервер DNS может определить, что некоторые из них соответствуют маске локально访 подсети запрашивающего клиента, они помешаются в ответ первыми. По умолчанию этот флажок установлен.
Включить безопасный кэш
Эта функция управляет добавлением в кэш ссылочных ответов. Если этот флажок установлен, ссылки добавляются в кэш только в том случае, если узел, на который они указывают, принадлежит к тому же родительскому домену, который указан в запросе. Например, если при запросе на узел в hq. example. net сервер DNS возврашает ссылку на сервер имен в example.net, эта ссылка кэшируется; но если возвращается ссылка на bad.hack.com, она не кэшируется и поэтому не используется при последующих разрешениях. По умолчанию это не разрешено. Прежде чем установить этот флажок, подума访те, не приведет ли это к замедлению работы из-за необходимости дополнительных запросов, например при идентификации.
Свойства сервера DNS: Корневые ссылки
В этой вкладке показан файл текущего кэша, или корневых ссылок. Выше, на рис. 4.11, можно было увидеть, что в нем используется стандартный набор серверов корневого уровня Internet. Здесь можно быстро проверить настройку корневых ссылок сервера DNS, Запомните, что этот файл имеет ключевое значение для настройки серверов внутреннего пространства имен, и поэтому при поиске неисправностей можно обратиться к нему и проверить, правильны ли используемые корневые ссылки.
Свойства сервера DNS: Ведение журнала
Эта вкладка позволяет выбрать, что будет записываться в файле отладочного журнала. На высокозагруженном серзере надо с осторожностью подходить к установке приведенных здесь флажков. Журнал можно найти в файле %windir%\system32\dns\dns. log； он представляет собой текстовый файл ASCII.
Несколько более подробная информация о возможных параметрах журнала представлена в табл. 11.2. Она должна быть полезной, поскольку в интерфейсе ничего об этом не говорится.
Эта возможность ведения журнала, особенно в сочетании с другими доступными средствами, наблюдением (т.е. системным монитором) и записью событий способствует созданию мошного информационного ресурса. Мы надеемся, что вам придется ее использовать не часто, исключая задачи определения требуемой емкости и отслеживания каких-нибудь нечестных попыток. Помните, что, разрешив ведение журнала, вы уменьшаете производительность сервера и заставляете его гораздо быстрее генерировать большой объем данных.
Свойства сервера DNS: Наблюдение
Эта вкладка позволяет послать тестовый рекурсивный запрос на удаленный сервер DNS или выполнить простой тест локальной системы. Это можно сделать, просто установив флажок напротив нужного теста и шелкнув на кнопке Тест. Более интересен параметр Удаленная система, однако он, даже при повторном применении, лишь позволяет установить, что два сервера находятся в контакте и общаются на одном и том же "язь^ке". Также можно запустить повторяющийся через определенные интервалы тест.
Свойства сервера DNS: Безопасность
Эта вкладка доступна, только если включена интеграция в Active Directory по крайней мере для одной зоны. Наиболее простой вид вкладки Безопасность показан на рис. 11.6; она представляет собой знакомое вам диалоговое окно Безопасность, используемое для редактирования списков
контроля доступа (ACL) в разных частях Windows 2000. Вкладка отображает настройку безопасности объекта MicrosoftDNS в Active Directory.
Выделенная строка для группы Прошедшие проверку показывает, что эта приоритетная группа обладает правом на чтение. В главе 7 вопросы безопасности при использовании Active Directory излагаются подробно.
Таблица 11.2. Параметры журнала сервера DNS
ПараметрЧто означает
Запрос Уведомление Обновление
Вопросы Ответы
Протоколируются входящие запросы
Протоколируются входящие уведомления
Протоколируются входящие динамические обновления
Протоколируются вопросные части входящих запросов Протоколируются ответные части сообщений, отправляемых в ответ на запросы
Отправить Получить UDP
Отслеживается число запросов, отправленных сервером
Отслеживается число запросов, принятых сервером
Отслеживается число входящих запросов через протокол дейтаграмм пользователя (UDP)
TCP
Отслеживается число входящих запросов через протокол управления передачей (TCP)
Полных пакетов
Отслеживается число отправленных полных пакетов
Запись с помощью2
Отслеживается число пакетов, записанных одновременно в зону и в кэш
Создание зоны, субдомена и записи ресурсов
Теперь у вас есть две возможности ввести в действие локальный сервер. Если устанавливается сервер только для кэширования и желателен файл корневых ссылок для Internet, все уже сделано. Просто укажите клиентам на эту машину. Может потребоваться задать несколько пересылочных узлов, но это не обязательно, сервер будет работать и без них. Если же вам нужен кэширующий сервер для внутреннего пространства имен, отредактируйте файл корневых ссылок и укажите узлы пересылки (если они есть).
'Более точно этот параметр должен называться "Сквозная запись ", так как здесь идет речь о записи & зону через кэш — Прим. ред.
D1 - свойства
^Интерфейсы ： ( Пересыпки： J ■■： ■ Jlotwwnirartrfo
Попныи доступЗописьСоздание есехдочермчхсб、ек，оеУдаление eg，дичерчьо объемовПопныи доступЗописьСоздание есехдочермчхсб、ек，оеУдаление eg，дичерчьо объемов>К<ЧЗневывсс«ля4 I： Ведеинея^ншМ<4: Набдаишиив^-ггБвЗОпм^осТ!,：：
Попныи доступ
Зопись
Создание есехдочермчхсб、ек，ое
Удаление eg，дичерчьо объемов
Попныи доступ
Зопись
Создание есехдочермчхсб、ек，ое
Удаление eg，дичерчьо объемов
йSYSTEM
色A4М"”58，0p3 Геа*mР1?\ааниниетро,ор3)
ЁазреввнияЁазреввнияД Администраторы домене (Е>ЛМР1_ЕАПмииистр @ Аа，《«“С гра г。".，"ре&^риаг"* (EXAMPtEVAfl«*， gCpea Windows 2000 даСЕуп [EXAMPt ССсапМЛе
Ёазреввния
Ёазреввния
Лщ。仲“，еено I Ма^гез^ги^Апя^Фвснотрат" J рмрвманий
р Переносить насАедаегшв or рйдшелмжопюаъета ■; разрешения ив этот объект .
OK I OtMBHe I Гчищенить^!
Рис. 11.6. Свойства безопасности сервера DNS
Создание зон
Более вероятно, что вам понадобится поддерживать делегированную часть пространства DNS, внутреннюю или открытую. Допустим, что вам нужен основной сервер для домена test. example.net. Ниже приводится порядок действий в допущении, что вы уже начали настраивать сервер и первым делом должны создать зону.
Откройте интерфейс управления DNS Server.
Щелкните на нухном сервере, чтобы выделить его.
Вызовите меню Действие или контекстное меню выбранного сервера и выберите команду Создать новую зону, которая запускает мастер создания зоны.
Щелкните на кнопке Далее и сообщите мастеру, что вы создаете обычную основную зону. Ее можно интегрировать в Active Directory позже, а таким способом вы сможете проанализировать файлы зон. Щелкните на кнопке Далее.
Выберите из предлагаемых вариантов создание зоны прямого просмотра. Щелкните на кнопке Далее.
Введите имя домена DNS. В реальном случае это имя, на использование которого вы имеете официальное Право, если вы подключаетесь к общей сети. Щелкните на кнопке Далее.
Для файла зоны можно использовать имя, отличное от предлагаемого по умолчанию (в данном случае test. example. net. dns). Учтите, что можно также импортировать существующий файл зоны. Примите имя, предлагаемое по умолчанию, шелкните на кнопке Далее, а затем — на кнопке Готово.
Это не должно занять много времени. Если раскрыть узел Зоны прямого просмотра, можно увидеть только что созданную зону. Создание дополнительных зон так же просто, с той разницей, что надо ввести не- которчто дополнительную информацию, например о том, где содержатся данные зоны.
Запустите мастер создания зоны, как описано выше.
Щелкните на кнопке Далее и сообщите мастеру, что бы создаете обычную дополнительную зону. Шелкните на кнопке Далее.
Из предлагаемых вариантов выберите создание обычной дополнительной зоны. Щелкните на кнопке Далее.
Введите имя домена DNS. Поскольку это дополнительная зона, имя будет таким же, как и у основной зоны. Шелкните на кнопке Далее.
Введите 1Р-адрес(а) серверов DNS, которые будут основными при передачах в эту дополнительную зону; или, если это серверы DNS, настроенные на консоли управления DNS, шелкните на кнопке Обзор и выберите их. После ввода всех основных серверов убедитесь, что их порядок соответствует вашим требованиям.
Шелкните на кнопке Далее, а затем — на кнопке Готово. Мастер не позволяет выбрать имя файла; его можно изменить только впоследствии, если вас не устраивает предлагаемое по умолчанию имя.
Создание зон обратного просмотра протекает так же просто, с той разницей, что они обозначаются обращенным IP-адресом сети.
Для этого выполните следуюшие действия.
Запустите мастер создания зоны, как описано выше.
Щелкните на кнопке Далее н сообщите мастеру, что вы создаете обычную основную зону. Щелкните на кнопке Далее.
Из предлагаемых вариантов выберите создание зоны обратного просмотра. Шелкните на кнопке Далее.
Введите IP-адрес, как это делается в наименовании сети. Например. 10.10 будет использовать часть диапазона IP класса А, поскольку он применяется в сети 10.10.0.0/16. Учтите, что эта операция генерирует имя зоны. Щелкните на кнопке Далее.
Здесь снова можно выбрать имя файла, .отличное от предлагаемого, но шелкните на кнопке Далее, а затем — на кнопке Готово.
Теперь у вас есть зона обратного просмотра, которая будет обслуживать адреса в диапазоне 10.10.0.0 - 10,10.255.255 и будет отображаться в составе узла Зоны обратного просмотра.
Если щелкнуть на любой из новых зон, так что ее записи ресурсов будут отображены на панели содержимого, можно увидеть, что каждая зона содержит две записи ресурсов. Это начальная запись (SOA) и запись сервера имен (NS), которые обе указывают на ваш сервер. В поле ответственного лица записи SOA указана учетная запись, которую вы используете.
Если посмотреть в каталог ^winciir%\ systeir.32\dns, там можно об- наружшъ новые файлы зон. В разделе реестра HKLM \ Sys tem\Cur rentControl Set \ Services \DNS\ Zones можно найти подразделы для этих зон, включая те, где записаны имена их фашов. Наконец, если открыть загрузочный файл в каталоге 宅windir暂\system32\dns, можно увидеть, что это содержащий минимум настроек файл NAMED.BOOT с той особенностью, что в нем нет директивы directory.
Дополнительные зоны выглядят несколько по-иному, поскольку мастер запрашивает у вас 1Р-адрес(а) главного сервера (или серверов) DNS. Эти машины являются источниками данных при передаче зоны. Перед созданием зоны и ее заполнением посредством передачи следует делегировать или по крайней мере гарантировать, что серверу, содержащему новую дополнительную зону, будет разрешено его назначенным главным сервером (или серверами) принимать передачу. Вы можете избежать формального делегирования, если хотите, чтобы новая дополнительная зона не обнаруживалась при запросах. Как будет показано при обзоре свойств зоны, в Windows 2000 поЯностью реализованы уведомление и добавочная передача IXFR. Возможно, вы захотите настроить уведомление для дополнительной зоны на главный сервер. Если для зоны разрешено динамическое обновление, преимущества уведомления имеют очень большое значение.
Передачи зон и другие свойства
Обратившись к свойствам зоны прямого просмотра, можно увидеть диалоговое окно, изображенное на рис. 11.7, Две его в кладки, Начальная запись зоны и Серверы имен, уже были описаны в главе 4, ''Подробная информация о домене".
Вкладка WINS (и WINS-R для зон обратного просмотра) также рассматривается в главе 4; использование служб DNS в этом аспекте отражено в главе 16, "WINS: традиционные службы имен и разрешение1'. Каждая из этих вкладок связана почти исключительно с одним типом записи ресурсов. Поэтому не будет лишним взглянуть на две оставшиеся вкладки.
Иня файле зоны;Иня файле зоны;Дла натройкх сеойста<!^«™<о"уе1фвейк<хсдгеое.：но»я«8»нижа^3'а>с«е*'л・。.<■■Дла натройкх сеойста<!^«™<о"уе1фвейк<хсдгеое.：но»я«8»нижа^3'а>с«е*'л・。.<■■:Отмена：'： I Г^мнант !:Отмена：'： I Г^мнант !
Иня файле зоны;
Иня файле зоны;
Дла натройкх сеойста<!^«™<о"уе1фвейк<
хсдгеое.：но»я«8»нижа^3'а>с«е*'л・。.<■■
Дла натройкх сеойста<!^«™<о"уе1фвейк<
хсдгеое.：но»я«8»нижа^3'а>с«е*'л・。.<■■
:Отмена：'： I Г^мнант !
:Отмена：'： I Г^мнант !
lest.example net - свойства
йвмяа {Начальная вались эк» 1： C^)eapj>«»i! W№| Перадаыияон|
Состояние
Рис. 11.7. Вкладка Общие диалогового окна Свойства зоны прямого просмотра
Общие настройки
По умолчанию обычные зоны создаются с отключенным динамическим обновлением DNS. Включение этой функции производится простой установкой переключателя Разрешить динамические обновления? в положение Да ”з положения Нет и при5)енением изменений. Если создается зона, интегрированная в Active Directory, этот переключатель по умолчанию стоит в положении Только безопасные обновления, что невозможно без интеграции. В главе 7 довольно подробно излагаются вопросы, связанные с хранением данных в Active Directory.
Во вкладке Общие можно видеть текущее состояние зоны; приостанавливать и возобновлять ее работу, что позволяет производить более тонкую регулировку, чем при останове и перезапуске на уровне сервера. Тип зоны говорит, является ли она обычной основной или дополнительной или же интегрирована в Active Directory; кнопка Изменить открывает Диалоговое окно, в котором можно изменить тип. Обратите внимание на кнопку Очистка. На рис. 7.1 показаны возможные параметры очистки зоны от устаревших записей, которые вызываются этой кнопкой.
Если используются DDNS и зашита обновлений, очень вероятно, что записи, которые в ином случае были бы бесполезными, будхт оставаться В файлах зон. Эти записи могут быть вредными, мешаюшими регистрации, а также замедлять обработку запросов из-за увеличения размера зоны. Болес подробно очистка рассматривается в главе 7.
Передачи зон
Во вкладке Передачи зон можно настроить характеристики как типа передачи зон, так и безопасности При них. На рис. JO. 1 показана эта вкладка, а на рис. 11,8 — диалоговое окно Уведомление, которое поя вл я- ется при щелчке на кнопке Уведомить в этой вкладке и содержит на- стройки функции уведомления. NT 4.0 также имеет функцию уведомления, но, поскольку в этой системе передачи зон не являются добавочными, этой функцией пользоваться неудобно.
Увепомпение
Дляш^онагичео^ьпадмчпвния хюполним、них cwepoe при ：н»шненииз>М1усга>«гаи1е флсжши ушмгв шрвары
p 繚 ^1?2££^$£9^£^且
"'л.г.^-ЯеддвмялткСТйвейысомрвиицисоротроеигэдн.:
「Зелига агаивннвв иртеры
Оптика " J
Рис. 11.8. Диалоговое окно Уведомление
В самой вкладке передачи зон мохно запретить, сбросив флажок Разрешить передачи зон. Если они разрешены, можно дать список IP- адресов серверов, которым будет разрешено принимать передачи зон, или разрешить передачи на любой сервер или же только на машины, представленньге в зоне записями NS. Настройками уведомления (на рис. 11.8) можно запретить уведомления или, разрешив их, направлять соот- ветствующие сообщения либо на машины, представленные записями NS, либо на серверы из отдельного списка.
Windows 2000 DNS Server всегда может производить добавочные передачи зон. Это зависит от того, принимает ли он требование AXFR (на полную передачу зоны) или IXFR (на добавочную передачу). Если пришло требование на добавочною передачу зоны, сервер DNS выполняет ее при условии, что разница в версиях не слишком большая. Если журнал изменений сервера DNS не может принять требование IXFR. поскольку какие-то изменения "не влезают1' в него, выполняется полная передача с помощью директив AXFR. Такая оптимизация процесса передачи имеет большое значение для зон, разрешенных для динамического обновления.
При настройке параметров уведомления не забудьте разрешить передачу для своих серверов (т.е. внесите их в список), чтобы они могли принимать передачи зон, и настройте уведомление на каждом сервере, который играет роль главного.
Делегирование и субдомены
Делегирование на консоли управления DNS выполняется почти так же, как и создание зоны. Теперь, когда у нас работает основной сервер DNS с основным авторитетом для test.example.net, посмотрим, что можно сделать с ним. На рис. 11.9 показано контекстное меню основной зоны. Контекстное меню дополнительной зоны немного отличается, поскольку ее сервер не имеет полномочий исходных данных, и поэтому команд создания записей для дополнительной зоны нет, однако вместо них присутствует команда принятия передачи (направления требования 1XFR),
Рис. 11.9. Команды меню основной зоны
, На рис. 11.9 домен example.net не имеет субдоменов и поэтому не раскрывается. Вы можете создать в своем домене некоторое число завм- i симых доменов и получить несколько другую картину.
:Проанализировав контекстное меню, можно найти в нем несколько
'команд создания новых записей и еще две команды под названиями I Создать домен и Создать делегирование. В следующем разделе объясняется, что эти команды означают и чем они отличаются друг от друга.
Создание домена DNS
После вызова команды Создать домен появляется диалоговое окно с предложением ввести имя нового домена, и на этом все заканчивается, В главе 4 упоминалось о создании субдоменов. Эта команда создает раздел пространства имен без делегирования.
Откроите консоль управления DNS Server и раскройте сервер, на котором должен быть задан новый домен.
Выделите основную зону, в которой будет создан домен (напрлмер, на example.net, чтобы создать west.example.net) и в контекстном меню зоны (щелчок правой кнопкой мыши) выберите Создать домен.
В диалоговом окне Создание домена введите имя домена. В примере из предыдущего пункта это может быть west (без точки).
Щелкните на ОК, и новая папка должна появиться в виде узла в составе зоны,
Вмзвав команду Создать домен, надо ввести одно допустимое имя (метку) без завершающей точки, т.е. west, но не west. или west, example . net, чтобы кнопка ОК стала доступной. После щелчка на ней возникает новая папка с этим именем в составе узла зоны. Эта папка пуста. Если теперь создать запись А для машины в новом субдомене, под именем, например. Bldl2-rl023, она появится в папке west. Обновите файл сервера на диске и найдите фа)1л зоны example .net — в нем будет зарегистрирована новая запись А с именем Bldl2-rl023. west.
Создание делегирования DNS
Команда Создать делегирование используется для создания делегированного субдомена, включающего запись NS. Эта запись определяет машину, которая будет отвечать на запросы по этому домену. Данная команда запускает мастер создания делегирования. В первом диалоговом окне, как и при создании домена, надо ввести единственное имя (метку) без завершающей точки. Это будет имя нового субдомена в составе узла, который вы выбрали для делегирования.
Откройте консоль управления DNS Server и раскройте сервер, на котором должен быть задано новое делегирование.
Установите фокус на основную зону, в которой будет определено делегирование (например, на example.net, чтобы создать east. example .net) и в контекстном меню зоны (щелчок правой кнопкой мыши) выберите Создать делегирование.
В мастере создания делегирования щелкните на кнопке Далее. В диалоговом окне Имя делегированного домена введите имя нового домена, В примере нз предыдущего пункта это может быть east (без точки). Заметьте, что полностью уточненное доменное имя (FQDN) делегированного домена появится в сером текстовом поле. Щелкните на кнопке Далее.
!
д Теперь надо указать серверы имен, которые будут обслуживать домен. Щелкните на кнопке Добавить и откройте диалоговое окно Запись нового ресурса для создания записей NS.
Щелкнув на кнопке Обзор, найдите записи А или CNAME маши' ны (или машин) или введите их IP-адреса по одному. Каждое введенное имя адрес соответствует новой записи NS в делегированном домене.
Щелкните на кнопке Далее, а затем — на кнопке Готово, чтобы закрыть мастер. Узел нового домена должен появиться в составе узла, для которого была вызвана команда Создать делегирование, |Т*"- После того как было задано имя суб домена, можно ввести любое ко- Отчество серверов, которым будут переданы полномочия (не полномочия ^：йсходных данных). Серверы вводятся либо по FQDN, либо по IP-адресу, !%扭)легче использовать функцию обзора, чтобы найти записи А или 『NAME сервера (или серверов) DNS в базе данных серверов, подклю- ^'.ченной к консоли управления. Каждый добавленный сервер получает за~ Лиси NS в новом домене. После завершения работы мастера появляется ))0вая подпапка с характерным значком, которую можно раскрыть и про- \рмотреть записи NS. Консоль управления DNS Server не позволяет добавлять записи в новый узел. Делегирование создает связующие записи в 'родительской зоне в предположении, что зона будет на одном из делегированных серверов.
Записи ресурсов
В главе 4 подробно рассматриваются основные типы записей ресурсов, а информацию об остальных можно найти в приложении Е, ''Записи ресурсов и файл кэша InlerNIC". Поскольку в главе 4 имеются изображения диалоговых окон и вводимую информацию так легко предсказать, эта глава не описывает ручного создания записей ресурсов в основных зонах. Большая часть команд создания записей открывает простое диа- .лотовое окно, в котором собраны важнейшие параметры записи, а по остальным обычно делаются разумные предположения. После создания записи диалоговое окно остается открытым, что позволяет сразу же создать следующую запись.
_ Несколько часто используемых записей ресурсов имеют команды для своего создания в контекстном меню, которое можно вызвать, когда фокус находится на основной зоне или внутри нее. Одна из команд. Другие 'новые записи, позволяет выбрать почти любой из указанных в RFC типов записей (кажется, тип DNAME отсутствовал в начальной версии Windows 2000, когда мы готовили книгу к печати) и несколько неупомянутых в . RFC (по крайней мере, на этот момент, как, например, поддержка ATM).
Вспомните, что зону, которая хранится в файле, всегда можно остановить и отредактировать. Просто сначала удостоверьтесь, что все кэшированные обновления "'выжаты?, на диск и что номер версии увеличился, прежде чем перезапустить зону и перенести изменения. У опытного администратора все это входит в привычку.
Интеграция в Active Directory
Использование Active Directory для хранения зоны влечет за собой множество последствий, довольно подробно описанных в главе 7. Поскольку изменить режим хранения зоны очень просто (щелчком на кнопке Изменить во вкладке Общие свойств зоны, см. рис. 11.7), также легко забыть об этих последствиях и новых вариантах действий, которые можно, а иногда и нужно выполнить.
После интеграции данные зоны хранятся в Active Directory, как показано на рис. 11.10. На этом рисунке изображена консоль управления Active Directory: пользователи и компьютеры с раскрытым контейнером MicrosoftDNS. (Должен быть включен режим Расширенный.)
:守 Йонсол «Зою ,£тр8ека.:守 Йонсол «Зою ,£тр8ека.,Действие вял Структура I,Действие вял Структура IS3 Е呻口昼й 电33心▽@ -S3 Е呻口昼й 电33心▽@ -江_1江_1.•■ —IComwJters jfJ，xd Doman CoM,o«e”：* __I ForeignSet4i'HyPfin(- _I Svstem:；.•■ —IComwJters jfJ，xd Doman CoM,o«e”：* __I ForeignSet4i'HyPfin(- _I Svstem:；_I AdmmSOHolde"_l DfSJ^Qntiquio'ion_J FiieLink:_l l₽ Seen-if, MaesoPzS_I AdmmSOHolde"_l DfSJ^Qntiquio'ion_J FiieLink:_l l₽ Seen-if, MaesoPzS_i e.omo'e? loc_l Ponces_I RAS and IAS Sei_i e.omo'e? loc_l Ponces_I RAS and IAS Sei♦ _I RpcSeMces♦ _I WinSocJ.Service♦ _I RpcSeMces♦ _I WinSocJ.Service-刘 TestUsers-刘 TestUsers.且 _gc」cp Cie)null-Fusl-Sfie-Nonie _s«es_herberos Jcpp] _keroeros jcp 尢一mwdEW _kerberc^ icp DelaiiM-Fnsi-S.ie-Nan'e s«es oc1 _kpe$swd jcp1 Jpesswfl 一udp❷ jaep jcp・]_ldap_тр 133ei&；"b36M86ro709"de6s333c5y] _ldop _'cp de _msd?s.]_^dnp jcp Deieui'-Fusi Sne+eme 一sees]_iaan Jcp Delaul:-Frrsl-5ne-Name _s“es de _m J 回 _ldap」cp DelBuh-Ffrbf-Site-Name _s"es gc a j ■]」dep Jcp gc 一msdesI *1 IdoD tco gwcbuilding _irtes.且 _gc」cp Cie)null-Fusl-Sfie-Nonie _s«es_herberos Jcpp] _keroeros jcp 尢一mwdEW _kerberc^ icp DelaiiM-Fnsi-S.ie-Nan'e s«es oc1 _kpe$swd jcp1 Jpesswfl 一udp❷ jaep jcp・]_ldap_тр 133ei&；"b36M86ro709"de6s333c5y] _ldop _'cp de _msd?s.]_^dnp jcp Deieui'-Fusi Sne+eme 一sees]_iaan Jcp Delaul:-Frrsl-5ne-Name _s“es de _m J 回 _ldap」cp DelBuh-Ffrbf-Site-Name _s"es gc a j ■]」dep Jcp gc 一msdesI *1 IdoD tco gwcbuilding _irtesonsZoae 6\szo“e dns№oe dcsZodeonsZoae 6\szo“e dns№oe dcsZodednsNode dnsNoCednsNode dnsNoCedcsZode dcsZode "sZode SsZgedcsZode dcsZode "sZode SsZgedemode SsZode aniNoOe Snsf-onedemode SsZode aniNoOe Snsf-onecnsZoae c”sZodecnsZoae c”sZodeJ ■] dop icp gwcbuiiamg svmsdc msdeJ ■] dop icp gwcbuiiamg svmsdc msdedn，NodessNotfe一二产dn，NodessNotfe一二产
:守 Йонсол «Зою ,£тр8ека.
:守 Йонсол «Зою ,£тр8ека.
,Действие вял Структура I
,Действие вял Структура I
S3 Е呻口昼й 电33心▽@ -
S3 Е呻口昼й 电33心▽@ -
江_1
江_1
.•■ —IComwJters jfJ
，xd Doman CoM,o«e”
：* __I ForeignSet4i'HyPfin(
- _I Svstem:；
.•■ —IComwJters jfJ
，xd Doman CoM,o«e”
：* __I ForeignSet4i'HyPfin(
- _I Svstem:；
_I AdmmSOHolde"
_l DfSJ^Qntiquio'ion
_J FiieLink:
_l l₽ Seen-if, MaesoPzS
_I AdmmSOHolde"
_l DfSJ^Qntiquio'ion
_J FiieLink:
_l l₽ Seen-if, MaesoPzS
_i e.omo'e? loc
_l Ponces
_I RAS and IAS Sei
_i e.omo'e? loc
_l Ponces
_I RAS and IAS Sei
♦ _I RpcSeMces
♦ _I WinSocJ.Service
♦ _I RpcSeMces
♦ _I WinSocJ.Service
-刘 TestUsers
-刘 TestUsers
.且 _gc」cp Cie)null-Fusl-Sfie-Nonie _s«es
_herberos Jcp
p] _keroeros jcp 尢一mwdE
W _kerberc^ icp DelaiiM-Fnsi-S.ie-Nan'e s«es oc
1 _kpe$swd jcp
1 Jpesswfl 一udp
❷ jaep jcp
・]_ldap_тр 133ei&；"b36M86ro709"de6s333c5
y] _ldop _'cp de _msd?s
.]_^dnp jcp Deieui'-Fusi Sne+eme 一sees
]_iaan Jcp Delaul:-Frrsl-5ne-Name _s“es de _m J 回 _ldap」cp DelBuh-Ffrbf-Site-Name _s"es gc a j ■]」dep Jcp gc 一msdes
I *1 IdoD tco gwcbuilding _irtes
.且 _gc」cp Cie)null-Fusl-Sfie-Nonie _s«es
_herberos Jcp
p] _keroeros jcp 尢一mwdE
W _kerberc^ icp DelaiiM-Fnsi-S.ie-Nan'e s«es oc
1 _kpe$swd jcp
1 Jpesswfl 一udp
❷ jaep jcp
・]_ldap_тр 133ei&；"b36M86ro709"de6s333c5
y] _ldop _'cp de _msd?s
.]_^dnp jcp Deieui'-Fusi Sne+eme 一sees
]_iaan Jcp Delaul:-Frrsl-5ne-Name _s“es de _m J 回 _ldap」cp DelBuh-Ffrbf-Site-Name _s"es gc a j ■]」dep Jcp gc 一msdes
I *1 IdoD tco gwcbuilding _irtes
onsZoae 6\szo“e dns№oe dcsZode
onsZoae 6\szo“e dns№oe dcsZode
dnsNode dnsNoCe
dnsNode dnsNoCe
dcsZode dcsZode "sZode SsZge
dcsZode dcsZode "sZode SsZge
demode SsZode aniNoOe Snsf-one
demode SsZode aniNoOe Snsf-one
cnsZoae c”sZode
cnsZoae c”sZode
J ■] dop icp gwcbuiiamg svmsdc msde
J ■] dop icp gwcbuiiamg svmsdc msde
dn，Node
ssNotfe
一二产
dn，Node
ssNotfe
一二产
Рис. 11.10. Данные зоны в Active Directory
Как можно видеть, отображение данных на этой консоли плоское, а не структурированное по доменам. Это вид только для чтения, за исключением спецификаторов безопасности, которые можно изменять. Видимость даннь(х свидетельствует о том, что они доступны для запросов LDAP, Эта доступность для LDAP может обесценить все ваши попытки защитить данные зон и передачи, если вы не будете внимательны.
О других аспектах интегрирования зон в режим каталога можно узнать из главы 7. Однако там не рассматриваются многие другие вопросы, затрагивающие механизм и сеть репликации и размещение серверов DNS на контроллерах домена. Эти проблемы частично решаются в главе 9. Все эти ссылки служат лишь напоминанием о том, что это простое переключение вовсе не так просто.
пы серверов
< Поскольку информация о них разбросана по предыдущим разделам, в 1 этом разделе лишь очень кратко перечисляются параметры, необходимые -с целью настройки сервера для работы различного рода.
Использование пересылки
Как было сказано выше, узлы пересылки настраиваются на уровне сервера в свойствах сервера. Windows 2000 DNS Server посылает на эти машины рекурсивные запросы. На остальные серверы DNS Windows 2000 DNS Server всегда посылает итеративные запросы.
Пересылку можно использовать в нескольких конфигурациях, приведенных ниже. Пересылающий сервер DNS может (или не может, в зависимости от настройки) также начинать самостоятельные попытки разрешения принятого им запроса после того, как он отправит его пересылочному серверу. Если ему не запрещено, Windows 2000 DNS Server начинает обрабатывать запрос самостоятельно, после того как период ожидания ответа от пересылочного сервера закончится.
Серверы только для кэширования
Сервер DNS, предназначенный только для кэширования, не имеет основной илм дополнительной зоны. Он полагается исключительно на услуги других серверов DNS и кэширует результаты их работы для неавторитетных ответов на последующие запросы. В стандартной исходной конфигурации Windows 2000 DNS Server не имеет зон и содержит файл корневых ссылок, предназначенный для работы в Internet. Отсюда следует, что в исходной конфигурации он может работать как сервер только для кэширования.
Для завершения конфигурации кэширующего сервера можно сделать еше две вещи. Во-первых, если сервер используется во внутренней DNS, конечно, потребуется соответственно изменить файл корневых ссылок. Во-вторых, неплохо было бы указать серверу использовать конкретные машины, которые во всех случаях выбираются по соображениям близости, а в случае внутренней сети — для пространства имен, которое должно разрешаться.
Подчиненные серверы
Здесь имеются в виду не подчиненные серверы при передачах зон, а серверы DNS, настроенные так. чтобы работать только с узлами пересылки. Они отличаются от серверов, выделенных только для кэширова-
ния, тем, что не могут сами пытаться разрешить приходящие запросы, а должны обязательно пересылать их. Чтобы сделать сервер DNS подчиненным, сначала укажите для него пересьшочные узлы. Затем установите флажок Не использовать рекурсию во вкладке Пересылка свойств сервера. Подобный, однако менее эффективный результат можно получить, так изменив файл корневых ссылок, чтобы этот сервер "знал" только о себе самом, как это сделано на некоторых серверах UNIX.
Авторитетные подчиненные серверы
За неимением лучшего термина эта конфигурация называется авторитетным подчиненным сервером. Она очень напоминает только что описанный подчиненный сервер. Различие состоит в том, что этот сервер DNS имеет также делегированные ему основную и/или дополнительную зоны. В этой конфигурации используются узлы пересылки и полученные ими результаты кэшируются. Но если запрос относится к узлу в пределах авторитета этого сервера, он отвечает на него авторитетно из данных зоны. В противном случае ответ на запрос возвращается, только если пересылочные узлы могут разрешить этот запрос. Иными словами: если флажок Не использовать рекурсию установлен, у сервера еше есть возможность давать авторитетные ответы.
Итеративные за叩осм
По умолчанию сервер DNS Windows 2000 принимает как итеративные, так и рекурсивные запросы. Это поведение можно изменить так, чтобы принимались только итеративные запросы. Для этого установите флажок Отключить рекурсию во вкладке Дополнительно свойств сервера. Итеративный сервер меньше загружается и поэтому имеет увеличенную емкость. Итеративные серверы заслуживают внимания в случае таких целей, как сервер DNS для представительства в обшей сети, поскольку эта конфигурация укрепляет сервер от атак, основанных на перегрузке сервера.
Чистота зоны
Динамическое обновление порождает некоторые проблемы. Вероятно, самая важная из них после проблем безопасности — это управление содержимым зоны. Важно подчеркнуть, что функция очистки, встроенная в Windows 2000 DNS Server, может причинить вам очень существенные неприятности, если вы попытаетесь использовать ее, не взвесив сначала всех последствий. Перечитайте главу 7, прежде чем решиться применить параметры очистки, описанные в этой главе.
Поддерживаемые функции
Сервер DNS в Windows 2000 способен работать самостоятельно, не создавая проблем, довольно продолжительный срок. Однако его работа требует некоторого надзора, и поэтому надо рассмотреть основные возможности выполнения такого контроля.
Ведение журнала
Надзор за работой вашего сервера должен быть постоянным. При первой настройке служб DNS это особенно важно; здесь вы должны по- лучить представление о том, как сильно загружены серверы и обнаружить любую большую или малую проблему.
Мы уже видели вкладку Ведение журнала в свойствах сервера. Было бы гораздо лучше, если бы эта функиия была реализована на уровне зоны, но и в таком состоянии она способна дать вам ценную информацию. Эта функция также относится к числу тех, которые надо использовать с осторожностью, особенно на сильно загруженных серверах. Она не только замедляет работу, но и заставляет сервер очень быстро генерировать большие файлы.
Мы еше не указывали на функцию просмотра событий Windows, которая в Windows 2000 содержит новый журна.1 событий DNS. На рис. 11.11 показана открытая консоль Управление компьютером. Журнал событий DNS — место, за которым не мешает постоянно следить, поскольку здесь отражается любая серьезная проблема. Однако не надейтесь на него как на эталон для настройки емкости и производительности системы.
|3 Управпенке компьютером|3 Управпенке компьютеромЛ^стаие &uЛ^стаие &u6*由国一出日區仅6*由国一出日區仅乱 Угравла-Ф^ кслтьютером ±. % Служебные прстраммы-Просмотр .-сттлич Ы Г^'_ю*е>«е 白 Drectory Service 独 DNS Server 回 Спухба pensm ；： И Бемлхмхть 1-1 Система■善 Свейегча。сктеме午 囹 Оповещения “ журча .■i. Vj Общие папки,j^ Диспетчер vcnx^Ti ■：•： DoKaibwe nwbjceai-匕 Загк**иэоши? успхмс Ynpwneme дисками」Ь Петмментац”я дк, 8 Логические дмз 3r乱 Угравла-Ф^ кслтьютером ±. % Служебные прстраммы-Просмотр .-сттлич Ы Г^'_ю*е>«е 白 Drectory Service 独 DNS Server 回 Спухба pensm ；： И Бемлхмхть 1-1 Система■善 Свейегча。сктеме午 囹 Оповещения “ журча .■i. Vj Общие папки,j^ Диспетчер vcnx^Ti ■：•： DoKaibwe nwbjceai-匕 Загк**иэоши? успхмс Ynpwneme дисками」Ь Петмментац”я дк, 8 Логические дмз 3r•УУ*АОМЛО<19 Л^УВ^ДОмлечия Дгьедупреждаие ^Уведсмлегмя Л)Уведомление•У Уведомления ^Уведомления-У Уведомления Л)Уездом ленив ◊Уведом печ^я Л)Уб₽дС«летч Ч)7в»домла-ия△吋 Ат*А«н« бнеломле^мп•УуведсмлежА 6П5еауПХжде«*•УУ*АОМЛО<19 Л^УВ^ДОмлечия Дгьедупреждаие ^Уведсмлегмя Л)Уведомление•У Уведомления ^Уведомления-У Уведомления Л)Уездом ленив ◊Уведом печ^я Л)Уб₽дС«летч Ч)7в»домла-ия△吋 Ат*А«н« бнеломле^мп•УуведсмлежА 6П5еауПХжде«*
|3 Управпенке компьютером
|3 Управпенке компьютером
Л^стаие &u
Л^стаие &u
6*由国一出日區仅
6*由国一出日區仅
乱 Угравла-Ф^ кслтьютером ±
. % Служебные прстраммы
-Просмотр .-сттлич Ы Г^'_ю*е>«е 白 Drectory Service 独 DNS Server 回 Спухба pensm ；： И Бемлхмхть 1-1 Система
■善 Свейегча。сктеме午 囹 Оповещения “ журча .
■i. Vj Общие папки
,j^ Диспетчер vcnx^Ti ■
：•： DoKaibwe nwbjceai
-匕 Загк**иэоши? успхмс Ynpwneme дисками」
Ь Петмментац”я дк, 8 Логические дмз 3r
乱 Угравла-Ф^ кслтьютером ±
. % Служебные прстраммы
-Просмотр .-сттлич Ы Г^'_ю*е>«е 白 Drectory Service 独 DNS Server 回 Спухба pensm ；： И Бемлхмхть 1-1 Система
■善 Свейегча。сктеме午 囹 Оповещения “ журча .
■i. Vj Общие папки
,j^ Диспетчер vcnx^Ti ■
：•： DoKaibwe nwbjceai
-匕 Загк**иэоши? успхмс Ynpwneme дисками」
Ь Петмментац”я дк, 8 Логические дмз 3r
•УУ*АОМЛО<19 Л^УВ^ДОмлечия Дгьедупреждаие ^Уведсмлегмя Л)Уведомление
•У Уведомления ^Уведомления
-У Уведомления Л)Уездом ленив ◊Уведом печ^я Л)Уб₽дС«летч Ч)7в»домла-ия
△吋 Ат*А«н« бнеломле^мп
•УуведсмлежА 6П5еауПХжде«*
•УУ*АОМЛО<19 Л^УВ^ДОмлечия Дгьедупреждаие ^Уведсмлегмя Л)Уведомление
•У Уведомления ^Уведомления
-У Уведомления Л)Уездом ленив ◊Уведом печ^я Л)Уб₽дС«летч Ч)7в»домла-ия
△吋 Ат*А«н« бнеломле^мп
•УуведсмлежА 6П5еауПХжде«*
Рис. 11.11. Журнал событий сервера DNS
Наиболее просто добраться до консоли Управление компьютером по команде Управление в контекстном меню Мой компьютер или введя в командной строке compmgmt .msc. Заметьте, что на рис. 11.11 раскрыты узлы Служебные программы и Просмотр сюбытий, а фокус установлен на пункт DNS Server, что отображает журнал событий DNS на панели содержимого. Прокрутив панель Структура вниз, до узла Службы и приложения, можно раскрыть его и убедиться, что на консоль Управление компьютером в виде интегрированного приложения загружен полный доступ к интерфейсу управления DNS.
Статистика и наблюдение
Если вы новичок в Windows NT и 2000, вы можете не оценить всего значения Системного монитора. Он запускается командой Системный монитор в папке Администрирование или вводом perfmon.msc в командной строке. В NT 4.0 этот инструмент назывался монитором производительности. Монитор работает в трех режимах: текущих событий, журнала и оповещений. Если щелкнуть на большом значке "гтюс" (+), который добавляет в гистограмму счетчики, появится диалоговое окно, в котором надо сначала выбрать интересуюший вас объект, в данном случае DNS, а в этом объекте — счетчики, которые булут использоваться.
Можно записывать в журнал объекты целиком для последующего просмотра. Очень ценным представляется то, что можно запрограммировать условия, которые буаут вызывать появление сообщении журнала событий. Далее, если у вас есть инструменты, подобные тем, что предоставляет Сервер управления системой {System management Server, SMS), эти сообщения могут запускать программируемые действия, отправлять по электронной почте сообщения и т.д.
Чтобы привлечь вас к исследованию всего многообразия сведений, которые можно получить через объект DNS, в табл. 3.3 мы поместил” список этих счетчиков. Просмотрев этот список, можно заметить, что легко установить наблюдение за использованием памяти, чтобы определить, в какой степени ваш сервер наделен этим, таким важным для серверов DNS, ресурсом. Наборы счетчиков уведомлений, IXFR, AXFR и передач дают возможность заглянуть в процессы передачи зон и установить, превращаются ли добавочные передачи (IXFR) в полные (AXFR), в предположении, что изначально запрашиваются только добавочные передачи. Счетчики динамических и безопасных обновлений дают информацию об интенсивности динамического управления зоной. Другие счетчики можно использовать для слежения за нагрузкой сервера от запросов и т.д.
Общее число полученных запросов Общее число полученных запросев/с Получено UDP-запросов Получено UDP-запросов/с
Получено ТСР-запросов Получено ТСР-запросов/с Отправлено всего ответов Отправлено всего ответов/с Отправлено UDP-ответов Отправлено UDP-ответов/с Отправлено ТСР-ответов Отправлено ТСР-отаетов/с Рекурсивных запросов Рекурсивных запросов/с Рекурсивных тайм-аутов отправления Рекурсивных тайм-аутов отправления/с Рекурсивных ошибок запросов Рекурсивных ошибок запросов/с Отправлено уведомлений
Получено запросов передач зоны Успешных передач зоны Неудачных передач зоны Получено запросов AXFR Отправлено AXFR-успехов Получено запросов IXFR Отправпено IXFR-успехов
Получено уведомлений
Отправлено запросов SOA передач зоны Отправлено запросов AXFR Получено ответов AXFR
Получено AXFR-успехов
Отправлено запросов IXFR
Получено ответов IXFR
Получено IXFR-успехов
Получено IXFR UDP-успехов
Получено IXFR ТСР-успехов
Получено запросов просмотра WINS
Получено запросов просмотра WINS/сек
Отправлено ответов WINS
Отправлено ответов WINS/сек
Получено запросов обратного просмотра WINS
Получено запросов обратного просмотра WINS/c Отправлено ответов обратного просмотра WINS Отправлено ответов обратного просмотра WINS/c Получено динамических обновлений
Получено динамических обновлений/с
Пустых динамических обновлений
Пустых динамических обновлений/с
Записано в базу данных динамических обновлений
Записано в базу данных динамических обновлений/с
Отклонено динамических обновлений
Тайм-аутов динамических обновлений
Поставлено в очередь динамических обновлений
Получено безопасных обновлений
Получено безопасных обновлений/с
Ошибок безопасных обновлений
Память узлов в базе данных
Память потока записей
Кэш-память
Память UDP-сообщений
Память ТСР-сообщений
Память Nbstat
Записи DNS Server в реестре
Сервер DNS в Windows 2000 обладает большим количеством разделов реестра; в большей части этих разделов хранятся значения, которые можно изменить на консоли управления DNS. Все они размещаются в разделе реестра HKLM\System\Cur rent Cont го lSet\Ser vices \DNS и его подразделах 'Parameters (глобальные настройки, перечисленные в табл. 11.5) и \zones (настройки зон, перечисленные в табл. 11.4 — по именам FQDN для каждой зоны отдельно).
Таблица 11.4. Разделы реестра DNS)специфические для зоны
Значение
Тип
Чго означает
Aging
Reg_Dword
0 — очистка отключена, 1 — включена
AllowUpdate
Reg_Dword
0 — обновление запрещено, 1 — разрешено. 2 —только безопасное обновление
DatabaseFile
Reg_Sz
Имя файла зоны в %windir%\system32\dns
Dsinteg rated
Reg_Dword
0 — запрещено, 1 — разрешено
MasterServers
Reg_Sz
Список IP-адресов, разделенных пробелами
NoRefreshinterval
Reg_Dword
Интервал блокировки, ч (в шестнадцатеричном формате)
NotifyLevel
Reg_Dword
0 — нет уведомления, 1 —уведомлять серверы NS, 2 — использовать NotifyServers
NotifyServers
Reg_Sz
Список IP-адресов, разделенных пробелами
Refreshinterval
Reg_Dword
Интервал регенерации, ч (в шестнадцатеричном формате)
SecureSecondaries
Reg_Dword
0 — нет, 1 ——серверы NS,
2 — использовать SecondaryServers
Secondary Servers
Reg_Sz
Список IP-адресов, разделенных пробелами
Type
Reg__Dword
0 — зона кэша, 1 — основная, 2 — дополнительная
Значение
Тип
Что означает
BindSecondaries
Reg_Dword
0 — запрещены, 1 —разрешены
BootMethod
Reg_Dword
1 — загрузка из файла, 2 — из реестра, 3 — из Active Directory и реестра
Cleanupinterval
Reg_Dword
Интервал очистки кэша в с (по умолчанию 900)
DisableAuto
ReverseZones
Reg_Dword
0 F — запрещено, 1 Т — разрешено (0 ., 127 ,, 255 . inarp. addr)
Forwarders
Reg__Sz
Список IP-адресов, разделенных пробелами
ForwardingTimeout
Reg__Dword
Срок ожидания ответа при пересылке, с (в шестнадцатеричном формате)
IsSlave
Reg_Dword
0 — нет, 1 — да
ListenAddress
Reg_Sz
Список IP-адресов, разделенных пробелами
NoRecursion
Reg_Dword
0 — принимать рекурсивные запросы, 1 — итеративные
RecursionRetry
Reg_Dword
Интервал повтора рекурсивного запроса, с на каждую попытку (в шестнадцатеричном формате)
RecursionTimeout
Reg_Dword
Срок рекурсивного запроса, всего с (в шестнадцатеричном формате)
PreviousLocal-
HostName
Reg_Sz
Строка-имя узла
Scavenginglnterva!
Reg_Dword
Интервал автоматической очистки, ч (в шестнадцатеричном формате)
SecureResponses
Reg_Dword
0 — запрещено, 1 — разрешено
Резюме
В этой главе мы проанализировали возможности настройки Windows 2000 DNS Server и дали некоторое объяснение важности настройки после инсталляции. Теперь вы должны бьпъ готовы без труда установить сервер DNS и начать заполнение данных зоны. Там, где проблемы требуют более тщательного рассмотрения, даны ссылки на соответствующие главы.
Ill
Поддержка служб DNS в Windows
В этой части...
Средства поиска неисправностей
Рациональные методы работы и обслуживания
Настройка и разрешение клиентов Windows
Службы DHCP в Windows
WINS: традиционные службы имен и разрешение
NetBIOS: традиционные службы имен и разрешение
Рекурсивные запросы
Безопасные обновления■
Полный объем запросов и ответов
Обработка TCP и UDP
WINS
Передачи зон
netmon
Список средств сетево访 диагностики a Windows 2000 и NT был бы неполон без упоминания о Сетевом мониторе. Эта программа позволяе| фиксировать и исследовать коммуникационные пакеты. Несмотря на довольно низкий для регулярного использования уровень, она может быть ценной как при поиске неисправностей, так и для сравнения того, что происходит в системе, с тем, что должно происходить.
Эта программа не входит в число обязательно устанавливаемых компонентов серверных версий Windows, поэтому для ее установки надо выбрать на панели управления аплет Установка/удаление программ, а в нем — команду Установка/удаление компонентов Windows, чтобы запустить мастер компонентов Windows. Как и в NT 4.0, эта версия программы ограничена, чтобы не ввести сетевую карту в беспорядочный режим Если требуется перехватывать больше, чем только пакеты с сервера и на сервер, где установлена программа, нужна версия SMS или программа другого разработчика.
Резюме
Windows 2000 основывается на мощном сетевом базисе и в значительной степени зависит от нормальной работы служб DNS. Неудивительно поэтому, что как количество, так и возможности инструментальных средств в этой системе возросли. В этой главе описаны основные инструменты, предоставляемые Microsoft, а также несколько других. Для основных инструментов описание призвано помочь в их эффективном применении.
Рациональные методы работы и обслуживания
В этой главе...
Совершенствование серверов DNS. В этом разделе излагаются некоторые вопросы, связанные с разработкой более сложной иерархии серверов DNS, и приводятся рекомендации по разработке. К сооб- ражениям, представленным в этом разделе, логически подводит множество вопросов, рассмотренных в других разделах.
Текущий контроль сервера DNS. В этом разделе объясняется, как инстр/ментш1ьнъ[е средства Windows 2000 позволяют бить в курсе всего, что происходит с серверами DNS. их настройки и качества работы.
Изменение IP-адреса зарегистрированного сервера DNS. Этот раздел помажет осознать некоторые важнне аспекты изменения IP-адреса сервера DNS, включая его регистрацию в InterNIC.
Увеличение емкости за счет нового сервера DNS. В этом разделе перечислены этапы встраивания нового сервера DNS в архитектуру сушеств>тоши\ служб DNS и причины, по которым это следует сделать.
Обслуживание данных зоны. Здесь рассматриваются разнообразные вопросы, связанные с обслуживанием зон на серверах DNS н перемещением зон между ними.
Многие решения, определяющие качество работы служб DNS, принимаются на стадии проектирования или при последующем улучшении системы по результатам исследования ее производительности и надежности. Чтобы поддерживать службы при их интенсивной работе или совершенствовать их характеристики в соответствии с изменениями предъявляемых требований, администратор DNS должен постоянно "держать руку на пульсе" установленных серверов DNS, что означает в том числе особое изучение производительности машин, на которых эти серверы DNS установлены. Следует постоянно поддерживать уровень обслуживания программ 11 использовать самые последние обновления, особенно связанные с безопасностью. Р1, конечно, остается обслуживание базы данных DNS. Оно включает ежедневное управление изменениями записей ресурсов, периодическое перемещение зон на другие машины, замену и модернизацию машин, а теперь еше и очистку динамических зон от устаревших записей, чтобы их размер оставался под контролем.
Совершенствование серверов DNS
В этом разделе рассматриваются некоторые способы контроля серверов DNS, Чтобы они были максимально полезными, вы должны "прочувствовать" эти службы. Надо установить определенный уровень производительности и нагрузки в ''обычных'' рабочих ситуациях. Также важно хорошо понимать структуру служб и их возможности. Тогда, если контроль покажет какое-то отклонение от этого уровня, вам не придется "бродить" по схеме системы, пытаясь определить, в чем дело, а надо будет лишь сориентироваться в ней, чтобы подтвердить свои предположения о причинах отклонения и ваших возможных действиях. Такая схема архитектуры ваших служб, висяшая на стене, поможет выяснить, где, какие типы запросов и от кого поступают. Она также должна помочь проследить путь клиента в процессе внутреннего и внешнего разрешения “ указать возможные альтернативные пути.
Наблюдение за производительностью серверов DNS имеет большое значение： оно может показать необходимость точной настройки служб, но и только. Производительность, как ее ошушает конечный пользователь, или распознаватели на других серверах DNS, — это реальный показатель, и его нельзя узнать только из данных журнала сервера. Необходим способ оценки всех факторов системы, включая задержку в сети, которые влияют на предоставляемую пользователю услугу. Это могла бы быть автоматическая выборочная проверка во время нормальной работы или (с меньшей надежностью или пользой) простое внимание к замечаниям пользователей-
[，• Если контроль показывает узкие места или перегрузку отдельных уча- 「tTKOB системы, посмотрите, есть ли простой способ перераспределить Енагрузку. Или, может быть, часть нагрузки можно переложить на другой [сервер? Почему сервер тратит столько циклов, отвечая на требования I^XFR, если все они должны быть 1XFR?
I Политика безопасности была принята во внимание на начальном эта- tie разработки. Но была ли она корректно реализована? Нужен ли про- Ijecc проверки? Или достаточно контроля за изменениями в данных и в йсонфигурации?
口 Время от времени структура системы будет изменяться. Может оказаться, что настройка клиентов для работы непосредственно с основными Серверами, а не дополнительнымн, слишком ограничивает, например, возможности обслуживания зоны или программ вручную. Или использование Internet в деловых операциях увеличивает объем разрешений внешних имен. Или какие угодно влияния могут со временем изменить систему. Если это произошло, вспомните критерии разработки и попытайтесь приспособить окружение к требованиям, которые кажутся вам йаилучшими для работы служб.
“ Рекомендуются следующие критерии,
['■ Легкость в текущем обслуживании и поддержание уровня безопас
ности без ^удшения или перерыва в работе клиентских служб.
г ■ Минимальное, в смысле качества сети, расстояние от клиентов до • серверов, авторитетных для собственных данных клиента и дан- ■, ных, наиболее часто используем]>1Х им.
Минимальная пропускная способность сети, требуемая для пере:дач зон, при максимально быстрой конвергенции данных зоны на
' всех авторитетных серверах.
I ■ Возможность настройки для каждого клиента по крайней мере ' двух путей разрешения, даюших доступ к разрешению как с учетом ! политики безопасности сайта, так и вне ее.
Если перевести эти требования в выбор возможных вариантов на- сгройкл, рекомендации будут звучать так.
I ■ Используйте добавочные передачи (1XFR) с уведомлением.
Ограничивайте передачи, чтобы они происходили исключительно между предназначенными для этого серверами DNS.
■ Дублируйте серверы для всех видов разрешения, как по типу сервера, так и по содержимому зоны.
'■ Размешайте серверы так, чтобы они были локальными (в смысле
качества сети) для своих клиентов.'
Используйте дополнительные серверы для избыточности, распре- г деления нагрузки и освобождения основных серверов от работы с клиентами, особенно, если зоны интегрированы в Active Directory.
Учитывайте недостаток безопасности при динамическом обновлении или используйте хранение в Active Directory, разрешив только безопасные обновления. Разберитесь в том, как назначается владелец записи, и следите за составом группы DNSUpdateProxy (возможно, сделав ее группой с ограниченным доступом), чтобы в нее не попали посторонние машины.
Разрешайте делать запросы на зоны, используемые в поддержке Active Directory, только доверенным клиентам.
Очишайте данные зоны от лишних, ненужных записей ресурсов. Это могут быть неиспользуемые записи CNAME в любых зонах н устаревшие записи — в динамических.
Правильно используйте серверы для пересылки и кэширования: там, где данные зоны не нужны локально, не применяйте их.
Применяйте передовые (bridgehead) передачи между главными сайтами, чтобы дополнительные серверы, локальные для сайта, получали информацию от своих передовых серверов.
Выясните, как влияет интервал блокировки на скорость изменения
Приведите длительность аренды DHCP в соответствие с параметрами очистки (возможно, лаже отрегулируйте значения срока жизни (TTL)), если включено динамическое обновление. Также необходимо знать, как работает механизм владения записью, если сервер DHCP является (или не является) членом группы DnsUpdateProxy.
Разбивайте большие зоны с несколькими субдоменами на отдельные зоны, если можно распределить зону по локальным дополнительным серверам.
Настройте серверы так, чтобы они отклоняли рекурсивные запросы там, где это имеет смысл, например на серверах представительства в обшей сети.
Уменьшайте дополнительную нагрузку на серверы, например за счет отмены упорядочения масок подсети, там, где это не приносит пользы, или уменьшения потребного объема кэша благодаря очистке зон.
Этот список можно продолжать, особенно в отношении конкретные иерархий или типов серверов DNS. Например, для некоторых серверов, уязвимых из-за своего расположения, имеет смысл ограничить использование протокола TCP/IP (и UDP) только необходимыми портами. Будьте готовь( время от времени обращаться к схеме системы и определять ва- рианть( новой настройки.
Текущий контроль сервера DNS
В небольшой корпоративной системе обслуживание DNS относитель- I но просто. С усложнением иерархии переносов и распределения сайтов I может увеличиться количество участков, где система уже не работает [идеально. Чтобы определить, находится ли производительность системы |на оптимальном уровне, надо контролировать и оценивать ее.
Эффективное использование консоли ^правления Microsoft
'「 На этот момент вы уже должны быть знакомы практически с каждым '• элементом управления и параметром консоли управления сервером DNS, Через некоторое время умение запускать и останавливать сервер и от- .,дельные зоны, начинать перезагрузку зоны, синхронизировать зону с данными на диске и обрашаться со множеством других функций станет } для вас второй натурой. Как уже можно заметить, многие серверы на ^консоли можно подключить так, чтобы управлять одновременно группой j серверов. Вероятно, вы уже обнаружили, как легко забыть о необходимо- I сти переключения консоли в режим Расширенный (в меню Вид).
! Также можно было заметить, что консоль Управление компьютером -имеет начальную настройку, даюшхто доступ к журналу событий, серверам DNS、DHCP, WINS и некоторым другим функциям. Но то, чего вы [еше не знаете, — это создание настраиваемых консолей.
! При создании настраиваемой консоли можно выбрать и добавить лю- [бую из оснасток консоли управления Microsoft и их расширений, поэтому !，надо точно знать, что они присутствуют на вашей машине. Самый простой ；путь собрать коллекишо доступных оснасток — инсталлировать Набор ре- [сурсов и Средства администрирования Windows 2000. Л и цензирован ная ко- !Пия набора ресурсов устанавливается при загрузке компакт-диска. Пакет средств администрирования помешается на CD Windows 2000. Программу .установки под названием "SMINPAK.MSI можно найти в каталоге . \i386 } на компакт-диске или в каталоге ^wi^dir? \systen32 установленного сер- FBepa. Как и любой лругоН пакет MSI. ее л\чше всего установить с помо- I шью аплета Установка/удаление программ, но можно также использовать 丨 команду Установить контекстного меню файла MCI. Любой из этих воз- 卜 Можностей можно воспользоваться в версии Professional, с которой вы бу- 〔дете работать для удаленного управления серверами.
! Для создания настраиваемой консоли выполните следующие действия.
I 1. В меню Пуск— Выполнить введите пипс, чтобы вызвать пустую Iконсоль управления.
2. Во всплывающем меню Консоль выберите команду Доба-
[вить/удалить оснастку.
3. Щелкните на кнопке Добавить под списком.
В диалоговом окне Добавить изолированную оснастку выберите оснастки в том порядке, в каком они будут отображены на готовой консоли. Начните с оснастки DNS, выделите ее и щелкните на кнопке Добавить.
Как в п. 4, выберите и добавьте оснастки DHCP и WINS, если они будут использоваться, а также Просмотр событий и Оповещения и журнал производительности. Очень вероятно, что в число применяемых оснасток войдут Маршрутизация и Удаленный доступ. Некоторые оснастки, например Просмотр событий, можно добавить отдельно для локальной машины и отдельно для удаленной. Если оснастка соответствует локальной машине, ее впоследствии можно переориентировать на другую машину с помощью контекстного меню.
После выбора всех необходимых оснасток щелкните на кнопке Закрыть.
Некоторые оснастки имеют зарегистрированные расширения. Перейдите во вкладку Расширения диалоговою окна Доба- вить/удалить оснастку и выберите в раскрывающемся списке Маршрутизация и Удаленный доступ, если эта оснастка была добавлена. Установите флажок напротив расширения Маршрутизация IP. При этом содержимое выпадающего списка обновляется и в пем можно выбрать новый элемент Маршрутизация IP.
После настройки необходимых оснасток щелкните на кнопке ОК. чтобы вернуться в новую консоль.
В меню Консоль вызовите команду Сохранить как и сохраните консоль, указав имя с расширением .MSC и соответствующее расположение (например, на рабочем столе).
В результате этого консоль настраивается в соответствии с вашими желаниями. После этого можно настроить каждую из добавленных оснасток, DNS, DHCP и WINS, для соединения с обслуживаемым сервером. При этом мы оставим режим по умолчанию — авторский режим, что означает, что открытая на консоли оснастка может быть м о ди ф и ци рова н а впоследствии. Консоли также можно сохранить в одном нз пользовательских режимов с ограниченным доступом, однажды выбрав соответствующий режим в диалоговом окне Параметры меню Консоль. Консоли с ограниченным доступом можно использовать для создания специальных интерфейсов для лиц, ответственных за определенные задачи управления, Одна из замечательных функций управления в Windows 2000 — команда runas, действие которой очень похоже на действие команды su в UNIX. Она позволяет выполнять задачи управления, требующие особых прав доступа, с обычной учетной записью. Полную справку по синтаксису можно получить, введя в командной строке runas /?. Например, runas /user: topdomainXschmacimin "mmc %windi\ system32\ schiwngmt.msc" запускает консоль диспетчера схемы от имени учетной записи schmadmin в домене topdomain.
[
Лучший способ использования возможностей программы runas — создание в меню Пуск ярлыка для новой настраиваемой консоли. Затем шелкните на этом ярлыке правой кнопкой мыши и отредактируйте его свойства (в контекстном меню ярлыка). Во вкладке Ярлык диалогового окна свойств установите флажок Выполнить как другой пользователь. По- ；еле этого при запуске данного ярлыка будет появляться диалоговое окно ：.'| для входа в систему с другой учетной записью. Эта запись будет исполь- ,зоваться во время выполнения. Настраиваемые консоли с ограниченным I’ доступом, запускаемые через runas, представляют собой эффективный ,способ делегирования задач н прав для выполнения этих задач.
[Статистика сервера DNS и информация о
j настройке
j Сервер DNS имеет множество внутренних статистических параметров. : Мы даже не будем пытаться показать всю массу данных, которые можно 卜 вывести в командной строке, задав команду dnscmd 〈сервер〉 г /svatictics (здесь вместо〈сервер〉может быть точка для локального 丿 сервера, имя узла DNS или IP-адрес). Очистить статистику сервера мож- j но с помошью команды dnscmd 〈сервер〉 /statictics /clear, а от- 卜 фильтровать выводимые данные — указав категории статистики. В лис- i тинге 13.1 представлена информация о доступных категориях статистики I и об их фильтрации. Значительную часть информации, генерируемую с I помошью этой команды, нельзя получить никаким другим способом, хо- j тя некоторая часть все же затрагивается в других программах. В будущем ■ следует ожидать появления новых интерфейсов управления информацией I и текущего контроля DNS Server, когда Microsoft или сторонние разра- - ботчики обнаружат, что Windows 2000 DNS Server полностью оснашена ( инструментальными средствами управления Windows (Windows Management 'Instrumentation, WM1).
; Очень простой способ проверить настройки, управляющие работой серве- ； ра, — ввести dnscmd〈сервер〉/info. В листинге 13.2 представлен вывод 『 этой команды, примененной к локальному серверу. В этих данньгх можно g узнать многне параметры, уже рассматривавшиеся в предыдущих главах.
I Контроль производительности сервера DNS
:Сервер DNS представлен в объекте DNS, который используется сис
темным монитором, обширным набором счетчиков, как было показано в ( табл, 11.1. Системный монитор Windows 2000 используется в сочетании с [ оснасткой консоли управления Оповещение и журнал производительно- [ сти. Вместе они обеспечивают возможности, которые в NT 4 предостав- ： лялись монитором производительности (кстати, его можно найти в Набо- :〃е ресурсов под именем PERFMQN4. ехе). На рис. 13.1 показано использо- ( вание этой оснастки для установки оповещения на передачи зоны AXFR ' в предположении, что все серверы настроены так, что должны происхо- j дить только добавочные передачи.
Листинг 13.1. Доступные параметры dnscmd
C:\>dnscmd /statistics /?
ИСПОЛЬЗОВАНИЕ： DnsCmd〈сервер〉/Statistics [<фильтр> I /Clear]
<фильтр> -- комбинация желаемых категорий статистики
(по умолчанию 00000001 — 00000002 00000004—
00000008 — 00000010 - 00000020 00000040 00000100 - 00000200 00000400 00O100G0 00100000 00040000 00080000-
00200000 -■
-все категории)
Query2 Recurse
Secondary
Update
SkwanSec
Memory PacketMem
records
NbstatMem
/Clear -- очистка данных статистики
Команда завершена успешно.
Листинг 13.2. Информация о настройках, полученная с помощью DNSCMD.EXE
C:\>dnscmd . /info Результат запроса: Информация о сервере: ptr=0075АЕ0
server name=demol.home.local
version=C2O00O05
DS container=c
Конфигурация: dwLogLevel=00000000
dwDebugLevel=00000000
dwRpcProtocol=FFFFFFFF
dwNameCheckFLag=00000002
cAddressAnswerList=0
dwRecursionRetry=3
dwRecursionTimeout=15
dwDsPollinglncterval=300
Флаги конфигурации: fBootMethod-3 _.
fAdminConfigured=0
fAllowUpdate=1
fDsAvailable=1
fAutoReverse Zones-1
fAutoCacheUpdate=0
fSlave=0
fNoRecursion=0
fRoundRobin-1
fLocalNetPriority=1
fStrict Fileparsing=0
fLoos eW 11 clear di ng=0
fBindSecondaries=0
fWriteAuthorityNs=0
Конфигурация очистки：
Scavenginginterval=0
DefaultAgingState=0
De faultRefreshInterval-168
DefaultNoRefreshinterval=168
Адреса серверов:
Addr Count = 2
=> 169.254.10.100=> 169.254.10.101=> 169.254.10.100=> 169.254.10.101Addr[0}
=> 169.254.10.100
=> 169.254.10.101
=> 169.254.10.100
=> 169.254.10.101
AddEj
Адреса приемников: NULL IP Array.
Пересылка:
Addr Count = 1
AddrIO] => 10.10.9.9
forward timeout= 5
slave= 0
Команда завершена успешно.
Полная передача эоны
Это схан>«рование опоея^шД буоет иемвтхепеалемиасосле。
1^и»»нениямэненеиВ! :
QjetMM-и.QjetMM-и.Комнаятарий:
QjetMM-и.
QjetMM-и.
然累…觑^瀛 2晔寸р
Оо£ави1ъ 1 Цоатоь |
Смннать локозвккя кючцые, Ннгврвас"/^'：a™.,£№HnuM：；fcs"' ' d"
J. OK . I Owwe [ Прнценн “ I
Рис. 13.1, Настройка оповещения с использованием счетчиков объекта DNS
Эта системная служба обладает довольно большой гибкостью. Оповещение может запустить журнал монитора производительности, записать в журнал событий, послать сообшение или вызвать команду. Сканирование условий, которые могут вызвать оповещение, можно запланировать, чтобы оно происходило только в определенные моменты, причем для каждого оповещения отдельно.
Ведение журнала — это функция, позволяюшая фиксировать значения счетчиков в файле с классификацией по объектам, например для всех счетчиков объекта DNS. Затем этот файл можно проанализировать. Периодическая запись в журнал — отличный способ накопить библиотеку данных, которые можно статистически обрабатывать для анализа производительности.
Сам по себе системный монитор может служить для воспроизведения журнала или для просмотра текушей статистики в одном из нескольких режимов графиков/гистограмм. Нельзя забывать и о диалоговом окне Свойства системного монитора. В начальном выпуске Windows 2000 было два разных диалоговых окна с таким названием. Первое из них, которое открывается в меню Действие или в контекстном меню, когда фокус находится на узле системного монитора, довольно бесполезно. Больший интерес представляет другое окно, для открытия которого надо щелкнуть на значке в виде руки, указываюшей на бумажный лист. Этот значок находится на панели инструментов над областью графиков, справа от значка в виде красного кружка с белым "X". Большая часть настроек относится к визуальному представлению данных; также здесь можно задать скорость обновления изображения.
Эта книга не содержит более подробных сведений о системном мониторе. В заключение можно только сказать, что это именно то инструментальное средст во, которое надо знать очень хорошо.
Журнал событий DNS как средство обнаружения проблем
Слхокбы DNS настолько важны для Windows 2000, что DNS имеет свой собственный журнал событий. Например, для небольшой фирмы одним из необходимых дел является соглашение по разделению данных и обязанностей DNS с lntemet-провайдером (ISP), Но совершенно другое дело — убедиться, что все работает нормально. Журнал событий дает ценную информацию, которую можно при этом использовать (например, чтобы проверить, действительно ли передачи зон происходят так, как надо).
Обычно доступ к этим данным получают на консоли Управление компьютером, которая открывается по команде ccmpmgmt.msc или Управление в контекстном меню Мой компьютер. Можно также обратиться к ним непосредственно, выбрав Просмотр событий в разделе Администрирование меню Пуск — Программы. Журнал событий содержит записи, соответствующие всем существенным проблемам сервера DNS, а также информативные записи, например по передачам зон. Значение журнала событий для обнаружения проблем трудно переоценить. Информация, приводимая здесь, помогает объяснить и исправить проблемы в большинстве аспектов окружения Active Directory Windows 2000. Средства создания и распространения оповешений, например по злектронной почте, при фиксации в журнале определенных событий облегчают контроль за журналами событн(1 в нескольких системах и позволяют высвободить время для других задач.
Журнал событий состоит из записей системных сообщений Windows 2000. В основном записи журнала событий имеют следующий формат.
<тип> <дата> <времч> <источник>〈категории〉<событие> 〈пользователь〉〈компьютер〉<ланные>
В Просмотре событий отображаются различные журналы для разных служб: Система, Безопасность, Приложение, Служба каталогов, Служба репликации файлов, DNS Server и т.д. Поле с^аннхе〉записи события содержит подробную диагностическую информацию. Для наблюдения за службой DNS просто выберите DNS Server в Просмотре событий, как показано на рис. 132 Расположение остальных перечисленных выше элементов —<тип>, <категория> и т.л. — можно менять путем перетаскивания заголовков колонок на правой панели. Во встроенной справке Windows 2000 приводится список событий, обычно отраженных в журнале событий DNS, и их объяснение.
9'，эеаом1 СПредугр9'，эеаом1 СПредугрlJQ「x|lJQ「x|
9'，эеаом1 СПредугр
9'，эеаом1 СПредугр
lJQ「x|
lJQ「x|
Рис. 13.2. Журнал событий DNS Server
На рис.13-2 показан формат типичного журнала. Обратите внимание на крайнюю слева колонку в окне событий, в которой указан тип записи. Белый "пузнрек" с буквой "Г означает, что это информационное сообщение и условий для ошибки нс сушествует. Желтый треугольник со знаком "!" означает, что это предупреждение. Третий символ, красный кружок с белым "X"、указывает администратору на то. что произошла серьезная ошибка и какой-то аспект системы, возможно, остался в нсра~ бочем состоянии. Причино11 тому может быть сбой при загрузке зоны или отказ какой-то части оборудования. Двойной щелчок на каком- нибудь з〃ементе открывает окно с подробной информацией о нем. как показано на pitc. 13.3.
Событие на рис. 13.3 показывает, что служба DNS обнаружила какие- то ошибочные элементы в процессе связи. Это часто встречающееся со- □бшение необязательно означает какую-то проблему с сервером; оно мо-
жет быть вызвано высокой частотой конфликтов входящих сообщений, например при передаче зоны, С другой стороны, это сообщение может быть инициировано злонамеренной атакой с целью вызвать отказ от обслуживания посредством неправильно сформированных пакетов. Другая группа подлежащих контролю событий — это сообщения стартовой инициализации, которые могут происходить в любое время при запуске сервера DNS. Другие сообщения отображаются при передаче зоны или останове службы. Если в журнале событий DNS появляются любые другие сообщения, их обязательно надо проанализировать, чтобы узнать, что случилось. Предупреждения появляются, если администратор запустил службу через загрузочный файл и затем задает неподдерживаемую директиву. В общем предупреждения сообщают о проблемах, но необязательно останавливают работу сервера DNS. Если произошла неисправимая ошибка и в журнале событий появился красный значок с "X", это значит, сервер DNS не функционирует в соответствии со своей настройкой, и администратор должен устранить какие-то проблемы.
Сеочстеа: Препупремпенне
гСобьпие/
Отсутеде「
.•flefifc®«sarwi«-；.-Herflews«；'
КомпьВ1ар* DEMO1
高硝麻2«згочисп«тшее1№гм1)ремени：
.■СТ4Н；абы«ноаызыв(воте®прн®*>н»Ш¥еи1«й!Н>а-илв
бПроаламемисю«мимгкм|3*^10рным£рефШЕ тееааняызниже，“о чисаа подаелвиньо、—
Рис, 13.3, Данные события, записанные в журнале сервера DNS
Как предотвратить смещение настройки
Проблема смещения настройки фактически возникает лишь в системах с совместным администрированием. После того как сервер был настроен, не мешает предусмотреть метод, с помощью которого можно было бы проверить, что эти настройки не были непреднамеренно изменены. Это часто встречается, если администратор производит настройку без учета всех факторов системы и влияния служб. Один нз самых простые
[ способов проверить это в Windows 2000 DNS Server — предварительно к сохранить в файле выдержку из структуры реестра, а конкретно — раздел J HKLM\System\CurrentControlSet\Seгvices\DNS, поскольку ОН содер- k жит текущие значения всех настроек. Вероятнее всего, в Windows 2000 'это можно выполнить, обратившись к утилитам rec.exe и regd^p.exe [из Набора ресурсов NT 4, а также версии REGDMF.EXE нз Набора ресурсов I Windows 2000. Первая из них сохраняет раздел в двоичной форме, при- I годной для восстановления, а вторая записывает его в файл ASCII, кото- I рый можно прочитать и автоматически сверить с другим файлом.
:В NT 4 или Windows 2000 (хотя в последней системе это и нс полдер-
:живается) команды сохранения настроек в файлах в каталоге С： \bkup\Dnscfg\Srvl выглядят так.
reg save HKLM\System\CurrentControlSet'Services\DNS
C:\bkup\DNScfg\Si?L\DNSkey-bin
； regdmp HKEY_LOCAL_MACHINE\Sy5tem\CurrentControlSet\5егУ1с?й\DNS > C : \bkup\DNScfg\Srvl\D№key . txt
' Имея в запасе эти файлы, можно легко контролировать конфигура- I цию сервера и зоны. Сохранить раздел в файле также можно из REGEDT32. EXE, внденмв раздел и вызвав команду меню Реестр— Сохранить раздел, однако этот способ нельзя автоматизировать. Самая большая проблема, встречающаяся в такой практике, — это подлержание сохраненной информации в текущем состоянии. В этом отношен ин эффективен метод управления изменениями, включающий обновление информации при изменении настройки машин, или автоматнческмн процесс периодической записи раздела в файл и сравнения его с эталонным текстовым файлом. Если при сравнении обнаруживаются расхождения, 1 сообщение об этом посылается по электронной почте.
В листинге 13.3 приведен пример фиксации реестра небольшого сервера DNS, который демонстрирует формат, содержащий всю ииформа- .цию о настройке сервера DNS. Если все данные для всех серверов оста- ，ются неизменными, это означает, что размещение зоны, топология и безопасность передачи зоны н типы серверов, вк-чючая пересылочные и подчиненные серверы, т.е. все, кроме самих данных зоны, не изменились. Следует еше сказать, что переключатель -т команды regchip и необязательное указание машины в reg save можно использовать для по- 'лучения информации с удаленной машины. Учетная запись, вынолняю- ,щая эти действия, должна иметь достаточные права на соединение с этой машиной и доступ к реестру.
Листинг 13.3. Получение настроек DNS Server через REGDMP.EXE
I С:\>regdmp
HKEY_LOCAL_MACHINE\Systen\currentCCJntrolset\5erviceb\dns
Type =-REG_DWORD ОхиОСОООЮ
Start = REG_DWORD 0x00000002
ErrorControi = REG_DKOFD 0x00000002
1Imagepath = REG_EXPAND_SZ %SystemRooC^XSybtem32\dns.exe
DisplayName = DNS Server
DependOnService = REG_MULTI_SZ "Tcpip"
"NetBT" "RpcSs"
"NTLmSsp"
DependOnGroup = REG_MULTI_SZ
ObjectName = LocalSystem
Description = Answers query and update request for \
Domain Name System (DNS) names.
Parameters
PreviousLocalHostName = demol.home.local
BootMethod = REG_DWORD 0x00000003
ScavengingInterval = REG_DWORD 0x00000000
NoRecursion = REG_DWORD 0x00000000
Forwarders = 10.10.9.9
ForwardingTimeout = REG_DWORD 0x00000005
IsSlave = REG_DWORD 0x0000000
BindSecondaries = REG_DWORD 0x00000000
SecureResponces = REG二DWORD 0x00000001
Performance
Library = dnsperf.dll
Open = OpenDnsPerformanceData
Close = CloseDnsPerformanceData
Collect = CollectDnSPerformanceData
Last Counter = REG_DWORD 0x00000c7e
Last Help = REG_DWORD 0x00000c7f
First Counter =-REG_DWORD 0x00000c02
First Help = REG_DWORD ОхОООООсОЗ Object List = 3074
WbemAdapFileTime = REG_BINARY 0x00000008 0x5830000
0x01bf2efc
WbemAdapFileSize = REG_DWQRD 0x00008110
WbemAdapStatus = REG__DWORD 0x00000000
Security
Security = REG_BINARY OxOOOOOObS 0x80140001\
0x00000014 0x00000001 0x00000101 0x00700002 0x000201fd 0x00000012 0x00000020 0x00180000 0x05000000 OxOOlcOOOO 0x050000000x050000000x00000014 0x00000001 0x00000101 0x00700002 0x000201fd 0x00000012 0x00000020 0x00180000 0x05000000 OxOOlcOOOO 0x050000000x05000000OxOOOOOOaO OxOOOOOOac 0x00000030 0x001cQ002 0x00148002 OxOOOfOlff 0x01000000 0x00000000 0x00000004 0x00180000 0x00000101 0x05000000 0x00000201 0x05000000 0x00000220 0x00730072 0x0002018d 0x00000101 0x0000000b 0x00000220 0x000201fd 0x00000201 0x00000012 0x00000101 0x00000012
0x00000014 0x00000001 0x00000101 0x00700002 0x000201fd 0x00000012 0x00000020 0x00180000 0x05000000 OxOOlcOOOO 0x05000000
0x05000000
0x00000014 0x00000001 0x00000101 0x00700002 0x000201fd 0x00000012 0x00000020 0x00180000 0x05000000 OxOOlcOOOO 0x05000000
0x05000000
1.168.192.in-addr.arpa
Type = REG_DWORD 0x00000001
DatabaseFile = 1.168.192.in-addr.arpa.dns SecureSecondaries = REG_DWORD 0x00000000 NotifyLevel = REG_DWORD-0x00000G01 AllowUpdate = REG二DWORD 0x00000000
n-addr.arpa
Type = REG—DWORD 0x00000001
DatabaseFile = 10.10.in-addr.arpa-dns SecureSecondaries - REG_DWORD 0x00000000 NotifyLevel = REG_DWORD'"0x00000001 AllowUpdate = REG二DWORD 0x00000000 example.net
Type = REG—DWORD 0x00000001
DatabaseFile = e?:ample . net .dns SecureSecondaries = REG_DWORD 0x00000000 NotifyLevel = REG_DWORD-0x00000001 AllowUpdate = REG二DWORD 0x00000001 NcRefreshInterva「= REG_DWORD 0x00000Ca8 Refreshinterval = REG_DWORD 0x000000a8 Aging = REG_DWORD 0x00000000 hq.example.net
Type = REJDWORD 0x00000001
SecureSecondaries = REG_DWORD 0x00000002
NotifyLevel = REG_DWORD^0x00000002 AllcwUpdate = REG二DWORD 0x00000001 NoRefreshinterval~= REG_DWORD 0x000000a8 Refreshinterval = REG_DWORD 0x000000a8 Aging = REG—DWORD 0x00000000 Dslntegrated = REG_DWORD 0x00000001 NotifyServers = 169.254.10.10 10,10,10.10 SeconclarySeivers 169.254.10.10 10.10.10.10 pc.example.net
Tvpe = REG_DWORD 0x00000002
MasterServ^rs = 207.32.154.3 209.132.35.3
DatabaseFile = west.demo.ret.dns SecureSecondaries - REG_DWORD 0x00000003 NotifyLevel = REG_DWORD~0x00000002
0 =Root\LEGACY_DNS\0000
Count = REG_DWORD 0x00000001
Nextinstance = REG_DWORD 0x00000001
Изменение IP-адреса зарегистрированного сервера DNS
Администратор не должен слишком часто изменять IP-адрес сервера. Однако иногда это бывает необходимо. Здесь мы говорим не об изменении IP-адреса при замене сервера другим, менее загруженным. Речь идет, скорее, о ситуациях, когда следует изменить IP-адрес уже существующего, делегированного сервера.
Само по себе действие замены IP-адреса несложно. Однако много неприятностей может принести перерыв в работе службы, если этой замене не предшествовало тщательное планирование. Некоторые клиенты неизбежно будут какое-то время использовать прежний адрес, если он зафиксирован в кэше где-нибудь в сети. Лучший способ ограничить такое влияние — соответственно задать TTL машины.
Перед изменением IP-адреса первым делом надо проверить, зарегистрирован ли этот сервер имен в InterNlC. (Услуги регистрации в InterNIC в США предоставляются компанией Network Solutions, Inc; за пределами США могут быть и другие службы регистрации.) Также имеет большое значение, основной это сервер или дополнительный. Если машина зарегистрирована в InterNIC, регистрационные данные до.тжны быть занесены в форму модификации, которая направляется в InterNIC. Если сервер имен является основным, форма модификации становится намного более важной.
Изменение регистрации
Форма модификации называется Формой узла (Host template); она должна использоваться при обновлении IP-адреса н/нпн имени сервера имен. Принятые на данный момент версии Соглашения о регистрации доменного имени не разрешают изменять IP-адрес или имя узла. Однако это соглашение разрешает соответствуюшей стороне заменять текущий сервер имен домена другим существующим сервером имен. Иными словами, соглашение о регистрации доменного имени можно использовать для передачи домена новому провайдеру, однако ни Internet-провайдер, нм администратор сервера не могут изменять IP-адрес или имя узла.
Форма узла может служить для регистрацтк удаления н изменения информации о сервере имен. Чтобы просмотреть текущую информацию о сервере имен, найдите в базе данных WHO1S его дескриптор NIC (NIC handle). Если сервер имен уже связан с определенными доменными именами, но вы не знаете его дескриптора NIC, поишитс в базе данных WHOIS имя или IP-апрес этого сервера. Программа WHO1S проверяет, доступен ли этот домен. К WHOIS можно обратиться в Web-броузере по адресу www.internic.net/. Дескриптор NIC — это уникальный идентификатор, содержащий до 10 букв и цифр, который присваивается каждой записи доменного имени, контактной записи и сетевой записи в базе доменных имен Network Solutions. Дескрипторы NIC следует использовать в регистрационных формах везде, где только возможно, поскольку они помогают экономить время и соблюдать точность в записях.
К счастью, при изменении IP-адреса или имени сервера имен не надо обновлять все записи домена, связанные с этим узлом. Когда 1Р-алрес или имя сервера обновляется, все записи домена, связанные с ним, обновляются автоматически. Это происходит потому, что как имя, так и IP- адрес сервера имен связаны с дескриптором NIC и все записи домена связаны с узлом по его дескриптору NIC.
Регистрационные формы применяются для отправки и обработки требований на регистрацию. Эти формы, в состав которых входит Соглашение о регистрации доменного имени、служат для регистрации новых доменных имен, новых контактов для доменных имен и новых узлов (серверов имен), а также для обновления доменных имен, контактов и записей узлов. Имеются версии форм как в формате Web, так н в текстовом виде (ASCII).
> Прежде чем отправлять требование на модификацию, убедитесь, что установлен новый сервер, который заменит старый, и что сервер имен '工 настроен так, чтобы отвечать на запросы по новому адресу. InterNIC не ■/' обрабатывает требования, которые нельзя проверить. Если машина, объ- ‘‘ явленная как основной сервер, не отвечает на запросы, InterNIC не про- :изведет никаких изменений. Если изменение заключается только в но- ，вом IP-адресе, убедитесь, что дополнительный адрес настроен и досту- 」пен. Если изменение влечет за собой создание нового сервера, должна быть установлена машина и на ней должен работать сервер DNS с полным набором зон. Если изменяемый сервер имен является основным или главным подчиненным, в дело вступают новые факторы; следует убедиться. что дополнительные серверы, производящие передачу зоны с этого узла, также обновлены. В противном случае администратора ожидает не очень приятный сюрприз — через некоторое время после изме- 'Нения срок действия зон всех дополнительных серверов истечет и они Прекратят отвечать на запросы.
Наконец, следует вспомнить и о клиентах. У всех клиентов, направлен- ■ ных на этот сервер имен, необходимо изменить настройку распознавателя. '■ Для тех узлов, которые используют DHCP, это довольно простое дело; оно ■ заключается в изменении параметров DHCP и установке приемлемого сро- 丿 ка аренды. Главное при изменениях в любой активной службе — это пла* нирование процесса изменения и внимание ко всем деталям.
^ Изменение конфигурации IP DNS в Windows 2000
_ Если вы еще не изменили IP-адрес компьютера, выполните следую- п щие действия.
『1. Добавьте новый IP-адрес к сетевому адаптеру.
Запустите консоль управления сервером DNS.
R 3. Обновите информацию сервера DNS для нового интерфейса.
t 4. Удалите старый IP-адрес (если можно, не сразу).
(■" В следующих подразделах эти процессы рассматриваются по отдель- [ным этапам.
[Добавление второго IP-адреса к сетевому адаптеру
? На рис. 13.4 показано окно, которое используется во вкладке Допол- ЬНИтельно диалогового окна свойств TCP/IP Windows 2000 Server при добавлении нового IP-адреса компьютера. (Чтобы найти диалоговое окно свойств TCP/IP, обратитесь к первому разделу главы 14, "Настройка и .разрешение клиентов Windows".)
ГП^1ГП^1|TCP/IPanpJT
ГП^1
ГП^1
吟aapec『t£9 su^iO io
I~讪 6ВЭ“А~1О1ИЕНО
Рис. 13.4. Добавление нового IP-адреса в свойствах TCP/IP Windows 2000
Чтобы добавить второй IP-адрес к сетевому адаптеру, выполните следующие действия.
Откройте диалоговое окно Свойства TCP/IP адаптера и перейдите во вкладку Дополнительно (см. процедуру в главе 14).
Во вкладке Параметры IP щелкните на кнопке Добавить под списком IP-адреса.
Во всплывающем окне ТСР/1 P-адрес введите новый IP-адрес н маску подсети, как показано на рис. 13.4.
Щелкните на кнопке Добавить и проверьте, появились ли в списке IP-адреса правильные данные.
Щелкните на кнопке ОК, чтобы вернуться на вкладку Общие свойств TCP/IP, и закройте это окно двумя щелчками на ОК.
Windows 2000 Server должен немедленно отреагировать на вновь введенный IP-адрес. Теперь можно проверить, использует ли сервер DNS новый интерфейс.
Настройка сервера DNS с новым интерфейсом
Если стандартные настройки сервера DNS не изменялись, он должен отвечать за все интерфейсы. Однако если интерфейсы были изменены, надо остановить и перезапустить сервер DNS; при этом проверяются настройки, включающие службу DNS на новом 1Р-адресе.
Откройте диалоговое окно Свойства сервера DNS из контекстного меню или меню Действие на консоли управления DNS. (Если подключено несколько серверов DNS, убедитесь, что фокус находится именно на том сервере, который вам нужен).
Во вкладке Интерфейсы проверьте положение переключателя: он должен быть установлен в положение Все IP-адреса или, при необходимости, Только следующие IP-адреса (в последнем случае введите новый адрес и щелкните на кнопке Добавить).
Закройте диалоговое окно Свойства сервера DNS.
Перезапустите этот сервер DNS, вызвав команду Перезапуск из раздела Все задачи контекстного меню или меню Действие.
После завершения всех изменений в инфраструктуре служб DNS, если необходимо, повторите предыдущие этапы и удалите старый 1Р-адрес.
I Изменение конфигурации IP DNS в Windows NT 4
；. В Windows NT 4 этот процесс несколько более трудоемок. На рис. 卜 13,5 показан аплет Панель управления сетью Windows NT 4, открытый на свойствах TCP/IP (см. главу 14), где надо будет произвести изменение f адреса самого компьютера.
I ок j Prwa II ок j Prwa I
I ок j Prwa I
I ок j Prwa I
Рис, 13.5. Добавление нового IP-адреса в свойствах TCP/IP Windows NT 4
I Добавление второго IP-адреса к сетевому адаптеру в NT 4
Чтобы добавить второй IP-алрес к сетевому адаптеру в NT 4, выпол- I ните следующие действия.
1. Откройте Панель управления сетью и перейдите во вкладку Протокол.
J2. Выделите TCP/IP и щелкните во вкладке Свойства.
t3. Щелкните на кнопке Дополнительно, а затем — на кнопке Доба-
( вить под списком IP-адрес, предварительно убедившись, что в раскрывающемся епмеке вверху диалогового окна выбран правильный адаптер.
Введите IP-адрес и маску подсети и щелкните на кнопке Добавить.
Если необходимо, например при новом адаптере, добавьте новый адрес шлюза.
Закройте панель правления и перезагрузите компьютер.
Настройка диспетчера DNS NT 4 с новым IP-адресом
В диспетчере DNS NT 4 перечислены серверы DNS, с которыми устанавливается соединение по протоколу IP. На рис. 13.6 показано диалоговое окно в диспетчере DNS, предназначенное для задания нового IP-адреса.
；Добаенть сервер DNS
Ввеастаимонли 1Р«фессе)»ера СХ5для' ловввлеимяеСяишк
■Сервер DNS;；侬：54 而 0J"
Рис, 13,6, Добавление нового сервера DNS в диспетчере DNS Windows NT 4
Затем надо запустить диспетчер DNS NT 4 и зарегистрировать сервер по новому !Р-адресу.
В меню Пуск выберите Программы — Администрирование — Диспетчер DNS.■
Щелкните правой кнопкой мыши на списке серверов и выберите команду Создать сервер.
Введите новый IP-адрес и щелкните на ОК.
Если допустимо в это время, выделите старый IP-адрес, щелкните правой кнопкой мыши, из контекстного меню выберите команду Удалить и подтвердите удаление.
Обновление информации с印вера DNS NT 4
После регистрации сервера по новому IP-адресу в диспетчере DNS надо обновить информацию сервера DNS. Вот как это делается.
Выделите вновь добавленный IP-адрес на левой панели диспетчера DNS.
В меню DNS или в контекстном меню выберите команду Обновление файлов данных сервера.
После этого сервер по новому IP-адресу готов для настройки файлов зоны и их содержимого, если это необходимо.
Удаление старого IP-адреса в NT 4
Наконец, вам, вероятно, потребуется удалить старый IP-адрес. Выполните для этого следующие действия.
Если старый сервер DNS остался зарегистрированным в диспетчере DNS, удалите его.
На панели управления сетью щелкните во вкладке Протокол.
Выделите TCP/IP и щелкните во вкладке Свойства.
Щелкните на кнопке Дополнительно, выберите нужный адаптер, а затем — старый адрес; щелкните на кнопке Удалить.
Закройте панель управления и перезагрузите компьютер.
Увеличение емкости за счет нового сервера DNS
Неизбежно приходит время, когда старая система требует обновления или необходимо включить новый сервер. Этапы установки “ настройки Windows 2000 DNS Server представлены в главе 11, "Настройка Windows DNS Server", но здесь мы вкратце напомним их.
Установите Windows 2000 DNS Server, если это еще не сделано.
Настройте сервер для использования статического IP-адреса (или адресов).
Выберите Установка и удаление программ — Компоненты Windows — Сетевые службы и установите в этом окне флажок DNS,
Запустите консоль управления DNS, соединитесь с локальным сервером и настройте интерфейсы н свойства сервера в соответствии с его типом и особенностями использования.
Настройте зоны, которые будут храниться на сервере.
На практике компьютер иногда устанавливают с времсннь〕м IP- адресом, а рабочий 1Р-а口рес настраивают на последнем этапе замены предыдущей машины. Так*е может иметь различные формы настройка зон, в зависимости от того, перемещаются ли зоны с прежнего сервера или же сервер создается вновь для новой цели. Некоторые из этих вариантов описаны в следующем разделе.
При установке новых серверов, замене серверов, перемещении зон, добавлении новых зон на сервер и так далее обычно бывает нужно сначала создать новые зоны на принимающем сервере. Ниже приводятся краткая сводка этих процедур и порядок настройки зоны, которая всегда должна производиться перед загрузкой и запуском зоны, но о которой так легко забыть.
Добавление основной зоны
Если сервер DNS Windows 2000 настроен для загрузки данных конфигурации из файла, добавить новую основную зону можно путем непосредственного редактирования загрузочного файла конфигурации, добавив новую директиву primary и затем перезапустив или перезагрузив
сервер. Для этого необходимо, чтобы файл данных зоны был доступен. Это превосходный метод для перемещения нескольких зон, но для новых зон он несколько более трудоемок. Самый простой способ, который работает во всех случаях, при любых вариантах загрузки и который включает использование существующих данных зоны, — это работа с консолью управления. При этом процесс добавления новой зоны ускоряется, так как можно при необходимости создать начальные данные зоны.
Чтобы добавить новую зону на консоли управления DNS Server, выполните следующие действия.
Щелкните на значке нужного сервера DNS, чтобы установить на нем фокус.
Щелкните на этом значке правой кнопкой мыши и в контекстном меню выберите команду Создать новую зону, которая запускает мастер создания новой зоны.
Выберите создание стандартной основной зоны и щелкните на кнопке Далее. Тип хранения зоны можно позднее изменить на интегрированную в Active Directory.
Выберите, какая зона будет создана： прямая или обратная in- addr. arpa.
Для зоны прямого просмотра укажите полное доменное имя DNS; для зоны обратного просмотра задайте код сети (более легкий способ) или введите правильное имя домена i六-addr. агра.
Если зона будет перемешена и файл данных уже подготовлен и отредактирован, установите переключатель Использовать этот существующий файл и укажите правильное имя файла (в каталоге %windir%\system32\dns). В противном случае примите имя, предлагаемое по умолчанию для нового файла, или введите другое в соответствии с вашим соглашением об именах.
Щелкните на кнопке Далее, проверьте введенную информацию и щелкните на кнопке Готово.
Мастер создания зоны завершит свою работу и автоматически создаст зону и файл зоны и впишет в него начальную запись зоны (SOA) и запись сервера имен (NS). Проверьте правильность записей SOA и NS в зонах, импортированных из существующих файлов. Если загрузка происходит из файла, в загрузочном файле также должна появиться новая директива primary.
Везде, где только возможно, создавайте зону обратного просмотра для каждого диапазона IP-адресов перед добавлением записей компьютеров А. Благодаря этому вы сможете использовать флажок Создать соответствующую PTR-запись в диалоговом окне Новый узел. Как было сказано выше, обратный просмотр может оказаться полезным, даже во внутренней сети. Гораздо легче предусмотреть обратный просмотр с самого начала, чем возвращаться назад, определять и загружать все необходимые обратные зоны потом.
Добавление дополнительной зоны
/ Процесс добавления дополнительных зон почти такой же, за исклю- 心 чением того, что надо указать, с какого главного сервера (или серверов) й DNS будут получены данные зоны. Чтобы добавить дополнительную зо- 卜 ну, выполните следующие действия.
1. Щелкните на значке нужного сервера DNS, чтобы установить на
нем фокус.
I 2. Щелкните на этом значке правой кнопкой мыши и в контекстном % меню выберите команду Создать новую зону, которая запускает ' мастер создания новой зоны.
Выберите создание стандартной дополнительной зоны и щелкните ' на кнопке Далее. Дополнительные зоны не интегрируются в Active Directory.
Выберите, какая зона будет создана: прямая или обратная in- addr. arpa.
Для зоны прямого просмотра укажите полное доменное имя DNS; для зоны обратного просмотра задайте код сети или введите правильное имя домена in-aadr.&гра. В обоих случаях можно просмотреть список основных зон (кнопка Обзор) и выбрать одну из них, если она находится на сервере, подключенном к консоли управления.
В следующем окне можно ввести некоторое число IP-адресов серверов DNS, которые будут главными для зоны, т.е. от них будут исходить передачи зоны. Серверы будут опрашиваться в том порядке. в каком они перечислены в списке. Здесь также есть возможность обзора и выбора подключенных серверов DNS.
Щелкните на кнопке Далее, проверьте введенную информацию и щелкните на кнопке Готово.
:Изменение свойств зоны
После успешного добавления зоны надо выполнить дополнительную I настройку, изменив свойства зоны. Этот процесс подробно описан в гла- 1 ве 11. Убедитесь, что, если используется динамическое обновление, оно . установлено для основной зоны. Держите под контролем передачи как основных, так и дополнительных зон. Хотя мы упомянули только два параметра, перед использованием новой зоны надо обратить внимание и на ■ многие другие параметры.
Если новая основная зона была создана с уже существующим файлом данных, проверьте ее записи SOA и NS. Убедитесь, что они исправлены . в соответствии с новым сервером и что все присутствующие записи NS остались правильными и после перемещения зоны.
При внесении в зону изменений на консоли управления сервером DNS администратор должен с осторожностью применять команду Обновление файлов данных сервера в контекстном меню. Эта команда немедленно записывает новую информацию в соответствующую базу данных и помешает ее на диск, если используется режим хранения в файле. Данные также переписываются при нормальном выключении сервера DNS, В контекстном меню зоны также есть команда Перезагрузка; она вызывает немедленную перезагрузку данных зоны из любого места, которое было установлено для постоянного хранения данных зоны при ее настройке.
Обслуживание данных зоны
Было время, когда обслуживание данных зоны состояло в редактировании текстового файла: изменении в нем записей ресурсов, обновлении номера версии записи SOA и последующем перезапуске сервера, чтобы он загрузил отредактированную зону. Хотя так поступают и сейчас (в Windows меньше, чем где бы то ни было), появилось множество других аспектов обслуживания данных. В этом разделе рассматриваются методы обслуживания в Windows 2000 и (поскольку здесь возникают совсем другие проблемы) в NT 4. Показано, как можно перемешать данные с одного сервера на другой и как подготовить и включить в работу сервер для замены устаревшего сервера.
При перемещении файлов зон с одного сервера на другой надо учитывать несколько обстоятельств. Во-первых, в загрузочном файле кон- фигураиин Windows 2000 поддерживаются очень немногие директивы. В результате сервер BIND не будет иметь проблем с загрузочным файлом конфиглрании. полученным от сервера Windows, хотя, вероятно, придется добавить оператор directory. Однако при обратном перемещении все будет далеко нс так просто. Поскольку загрузочный файл соответствует расширению DNS для BIND, а не спецификации RFC, Microsoft реитла ограничить поддержку его директив, оставив только директивы cache, primary и secondary. Все остальное игнорируется. Файлы данных зоны полностью стандартные и мог\т перемешаться с Windows 2000 DNS на BIND, но с двумя исключениями. Во-первых, если используются записи WINS и W1NS-R, их необходимо удалить. Во-вторых, если включена очистка, в записях появляется штамп времени. Если планируется перенести основную зону с Windows DNS на BIND, где она также будет основной, лучше всего отключить очистку зоны и обновить файл перед перемещением. Если зона на сервере BIND должна быть дополнительной, проше всего, конечно, использовать передачу зоны; при этом штамп времени автоматически удаляется.
Если перемешение зон производится для последующей замены основного сервера имен, рекомендуется сначала настроить новую машину как дополнительный сервер. После того как зоны будут переданы, тип сервера можно изменить с дополнительного на основной. После этого новый узел можно будет включить в сеть на место старого, и он продолжит обработку информации DNS.
Очистка в динамически обновляемых зонах
Управление динамическими зонами в первую очередь включает поддержание приемлемого уровня безопасности при передачах, и затем — управление размером файла зоны. Если никто (или ничто) не будет удалять записи ресурсов, динамически обновляемая зона со временем будет неограниченно расти. Это занимает ценную память сервера DNS и замедляет обработку запросов. Что более важно, это также приводит к возникновению конфликтов, когда клиенты требуют новых регистраций. В главе 7, "Динамическая DNS и Active Directory'', подробно описана настройка программы очистки, которая поставляется с Windows 2000 для автоматизации этого процесса. Поскольку очистка может стать чрезмерно активной, следует быть осторожным при включении этой функции и настройке ее параметров, а также при разрешении очистки для других зон.
Даже если очистка включена, очень вероятно, что для освобождения зон от ненужных записей понадобится дополнительное вмешательство. Рекомендуется периодически проверять размер зоны. Но поскольку в большинстве случаев, когда включена очистка, данные будут (или должны) храниться в Active Directory, это не так просто сделать, как проверить размер файла. Если речь идет о дополнительном сервере, файлы проверить несложно. В ином случае возможные альтернативы — просмотр зоны вручную на консоли управления DNS или автоматическая передача ее в файл. Традиционно для проверки зоны применяется команда nslookup, но в Windows 2000 для этой иели также имеется новое средство для работы в командной строке driscmd. Пример его использования приведен в листинге 13.4. Здесь показан синтаксис команды dnscmd 〈сервер〉 /EnumRecords и приведен список данных небольшой тестовой зоны.
Листинг 13.4. Список данных зоны, полученный с помощью
DNSCMD.EXE
C:\>dnscrnd /EnumRec2rds /?
ИСПОЛЬЗОВАНИЕ; D;;sCrad <серзер> <зона> <у?ек> 〈параметра 厂аннзх> [〈параметры вида>]
<зсна> - FQDN уз二а зоны, данные которой надо перечислить /RootHints для перечисления корневых ссылок /Cache 如弓 вытола данных кэша
<узел> - ”мя узла, данные которого над。 перечислить
означает ксрень зеныили
FQDN узла (имя с завершающей точкой или
-имя узла относительно <・зсна> 〈параметры данных> (по умолчанию выводятся все данные) /Туре <тип запмек ресурсов〉 ——перечислить записи данного тмпа
■ тип записи ресурсов〉- стандартное имя типа, т.е.
А, №, SOA и т.д.
/AuihoEityвключать авторитетные
данные
/G1L：евключать связующие
данные
/Additional— включать в перечисление
дополнительные данные
/Nodeперечислять только
записи данного узла
/Child-- перечислятв только
записи дочерних узлов данного узла
/StartChild <дочерний узел> -- имя дочернего узла, после которого начинать перечисление
〈параметры зида>:
/Continue -- при заполнении буфера продолжать перечисление до конца записей. По умолчанию перечисление продолжается только до заполнения первого буфера данных
/Detail -- выводить подробную информацию о записям узла. По умолчанию запмсп выводятся так, как в файле зоны.
Команда завершилась успешно.
C:\>dnscmd /EnumRecords example.net. @
Returned records:
@ 86400 NS ns.example.net. 66400 NS 86400 SOA1999122544 10800 3600 604800 86400 MX 0 WINS LOCAL fsl 86400 A maii^ub 86400 A ns 96400 A wsl 8640。 A ws2 86400 A ws3 86400 A ws4 8640Q A Команда завершилась успешно.@ 86400 NS ns.example.net. 66400 NS 86400 SOA1999122544 10800 3600 604800 86400 MX 0 WINS LOCAL fsl 86400 A maii^ub 86400 A ns 96400 A wsl 8640。 A ws2 86400 A ws3 86400 A ws4 8640Q A Команда завершилась успешно.demo.home.local.ns.example.net. administrator.86400demo.home.local.ns.example.net. administrator.8640010.mailhub.example.net.2 900 192.168.1.10192.168.16.1010.mailhub.example.net.2 900 192.168.1.10192.168.16.10
@ 86400 NS ns.example.net. 66400 NS 86400 SOA
1999122544 10800 3600 604800 86400 MX 0 WINS LOCAL fsl 86400 A maii^ub 86400 A ns 96400 A wsl 8640。 A ws2 86400 A ws3 86400 A ws4 8640Q A Команда завершилась успешно.
@ 86400 NS ns.example.net. 66400 NS 86400 SOA
1999122544 10800 3600 604800 86400 MX 0 WINS LOCAL fsl 86400 A maii^ub 86400 A ns 96400 A wsl 8640。 A ws2 86400 A ws3 86400 A ws4 8640Q A Команда завершилась успешно.
demo.home.local.
ns.example.net. administrator.
86400
demo.home.local.
ns.example.net. administrator.
86400
10.mailhub.example.net.
2 900 192.168.1.10192.168.16.10
10.mailhub.example.net.
2 900 192.168.1.10192.168.16.10
Управление несколькими зонами
Управление несколькими зонами требует не много умения, но массу внимания, чтобы поддерживать базы данных в организованном и удобном для чтения состоянии. Администратор должен учитывать распределение IP-адрссов и иметь схему присвоения адресов узлам. Как правило, администратору приходится управлять как минимум двумя зонами: одной или несколькими для прямого поиска IP-адресов по доменным именам и зоной in-addr для поиска в обратном направлении — доменных имен по IP-адресам.
(
На консоли управления Microsoft DNS можно добавлять несколько серверов DNS Windows 2000 и проводить изменения в зонах, управляемых этими серверами Важно заметить, что при создании основных и дополнительных серверов, необходимых для связи с Internet, сначала следует создать и настроить сервер именно на консоли управления DNS. Затем создается одна или несколько зон, управляемых этим сервером. Количество зон, которыми можно управлять, не ограничено.
匕 Обычное руководство по основным и дополнительным серверам DNS f неприменимо для настройки и работы реальных серверов имен DNS. К Поскольку вследствие административного выделения зол каждый сервер & DNS управляет своей частью пространства доменных имен, данные на £ сервере хранятся в файлах зон. В реализации Microsoft DNS зона представляет собой непрерывную ветвь пространства доменных имен, напрп-
k мер домен и некоторое число его непосредственных "потомков". Файл Г зоны будет иметь одну запись SOA.
I Когда данные переносятся между основными и дополнительными ,серверами, фактически переносятся зоны. Microsoft DNS Server присваи- [вает этот параметр (т.е. основной или дополнительный) самой зоне. ] Иными словами, обозначение источника данных как основного или до- ； полнительного выполняется на уровне зоны, а не на уровне сервера.
Администраторы, достаточно удачливые, чтобы научиться ведению DNS у Internet-провайдера, особенно у того, который сам обслуживает домен, могут 上 работать с тысячами зон на единственном сервере. Хотя доменов обратного I Просмотра может быть относительно мало, зоны обычных доменов могут ] превратиться в мешанину файлов, которые будет трудно или невозможно f идентифицировать по одному имени. При аккуратном управлении зонами и I доменами IP-адреса не должны создавать перекрестные ссылки или, хуже того, присваиваться неправильному домену. Очень жаль, что по умолчанию в
> Windows 2000 принята схема именования зон <домен9ое_имя>. dns, а не <обращен1-юе_доменное_имя>, так как в последнем случае домены и зоны
1 для их дочерних доменов группировались бы в естественном порядке. С об-
I ращенными нменамм список зон в каталоге выглядел бы так.
com.corp
сот.corp.asia сот.corp.hq сот.corp.west net.example
- net.example.advisory
net. example . comm'jnication net.example.consult net. e?;ample .training
При существующем соглашении об именах этот список имеет сложите организацию и менее удобен для чтения.
adv;soiy.example.net.dns
asia.corp.ccn.cns
communication.example.net.dns consult.example.net.dns
corp. coir. dns
example.net.dns
hq.corp.com.dns
training.example.net.dns
west.corp.com.dns
Если вам необходимо управлять большим количеством зон, очень целесообразно принять такое соглашение об именах, которое позволяет видеть структуру домена в списке имен файлов в каталоге.
Администратор, который думает о перестройке структуры сети своей компании, может столкнуться с вопросом такого рода: можно ли иметь два основных сервера доменных имен, каждый из которых будет обслуживать зону и иметь домен, например example. net, со следующими субдоменами.
consult.example.net
training.example.net
advisory.example.net communication.example.net
Скажем, администратору захочется назначить один сервер имен для консультаций и обучения ("consult and training1') и другой — для предложений заказчиков и связи с ними ("advisory and communication1').
Это вполне достижимо. Надо только создать три или пять зон, в зависимости от ваших предпочтений, основная зона: example.net основная зона: consult.example.net основная зона: training.example.net основная зона: advisory.example.net основная зона: communication.example.net
Здесь зона example. net включает делегирование всем своим субдоменам, т.е, всего пять зон. Два субдомена можно оставить в той же зоне, что и example.net. Тогда конфигурация будет такой.
основная зона: example.net
с доменами consult.example.net и training.example.net в зоне example,net И основная зона: advisory.example.net основная зона: communication.example.net
В этих примерах показано только два варианта распределения по двум серверам основных зон для домена с четырьмя субдоменами. Конечно, возможны и другие конфигурации. Разбиение больших зон в соответствии со структурой Active Directory и топологией сети может быть очень важным методом оптимизации для больших, рассредоточенных организаций.
Перемещение файлов зон с одного сервера на другой
Зона является авторитетной для всей информации DNS в неМ. Зона может содержать один или несколько доменов, и та же зона может вклю- ;чать в себя субдомены, но в Windows 2000 они должны быть смежными. Дня повышения производительности и доступности каждая зона может I иметь более одного авторитетного сервера имен. Это может создать проблему обслуживания общих данных, если придется аккуратно и своевременно обслуживать более одной главной базы данных. Главный сервер имен может инициализировать базы данных для всех зон, которыми он управляет, либо из локально хранящихся данных, либо с другого главного сервера имен. В последнем случае подчиненный главный сервер может попросить у основного главного, на котором хранится база данных, передать всю информацию зоны через соединение по протоколу TCP. Информация записывается и сохраняется локально в файле данных, который будет использован позднее, в случае, если передачу зоны не удастся закончить. При работе с некоторыми серверами DNS, не являюшимися разработками Microsoft, это локальное сохранение необязательно; напротив, для Windows 2000 DNS Server дополнительная зона всегда сохраняется в - локш!ьном файле. Вероятно, заслуживает внимания сохранение зоны локально в файле в том случае, когда как основной, ток и дополнительные серверы переходят в автономный режим, но основной сервер затем не возвращается в сеть. Если файлы зон сохранены хотя бы на дополнительном сервере, этой копии может быть достаточно для использования, пока основной сервер не вернется в строй, В случае крайней необходимости этот файл можно использовать для восстановления основной зоны при полной потере данных иа основном сервере. В некоторых системах есть сервер DNS, единственное назначение которого — быть дополнительным для всех зон и сохранять их в файлах именно для такого резервного копирования. Наряду с этим традиционным методом новые соображения добавляют хранение данных в Active Directory it конфигурации в реестре. Если данные не хранятся в файлах, один из этих источников является резервным- Это можно реализовать с помощью программы резервного копирования Windows, облегченная версия которой поставляется с Windows 2000, задав ей резервирование состояния системы.
Примечание
Как и для любого важного сервера, администратор должен быть уверен, что резервное копирование производится регулярно. Если сервер обслуживает несколько различных доменов, значение хорошего резервирования становится еще больше. Для резервирования не требуется никаких мер предосторожности, поскольку зоны— это всего лишь текстовые файлы или содержимое файла NTDS.D工т, если зоны интегрированы в Active Directory, а данные конфигурации располагаются либо в текстовом файле, либо в реестре. Windows DNS Server не блокирует файлы, когда они открыты Чтобы резервировать реестр и Active Directory, администратор должен указать, что следует сделать резервную копию состояния системы.
Независимо от того, какая стратегия принята для основного сервера DNS, по крайней мере один из дополнительных серверов DNS для открытых имен должен быть размешен у Intemet-провайдера, путь подключения к которому должен как можно менее зависеть от пути, используемого для основной части системы. Такое расположение может быть принято с участием Intemet-провайдеров, других групп в большой организации, или других систем, намеревающихся организовать обмен дополнительными DNS (т.е. чтобы каждая организация обслуживала дополнительные серверы DNS другой организации). Наллучший вариант — это максимально удаленный (в масштабах сети) за пределы сайта дополнительный сервер. Также целесообразно, чтобы дополнительный сервер имел совершенно другое соединение с сетью, чем провайдер, у которого находится основной сервер. Эти рекомендации хорошо работают для служб DNS представительства в общей сети, но для поддержки Active Directory лучше поместить сервер(ы) DNS на каждом удаленном внутреннем сайте.
Как правило, зоны перемешаются с одного сервера имен на другой путем передач, инициируемых дополнительным сервером, либо при запуске (особенно в начале работы системы, или в случае, когда дополнительный сервер не имеет резервной копии зоны), либо после того, как дополнительный сервер обнаружит, что серийный номер его главного сервера изменился. Один из способов уменьшения затрачиваемого на это времени — распространение изменений с помошью уведомления (см. рис. 11.8), когда основной или главный сервер сообщает дополнительным, что у него произошли изменения. Уведомление частавляет основной сервер предлагать дополнительным серверам проверить увеличение его серийного номера. Если серийный номер в записи SOA показывает, что дополнительный сервер не имеет самых свежих данных зоны, дополнительный сервер выдает требование на передачу. Передачи по уведомлению должны быть добавочными (через требования IXFR). Использование уведомления в сочетании с разрешением передач только на серверы, указанные в списке уведомления, является важным элементом безопасности данных зоны.
В начале раздела "Увепнчение емкости за счет нового сервера DNS" было намечено несколько этапов создания нового сервера. Кроме того, было показано, как создать основную или дополнительную зону. В случае основной зоны есть два способа переноса зоны из существующего файла данных — либо через редактирование вручную, либо с помошью консоли управления. Ниже рассмотрено еше несколько особых случаев перемещения зоны.
Передачи зон в системах с интеграцией DNS и WINS
Если Microsoft DNS Server интегрирован с WINS, он должен быть явно настроен для взаимодействия с серверами имен, отличными от серверов имен Microsoft (серверами UNIX). Microsoft представляет информацию WINS в DNS с помошью записей ресурсов нестандартного типа.
；Обычно серверами имен DNS в Internet используются все записи ресур- 'сов, кроме записей WINS и WINS-R. Эти записи введены специально j для взаимодействия между серверами DNS Microsoft и серверами WINS.
[ Нестандартные записи могут вызвать сбой сервера имен при попытке й приема зоны с сервера Microsoft. Старые серверы BIND могут фактиче- ；скн прекратить работу, если в передаче зоны попадутся такие записи. I Поскольку эти записи уникальны для Microsoft DNS Server, они не 'должны копироваться при передачах основной зоны в дополнительные :зоны на серверах имен DNS, где работает программа DNS, отличная от 1 Microsoft DNS Server.
' Если используется просмотр WINS или обратный просмотр WINS-R и в системе есть дополнительный сервер (не Microsoft DNS Server), надо исключить записи WINS или WINS-R из передач иа него. Также надо удалять такие записи из файлов зон при их переносе вручную на BIND.
Чтобы запретить передачу псевдозаписей WINS или WINS-R в Windows NT 4, выполните следующие действия.
■1. Запустите диспетчер DNS.
Щелкните правой кнопкой мыши на нужной зоне.
Выберите в контекстном меню команду Свойства.
Перейдите во вкладку Просмотр WINS или Обратный просмотр WINS-R, как показано на рис, 13.7.
Установите флажок Параметры действуют только на локальный сервер.
Щелкните на кнопке ОК.
Пресного VWS?j,?；Пресного VWS?j,?；,：|>ЯмоиММ5-;,：|>ЯмоиММ5-;I 1541011®I 1541011®Рис. 13.7, Настройки WINS сервера DNS в диспетчере DNS Windows NT 4Рис. 13.7, Настройки WINS сервера DNS в диспетчере DNS Windows NT 4
Пресного VWS?j,?；
Пресного VWS?j,?；
,：|>ЯмоиММ5-;
,：|>ЯмоиММ5-;
I 1541011®
I 1541011®
Рис. 13.7, Настройки WINS сервера DNS в диспетчере DNS Windows NT 4
Рис. 13.7, Настройки WINS сервера DNS в диспетчере DNS Windows NT 4
В Windows 2000 это же действие производит флажок Не выполнять репликацию этой записи во вкладке WINS или WINS-R диалогового окна свойств соответственно прямой и обратной зоны.
В Windows 2000 выполните следующие действия.
Запустите консоль управления DNS Server.
Установите фокус на зону, которую надо модифицировать.
Щелкните правой кнопкой мыши на этой зоне и выберите в контекстном меню команду Свойства.
Перейдите во вкладку WINS или WINS-R (см. рис_ 16.7 и 16.9).
Установите флажок Не выполнять репликацию этой записи.
Щелкните на кнопке ОК.
Перемещение данных зоны с UNIX на Windows и обратно
Для обмена данными зон между серверами имен UNIX и серверами имен Windows можно использовать программу nslookup, которая поставляется с серверами как первого, так и второго типа. Запустите nsiookup и введите команду server имя_сервера, где ммя_сервера — имя авторитетного сервера для зоны, которую требуется передать. Затем в Windows введите 1s имя_зоны > c:\outfile.txt, где вместо c:\outfile.txt надо подставить нужное имя файла назначения с полным указанием пути. В UNIX можно использовать стандартную переадресацию вывода в допус гимый файл. Фактически при этом информация зоны переносится с одного сервера имен на другой. Чтобы этот метод работал, машине, на которой он выполняется, должно быть разрешено принимать передачи с целевого сервера. Иногда это более удобно, чем другие средства перемещения файлов, например FTP, Это также хороший способ проверить, возможна ли передача зоны, при поиске неисправностей, однако, вероятно, в этом случае придется ограничить количество перечисляемых записей, чтобы не передавать всю зону,
Перенос всех зон на новый сервер DNS Windows 2000 с начальной загрузкой из файла
Если требуется перенести одну или больше зон со старого сервера DNS на новый, причем оба они используют Microsoft DNS Server, суше- ствует быстрый способ сделать это. Надо использовать возможность запуска службы из загрузочного файла на новом сервере. Вариант получения информации из реестра будет рассмотрен позже.
Если DNS запускается из загрузочного файла, для переноса файла (или файлов) зон выполните следующие действия (при этом, конечно, подразумевается, что на новом сервере Windows 2000 уже установлена служба Microsoft DNS Server).
Скопируйте все файлы зон В каталог Wwindirg\System32\dns.
Исправьте в каждом файле зоны записи SOA и NS, а также связанные с ними записи А.
Откройте консоль управления Microsoft DNS Server и проверьте, настроен ли сервер на загрузку из файла.
В контекстном меню сервера или меню Действие выберите команду Стоп и остановите сервер.
I 5. Запишите в загрузочный файл в том же каталоге директивы primary и secondary ДЛЯ новых зон.
;6. В контекстном меню сервера или меню Действие выберите коман-
i ду Пуск и запустите сервер.
Если изменения не видны сразу же, выберите в меню команду Обновить; обычно в этом нет необходимости.
Если требуется, верните сервер в режим загрузки из реестра.
Настройте параметры зон в их диалоговых окнах Свойства или загрузите параметры для всех зон сразу с помощью редактора реестра.
Можно также поочередно создавать зоны на консоли управления DNS Server, импортируя их из перенесенных и отредактированных файлов зон.
Перенос всех зон с одного сервера DNS Windows NT 4 на другой с начальной загрузкой из файла
Хотя необходимость в такой процед>ре уже стала редкой, опыт подсказывает, что это наилучший подход; поэтому мы приводим ее здесь для информации. Если DNS запускается из загрузочного файла, для переноса файла (или файлов) зон со старого сервера NT 4 на новый выполните следующие действия (при этом полностью заменяется вся существующая конфигурация DNS на новой машине).
В аплете Службы на панели управления остановите Microsoft DNS Server на обоих компьютерах. Это надо сделать как на старой маши не, перед получением файлов, которые будут скопированы на новый сервер, так и на новом сервере перед загрузкой перенесен, ных зон,
Вручную скопируйте все содержимое (включая подкаталоги) каталога ;Systemroot % \Systen32 \DNS со старого сервера на новый.
Перезапустите Microsoft DNS Server на новом компьютере.
После этого может потребоваться установить IP-адрес нового сервера, Друтая перенастройка клиентов производится на следующем этапе.
Перенос всех зон на новый сервер DNS Windows 2000 с начальной загрузкой из реестра
В Windows 2000 имеется два варианта загрузкм из реестра: один с хранением данных зоны в файле и другой — с хранением в Active Directory. Если хранение в Active Directory не используется, легко переключить сервер в режим загрузки из файла. Затем, выполнив обновление файлов данных сервера (на всякий случай), можно использовать любой из описанных раньше методов переноса зон. После того как зоны будут перенесены и их свойства настроены, можно снова перевести сервер в режим
загрузки из реестра. Если применяется интеграция в Active Directory, этот метод работать не будет. В этом случае лучше всего создать новые зоны на консоли управления, используя возможность импорта данных существующей зоны в мастере создания зон. Этот метод удобно использовать везде, где требуется импортировать небольшое количество зон при всех вариантах их хранения.
Перенос всех зон с одного сервера DNS Windows NT 4 на другой с начальной загрузкой из реестра
Если DNS Server NT 4 запускается из реестра, для переноса одного файла зоны выполните следующие действия.
На сервере, на который будет скопирован файл, создайте с помошью диспетчера DNS новую зону. Настройте ее в соответствии с настройкой зоны на исходном сервере как основную либо как дополнительную, Файл новой зоны должен иметь то же имя, что и исходный файл. Например, если на исходном сервере файл зоны назывался PARADISE.COM. DNS, новый файл также должен называться PARADISE.COM.DNS.
В аплете Службы на панели управления остановите Microsoft DNS Server на обоих компьютерах.
Скопируйте нужный файл зоны из папки lSysteinroot%\ System32\DNS исходного сервера в такую же папку на новом сервере.
Если необходимо, исправьте в скопированном файле записи SOA и NS и связанные с ними записи А. чтобы в них присутствовало правильное имя узла и IP-адрес новой машины.
Перезапустите Microsoft DNS Server на новом компьютере.
Ниже поэтапно описан процесс перемещения всех зон в случае, когда Windows NT 4 DNS Server запускается из реестра. Этапы 1 и 2 выполняются только на сервере, на который будет перенесена зона. Этапы 5-8 выполняются только на исходном сервере. При этой процедуре создается совершенно новый сервер и все прежние зоны на нем теряются.
В диспетчере DNS создайте пробито зону под названием sat-iple . СОМ. Создание пробной зоны гарантирует, что информация из загрузочного файла DNS Server будет записана в реестр и что DNS Server будет знать расположение кэша.
В диспетчере DNS удалите пробную зону, которая была создана на этапе 1.
В аплете Службы на панели управления остановите службу Microsoft DNS Server на обоих компьютерах.
Скопируете всю папку ^Systemroot - \Systera32\DNS исходного сервера в такую же папку на новом сервере.
Запустите редактор реестра (REGEDT32) на исходном сервере.
I 6. Перейдите к подразделу hkey_local_machine\system\
[CurrentControlSet\Services\DNS.
I 7. Выделите подраздел Zones и вызовите команду меню Реестр 力 йСохранить раздел.
口 8. Сохраните этот раздел в таком месте, откуда его можно будет вос- I I становить на новом сервере. Закройте редактор реестра.
!9. Переместите файл с разделом реестра на новый сервер.
,10. Запустите редактор реестра（REGEDT32） на новом сервере.
I' 11. Перейдите К подразделу HKEY_LOCAL_MACHINE\SYSTEM\
'CurrentControlSet\Services\DNS.
'、12. Выделите подраздел Zones и вызовите команду меню Реестр 力
Восстановить.
В диалоговом окне укажите файл, который был экспортирован с Iисходного ссрвера,
]14. Подтвердите восстановление и закройте редактор реестра.
Перезапустите Microsoft DNS Server на новом компьютере.
Информация, перенесенная в разделе реестра, содержит имена зон и ' позволяет не создавать их заново для каждой скопированной зоны в диспетчере DNS. Также переносятся необязательные параметры конфигура- , ции сервера. Однако будьте осторожны, так как неправильное применение редактора реестра может вызвать в системе серьезные проблемы, которые могут потребовать переустановки Windows NT 4. Перед тем как работать с реестром, сделайте его резервную копию.
I После завершения этой процедуры может потребоваться исправить имя узла и I P-адрес нового сервера. Начиная с этого момента можно уничтожить старый сервер и поместить новый компьютер в сеть. Лишь I это незначительное действие отделяет новый сервер от возможности про- I верить его работу под новым именем и IP-адресом, так как он, конечно, не может появиться в сети, пока работает старая машина.
Примечание
Похоже, что Microsoft DNS в Windows NT 4 не дает возможности вручную передавать зоны в целях проверки. Администратор должен ожидать, пока зона не будет передана, и после этого сам проверять результаты. Можно использовать утилиту ns Lookup для просмотра содержимого зоны и копирования его в файл, если машина, на которой работает эта программа, имеет полномочия для передачи зоны. Еще один инструмент, которым можно воспользоваться, —это Просмотр событий, где фиксируются требования на передачу зоны и сами передачи зон. Просмотр событий сообщает состояние передачи, дату и время, когда она произошла, домен, к которому она отно- ：：： сится, и имя файла зоны, который был записан И nslooKup, и Просмотр событий представляют собой лучшие средства поиска неисправностей в 笠 Windows NT 4, если служба DNS не работает.
Проблемы при работе с серверами DNS в Windows NT 4
В некоторых случаях процесс манипулирования зонами в реализации Windows NT 4 DNS Server протекает не так гладко. Например, если создать дополнительную зону и затем сделать ее основной, реестр не будет обновлен в соответствии с этим изменением. Когда вы в следующий раз запустите DNS Server, появится сообщение об ошибке, указывающее, что адрес основной зоны DNS отсутствует. В этом случае служба DNS не запустится. Также файл CACHE. DNS может быть заменен пустым файлом, что лишит вас возможности разрешать имена за пределами локальной зоны.
В Service Pack 4 для Windows NT 4 эти ошибки в Microsoft DNS Server исправлены; теперь текущий тип зоны корректно записывается в реестр. В Windows 2000 такой проблемы вообше нет.
В Windows 2000 учтены некоторые другие проблемы, которые могли произойти в Windows NT. В частности, если файл зоны содержит большое количество (примерно 100) записей А для одного имени узла (все записи отображаются на разные IP-адреса), при попытке отобразить информацию зоны пользовательский интерфейс перестает реагировать (зависает).
В это время объем памяти, используемый диспетчером DNS NT 4 (DNSADMIN.EXE) последовательно возрастает, пока система не покажет диалоговое окно с сообщением, что виртуальная память исчерпана, и рекомендацией пользователю увеличить размер файла подкачки. Через несколько минут появляется другое диалоговое окно, сообщающее, что недостаточно памяти, чтобы разместить все записи. В нижмем правом углу диспетчера DNS появляется сообщение "Нехватка памяти", а за ним — другое сообщение о нехватке виртуальной памяти. Диспетчер DNS зависает, если имеется очень много записей для отдельного узла, поскольку исчерпывается буфер RPC (удаленного вызова процедур).
Чтобы устранить эту проблему в NT 4, надо увеличить в реестре размер буфера RPC для администратора DNS. Для этого выполните сле- пуютие действия.
Запустите редактор реестра (REGEDT32.EXE).
Перейдите К разделу HKEY_LOCAL_MACHINE\Software\ Microsoft'DNS Administrator.
В меню Правка вызовите команду Добавить параметр и создайте параметр PpcBufferAlloc со значением 16384 и следующими данными.
Название параметра: P.pcBufterAlloc
Тип параметра: REG_Dword
Данные： 0-FFFFFFFF"
По умолчанию: 800 (20-18)
Описание: Этот параметр определяет размер буфера размещения
RFC для Администратора DNS.
Повторите nn. 2 и 3 для раздела HKEY_CURRENT_USER\Software\ Microsoft、DNS Administrator.
Закройте редактор реестра.
Другая проблема связана не с самим DNS Server, а с его интерфейсом управления. В NT 4. если одна илн несколько зон содержат 65535 записей, при попытке просмотра зоны в диспетчере DNS он зависает. В мо- } ниторе производительности или диспетчере задач можно обнаружить, что диспетчер DNS или консоль управления DNS Server используют до 90% ресурсов процессора.
На момент написания книги не существовало метода преодоления I этой сложности. Windows 2000 также подвержена подобному недостатку, возможно, связанному с этой же проблемой. Но здесь, в отличие от NT 4, консоль управления DNS Server продолжает работать, но показывает лишь около половины всех записей ресурсов. Таким образом, похоже, что как в NT 4, так и в Windows 2000 зоны более чем с 6 5 5 3 5 записями надо просматривать и редактировать в текстовом редакторе, таком как Word Pad или Edit.
Резюме
В этой главе представлено несколько идей и практических приемов, а также другая, не очень легко доставшаяся информация по практической работе иерархии серверов DNS. Приведены некоторые данные по серве- рам DNS на Windows NT 4, поскольку это друтая реализация DNS с другими, иногда довольно серьезными, проблемами.
宀飞14
Настройка и разрешение клиентов Windows
В этой главе...
Свойства TCP/IP клиента. Здесь на примере различных клиентских систем показано, с чего можно начать процесс настройки клиента.
Настройка клиентов длн использования DHCP. Протокол динамической конфигурации узла (Dynamic Host Configuration Protocol, DHCP) может служить для настройки у клиентов всех параметров TCP/IP. Эти параметры принимаются по умолчанию, если они не будут явно изменены на стороне клиента.
Настройка клиентов для использования DNS. Здесь показано, как настроить клиенты Windows для работы с DNS.
Настройка клиентов для использования WINS. Здесь описаны параметры настройки клиентов для работы со службой имен Internet для Windows (Windows Internet Naming Service, WINS).
Как клиент использует распознаватель Windows. В этом разделе речь идет о том, как параметры настройки действуют на поведение клиента Windows, когда требуется получить 1Р-а,трес по имени узла.
»■ Другая информация о поддержке клиента. Этот раздел посвяшен не
! которым другим вопросам: прокси-серверам WINS, обновлению ( TCP/IP-32 для MS DOS и параметрам реестра для NetBT.
彳 Компьютер, работающий под управлением Windows, может разрешать J имена различными способами, которые полностью определяются на- ■ стройкой компьютера. В этой главе показано, как настроить клиенты для ■■ просмотра имен узлов на серверах DNS и имен NetBIOS на серверах WINS. Здесь также рассказано, как и зачем можно настроить клиенты
1' для просмотра имен компьютеров NetBIOS через DNS и как всю эту настройку можно выполнить централи зован но с помошью сервера DHCP.
j Клиентские машины могут работать с множеством различных сетевых Протоколов, но эта глава уделяет особое внимание настройке TCP/IP, поскольку это необходимо для использования DNS.
'Свойства TCP/IP клиента
■ Параметры настройки, описанные в этой главе, можно найти в диалоговом окне свойств TCP/IP клиентской системы. Ниже приводится
I порядок открытия этого окна.
В Windows NT 4.0 (в Windows 95/98 принята подобная процедура) выполните следующие действия.
Откройте диалоговое окно Сеть. Для этого дважды щелкните на 1 аплете Сеть на панели управления либо щелкните правой кнопкой , мыши на значке Сетевое окружение на рабочем столе и выберите в контекстном меню Свойства.
,2. Перейдите во вкладку Протоколы и выберите в списке пункт TCP/IP.
.3. Щелкните на кнопке Свойства под списком, чтобы открыть диа
логовое окно Свойства TCP/IP или подобное диалоговое окно для других низкоуровневых операционных систем.
В Windows 2000 мало что изменилось, поэтому достаточно выполнить следующие действия.
:1. Откройте диалоговое окно Сеть и удаленный доступ к сети. Для
этого выберите одноименный пункт в меню Пуск — Настройка либо дважды щелкните на этом аплете на панели управления или сделайте один щелчок правой кнопкой мыши на значке Мое сетевое окружение на рабочем столе и выберите в контекстном меню Свойства.
Выберите объект подключения с именем по умолчанию Подключение по локальной сети и щелкните на нем правой кноп-
, кой мыши и выделите пункт Свойства, либо дважды щелкните на
1 кнопке Свойства. В результате откроется диалоговое окно Свойства подключения по локальной сети (или другого объекта подключения в соответствии с его названием).
В диалоговом окне Свойства подключения по локальной сети выделите в списке элемент Протокол Интернета (TCP/IP).
Щелкните на кнопке Свойства под списком, чтобы открыть диалоговое окно Свойства: Протокол Интернета (TCP/IP).
На рис. 14,1 показано диалоговое окно Свойства: Протокол Интернета (TCP/IP). Windows 2000. Большая часть этой главы посвящена параметрам этого диалогового окна, а особенно тем, к которым можно получить доступ по щелчку на кнопке Дополнительно. Для удобства будем называть это диалоговое окно Свойства TCP/IP,
Свойства: Протокол Интернета (TCP/IP)
Пввеиб1ри1Рногут назяачо1ксяоэтонвтичеа>и.вслисв«> •■•： ■ ■'.■ падседашаааг эту воэношость 9 противном слдчаа га^вне<ры Р моего получить a ceieeoco впммнистраюва : .
г До"кряп.Р-дорасав1онагичеа<и
•~ Ио»л»эавоть спщщюший Рчшрвс
Ммхалодсет.Ммхалодсет.ОогеЕнсилуноаОогеЕнсилуноа! 169~~ST ~W~ioo! 169~~ST ~W~iooР^Г ЙГ "Ё55 ~б-:[1 话?m [T一i — ?
Ммхалодсет.
Ммхалодсет.
ОогеЕнсилуноа
ОогеЕнсилуноа
! 169~~ST ~W~ioo
! 169~~ST ~W~ioo
■■ >^о 自 эвватьсявдуюшиаалресаОН&серееров:
Г^едПочитовг&Л DHS-cepaap-
Рис. 14.1. К большей части параметров настройки можно получить доступ, щелкнув на кнопке Дополнительно в диалоговом окне Свойства TCP/IP Windows 2000
Настройка клиентов для использования DHCP
Поскольку DHCP применяется во многих системах для доставки клиентам их IP-адресов и параметров настройки, мы начнем именно с него. Еше одна причина, по которой сленует начать с настройки DHCP клиента, — то. что параметры, полученные от сервера DHCP, применяются клиентом до тех пор, пока они не будут явно изменены на машине клиента в разделах DNS и WINS, которые описываются в этой главе ниже.
При поиске неисправностей в клиенте DHCP полезно вспомнить это и проверить, не были ли изменены первоначальные настройки DHCP.
Для применения DHCP к клиенту предъявляется единственное требование: операционная система на компьютере клиента должна поддерживаться службой DHCP. Работа DHCP возможна в следующих операционных системах.
Windows 2000 Server и Professional.
Windows NT Server 3.5, 3.51 и 4.0.
Windows NT Wokstation 3.5, 3.51 н 4.0.
Windows 95 и 98.
Windows для рабочих групп 3.11 с установленным драйвером Microsoft TCP/I Р-32 для Windows для рабочих групп.
MS Network Client 3.0 для MS DOS с установленным драйвером реального режима TCP/IP-32.
LAN Manager 2.2с (но не LAN Manager для OS/2),
Solaris 2.x и 7,
Linux (все последние дистрибутивы).
Чтобы включить клиент Windows 2000 DHCP, следует зарегистрироваться на машине клиента с правами администратора. Обычно DHCP включается в холе процедуры установки Microsoft TCP/IP. Но, если уже имеется вручную настроенный TCP/IP, можно выполнить следующую процедуру.
Откройте диалоговое окно Свойства TCP/IP.
В NT 4 выберите переключатель Получить IP-адрес с сервера DHCP и подтвердите выбор протокола DHCP в окне сообщения. В Windows 2000 этот переключатель называется Получить IP-адрес автоматически.
Поля IP-адрес и Маска подсети становятся недоступными (приобретают серый фон). Появившийся в Windows 2000 новый переключатель Получить адрес DNS-сервера автоматически позволяет использовать параметры, предоставленные DHCP, или настроить их вручную.
Обычно принимается автоматическая настройка; однако если эти параметры должны быть изменены, это можно сделать сейчас, В Windows 2000 щелкните на кнопке Дополнительно, чтобы задать адреса серверов WINS и DNS. Когда клиент, ранее настроенный вручную, переводится в режим автоматической настройки, рекомендуется удалить прежние настройки, особенно параметры WINS.
Щелкните на кнопке ОК, чтобы выйти из диалогового окна свойств TCP/IP.
Еще раз щелкните на ОК. В Windows 2000 этого достаточно. В низкоуровневых клиентах требуется еще перезагрузить компьютер.
Если для передачи IP-адреса и других параметров настройки клиентов DHCP используется сервер DHCP, не являющийся разработкой Microsoft, скорее всего, он предоставляет все обычные параметры, но не обладает некоторыми способностями Windows 2000 DHCP. Одна из них — согласование с DNS с помощью динамических обновлений, другая —параметр 81 класса пользователя и, наконец, параметры NetBIOS и WINS. Возможность обновления DNS относится к настройке сервера, а параметр S1 в настоящее время еще разрабатывается и, вероятно, еше не включен в другие серверы DHCP в такой форме, которая была бы совместима с клиентом DHCP в начальной версии Windows 2000. Чтобы передать необходимые данные настройки WINS клиентам DHCP, сервер DHCP должен иметь следующие параметры DHCP.
044 — серверы W1NS/NBNS с заданным IP-адресом одного или нескольких серверов WINS.
046 — тип узла W1NS/NBT со значением 0x1 (Ь-узел), 0x2 (р-узсл), 0x4 (m-узел) или 0x8 (h-узел).
Более подробные сведения о настройке Microsoft DHCP Server для обслуживания клиентов Windows можно найти в главе 15, "Службы DHCP в Windows.". О типах узлов подробно рассказано в главе 17, "NetBIOS: традиционные службы имен и разрешение".
Настройка клиентов для использования DNS
Как мы уже отмечали в предыдущих главах, DNS предоставляет распределенную базу данных, содержащую иерархическую систему имен для идентификации узлов в Internet. Исходная спецификация DNS пана в RFC 1034 и 1035；
Если не используется сервер DNS Windows 2000 или интеграция DNS/WINS, для низкоуровневых клиентов требуется статическая настройка IP-адресов для отображения имен на адреса в их зонах. Хотя WINS и DNS, как службы имен, могут показаться похожими. WINS может давать отображение имен на адреса динамически, поэтому при интеграции с DNS эта служба требует значительно меньших усилий по администрированию. чем DNS без динамического обновления. К низкоуровневом клиентам, лаже при отсутствии Windows 2000 DHCP, можно получить доступ через DNS, если сервер DNS настроен для использования WINS. Клиенты Windows 2000, разумеется, могут управлять своими записями в DNS, если разрешено динамическое обновление. Все это дает другим системам возможность определять местонахождение отдельного компьютера с помошью DNS стандартным способом, через регистрацию компьютера.
Во всех этих случаях, если клиент должен уметь определять местонахождение машин и ресурсов в пространстве имен DNS, он должен иметь параметры, указывающие на один или несколько серверов DNS, Эти параметры могут быть получены через DHCP или установлены вручную. Указанные параметры настраивают распознаватель TCP/IP, позволяющий определять местонахождение ресурсов в сети TCP/IP. Если службы DHCP работают в Windows 2000 Server, они также определяют, куда сервер DHCP будет посылать динамические обновления, когда эта функння разрешена.
:Установка имени узла и доменного имени р для DNS
> Чтобы установить имя узла и доменное имя DNS в низкоуровневых 'операционных системах, следует ввести их соответственно в полях Имя ■ . компьютера и Домен вкладки Конфигурация DNS диалогового окна ■ Свойства TCP/IP. Более подробно эта операция описана в разделе :''Включение DNS”.
I В Windows 2000 этот процесс немного отличается, что отражает важ- ■ ность DNS в это11 версии Windows. Компьютер как одно целое обладает признаком основной идентичности DNS в Windows 2000, как показано
^■ШВЗ^■ШВЗ■I на рис. 14.2, а интерфейсы могут иметь частные признаки идентичности ' DNS, которые описаны ниже в этой главе.
^■ШВЗ
^■ШВЗ
Qocated ин$-о^***свгога ппммтвра ■
Рис. 14.2, Установка 叩изнака основной идентичности DNS в Windows 2000
Чтобы установить признак идентичности DNS компьютера в Windows 2000, выполните следующие действия.
Щелкните правой кнопкой мыши на значке Мой компьютер на рабочем столе и в контекстном меню выберите команду Свойства или дважды щелкните на значке Система на панели управления, чтобы вызвать диалоговое окно Свойства: Система.
Перейдите во вкладку Сетевая идентификация.
Щелкните на кнопке Свойства, чтобы открыть диалоговое окно Изменение идентификации.
Щелкните на кнопке Дополнительно, чтобы открыть диалоговое окно DNS-суффикс и NetBIOS-имя компьютера.
Введите правильный основной суффикс DNS этого компьютера в одноименном поле.
Если домены DNS соответствуют доменам Windows 2000, рекомендуется установить флажок Сменить основной DNS-суффикс при смене членства в домене.
Щелкните на кнопках ОК столько раз. сколько понадобится, чтобы закрыть все диалоговые окна, и перезагрузите компьютер (это один из немногих оставшихся в Windows 2000 случаев, когда требуется перезагрузка).
Доменное имя DNS вместе с именем узла создают полностью уточ - ненное доменное имя компьютера (fully qualified domain name, FQDN). Если Windows 2000 настроена для динамического обновления DNS, для этого FQDN создаются записи А и, возможно, PTR (если другие настройки не изменят это поведение), В низкоуровневых системах домен DNS очень часто отличается от домена Windows NT или LAN Manager. В начальной версии Windows 2000 эти домены можно сделать различны\(и только после некоторых усилий, поэтому, скорее всего, в большинстве новых систем будет применяться модель, в которой доменные имена DNS и Windows 2000 синхронизированы. Записи DNS в этих низкоуровневых системах, и, следовательно, домены, где они присутствуют, управ* ляются администратором DNS либо настройкой сервера DHCP. Записи DNS для клиентов Windows 2000 управляются администратором DNS, если регистрация клиентов статическая, или параметрами настройки DNS этих клиентов, если они регистрируются динамически.
Список суффиксов DNS
Кроме определения местонахождения компьютера по запросам друшх компьютеров, имя DNS оказьЕвает влняние на работу локального распознавателя. В ходе запросов DNS локальное доменное имя DNS может определять, что будет добавляться к коротким именам. Короткое имя — это имя, которое не является FQDN. Когда распознаватель состанляет запрос к DNS, он использует список суффиксов DNS. по очереди добавляя суффиксы из списка и пытаясь разрешить имя, которое получается в результате.
Если не имеется явно заданного списка суффиксов DNS, используется список по умолчанию, Он состоит из домена DNS компьютера и всех родительских доменов, за исключением домена верхнего уровня (TLD), т.е, содержит по крайней мере два имени. Например, если полное имя компьютера —poke. hq. example . net. принятый по умолчанию список будс состоять из имен hq.example.nc；t и example.net. Имя net входить в него не будет. Заданный список суффиксов DNS просматривается точно так, как он задан. Поэто\ту, если требуется собственный домен машины, его и все нужные родительские домены следует включить в список.
Элементы настройки, с помощью которых можно контролировать 'этот список, показаны на рис. 14.5. В текстовом поле под названием i DNS-суффикс подключения в самом низу диалогового окна вводится до- 1 мен DNS, связанный с конкретным адаптером. Домен DNS, который был показан в окне Свойства: Система, рассмотренном выше, — это ос* новной суффикс DNS. Можно заметить, что в диалоговом окне на I： рис. 14.5 имеется переключатель с двумя взаимоисключающими вариан- i тами настройки распознавателя TCP/IP: добавлять основной суффикс, ；суффикс подключения и, возможно, родительские домены основного ;суффикса или использовать заданный список суффиксов. Прежние вер- :сии Windows не имели такой возможности настройки.
Включение DNS
$ В Windows 2000 нет возможности выбора, но в низкоуровневых кли- * ентах можно решить, настраивать ли компьютеры для использования f DNS, Обычно DNS будет использоваться, если используется и TCP/IP, ■® либо для связи через Internet, либо, если во внутренней сети intranet DNS % применяется для распространения информации об узлах. Если выбор J сделан в пользу применения DNS, надо настроить способ, которым ком- -；пьютер будет делать это. При этом также автоматически разрешается 卍 применение файла HOSTS, Если для автоматической настройки 1Р служит Y DHCP, эти параметры могут быть предоставлены сервером DHCP. Нл- 总 стройка DNS является глобальной для всех установленных на нмзкоуров- < Невом компьютере сетевых адаптеров, но в Windows 2000 можно задавать L некоторые дополнительные параметры для каждого интерфейса отдельно. V На рис. 14.3, 14.4 и 14.5 и в соответствующих им описаниях отражена ； процедура настройки интерфейсов для Windows 95/98, Windows NT 4.0 ” ш；' Windows 2000 соответственно. Глобальная настройка для Windows 2000 Л была показана раньше, когда рассматривалась основная идентичность '•： DNS на уровне сервера.
i Чтобы настроить компьютер, на котором работает Windows 95, для ис- £ пользования DNS при разрешении имен, выполните следующие дейсгаия.
В диалоговом окне Свойства TCP/IP перейдите во в кладку Конфигурация DNS.
Выберите переключатель Включить DNS.
Укажите имя узла и доменное имя, учитывая, что эти данные формируют FQDN данного компьютера.
Введите и добавьте один, а лучше несколько серверов DNS по их IP-адресам в области Порядок просмотра серверов DNS.
В области Порядок просмотра доменных суффиксов введите список доменных суффиксов DNS. если предполагается его использование распознавателем.
Рис. 14.3. Процесс включения DNS в клиенте Windows 95Рис. 14.3. Процесс включения DNS в клиенте Windows 95Рис. 14.4. Процесс включения DNS в клиенте Windows NT 4,0Рис. 14.4. Процесс включения DNS в клиенте Windows NT 4,0
Рис. 14.3. Процесс включения DNS в клиенте Windows 95
Рис. 14.3. Процесс включения DNS в клиенте Windows 95
Рис. 14.4. Процесс включения DNS в клиенте Windows NT 4,0
Рис. 14.4. Процесс включения DNS в клиенте Windows NT 4,0
Настройка компьютера, на котором работает Windows NT 4.0, для использования DNS при разрешении имен состоит из таких же этапов, но выглядят они несколько иначе.
В диалоговом окне Свойства TCP/IP перейдите во вкладку DNS.
Укажите имя узла и доменное имя, учитывая, что эти данные формируют FQDN данного компьютера.
Введите и добавьте один, а лучше несколько серверов DNS по их IP-адресам в области Порядок просмотра серверов DNS.
В области Порядок просмотра доменных суффиксов введите список доменных суффиксов DNS, если предполагается его использование распознавателем.
Чтобы настроить компьютер, на котором работает Windows 2000, для использования DNS при разрешении имен, выполните следутошие действия.
В диалоговом окне Свойства TCP/IP шслкните на кнопке Дополнительно, а затем перейдите во вкладку DNS.
Введите и добавьте один, а лучше несколько серверов DNS по их IP-адресам в области Адреса DNS-серверов.
Выберите переключатель Дописывать основной DNS-суффикс и суффикс подключения либо Дописывать следующие DNS-суффиксы; в последнем случае с помощью кнопки Добавить включите в список все доменные суффиксы DNS, которые предполагается использовать в распознавателе.
Во всех этих системах, как уже было сказано, необходимо помнить, что заданный список суффиксов будет применяться в том порядке, в ка-
Рис. 14,5. Процесс включения DNS в клиенте Endows 2000Рис. 14,5. Процесс включения DNS в клиенте Endows 2000[■Допопнятеньные параметра ГСРАР[■Допопнятеньные параметра ГСРАР& f .Отнеие j& f .Отнеие j
Рис. 14,5. Процесс включения DNS в клиенте Endows 2000
Рис. 14,5. Процесс включения DNS в клиенте Endows 2000
[■Допопнятеньные параметра ГСРАР
[■Допопнятеньные параметра ГСРАР
& f .Отнеие j
& f .Отнеие j
! ком он задан. Как наиболее ясно видно в Windows 2000, заданный спи- [сок суффиксов заменяет список по умолчанию, который был создан на I базе домена DNS данного компьютера.
ВЕЗ：
| Указание настроек DNS в реестре
； В системах низкого уровня можно задать для серверов DNS до трех IP- ;адресов, а в Windows 2000 — намного больше. При каждом запросе DNS 卜 распознаватель сначала пытается получить информацию DNS по первому адресу в списке. Если ответ не приходит, распознаватель переходит ко вто- ；рому серверу в списке и т.д. Чтобы изменить порядок IP-адресов в низко- \ уровневых клиентах、следует удалить их и ввести заново в нужном порядке, р, В Windows 2000 можно использовать гораздо более изящный способ — » кнопки изменения порядка. Эта настройка на компьютере, на котором ра- %6отает сервер DHCP, определяет, на какой сервер DNS будут направляться ；сервером DHCP обновления динамической DNS (DDNS).
В Windows 2000 этот список серверов хранится в разделе реестра 'HKLM\Systerri| CurrentCont rolSet\Services, в подразделе Tcpip\ t Parameters \ Interf aces\<GUID интерфейса〉，в виде строкового пара- £ Метра Nameserver. Это говорит о том, что в Windows 2000 каждый адап- :Тер можно настроить независимо от остальных. На рис. 14.6 показана эта :，область реестра, где перечислено несколько параметров, которые можно настроить для каждого интерфейса отдельно.
I-冋 XfI-冋 XfРедактор реестра - [HKLY_LdCAL_MACHiNE на локальном компьютере
I-冋 Xf
I-冋 Xf
-6symc8：Q-GO symcflj>-ГП sysoudg-口 SysmonLog-Cj TapiSrv-O Enum-О U&ege*GJ Roiemeters-6symc8：Q-GO symcflj>-ГП sysoudg-口 SysmonLog-Cj TapiSrv-O Enum-О U&ege*GJ Roiemeters■ Вмстр Омвка Структура &« бемгисностъ Параметры й^ Правка
-6symc8：Q
-GO symcflj>
-ГП sysoudg
-口 SysmonLog
-Cj TapiSrv
-O Enum
-О U&ege
*GJ Roiemeters
-6symc8：Q
-GO symcflj>
-ГП sysoudg
-口 SysmonLog
-Cj TapiSrv
-O Enum
-О U&ege
*GJ Roiemeters
Add'essType REG-DWORD 0
DMa"Gaeway REG_MUITI_S2 192168 202 4
D&lauliGalewfiyMBiric REG_MULTI_SZ 1
DhcpSeeet REG_SZ Zb5 255.255 255
DisobiBDynamjcUpdBlB REG_OWOftD 0
Do man REG_SZ
EnebieAdepterOomsm№meReg,saeg" REG_CW0RD 0
EnobleDBBdGWDeieci REG DWORD 0x1
-&AeapleFi-Й DNSRegrsieredAdapi-Olnlertaces卜 O{37A5e?EC9?A“ |-O{60E332”3?51・/-&AeapleFi-Й DNSRegrsieredAdapi-Olnlertaces卜 O{37A5e?EC9?A“ |-O{60E332”3?51・/-OPsrsisientRoules LQWir.sock-Q Pertoimnnce-О SecurityLQ SeMcePigde,-o TCWSYNC-O2NETB-OTDPIPE-CjTDSPX-О TerrnDD-g TermSeeice-OPsrsisientRoules LQWir.sock-Q Pertoimnnce-О SecurityLQ SeMcePigde,-o TCWSYNC-O2NETB-OTDPIPE-CjTDSPX-О TerrnDD-g TermSeeiceEnobleDHCP REG.0W0R0 6
-&AeapleFi
-Й DNSRegrsieredAdapi
-Olnlertaces
卜 O{37A5e?EC9?A“ |-O{60E332”3?51・/
-&AeapleFi
-Й DNSRegrsieredAdapi
-Olnlertaces
卜 O{37A5e?EC9?A“ |-O{60E332”3?51・/
-OPsrsisientRoules LQWir.sock
-Q Pertoimnnce
-О Security
LQ SeMcePigde,
-o TCWSYNC
-O2NETB
-OTDPIPE
-CjTDSPX
-О TerrnDD
-g TermSeeice
-OPsrsisientRoules LQWir.sock
-Q Pertoimnnce
-О Security
LQ SeMcePigde,
-o TCWSYNC
-O2NETB
-OTDPIPE
-CjTDSPX
-О TerrnDD
-g TermSeeice
InteriocsMetoc REG DWORD Dal iPAdSess REG_MULTI_SU 192168 202 60
IPAutocbrifiguraiioriAddress R£G_SZ 0000 |CAutoc.onfiaufaiionMa5k REG_SZ 255 255 0 0 iFAuTocontiguraijo^Seed REG_Ci'MDRl» Q
Leese R=G_DWOF(D 0*elG
LeeseObtainedTjmt REC-CWORC 0x3altbb^B
LeeseTemriaiasTma REG_0W,ORD 0*3a11c958 NqmeServer.REG SZ 127001 !
NTEContextUst REG_MULT1_SZ 0.00000002
RawiPAJiowedProiDcois REG_MULT1_S2 0
SubnetMask REG MHLTI_SZ 25；?$5 255 0
Tf REG_D\--ORD OCaltcHO
T2 REG_DWORD 0.3e1te73E
TCPAhowedPorts REG_MUlTLSZ 0
UDPAllowedPorts REG_MULTI_$2 0
Use^eroBroadcnst REG_DWOmO 0
Рис. 14.6. Настройки отдельных интерфейсов в реестре Windows 2000
Ясно, что все адреса, записанные как серверы DNS, должны соответствовать работающим DNS. Поскольку распознаватель запрашивает серверы в указанном порядке, пока один из них не ответит, слишком большое количество указанных серверов может замедлить работу пользователя в сети. Как только сервер отвечает, независимо от того, успешный этот ответ или нет, распознаватель прекращает перемещение по списку серверов. Наиболее близкие и надежные серверы следует помешать в начале этого списка.
Установка порядка доменных суффиксов DNS через текстовый файл
Порядок доменных суффиксов DNS также можно задать автоматически. Для Windows 2000 следует использовать файл UNATTEND.TXT, а не то, что предлагается в методе, описанном ниже. Для Windows NT Workstation и Windows NT Server 4.0 необходимо использовать редактор реестра, поскольку для режима автоматической установки Windows NT нет возможности указать порядок доменных суффиксов.
Создайте текстовый файл, состоящий из 口вух указанных ниже строк текста, и сохраните его под именем SUFFIX. тхт. Расположение знаков в тексте должно быть в точности таким, как показан。 ниже; вместо хххххххх. ххх нужно ввести доменный суффикс. Можно указать до шести доменных суффиксов. Порядок их просмотра — слева направо.
к \\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
g\TCPIP\Parameters
К "SearchList=textxxxx.com test2xxxx.net Зхххх.gov"
В Скопируйте файлы regini.exe и suffix.txt в подкаталог $ОЕМ$ йэталога инсталляции, regini . EXE — это утилита из Набора ресурсов windows NT.
F Создайте в подкаталоге $оем$ файл CMDLINES.TXT, если его еще не ^шествует, и добавьте в него следующую строку (включая кавычки).
Li [Commands ]
!■ ".'REGINI SUFFIX.TXT"
卜 Заголовок [Commands] должен встречаться в файле CMDLINES.TXT Только один раз.
f Убедитесь, что в разделе [UNATTEND1 файла UNATTEND.TXT имеется ^аПИСЬ OEMPREINSTALL=Yes.
ЁУстановка порядка доменных суффиксов DNS через реестр
I： Создайте файл реестра, состоящий из двух указанных ниже строк тек- 伝та, и сохраните его под именем SUFFIX.REG. Расположение знаков в ^тексте должно быть в точности таким, как показано ниже; вместо (кххххххх. ххх следует ввести доменный суффикс. Можно указать до Крести доменных суффиксов. Порядок их просмотра — слева направо.
卜 \\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
:\TCPIP\Parameters
卜 "SearchList=textxxxy.con test2x?:xx.net 3xxxx.gov"
Скопируйте файлы REGEDIT.exe И SUFFIX.REG в подкаталог $ОЕМ$ каталога инсталляшш.
!. Создайте в подкаталоге $оем$ файл CMDLINES.txt, если его еще нет, «и добавьте в него следующую строку (включая кавычки).
； [Commanos] j ".\REGINI /s SUFFIX.REG"
Заголовок [Commands) должен встречаться в файле CMDLINES.TXT только один раз,
■ Убедитесь, что в разделе【UNATTEND) файла unattended.txt имеется Запись OEMPRE工NSTALL=Yes.
И Написание кода
|В Указанный выше раздел реестра записывается в одной строке; здесь он Ш перенесен на другую строку для удобства чтения.
И Будьте осторожны при работе с редактором реестра
И Мы еще раз подчеркиваем важность внимательного использования реИ дактора реестра Любое некорректное изменение реестра может вызвать К серьезные проблемы, которые могут потребовать переустановки операцион- И ной системы!
Г
Настройка клиентов для использования WINS
Клиент, применяющий WINS, связывается с сервером WINS для регистрации своего имени в базе данных WINS к получения 1Р-；1лресон. которые отображаются на имена NetBIOS посредством запросов WINS. В настройке клиентов WINS записываются IP-адреса одного или нескольких серверов WINS; как правило, это основной и дополнительный серверы. При запуске клиенты WINS соединяются непосредственно с сервером WINS и регистрируют свои имена и соответствующие IP-адреса. Работа WINS и клиентов WINS подробно описана в паве 16. "WINS традиционные службь: имен и разрешение". Имя, регистрируемое в WINS, фактически можег содержать не только имя компьютера, но и указывать, что по этому имени могут быть получены услуги управления домена. Различные способы применения имен NetBIOS описаны в главе 17, ''NetBIOS: традиционные службы имен и разрешение1'.
Поддерживаемые клиенты
Следующие операционные системы могут в настоящее время работ a ib как клиенты WINS, если в качестве сервера WINS используется Windows.
Windows 2000 всех Bepcitii (Professional. Serve匚 Advanced Sen er. Datacenter).
Windows NT Workstation версии 3.5x или 4.0.
Windows NT Server версии 3.5x или 4.0.
Windows 95 и Windows 98.
Windows для рабочих гр\ nn 3.11 с установленным 32-разрядным стеком Microsoft TCP/IP.
Microsoft Network Client хпя MS DOS c TCP/IP-32 реального режнха
LAN Manager для MS DOS 2.2 (но не версия для OS/2).
OS/2.
Клиенты Linux и UNIX с установленным пакетом SAMBA.
Настройка клиента WINS
Клиентское программное обеспечение WINS в Windows 98 и Windows 98 устанавливается автоматически при установке Microsoft TCP/IP В Windows NT и 2000 не нужно никаких специгыьных действий, ес.ш TCP/IP установлен.
В клиентах Windows 95. Windows 9S, Windows 2000 н NT настраиваекя IP-адрес одного илн нескольких серверов WINS. Это выполняется во вкладке WINS диалогового окна Свойства TCP/IP- На рис. 14.7. 14.8 и 14.9 и в со<)г~ ветств\тощих их описаниях показана процедура настройки WINS :丄讶
Windows 95, Windows NT 4.0 и Windows 2000 соответственно. В низкоуровне- дх клиентах можно указать до двух серверов WINS. IP-адреса, присвоенные
серверам, должны быть предоставлены администратором сети. Там. где
0、оЖН。задать больше серверов, в частности в Windows 2000, первыми долж- %& быть указаны наиболее надежные н близкие серверы.
Сеойова Miuosott TCP/IP
Свойства: TCP/IPСвойства: TCP/IPРис. 14.7. Процесс включения WINS в клиенте Windows 95Рис. 14.7. Процесс включения WINS в клиенте Windows 95Au«F| DNS <иш« WWW I!рмлш)PHCF|Мвхвдппши)Au«F| DNS <иш« WWW I!рмлш)PHCF|Мвхвдппши)С<^*ва мен k*emel Дж Wrdcw，MNHС<^*ва мен k*emel Дж Wrdcw，MNHВщиЛсвсвврЗНЗ「^~"й,8 20 95ВщиЛсвсвврЗНЗ「^~"й,8 20 95Г* «елочз 0N£ ат ркпмнвмшп Wndow»
Свойства: TCP/IP
Свойства: TCP/IP
Рис. 14.7. Процесс включения WINS в клиенте Windows 95
Рис. 14.7. Процесс включения WINS в клиенте Windows 95
Au«F| DNS <иш« WWW I!рмлш)PHCF|Мвхвдппши)
Au«F| DNS <иш« WWW I!рмлш)PHCF|Мвхвдппши)
С<^*ва мен k*emel Дж Wrdcw，MNH
С<^*ва мен k*emel Дж Wrdcw，MNH
ВщиЛсвсвврЗНЗ「^~"й,8 20 95
ВщиЛсвсвврЗНЗ「^~"й,8 20 95
Р Вк^ичяь чи'^'ОТр LH^OS И«юрг LMHOSTS I
Рис. 14,8. Процесс включения WiNS в клиенте Windows NT 4,0
Чтобы настроить компьютер, на котором работает Windows 95 или Windows 98. .'ыя применения WINS при разрешении имен, выполните следующие действия.
1. В диалоговом окне Свойства TCP/IP перейдите во вкладку
Конфигурация WINS
2. Если имеется сервер DHCP, настроенный для предоставления ин-
i'формашш о доступных серверах WINS, выберите переключатель
Использовать DHCP для распознавания WINS. Если сервер WINS доступен, но недоступен сервер DHCP, выберите переключатель Г Включить распознавание WINS и введите IP-адреса основного и по- [юлиительного серверов WINS.
3. Если распознавание WINS включено, введите в поле Код области
( иленгифпкатор области компьютера, если он используется 「 (обычно ло поле оставляют пустым).
Чтобы нас гром гь компьютер, на котором работает Windows NT 4.0, для ^Применения WINS при разрешении имен, выполните следующие делствия. ('1. В диа.юговом окне Свойства TCP/IP перегшите во вкладку Адрес WINS.
2. Введите имя \зла и доменное имя, учитывая, что эти данные фор-
мнруют FQDN данного компьютера.
Введите IP-адреса основного и дополнительного серверов WINS. Если клиент получает информацию о настройке TCP/IP от DHCP, введенная вами информация заменит серверы WINS, предоставленные DHCP.
Введите в поле Код области идентификатор области компьютера, если он используется (обычно это поле оставляют пустым).
Установите флажки Включить DNS для распознавания Windows и Включить просмотр LMHOSTS, если это необхолимо (см. ниже).
Допопнитепьнве параметры TCP/IP口口!
：Пч)аг|ет[Ий Р：|：1ЭЫ8я ： WWS ] Параметры |
■ ： МЛ№«дрисо. епормха шлользоеания'
Ислальзоеание гфосматра1МНО5ТЗвлизат иавсгтоклюианиа.：.：
-нспольэянмцие ТСРЦР: ■ • ■■ 一
к Вслюмигь просмотр LMHOSTSУнп^и LMHOSTS
■：л.Бкд10читьЫе1В108маяваТСРЛР!： . ： ；" . : :-：：™ :-：； -，
5кточи，、М^Ю5черавТСР/Р
< Испо HlOBBti поронвтр NeSSOS с ОНО^серверг
Рис. 14.9. Процесс включения WINS в клиенте Windows 2000
Чтобы настроить компьютер, на котором работает Windows 2000. для использования WINS при разрешении имен, выполните следующие действия.
В диалоговом окне Свойства TCP/IP щелкните на кнопке Дополнительно, а затем перейдите во вкладке WINS.
С помошью кнопки Добавить введите IP-адреса серверов WINS для данного подключения. Можно добавить несколько серверов WINS и расположить их в порядке, в котором они бч'лут опрашиваться, но при этом наиболее близкие и надежные серверы должны быть в начале списка.
Убедитесь, что выбран переключатель Включить NetBIOS через TCP/IP. Обратите внимание на новый перек_[1ючатель для получения настроек от сервера DHCP.
!
B Windows 2000 на вкладке WINS можно заметить несколько новых элементов управления. Отключение NetBT (с помощью переключателя Отключить NetBIOS через TCP/IP) в данном контексте не имеет смысла, поскольку здесь рассматривается включение WINS. Если взаимодействле с.низкоуровневыми системами Windows не нужно, отключение NetBT эффективно блокирует обращения tcpip.sys к вспомогательной библиотеке NETBT. SYS, однако в начальной версии Windows 2000 целесообразно проверить, доступны ли все необходимые функции, прежде чем отключать NetBT. Также следует заметить, что в дихюговом окне настройки WINS в Windows 2000 нет возможности включить DNS для распознавания Windows, как в других операционных системах (потому что эта служба включена всегда; подробнее об этом вы узнаете несколько позже). Заметьте, что здесь также нет возможности задать область NetBIOS, как в других операционных системах. В Windows 2000 ее можно задать только в разделе реестра HKLM\?YSTEM\Currer.rC-?nt rolSct \ Servi ces\Net ВТ \ Paramet er s\ Scope ID или в настройках области через
{ сервер DHCP.
j Область NetBIOS
I-' Область NetBIOS может использоваться (но на практике это делается не ，часто) для разбиения пространства имен NetBIOS. Она дает возможность X взаимодействия с другими версиями NetBIOS, имеющими такой же код V области. Код области NetBIOS дописывается к имени NetBIOS в каждом 承 пакете перед его передачей. На принимающей стороне область NetBIOS в 《 пакете должна совпадать с локально заданной областью NetBIOS, иначе J пакет игнорируется. Следовательно, взаимодействовать с помощью I NetBIOS могут только компьютеры с одинаковой областью. Кроме того, в
|
коде области различаются прописные и строчные буквы; поэтому компьютер с кодом "scope" не может взаимодействовать с компьютером, имеющим код области ■15СОРЕ,\ посредством NetBIOS через TCP/IP.
Необычный случай представляет собой Windows 95, где иногда может потребоваться вмешательство пользователя. В разделе Сеть на панели управления Windows 95 и Windows 98 сначала следует включить разрешение имен WINS, чтобы можно было вручную настроить кол области NetBIOS в свойствах TCP/IP. Следовательно, надо также ввсстн хотя бы один [P-адрес сервера WINS, даже если таких серверов в сет и нет. Если Windows 95 или Windows 98 устанавливается с использованием сценария настройки, в котором указывается кол области NetBIOS, также не следует указывать wins=l и IP-адрес сервера WINS. Поскольку коды областей NetBIOS будут служить для разделения сетевого трафика, надо быгь осторожным с их назначением. При неправильном коде области пользователь не сможет соединиться с другими компьютерами. Если распознавание WINS отключено, код области NetBIOS можно изменить только вручную, отредактировав реестр следующим образом.
Запустите редактор реестра (REGEDIT.EXE).
В улье HKEY_LOCAL_MACHINE перейдите к разделу System' CurrentControlSet\Services\VXD\MSTCP.
Вызовите команду меню Правка — Создать — Строковый параметр. Введите название параметра Scope：D и нажмите <Enter>. Дважды щелкните на этом параметре. Появится окно Изменение строкового параметра. Введите код области в поле Значение.
Как клиент использует распознаватель Windows
На самом деле говорить ''распознаватель Windows'' неправильно. Компьютеры под управлением Windows имеют так много возможностей разрешения имен, что иногда трудно предугадать, как 0HH будут себя веста. Способы настройки распознавателя, которые мы фактически описывали в этой главе, когда рассказывали о параметрах настройки TCP/IP, создают огромные различия в поведении распознавателя. Иногда компьютер просто не может найти другие компьютеры в сети, даже если онн видны в списке броузера. Если вы знаете, как работают распознаватели, секреты успеха или неудачи их работы становятся чуть более раскрываемыми. Цель этого раздела ——помочь понять действие распознавателя Windows. Но прежде чем углубляться в его изучение, обратитесь к главе 17 за более подробной информацией по NetBIOS в броузере.
Предупреждение об использовании редактора реестра
二： Неправильное использование редактора реестра может вызвать серьез- 妄 ные проблемы с системой, которые могут потребовать переустановки Win
dows 95 или Windows 98.
Введение в распознаватель Windows
Распознаватель — это совокупность функций, к которым компьютер клиента обращается для использования службы имен. Распознаватель Windows размешается в файле TCPIP. SYS и его вспомогательной библиотеке NETBT.SYS. Но этих сведений недостаточно, чтобы рассказать о них. Второй из этих файлов разрешает имена узлов IP (DNS), а первый выполняет разрешение имен NetBIOS для TCP/IP. В контексте этого раздела разрешение означает получение ответа об отображении имени на 1Р-адрес.
Распознаватель UNIX работает почти исключительно с именами узлов IP. В отличие от него распознаватель Windows должен поддерживать два типа имен: имена компьютеров NetBIOS и имена узлов 1Р. Более того, распознаватель Windows должен решать, какой из нескольких возможных способов применять для разрешения. Также распознаватель должен знать, что делать, если не удается первая попытка разрешения, вторая и
■ т.Д- Распознаватель сначала должен запросить адрес у сервера имен jWINS или DNS и затем ожидать, пока не придет ответ, даже если этот * ответ будет означать, что надо запросить другой сервер или применить .Другие методы. Обычно распознаватель пробует все доступные ему спо-
do6bi, пока не найдет ответ или не исчерпает все возможности.
. Функция универсального распознавателя в операционной системе f Windows доступна всем программам, которые в ней нуждаются, особенно
и тем, которьге не умеют сами разрешать имена. Большинство приложе-
、НМ员，которым нужна служба имен, обращается к универсальному распо-
■；знавателю, задавая ему имена компьютеров, которые надо разрешить.
Распознаватель имен Windows отправляет запросы серверам имен и обрабатывает возможные ответы, которые могут от них поступить. Когда
имена разрешены, приложения, как правило, могут продолжать свою работу. Если по какой-то причине распознавателю не удается разрешить имя, он посылает локальному приложению, которое запросило службу имен, соответствующее сообщение об ошибке. Большинство приложений Windows 2000 могут воспринимать такие сообщения, информируя, в свою очередь, пользователя о неудаче разрешения.
Различия в поведении распознавателей
Разница в поведении распознавателей Windows 95, Windows 98, Windows NT и Windows 2000 здесь подробно не рассматривается, так как различия слишком велики. Приводятся лишь основные различия и описывается влияние параметров, которые можно задать в диалоговом окне свойств TCP/IP, на последовательность попыток просмотра Порядок запроса и метод определения, которые будут использованы или отклонены, определяются параметрами настройки и версией системы, а также конкретной ситуацией. Общие правила можно применить лишь для объяснения различия между отдельными вариантами настройки.
Методы разрешения Windows
В главе 17 описано шесть методов разрешения, доступных распознавателю.
Локальный кэш имен.
Широковещание NetBIOS.
Серверы WINS.
Файл LMHOSTS.
Серверы DNS.
Файлы HOSTS.
Широковешание, WINS и файл LMHOSTS работают с именами NetBIOS и используются (в основном) в NetBT ("в основном", так как есть еше возможность интеграции DNS/WINS). Два последних метода, DNS и файл HOSTS, работают с именами DNS. Для простоты мы иногда
будем говорить о ннх как о двух типах имен, или о двух возможных ре- 氷нмах работы распознавателя, или обозначать их как методы NetBIOS и методы DNS. Если клиент установил режим Включить DNS для WINS, методы NetBIOS включают и два метода DNS.
Однако выполнить разрешение — это не просто направить имя NetBIOS по маршруту NetBIOS, а лмя узла DNS — по другому пути. Проблема, во- первых, в том, чтобы определить, какого типа это имя. Во-вторых, надо знать, какие службы может использовать для этого распознаватель. Как отмечено выше, их может быть шесть. Доступны ли все службы, зависит от того, как насгросн распознаватель. И наконец, надо определить, в каком порядке распознаватель должен применять эти методы.
Поведение распознавателя Windows
К счастью, на один из этих вопросов ответить просто: из всех методов разрешения кэш имен всегда задействуется первым. Это все равно, как если бы человек вспомнил значение слова сам, прежде чем смотреть в словаре. Конечно, имеется два локальных кэша — один для имсн NetBIOS, а другой — ;и(я имен DNS. Чтобы просмотреть локальный кэш NetBIOS, введите в окне команду nbtst&t -п. Для просмотра локальною кэша имен DNS надо ввести ipconfig /di splaydr.s. Эта опция ipconfig появилась в Windows 2000 и в настоящее время еше непоступ- на в низкоуровневой NT.
Первое разллчле между версиями, на которое надо обратить внимание, — то, что Windows 2000 всегда пытается разрешить имя. использчя оба способа (если только режим NctBT включен). В этом ее отличие от всех предыдущих систем: все они сначала пробуют определить, к какому типу относится данное имя. Одно из следствий этого — то, что если задано имя NetBIOS if включена интеграция DNS/W1NS, часто запрашиваемые имена NetBIOS разрешаются из кэша сервера DNS очень быстро и с малыми затратам и. Поэтому не удивительно, что некоторые документы Microsoft рекомендуют эту конфигураиию DNS/WINS при использовании имен NciBIOS.
Другое отличие Windows 2000 от всех остальных версий в том, что в системах Windows 2000 всегда настроена DNS (или, скорее, должна быть настроена при работе в сети). Во всех остальных системах DNS необязательна. Поэтому системы низкого уровня должны определять, доступны пн методы DNS.
Вспомнив настройку свойств TCP/IP, описанную в начале этой главы, можно заметить, что и список доменных суффиксов также обрабатывается в Windows 2000 особым образом. Очевидные отличия — во-первах. пользователь располагает большими возможностями для управления списком, и, во-вторых, имеются основной суффикс DNS и суффикс для данного подключения. Этот двойной признак идентичности DNS и настройка для каждого адаптера отдельно отсутствуют во всех системах ни зкого уровйя.
Поскольку в Windows 2000 предусмотрено два маршрута разрешения, К большей части последующих рассуждений следует отнестись критически. Вместо того чтобы все время повторять "для низкоуровневых смс- тем" или "кроме Windows 2()6()", в этой главе просто описывается, как работакп все остальные системы. Просто имейте в виду, что все это относится и к Windows 2000, ес/ш отключен режим NetBT. В конце кониов, МН ведь предупредили, что эго сложная тема.
Если имя несомненно является именем DNS, например, если это FQDM или если оно имеет c/utuikoM большую длину для имени NetBIOS, с ним буд\т иметь лело только методы DNS. В противном случае, если имя неясного |троисхождения и может принад-чежать как к тому, так л к другому типу, оно пре口назначено для обоих маршрутов разрешения При попытках разрешения через NetBIOS просто запрашивается данное имя Напротив, попытки разрешения через DNS повторяются с разными суффиксами “з списка суффиксов DNS, пока не будет найдено FQDN, на коюрос придег ycncunibiii ответ. Если имя сомнительное, обычно сначала лроизволится попытка разрешения через NetBIOS; при неудаче с：1с.|)ют попытки разрешения иерез DNS при условии, что DNS включена. Трудно точно опрслслить, какое имя можно считать сомнительным Например, Windows NT допускает точку (.) в имени NetBIOS.
Но если у клиента есть режим Включить DNS для WINS и он установлен. имена NetBIOS переадресуются методам DNS, т.е. они также должны использовать список суффиксов. Когда этот режим включен в NT 4.0, разрешение имени NetBIOS начинается с метода DNS. Чтобы подобны!! порядок был возможен в Windows 95. надо отредактировать реестр. В сушности, этот режим подразумевается в Windows 2000, но, как можно замениЬ' он нс отражен в ди;итоговом окне Свойства TCP/IP. Полная на- сцюика (iHTei'paiiiiif DNS/WINS. как показано в главе 16, может быть очень важной 山旧 1аранпш. что этот маршрут для разрешения NetBIOS бупет успешным. В э,ом случае важно 1аюке убедиться, что у клиента нз- строек список суффиксов DNS, подходяший для интеграции DNS/WINS. Даже без интеграции DNS/WINS, если используются статические IP- адрсса, применение одного и того же имени в обоих пространствах имен и надлежащая регистрация DNS могут сделать этот способ полезным.
Порядок применения методов NetBIOS зависит от типа уз,】а NetBIOS клиента '^го подробно описано в「.】аве 17. Обычно не рекомендуется использовать Широкове танке NclBIOS везде, кроме очень маленьких систем. Если клиент настроен для работы с WINS, его узел будет гибридным (h- узе.г!) т с 6\;】ет использовать трансляцию в сам\ю последнюю очередь, после тоги, как все прямые поаклютення к указанном серверам WINS не дадут результата. Utq6i>i узнать тип узла к_пиента, можно использовать команду lcc：：-；fij /а! 1 в Windows NT 廿 2000 или соотвегствующую ей команду wief •「с и Windows 95 и Windows 98 (подробнее об этих командах ск. главу 12, ''Средства поиска неисправностей''). Их действие показано на рис. 14.10 для NT 4.0 и на рис. 14.11 — для Windows 95. В Windows 2000 ipyiEL? имеет「орпзло больше параметров, но с помощью параметра /ii j можно вывести иочш ；акие же данные. Наиболее часто встречаются типы узлов NetBIOS "гибридный'' и ■■широковещательный''.
Рис. 14.10. Просмотр конфигурации TCP/IP в NT 4.0 с помощью ipcorifig /all
Если тип имени сомнителен и разрешить его как имя NetBIOS не удалось, при следующих попытках оно рассматривается как имя DNS, но только при условии, что клиент настроен для использования DNS и, согласно этой настройке, методы DNS еще не применялись, В основном это бывает при работе с DNS устаревших клиентов,
Еше один способ, который может быть полезным, хотя и вышел из употребления, заключается в предварительной загрузке кэша распознавателя NetBIOS из файла LMHOSTS. Описание этого способа можно найти в приложении А. С появлением WINS эти файлы стали в основном ненужными, однако многие администраторы все еше пользуются ими как средством для восстановления информаиии при отказе WINS, особенно на серверах, образующих ядро системы. 5йл полезен также в том случае, если из него следует, что клиент должен нспюльзовпть безопаснь市 канал на конкретном контроллере домена.
Другая информация о поддержке клиента
Этот раздел посвяшен нескольким функциям, которые могут быть полезны в некоторых случаях. В их число входят пгфаметры peecipa, связанные с NetBT. К другим функциям — прокси-серверам WINS — обращаются редко, но они необходимы при поддержке устаревших клиентов, которые не работают непосредственно с WINS, но могут использовать NetBIOS. Кроме того, здесь представлены данные об ограничениях MS DOS как при использовании 32-ра)рялного драйвера TCP/IP-32, так и без него.
Рис. 14,10, Просмотр конфигурации TCP/IP в Windows 95 с помощью winipcfq /all
I Прокси-серверы WINS
Г Сетевые клиенты на базе Windows могут использовать WINS непо- 1 средственно. Компьютеры без поддержки WINS, совместимые с Ь-узламн I (как это опнсано в RFC 1001 и 1002) могу г обращаться к WINS через [ прокси-серверы. Прокси-серверы WINS — это компьютеры с поддерж- кой WINS, которые принимают регистрации имен и запросы и пересылают их на сервер WINS.
Когда клиент без поддержки WINS запрашивает разрешение имени, 'он фактически опрашивает все принимающие машины, знают ли они, где находится компьютер, указанный в запросе. На этот вопрос может ответить любой клиент NetBIOS, если он является искомой машиной, или если искомое имя имеется в его кэше. Прокси-сервер вмешивается в I этот процесс и соединяется с сервером WINS для разрешения имен, на которые нет ответа. Он играет роль посредника, передавая запрос серверу WINS и возвращая е「о ответ клиенту. Когда прокси-сервер обрабатывает объявление нового имени, он соединяется с сервером WINS, но имя не регистрируется Клиент только информируется о том, доступно ли имя для использования; объявленное имя не резервируется путем регистрации в WINS.
На платформе Windows NT 3.51 прокси-сервер назначается установкой флажка' Включить прокси-агент WINS в диалоговом окне [ Дополнительная настройка Microsoft TCP/IP.
! На платформе Windows NT 4.0 ичи Windows 2000 для того, чтобы на- :значить прокси-сервер, в редакторе реестра (REGEDT32.EXE) следует добавить новую запись, которая могла бы быть воспринята как указание, что в
I данный момент эти системы не должны сами разрешать имена через
WINS. В любом случае, чтобы настроить прокси-сервер WINS, oip3g“- руНте раздел реестра HKLMXSybtc-rrXCdrrentCoriLrolSe^XSE-i Vi-c Netbt\ par abaters на компьютере, который должен стать прокси сервером. Значение 1 параметра EnableProxy включает эту функцию,,； значение 0 — отключает. Если вы собираетесь использовать проксисерверы WINS, убедитесь, что они размешены в каждом сегменте сеги, содержащем клиенты без поддержки WINS, и что онн легко доступны Олп ко лучшее решение на сегодняшний день — это замена старых спеем
MS DOS и драйвер TCP/IP-32
MS DOS-реализация TCP/IP для Microsoft Network Client версии g П для MS DOS поддерживает следующие функции.
Интерфейс на базе MS DOS.
Распознаватель доменных имен (DNR) xim рарешения имени уз в IP-адрес, если в вашей сети имеется сервер DNS.
Протокол динамической конфигурации хзла (DHCP)
Разрешение WINS.
Функции Windows Sockets.
Следующие функии», предоставляе.\(ыс TCP/IP-32 для Windows 丄 1】 рабочих групп 3.11, TCP/IP-32 для Windows 95 и Windows NT W'oiksmiio . и Server версий 35 3.51 и 4.0, клиентами на базе MS DOS не по vicpAii ваются.
Разрешение WINS с помощью DNS
Регистрация имен в базе данных WINS. Учтите, что компьютеру MS DOS — это клиенты, а не сервера, и полому регией рация им как правило, нс нужна.
Работа в качестве прокси-узла WINS.
Поддержка нескольких сетевых адаптеров.
Поддержка межсетевого протокола управления группами (Intciih' Group Management Protocol. IGMP).
Параметры TCP/IP в реестре
Очень многие параметры ТС P/IP находятся в разделе pcecijit HKSY_LOCAL_MACKINE\SYSTEM\Cjrгеп*-Ccr.trolf：et \ Services\亡 oip ' arareters. Основную их часть можно изменять ;пя гочной регулировк；' работы TCP/IP, так как они влияют на обшито прои!вол!ие.iьно(.ть 7” uihны и на ее сопротивляемость сетевым атакам. Большую часть нео6\о димых настроек можно выполнить в интерфейсе Windows, поэтому он;: здесь не упоминаются. Мы расскажем только о нескольких из множеств ： параметров, которые могут представлять интерес
[Параметр DatabasePath
；\ Параметр DatabasePath указывает для служб Winsock расположение (■стандартных файлов ааннмх Internet (HOSTS. necwcrKs, piciocjj.，, services) it файла L：<HCS7S. Атрибуты этого параметра слс/пющис.
Раздел: Tcpip\Parc^,eters.
♦■ Тип значения: ?EG_EXPAND_SZ.
Диапазон значений: любой допустимый п\ть.
■■ Значение ПО умолчанию: ^Systeir.Root1- \ syst^n 32\cir ivc г s\^ic.
Параметр DisableDHCPMediaSense
. Параметр DisableDHCPMediaSense отключает jcihchг DHCP там, где при обнаружении события считывания с носичеля он получает аренду ,(по событию подключения) или отменяет интерфейс и связанную с ним Информацию (по событию отключения). Атрибуты лого параметра следующие.
Раздел： Tcpip\E,araK1Rtcrs.
Тип значения: reg^dword
Диапазон значений: 0, 1 (0 — пожь. 1 — истина),
Значение по умолчанию: 0.
Параметр EnableDeadGWDetect
Если параметр EnableDeadGWDetect включен (по \молчанию), он разрешает TCP изменять !Р используемого шлюза в случае проблем на нескольких полк_чючсниях и при наличии другого иасгросииого шлюза, ' Атрибуты этого параметра следующие.
Раздел： Tcpjp\Parameters.
в Тип значения: reg_dword.
Диапазон значений： 0, 1 (0 — ложь, 1 — истина).
■ Значение ио умолчанию: 1.
Параметр IPAutoconfigurationEnabled
Параметр IPAutoconfigurationEnabled МОЖНО установить глобально или для каждого интерфейса отдельно Он определяет, обратится ли клиент к автонастройке IP, если не удастся найти сервер DHCP. Атрибуты этого параметра следующие.
■ Раздел: TcpipVPard^eLers.
■ Раздел: Tcpip\Pa二ат.е:ег$\工Titerfaces\<;ii-.rep?c・;Zt>.
■ Тип значения: REG_DVJORD.
Диапазон значений: 0, 1 (0 — ложь, 1 — истина).
Значение по умолчанию: 1.
Параметр IPAutoconfigurationSubnet
Параметр IPAutoconfigurationSubnet можно установить глобально илк для каждого интерфейса отдельно. Он определяет подсеть IP. и) которой автонастройка IP получит IP-адрес для клиента, если не удастся найти сервер DHCP, Атрибуты этого параметра следующие.
Раздел: Tcpip'Parameters.
Раздел： Tc；pip\Parameters\Interfaces\<wHTep$eiic>.
Тип значения，reg_sz.
Диапазон значений: допустимые подсети IP.
Значение по умолчанию: 169.2 54 . 0 . С.
Параметр IPEnableRouter
Параметр IPEnableRouter разрешает протоколу IР перенаправлять пакеты с одного сетевого подк.11ючсния на другое. Атрибуты этого параметра следующие.
Раздел： Tcpip\Pardmetcrs.
Тип значения: reg_evjord.
Диапа юн значении' 0. I (0 — ложь, 1 — истина).
Значение по умолчанию: 0.
Параметр SynAttackProtect
Параметр SynAttackProtect разрешает протоколу TCP регулировать скорость г1средачи, чюбы тайм-аут при попытке соединения мог происходить быстрее, чем обычно. Это делается, если значение параметр,】 ТСРГ--ахЕ-:огI ^Exhausted свидетельствует о синхронной атаке на сервер- Атрибуты это! о параметра следующие.
Разде；1： Tcpip\P = raraetei~
Тип значения: reg_dword
Диапазон значений： 0, I (0 — ложь, 1 — истина).
Значение по умолчанию： 0.
Параметры клиента DNS в реестре
В разделе реестра HKEY_LOCAL_?-1ACHINE\SYSTEM\Cur rent Centre：- SeL\s&rvice^XTcplcAEararrieters содержится множество параметров, связанных с разрешением DNS и динамической регистрацией клиентов
* DNS. Эти параметры перечислены в следующих подразделах. Есть также несколько параметров, управляющих распознавателем DNS и его кэшем, [В том числе параметр, позволяющий отключить его (в разделе реестра: \hKEY_LOCAL_：<ACH1 NE\SYSTEM\CurrentCortrclSet\Services\DNScach ''Parameters). Эти параметры здесь не приводятся.
Параметр DefaultRegistrationTTL
Параметр DefaultRegistrationTTL определяет время, которое ука- i знвается в требовании регистрации DDNS. Атрибуты этого параметра ' следующие.
Раздел: Tcpip\PaiametLGrs.
. а Тип значения' REG_DWORD (в секундах).
Диапазон значений: 0-0xFFr;I~FFFF
Значение по умолчанию: 0х4В0 (1200 секунд. 20 минут).
Параметр EnableAdapterDomainNameRegistration
' Параметр EnableAdapterDomainNameRegistration устанавливается ；для каждою интсрфс1!са олдельно н указывает, что в регистрации DDNS ' должно использоваться настроенное доменное имя адаптера. Если значе- ■ ние 「isahleCynarnLcUodate равно 0, а значение этого параметра — I, интерфейс регистрируется под сбохмн доменными именами. Атрибуты ,этого параметра следующие.
Разде.Т Tcoit-^ "araiTieter5\Interfaces\<ZHTepQe>ic>,
Тип значения: £lU_dword.
Диапазон значений: 0, I (0 ~ ложь, 1 — истина).
Значение по умолчанию： 0.
Параметр DisableDynamiclIpdate
， Параметр risabl eDy-ami cupdace можно установить как глобально, ‘ так и для каждого интерфейса в отдельности. Он разрешает или запрещает регистрашпо DDNS. Атрибуты этого параметра следующие.
Раздел. Tupi p\Pararrieter s.
Раздел: Tcpip\Farajreters\Interfасез\<интерфейс>.
Тип значения: reg_dword
Диапазон шачений. 0, I (0 — ложь, 1 — истина).
Значение по умолчанию' 0.
Параметр DisabieReplaceAddressesInConflict
Параметр DisableReplaceAddressesInConflict МОЖНО установить глобально. Он определяет, как будет вести себя клиент DNS при обнаружении регистраиии DNS, конфликтующей с той. которую он хочет создать для себя. Атрибуты этого параметра следующие.
Раздел： Тер ip \ Parameters.
Тип значения: REG_DWORD.
Диапазон значений: 0, 1 (0 — ложь, 1 — истина).
Значение по умолчанию: 0.
Параметр DisableReverseAddressRegistrations
Параметр DisableReverseAddressRegistrations можно установить как глобально, так и для каждого интерфейса в отдельности. Он запрещает регистрацию записей ресурсов PTR клиентом DDNS. Атрибуты этого параметра следуюшие-
Раздел： Tcpip\Parameters.
Раздел： Tcpip\Pararrieters\ Inter faces \<интерфейс>.
Тип значения: reg_dword.
Диапазон значений: 0, I (0 — ложь, 1 — истина).
Значение по умолчанию: 0.
Параметр UpdateSecurityLevel
Параметр UpdateSecurityLevel является глобальным. Он устанавливает предполагаемый уровень безопасности при динамическом обновлении DNS. По умолчанию (0x0) производится попытка незашишенного обновления, а затем, если необходимо — попытка безопасного обновления. Другие значения этого параметра определяют такое поведение клиента: 0x00000010 — не использовать безопасность, 0x00000020 — использовать безопасность, и 0x00000100 — использовать только безопасное обновление. Атрибуты это,'о параметра следующие.
Раздел： Tcpip\Parameters.
Тип значения: reg_dword.
Диапазон значений: 0, 0x000000010, 0x00000020, 0x00000100.
Значение по умолчанию: 0.
Параметр AllowlInqualifiedQuery
Параметр AllowUngualif iedQuery указывает, будет ли распознаватель посылать в DNS запрос, содержащий только имя узла. Если он отключен- то, например, запрос на разрешение имени компьютера cowpoke в домене
range. com преобразуется в запрос DNS на cowpoke. range. com. Если этот \ параметр-в)счючен, cowpoke, будет отправлено в запросе DNS как полное \нмя. Атрибуты этого параметра следхтошие.
'\ ■ Раздел： Tcpip\Parameters.
,\ ■ Тип значения: reg_dword
■ Диапазон значений: О, I (0 — ложь, 1 — истина).
Значение по умолчанию: 0.
ГЬраметр DisjointNamespace
Параметр DisjointNamespace определяет, будет ли распознаватель 【рассматривать каждый интерфейс как отдельное пространство имен DNS. ,Если он включен, распознаватель будет при необходимости опрашивать ：все интерфейсы, пока не получит результат. Атрибуты зтого параметра 、следующие.
Раздел： Тсрд.р\Parameters.
'■ Тип значения: reg_dword.
Диапазон значений: 0, 1 (0 — ложь, I — истина).
I ■ Значение по умолчанию: 1.
I Параметр UseDomainNameResolution
' Параметр UseDomainNameResolution определяет, будет ли распо- 'знаватель формировать запросы DNS для сомнительных имен, дописывая ；к ним домен клиента, родительский домен и так далее, кроме домена первого уровня. Атрибуты этого параметра следующие.
'■ Раздел: TcvipXPara^e^ers.
Тип значения: REG_DVJORD.
Диапазон значений: 0, 1 (0 — ложь, 1 — истина).
Значение по умолчанию: 0.
Параметры NetBT (NetBIOS через TCP/IP) в реестре
Все параметры NetBIOS через TCP/IP размешаются в следующих подразделах раздела реестра HKEY_LOCAL_MACHINE\SYSTEM\Current- ■ ControlSet \ Servic(:s\.
■ Netbt\Parameters.
；■ "etbt\Adapter?\<；｛йзьан;<е адагтера> В NT 4.0 (где〈название
ада^-?ера> означает подраздел для сетевого адаптера, с которым связан NetBT, например LanceOl).
Netbt\Parameters\Interfaces\<GUID интерфейса> в Windows 2000 (где <GUID интерфейса> — уникальное имя, присвоенное системой интерфейсу).
Значения в последних двух подразделах устанавливаются отдельно для каждого адаптера (интерфейса). Чтобы изменение этих параметров произвело эффект, необходима перезагрузка системы, если только клиент не использует DHCP. В последнем случае для изменения настроек NetBT можно использовать команду ipconfig /renew.
f； Может потребоваться перезагрузка
二 Чтобы гарантировать, что регистрация прошла полностью, сервер должен быть перезагружен. При этом восстанавливаются записи адресов WINS, если опция nbtstat -RR недоступна.
В ходе установки компонентов TCP/IP некоторым описанным ниже параметрам присваиваются значения по умолчанию, указанные в инсталляционных файлах. Не все из этих параметров всегда имеются в реестре Для их настройки также можно использовать редактор реестра.
Приведенный ниже список не является исчерпывающим, но представляет наиболее часто используемые или интересные параметры. Сюда не входят параметры DHCP, в которых клиент DHCP хранит значения, полученные от сервера DHCP. Эти параметры нельзя установить непосредственно. Из параметров NetBIOS в списке приводится около половины. Отсутствующие параметры регулируют значения тайм-аута для различных типов запросов, управляют созданием соединений NetBIOS, регулируют кэширование имен NetBIOS и поведение в многосетевых системах, а также определяют работу с прокси-серверами.
Параметр NetbiosOptions
Этот параметр реестра Windows 2000 отсутствует в Windows NT. Параметр NetbiosOptions определяет, включена ли в интерфейсе NetBIOS (значение 1) или отключена (значение 2). Его можно задать в диалоговом окне Свойства TCP/IP, выбрав переключатель Включить NetBIOS через TCP/IP; непосредственно изменять его в реестре не нужно. Если этого раздела не существует. используется значение параметра DHCPNetbiosOptions (если он су- шествует), которое можно настроить только через DHCP. Если же параметр NetbiosOptions существует, DHCPNetbiosOptions игнорируется. Атрибуты этого параметра следующие.
Раздел： Netbt\Parameters\Interfaces\<интерфейс>.
Тип значения: REG_DWORD.
Диапазон значений; 1 — включено, 2 — отключено.
Значение по умолчанию: 1.
[Параметр UseDNSOnlyForNameResolutions
к Этот параметр реестра Windows 2000 отсутствует в Windows NT. Его мож- \но использовать для запрещения всех запросов на имена NetBIOS. Сам по Дебе интерфейс NetBIOS он не отключает, и регистрация имен и обнонление Продолжают происходить. Атрибуты этого параметра следующие.
\ ■ Раздел： Netbt\Parameters.
\・ Тип значения: reg_dword.
Диапазон значений: 0, 1 (0 — ложь, 1 — истина).
Значение по умолчанию: 0.
Параметр SMBDeviceEnabled
Этот параметр реестра Windows 2000 отсутствует в Windows NT. Параметр SMBDeviceEnabled можно использовать для отключения нового компонента :SMB (Server Message Block), который определен в Windows 2000 как сетевой ^транспортный протокол. Агрибуты этого параметра следующие.
Раздел： Netbt\Parameters.
I ■ Тип значения: reg_dword.
L ■ Диапазон значений: 0,1 (0 — ложь, отключено; 1 — истина, включено).
Значение по умолчанию: 1.
^Параметр NodeType
■ Параметр NodeType определяет поведение клиентской системы при 丨 регистрации и разрешении имен NetBIOS. Атрибуты этого параметра следующие.
；■ Раздел： Netbt\Parameters.
;■ Тип значения: reg_dword.
Г ■ Диапазон значений: 1,2,4,8 (1 — Ь-узел, 2 ~ р-узел, 4 т-узел, 8 — h-узел).
Значение по умолнанню: 1 или 8 в зависимости от статуса системы как клиента WINS.
:Параметр SessionKeepAlive
Параметр SessionKeepAlive определяет интервал между соедине- ,Ниями поддержки сеанса NetBIOS, которые поддерживают неактивные г сеансы в открытом состоянии. Временной интервал указывается в мил- ,лисекундах, а значение OxFFFFFFFF отключает поддержку сеанса. Атрибуты этого параметра следующие.
Раздел: Netbt\Parameters.
Тип значения: REG_dword (в миллисекундах),
Диапазон значений: 60000-0xFFFFFFFF.
Значение по умолчанию: 3600000 (1 час).
Параметр WinsDownTimeout
Параметр WinsDownTimeout определяет, как долго клиент будет ожидать после того, как все попытки соединиться с настроенными серверами WINS не увенчаются успехом. Временной интервал указывается в миллисекундах, и после его истечения клиент предпринимает новую попытку. Этот параметр служит для ускорения процесса загрузки отключенных клиентов. Атрибуты этого параметра следующие.
Раздел： Netbt'Parameters.
Тип значения: REG_dword (в миллисекундах).
Диапазон значений: 1000-0xFFFFFFFF.
Значение по умолчанию: 15000 (15 с).
Параметр NameServerList
Этот параметр реестра Windows 2000 отсутствует в Windows NT. Параметр NameServerList указывает IP-адреса серверов WINS. Если в нем содержится допустимое значение, оно заменяет значение (или значения), полученное через DHCP. Этот параметр можно установить в диалоговом окне Свойства TCP/IP; задавать его непосредственно в реестре не нужно. Атрибуты этого параметра следующие.
Раздел: NeCbt\Parameters\InCerfaces\<интерфейс>.
Тип значения: REG_multi_sz (список IP-адресов из десятичных чисел, разделенных точками; адреса отделяются друг от друга пробелами, например 11,101,1.200 11.101.3.300).
Диапазон значений: любой допустимый 1 Р-адрес.
Значение по умолчанию: пусто (нет адресов).
Параметр NameServer
Этого параметра реестра Windows NT 4.0 уже нет в Windows 2000. Параметр Nameserver указывает IP-адрес основного сервера WINS, Если в нем содержится допустимое значение, оно заменяет одноименный параметр DHCP. Данный параметр можно установить в диалоговом окне Свойства TCP/IP; задавать его непосредственно в реестре не нужно. Атрибуты этого параметра следующие.
Раздел: Netbt\Adapters\<Ha3BaHMe адаптера〉.
Тип значения: reg_SZ (IP-адрес из десятичных чисел, разделенных точками, например 11.101.1,200).
'■ Диапазон значений: любой допустимый 1Р-адрес.
卜 ■ Значение по умолчанию: пусто (нет адресов).
^Параметр NameServerBackup
:\ Этот параметр реестра Windows NT 4.0 уже не используется в 匕诚ndows 2000. Параметр NameServerBackup указывает IP-адрес резерв- ,лого сервера WINS. Если в нем содержится допустимое значение, оно j заменяет одноименный параметр DHCP. Данный параметр можно уста- ；новить в диалоговом окне Свойства TCP/IP; задавать его непосредственно в реестре не нужно. Атрибуты этого параметра следующие.
.、■ Раздел： Netbt\Adapters\<H33BaHne адаптера〉.
Тип значения: reg_sz (IP-адрес из десятичных чисел, разделенных точками, например 11.101.1. 200).
■ Диапазон значений: любой допустимый 1Р-адрес.
:■ Значение по умолчанию: пусто (нет адресов).
「Параметр NameServerPort
К
Параметр NameServerPort определяет номер порта назначения WINS, на который NetBT будет направлять пакеты службы имен, т.е. за- ，просы и регистрации. Microsoft WINS принимает данные из порта 0x89 ■ (десятичное значение 137). Серверы имен NetBIOS других разработчиков I могут использовать другие порты. Атрибуты этого параметра следующие, j ■ Раздел： Netbt\Parameters. - t ■ Тип значения: reg_dword (номер порта UDP).
Диапазон значений: 0—OxFFFF.
Значение по умолчанию: 0x89.
:ГЬраметр NameSrvQueryCount
•• Параметр NameSrvQueryCount определяет, сколько раз NetBT будет [ направлять на сервер WJNS запрос на одно и то же имя, если ответ не I, приходит. Атрибуты этого параметра следующие.
卜■Раздел： Netbt\Parameters.
г - ■Тип значения: reg_dword (количество раз).
；■Диапазон значений: 0—OxFFFF.
卜■Значение по умолчанию: 3.
Параметр NameSrvQueryTimeout
Этот параметр задает период ожидания между попытками послать на сервер WINS запрос на одно и то же имя. Атрибуты этого параметра следующие.
Раздел： Netbt\Parameters.
Тип значения: reg_dword (время в миллисекундах).
Диапазон значений: 100—OxFFFFFFFF.
Значение по умолчанию: 1500 (1,5 с).
Параметр BroadcastAccess
С помощью параметра BroadcastAccess можно заставить NetBT использовать конкретный адрес для всех широковещательных пакетов службы имен. По умолчанию NetBT применяет адреса широковещания с подстановкой единиц для каждой сети (например, для сети 11.101.0.0 с маской подсети 255.255.0.0 адрес широковещания подсети будет 11,101.255. ?55) Если же, например, в сети принят адрес широковещания с подстановкой нулей (этот режим задается параметром ТСР/1 Р UseZeroBroadcast), то в предыдущем примере адрес широковещания подсети будет 11.101.0,0, а значение этого параметра — 0х0А650000 Это глобальный параметр и используется во всех подсетях, с которыми связан NetBT. Обычно этого параметра в реестре нет, но его можно создать, чтобы изменить стандартное поведение драйвера протокола NetBT. Атрибуты этого параметра следующие.
Раздел: Netbt\Parameters.
Тип значения: reg_dword (IP-адрес в прямом порядке, состоящий из 4 байт).
Диапазон значений: 0—OxFFFFFFFF.
Значение по умолчанию: адрес широковещания с подстановкой единиц каждой сети.
Параметр EnableDNS
Если параметр EnableDNS равен 1 (истина), NetBT будет запрашивать в DNS те имена, разрешить которые через WINS, широковещание или файл LMHOSTS не удалось. В NT 4.0 это происходит в первую, а не в последнюю очередь. Этот параметр можно установить в ди;шоговом окне Свойства TCP/IP; задавать его непосредственно в реестре не нужно. Атрибуты этого параметра следующие.
Раздел: Netbt\Parameters.
Тип значения: REG_DWORD (Boolean).
Диапазон значений: 0, 1 (0 — ложь, 1 — истина).
Значение по умолчанию: 0.
Параметр DNSServerPost
I Параметр DNSServerPort указывает, какой порт протокола UDP Применяется, когда NetBT посылает запросы в DNS. Атрибуты этого параметра следующие.
Раздел: Netbt\Parameters.
Тип значения: reg_dword.
Диапазон значений: O-OxFFFF.
Значение по умолчанию: 0x35 (десятичное значение 53).
Параметр EnableLmhosts
Если параметр EnableLmliosts равен 1 (истина), NetBT будет искать в файле LMHOSTS те имена, разрешить которые другими способами не удалось. По умолчанию каталога базы данных (который указывается в параметре Tcpip\Parameters\DatabasePath) не существует, ПОЭТОМУ поиск в LMHOSTS не производится. Этот параметр можно установить в диалоговом окне Свойства TCP/IP; задавать его непосредственно в реестре не нужно. Атрибуты этого параметра следующие.
Раздел： Netbt'Parameters.
Тип значения: reg_dword (Boolean).
Диапазон значений: 0, 1 (0 — ложь, 1 ——истина).
Значение по умолчанию: 1.
Параметр ScopelD
Параметр ScopelD определяет область имен NetBIOS для компьютера. Его значение, если оно допустимо, заменяет одноименный параметр DHCP. Значение * задает пустую область и также заменяет параметр DHCP. Значение этого параметра не может начинаться с точки (.); пустое значение игнорируется. Этот параметр можно установить в диалоговом окне Свойства TCP/IP； задавать его непосредственно в реестре не нужно. Атрибуты этого параметра следующие.
Раздел: Netbt\Parameters.
Тип значения: REG_sz (строка символов).
Диапазон значений: любое допустимое доменное имя DNS, состоящее из двух частей, разделенных точкой, или звездочка (*).
Значение по умолчанию: нет.
Резюме
В этой главе довольно подробно описана настройка клиентов Windows для работы со службами имен WINS н DNS. Вслед за этим рассматриваются практические приемы, позволяющие понять все разнообразие сценариев разрешения для клиента в различных версиях Windows.
15
Службы DHCP в Windows
3 этой главе...
( Рассматривается установка н HacrpoitK：i сервера протокола динамиче- %ой конфигурации у^ш〈Dynanxc Host Configuration Protocol, DHCP), uc- 1：ользованне c.】y*6 DHCP для упрощения управления пространством 触ен DNS с помощью динамических обновлении, а также вопросы на- 1ройки KiHiUTa и параметры областей.
„ DHCP ynpom.iei управление： клиентской машиной за счет передачи ииенту 1Р-алресов и друт их парамстров настройки по его требованию Срез сеть. Прн эгам также сохраняется запас IP-адресов, поскольку они ыделякися клиентам только пя временного пользования. Обновления Sdns позволяют серверу DHCP делать записи в фай_пах зон DNS, что pKpamaei объем работы, необходимой для адм и н иезрирован ия DNS. Обновление DNS через DHCP особенно полезно в кратных системах, ак как нс только сокращает объем вмешательства гшминистратора DNS, 【0 и. что более важно, уменьшает потребность в непосредственной на- Гройке администратором клиентских машин и повышает их мобиль- Ость. В особенности зто слносшся к ютиентам низкого уровня, которые, 'отличие от клиентов поз }праи；1ением Windows 2000, часто не могут ^менять у себя DDNS.
■ Что такое DHCP. Краткая история DHCP и обзор его возможности
■ Установка сервера DHCP. Описываются этапы установки DHCP в Windows 2000.'
■ Настройка сервера DHCP. Рассматриваются определение областей “ установка параметров, разрешение аренды и возможные ограничения
■ Настройка клиентов для использования DHCP. Кратко излагаются вопросы настройки на стороне клиента и приводятся ссылки ма подробное изложение процесса настройки клиента в главе 14, ''Настройка и разрешение клиентов Windows".
■ DHCP в сравнении с ВООТР. Рассматривается ВООТР и поддержка клиентов ВООТР серверами DHCP.
До сих пор настройка DNS как базы данных, отображающей имена узлов на IP-адреса, была относительно простым делом. Узлам в сети бм- ли присвоены IP-адреса, и соответствующие записи ресурсов (RR) вносились в нужный домен DNS. Это выполнялось либо вручную для icni- ентов низкого уровня, не подцерживаюших DDNS, либо автоматически при загрузке клиентов Windows 2000.
Но что, если бы существовал способ автоматического присвоения 13 адрссов? И если бы можно бььчо в то же время автоматически регистрировать записи ресурсов DNS? Все это в Windows 2000 может делагь протокол динамической конфигурации узла (DHCP). Когда DHCP применяется в сочетай ни с DDNS, получается практически полная автоматическая настройка клиента через сеть.
Что такое DHCP
DHCP служит для автоматического присвоения клиентам параметров протокола TCP/IP. После запуска клиент, поддерживающий DHCP, з」- праишвает IP-адрес и другую информацию у сервера DHCP. 1Р-адресз поступают из пула, определенного в базе данных DHCP и называема о областью (scope). Сервер выделяет IP-адрес нз определенный перн(>1 времени, называемый арендой (lease).
Это означает, что пользователи уже не должны получать данные IP о「 администратора или вручную настраивать свои компьютеры по эип! данным. С ручной настройкой TCP/IP часто связаны проблемы зубпкрс- вания IP-адресов, неправильного ввода данных, что делает невозможном подключение к сети, и дополнительных работ по администрированию, когда узлы перемешаются в другую подсеть. DHCP создан с целью yci- ранить эти проблемы; ею преимуществами являются автоматизация и иентра/шзованное управление настройкой TCP/IP клиентов. Поскольку IP-адреса после использования возвращаются в пул области, их количество остается неизменным. Чтобы завершить знакомство с DHCP. р；к- смотрнм, как он согласуется с DNS. и его отношение к ВООТР — 口р”、 му протоколу присвоения IP-адресов.
!
'Протокол DHCP определен в RFC 2131 и 2132, основанных на более
ранних RFC 1533, 1534, 1541 и 1542. Служба DHCP Windows 2000 поддер- *иваст стандарты, указанные в RFC 2131 и 2132. Следует указать, что на момент написания этой книги взаи\)одействие DHCP с динамическим обновлением DNS находится на этапе проекта 1ETF (см. приложение Б., 十,"Документы RFC по DNS"). который обычно предшествует стандарту 片 RFC. Windows 2000 DHCP Server также поддерживает еще не включенный 3 В стандарт парамегр класса пользователя, которь亩 предоставляет серверу 'DHCP информацию о клиенте. На основании этой информации сервер ■ определяет, какой класс обработки надо использовать д.чя клиента.
' Аренда IP выполняется в ходе четырех зтапов обмена между клиентом И сервером DHCP. После того как клиент получит аренду IP и соответст- j вуюшие параметры, он ограничен сроком этой аренды. Перед нстеченн- ;ем срока клиент соединяется с сервером DHCP и запрашивает продол- ,-j *енме аренды. Если этот запрос отклоняется, клиент должен прекратить ；использовать этот 1Р и получить новый. Можно предусмотреть резервирование IP на сервере DHCP, так что клиент всегда будет получать один .й тот же IP. Это полезно в некоторых ситуациях, но одновременно 'уменьшает преимущества DHCP в администрировании.
Что DHCP может предложить клиенту
DHCP предоставляет гораздо больше, чем просто передачу IP-адреса Клиенту. Когда клиент получает 1Р-алрес, он, скорее всего, получит и несколько параметров настройки. Кроме того, не все 1Р-адреса одинаковы. Наряду с обычными адресами (классов А, В или С) DHCP Windows 2000 может предоставлять клиентам групповые IP-адреса (класса D), исноль- »зуя тог же метод определения областей (см. ниже).
i В Windows 2000 динамическая DNS полное и>ю интегрирована в смете- Зу и полностью соответствует стандартам; службу DHCP также можно на- ■■Строить для испольювания сообщений динамического обновления соглас- ,но требованиям RFC. Прежде Microsoft предлагала интеграцию DNS со .■службой WINS、которая имела некоторые из этих возможностей, но была ■^рбственной разработкой Microsoft. Это решение остается единственной альтернативой, когда динамическая DNS недоступна. В старых версиях BIND предлагался ряд настроек API, которые администраторы мог.ин ис- ?Пользовать для контроля процессов в зоне, однако более новые версии 电IND имеют станлар1изованнь[е версии сообщений динамического обнов- 审ения DNS, способные взаимодействовать с Windows 2000 DHCP.
Сервер DHCP Windows 2000 можно настроить так, чтобы он регист- 通Провал для клиента либо любую комбинацию записей ресурсов адреса t(A) и указателя (PTR), либо не peiнстрнровал никаких записей. При ^бычной настройке клиенту разрешено регистрировать запись A; DHCP ^Регистрирует запись PTR. Таким образом, клиент имеет полную сетевую Поддержку TCP/IP и может быть разрешен в пространстве имен DNS; ^лава 15. Службы DHCP в Windows 345
эта возможность до сих пор была недоступной, если только не испольit) валась нестандартная интеграция WINS н DNS, Сервер DHCP может определить, что запрос исходит не от клиента Windows 2000, и на оснсне этого решить, что следует зарегистрировать в DNS Для клиентов низкою уровня и сторонних систем сервер DHCP может быть настроен так, urr- бы регистрировать записи как А, так и PTR.
Чтобы настройка клиента была полной, области DHCP мог.т предоставлять параметры в процессе получения аренды. Полное станларгкос описание всех параметров приводи гея в RFC 2132. В габл. 15.】 перечм • лены некоторые ппрамецэы, обычно исиользуемме в окружении Wind。、、 а также параметры, которые прнменякпен юлько в окружении Window хотя и не часю (например, параметр 47)
Таблица 15.1. Параметры клиентов DHCP в Windows 2000
Параметр
Назначение
1
Маска подсети
3
Маршрутизатор
6
Сервер DNS
15
Доменное имя
44
Сервер WINS
45
Сервер распространения дейтаграмм NetBIOS
46
Тил узла NetBIOS
47
Код области NetBIOS
51
Период аренды
55
Запрос клиента на другие параметры
58
Время обновления аренды, с
59
Время перепривязки аренды, с
Как клиент настраивается через DHCP
Настройка клиента DHCP проходит в четыре фазы Если клиент многосетевой, процесс настройки выполняется отдельно для ка*но Q адаптера и кажлм” адаптер получает уникальный !Р-алрес Этот яроис' с показан на рис. 15.1; иногда ею называют Г!роцессом DORA по первм、’ буквам названий этапов (Discovery — обнаружение. Offer — npejbioAi - ние, Request — запрос. Acknowledgement — подтверждение)-
клиент с поддержкой DHCPклиент с поддержкой DHCPвыбор аренды , подтверждение арендувыбор аренды , подтверждение арендусервер DHCP № 1сервер DHCP №2сервер DHCP№3сервер DHCP № 1сервер DHCP №2сервер DHCP№3сервер DHCP № 1сервер DHCP № 1
клиент с поддержкой DHCP
клиент с поддержкой DHCP
выбор аренды , подтверждение аренду
выбор аренды , подтверждение аренду
сервер DHCP № 1
сервер DHCP №2
сервер DHCP№3
сервер DHCP № 1
сервер DHCP №2
сервер DHCP№3
сервер DHCP № 1
сервер DHCP № 1
Рис. 15.1. Четыре фазы настройки клиента через DHCP
Обнаружение
， В первой фазе клиент инициализирует ограниченную версию TCP/IP и распространяет широковещательный запрос на IP-адрес (DHCPDiscovcr). Эта фаза называется обнаружением、или фазой запроса аренды IP. Поскольку при этом используется широковещание, маршрутизаторы между клиентом и сервером DHCP должнье быть настроены так, чтобы пересылать пакеты BOOTP/DHCP, или же в сегменте сети клиента должен присутствовать агент ретрансляции DHCP. Можно также развернуть сервер DHCP в каждом сегменте, где есть клиенты DHCP. Это широковещательное сообщение содержит и аппаратно зафиксированный адрес Media Access Control (МАС) запрашивающего клиента, и даже поле для исходного IP- адреса. Если пакет проходит через прокси-сервер, этот исходный IP меняет свое значение с 0 . О . О . О на IP-адрес интерфейса, на котором запрос был Принят агентом ретрансляции ВООТР или DHCP.
Предложение
Во второй фазе серверы DHCP (один или несколько), получившие за- ,Прос, распространяют ответ. Это широковещательное сообщение (DHCPOffer) содержит аппаратный адрес запрашивающего клиента, прсд- лагаемый IP-адрес, маску подсети, длительность аренды и IP-адрес предлагающего сервера. Эту фазу называют фазой предложения аренды IP, Чтобы уменьшить количество предложений при сохранении избыточности, промежуточные маршрутизаторы могут быть настроены так, чтобы пересылать запросы обнаружения максимум на два IP-алреса. Может быть и так, что ни один сервер DHCP нс предложит аренды. Клиенты Windows 2000 Можно настроить так, чтобы после определенного количества неудачных Попыток получить аренлу они переходили к автонастройке IP.
За 叩 ос
В третьей фазе клиент принимает дошедшее до него предложение и Объявляет (сообщением DHCPRequest), что это предложение принято. 〔Тем самым он дает предложившему серверу знать, что ''согласился'' на Улава 15. Службы DHCP в Windows347
его предложение, а остальным серверам — что они могут снять свои предложения. Именно для этой цели, чтобы информировать другие возможные серверы DHCP, клиент распространяет этот ответ. Эта фаза называется запросом, или фазой выбора аренды IP
Подтверждение
В четвертой фазе сервер DHCP, предложение которого принято, нп- правляет клиенту широковещательное подтверждение (DHCPAck). Эю с<>~ общение содержит действительный IP-адрес, длительность аренды и др\- гую информацию по настройке (параметры DHCP), если сервер можег си предоставить. Эта фаза называется фазой подтверждения аренды IP.
Поскольку клиенты DHCP могут делать конкретные запросы, например на определенный IP-шхрес, сервер DHCP может ответить сообщением отказа (DHCPNak). Когда это происходит, клиент может сам onpesic лить, что ему делать дальше. Обычно клиент, в данном случае клиент Windows 2000, начинает процесс сначала, но запрашивает уже любои, п не какой-то определенный 1Р-адрес-
Обновление аренды
Клиент DHCP Windows 2000, имеющий арендованньп! IP-адрес, питается обновить его аренду, после того как истечет половина срока аренды. По умолчанию срок аренды восемь дней; т.е. через четыре дня нос ie получения аренды клиент направляет сообщение на сервер DHCP. Ec.’iii IP-адрес клиента еше действителен, сервер отвечает подтвераденпем и обновленной информацией, если это необходимо. Эти сообшения подобны применяемым в третьей и четвертой фазах процесса начальном настройки, но являются направленными, а нс широковещательными Когда клиент пытается обновить аренду, считается, что он находится в состоянии обновления (renewal siale). Если клиент не может обнови и. аренду, когда до ее конца осталась восьмая часть срока, он начинает попытки получить обновление текущего IP от любого сервера DHCP, который ответит. Начиная с этого момента считается, что клиент находится в состоянии перепривязки (rebind state). Если срок аренды истек, а получиib обновление не удалось, клиент прекращает испо；1ьзование IP и снова начинает четырехфазный процесс получения аренды,
Принятая по умолчанию длительность аренды — восемь дней в Windows 2000 — может быть нзменена по многим причинам. В их чис 储 могут быть крайне интенсивное или очень редкое изменение состава клиентов либо отношение количества машин к количеству 1Р-адресон Иногда говорят, что восьмидневный срок аренды был принят из-за то：(>. что он согласуется с недельным отпуском. При регулировке ухлительнос i и аренды также надо учесть его влияние на динамические регистрации DNS, особенно на срок жизни (TTL), принятый по умолчанию как срок начальной записи зоны (SOA). а также на параметры очистки сервер DNS, и влияние на упорядоченность данных в Active Directory, если ,1» мен DNS интегрирован в него.
^установка Windows DHCP Server
能 При установке сервера DHCP надо принять во внимание конфигура- -j иию сети, так чтобы конфигурация служб DHCP соответствовала ей наи- ^более эффективно. В сетях малого и среднего размера служба DHCP ^Server может работать на юм же компьютере, что и другие службы, на-' Пример WINS или DNS. В малых системах совместная работа этих трех 《:служб (DNS, DHCP и WINS), если они настроены для взаимодействия 4"ме*ДУ собой, дает преимушество уменьшения объема связи через сеть. В сетях с тысячами клиенчов DHCP надо учитывать пропускную способ- 口■цостъ сети, производительность дисковой подсистемы и мощность про- *цессора, требуемые для сервера DHCP. Также в больших организациях ^со многими подразделениями имеет знаиенне координация между всеми ^Частями работающих служб DHCP.
2* Если имеется несколько подсетей с клиентами DHCP, лучшее реше- "цие — установить серверы DHCP в каждой подсети. Если этого нельзя ；1；®делать, следует установить агенты ретрансляции, как описано ниже в этом Xразделе, или настроить маршрутизаторы так, чтобь[ они действовали как рэти агенты. Обычно рекомендуется создать избыточность DHCP, что легче ^^всего осуществить путем ретрансляции на несколько серверов DHCP.
^Требования и необходимые полномочия
1'" Хотя имеются и другие программы серверов DHCP, в этой книге под- \разумсвается, что вы будете использовать Microsoft DHCP Server, кото- ，阿й вхоапт в состав Windows 2000 версии Server. Требования длм уста- Lhobkh примерно такие же, как и при установке WINS или DNS. Нужно, ^чтобы была усгановлема система Windows 2000 Server и настроен прото- ；Коп TCP/IP с использованием статически присвоенного IP-aipeca.
> Однако, чтобы установить и настроить DHCP, дополнительно нужно за- ^регистрироваткя в системе с правами администратора предприятия. За ис- ^Длюченмем работы без Active Directory, простой учетной записи админлетра- [iropa недостаточно для установки DHCP, если только администратор предприятия не делегировал эти полномочия специально для данной учетной 1загтиси. Некоторые вопросы, связанные с этим требованием, рассматривают- Ъя в последнем разделе "Авторизасхия Windows DHCP Server".
Установка
г Процесс установки сервера DHCP очень похож на установку сервера pNS или WINS. Как и с этими серверами, основная работа заключается |В настройке после установки. Можно использовать мастер настройки Сервера или выполнить следующие действия.
* 1. Откроите панель управления.
f 2. Запустите аплет Установка/удаление программ.
Щелкните на значке Установка/удаление компонентов Windows слева и запустите мастер компонентов Windows.
Прокрутите список и выберите в нем пункт Сетевые службы.
Щелкните на кнопке Состав и откройте список сетевых служб.
Прокрутите список и установите флажок напротив пункта DHCP.
После этого можно просто завершить работу мастера компонентов Windows, щелкнув на кнопке Далее и/или Готово, или же установить в нем другие параметры по вашему усмотрению.
Олмсаяив- Устаиввливве'г РНФнэрввр кп<орый ввюмпгимеслинознамаа!' ервмвнные 1Р,-ал^Ё&аклиенгсх№^ка*^Пью1ер№ в гоя же сетн.Олмсаяив- Устаиввливве'г РНФнэрввр кп<орый ввюмпгимеслинознамаа!' ервмвнные 1Р,-ал^Ё&аклиенгсх№^ка*^Пью1ер№ в гоя же сетн.Требуется ив диашСвободно мп лоеТребуется ив диашСвободно мп лое900.2 МБ900.2 МБОтненоОтнено
Олмсаяив- Устаиввливве'г РНФнэрввр кп<орый ввюмпгимеслинознамаа!' ервмвнные 1Р,-ал^Ё&аклиенгсх№^ка*^Пью1ер№ в гоя же сетн.
Олмсаяив- Устаиввливве'г РНФнэрввр кп<орый ввюмпгимеслинознамаа!' ервмвнные 1Р,-ал^Ё&аклиенгсх№^ка*^Пью1ер№ в гоя же сетн.
Требуется ив диаш
Свободно мп лое
Требуется ив диаш
Свободно мп лое
900.2 МБ
900.2 МБ
Отнено
Отнено
Рис. 15.2. Выбор DHCP в диалоговом окне Сетевые службы
Однако надо проделать еше много работы, так как в этом состоянии только что установленный сервер DHCP неработоспособен. Еше надо выяснить, как сервер будет выделять аренды, определять пулы адресов, настроить его параметры и рассмотреть несколько других факторов.
Это обязательно
Любой компьютер, на котором работает сервер DHCP, должен иметь статически присвоенный IP-адрес Иными словами, этот компьютер сам не может быть клиентом DHCP
Интерфейс управления Windows DHCP Server
Теперь самое время откр1>|ть консоль управления сервером DHCP, если вы еше не сделали этого. Ее можно найти в меню Пуск — Программы —Администрирование — DHCP. Также эту консоль можно запусти i ь в меню Выполнить н:ш в комариной строке, введя dhcpir.gir：t. ^；sc. Возможно. на консоли сначала потребуется выбрать Локальный сервер.
На открь[той консоли можно обнаружить, что контекстное меню (открывается щелчком правой кнопки мыши) самого верхнего узла, оз,『
：главленного DHCP, похоже на меню Действие. В данный момент нас ин- ■ тересуст команда этого меню Добавить сервер, ведь сначала надо добавить какие-нибудь серверы, чтобы управлять ими. Легко управлять несколькими серверами можно не только на этой консоли; это можно делать и в настольной версии Windows 2000, установив средства ；администрирования (adminpak.msi).
? Авторизация Windows DHCP Server
&' Чтобы сервер DHCP Windows 2000 мог предоставлять аренду, он дол- „! жен не только иметь область, но и быть авторизован. Как можно вспом- 口 нить, процесс DORA является довольно открытым, без направления со- f общений только одному определенному адресату и без взаимной ндентм- i( фикапии. Это просто вопросы и ответы. В таком окружении действия '■. инородных серверов DHCP могут вызвать серьезные нарушения.
1* Вследствие большого риска вмешательства в существующих системах >.службы DHCP в Windows 2000 для своего запуска могут потребовать Л полномочий высокого уровня. Если DHCP установлена на автономном [сервере и в сети нс обнаруживается доменов Windows 2000, администра- .；■ торы этого сервера мопт сразу настроить и запустить сервер DHCP У Windows 2000. Если же сервер является частью домена, или даже нет, но в сети имеются домены Windows 2000, компьютер должен быть авторизо- ,ван в Active Directory. Если сервер находится в домене, это выполняет .администратор предприятия для Active Directory, в котором находится * домен этого сервера. Если сервер DHCP не включен в домен, авторизо- f вать сервер до/окны администраторы предприятия всех лесов Active i' Direciorx'. видимых для сервера DHCP, каждый в своем Active Directory.
Чтобы авторизовать сервер DHCP, имея полномочия администратора ;предприятия или должным образом делегированную учетную запись, вы- :полните следующие действия.
!1. Откройте интерфейс управления сервером DHCP,
；2. Выберите в меню Действие или в контекстном меню узла DHCP
Y команду Управление авторизованными серверами,
I 3. Щелкните на кнопке Авторизовать.
；4. Во всплывающем окне Авторизовать DHCP-сервер введите имя и
LIP-адрес сервера, который надоавторизовать.
*5. Щелкните на кнопке ОК, а затем подтвердите авторизацию, щелк-
tнув на кнопке Да.
：；6.Закройте окно авторизации.
Е Windows 2000 позволяет контролировать работу сервера DHCP в сети, J' Пока Windows 2000 DHCP Server не авторизован, он не может начать рат боту. Причин тому много, и не вес они приводятся здесь. В частности, ■ Каждый Active Directory ведет список авторизованных серверов DHCP в г своем контексте предприятия, где они перечислены по IP-адресам. Когда
компьютер пытается запустить Windows 2000 DHCP Server, производи гея опрос контекста предприятия домена этого сервера, или, если он це включен в домен, опрос всех обнаруженных контекстов предприятя Active Directory, Сервер DHCP не начнет работу、пока он не найдет св<)т IP-адрес во всех проверяемых контекстах предприятия (в одном, если л0 сервер в домене, и во всех — в остальных случаях).
Эта тема не входит в круг вопросов, освещаемых в данной книге, Ну можете сами исследовать эти функции обнаружения инородных серверов И еше одно замечание: этот механизм авторизации DHCP работает тоц^ ко для серверов DHCP Windows 2000.
0мя“п“ И^вдрес小6女6：(П而一
Рис. 15,3. Авторизация Windows 2000 DHCP Server
Агенты ретрансляции DHCP
После того как сервер DHCP установлен, его можно настраивать. Г^- ли имеется несколько подсетей, нужно найти способ обслуживания к ш- ентов, которые находятся в другом сегменте сети. Поскольку служил DHCP основана на широковещании, а широковещательные сообщения обычно не проходят через маршрутизаторы, надо использовать агент ретрансляции или настроить маршрутизаторы так, чтобы они пропуска【н пакеты DHCP/BOOTP.
Серверы DHCP могут предоставлять IP-адреса клиентам, находящимся в нескольких подсетях, если маршрутизаторы, разделяющие их, mci\「 работать как агенты ретрансляции стандарта RFC 1542 (ВООТР). Ес【н маршрутизатор не способен к этому, каждая подсеть, содержащая клиенты DHCP, должна иметь свой сервер DHCP или службу под названием "Агент ретрансляции DHCP", установленную на компьютере Windows 2000. Этот агент ретрансляции перехватывает широковешательные сообщения DHCP (и ВООТР) и направляет пакеты прямо на ссрвер(м) DHCP. Эти направленные сообщения могут проходить через маршруiи- заторы; они содержат информацию о сетевом интерфейсе, который принял широковещательное сообщение. Таким образом, агент ретрансляшш DHCP действует как локальный прокси-сервер для удаленных серверов DHCP, которые используют информацию об интерфе!1се, чтобы определить, куда послать ответ и какую область применить.
Агент ретрансляции DHCP устанавливается на консоли Маршрутизация и удаленный доступ, которую можно открыть в меню Пуск — Программы —Администрирование. При перво” обращении к этой консс ；н нужно установить и запустить службы (см. меню Действие).
Откройте интерфейс управления Маршрутизация и удаленный доступ.
Раскройте узел, представляюший ваш сервер.
Раскройте узел IP-маршрутизация.
Если в состав этого узла не входит элемент Агент DHCP- ретрансляции, в контекстном меню узла Общие выберите команду Новый протокол маршрутизации, а затем выберите и добавьте агент.
Установите фокус на узел Агент DHCP-ретрансляции, шелкните правой кнопкой мыши и выберите команду меню Свойства. Появится диалоговое окно, показанное на рис. 154
Введите и добавьте в спнсок адреса серверов DHCP.
Щелкните на кнопке ОК и закройте окно.
血血Общие пвд>аив!ры ЕХФОбщие пвд>аив!ры ЕХФборее сервераборее сервераАгент 1ЖРт»грансл(ло«и cocuntieT esaBassxHS не апрвса серверов :прадсгавсенкме есписке.：、：Агент 1ЖРт»грансл(ло«и cocuntieT esaBassxHS не апрвса серверов :прадсгавсенкме есписке.：、：J Отмене」j ■ Пяниенить ! |J Отмене」j ■ Пяниенить ! |Рис. 15,4. Установка адресов серверов DHCP в агенте ретрансляцииРис. 15,4. Установка адресов серверов DHCP в агенте ретрансляции[еяойстй: Atwrl
血
血
Общие пвд>аив!ры ЕХФ
Общие пвд>аив!ры ЕХФ
борее сервера
борее сервера
Агент 1ЖРт»грансл(ло«и cocuntieT esaBassxHS не апрвса серверов :прадсгавсенкме есписке.：、：
Агент 1ЖРт»грансл(ло«и cocuntieT esaBassxHS не апрвса серверов :прадсгавсенкме есписке.：、：
J Отмене」j ■ Пяниенить ! |
J Отмене」j ■ Пяниенить ! |
Рис. 15,4. Установка адресов серверов DHCP в агенте ретрансляции
Рис. 15,4. Установка адресов серверов DHCP в агенте ретрансляции
После этого агент ретрансляции "знает", куда пересылать широковс- ^Шательные сообщения, однако надо еще указать, где они будут приниматься. В контекстном меню узла Агент DHCP-ретрансляции выберите 'команду Новый интерфейс и укажите лнтерфейс(ы), которые будут принимать сообщения. Свойства интерфейса показаны на рис. 15.5, К этому диалоговому окну можно обратиться в любой момент, дважды щелкнув На интерфейсе на правой панели, когда на левой панели вьпелен узел Агент DHCP-ретрансляции. Флажок Ретрансляция ОНСР-пакетов включает 'или отключает ретрансляцию для данного интерфейса.
^^ ：' ОНСР-ияй|рфейе^^ ：' ОНСР-ияй|рфейеU旦U旦
^^ ：' ОНСР-ияй|рфейе
^^ ：' ОНСР-ияй|рфейе
U旦
U旦
"I .Отмене：」
Рис. 15.5. Включение интерфейса для агента ретрансляции DHCP
Это требуется не всегда
На сервере DHCP необязательно должен быть установлен агент ретрансляции DHCP, а в Windows 2000 он и не может быть установлен. Агент ретрансляции устанавливается только на компьютерах, которые находятся в подсетях, не имеющих своих серверов DHCP
Настройка Windows DHCP Server
Каждый сервер DHCP должен иметь по крайней мере один пул IP- адресов для выделения клиентам. Этот пул называется областью. Сервер DHCP может иметь области для нескольких подсетей при условии, что широковешательные объявления клиентов могут достичь этого сервера из каждой подсети. Для этого сервер DHCP должен быть многосетевым или должны быть установлены агенты ретрансляции.
На каждом отдельном сервере DHCP определенной подсети можно присвоить только одну область, но разрешается разделить подсеть между двумя или более серверами DHCP в мелях избыточности. Надо только обеспечить, чтобы каждый 【P-адрес был доступен только с одного сервера (если только на этих серверах не зарезервированы одинаковые адреса: резервирование рассматривается ниже). Сервер DHCP не может иметь общую с другими серверами информацию, поэтому надо быть очень внимательным, чтобы не допустить пересечения адресных пулов (за исключением зарезервированных адресов). На рис. 15.6 показано такое использование пвух серверов DHCP, создающее избыточность.
область для сети 2:192,168.70.151-192.168.70.200область для сети 2:192,168.70.151-192.168.70.200область для сети 1:192.168.69.151-192.168.69.200область для сети 1:192.168.69.151-192.168.69.200Рис. 15.6. Распределение областей между несколькими серверами DHCPРис. 15.6. Распределение областей между несколькими серверами DHCP
область для сети 2:
192,168.70.151-192.168.70.200
область для сети 2:
192,168.70.151-192.168.70.200
область для сети 1:
192.168.69.151-192.168.69.200
область для сети 1:
192.168.69.151-192.168.69.200
Рис. 15.6. Распределение областей между несколькими серверами DHCP
Рис. 15.6. Распределение областей между несколькими серверами DHCP
Пусть сервер DHCP А находится в подсети 1. а сервер В — в подсети 2. Серверы А и В используют в своей области 75% пула IP-адресов для подсетей 1 и 2 соответственно. Для оставшихся 25% пула IP-адресов в удаленной подсети можно задать другую область. Теоретически сервер А обрабатывает ,все запросы клиентов из своей подсети, поскольку он может отвечать быст- 1 рее, чем удаленный сервер В, но если сервер А отключается, его запросы переходят к серверу В. В этой конфигурации следует задать точное разделе- 1 ние — 75/25, 80/20 и так далее, руководствуясь наблюдаемым объемом выде- ! ления аренды и в зависимости от таких факторов, как относительная [латентность сети между клиентом и двумя серверами.
> Настройка интерфейсов, через которые сервер DHCP будет прини- i Мать сообщения, является глобальной для сервера. Эта настройка, а так- F же настройка обнаружения конфликтов производятся на странице [свойств сервера DHCP. Для этого надо выполнить следующие действия. :1. Откройте интерфейс управления сервером DHCP.
Установите фокус на узел, представляющий нужный сервер, шелкнитс правой кнопкой мыши и выберите в контекстном меню сер' вера команду Свойства.
Выберите вкладку Дополнительно.
.4. Щелкните на кнопке Привязка и откройте одноименное диалого
' вое окно.
Установите флажки около названий интерфейсов, через которые должен быть доступен сервер DHCP, и щелкните на ОК.
Во вкладке Дополнительно свойств сервера, если необходимо, включите обнаружение конфликтов, введя количество попыток.
Закройте диалоговое окно свойств и сохраните изменения, щелкнув на кнопке ОК.
Заметьте, что на вкладке Дополнительно можно указать размещение журнала и базы данных DHCP, Обнаружение конфликтов — это функция, с помощью которой сервер DHCP может установить, не используются ju 1Р-алреса, которые он собирается выделить. Он делает это, пытаясь связаться с этими адресами через сеть. Ясно, что обнаружение конфликтов вносит дополнительную нагрузку и замедляет ответы DHCP клиентам. Если вы имеете исключительное право контроля над сетью, эта функция может показаться ненужной и вредной в смысле снижения производительности, но надо помнить, что она полезна для разрешения проблем.
Определение областей
Чтобы создать новую область, выберите на консоли управления DHCP сервер, который будет поддерживать эту область, и вызовите его контекстное меню, которое показано на рис. 15.7. Здесь есть команды создания новой области, суперобласти и многоадресной области. Мы будем иметь дело с обычной областью.
Рис, 15.7. Главное контекстное меню сервера DHCP
Благодаря использованию протокола MADCAP многоадресные области могут предоставлять клиентам групповые IP-адреса (класса D). Суперобласти объединяют несколько областей, соответствующих сегменту сети, в большую логическую структуру. Они могут быть очень полезны при переходе от одного пула адресов к другому. Многоадресные области и суперобласти создаются и управляются подобно обычным областям.
Чтобы создать область, выполните следующие действия.
Откройте консоль управления DHCP Server.
Установите фокус на узел, представляющий нужный сервер, щелкните правой кнопкой мыши и откройте контекстное меню сервера.
Выберите в меню команду Создать область и запустите мастер. Команды Создать суперобласть и Создать многоадресную область запускают мастера, соответственно приспособленные для сбора информации, необходимой для данного типа области,
Введите имя и описание области. Эти данные позднее можно будет изменить в свойствах области. Щелкните на кнопке Далее.
Задайте пул IP-адресов, введя начальный и конечный 1Р-адреса. Затем укажите маску подсети, задав либо длину ес части сети в битах, либо в виде десятичных чисел, разделенных точками. Эта ситуация показана на рис. 15.8, где в пуле размещена часть сети класса В, соответствующая последнему октету. Введя эти данные, щелкните на кнопке Далее.
Мастер создания области
Рис. 15.8. Размещение адресов в новой области
В мастере создания новой области есть возможность исключить из использования областью IP-адреса в только что указанном диапазоне. Сейчас исключать ничего не надо; это можно сделать позже. Щелкните на кнопке Далее.
Стандартный срок аренды — восемь дней — можно изменить. При этом необходимо учитывать, какое ачияние окажет это изменение, особенно, если включена динамическая очистка DNS. Примите предлагаемое значение или задайте новое и щелкните на кнопке Далее.
На этом этапе работы мастера можно начать настройк%' параметров новой области. Все эти параметры можно установить вручную, но при настройке нескольких областей удобнее принять стандартные значения. Сделайте выбор и щелкните на кнопке Далее.
Если на предыдущем этапе вы решили настроить параметры позже, работу мастера можно закончить. В противном случае теперь надо поэтапно задать параметры для маршрчтизатора (шлюза).工＜_)_ мена DNS, где у клиентов будут имена узлов, серверов DNS и серверов WINS, которые будут использоваться клиентами. Пос」е этого вам будет задан вопрос: когда активизировать область — ceii- час или позже?
*• DHCP*• DHCPе? DG й 9-Облить [Ю.о;о.о]ехатр1е ■ Сос£рж1-мзесб... j__:-О Аренд овэ-«-ьн♦^piRinpi^Г^&гметоы ut；е? DG й 9-Облить [Ю.о;о.о]ехатр1е ■ Сос£рж1-мзесб... j__:-О Аренд овэ-«-ьн♦^piRinpi^Г^&гметоы ut；Если щелкнуть на кнопке Готово, новая область появится на левоц панели в составе сервера, как показано на рис. 15.9. Исключать какие- либо адреса из области необязательно. Это можно проделать или изменить существующие исключения в любое время, раскрыв узел области на консоли управления и вызвав команду Создать диапазон исключений в меню узла Пул адресов. Также в любое время можно задать длительность аренды в днях, часах и минутах в диалоговом окне свойств области. Максимально возможный срок аренды — 999 дней. При регулировке срока аренды не забудьте соответственно настроить динамическую DNS
*• DHCP
*• DHCP
е? DG й 9
-Облить [Ю.о;о.о]ехатр1е ■ Сос£рж1-мзесб... j__
:-О Аренд овэ-«-ьн
♦^piRinpi
^Г^&гметоы ut；
е? DG й 9
-Облить [Ю.о;о.о]ехатр1е ■ Сос£рж1-мзесб... j__
:-О Аренд овэ-«-ьн
♦^piRinpi
^Г^&гметоы ut；
Действне &•*6 - 由宮＞
Структура j
]Об2：ть [iaQO0]eYample|]Об2：ть [iaQO0]eYample|-.5 ?：＜al example net |1 уч zu II
]Об2：ть [iaQO0]eYample|
]Об2：ть [iaQO0]eYample|
дГ)ул р.ккое
Q Аоендо&А-ь»； аджа
■ d Pe»t3txe＞v＞r
» Паоз*т w о£"1э;ти
_j гираметсю! серели
Рис. 15.9. Новая область на консоли управления DHCP
Вновь созданная область обозначается на консоли управления маленькой красной стрелкой, направленной вниз, в белом кружке над значками папок. Эта стрелка, направленная вниз, означает, что облает ь не включена. Это видно и из контекстного меню области, где присутствует команда Активизировать (при включенной области была бы команда Деактивизировать). Параметры области лучше установить перед тем, как делать ее доступной для аренды.
Обратите внимание на эту удобную возможность просто деактивизировать область для обслуживания и понска неисправностей, вместо того, чтобы удалять ее н создавать заново. Это делается только при работе с суперобластью, которую в лвух словах можно описать как множество областей, к которому можно обращаться как к едино!! области.
Установка обновления DDNS для области
Динамическое обновление записей DNS для арендованных IP-алресов является одним из преимуществ DHCP, особенно для клиентов низкого < уровня, которые не могут сами регистрироваться в DNS, На рис. 15.10 показана вкладка DNS диалогового окна Свойства TCP/IP с установками, предусмотренными по умолчанию. Очень похожую вкладку DNS можно 'найти в диалоговом окне свойств DHCP. Свойства уровня сервера опре- 1 деляют исходные значения свойств для новых областей, а свойства уров- 」НЯ области управляют поведением области.
|Сао“ства： Обпасть [169.泓20一5
.Сбш» ：3»6»NS j ДоЛИНлШ»!
Мотя» ^w^ouTbfMCFctWMP м> *гамп««еаихе 6е>—,”
1№Ф^чци<об №Vhh иadtccQ нь!Ж$*<»с^ш. Kffiowe /к： -пш^Ппеакя BOwffiwa^ сбивяение
^®&®MWi.DNS'TMMono3«ioq|DHCP«™«tBa:
P 'MMwa чясмчшев uww.Miw лнмого прошофа:
Г* Рвмк*лЪйбм«4анс4№ DH5*jw*ito3. kotdoj» н«
—лмйорюокг аичммк» во6нселем« 一；
Рис. 15.10. Установка обновления DDNS для областиРис. 15.10. Установка обновления DDNS для области
Рис. 15.10. Установка обновления DDNS для области
Рис. 15.10. Установка обновления DDNS для области
Когда сервер DHCP включен, он посылает сообщения обновления на сервер DNS, указанный на странице Свойства TCP/IP сервера. Может быть целесообразно настроить сервер так, чтобы использовать основной сервер DNS, тогда обновлениям DNS не нужно будет перенаправляться от дополнительного сервера к основному. Обратите внимание, что здесь имеется возможность полного отключения этой функции или выдачи обновлений DHCP либо всегда, либо только по запросу клиента. Поскольку клиенты DHCP Microsoft посылают информацию о классе вендора, сервер DHCP может определить, что клиент инородный.
Имеется возможность обновлять DNS через DHCP для всех неилен- тифицированных клиентов как для тех. которые могут это делать. Это клиенты, которые не предоставляют серверу DHCP своего имени FQDN для использования параметра 81. Клиенты Windows 2000, которые нмеют этот параметр, регистрируются в домене DNS, указанном в полностью уточненном доменном имени (FQDN).
Когда DHCP регистрирует клиента в DNS, он может быть определен как владелец записей DNS. если выполняются меры зашиты DNS, предусмотренные при интеграции в Active Directory. Если учетная запись сервера. на котором работает DHCP, является членом стандартной группы Active Directory DnslIpdateProxy, сервер DHCP не становится автоматически владельцем созданных им данных, но если она не входит в эту группу, сервер становится владельцем. Эти особенности рассмагриваются в главе 7, Динамическая DNS и Active Directory''; их надо принять во внимание、 когда функция обновления включается в подобной ситуации.
Резервирование клиента
Можно настроить DHCP так, чтобы сервер DHCP выдавал определенному клиенту всегда один и тот же IP-адрес. Это называется резервированием клиента.
Для резервирования клиента выполните следуюихие действия.
Откройте интерфейс управления сервером DHCP.
Раскройте узел сервера, а затем узел области, где следует создагь резервирование.
Щелкните правой кнопкой мыши на папке Резервирование этой области и выберите команду Создать резервирование.
Укажите имя резервирования, IP-адрес, адрес Ethernet (или алрсс МАС), введите описание и выберите поддерживаемый тип (DHCP, ВООТР или Любой). Адрес МАС содержит 6 байт в шестнадцатеричной форме и и мест вид 23-a7-5f-77-d8-45.
Щелкните на кнопке Добавить и после этого закройте окно
Адрес МАС служит в качестве уникального имени для машины Можно вспомнить, что адрес МАС посылается клиентом в начальном сообшенми обнаружения. При получении запроса аренды DHCPDiscovcr сервер, прежде чем предложить IP-адрес, проверяет, нет ли резервирования в соответствующей области. Адрес МАС можно узнать, введя команду ipconfig /all на компьютере Windows 2000, для которого создается резервирование, или, если можно связаться с этой машиной через сеть, просмотрев локальную таблицу протокола распознавания адресов (Address Recognition Protocol, ARP).
Резервирование клиента также позволяет задать параметра на уровне конкретной машины. После этого DHCP сможет производить настройку, уникальную для каждой машины. Хотя при этом не используются преимущества DHCP, упрощающего администрирование, этот способ индивидуальной настройки клиентов дает другое преимущество — централизованного управления.
Можно использовать один и тот же IP в областях на разных серверах DHCP, которые совместно поддерживают подсеть. При этом адрес 1Р в обеих областях должен быть зарезервирован для одного и того же клиен-
K та по адресу МАС. Не забудьте сделать это и не ликвидируйте резервирования, поскольку после этого IP-адрес станет доступным для аренды, что
: приведет к дупликации IP-адресов в обслуживаемой подсети.
! Параметры DHCP
、 Мы уже знаем, как сервер DHCP доставляет клиенту IP-адрес, но что < происходит с друш\fn данными конфигурации, которые нужны, чтобы j vиспользовать TCP/IP? Сервер DHCP предоставляет маску подсети, кото! рая была указана при создании области. Он также может предоставить : клиенту DHCP несколько других значений параметров. В табл. 15.1 f приводится список некоторых наиболее общих параметров, используемых клиентами Windows. Полный список параметров определяется стан- 卜 дартами RFC и постоянно растет. Быстрее всего изучить доступные па- ； раметры можно, просмотрев их список с краткими описаниями в интер- ；фейсе сервера DHCP.
I Классы и уровни настройки параметров
! Параметры можно настраивать на трех уровнях: глобальном, области t и клиента. Параметры обозначаются номерами. Глобальные параметры, 1 параметры области и клиента различаются только по уровню. Другими j словами, определенный параметр можно использовать на любом или на I всех уровнях. В терминологии Microsoft и в интерфейсе Windows 2000 f DHCP Server глобальные параметры называются параметрами сервера.
:Параметры, предостакояемые клиенту, также могут определяться ин
формацией, которую клиент направляет на сервер DHCP в виде так называемых классов. В Windows 2000 DHCP Server поддерживаются классы пользователя и классы вендора. Следует подчеркнуть, что определение j стандартов для DHCP — в настоящее время довольно напряженно" про- I цесс. Некоторые веши, рехчизованные в Windows 2000, опережают появле- : ние стандартов. Единственный предопределенный класс вендора в начшть- г ной версии Windows 2000 — это класс вендора Microsoft, но можно устано- |вить и использовать и друтпе классы. Вновь появившийся параметр класса пользователя поддерживается как в клиентах Windows 2000. так и на серве-
卜 ре DNCP. хотя стандарт RFC для него euie разрабатывается.
I Глобальные параметры доступны для всех клиентов DHCP на ссрве- |ре. Параметра области доступны для всех клиентов в данной области и отменяют все глобальные параметры. Параметры клиента создаются для
I конкретного клиента, который использует резервирование, м отменяют С глобальные параметры и параметры области. Отмена означает, что, если I опрелеленные параметры разных уровней противоречат друг другу, ис- I пользуется параметр наиболее частного, конкретного уровня. В ином I случае параметры складываются. Если применяются классы пользователя или вендора, они мслуг быть размешены на любом из этих уровней. В ' случае противоречия, если класс применяется к определению парамет-
ров, направляемых к клиенту, параметры, указанные для класса, отменяют параметры, указанные на том же или более высоком уровне. Другими словами, например, параметр класса пользователя на уровне области отменяет такой же параметр, указанны；! на уровне области или глобальном уровне.
Указание параметров
Предопределенные параметры установлены в узле DHCP Server; и\ нельзя смешивать с глобальными параметрами или параметрами сервера. На рис. 15.7 в контекстном меню сервера есть команды определения классов и установки предопределенных параметров. Когда мы рассмотрим настройку параметров, будет видно, что предопределенные параметры функционируют как значения по умолчанию при установке параметров на глобальном уровне, уровнях области или клиента.
Определение класса пользователя или вендора, как показано на рис 15.11, производится выбором соответствующих значений в диалоговом окне Свойства сервера. Для этого пало ввести имя, описание и код класса (который должен быть предоставлен клиентами точно в таком виде, как он вводится). Этот код класса можно ввести либо в области Двоичные данные, либо в области ASCII; он сразу хе появится в другой области.
В>ЯСДИМ0|!步*
■^E'Sriir.'ll/T!'； IIILjr.llll-
Йписпние
iNDLeuiLifts U=?r CIS5
Лвоимныв лонные.
Oihoho
Рис, 15,11. Задание нового класса пользователя
После того как класс определен, надо задать параметры, которые класс будет указывать, выбрав команду Настроить параметры, например, в контекстном меню ума Параметры сервера. Затем следует выбрать на вкладке Дополнительно раскрывающийся список Класс вендора либо Класс пользователя и выбрать в нем имя нового класса. После этого можно начать установку параметров, устанавливая: напротив них флажки и вводя требуемую информацию. Этот процесс очень похож на установку парамел-
ров, не относящихся к классу, как будет показано ниже. Но отличие этих Параметров в том. что они могут быть применены только на выбранном 1|ровие для клиентов, которые предоставят строку кода класса,
■ Установка глобальных параметров сначала может показаться неумного запутанной. Можно вызвать контекстное меню узла сервера и i'выбрать в нем команду Установить предопределенные параметры. Эта ^команда открывает ;ша.-[огавое окно, где можно установить значения па- .раметров. которые затем буд\т предлагаться по умолчанию в других диа- ；договых окнах настройки. Данное диалоговое окно отличается от опи- ^санного выше тем. что не имеет флажков напротив параметров, посколь- ：ку то, использовать или не использовать параметры, определяется в других диалоговых окнах. В этом окне надо просто выделить параметр и ；установить значение по умолчанию.
Для настройки [лобальнь!х параметров следует вызвать контекстное меню узла Параметры сервера в составе сервера, для параметров области —контекстное меню узла Параметры области в составе области, и для [параметров клиента — резервирование в пзпке Резервирование в составе области. На рис. 15.12 показано диалоговое окно, в котором, с небодь- ：Шим и вариациями, ласграиваются параметры во всех случаях. Чтобы его [открыть, щелкните на нужном узле и выделите его Затем вызовите кон- 『текстное меню и выберите в нем команду Настроить параметры.
На рис. 15.12 выбрана вкладка Дополнительно. На вкладке выделен Класс пользователя, прсдусмотренньи'! но умолчанию, и для него выбран параметр 5. который настраивает сервер DNS. В нижней части окна показан сервер, настроенный как образец по уъ(олчанию. Если задать новый 11 ол ьзовател ьск и й класс, он также появится в списке классов.
Для настройки параметров DHCP выполните следующие действия,
Откройте диалоговое окно параметров на нужном уровне (глобальном, области или в резервировании, как было показано выше).
Во вкладке Общие установите флажок напротив параметра, который будет использоваться.
После установки флажков появятся поля для ввода будущих значений. Чтобы облегчить ввод, можно сначала установить значения по умолчанию в предопределенных параметрах, как описано выше. —тогда не придется каждый раз вводить информацию при настройке нескольких классов нли областей.
Повторите пп. 2 и 3 для всех нужных параметров.
Если необходимо, перейдите во вкладку Дополнительно диалогового окна.
Выберите подходящий класс вендора или пользователя и выполните пп. 2—4. Класс вендора Стандартные параметры DHCP и класс пользователя Класс пользователя по умолчанию соответствуют параметрам, представленным во вкладке Общие.
Сохраните изменения и закройте окно, щелкнув на ОК.
Можно перейти сразу во вкладку Дополнительно, поскольку там лос- т\пны все настройки, включая параметры, показанные на вкладке Общие (через Класс пользователя по умолчанию и Стандартные параметры DHCP). Может оказаться, что надо закрыть это окно н заново открыть его, чтобы синхронизировать списки параметров во вкладках Общие и Дополнительно. Если какой-то класс вендора или пользователя заставляет использовать определенные значения параметров, они должны быть определены для этого класса на соответствующем глобальном уровне, уровне области или клиента. Класс не должен давать одно и то же то же значение для какого-либо параметра везде, где он используется, его задача —указывать уникальные значения для каждого случая.
Может понадобиться запомнить порядок применения этих установок, когда сервер будет решать, какие параметры направить клиенту.「ло- ба-льный уровень, класс на глобальном уровне, область, класс на уровне области, клиент (резервирование), класс на уровне клиента — в этом порядке конфликтующие параметры могут отменять друг друга. Запомните, что клиент может предоставить только один класс пользователя. Чтобы уменьшить объем работь( по администрированию, определяйте параметры на самом высоком уровне и затем отменяйте их, где это необходимо. Обратная сторона такого подхода — то, что может быть затруднительно определить, какие параметры будут переданы клиенту DHCP, поскольку придется анализировать установки на нескольких уровнях.
Застройка клиентов для ；использования DHCP
； Главные этапы настройки клиентской системы Windows для исполь- ;зования DHCP были рассмотренье в главе 14. Там было показано, что в диалоговом окне Свойства TCP/IP имеется флажок, позволяюший полу- '(чить настройки IP or сервера DHCP. Если клиент явно установил значе- ;ния свойств TCP/IP, напрнмер порядок поиска серверов DNS, они от- :меняют значения, передаваемые как параметры DHCP. Разумеется, клиенты отличаются друг от друга, и Windows 2000 имеет некоторые ■ особенности диалогового окна свойств TCP/IP, что очевидно следует из :рисунков в этой главе. Прежде чем производить такую отмену, необхо- .димо проверить эти дополнительные элементы.
， В этом разделе рассматривается ряд других факторов настро访кн, не :описанных в главе 14.
■ Хотя в RFC определено много параметров, старые клиенты Microsoft [DHCP могли воспринимать только шесть из них.
Адреса шлюзов (маршрутизаторов) по умолчанию (код 3).
Адреса серверов DNS (код 6).
j ■ Доменное имя DNS (код 15).
В ■ Адреса серверов WINS (код 44).
g■ Тип узла (разрешения имен) NetBIOS (код 44).
卜■ Код области NetBIOS (код 47),
Следует убедиться, что настройки динамической регистрации в DNS, [заданные в клиенте и на сервере DHCP, не противоречат друг другу.
Клиенты Windows 2000 и Windows 98 поддерживают классы вендора, а } в теперешней версии клиенты Windows 2000 можно настроить для работы 宁 С классами пользователя. Для этого необходимо воспользоваться новой Г версией программы командной строки ipconfig.
Г ipconfig позволяет просматривать и изменять класс пользователя. [Следует указать параметр <интерфейс>; его значение можно узнать с ' помощью ipconfig /all. Обычный интерфейс — это Подключение к 『локальной сети; это значение надо заключить в кавычки, так как оно ;содержит пробелы.
i ipconfig /showclassid <интерфейс> показывает коды классов ' DHCP, разрешенные для данного адаптера (который можно указать, если I у вас имеется несколько адаптеров).
ipconfig /setclassid <интерфейс> 〈строка кода класса〉 позволяет изменить код класса. <строка_кода_класса> чувствительна к регистру. Она должна совпадать с кодом класса на сервере DNCP. Если <строка_кода_класса> опушена, любое исходящее значение удаляется.
Перед тем как перейти к следующей теме, запомните, что команда ipconfig /renew освобождает и обновляет все существующие аренды DHCP, а параметр /release лишь освобождает IP-адрес, оставляя клиента на этом интерфейсе без адреса.
DHCP в сравнении с ВООТР
DHCP — это расширение протокола загрузки (Bootstrap Protocol. ВООТР). Создание ВООТР (определенного в стандартах RFC 951 и 1532) преследовало две цели: чтобы клиенты могли запросить адрес IP и дру!ис настройки ТСP/IP, а бездисковые рабочие станции — размещение файла загрузкн, из которого они загружались после получения этого фай ij образа загрузки по простейшему протоколу передачи файлов (Trivial File Transfer Protocol, TFTP). Но в исходном виде ВООТР не поддерживас! принцип аренды, н каждый аппаратный адрес клиента должен быть связан с конкретным адресом IP.
Поскольку компьютеры пол управлением Windows поддерживаю! DHCP, но не используют ВООТР, причин применять ВООТР в чистом Windows-окружении не много. Но так как Windows предоставляет услу, и DHC巳 a DHCP происходит от ВООТР, в Windows начиная с NT 4.1) Service Pack 2 предлагается поддержка клиентов ВООТР. Это означат、 что сервер DHCP может реагировать как на запросы DHCP, так и на запросы ВООТР от оиентов UNIX и/или бездисковых рабочих станции Это может быть особенно ценно в разнородных окружениях, где мнаис возникла бы проблема конфликта серверов DHCP/BOOTP. Как и дл” DHCP, Windows предусматриваст прохождение запросов ВООТР из пол- сетей, удаленных от сервера, через настраиваемые агенты ретрансляции. Однако Windows 2000 не имеет настраиваемой службы TFTP ля” доставки файлов загрузки.
Эта частичная поддержка может показаться странной, но, если учесть объем использования файлов загрузки в сетевых устройствах, такое огра ничение не кажется особенно серьезным и. конечно же, не оказываем влияния на клментн Windows, Параметры DHCP (назовем их здесь параметрами ВООТР) служат для информирования клиентов ВООТР об имени и местонахождении (сервере) файла загрузки. Windows 2000 DHCP Serx'er игнорирует запросы ВООТР. если в таблицу ВООТР нс была включена нн©орм;ш“я по KpariHeii мере об одном файле загрузки Еше одна особенность Windows 2000 — клиенты ВООТР, которые специально не указывают запрашиваемые параметры, не получают никаких.
Дннаммчнос расширение ВООТР в Windows 2000 предусматривает упрощение администрирования за счет объединения IP-адресов в области ВООТР. Если имеются области ВООТР, не нужно задавать жесткое соответствие между компьютерам” ” IP-адресами путем резервирования при условии, что не нужны особые параметры или клиенты ВООТР не поддерживают динамический ВООТР. Области ВООТР создаются точно
так же, как и обычные области, но затем они помечаются как предназначенные для запросов ВООТР путем выбора переключателя Назначать динамические IP-адреса клиентам — только ВООТР или — обоих типов серверов во вкладке Дополнительно диалогового окна Свойства области.
,как показано на рис, 15.13. В отношении этого диалогового окна следует заметить, что для клиентов ВООТР достх'пны все возможности динамического обношения DNS.
Чтобы настроить файл загрузки, сначала измените исходные значения во вкладке Общие диалогового окна свойств сервера DHCP, показанной ;на рис. 15.14, — установите флажок Отобразить папку таблицы ВООТР.
Откройте интерфейс управления сервером DHCP.
Щелкните на узле сервера, чтобы установить на него фокус, вызовите контекстное меню (щелчком правой кнопки мы ши) и выберите в нем команду Свойства.
Во вкладке Общие появившегося диалогового окна установите флажок Отобразить папку таблицы ВООТР.
Щелкните на ОК и закройте диалоговое окно Свойства.
「о***) с<ч»& ats I 必m j4 "^「о***) с<ч»& ats I 必m j4 "^|С8о%ства Область [169.254.：
「о***) с<ч»& ats I 必m j
4 "^
「о***) с<ч»& ats I 必m j
4 "^
£бщче1 C/tfxcdiDN^ Лы»л
・ Ншначвгьл»м1Мм«41Р«ияы ммигj
-「томо ОЦФ
Рис. 15.13. Настройка области DHCP для обслуживания клиентов ВООТРРис. 15.13. Настройка области DHCP для обслуживания клиентов ВООТР「Oto* мюв помп»
Рис. 15.13. Настройка области DHCP для обслуживания клиентов ВООТР
Рис. 15.13. Настройка области DHCP для обслуживания клиентов ВООТР
] 曾 ~| 一 Отлои I n»tfp,^J
Рис. 15.14. Настройка сервера DHCP для доступа к таблице ВООТР
Следутошая операция также необходима, поскольку сервер игнорирует запросы ВООТР, если этл таблица пуста. Когда на консо;в! сервера DHCP появится узел Таблица ВООТР, вызовите в его контекстном меню команду Создать образ загрузки и введите нужную информацию. Эга информация будет возвращаться сервером DHCP при ответе на запрос ВООТР.
Откройте интерфейс унравлення сервером DHCP.
Раскройте узел сервера.
Щелкните на узле Таблица ВООТР. Если этот узел не виден, проведите описанную ранее процедуру, включив отображение таблицы ВООТР в диалоговом окне свойств сервера.
Уже заданные файлы загрузки ВООТР перечислены на правой панели. Чтобы добавить новый файл, вызовите контекстное меню узла Таблица ВООТР (щелчком правой кнопки мыши) и выберите в нем команду Создать образ загрузки
Введите имя сервера TFTP, имя файла загрузки и путь к нему на сервере TFTP, а затем щелкните на кнопке Добавить.
Пакеты ВООТР и DHCP имеют почти одинаковый формат, и оба по умолчанию используют порты UDP 67 и 68 соответственно на сервере и клиенте. Но ответ сервера ВООТР имеет фиксированный размер, меньше, чем возможный для DHCP, из чего следует, что при настройке параметров, которые будут возвращаться в ответе ВООТР, необходимо соблюдать осторожность. Клиенты ВООТР не знают аренды, подобной аренде IP. Это не является проблемой при традиционном использовании ВООТР, когда для всех клиентов ВООТР создаются резервирования Windows 2000 DHCP Server, как было показано, позволяет задавать области для обслуживания ВООТР, динамически распределяющие IP- алреса. В слуипс динамического расширения ВООТР сервер DHCP по истечении срока аренды проверяет, используются ли еше адреса, назначенные клиентам ВООТР, и ползает их обратно. Следует также заметить, что процесс обмена между сервером и клиентом ВООТР состоит из двух этапов, а нс из четырех; кроме того, в этом случае нет периодического обновления.
Если требуется предоставлять параметры отдельно для каждого клиента ВООТР, для них должны быть соззанм резервирования по их МАС- адресам. Это делается точно так же. как и для клиентов DHCP. В табл. 15.2 приведены некоторые параметры, поддерживаемое для ВООТР. Клиент ВООТР должен явно указать параметры, иначе он не получит ничего.
Резюме
Многие не используют DHCP или сомневаются, использовать ли его, так как на ранних стадиях своего развития эту службу нельзя было как следует кнгегрировать с DNS. Хотя старое решение Microsoft с применением WINS позволяло реализовать эту возможность, нестабильность первого поколения WINS it ее “астимН характер не способствовали ее популярности
В этой главе показано, что благодаря сочетанию Microsoft DHCP и DNS с разрешенным динамическим обновлением компьютеры в сети могут иметь динамически присвоенные IP-адреса, что нс мешает им)ча- ствовать r DNS. Кроме гого, это избавляет от множества усилий по администрированию. В случае применения DHCP следует подымать о количестве и размеи(ении серверов DHCP и совместном влиянии на DNS
Д этой службы и. например, процессов очистки. После этого можно уста- ;Хновить и авторизовать службу DHCP Server, определить и включить об' дасти и параметры и настроить клиенты так, чтобы они стали клиентами ' DHCP. Если сушествует база клиентов DHCP, изменение их сетевой на- 1 стройки производится централизованно с помошью предоставляемых па- i раметров DHCP.
[Таблица 15.2. Некоторые параметры, применяемые для клиентов
!воотр
I 7
I
ПараметрНазначение
Маска подсети
Маршрутизатор
Сервер времени■
Сервер имен
Сервер DNS
!9Сервер LPR
j12Имя узла
；13Размер файла загрузки
i15Доменное имя DNS
■16Сервер обмена
i17Корневой путь
;28Адрес широковещания
I42Серверы NTP
,43Информация вендора
:48Сервер шрифтов системы X Window
49Диспетчер отображения системы X Window
；66Имя узла загрузочного сервера
67Имя файла загрузки
69Сервер SMTP
70Сервер POP3
WINS: традиционные службы имен и разрешение
В этой главе...
Рассматривается служба имен interne! для Windows (Windows Internet Naming Service, WINS). Весьма вероятно, что администратор будет мметь дело с этой службой. WINS рассматривается в этой книге о DNS только потому, что предоставление служб имен в полном объеме для компьютеров под управлением Windows, особенно низкоуровневых версий, требует знакомства с этой службой имен Windows, Кроме того, Microsoft рекомендует интегрировать службы DNS Windows 2000 с WINS, если имеются клиенты NetBIOS, Это очень полезно с точки зрения разрешения имен WINS для клиентов Windows 2000. Ошибочно рассматривать DNS и WINS как аналоги, поскольку у них разные, хотя и в некоторой степени пересекающиеся, возможности. Здесь описаны преимущества и методы включения просмотра имен WINS на сервере DNS.
Возможности WINS. WINS оказывает неоценимую услугу, помогая клиентам разрешать имена NetBIOS в сегментированных сетях, но се правила и реализация накладывают некоторые ограничения. В этом разделе описываются наиболее важные преимущества WINS
и предлагаются советы для преодоления ее ограничений. Роль, ко- торую играет WINS, особенно ее интеграция с DNS, — важный фактор при развертывании Windows 2000.
Установка серверов WINS. Установить WINS довольно легко, как показано в этом разделе.
Настройка DNS с интеграцией WINS. Несколько записей в доменах DNS, разрешающих DNS применять WINS, специфичны для Microsoft. Здесь приводятся советы по правильному использованию этой особенности.
Возможности WINS
На каждом компьютере под управлением Windows есть некоторые приложения, используюшие имена NetBIOS. Это справедливо и для Windows 2000. Windows унаследовала эту особенность с той эпохи, когда Microsoft и IBM вместе работали над программами связи, такими как LAN Manager. Начиная с версии NT 3.5 Microsoft определяет WINS как службу, работающую по протоколу TCP/IP и способную к переводу имен NetBIOS в IP-адреса и обратно. W1NS не заслужила у администраторов особенно хорошей репутаиим; однако в NT 4 Service Pack 3—5 WINS претерпела серьезные изменения, в результате чего ее стабильность повысилась. WINS в NT 4 Service Pack 5 имеет ту же функциональность, что и в Windows 2000, и может работать с ее сервером WINS.
WINS предоставляет службу имен NetBIOS (NBNS) в сетях TCP/IP, со- отвечствуюшую стандартам RFC 1001 и 1002. До появления WINS обслуживание имен NetBIOS в сегментированных сетях было связано с большими проблемами. Широковещательные операции либо не проходили через маршрутизаторы, либо нарушали работу сети. На рис. 16.1 показана ситуа- иия. в которой миенты Боб и Терри, не подцерживаюшие WINS, не имеют доступа ни к одному ресурсу в широковещательном домене В, путь к которому лежит через маршрутизатор, соединяющий два сегмента.
Когда система NetBIOS впервые была выделена в TCP/IP для решения проблемы сегментации, пары имен и IP-адресов, которые нельзя было узнать при широковешании, были собраны в файле lmhosts. Главная трудность этого способа, напоминаюшего старый файл HOSTS, который применялся до появления службы DNS, состояла в ручном административном обслуживании. В предыдущем примере на каждой машине должен 6ь1л быть файл lmhosts, в котором были бы перечислены IP- адреса .тля имен NetBIOS всех других машин. Ясно, что это требовало большого объема работы при изменении машин и сетей. WINS дала решение этой проблемы. В этом примере необходимо лишь, чтобы все машины были настроена для работы с одним и тем же сервером WINS или с сервером WINS в одном и том же цикле репликации.
Рис, 16.1. Сегментирование в сети, разделенной маршрутизатором
Примерно в то же время, когда появилась WINS, для динамическою присваивания IP-адресов начал применяться протокол DHCP, Возможность для клиента DHCP объявить себя в системе WINS в сети IP создавала окончательное решение для клиентов Windows, причем для определения местонахождения этих клиентов, кроме стандартной службы имен DNS, не требовалось никаких дополнительных машин. Рост популярности промышленного стандарта TCP/IP в качестве протокола и обыкновенно вводимое в целях безопасности ограничение на разрешение NeiBIOS в сетях intranet скоро сделали сочетание WINS и DHCP недостаточным для удовлетворения всех нужд.
Когда служба DNS стала частью Windows NT 4, были также введены специальные записи WINS и WINS-R (для обратного просмотра), чтобы серверы DNS могли искать имена в базе данных WINS. Интеграция DNS и WINS в то время была единственным способом реализовать эту важную функцию, особенности и преимушества которой описаны ниже. Теперь Windows 2000 может предоставлять многие из этих функциональных возможностей для клиентов нижнего уровня, зарегистрированных н NetBIOS, благодаря Windows 2000 DHCP Server. Однако, как считает Microsoft, для клиентов Windows 2000 можно наиболее эффективно определять местонахождение ресурсов NetBIOS, продолжая использовать интеграцию WINS и DNS.
Что ожидает WINS и NetBIOS в будущем
Администраторы должны планировать поддержку NetBIOS, пока в их сети остаются компьютеры с DOS LAN Manager, Windows 95/98, Windows NT 3.x и Windows NT 4. Всем этим клиентам нужна NetBIOS, и она 6у-
' дет нужна им и в дальнейшем. Хотя сочетание динамической DNS (DDNS) и использования DHCP в Windows 2000 дает более новые, лучше соответствуюшие стандартам средства для работы через сеть, чем старая, нестандартная интеграция WINS и DNS, бывают ситуации, когда их немедленное использование для старых клиентов неудобно. Только когда Windows 2000 и ее преемники полностью заменят прежние операцион- ,ные системы, можно будет с уверенностью сказать, что от NetBIOS можно отказаться. Вполне вероятно, Microsoft создаст альтернативные клиенты для традиционных систем, но пока это доступно только для Windows 95 и 98. Даже при такой модификации нельзя забывать, что NetBIOS — это API и соглашение об именах, а не настоящий сетевой протокол. (Подробнее об этом см. главу 17, ''NetBIOS: традиционные службы имен и разрешение''.) Поэтому применение NetBIOS встроено в приложения.
:Очень легко спутать отказ от NetBIOS через TCP/IP (NetBT) с отказом от NetBIOS Следовательно, даже если все клиентские операционные системы клиента имели бы полную функциональность без имен NetBIOS, возможно, что эти имена все равно были бы нужнм для старых приложений. И решение для этой ситуации — WINS,
:Задачи и ограничения WINS
I Без WINS клиенты мог\т обнаруживать другие ресурсы с именами NetBIOS только путем широковещания по локальной подсети или поиска их в файле LMHOSTS. Это возможно только в случае очень маленьких сетей. Первоначально в сетях NetBEUI использовалась модель Широковешания;
‘ затем, с ростом популярности TCP/IP, начал применяться файл LMHOSTS, Ограничения этих "малосетевых" подходов стали очевидны, поскольку
'системы Windows начали применяться в сетях большого масштаба.
Серверы WINS обрабатывают запросы одним очень простым способом: они отвечают положительно и дают искомые имя и адрес или отвечают отрицательно и выдают сообщение ''Запрашиваемого имени не су- шествует'1 Серверы WINS ищут имена в своих файлах баз данных компьютеров, которые были зарегистрированы на них или на любых серверах WINS — их партнерах по репликации.
WINS создает централизованную, но реплицируемую базу имен NetBIOS. Что более важно, WINS, по определению, работает по протоколу TCP/IP и является динамической. Это решает проблему сегменти- (рования, которую имели широковешательные протоколы, и допускает динамическое присвоение 1Р через DHCP при сохранении осмысленных имен компьютеров. Клиенты WINS требуют регистрации имен в базе данных WINS, а когда им необходимо найти ресурс по имени NetBIOS, они делают запрос в эту базу данных, требуя перевести это имя в IP- адрес, Имена NetBIOS, как показано в главе 17, могут объявлять различные типы ресурсов. Эта особенность позволяет определять местоположение служб таким способом, который нельзя было реализовать через службу имен DNS, пока не появилась запись ресурсов SRV.
Сочетание протокола TCP/IP и использования имен NetBIOS реализовано в системах Windows в службе Net ВТ. Уже давно известно, чю NetBIOS через TCP/IP — далеко не идеальное решение и что это фактически создает проблемы, потому что система NetBIOS просто не предназначалась для такой всеобъемлюшей сети, как Internet. NetBIOS была разработана для малых сетей н теперь работает в сетях, во много тысяч раз больших по размеру, чем те, для которых она бьыа создана Хотя решение WINS преодолело проблему маршрутизации, оно привнесло свои собственные проблемы. Одной из проблемных областей, особенно до появления NT 4 Service Pack 3, была архитектура репликации. Не решена проблема производительности вследствие размера базы данных и отсутствия иерархической структуры, которая непосредственно связана с тем, что пространство имен NetBIOS плоское, одноуровневое. Поспе внедрения WINS NetBT, в принципе, легко может передать массу информашш о системе Windows кому угодно в мире. Одной из особенностей распространения сетей intranet было блокирование портов NetBIOS (137, 138 и 139) в брандмауэре с целью защиты от внешнего мира информации об объявленных машинах и службах. Решаюшим фактором было стремление защитить некоторые из объявленных служб, например службу серверов Честно говоря, с появлением записей служб (SRV) эти проблемы просто переместились в службы DNS.
Как работает WINS
Вся связь в WINS организуется по протоколу дейтаграмм пользователя (UDP) через порт 137. Другие порты, часто связываемые с NetBT,— это TCP 139, который используется для сеансов протокола блока серверных сообщений NetBIOS (Server Message Block. SMB), и UDP 138, применяемый для гиироковешания NetBIOS и однонаправленного трафика. Но для регистрации и разрешения имен NetBIOS служит порт 137.
Серверы WINS поддерживают базу данных, содержащую отображения имен NetBIOS на IP-адреса. В отличие от DNS эта база данных плоская, а не иерархическая. Она может копироваться (реплицироваться) на несколько серверов WINS для повышения доступности и отказоустойчивости. Исходный сервер WINS, который предоставил регистрацию имени, владеет всеми регистрациями в базе данных. Монопольное использование становится важным, когда базу данных копируют несколько серверов WINS. Оптимальная для системы архитектура репликации зависит от многих коэффициентов и выходит за пределы рассмотрения этой главы В число этих факторов входят количество серверов, необходимое по соображениям емкости и отказоустойчивости, н их размещение в топологии сети. Microsoft выпустила ряд документов по этим вопросам с рекомендациями в отношении нескольких типов архитектуры репликании- которые изменились с развитием WINS и поэтому требуют консультации для получения дополнительной информации. В обшем, рекомендуется максимальная простота системы при минимальном числе серверов, на-
j строенных как опрашиваюшие/извещающие паршеры по репликации, F для того.чтобы все клиенты WINS обслуживались в одной базе данных.
I
1'Службу WINS можно рассматривать как пассивную, или управляемую
клиентами. При этом не учитывается архитектура репликации базы данных WINS, но такой подход допустим с точки зрения клиента WINS, потому что WINS никогда сама не начинает связи с клиентом. Даже при
I интеграции WINS с DNS сервер DNS является, по сути, клиентом, за- [прашиваюшим WINS,
:WINS предоставляет услуги по требованию клиентоз. Клиенты WINS
I отвечают за четыре главных действия: регистрацию имени NetBIOS, его ； обновление, освобождение и запрос.
{ Регистрация имени NetBIOS
S
'При запуске клиента WINS или изменении его IP-адреса (в случае,
если это юшент DHCP) клиент посылает на сервер WINS запрос регист- ,рашпз содержащий его имя и IP. Если это имя не используется, сервер !. WINS отвечает полтверждением, предоставляя имя и интервал обновле- > нияп или срок жизни (time-to-Iive, TTL). Сам сервер WINS использует это у значение для периодической очистки, потому что он знает, что клиенты i должны возобновить свою регистрацию в течение этого времени, или : имя может быть освобождено. В случае конфликта имен сервер WINS [проверяет, используется ли еше зарегистрированное имя. Конфликт I имен имеет место, когда требуемое имя соответствует записанному в базе ' данных, но связанный с ним IP не совпадает с адресом, записанным в ' этой паре "имя-аарес" в базе данных. Сервер WINS проверяет регистра! цию, посылая запрос о состоянии адаптера NetBIOS на IP, соответст- : вующи!! имени в базе данных WINS, или на каждый IP, если имя запи- f сано в групповой регистрашш. Если машина действует и откликается в течение трех попыток, предпринимаемых сервером WINS, м возврашае- , мое имя соответствует в базе данных этому IP, запрашивающая машина : получает отрицательный ответ. Если в ответ на три запроса о состоянии 1 адаптера не приходи? никакого отклика, имя делается лоступннм и пре- ；доставляется регистрация.
■ Когда клиент пробует зарегистрироваться. может оказаться, что основ: ной сервер WINS недоступен. Клиент повторяет попытку и после трех не- ； удачных попыток переключается на спелую山нН указанный в его настрой- ； ках сервер WINS. Если все попытки войти в контакт с сервером WINS не удаются, камент может перейти к широковещательному объявлению о своем имени при услонии, что тип узла NetBIOS клиента позволяет это,
I Коша клиенг многосетевой, он регистрируется на каждом интерфей- [се, связанном с NetBT. Но на каждом интерфейсе, связанном с NetBIOS, регистрируется только первый IP Многосетевая адресация реализуется , различными способами; но для NetBIOS она означает только наличие ； нескольких сетевых карт. Еше раз напомним, что NetBIOS использует только один IP-адрес на каждую карту. Многосетевая адресация с участием нескольких IP-адресов на карте в данном случае не применяется.
Обновление имени NetBIOS
Получив регистрацию имени WINS, клиент отвечает за сохранение этой регистрации, периодически обновляя ее. В ранних версиях NT 4 31s был довольно сложный и ненадежный ироиесс. В Windows 2000 алгоршм первого обновления отличается от используемого при следующих обнов пениях. Здесь применяется новая функция разбивки обработки сервера WINS (см. ниже). После первого обновления клиент пытается выполнил, следуюшее обновленце посредине срока TTL и повторяет обновление, если необходимо, перед переключением на дополнительный сервер (или серверы) WINS. Если клиент столкнулся с проблемами на своем основном сервере н переоючллся на дополнительный сервер, возможно, он будет периодически пытаться вернуться на основной сервер. Это поведение было одним из недостатков в версии NT 4, и, чтобы определить, yci- ранен ли этот недостаток полностью, требуется некоторое время, Точии задать интервалы обновления нельзя, так как они. скорее всего, различаются на разных платформах и версиях.
Администратор должен знать, что переключатель nbtstat -rr, появившийся в утилите командной строки Nbtstat в NT 4 Service Pack 4, доступен и в Windows 2000. С его помощью клиента WINS можно заставиiь обновить регистрацию своего имени (имен) NetBIOS. Раньше, чтобы любиться этого, приходилось перезагружать машгшу Для важных регистр/ ин〃，напрнмер на контроллерах домена (DC), это требовалось бы делан, слишком часто.
За叩ос имени NetBIOS
Запрос имени, конечно, является главной целью WINS. Регистрации и статические записи образуют базу данных, к которой направляется зп- прос, но сами запросы, как правило, более часты. Когда приложении! NetBIOS нужно соединиться с машиной или слабой, известной по имени NetBIOS, клиент WINS посылает запрос серверу WINS. Разрешение имени NetBIOS может производиться различными путями в зависимое!!! от настройки клиента и операшюнной системы, но для клиента WIN оно начинается с подключения распознавателя в NetBT к WINS. Как правило, этот запрос направляется основному серверу WINS. Когда сер вер дает положительный или отрииательный ответ, распознаватель принимает этот ответ. Только если сервер WINS не отвечает, распознавать% применит другие альтернативы, первой из которых будет какой-то дополнительный сервер (или серверы) WJNS при условии, что он записан в настройках. При успешном выполнении запроса WINS запрашиваюшп|'| клиент получает 1Р-адрес,
Освобождение имени NetBIOS
Когда к/шент нормально завершает работу, он посылает своему серверу WINS сообщение об освобождении. На это сервер WINS отвечает либо положительно, либо отрицательно. Цель освобождения имени в том.
чтобы сохранить базу данных и уменьшить количество имен, которые должен проверить сервер WINS, когда клиент пытается обновить свое имя. т.е., возможно, всего лишь перезагружается. Полезность отрицательного ответа на освобождение имени сомнительна. Клиенты, вероятно, игнорируют такой ответ.
Имя и характеристики базы данных в системах WINS
Как только что было сказано, в системе WINS все имена регистрируются на сервере WINS. Имена хранятся в базе данных на сервере WINS, который отвечает на запросы о разрешении имен в IP-адреса, основываясь на записях в этой базе данных. Имена NetBIOS служат для многих целей, как говорится в главе 17： эти цели различаются по последнему символу в именах. Записи WINS также имеют различные типы. На рис. 16.2 показаны возможные варианты создания статической записи WINS.
Обычно на эти различные типы записей WINS не обращают внимания, поскольку они выбираются автоматически при регистрации. Существуют следующие типы записей.
Уникальный. Служит для связи имени NetBIOS с единственным IP, обычно для имен [OOh], [03h] и [20h],
Группа. Предназначена для связи нескольких IP-адресов с именем NetBIOS для групповых соединений.
Имя домена. Используется для связи имени NetBIOS [ICh] с IP- адресами контроллеров домена
Internet Group. Применяется для связи имени NetBIOS (20h] с нс、 сколькими IP-адресами (до 25).
Многосетевой. Связывает имя NetBIOS с олннм IP для кавдого адаптера в машине, которая имеет несколько адаптеров.
Избыточность м распределение нагрузки можно реализовать за счет того, что в системе WINS может быть более одного сервера WINS. Эщ серверы копируют записи в базах данных друг друга, чтобы обеспечигь одинаковое представление пространства имен. Время этого копирования (репликации), часто называемое сходимостью базы данных, определяет, как быстро новая регистрация или запись станут видимы всем клиешаА； WINS, В большинстве систем Windows существует одна база данных WINS для всех клиентов всех доменов; таким образом создается возможность определения IP-адресов в пределах всей системы.
Каждое заре「нстрнрован“ое имя имеет запись в базе данных. Имя принадлежит серверу WINS, который зарегистрировал его, н копируется на все остальные серверы WINS. На консоли управления WINS содержимое базы данных можно отфильтровать по определенному владельцу Это создает иллюзию внутренней структуры в базе данных. Но эта 6a# данных является единой неразделенной совокупностью имен NetBIOS, организованных в базу данных типа Jet. Этот факт имеет определенные последствия, которые будут рассмотрены при установке сервера WINS.
Каждая запись имеет связанное с ней состояние. Записям также присваивается код версии, который служит для управления процессом реп - ликации. Запись может быть в активном, освобожденном или угасшем (также известном как захороненное) состоянии. Способ обработка записей, помеченных для угасания, в Windows 2000 усовершенствован; такхе изменен диапазон записей, которые можно вручную пометить для rauic- ния. Поскольку это усовершенствование очень важно, на рис. 16.3 показаны варианты выбора, предлагаемые при удалении записи.
[Упаленке записи
6 恥® 不亘运码或运近忌
Рис. 163 Возможные варианты при удалении записи WINS
Раньше гасить имя мог только владеющий им сервер WINS, а удал歼门， вручную можно бы;ю только статические записи. Теперь можно удалясь любые записи и использовать новь(й метод захоронения, который реплицирует стирание на все серверы-партнеры. Эти новые алгоритм* весьма повысили обшую стабильность реплицированной базы данных и улучшили управляемость
Система WINS также позволяет регистрировать статические имена. Это дает администратору возможность регистрировать имена для серверов, на которых работают операционные системы, неспособные к динамической регистрации WINS, и резервировать имена от выгрузки. Если зарегистрировать компьютеры, не поддерживающие WINS, как статические записи, клиентам WINS не будет разрешено регистрировать это имя. Статические имена уже приводили ко многим неприятностям, и их использование не рекомендуется. WINS различает динамические и статические запмсн и обрабатывает статические имена несколько иначе, чем динамические. Теперь можно заранее установить, можно ли переписывать статические записи при репликации. Статические имена в прошлом были главной проблемой в реагтицированной базе данных WINS. Усовершенствование WINS в Windows 2000 и при обновлении NT 4 может предотвратить эту проблему, а также проблему восстановления при репликации записей.
Преимущества и проблемы сочетания WINS и DNS
Microsoft DNS Seiver обладает большими способностями к взаимодействию, в частности с Microsoft WINS Server. Для реализации этого взаимодействия была разработана запись нового типа, которую можно вводить в файлы зон. Запись WINS специфична для DNS Windows и может быть приложена только к корневому домену зоны. Присутствие записи WINS сообщает серверу имен, что можно использовать WINS для поиска при ответе на запросы обо всех узлах зоны, для которых не имеется записей ресурсов в базе данных DNS. Эта функция особенна полезна для клиентов на базе UNIX, которым требуется соединиться с клиентами, поддерживающими как DHCP. так п WINS.
В Microsoft DNS Server можно разрешить использование WINS для разрешения имен узлов, так как часть имени узла в полностью уточненном доменном имени DNS подобна имени компьютера NetBIOS. В процессе разрешения клиент DNS запрашивает Microsoft DNS Server, который переадресует запрос соответствующему серверу WINS. Специфические для Microsoft записи WINS и WINS-R дают серверу DNS возможность перенаправить запрос на сервер WINS, который будет обрабатывать его, если сервер DNS иначе не может выполнить запрос по одному из своих авторитетных доменов.
Используя WINS и Microsoft DNS Server в сети IP, клиенты могут определять местонахождение других компьютеров и связываться с ними как по именам NetBIOS, так и по именам DNS. Если сервер DNS не может найти имя, он пересылает его на сервер WINS. После того как сервер WINS находит нужный узел, он возвращает адрес этого узла на сервер DNS, который пересылает его клиенту. Все взаимодействие между сервером WINS н сервером DNS скрыто от клиентов. Для клиентов операция между WINS и DNS выглядит так, как если бы сервер DNS обрабатывал запрос самостоятельно.
В NT 4 эта интеграция DNS/WINS решает, возможно, самую большую проблему для администраторов DNS: не нужно обновлять регистрацию имени. Удалив большую часть записей адреса (А) с сервера DNS и направив их на локальный сервер WINS, можно сделать сервер DNS как бы динамически обновляемым. Такой же подход решает проблему, связанную с IP-адресами, назначенными через DHCP. В этом случае клиент WINS обновляет базу данных WINS, и DNS может возвращать 1Р при обстоятельствах, в которых администратор DNS, возможно, не смог бы ничего сделать.
До появления DDNS единственный способ уменьшить число статических записей ресурсов, которые обычно приходилось обслуживать в файле зоны сервера DNS, заключался в интеграции WINS и Microsoft DNS. что позволяло использовать динамические возможности WINS. Это особенно ценно для компьютеров Windows, которые настроены на работу как с DHCP, так и с WINS, потому что в таком случае даже не нужно вручную настраивать клиенты Windows, возлагая всю работу по настройке на DHCP. Теперь, когда в числе возможностей DHCP в Windows 2000 предусмотрена динамическая DNS (DHCP рассматривается в главе 15, "Службы DHCP в Windows'') и эта служба может регистрировать даже низкоуровневые клиенты, значение WINS для обслуживания пространен ва имен уменьшилось. В Windows 2000 появились новые альтернативы, как у клиента, так и у сервера DHCP, регистрировать эти записи в DNS через динамическое обновление. Следует проанализировать потребности и возможности клиентов, использующих DHCP или DDNS. и затем определить роль, которую интеграция DNS/WINS должна играть в системе.
Установка разрешения WINS через DNS на уровне клиента
В системах низкого уровня имеется параметр настройки TCP/IP, относящийся к интеграции WINS и DNS, но независимый от нее. Эго флажок Включить DNS для разрешения Windows (как он называется в NT 4). На основании этой настройки распознаватель клиента управляет пс- ресылкой запросов WINS на сервер DNS (и также допускает использование файла HOSTS, если это необходимо). При этой настройке клиент будет сначала запрашивать DNS, а затем, при необходимости, использовать другие средства. Вольшннство распознавателей низкоуровневых клиентов обычно придерживаются другого порядка: сначала используют методы разрешения NetBIOS (кэш NetBIOS, WINS, LMHOSTS), а затем обращаются к DNS для разрешения имени NetBIOS. Следует указать, что 亦 настройку клиента можно дополнить применением специальных запнсе】1 WINS и W1NS-R для интеграции WINS в DNS. Однако это необязательно. Сервер DNS при необходимости обращается к WINS, если это разрешено, независимо от этой установки клиента. Она лишь предоставляет распознавателю клиента прямой путь к этой дополнительной возможности службы DNS. По тем же причинам необходимо указать, что этот параметр настройки клиента должен устанавливаться, только если обслужи-
вание запросов WINS в DNS будет проходить успешно. Это можно обеспечить либо путем интеграции DNS/WINS, либо аккуратно соблюдая правила именования как узлов, так и доменов DNS, которые распознаватель клиента будет дописывать при формировании запросов DNS.
Замечания по интеграции DNS/WINS и ее стратегии
Даже при том, что компьютерное имя в WINS является именем NetBIOS, оно может также быть именем узла компьютера Windows в системе доменных имен IP. Но при этом подразумевается, что схемы именования не противоречат друг другу, т.е. можно использовать одно и то же имя в обоих пространствах имен. Для упрощения интеграции DNS и WINS это даже необходимо.
Одна из рекомендуемых методик при интеграции DNS и WINS в Windows NT состоит в том, чтобы выделить делегированный домен DNS для использования всеми клиентами WINS. Причина гако订 рекомендации проста: обычно имеется одна база данных WINS. Если WINS включена в нескольких зонах DNS, компьютер, зарегистрированный в WINS, доступен сразу в нескольких зонах DNS, и, следовательно, по полностью уточненным именам. Иными словами, имя WINS было бы пилимо серверу DNS в нескольких зонах. Поскольку это привело бы к путанице, а в некоторых ситуациях — к трудностям с настройкой, принято использовать записи WINS и WINS-R только в одном субдомене. Такнм образом, домен DNS, указанный в свойствах TCP/IP машины клиента, всегда может аккуратно обрабатывать ответы, полученные от разрешения DNS. с использованием интеграции WINS.
Однако похоже, что эта стратегия вступает в конфликт с Windows 2000, где рекомендуется согласование домена Windows и домена DNS. (Фактически в первой версии Windows 2000 отступление от этою правота даже приводит к многочисленным проблемам.) Действительно, Windows 2000 DNS Server дает возможность указать, какой домен DNS будет использоваться для формирования полностью уточненного доменного имени (FQDN), когда обратный просмотр выполняется с помощью WINS. Но верно и то. что всех клиентов NetBIOS рекомендуется собирать в одной базе данных WINS, Эти клиенты могут принадлежать к разным доменам Windows, т е., скорее всего, н к разным доменам DNS. Одно из возможных решений кроется в слабо документ крован ной возможности настройки се- тевьгх интерфейсов Windows 2000 для использования дополнительных доменов DNS. Но если требуется более прямой путь, следует признать, что эта проблема разрешения традиционных имен вызвана только наличием устаревших клиентов. Предоставление '"традиционным" (т.е. устаревшим) клиентам отдельного домена DNS при сохранении их членства в разных доменах Windows 2000 порождает меньше проблем, чем такая же операция с клиентами высокого уровня. Они могут быть выделены в такой cueuu- ально делегированный домен DNS как клиенты второго класса в архитектуре службы каталогов Windows. В конце концов, разве вы не собираетесь через какое-то время заменить их на клиенты Windows 2000?
Службы WINS и DNS могут работать на одном и том же компьютере или на различных компьютерах. Их размещение зависит от ряда факторов, например от того, используется ли интеграция DNS в Acii\e Directory'- В этом случае можно было бы порекомендовать разместить серверы WINS на машинах, менее загруженных, чем контроллеры домена. Помните, что высокозагруженный сервер WINS интенсивно использует дисковую подсистему, что, конечно же, не благоприятствует работе контроллеров домена Windows 2000.
Версии WINS
Как указывалось выше, сервер WINS в NT 4 был модернизирован в Service Pack 5, после чего он приобрел функинональность, одинаковую с сервером WINS в Windows 2000, Многие проблемы, с которыми приходилось сталкивалься в ранних версиях сервера WINS, были устранены за счет введения новых алгоритмов, и были внесены усовершенствования в выполнение основных процессов.
， К главным усовершенствованиям WINS в Windows 2000 можно отнести следующие.
Для партнеров по репликации с хорошей связью можно настроит,- постоянные подключения, что уменьшает потери времени на установку соединения и увеличивает скорость репликации при одновременном снижении нагрузки на серверы.
Усовершенствования в системе управления базой данных повышают надежность н производительность базы данных WINS.
Возможность захоронения записей вручную с репликацией захоронения гарантирует, что однажды удаленные записи не буд\т появляться вновь.
У.чучшсиный интерфейс управления делает админиелрированпе WINS более продуктивным.
Если возникает вопрос, на какой версии Windows разметать WINS, можно найти, что интерфейс администрирования в Windows 2000 более удобен. Конечно, нет никакой причины продолжать работу WINS в предыдущей версии WINS (учитывая повышенную прои зводитсльность п надежность новой версии). В приведенном выше списке не указано и множество новых функций управления серверами WINS и навигации в базе данных WINS. Помимо легкости в использовании, WINS Windows 2000 предусматривает проверку базы данных, экспорт базы данных и работу в командной строке.
Установка серверов WINS
Установка WINS чрезвычайно проста. Фактически она настолько про ста. что при сбоях немало администраторов выбирают переустановку WINS как средство устранения неисправности. Немногие требуемые деи- ствия указаны ниже.
Откройте панель управления.
Запустите аплет Установка/удаление программ.
Щелкните на значке Установка/удаление компонентов Windows слева и запустите мастер компонентов Windows.
Прокрутите список и выбери ге пункт Сетевые службы, как показано на рнс. 16.4.
Щелкните на кнопке Состав и откройте список сетевых служб.
Прокрутите список до конца и установите флажок напротив пункта WINS.
После этого просто завершите работу мастера компонентов Windows с помощью кнопок Далее и/или Готово или же установите в этом мастере другие параметры, если необходимо-
Рис. 16,4, Выбор сетевых компонентов для установки
Верите вы или нет, но с этого момента уже можно начать работу с WINS, Теперь для этого нужно лишь настроить клиенты для использования нового сервера WINS. Конечно, в будущем придется выполнять и другие настройки, но сервер WINS уже сейчас готов к работе. Если сеть крупная, придется установить несколько серверов WINS и настроить репликацию между ними. Кроме того, помимо ознакомления со службой WINS, необходимым для нее обслуживанием и ее интерфейсом, который можно HaiiTH под названием WINS в меню Пуск — Программы — Администрирование, надо будет установить несколько свойств.
На рис. 16.5 показана страница Свойства сервера WINS, которую можно открыть, шелкнув на сервере WINS правой кнопкой мыши и выбрав команду Свойства.
На этом рисунке указано место для резервных копий базы данных WINS и установлен флажок, включающий резервирование базы данных при завершении работы сервера (это стандартное поведение в NT 4). Если этот флажок не устанавливается, следует периодически резервировать базу данных, что можно выполнить с консоли управления.
Свойства: DEMO1I1O
дас:- ■ ■ . и*«； 中：；
| СЖ ] Оги» I Пуцаие ]
Рис. 16.5. Страница Свойства сервера WINS в Windows 2000
Другие параметры, которые можно найти на этой странице, позволя- ют настроить различные временные интервалы, например срок жизни TTL, который передается клиенту WINS как интервал обновления. ,1 также место хранения базы данных WINS и поведение сервера WINS при большом количестве запросов. Перед тем как изменять значения интервалов времени, следует прочесть о действии зткк параметров в документации и проанализировать их роль в данной системе WINS.
После некоторого знакомства с консолью управления можно заметить на ней команды очистки, резервирования и восстановления, проверки балл данных и другие. Мнотс из них находятся в контекстном меню, которое можно открыть, щелкнув правой кнопкой мыши на узле сервера. Проверка базы данных — это ресурсоемкая и не часто выполняемая операция. Начинайте ее, когда ее влияние на сеть будет как можно меньшим.
Windows 2000 WINS Server позволяет проводить уплотнение базы данных в фоновом режиме, а также допускает уплотнение вручную в автономном режиме. Поскольку производительность WINS тесно связана l размером базы данных, а фоновое уплотнение не дает столько свободного места, сколько можно получить при автономном уплотнении, большие базы данных WINS иногда уплотняют вручную. Ввиду того, что WINS фактически является системой управления базо访 данных, при выборе аппаратуры следует уделить особое внимание производительности дисков. Для работы с WINS надо знать и уметь применять команды резервирования, очисткн и сжатия, чтобы поддерживать работоспособность базы данных и ее максимальную производительность.
Новая функция разбивки обработки в сервере WINS Windows 2000 позволяет откладывать работу, когда сервер сильно загружен. При необходимости сервер немедленно предоставляет регистрации имен с корот - кими значениями TTL, когда они запрашиваются, без предварительной
проверки их доступности. При этом клиент сразу получает ответ, что ос* вобождает систему WINS от повторения запросов или переключения их на дополнительные серверы, а проверка откладь!вается на более поздний срок. В связи с тем что клиент Windows 2000 запрашивает первое обновление после истечения одной восьмой этого до пол н ител ьного короткого срока TTL, непроверенная регистрация действует недолго-
Как было сказано выше, репликация WINS подробно не рассматривается. Но есть несколько замечаний, которые мы хотели бы сделать. Во- первых, по умолчанию репликация производится только с явно заданными партнерами. Вероятно, эту настройку следует оставить без изменений. Это сделано более всего по соображениям безопасности, поскольку администратор при этом может контролировать всех, кто может получить копию базы данных WINS. Автоматическое обнаружение и настройка репликации целесообразны лишь в очень малых системах, где есть только два или три сервера WINS. Во-вторых, можно настроить партнеров для извещающей репликации, запрашивающей репликации или той и другой вместе. Эти методы репликации несколько различаются. Извещающая репликация, в отличие от запрашивающей, не планируется заранее. Это различие помогает при настройке партнеров, соединение с которыми происходит по медленным каналам. Но оно также влияет на время, которое требуется для сходимости базы данных к одному и тому же содержанию на всех серверах WINS. Когда репликация выполняется не по медленному каналу, рекомендуется использовать новую функцию постоянного подключения партнеров. Это неприемлемо для запрашивающей репликации, но там, где постоянное подключение применимо, оно существенно сн!1жает нагрузку и улучшает сходимость. При заира- шиваюшей репликации может потребоваться отрегулировать порог количества накапливаемых перед запуском репликации изменений- Этот порог должен соответствовать потребностям данной системы. Если не имеется никаких противо!юказаний, партнеров следует настроить для обоих типов репликации.
В заключение следует обратить вннманне на статистику WINS, доступную на консоли упраш|ения, поскольку она может дать вам представление о состоянии системы WINS и, более того, о ее загрузке. Заслуживают упоминания и два других средства контроля и управления WINS. Это, конечно же, объект WINS в системном мониторе и контекст WINS в neesh. (Пр01рамма netsh рассматривалась в главе 12, "Средства поиска неисправностей".) Умение работать с ними облегчит жизнь администратора, если WINS является ключевой и сильно загруженной частью системы.
Настройка DNS с интеграцией WINS
Для [щеальной интеграции узлы NetBIOS и DNS должны под,1ержи- вать как разрешение имен, так и обратный поиск адресов- Разрешение имен — это процесс, в koi ором имя узла NetBIOS или DNS разрешается в IP-адрес. Это означает, что по имени, например Hosl . example. net
(имя DNS) или Host (имя NetBIOS), должен быть однозначно определен IP-адрес, например 198.25.40.31. Обратный поиск адреса разрешас] IP-адрес в уникальное имя узла NetBIOS или DNS. Это означает, что по IP-адресу, например 19^.25.40.31, надо однозначно определить имя. например Host. example . net или Hosr,
В этом разделе рассматривается интеграция методов разрешения DNS и WINS и указываются проблемы, с которыми можно столкнуться при еи выполнении. Если речь идет о разрешении имен, больше всего усилии требует обеспечение разрешения узлами DNS динамических имен NetBIOS. Противоположный процесс тривиален, потому что узлы NetBIOS могут разрешать любые статические имена узлов DNS с помощью распознавателя DNS.
Перед тем как перейти к изучению этапов этой интеграции, иротппе следующий раздел, где на базе сценариев рассматриваются различные сочетания типов клиентов, чтобы выяснить, какме действия и в каком случае могут или должны быть предприняты. Этот раздел представляет собой обзор всего, что ло сих пор было сказано в этой главе; его мель более явно проиллюстрировать разнообразие ситуаций, с которыми можно столкнуться.
Как работает интеграция
DNS использует WINS благодаря добавлению в базу паннзх DNS специальных введенных Microsoft записей ресурсов (RR), Это всегда производится в корне зоны DNS. Когда сервер DNS п!>1тается разреизть запрос имени в домене, поддерживающем WINS, и не находит нужнои записи А, он может передать часть FQDN, образующую имя узла, в WINS. Если WINS возвращает IP-адрес, DNS кэширует его и возвращает клиенту. Чтобы этот процесс работал, домен DNS в FQDN должен поддерживать WINS. Во избежание путаницы клиенты WINS также должны знать, что это их домен DNS.
Различные ситуации при разрешении имен
В зависимости от объема взаимодействия между узлами DNS и узлами NetBIOS при разрешении имен могут складываться некоторые интересные сценарии,
В первом сценарии клиенты соединяются с серверами и между клиентами не нужно никакого взаимодействия. Если в соединении участвуют узлы NetBIOS (например, узль( Microsoft) и узлы DNS (намрммер, узлы UNIX), интеграция часто происходит без затруднений по следующим причинам.
Узлы NetBIOS могут запрашивать у сервера DNS разрешение имен узлов DNS. Это гарантирует, что к серверам UNIX можно обращаться из клиентов NetBIOS.
Узлам NetBIOS (например, серверам Windows, на которых работают FTP, IIS или другие серверные службы на базе TCP/IP) могут быть присвоены статические IP-адреса, которые могут быть отображены в базе данных DNS. Тогда клиенты UNIX смогут использовать DNS для разрешения этих узлов NetBIOS. Также можно использовать либо статические, либо присвоенные через DHCP IP- адреса в сочетании с динамической регистрацией DNS, хотя для главных серверов рекомендуется статическое назначение IP.
Клиенты WINS продолжают использовать серверы WINS для разрешения имен узлов NetBIOS в 1Р-адреса.
В этом сценарии фактически даже не нужно, чтобы в DNS было включено разрешение через WINS. Но если для назначения IP-адресов применяется протокол DHCP и DDNS не включена, этот сценарий не позволит клиентам UNIX находить узлы NetBIOS, обслуживаемые через DHCP. Впрочем, если эти клиенты регистрируются через WINS, a DNS использует WINS, любой клиент может найти эти узлы с помощью запросов DNS.
Во втором сценарии каждый узел должен был соединяться с другим узлом, например в рабочей группе, особенно в том случае, когда используется DHCP или когда статически присвоенные компьютерам NetBIOS IP-адреса не зарегистрированы в DNS статическими записями А. Интеграция становится более необходимой из-за неструктурированной связи между узлами NetBIOS и узлами UNIX и отсутствия динамического (или ручного) обновления DNS. В этой ситуации Windows DNS Server может обслуживать клиентов через интеграцию с WINS,
В дополнение к своей работе обычного сервера DNS Windows DNS Server помогает в поиске в базе данных WINS заданного имени узла, которое не может быть найдено в базе данных DNS. Если клиент UNIX, который ничего не знает о WINS, запрашивает имя узла NetBIOS, то, например, распознаватель DNS на компьютере UNIX можно настроить так, чтобы он указывал на службу DNS Windows. Windows DNS Server пройдет часть процесса разре山ення、относящуюся к DNS, а затем обратится к базе данных WINS (расположенной на той же или на удаленной машине). Фактически это позволяет клиентам, не поддерживающим WINS, разрешать нмена NetBIOS, запрашивая сервер DNS. До появления интеграции WINS не существовало способа надежного разрешения имен клиентов DHCP по причине динамической адресации【Р и отсутствия записи DNS А.
Число доступных альтернатив с появлением Windows 2000 увеличилось за счет реализации DDNS. Эта функция позволяет выполнять обновления DNS либо непосредственно клиентами, либо DHCP по их требованию. Фактически Windows 2000 DHCP Server может выполнять обновления даже для клиентов DHCP, отличных от Windows. Это дает клиентским системам сторонних разработчиков такую же возможность динамического назначения IP-адресов при сохранении разрешения DNS,
как и у клиентов разработки Microsoft. Но в этом разделе описывается прежде всего интеграция WINS, которая выполняется одним и тем же способом как в NT 4, так и в Windows 2000. Эту интеграцию предполагается поддерживать и в дальнейшем, и использоваться она будет главном образом для клиентов, не поддерживающих DHCP, или клиентов сторонних разработчиков, которые регистрируются в WINS.
Анализ ситуаций интеграции WINS/DNS
В первом приводимом здесь примере рассматриваются проблемы, связанные, скорее, не с интеграцией DNS/WINS, а являющиеся результатом непонимания потребностей клиента и неправильного использования интеграции. В этой ситуации клиенты пытаются достичь сервера в сети, администратор DNS которой не делает своевременных обновлений DNS, а динамическая DNS не включена. Эта сеть показана на рис. 16.6.
Широковещательный домен ВШироковещательный домен ВФайл-серверФайл-серверФренчиФренчиEarthEarth
Широковещательный домен В
Широковещательный домен В
Файл-сервер
Файл-сервер
Френчи
Френчи
Earth
Earth
Рис. 16,6. Варианты разрешения клиентов Windows NetBIOS
Предположим, что клиент Терри пытается проверить доступность недавно установленного в корпоративной части сети узла frenchy.example.net.
Если бы компьютер Терри (terxi. example .net) послал широковещательный запрос NetBIOS, этот запрос не прошел бы через маршрутизатор. Если он попробовал бы найти имя frenchy в своем файле LMHOSTS и запись frenchy.example.net в файле HOSTS, вероятно, что эта новая машина не была бы найдена. Два других варианта — проверить в DNS, является пн tern. example. net клиентом DNS, и в WINS—
является ли terri.example.net клиентом WINS. Возможно, не каждый помнит, что машины Windows не всегда являются клиентами DNS, по крайней мере до версии Windows 2000, и что они также необязательно могут быть клиентами WINS.
Если администратор DNS еше не обновил вручную файлы конфигурации для exan.ple. net. запрос DNS клиента Терри не будет разрешен. Если Терри ——клиент WINS, запрос направляется на сервер WINS на winsl. example.net. Если этот сервер WINS имеет отображение для \\FRENCHY, Терри получает IP-адрес и может связаться с этой машиной. Конечно, при интеграции DNS/WINS запрос DNS Терри был бы разрешен успешно, если \\FRENCHY зарегистрировано в WINS-
По этому примеру можно сделать некоторые наблюдения и замечания. Если новая машина — клиент WINS, она регистрирует имя WFRENCHY на сервере WINS, который должен быть либо самим winsl. example .пес, либо его партнером по репликации. Далее, если terri.example.net — низкоуровневь(й клиент DNS, а разрешаемое имя — f renchy. example .net, а не WFRENCHY, запрос будет сначала послан в DNS. Если tem. example. net — клиент Windows 2000. запросы в DNS и в WINS направляются одновременно. В любом случае интеграция DNS/W1NS дает наиболее быстрое разрешение. В первом случае потому, что WINS не будет проверяться, пока запрос DNS не потерпит неудачу, а в случае Windows 2000 из-за лучшей производительности DNS (при условии, что frenchy. example. net находится в кэше DNS после какого-то более раннего запроса) по сравнению с WINS с ее неструктурированной базой данных. Также следует подчеркнуть, что расположение серверов DNS и WINS в сети не имеет значения, если имеется связь с ними по TCP/IP. Наконец, надо заметить, что, если frenchy.example.net— клиент Windows 2000 пли клиент службы DHCP Windows 2000, любой из этих случаев может предусматривать прямую регистрацию в DNS с помощью динамического обновления.
Одна из проблем, с которыми можно столкнуться npst интеграции WINS и DNS, касается сетей, в которых IP-адреса управляются серверами DHCP, не относящимися к Windows 2000, Если frenchy. exarr.ple . net имеет статический IP-адрес 1 92 . 1 6Й . 10.4 1 И администратор DNS вручную создает запись А в файле конфигурации, отображающую этот адрес, Терри может связаться с frenchy. example .net. Но если \\FRENCHY использует сервер DHCP, который не обновляет DNS, IP-адрес является динамическим и, следовательно, может изменяться, и в этом случае у администратора нет никакой возможности отредактировать запись DNS А. Решение в этой ситуации —сделать WFRENCHY клиентом WINS и использовать интеграцию WINS/DNS. Однако это требует, чтобы WFPENCHY была системой Windows или по крайней мере системой UNIX, работающей через Samba. Другие не поддерживающие NetBIOS клиенты не могут воспользоваться этим старым способом интеграции DNS/WINS, как это возможно с помощью DHCP Windows 2000 с динамическим обновлением DNS.
Предпосылки для интеграции WINS/DNS
Для запроса DNS должно использоваться имя FQDN. Поэтому, чтобы запросить базу данных WINS через узлы DNS (с помощью Windows DNS Server), надо выделить в организации зону пространства имен DNS, которая будет содержать динамические узлы (под.'терживаюшие WINS), Например, если организации присвоен домен Internet example. net, можно делегировать зону (скажем, interactive. example .пег), которая 6уде1 содержать динамические узлы DHCP (поддерживающие WINS).
Основным сервером DNS для зоны interactive может быть назначен сервер DNS Windows. Основной сервер DNS Windows для этой зоны може】 также быть сервером WINS нлн указывать на сервер WINS в сети- Узлы UNIX (и узлы Windows в этом отношении) могут быть настроены так, чтобы запрашивать на сервере DNS Windows все имена узлов, которые буду! разрешены в части interactive . example. net пространства имен DNS- Сервер DNS Windows будет, в свою очередь, нспользовагь базу данных WINS (локальную или удаленную) для разрешения имена в зоне NetBIOS.
Этот подход рекомендовался в зпоху NT 4. Делегирование такой зоны для клиентов WINS давало ясный н простой способ интегрировать их видимость для DNS в существующую прхитсктуру служб DNS. Делегирование одной зоны в Microsoft DNS также было более приемлемо для существующих центров DNS, чем перенос нз BIND Это решение вь!годно для всех сторон — для сервера DNS, клиентов NetBIOS и для узлов, которые разрешают их но имени, — т.е. для всех, так или иначе связаннык с использованием FQDN.
Теперь рассмотрим другую ситуацию, с той же компанией, но с динамическим распределением узлов NetBIOS межд\ двумя зонам” (например, interactive!.example.net И inteiactive2.exanole.net). В этой ситуации назначение Windows DNS Server основным сервером для обеих зон позволяет разрешать имена узлов NetBIOS описанным выше способом. Такой же результат дает размещение этих 口вух зон на отдельных сервера、’ DNS Windows. Однако сервер DNS мри использовании WINS для разрешения имен не будет знать, действительно ли данный динамический узел NetBIOS относится к зоне interact .i vel iuim interactive? с точки зрения DNS (потому что база данных WINS не имеет структуры). Фактически DNS может на)1ти любой из узлов NetBIOS сразу в обеих зонах, что может создать проблему. Но при этом прямой просмотр продолжает выполнял ь свою задачу — определение правильного [Р-адреса.
Сформулмруег основные вопросы, связанные с интеграцией.
■ Используется ли DHCP?
■ Используется ли динамическая DNS?
■ Если ответы на оба этих вопроса утвердительные, могут ли вес клиенты DHCP динамически обновлять свои записи DNS? Эю почти эквивалентно вопросу, используются ли Microsoft DHCP н DNS и включено ли динамическое обновление.
■ Нужно ли уменьшить объем обслуживания записей ресурсов DNS вручную, не прибегая к DDNS?
Если ответы на эти вопросы показывают, что существуют назначения 1Р, не имеющие соответствия в записях DNS, возникают следутошие вопросы.
■ Нужно ли каким-нибудь клиентам, не поддерживающим WINS, разрешать имена для этих назначений IP?
■ Будет ли более удобно или эффективно сделать так. чтобы клиенты WINS разрешали эти “мена с помощью DNS?
■ Если ла. какое доменное имя (или имена) DNS следует использовать? И, если надо использовать несколько доменов или передавать зоны на серверы DNS, не являющиеся разработками Microsoft, будет ли допустимо возникающее при этом смешение?
Настройка DNS для использования WINS
Теперь вам должно быть ясно, что служба WINS устанавливается очень легко. Поскольку так же легко разрешить DNS использовать WINS, естественно, возникает вопрос, в чем же проблема?
Перед тем как использовать эту возможность, надо составить план, какие клиенты будут разрешаться и в каком домене DNS, как было рассмотрено выше. Это решение не столь просто в Windows 2000, как в NT, из-за того, что домены DNS используются как имена Windows 2000. Перед составлением этого плана не помешает также изучить работу обратного просмотра WINS-R, которая рассматривается ниже в этой главе. Кажется, Microsoft не дает никакого более ясного указания на это, чем вопросы, которые рассматривались ранее, или чем сама возможность заменить клиенты низкого уровня на Windows 2000,
Вторая проблема, причем гораздо более четко определенная, состоит в том. что записи WINS в зонах DNS будут передаваться на любой сервер DNS, отличный от сервера Microsoft, не без затруднений. Из этой ситуации легко выйти с помощью настроек, описанных ниже. Однако при этом появляются дополнительные серверы, неспособные разрешить все имена, разрешимые серверами DNS Microsoft для зоны. Это может привести к неустойчивому поведению, заметному для клиентов DNS.
Включение прямого просмотра WINS
В этом разделе рассказывается, как на консоли управления DNS настроить DNS для использования WINS. Но сначала показано, чго это можно сделать и в файлах зон.
В дополнение к стандартным записям ресурсов, поддерживаемым файлами зон DNS, Windows DNS разрешает применять записи WINS и WINS-R. В файле примера flace .dns, который можно найти в каталоге Swindiг%\SYSTEM32\DNS\Samples, сказано следующее.
Присутствие записи WINS в корне зоны указывает серверу имен, что он должен использовать просмотр WINS для любых запросов А-записеи (адресов) для имен, которые являются прямыми потомками корня зоны и которые не имеют A-записей в файле зоны
Этот файл, кажется, перенесен из NT 4 без изменений; он дает некоторые советы по использованию этой функции.
Общий синтаксис записи WINS имеет следующий вид.
<домен> IN WINS [LOCAL] [Ь<тайм-аут просмотра〉]
[С<тайм-аут кэша>) (〈серверы WINS〉)
Необязательный флаг local указывает, что эта запись не должна включаться в передачи зон. Между флагом local и именем сервера (или серверов) WINS, который предполагается использовать, можно указать значения [Ъ<тайм-аут просмотра〉] И [С<тайм-аут кэша>] в секундах.
Чтобы добавить запись WINS в файл зоны, запишите код, подобный следующему.
Листинг 16.1. Записи ресурсов для WINS в файле DNS
@ IN WINS LOCAL L900 С2 (
198.25.40.20
198.25.40.30)
earth.example.net.IN A198.25.40.20
mars.example.net.IN A198.25.4C.30
В этом примере указаны IP-адреса двух серверов WINS в том порядке, в котором они будут использоваться. Удалите флажок LOCAL, если запись WINS не должна передаваться при передаче зоны.
Более удобно, чем вводом записи WINS вручную, просмотр WINS можно включить на консоли управления DNS.
В NT 4 для этого надо выполнить слелуюшне действия.
Откройте диспетчер DNS NT 4.
Выберите зону, вызовите ее контекстное меню (щелчком правой кнопкой мыши) и откройте диалоговое окно Свойства зоны.
В диалоговом окне Свойства зоны выберите вкладку WINS.
Установите флажок Использовать разрешение WINS и введите【Р- адрес(а) сервера (серверов) WINS, которые нужно использовать, с помошью кнопки Добавить.
Установите флажок Не выполнять репликацию этой записи, если нужно, чтобы запись WINS не распространялась при передаче зоны.
В Windows 2000 настройка использования интеграции WINS выполняется подобным образом.
Откройте консоль управления Windows 2000 DNS Server.
Раскройте сервер в иерархической структуре на панели слева и выделите корневой узел зоны, в которой надо включить WINS.
Вызовите контекстное меню зоны (щелчком правой кнопкой мыши) и откройте диалоговое окно Свойства зоны.
В диалоговом окне Свойства зоны выберите вкладку WINS, как показано на рнс. 16.7.
Установите флажок Использовать прямой просмотр WINS и ввезите IP-aapec(a) серверов WINS щелчком на кнопке Добавить.
Установите флажок Не выполнять репликацию этой записи, если нужно, чтобы запись WINS не распространялась при передаче зоны.
Если необходимо, скорректируйте значение TTL, которое будет передаваться в ответах DNS.
Щелкните на кнопке Дополнительно во вкладке WINS,
Если необходимо, измените стандартные сроки кэширования ответов WINS сервером DNS и ожидания ответа от WINS.
Сохраните изменения, щелкнув на кнопке Применить или ОК.
WINS в ONS
На рис. 16.7 показано диалоговое окно настройки WINS для Windows 2000 DNS Server. Если при запуске консоли управления DNS Server на ее левой панели ваш сервер DNS не обнаруживаете开，следует выделить узел DNS в верхяей части этой панели и вызвать в меню Действие или в контекстном меню команду Соединение с компьютером.
Флажок Не выполнять репликацию этой записи определяет, будет ли запись WINS включена в передачу зоны, и соответствует флагу local в записи WINS. Щелкнув на кнопке Дополнительно, можно настроить таймаут кэширования и тайм-а\т ожидания запросов WINS. Тайм-аут кэширо-
вания определяет, сколько времени устаревающие данные могут оставаться в кэше сервера DNS; его нельзя смешивать со значением TTL, которое WINS предоставляет клиентам WINS, или значением TTL. которое DNS будет использовать в ответах. Однако эти значения целесообразно устанавливать одинаковыми, чтобы изменения зарегистрированных имен WINS отражались в использовании WINS службой DNS. Следует также знать, что можно добавить несколько серверов WINS, но что все они будут опрашиваться, возможно, задерживая просмотр WINS, если первый и второй серверы из списка окажутся труднодоступними и ненадежными. На рис. 16 8 показано то же самое диалоговое окно, но для дополнительной зоны, которая не получает записи WINS от основного сервера.
Рис. 16.8. Настройка WINS для дополнительной зоны
Здесь можно компенсировать отсутствие записи WINS в зоне, переданной с основного сервера. Обратите внимание, что управляющий этим флажок нельзя сбросить, поскольку Использование локальной записи ресурса WINS подразумевается, когда администратор вводит запись WINS, заменяю山ую аналогичную запись в основной зоне. Также предполагается, что эта запись будет рассматриваться как локальная и не будет передаваться на любой другой дополнительный сервер, для которого этот дополнительный сервер является главным.
Обратный просмотр в WINS
Хотя изначально WINS не была создана для обратного просмотра, при использовании Microsoft DNS Server она может выполнять эту функцию, подражая записям PTR для клиентов, поддерживающих WINS. Наличие записи WINS-R в корне зоны in-addr. агра сообщает серверу имен, что он
должен просматривать состояние адаптеров узлов NetBIOS при обработке всех запросов обратного поиска IP-адресов в зоне, если эти адреса нельзя найти в записях указателей (PTR.). Это означает, что в ответе на запрос DNS участвуют как сервер DNS, так и машина, используюшая IP. А это, в свою очередь, означает, что в этот процесс заложена немалая задержка в сети. Обратный просмотр WINS ——не высокопроизводительное действие, но довольно полезная функция, особенно, если другие способы неприменимы.
Общий синтаксис записи W1NS-R следующий.
<домен> IN WINS-R [LOCAL] <домен, который дописывается к возвращаемым именам NetBIOS〉
Между необязательным флагом LOCAL и доменом, который будет дописываться, можно указать значения [Ь<тайм-аут просмотра〉] и [С<тайм-аут кзша>] в секундах. В реальном домене запись WINS-R может выглядеть так.
@ IN WINS-R LOCAL L9O0 С2 example.net.
Настройка обратного просмотра WINS на консоли управления DNS очень похожа на настройку WINS для прямого просмотра с тем отличием, что сначала на левой панели консоли управления выбирается зона обратного просмотра in-addr. агра. После этого в диалоговом окне Свойства зоны надо перейти во вкладку WINS-R, как показано на рис. 16.9.
Рис. 16.9. Настройка просмотра WINS-R bDNS
Не забудьте установить флажок Не выполнять репликацию этой записи, если данный сервер DNS будет передавать эту зону на любые серверы DNS, не являющиеся разработками Microsoft. Кнопка Дополнительно, как и для прямого просмотра, позволяет установить тайм-ауты кэша и просмотра.
В поле Домен, добавляемый к возвращенному имени указывается используемый домен DNS. Помните, что имя NetBIOS не уточняется рархией DNS как имя, которое можно видеть в этом поле. W1NS-R фактически вообще не использует WINS. Вместо этого, когда приходит прос PTR. который DNS иным путем не может разрешить в своей зоне, сервер DNS посылает запрос о состоянии адаптера NetBIOS, используя IP. Если машина доступна и на ней работает NetBT, она отвечает, возвращая свое имя NetBIOS. После этого DNS приписывает к нему значение, указанное в этом поле, и возвращает результат как FQDN в ответ на запрос PTR. Безусловно, можно указывать разные имена домена для каждой зоны, поддерживающей WINS, но надо тщательно проанализировать, к чему это приведет.
Обратный просмотр адреса, позволяющий получить имя FQDN DNS узла по e「Q IP-aqpecy、 все чаще применяется для входа в систему, брандмауэров и других мер защиты. Наблюдается тенденция усложнения интеграции WINS и D&S, но ее использование рекомендуется для полноценного обслуживания клиентов низкого уровня, которые не могут функционировать без интеграции DNS/W1NS.
Резюме
В этой главе рассматривается назначение WINS, ее действие и способы ее совместного использования с DNS для полноценной сетевой поддержки клиентов низкого уровня. Анализируется множество взаимодействующих факторов и приводятся основные соображения по успешному развертыванию WINS и ее интеграции с DNS. Подробно излагаются этапы установки и настройки WINS, в том числе с целью ее интеграции с DNS. с акцентом на ключевых параметрах настройки.
17
NetBIOS: традиционные службы имен и разрешение
В этой главе...
Рассматривается сетевая баювая система ввода-вывода (Network Basic Input/Output System, NetBIOS), которая широко используется в службе WJNS и при просмотре. В этой главе показано, что эта система выполняет, и даны рекомендации по работе с NetBIOS на практическом уровне. Хотя Windows 2000 многого достигла в плане отмежевания от NetBIOS, еще некоторое время большие системы Windows не будут работать без NetBIOS. По этим причинам, а также потому, что разрешение традиционных имен вообще остается неясным вопросом, и включена эта глава.
История и характеристики NetBIOS. NetBIOS — это интерфейс к традиционным приложениям, разработанный с целью облегчить организацию малых одноранговых сетей. NetBIOS работает на основе нескольких транспортных протоколов. В этом разделе дается краткий обзор NetBIOS, так чтобы можно было точно понять, что это такое и чем отличается, например, от NetBEUI. Одна из задач Windows 2000 состоит в постепенном отходе от NetBIOS. Если в вашей системе есть клиенты низкого уровня, вероятно, придется продолжить поддержку NetBIOS и сохранить возможность использования WINS.
Регистрация имен NetBIOS. Имена NetBIOS должны быть объявлены, как объясняется в этом разделе.
Имена NetBIOS м коды ресурсов. Имена NetBIOS содержат скрытый символ, который идентифицирует специальные ресурсы, например службы сообщений и контроллеры домена. В этом разделе приводится их краткий обзор.
Разрешение имен NetBIOS. В NetBIOS предусмотрено много способов разрешения имен. В этом разделе описана работа распознавателя Windows.
Типы узлов NetBIOS. Клиенты NetBIOS различаются по типам узлов в зависимости от их поведения при регистрации и разрешении. В этом разделе определены типы и их особенности.
Просмотр: служба обнаружения NetBIOS. Служба обозревателей — высокоавтоматизированная функция, которую можно обнаружить, например, в меню значка Мое сетевое окружение
С вами говорит NetBIOS. NetBIOS используется для именования и передачи услуг через сеть, но не как сетевой транспортный протокол. NetBIOS доступна в Windows 2000 как в старой форме, так и в виде новых способов поддержки SMB через прямой хостинг, как показано в этом разделе.
История и характеристики NetBIOS
В мире UNIX нет ничего подобного NetBIOS. Администраторы Windows долгое время боролись с поддержкой пространства имен NetBIOS из-за се архитектурных ограничений. Хотя введение WINS и последующее закрепление этой службы в сервисных пакетах NT 4 помогло сделать плоское пространство имен NetBIOS действительно полезным, в Windows 2000 Microsoft решительно намерена отказаться от этой ненадежной модели организации сети.
Несколько обстоятельств делают изучение NetBIOS необходимым для системных администраторов. NetBIOS не сразу выйдет из употребления, а будет использоваться, пока надо будет поддерживать традиционные приложения н операционные системы. Чтобы все службы NetBIOS и зависящие от них приложения работали правильно, для NetBIOS нужен сервер имен, отличный от DNS (например, сервер WINS), Со временем у распознавателя NetBIOS появилось столько альтернативных способов разрешения, что понимание его работы может быть весьма важно для функционирования клиента. При неправильной настройке клиенты NetBIOS могут вызвать значительную ненужную загрузку сети.
Параметры настройки сети Windows 2000 позволяют отключить выполнение NetBIOS через протокол TCP/IP (NetBT). Эта возможность предоставляется для тех случаев, когда обратная совместимость в системе не нужна (например, если сеть состоит только из Windows 2000). Однако
некоторые особенности первой версии Windows 2000, возможно, еше требуют применения имен NetBIOS. Работа по достижению полной независимости Windows 2000 от NetBIOS продолжится еше какое-то время, и поэтому рекомендуется тщательная проверка системы, если в ней планируется отключить NetBIOS. Наконец, следует признать, что удаление NetBIOS через TCP/IP необязательно будет означать полный отказ от имен NetBIOS.
Краткая история NetBIOS
NetBIOS не является службой имен, хотя и располагает некоторыми ее возможностями, как и формальная служба имен WINS. NetBIOS начала свое существование как сетевой интерфейс прикладного программирования (application programming service, API) для компьютеров MS DOS в небольших, одиосегментных сетях, но была вынуждена работать в больших сетях, когда стали популярны Microsoft Windows 3.x и Windows для рабочих групп. NetBIOS также не сетевой протокол в том смысле, в каком IP — тринсиортный протокол, а предназначена, скорее, для использования с множеством других протоколов. Эта ситуация отражена на рис. 17.1, пе видно, что NetBIOS выполняет свою работу на верхних уровнях системы протоколов.
Обычная реализацияNetBIOSОбычная реализацияNetBIOS7Поиложение5Приложение6Представление5Сеанс4Транспорт4Транспорт3Сеть32Канал передачи данных2Канал передачи данных1Физический1Физический7Поиложение5Приложение6Представление5Сеанс4Транспорт4Транспорт3Сеть32Канал передачи данных2Канал передачи данных1Физический1ФизическийУровни 0SIУровни TCP/IPУровни 0SIУровни TCP/IPРис. 17.1. Сетевые уровни и NetBIOSРис. 17.1. Сетевые уровни и NetBIOSПриложение NetBIOSЭмулятор NetBIOSИнтерфейс транспортного драйвераилиилиИнтерфейс сетевого драйвераФизическийПриложение NetBIOSЭмулятор NetBIOSИнтерфейс транспортного драйвераилиилиИнтерфейс сетевого драйвераФизический
Обычная реализация
NetBIOS
Обычная реализация
NetBIOS
7
Поиложение
5
Приложение
6
Представление
5
Сеанс
4
Транспорт
4
Транспорт
3
Сеть
3
2
Канал передачи данных
2
Канал передачи данных
1
Физический
1
Физический
7
Поиложение
5
Приложение
6
Представление
5
Сеанс
4
Транспорт
4
Транспорт
3
Сеть
3
2
Канал передачи данных
2
Канал передачи данных
1
Физический
1
Физический
Уровни 0SIУровни TCP/IP
Уровни 0SIУровни TCP/IP
Рис. 17.1. Сетевые уровни и NetBIOS
Рис. 17.1. Сетевые уровни и NetBIOS
Приложение NetBIOS
Эмулятор NetBIOS
Интерфейс транспортного драйвера
или
или
Интерфейс сетевого драйвера
Физический
Приложение NetBIOS
Эмулятор NetBIOS
Интерфейс транспортного драйвера
или
или
Интерфейс сетевого драйвера
Физический
NetBIOS была разработана для среды персональных компьютеров, чтобы дать возможность профаммистам разрабатывать на ннх программы 1Ст1Иент/сервер, и впервые была реализована IBM в протоколе расширенного пользовательского интерфейса NetBIOS (NetBIOS Extended User
Interface, NetBEUI) в 1985 г. IBM заложила поддержку NetBIOS в сетевой протокол NetBEUI, чтобы предоставить приложениям MS DOS для PC удобные в работе сетевые услуги в локальных сетях (LAN),
NetBEUI удобен лишь для нескольких сотен компьютеров и не можег быть распространен на глобальные септ (WAN), потому что его нельзя маршрутизировать. Негативный пример этого устаревшего принципа иногда можно видеть, когда один список обозревателя отличается ог другого, так как пользователи находятся по разные стороны мар山рутнза- тора. Эту невозможность маршрутизации пытались преодолеть в NetBT сначала с помощью файлов LMHOSTS, а затем через WINS.
ЗСот и Microsoft совместно разработали LAN Manager, который должен был работать как процесс на OS/2. Версия IBM, называвшаяся LAN Server, несколько отличалась, но обе эти программы использован NetBEUI. В 1993 г, Microsoft отделила NetBIOS от NetBEUI и связала с TCP/IP, а в 1995 г. — с протоколом Novell IPX/SPX. Это сделало служб* NetBIOS более полезными в глобальных сетях, но не устранило всех ограничений их архитектуры. NetBIOS еше может использовать широковещание в большей степени, чем другие протоколы служб TCP/IP, и применяет совершенно иное соглашение об именах компьютеров и служб. (См. об этом ниже в этой главе, в разделе "Имена NetBIOS и коды ресурсов''.)
Службы NetBIOS
Функции, предоставляемые NetBIOS, определены в RFC 1001 и 1002 Некоторые широко используемые и очень удобные службы зависят о】 NetBIOS, например версии службы обозревателей, предшествовавшие Windows 2000 (которая предоставляет список компьютеров в окне Мое сетевое окружение), служб сервера и рабочей станции (которая, напрк- мср, применяет блок серверных сообщении (Server Messenger Block, SMB) для совместно использования файлов в так называемых сетях Microsoft), и слузкбы сообщений (которая позволяет посылать пользователям сообщения, сонержашке только их регистрационные имена (для справки)).
Некоторые другие службы также зависят oi NetBIOS, но о них мы расскажем после того, как опишем NetBIOS бопее подробно. NetBIOS лучше всего определить как набор служб межпроцессного взаимодействия (interprocess communicating, I PC), относящихся к трем категориям.
Службы имен получают, выдают и разрешают имена ресурсов. Имена NetBIOS должны быть уникальны. Они используются для индивидуальных пользователей, компьютеров, служб it других ресурсов. Имена в плоском пространстве имен локализуются путем широковещания или, в случае WINS, путем прямой связи с постоямным авторитетным сервером имен, способным к адресации компьютеров в любой доступной сети IP.
Службы сеансов включают передачу команд, которая обеспечивает двум приложениям, использующим NetBIOS, полнодуплексное, упорядоченное и надежное соединение. Поддерживается несколько одновременных соединений, а имена идентифицируют обоих участников.
Службы дейтаграмм передают и получают сообщения от участников путем широковещания на имена групп или направленной передачи на уникальные, индивидуальные имена. В отличие от служб сеансов, службы дейтаграмм не упорядочены, ненадежны н не устанавливают соединения.
Служба NetBIOS, которая поддерживает регистрацию и разрешение имен, имеет близкое отношение к DNS, основной теме этой книги. NetBIOS часто можно вызывать для широковещания, даже по протоколу TCP/IP. Применение широковоиания службы имен по своей архитектуре ограничено одним сегментом сети. Поскольку широковещание не всегда приемлемо, а в мартрутнзнруемнх сетях неэффективно, был разработан NetBT. После появления NetBT, а затем WINS, были определе- ! ны различные типы узлов NetBIOS (в основном для второго из этих протоколов), позволяющие задать исходное поведение службы имен I NetBIOS. Но вплоть до обновления в NT 4 Service Pack 3—5 службь】 имен ； NetBIOS, использующие WINS, были довольно ненадежны. К счастью, j службы сеансов NetBIOS обычно работают прекрасно, если решены про- i блемы службы имен.
1 На рис. 17.2 показаны параметры раздела реестра Windows 2000 ；HKLM\SYSTEM'Cu г eutCont г oiset\ Services\NetBT, соответствующие I NetBIOS и Net ВТ.
|3нсрмгураина IP
WSMlSIERSON.teiib»：
далаэ.пга
J
MrGHrtms：Маоюлими«№РкшхЧваж aHtlBiaS е покошл ONSСлеаежюмнюелгнре ^_
W1NSE
Адрес впггролчг^а'
Мюапщапи.
? / К
□
2®M、M*
：Лостут получен- Дсетб ыяекмг
Г »м) сервер WINS _ eTc«a«««dc4^M9^ws
Рис. 17.2. Параметры NetBIOS и NetBT в реестре
Как неоднократно указывалось в этой книге, в свойствах TCP/IP Windows 2000 есть элемент управления, позволяющий отключить NetBT. Его нельзя смешивать с отключением NetBIOS. Строго говоря, NetBT 一 вспомогательное средство для TCP/IP и единственный способ, паютнм доступ к NetBIOS. Иными словами, их легко cnyiaib. Обычно мы испол[>- зуем NetBT, так что в подакпяюшем большинстве случаев NetBIOS работает только через TCP/IP и поэтому воспринимается через призму NetBT. В этой главе предпринята попь[тка расставить NetBIOS и NetBT по местам, даже когда речь идет об использовании NetBIOS через протокол TCP/IP.
Регистрация имен NetBIOS
Как легко можно понять, службы сеансов м дейтаграмм NetBIOS бесполезны без службы имен. Машины должны обнаружить друг друга, чтобы соединиться. Для службы имен клиент должен объявить себя, чтобы его можно было локализовать.
Это автономное происхождение имен имеет и сильные, и слабые стороны. Его преимущество в том, что оно было динамическим и самона- страиваемым, чего не могла добиться DNS, пока не появилось динамическое обновление. О недостатках свидетельствует длинная история поиск；〕 удовлетворительной реализации.
Первоначально клиент NetBIOS периодически распространял по сети широковещательные сообщения, чтобы дать другим знать о своем присутствии. Другие клиенты NetBIOS, принимая эти сообщения, могли формировать в своем кэше имен NetBIOS спнскн всех участников сети или, точнее, своего сегмента сети.
Два подхода, которые использовались для преодоления ограниченна этой архитеК1уры широковешания до появления WINS, все еше применяются. Одиfi из них. служба обозревателей, представлял собой что-то вроде выделения машин для служебного пользования. При зтом подхоле большинство компьютеров освобождалось от обязанностей составления списка имен, которые переносились на несколько специально назначенных машин. Этот способ описан ниже, в разделе "Просмотр: служба обнаружения NetBIOS'1. Другой подход состоял в использовании файла LMHOSTS. С появлением Net ВТ и способности проходить через маршрутизаторы файл LMHOSTS стал служить для создания простой таблицы отображений имен на IP-адреса. (Подробнее об этом см, в приложении А. ''Файлы LMHOSTS и HOSTS”.)
Наконец WINS позволила предоставлять услуги имен NetBIOS в больших системах TCP/IP. Компьютер, который является клиентом WINS, сам регистрируется непосредственно в WINS и периодически возобновляет регистр^анию. (Подробнее см. главу i6, "WINS: традиционные службы имен II разрешение''.) Вез WINS клиент способен только к широковещательным объявлениям. В любом случае клиент NetBIOS должен или, если хотите, вынужден объявлять о своем присутствии.
Имена NetBIOS и коды ресурсов
Имена NetBIOS и имена DNS подчиняются разным правилам. С появлением Windows 2000 стало еще более важным, чтобы машины всегда, когда это только возможно, носили одно и то же имя в обоих пространствах имен. Это ограничивает как DNS, где одно и то же имя по этой причине уже не может использоваться в разных доменах, так и NetBIOS, где в именах приходится применять более ограниченный набор символов DNS. Хотя Windows 2000 устраняет противоречия между DNS и именами нижнего уровня, немедленные преимущества, особенно при переносе на другую систему, не стоят долгосрочной путаницы в именах. Иными ело- вами, если ситуация создана существовавшей ранее системой имен, можно, конечно, применить одну систему в ущерб другой, но потом все равно придется исправлять положение.
Плоское пространство имен и области NetBIOS
Пространство имен NetBIOS не является иерархическим; оно плоское, одноуровневое, что создает некоторые проблемы для администраторов. Ограниченное количество возможных имен — одна из таких проблем, потому что в плоском пространстве имен два компьютера не могут иметь одно и то же имя. Можно представить себе, что случилось бы, если бы во всем мире только одна компания могла назвать свой сервер в Internet именем WWW! В больших корпоративных системах это преобразуется в потребность использовать стандарты именования, чтобы избежать конфликтов. Это особенно верно теперь, когда Windows 2000 налагает ограничение уникальности на имена нижнего уровня в локальном лесу Windows 2000.
NetBIOS дает одну возможность преодолеть ограничения своего плоского пространства имен. Она заключается во введении кодов областей NetBIOS. NetBIOS может использовать коды областей, но по большей части они не настраиваются и оставляются по умолчанию. Если в двух машинах настроен один и тот же код области, они могут взаимодействовать в NetBIOS. Если машины имеют разные коды областей, они не будут признавать друг друга или взаи модействовать. Код области неявно добавляется при регистрациях, обновлениях, запросах и освобождениях имен NetBIOS. Это средство не стоит переоценивать. Коды областей NetBIOS позволяют создавать в сети несколько пространств имен NetBIOS, возможно, сокращая их размер, но ничего не делают для введения иерархии этих плоских пространств имен. На практике коды областей NetBIOS не пользуются популярностью.
Характеристики имен NetBIOS
Имена NetBIOS всегда являются 16-байтовыми строками. Если н\口 содержит менее 15 символов, оно автоматически дополняется пробелам и до 15 байт. Еше один байт зарезервирован для суффикса, который, по сути дела, является кодом ресурса или службы. Суффикс автоматически добавляется после 15-го байта. Суффикс обычно скрыт, если только не просматривается база данных WINS, трассировка или вывод такой команды, как nbcstac.
При отображении имена NetBIOS укорачиваются до последнего печатаемого символа, поэтому можно видеть имена и короче 15 символов.
Имена NetBIOS могут состоять из алфавитно-цифровых символов, включая пробелы и такие специальные символы, как ! @ # $ W 八 & )-'{}_. ~. Интерфейсы управления NT 4 все более и более о,- раничива.г[и возможности выбора имени машины, но в действительности в имен” NetBIOS допустим любой символ, кроме некоторых зарезервированных для специального использования, а именно ? * ： ; I / \ < > [1 , ' + -, В интерфейсе управления Windows 2000 в именах NetBIOS не допускается и точка (.).
Имена NetBIOS не могут начинаться со звездочки (*), которая зарезервирована для широковещательной адресации. Даже при том, что точка (.)допустима в именах NetBIOS и разрешается в NT 4, она не может присутствовать в именах узлов для пространства доменных имен DNS, поскольку разделяет элементы полностью уточненного доменного имени (FQDN). Подробная информация о правилах именования, особенно с учетом совместимости с DNS, приводится в разделе '■Характеристики имен узлов" главы 1, "Введение в систему доменных имен".
Только то, что можно что-нибудь сделать, не является серьезным основанием, чтобы поступать так. Это особенно верно, если требуется, чтобы имя NetBIOS было совместимом с DNS. Используйте только специальный символ дефиса, или знак "минус" ([ms]); любой другой похожн" символ будет отклонен в стандартных конфигурациях большинства современных серверов DNS. Некоторые приложения печати имеют про- блемм с символом дефиса (-); поэтому для максимальной совместимости используйте исключительно алфавитно-цифровые символы, причем первый символ должен быть буквой. С другой стороны, если ваша цель — защитить внутреннее пространство имен, заслуживает внимания допустимость в Microsoft DNS расширенного набора символов.
Коды ресурсов в именах NetBIOS
Коды ресурсов дают NetBIOS возможность регистрировать не просто имена, но и компьютеры, стандартные службь( и другие ресурсы. Поскольку NetBIOS уже знает, где находятся службы, т.е. какой 1Р-адрес нужен, чтобы связаться с ними, клиенты могут запрашивать эти службы
по именам, не зная, где они находятся. После введения в DNS записей SRV эту ранее уникальную возможность пространства имен NetBIOS частично можно обеспечивать и через DNS, что фактически уже сейчас широко практикуется в доменном окружении Windows 2000 ”，вероятно, со временем будет использоваться все больше н больше для объявления служб в системе DNS.
В табл. 17.1 перечислены наиболее часто встречающиеся коды ресурсов служб NetBIOS. Большая часть этих кодов применяется только для идентификации компьютеров и ресурсов. Некоторые коды появляются в базе данных WINS редко, например только для специальных приложений, м не приводятся в этой таблице.
Таблица 17.1, Коды ресурсов служб NetBIOS (16-й байт)
Код ресурса
Тип имени
Что регистрируется; служба, производящая регистрацию
<00>
Имя компьютера или домена
Имя компьютера NetBIOS или членство в домене：
служба рабочей станции
<01>
Буквально “—MSBROWSE _"
IP или локальный главный обозреватель для объявления другим обозревателям;
служба обозревателей
<03>
Имя пользователя или компьютера
Адресат сообщения, имя пользователя NetBIOS или имя компьютера NetBIOS, служба сообщений
<06>
Имя компьютера
Имя компьютера NetBIOS, на котором работает служба удаленного доступа：
служба удаленного доступа
<1В>
Имя домена
Главный обозреватель домена;
специальная служба главного обозревателя домена на основном контроллере до-
<1С>
Имя домена
Имя группы домена;
основной или резервный контроллер домена (на каждый домен можно зарегистри
ровать до 25 контроллеров)
<1D>
Имя домена
Локальный главный обозреватель, публикующий список просмотра для резервных локальных обозревателей.
служба обозревателей
Окончание табл. 17.1
Код ресурса
Тип имени
Что регистрируется; служба, производящая регистрацию
<1Е>
Имя домена
Обычное имя группы для выбора локальных главных обозревателей： служба обозревателей
<1F>
Имя домена
Имя компьютера NetBIOS, способного к сетевому DDE;
служба сетевого DDE
<20>
Имя компьютера или группы
Компьютер NetBIOS или специальное административное имя группы：
служба сервера
<21>
Имя компьютера
Имя компьютера NetBIOS;
клиент службы удаленного доступа (RAS)
<ВЕ>
Имя компьютера
Имя компьютера NetBIOS;
агент сетевого мониторинга
<BF>
Имя компьютера
Имя компьютера NetBIOS, служебная программа сетевого мониторинга
Ниже приведены некоторые примеры имен NetBIOS, обычно используемых компонентами Microsoft.
им月一компьютера [QOh] регистрируется службой рабочей станции на клиенте WINS.
имя_компьютера [03h] регистрируется службой сообщений на клиенте WINS.
имя_компьютера [06h] регистрируется службой удаленного доступа (Remote Access Service, RAS) на сервере RAS.
имя_компьютера [ iFh] регистрируется службой сетевого динамического обмена данными (Network Dynamic Data Exchange, NetDDE). По умолчанию службы сетевого DDE не запускаются автоматически.
имя_компьютера [20h] регистрируется службой сервера на клиенте WINS.
имя_компьютера [21h] регистрируется службой клиента удаленного доступа, когда она запускается на клиенте RAS.
имя_компьютера [BEh] регистрируется службой агента сетевого мониторинга и появляется, только если эта служба работает на компьютере. Если имя компьютера короче 15 символов, оно дополняется знаками 14плюс" (+).
имя_компьютера [BFEh] регистрируется служебной программой сетевого мониторинга (которая входит в состав сервера управления системой Microsoft). Если имя компьютера короче 15 символов, оно дополняется знаками плюс (+).
имя_пользователя [03h] Имена пользователей, входящих в систему, регислрируются в базе данных WINS. Имя пользователя регистрируется компонентом сервера, так что он может принимать все команды net send, посланные на это имя. Если в систему под одним и тем же именем вошло несколько пользователей, имя регистрирует только первый компьютер, на котором пол этим именем зарегистрировался пользователь.
имя_домена [1ВИ] регистрируется основным контроллером домена (primary domain controller, PDC) Windows NT Server, действующим как главный обозреватель домена, и разрешает удаленный просмотр доменов. Когда на сервер WINS поступает запрос на это имя, он возвращает IP-адрес компьютера, зарегистрировавшего это имя.
имя_домена [ IDhJ регистрируется только локальным главным обозревателем, который должен быть единственным в подсети. Это имя используется резервными обозревателями, когда они соединяются с главным обозревателем и получают от него список доступных серверов.
Сервер WINS всегда возвращает положительный ответ на регистрацию имя_домена [IDh], хотя и не регистрирует это имя в своей базе данных. Поэтому, когда сервер WINS получает запрос на имя__домена [lDhJ, он возвращает отрицательный ответ, что заставляет клиента разрешать имя путем широковещания.
имя_домена [OGhJ регистрируется службой рабочей станции, так что домен может получать оповещения обзора сети от компьютеров под управлением LAN Manager.
имя_домена [ICh] регистрируется для использования контроллерами домена в пределах домена; может содержать до 25 IP-адресов. Один IP-адрес присваивается основному контроллеру домена, а остальные 24 ——адресами резервных контроллеров домена.
имя_домена [ lEh] регистрируется для целей просмотра и используется обозревателями для выбора главного обозревателя. Всегда, когда сервер WINS получает запрос на имя, оканчивающееся на [1Е]. он возвращает широковещательный сетевой адрес для локальной сети запрашивающего клиента.
_MSBROWSE_[Glhj регистрируется главным обозревателем каждой подсети. Всегда, когда сервер WINS получает запрос на такое имя, он возвращает широковешательный сетевой адрес для локальной сети запрашивающего клиента.
Разрешение имен NetBIOS
Службы имен NetBIOS позволяют регистрировать имена через широковещание в малых сетях и через направленную связь при доступности сервера WINS. После регистрации эти имена можно использовать в ответах на запросы в процессе разрешения. С помошью NetBT разрешение возвращает IP-адрес, соответствующий зарегистрированному имени NetBIOS не требует сервера имен, как DNS или WINS. Серверы имен полезны, а при некоторых обстоятел ьствах и необходимы, но они представляют лии^ь один из нескольких механизмов разрешения имен, которые может использовать NetBIOS.
Методы разрешения имен
Компьютеры Windows могут разрешать сетевые имена, пользуясь шестью возможными источниками, не считая методов LDAP, В главе 14, "Настройка и разрешение клиентов Windows'', описаны некоторые другие особенности порядка использования клиентами различных механмз- мов запроса в зависимости от их версии Windows, их настройки и доступности методов- На рис. 17.3 показано, что происходит при применении трех из числа наиболее часто встречающихся методов. Обратите внимание, что широковещательное разрешение, как правило, не возвращает адреса узлов за пределами локальной сети. Это ограничение обычно преодолевается за счет установки сервера WINS.
В оставшейся части этой главы предполагается, что NetBIOS использует транспортный протокол TCP/IP. По различным причинам это] транспортный протокол применяется все более интенсивно. Ниже кратко описаны различные источники разрешения имен, которыми могут пользоваться компьютеры Windows. Первыми представлены четыре источника разрешения имен NetBIOS, как правило, применяемых в NT 4. Но прп устранении различий между именами DNS и NetBIOS можно использован. все источники. Два последних — DNS и фай-'i HOSTS — также служат для разрешения NetBIOS в некоторых версиях Windows, когда в клиенте установлен режим Включить DNS для разрешения Windows (или подобный переключатель, который можно найти во вкладке WINS диалогового окна Свойства TCP/IP). (Стиенты Windows 2000 несколько отличаются тем, что они всегда используют механизмы разрешения как DNS, так и NetBIOS, если оба эти способа доступны. Способность клиентов Windows 2000 успешно разрешать имена NetBIOS через интегра- иию DNS/WINS может дать преимущество в производительности.
Kaiu имен NetBIOS. Локально сохраняемый кэш имен, накашш- ваемый в памяти каждого клиента путем предварительной загрузки (см. 1MHOSTS в этом списке) или по результатам успешного разрешения адресов. Последующие запросы разрешаются через кэш быстро. но срок кэширования каждой записи — только 10 минут, после чего она должна быть обновлена.
NetBIOS без WINS
ЛокальноЛокальноМаршрутизация дли локальныхМаршрутизация дли локальныхраспространяемыйраспространяемыйадресов не нужнаадресов не нужнаКлиент запрашиваетимя NetBIOS черезшироковещание
Локально
Локально
Маршрутизация дли локальных
Маршрутизация дли локальных
распространяемый
распространяемый
адресов не нужна
адресов не нужна
NetBIOS без WINS
Сервер имен DNSСервер имен DNSРис. 17.3. Методы и результаты запросов имен NetBIOS и DNSРис. 17.3. Методы и результаты запросов имен NetBIOS и DNSКлиент запрашивает ммя NetBIOS у WINSКлиент запрашивает ммя NetBIOS у WINSТолько DNSТолько DNSКлиент запрашивает доменное имя Internet у DNSКлиент запрашивает доменное имя Internet у DNSШироковещательные запросы. Используйте службу распределения дейтаграмм NetBIOS (NetBIOS Datagram Distribution Service, NDDS) на портах UDP 137 и 138. если имена нельзя найти в кз山е н сервер WINS не настроен для работы в качестве службы имен NetBIOS (NBNS). Широковещательные запросы предлагают компьютерам в локально兑 сети найти имя в своих таблицах имен Искомый узел, если он находится в этой сети, отвечает на запрос. Маршруги заторы обычно блокируют широковещание NDDS、что ограничивает применение этого метода одним сегментом сети. Если сегмент крупный, Широковещательный метод может чрезмерно загрузить сетевой трафик; в этом случае надо отказаться от широковещания или разбить сеть на меньшие сегменты.
Сервер имен DNS
Сервер имен DNS
Рис. 17.3. Методы и результаты запросов имен NetBIOS и DNS
Рис. 17.3. Методы и результаты запросов имен NetBIOS и DNS
Клиент запрашивает ммя NetBIOS у WINS
Клиент запрашивает ммя NetBIOS у WINS
Только DNS
Только DNS
Клиент запрашивает доменное имя Internet у DNS
Клиент запрашивает доменное имя Internet у DNS
WINS: сервер имен NetBIOS Microsoft. Клиенты регистрируют м освобождают свои имена по адресу сервера WINS, для работы с которым они были настроены. Для разрешения они запрашивают этот же адрес. Связь клиента с WINS осуществляется посредством
направленных сообщений через порты UDP 137 и 138, что позволяет проходить через маршрутизаторы. Если WINS не удается разрешить имя, некоторые клиенты могут вернуться к широковещательным запросам.
LMHOSTS. Локально сохраняемый файл узлов стиля LAN Manager (текстовый), в котором клиент может искать ответ, если широковещательный запрос не удается. Имена из lmhosts можно предварительно загрузить в локальный кэш имен NetBIOS с помощью ме】кн 书PRE, чтобы часто запрашиваемые узлы не запрашивались широковещательно. Метка #pre полезна также для узлов за пределами локальной сети, так как предотвращает появление гарантированно неудачных широковещательных запросов. До появления Windows 2000, если контроллер домена находился не в сети клиента, требовалась предварительная загрузка адреса контроллера домена с помощью меток #PRE и #DOM (если для входа в домен Windows не использовхпась WINS). Файл lmhosts рассматривается в приложении А.
DNS. Клиенты будут запрашивать имя NetBIOS у сервера DNS. В NT 4 для этого надо было установить флажок Включить DNS для разрешения Windows в диалоговом окне Свойства TCP/IP клиента. В Windows 2000 эта возможность предоставляется по умолчанию. Порядок использования методоа разрешения в NT и 2000 также отличается от стандартного поведения клиента для других платформ Windows. NT (если DNS включена) сначала проверяет DNS. Windows 2000 (конечно, если DNS настроена) проверяет DNS одновременно с разрешением NetBIOS. На других платформах серверы DNS всегда опрашиваются в последнюю очередь, т е. меньше всего полагаются на DNS при разрешении имен NetBIOS. Чтобы DNS приносила большую пользу, надо применить интеграиию DNS/WINS {как показано в главе 16), хотя и при этом необходимо осторожное использование одинаковых имен узлов NetBIOS и DNS и планирование доменов и списка поиска распознавателя.
HOSTS. Локально сохраняемый файл узлов стиля UNIX (текстовый), в котором клиент также может искать ответ, если другие методы не принесли желаемого результата. Он доступен везде, где настроена DNS, которая для некоторых клиентов (см. предыдущий пункт) применяется, только если все другие методы запросов потерпят неудачу. Файл HOSTS рассматривается в приложении А.
Главный недостаток файлов как LMHOSTS, так и HOSTS состоит в трудоемкости обслуживания файла на множестве оиентских машин. Впрочем, файл lmhosts можно обслуживать на сервере и вставлять в файлы LMHOSTS клиентов. В любом случае надо стремиться к тому, чтобы в этот файл включались только редко изменяющиеся узлы.
О поведении распознавателя, например, когда используется каждый из этих методов, можно сказать гораздо больше. Но вначале имеет смысл прочесть следующий раздел о типах узлов NetBIOS.
Типы узлов NetBIOS
Каждый компьютер NetBIOS имеет определенный тип узла. Тип узла NetBIOS не имеет никакого отношения к доменам DNS и разрешению имен узлов в IP-адреса; это параметр настройки только для компьютеров NetBIOS.
Четыре возможных типа узлов определяют, какой метод будет использован для регистраиии и разрешения имен компьютеров NetBIOS.
Клиенты b-узла используют только широковещание.
Клиенты p-узла используют только направленное соединение с сервером имен.
Клиенты m-узла, иногда называемого смешанным узлом, сначала используют широковещание, а затем — направленное соединение.
Клиенты h-узла, иногда называемого гибридным узлом, сначала используют направленное соединение, а затем — широковещание.
В некоторых документах Microsoft упоминается пятый тип ——клиент h-узна, который при разрешении имени NetBIOS сначала использует DNS (в режиме Включить DNS для разрешения Windows).
Машина, настроенная как клиент WINS, является h-узлом; машина с пустым адресом WINS считается по умолчанию b-узлом. Установить тип узла удобно с помощью DHCP. Типы m-узла и p-узла встречаются редко, практически только при ручной их настройке через реестр или сервер DHCP. В следующем разделе кратко рассматриваются р- и m-узлы перед переходом к подробному описанию более обычных h- и b-узлов. При разрешении узлы всех типов, прежде чем перейти к любому из описанных методов, сначала проверяют свой кэш имен NetBIOS,
Редкие типы узлов: p-узел и т-узел
p-узлы никогда не передают широковещательных сообщений, если им надо зарегистрировать себя или найти адреса. Они соединяются с сервером имен NetBIOS (WINS) только направленно, используя дейтаграммы протокола UDP или сеансы TCP.
p-узлами практично сделать, например, клиентов на удаленной стороне канала глобальной сети из главного офиса, когда широковещательные сообщения, конечно, не достигали бы пели из-за маршрутизаторов.
m-узлы передают широковешательные запросы и затем, если это не удается, соединяются непосредственно с сервером WINS. Эта конфигурация применяется в самом последнем случае, так как она очень непрактична. m-узлы могли бы быть полезны там, где на отдаленном сайте глобальной сети нет сервера WINS, а клиенту нужны в основном серверы, расположенные в той же подсети. Если попытка локального разрешения через широковещание не удается, клиент соединяется с сервером WINS в главном офисе через маршрутизатор. Задержка может составлять несколько секунд, но при медленном канале глобальной сети пользователю все равно придется ожидать.
Разрешение b-узла
b-узлы разрешают имена только через широковещание, что обычно означает, что их область действия ограничена одной подсетью. Поскольку маршрутизаторы, как правило, блокируют широковешательные сообщения, они препятствуют b-узлам разрешать компьютеры по ту сторону. b-узлы никогда не использктог сервер имен. На рис. 17.4 показаны методы разрешения, доступные для Ь-узлов.
Рис. 17.4. Действия Ь*узла NetBIOS при разрешении
Недостаток b-узлов в том, что они вносят в сеть ненужный трафик, чего можно избежать только установив сервер WINS. Если вы не хотите использовать WINS и планируете применять главным образом широковещание, можно получить некоторый выигрыш в прямой адресации, минуя маршрутизаторы, за счет предварительной за】рузкм адресов в ло- кгыьный кэш имен NetBIOS. Для этого нужны только файл lmhosts и директива ^где. При этой методике уменьшается также объем широковещания, потому что каждый предварительно загруженный адрес, который иначе требовал бы широковещания, теперь можно найти в кэше.
Разрешение h-узла
h-узлы, или гибридные узлы, разрешают имена, запрашивая сервер WINS. Если это не удается, они делают широковещательный запрос, h- узлы преодолевают ограничения b-узлов, потому что запросы к серверу имен проходят через маршрутизаторы. Ввиду того что распознаватель h-
узла уже знает адрес одного или нескольких серверов WINS, разрешить адрес искомого компьютера легко. После этого клиент соединяется с ним снова через маршрутизатор. В этом h-узлам действительно нет равных. Работу h-узла иллюстрирует рис. 17.5. Эти узлы могут определить местонахождение любого компьютера, зарегистрированного на том же сервере WINS, в отличие от b-узлов, которые, как правило, не могут определить никаких адресов за пределами их собственной подсети без помощи файлов LMHOSTS.
Рис. 17.5, Действия h-узла NetBIOS при разрешении
Работа с гибридными узлами не должна показаться особенно трудной — для них надо всего лишь установить сервер WINS! Ниже показана последовательность действий типичного h-узла от запуска до отключения.
Регистрация. При запуске h-узен регистрирует свои имя и адрес на сервере WINS, используя направленную связь с сервером по адресу, указанному в свойствах TCP/IP или полученному от DHCP
Обновление регистрации, h-узел должен периодически обновлять регистрацию своего имени на сервере WINS с частотой, зависящей от времени, заданного сервером WINS при регистрации.
Разрешение. До отключения h-узел может разрешать имена с какой угодно частотой, непосредственно запрашивая сервер WINS. Возвращаемые сервером WINS адреса h-узел использует для прямого соединения с другими компьютерами.
Освобождение. При отключении h-узел освобождает свою регистрацию на сервере WINS, показывая, что его имя уже недоступно.
h-узлы всегда обращаются к серверу WINS после проверки местного кэша имени NetBIOS. Они начинают действовать как b-узлы, только если нет другого выбора, т.е. если ни один указанный в настройке сервер WINS не отвечает или если по какой-то другой причине клиент не может зарегистрировать себя после запуска. Даже в таких случаях клиент продолжает попытки войти в контакт с сервером WINS, чтобы вернуться к методу прямой адресации.
Просмотр: служба обнаружения NetBIOS
Служба просмотра создает список имен компьютеров NetBIOS, упорядоченный по именам групп, который можно просмотреть в меню значка Мое сетевое окружение или с помощью команды net view. Служба просмотра контролирует объявления, выполняемые всеми компьютерами в сети, и составляет из них списки по рабочим группам или по доменам. Но сама эта служба не имеет никакой информации об адресах и полагается на доступные службы имен NetBIOS. Список просмотра Мое сетевое окружение продолжает работать в Windows 2000, если NetBT отключен, но не отображает машины низкого уровня. В этом разделе рассказывается о работе службы просмотра с NetBT.
Двойной щелчок на имени в списке просмотра означает требование напрямую соединиться с выбранным компьютером, используя адресную информацию в списке просмотра, и показать все его ресурсы. Если зта операция проходит успешно, вы быстро увидите, какие принтеры и файлы доступны. Если нет, значит, что-то необходимое для правильной ад- ресаиии данного компьютера, изменилось. Например, он мог отключиться после того, как список обновлялся последний раз, изменить свой IP- адрес и т.д. В этом случае NetBIOS пытается разрешить имя заново, причем может быть запрошен сервер WINS. Если это проходит успешно, доступные файлы и принтеры вновь отображаются в списке, но после некоторой задержки. Но если разрешить имя не удается, пользователь получает сообщение, что имя или сетевой путь не найдены.
Просмотр работает прекрасно, если только в сети нет маршрутизаторов, так как он обнаруживает имена компьютеров путем приема широковещательных объявлений. Как только в сеть включаются маршрутизаторы, просмотр становится ненадежным и, без сомнения, более сложным. Сервер обозревателя должен принимать все, что ему доступно. В маршрутизированной сети ему могут быть доступны лишь ресурсы сегмента, в котором он находится. Таким образом, создается несколько списков,
! каждый в отдельном сегменте, и, чтобы с ними было удобно работать, е1 эти списки надо объединить.
Г Для того чтобы создать надежный просмотр, надо, во-первых, понять, j как он работает, и во-вторых, спланировать необходимую для его работы [поддержку.
В каждой подсети для каждого протокола (например, NetBEUI, TCP/IP и IPX, если есть компьютер, который их использует) существует по крайней мере один локальный главный обозреватель (local master n browser, LMB). В документации Microsoft он называется главным обозре- j ватеяем и в некоторых аспектах отличается от главного обозревателя доме- I на (domain master browser, DMB). Далее, согласно документации ； Microsoft, LMB могут быть главными обозревателями, резервными обозревателями либо потенииальными обозревателями.
I Главный обозреватель домена отвечает за сбор списков от локальных 1 обозревателей, их объединение и распространение обратно на LMB. Этот I процесс показан на рис. 17.6. DM В также отвечает за обслуживание и про- [ верку списка Вся сеть, который распределяется на LMB. Для списка Сеть Microsoft Windows в NT 4 DMB периодически перебирает все зарегистрированные на сервере WINS доменные имена и проверяет их существование.
1 Различные роли LMB состоят в сборе локального списка, связи с DMB и управлении резервными обозревателями. Резервные обозреватели получают список от главного обозревателя и предоставляют его компьютерам в локальном сегменте по их требованию. Потенциальные обозреватели готовы выполнять одну из других ролей LMB, когаа необходимо.
Примечание
Здесь обозреватели называются либо локальными главными обозревателями, либо главными обозревателями домена, чтобы подчеркнуть их роль как важную для этой темы, LMB отвечают только за имена в одном сетевом сегменте, или подсети. DMB— всегда основной контроллер домена и отвечает за списки просмотра во всем домене.
LMB, с которым NetBIOS связывается и использует его для службы имен, — это обозреватель для протокола, первым указанного для сетевого адаптера. Рекомендуется использовать только один протокол или только абсолютно необходимые протоколы. Если требуется более одного протокола, удостоверьтесь, что все компьютеры имеют один и тот же порядок привязки, чтобы служба имен NetBIOS работала надежно и эффективно. Если применяется TCP/IP, LMB появятся и для каждого имени рабочей группы или домена в подсети. Основной приниип здесь таков: надо по возможности уменьшить количество имен рабочих групп и доменов, поскольку это влияет на нагрузку, вносимую службой просмотра в сеть.
Чтобы просмотр был надежным, необходимы члены доменного окружения в каждой подсети, где требуется надежный просмотр. В рабочей группе списком просмотра владеет наиболее авторитетная машина, которая загрузилась в то время, когда она была членом рабочей группы. Приоритет уменьшается в направлении от контроллеров домена, рядовых
серверов, версий Professional или Workstation к машинам Windows 9х, причем предпочтение отдается старшим версиям. Когда машина пытается войти в контакт с локальным обозревателем и это ей не удается, машина сама объявляет себя в сети локальным обозревателем, если это не запрещено в системном реестре. Когда машина с более высоким приоритетом принимает это объявление, она оспаривает его, в свою очередь, объявляя себя локальным обозревателем. Машина, объявление которой не оспорено никем, начинает играть роль LMB для этой подсети. Если LMB входит в состав доменного окружения, в его функции входит взаимодействие с главным обозревателем домена, что оказывается очень важным для стабилизации окружения просмотра.
Рис. 17.6.「лавннЕ обозреватель домена управляет списком просмотра
Основной контроллер домена — единственный сервер, который можег играть роль DMB. Главные обозреватели домена (DMB) незаменимы, так как они объединяют списки просмотра, полученные от локальных обозревателей (LMB) и затем передают их назад в отсортированном виде.
Как было сказано выше, DMB также поддерживают список всех доменов и рабочих групп. Кроме того, за пределами видимости остается довольно большой объем сетевого трафика, вызванного всем этим сбором списков, проверкой и распределением, которые регулярно повторяются четыре или пять раз в час. LMB также используют ротацию машин. В среднем около 3% компьютеров в сети работают как LMB, не считая потенциальных обозревателей. Для каждого протокола *в каждой подсети всегда имеется по крайней мере один LMB. Если же число клиентов, использующих данный протокол в сети, увеличивается, добавляется один LMB в резервной роли на каждые 32 клиента. В пределе как минимум одна из каждых 32 (или около 3%) машин постоянно поддерживает просмотр.
Рекомендуется использование сервера WINS, так как это позволяет DMB и LMBS в различных подсетях найти друг друга, запрашивая в WINS имена IBh, IDh или lEh. Вместо WINS можно применять специальные записи в файлах LMHOSTS, что и делалось для объединения службы просмотра до появления WINS. В непостоянных сетях, т е. таких, где применяется наборный доступ, а постоянных пользователей нет, можно установить в качестве главного обозревателя Windows NT Server и сделать имена всех рабочих групп или доменов пользователей наборного доступа такими же, как и для сервера.
В прошлом надо было принимать меры, чтобы главный обозреватель домена не потерял свой "пост". За этим целесообразно следить и сейчас, особенно в сильно взаимопроникающих системах. Раньше это было проблемой, но с появлением Service Pack для NT 4, кажется, в основном, если не полностью, решено. Прежде несколько доменов, объединенных в одну сеть, не всегда сохраняли неизменными и отдельными своих обозревателей. Существовало также частичное решение — не помешать основной контроллер домена в сегмент сети, в котором работает более новая версия Windows Server, чтобы она не стала LMB, возможно, лишив старый DMB его ^должности5'. Списки просмотра для разных доменов теперь более терпимы в совместном использовании сетевых сегментов без взаимного вмешательства. Однако рекомендуется следить за результатами выбора обозревателей и исследовать их, когда это кажется необходимым. Сетевой монитор, если проверять в нем трафик выбора обозревателей, иногда показывает повторные или излишне частые выборы.
Чтобы скрыть службу сервера Windows от списка просмотра, в разделе реестра HKEY_LOCAL_MACHINE\System\Cu.rrentControlSet\Services, где обычно помешаются параметры служб, измените значение параметра LanmanServer\Parameters\Hidden с 0 на 1. Служба сервера останется активной и пользователи смогут подключаться, но сервер не будет объявлять свою службу сервера и не будет появляться ни в одном списке просмотра.
С вами говорит NetBIOS
В этом разделе приводятся другие факторы, касающиеся NetBIOS и ее использования. Первый из них фактически представляет собой перечень проблем, с которыми сталкиваются администраторы, но которые были раньше лишь упомянуты в этой главе. Другие разделы этой главы посвящены нескольким вопросам, которые, возможно, еще недостаточно освещены в этой главе.
Проблемы) возникающие при использовании NetBIOS
Вероятно, самая большая проблема с NetBIOS — контроль, в целях защиты, над доступом к портам NetBIOS. Также очень важное место в списке проблем занимает управление широковещанием. Следом за ними по важности идет надежность службы просмотра, или, более правильно, служб WINS и выбора обозревателей. Следующая проблема — загрузка сети, вызываемая службой просмотра при выборах обозревателей и обслуживании списков.
Широковещанием NetBIOS можно управлять, используя WINS и имея надежную связь. Клиент Windows, настроенный как клиент WINS, автоматически становится гибридным (h-узлом), а не клиент WINS по умолчанию становится широковещательным (b-узлом). Этот факт сохраняет свое значение и при настройке машин Windows 2000, когда, казалось бы, не нужно делать их клиентами WINS.
Надежность служб имен Windows и просмотра была улучшена в служебных пакетах NT 4. Service Pack 3 решил многие из проблем выбора обозревателей, a Service Pack 4 и 5 за счет существенных изменений в WINS повысили управляемость и стабильность большой базы данных WINS. Еше одну важную проблему решило добавление переключателя nbtstat -rr, заставляющего клиента перерегистрироваться в WINS без перезагрузки.
Раньше много трудностей создавали многосетевые машины. Однако с появлением многосетевой регистрации WINS стало возможным легко управляться с этими старыми проблемами, если только вспомнить, что лишь первый протокол, связанный с адаптером, и/или первый 1Р в адаптере могут быть связаны с NetBIOS.
Учитывая, что эти службы довольно самостоятельны и, можно надеяться, теперь уже надежны, остаются только проблемы зашиты и нагрузки на сеть. Ранее в этой главе были описаны типы нагрузки, создаваемые службой просмотра, и рекомендовался отход от использования широковещательных клиентов. Итак, кажется, мы упомянули все, что может быть полезным, за исключением разве что того, что можно знать только для информации.
Самый простой способ выяснить, какого типа узел представляет ваша локальная машина, — ввести в командной строке ipconfig /all. Существует также утилита nbtstat, которая является для NetBT тем же, чем netstat для TCP/IP. Обе эти программы упомянуты в главе 12, "Средства поиска неисправностей". В листинге 17.1 приведен текст, выводимый командой nbtscat -г на компьютере Windows 95/98. Команда nbtstat -г показывает статистику разрешения начиная с момента загрузки. В данном случае она говорит о том, что сервер WINS разрешил все 1S запросов имен, сделанных клиентом.
Листинг 17.1. nbtstat -г показывает историю разрешения имен
С:'WINDOWS > nbtstat -г
NetBIOS Names Resolution and Registration Statistics
Resolved By Broadcast=0
Resolved By Name Server=18
Registered By Broadcast=0
Registered By Name Server=4
В листинге 17.1 приведен текст, выводимый на том же компьютере Windows 95/98 командой nbtstat -п. Эта команда показывает, какие имена успешно зареги стр ировали с ь на сервере имен.
Листинг 17.2. nbtstat -п показывает зарегистрированные имена
С:'WINDOWS > nbtstat -п
Node IP Address: [10/14/194/8] Scope Id：[]
NetBIOS Local Name Table
Name
TypeStatus
WS-EXAMPLE
COMPANY WS-EXAMPLE MEXAMPLE
00>UNIQUERegistered
00>GROUPRegistered
03>UNIQUERegistered
03>UNIQUERegistered
Что касается вопросов зашиты NetBIOS, то она традиционно заключается в том, что чем меньше информации доступно возможным злоумышленникам, тем лучше. В случае с WINS это труднее обеспечить, потому что NetBT разрешает значительно более широкое распространение информации имен NetBIOS, чем формы NetBIOS без применения WINS, ограниченные одним сегментом сети. Основная рекомендация состоит в том, чтобы фильтровать или отключить маршрутизацию трафика NetBIOS между вашей системой и открытой сетью.
NetBIOS по TCP/IP и другим транспортным протоколам
NetBIOS через TCP/IP, документированная в RFC 1001 и 1002, называется NetBT, или NBT. NetBIOS предоставляет один и тот же набор служб по протоколам NetBEUI, IPX /SPX и TCP/IP. Но следует обратить внимание, что службы NetBIOS, работающие по одному транспортному протоколу, не могут связываться со службами NetBIOS по другому транспортному протоколу. Например, можно использовать NetBEUI (который всегда включает NetBIOS) на одном компьютере, a NetBIOS через TCP/IP на другом, но они не смогут связаться между собой. На рис. 17.1 в начале этой главы изображено отношение NetBIOS к хорошо известной модели организации сетей OS1 с семью уровнями. Отсюда видно, что NetBIOS на сетевых верхних уровнях на двух машинах сможет установить сеанс, только если эти две машины имеют одинаковый протокол на нижних уровнях и NetBIOS разрешено использовать этот протокол на обеих машинах. Поэтому для повышения эффективности, если NetBIOS допускается по нескольким протоколам, то протокол, общий с другими машинами, должен быть первым, который применит NetBIOS при попытке установить сеанс.
Блоки серверных сообщений (SMB) и Общая файловая система Internet (CIFS)
Совершая обзор истории NetBIOS, мы не можем не упомянуть сетевые функции протокола блоков серверных сообщений (Server Message Block, SMB), которые дают компьютерам Windows собственное средство переадресации файлов для доступа к удаленным файловым системам. Некоторые разработчики рассматривают SMB как протокол LanMan, потому что в свое время он распространился благодаря уже не применяемым теперь продуктам ЗСот LAN Manager. Когда речь идет о SMB, более правильно думать о службах сеансов и дейтаграмм NetBIOS, поскольку службы имен это даже не касается. Хотя SMB и NetBIOS можно считать современниками, SMB оказался более устойчивым. Он был включен в открытый стандарт Общей файловой системы Internet (Common File Internet System, CIFS), предложенный Microsoft, Network Appliance и другими корпорациями. CIFS бььча очень похожа на Сетевую файловую систему (Network File System, NFS), обычно используемую на компьютерах UNIX, но имела некоторые существенные отличия.
Примечание
NetBIOS использует известные порты TCP/IP.
Службы имен NetBT используют порт UDP 137.
Службы сеансов NetBT — порт TCP 139
Службы дейтаграмм NetBT — порт UDP 138
С появлением Windows 2000 для SMB стал необходим новый способ работы, так,как NetBT на компьютерах Windows 2000 можно отключить. Для поддержки SMB машина Windows 2000 с отключенным NetBT получает IP-адрес целевой машины с помощью разрешения DNS. После этого она устанавливает сеанс SMB через порт 445. Microsoft называет этот процесс прямым хостингом. Если обе машины могут поддерживать прямой хостинг, сеанс SMB возможен и без применения NetBT.
SMB интенсивно применяется в популярном, распространяемом по открытой лицензии приложении для U NIX, называемом SAM В А. SAMBA позволяет узлам UNIX использовать файлы и принтеры совместно с компьютерами Windows и в большинстве случаев ведет себя как клиент низкого уровня, который может использовать WINS. Теперь, благодаря прямому хостингу в Windows 2000, поддержка SMB не требует Ne【BT. Однако надо сказать, что NetBIOS останется частью компьютера ного мира по крайней мере в ближайшее время.
Резюме
В этой главе представлены главные особенности NetBIOS, причем особое внимание уделено NetBT. Мы ознакомили вас с концепциями, призванными помочь администраторам в принятии проектных решений относительно WINS, служб просмотра и других служб в сетевом окружении Windows.
IV
Приложения
В этой части...
Файлы LMHOSTS и HOSTS
Б. Документы RFC по DNS
Домены Internet верхнего уровня
Г. Регистрация адресов в Internet
Д. Примеры трассировки разрешения DNS
Записи ресурсов н файл кэша InterNIC Ж. Использование IPv6
Многосетевые серверы Windows
AA
A
A
Файлы LMHOSTS и HOSTS
В этом приложении...
Здесь представлена информация о файле LMHOST5, используемом длм ра(решения имен NetBIOS, и 巾ai5e hosts, которь巾 применяется ты” разрешения имен DNS н системах Windows. В свое время эти ф^й.1Ы имели очень большое значение、но в последние годы они почти вышли из употребления. Однако для некоторых целен они остаются очень полезными. Многие администраторы, вероятно, из-за аккуратности или но привычке, все еще создают на своих ключевых серверах файлы lmhos.'',- как для предварительной загрузки кэша NetBIOS, так и для разрешения в аварийном режиме, когда все другие методы не действуют. Эти файлы также очень полезны для тех пользователей, которым нравится самим придумывать узлам имена, а также для разработчиков, которым нужны ярлыки для проверки Web-сайтов или временных мпшин, не регистр)! руемнх в службе имен.
Когда эти фа11лы используются, целесообразно вносить записи отдельных узлов параичлельно в оба файла, если вы нс абсолютно уверены в порядке поиска распознавателя. Надо иметь в виду и еще одно обстоятельство: каждый файл, когда это необходимо, аначизлрустся от начала к концу. По этой причине рекомендуется помешать наиболее часто нс- пользуемые записи в начале файла, размешать записи перед комментариями и содержать в этих файлах только необходимые записи.
Файл LMHOSTS
Файл LMHOSTS несет две функции. Во-первых, он анализируется при предварительной загрузке кэша распознавателя NetBIOS (который можно проверить с помощью команды nbtstdt -п}. Во-вторых, это последнее средство для распознавателя Net ВТ. Файл LMHOSTS на самом деле более легок в применении, чем это может показаться. Только не забудьте убедиться, что на вкладке WINS диалогового окна Дополнительные параметры TCP/IP установлен флажок Включить просмотр LMHOSTS.
LMHOSTS хранится в каталоге ^wir：dir%\ cirivers\ etc. где можно найти и представленный Microsoft образец этого файла LMHOSTS. SM. Его можно практически использовать, надо только удалить расширение .SAM. lmhosts очень похож на файл hosts в системах UNIX, но, как было сказано выше, он работает с именами NetBIOS, используя тот же синтаксис, что и Microsoft LAN Manager 2.x. При простом отображении имен на адреса LMHOSTS фу[1киионирует подобно файлу HOSI'S, оинако поддерживает и директивы, которые не разрешены в файле HOSTS.
Символ и, занимаюший первую позицию в строке, указывает, что эта строка содержит только комментарии для пользователя. Но если непосредственно за символом * следует одно из зарезервированных слов, показанных в табл. А.1. эта строка интерпретируется как директива, а не как комментарий. Эти директивы в основном применяются при предварительной загрузке кэша. Управлять файлами l_MNOS'：S можно централизованно, с помощью директивы INCLUDE.
Таблица А.1. Зарезервированные слова в файле LMHOSTS.SAM
Зарезервированное Описание слово
#PREЗагружает запись в кэш имен NetBIOS, где она остает
ся, пока компьютер работает. Эта директива необходима м должна предшествовать именам компьютеров, которые будут включены директивой # included. Можно предварительно загрузить до 100 записей
#DOM：Идентифицирует имя компьютера, выполняющего ра-
<имя_домена>боту контроллера домена Важно, особенно в отсутст
вие WINS, чтобы контроллеры домена были указаны на всех машинах домена. Запись имеет форму
■:丁 F-a 口 рс(;'><:;мя_маш1-1н=1> &PFE ¥DOM:
<имя_домена>
i3EGiN_ALTERNATE Обозначает начало раздела, где присутствуют операторы 井二кс二ude <нмс_фгйлй> После успешного включения (загрузки) первого файла в любом разделе в ходе обработки lmhosts остальные файлы пропускаются
Окончание табл. А.1
ЗарезервированноеОписание
слово
# includeУказывает один или несколько файлов lmhosts на
<^мя_факла>других компьютерах, которые нужно считать и вклю
чить в список имен и адресов. Для имени файла используется синтаксис UNC
^F.ND—ALTERNATE Обозначает конец раздела, где присутствуют операторы 4 INCLUDE
\CxnnОпределяет шестнадцатеричное значение непеча
таемого символа, который будет добавлен в конец имени NetBIOS в 16-м байте Это позволяет вручную указать коды служб подобно тому, как это делается при регистрации в WINS Если код прибавляется к имени, которое короче 15 символов, его надо заключить в кавычки и поставить Охлп внутри кавычек начиная с 16-й позиции Значение кодов ресурсов см в табл. 17 1. Можно также использовать другие специальные коды приложения, документированные в литературе по данному продукту Обратите внимание, что в LAN Manager эта функция отсутствует
Вероятно, не существует более ясного руководства по использованию файла LMHOSTS, чем собственное руководство Microsoft, включенное в поставляемый с системой образцовый файл. Этот файл LMHOSTS. SAM, автоматически устанавливаемый на компьютерах Windows 2000/NT в каталоге ' windir* \ systezi32 \arivers\etc, приведен в листинге А.1.
Листинг А.1. Образцовый файл LMHOSTS.SAM
# Copyright (с) 1。93-1999 Microsoft Corp.
# 770 образе」 файла LMHCSTS, используемого Microsoft
* Т ： 1- /1Р 匚ле Windows.
It Этот файл садерта1т таблицу соответствия IP-адресов и 井 оОычних (NetBIOS) имен компьютеров. Каждый элемент # должен располагаться в отдельной строке. IP-адрес # должен начинаться с первой позиции строки, а за ним # целует соотгетствующее ммя компьютера.
s TP-адрес к хм5? компьютера должны быть отделены друг от 斗 лругг хс?я Еь. оххям пробеле:-! клм символом табуляции.
-Зха?、"±" обычно у? сзывает на начало комментария г IИсключения из этого лрааила будут перечислены ниже丿.
* Этот файл совместим с файлам Microsoft LAN Manager # ?.х TCP/i? lmhosts
* " в нем можно использовать следующие дополнительные *= оператору:
#PRE
ЧООМ:<домен>
* INCLUDE <имя_файла>
#BEGIN_ALTERNATE
#END_ALTERNATE
\Oxnn (поддержкаспециальных символов 1
Если дополнить любую из строк символами "ifPRE", то
соответствующий элемент будет предварительно загружен
в буфер имен. По умолчанию элементы этого списка не
загружаются предварительно, а весь список просматривается
только в том случае, если динамическое разрешение
соответствий имен не привело к успеху.
Если дополнить любую из строк символами #DOM:<домен>",
то соответствующий элемент будет связан с указанным
доменом. Это влияет на поведение служб обзора и
регистрации в среде TCP/IP. Для того чтобы обеспечить
предварительную загрузку имени, связанного со строкой
#DOM, необходимо также добавить #PRE к этой строке.
Имя такого домена будет предварительно загружено, хотя # будет отображаться при просмотре буфера имен.
井
乱 Если дополнить любую из строк символами
И "^INCLUDE <имя_файла>", то зто приведет к тому, что
RFC NetBIOS (NBT) произведет поиск указанного файла и
выполнит его просмотр так, слоено он является
локальным файлом.
Обычно <имя_файла> задается в формате UNC, что
поззоляет хранить централизованный файл LMHOSTS на
сервере. Учтите, что в таком случае строка
соответствия IP-адреса для используемого сервера
ОБЯЗАТЕЛЬНО должна предшествовать его применению в
директиве itINCLUDE. Это соответствие так*е должно
использовать директиву #PRE.
我 Кроме того, общий ресурс "public" из приведенного ниже
примера должен присутствовать в списке "NullSessionShares
на LanManServer для того, чтобы клиенты смогли успешно
прочитать файл LMHOSTS.
Этот параметр хранится в системном реестре по адресу
\machine\system\currentcontrolset'services'
lanmanserver\parameters\nullsessionshares.
Нужно просто добавить строку "public" к имеющемуся там
списку.
Ключевые слова #BEGIN_ и 代END_ALTERNATE позволяют
группировать вместе несколько директив #INCLUDE. Хотя
бы одно успешное выполнение директивы "include"
считается успешным выполнением всей группы.
Наконец можно использовать специальные символы при
сопоставлении имен с помощью заключения
соответствующего имени в кавычки, а затем
использования шестнадцатеричного кода символа с
помощью записи \0xnn.
# й
# #
#
#
В следующем примере задействуются все перечисленные выше дополнительные операторы:
1Q2.54.94.97
102.54.94.102
102.54.94 .123
102.54.94.117
"appname popular localsrv
#PRE #DOM：networking #домен группы \0xl4" #специальный сервер приложений #PRE #предварительно загружаемое имя
#PRE #сервер, используемый в "INCLUDE"
BEGI：N_ALTERNATE
INCLUDE \\localsrv\public\lmhosts «INCLUDE \\rhino\public\lmhosts
END ALTERNATE
В приведенном выше примере в имени сервера "appname" имеется специальный символ, имена серверов "popular" и "localsrv" будут предварительно загружены, имя сервера "rhino" позволит получить централизованный файл LMHOSTS в том случае, если система "localsrv" будет недоступна.
# ### ##Учтите, что весь файл LMHOSTS, включая комментарии, будет просматриваться при каждом его использовании, так что имеет смысл минимизировать количество вводимых комментариев. По этой причине не следует просто дополнять данный файл нужными строками таблица соответствия, а лучше будет создать новый файл.
# #
#
# #
#
Файл HOSTS
Файл HOSTS играет в системах Windows точно такую же роль, что и в системах UNIX. Можно вспомнить, что в свое время, до появления BIND, разрешение всех имен узлов в сети TCP/IP проходило с помощью файлов HOSTS. Этот файл представляет собой локальную таблицу соответствия IP-адресов именам узлов DNS. Если распознаватель NetBT настроен для использования DNS для имен NetBIOS, этот файл будет проверяться этим распознавателем, а не просто распознавателем DNS.
Файл HOSTS также находится в каталоге %windir%\drivers\etc. Его синтаксис довольно очевиден, за исключением того, что нигде не говорится, что в строке каждого IP-адреса можно указывать несколько имен. Иными словами, если имеется строка
102.54.94.97 rhino.acme.com buddy itsmysite
можно обратиться к узлу itsmysite, и это будет то же самое, что обращение по адресу 102.54.94.97. Эти имена, конечно, также могут быть правильными FQDN для указанных IP-адресов.
Листинг А,2 представляет образцовый файл hosts, входящий в поставку Windows 2000/NT.
Листинг А.2. Образцовый файл HOSTS
(С) Корпорация Майкрософт (Microsoft Corp.), 1993-1999
Это образец файла HOSTS, используемый Microsoft TCP/IP # для Windows.
Данный файл содержит сопоставления IP-адресов именам узлов
Каждый элемент должен располагаться в отдельной строке.
IP-адрес должен находиться в первом столбце, за ним
должно следовать соответствующее имя.
IP-адрес и имя узла следует разделять хотя бы одним пробеле
Кроме того, в некоторых строках могут быть вставлены
комментарии (такие, как эта строка), они должны
следовать за именем узла и отделяться от него символом
Например：
#
102.54.94.97rhino.acme.com # исходный сервер
38.25.63.10х. acme. com# узел клиента >:
127.0.0.1localhost
Б
Документы RFC по DNS
Документы Request for Comments (RFC) выполняют несколько задач. Некоторые RFC описывают работу Internet, задавая стандарты. Другие служат для информации, а третьи предназначены дли обсуждения, представляя собой предложения, на основе которых могут быть созданы новые стандарты, или замечания, предлагающие полезные методы работы. В начале каждого RFC объявляется его статус и указывается, какого рода этот документ.
Выпуском RFC занимается редактор RFC в Институте информационных наук (ISI), отвечающий за публикацию документов в их окончательном виде. RFC можно найти на многих узлах; наиболее прямой адрес —— http://www.rfc-editor.org/rfc.htmL Для получения краткой информации о том, что такое RFC и каков процесс их продвижения, посетите http://www.rfc-editor.org. В Проблемной группе проектирования Internet (IETF) определенный RFC можно найти по его номеру NNNN, сформировав ссылку http://www.ietf.orq/rfc/rfcNNNN.txt. Можно также обратиться, особенно по поводу проектов Internet, на начальную страницу IETF http： //www. ietf.org.
В оставшейся части приложения дан список номеров и названий RFC, касающихся DNS, NetBIOS и технологий, связанных с использованием DNS (см- табл. Б.1). Для краткости в этот список не включены документы по протоколам Х.500 и LDAP и инфраструктуре открытых ключей (PKI). Некоторые из текущих проектов IETF. имеющих отношение к DNS, а особенно к DNS Windows 2000, приведены в конце.
Таблица Б.1. Документы RFC, используемые с DNS, NetBIOS и сопутствующими технологиями
RFCОписание
RFC 819，Соглашение о доменных именах для пользовательских приложе
ний Internet
RFC 830: Распределенная система службы имен Internet
RFC 920. Требования к домену
RFC 974: Маршрутизация почты и доменная система
RFC 986: Рекомендации по использованию адресов Internet (IP) в сетевом протоколе без установления соединения
RFC 1001: Стандарт протокола для службы NetBIOS через транспорт TCP/UDP концепции и методы
RFC 1002: Стандарт протокола для службы NetBIOS через транспорт TCP/UDP. подробное описание
RFC 1032， Руководство администраторов домена
RFC 1033: Рабочее руководство администраторов домена
RFC 1034: Доменные имена' концепции и возможности
RFC 1035: Доменные имена реализация и описание
RFC 1069. Рекомендации по использованию адресов Internet (IP) в сетевом протоколе ISO без установления соединения
RFC 1101' Кодирование в DNS сетевых имен и других типов
RFC 1118: Путеводитель по Internet
RFC 1122' Требования к узлам Internet' уровни связи
RFC 1123: Требования к узлам Internet приложение и поддержка
RFC 1183: Определения новых записей ресурсов DNS (дополняет RFC 1034 и 1035)
RFC 1348: Записи ресурсов DNS NSAP (документ заменен на RFC 1637)
RFC 1464: Использование доменной системы имен для хранения произвольных строковых атрибутов
RFC 1508 Универсальный интерфейс прикладного программирования для службы безопасности (документ заменен на RFC 2078)
RFC 1510: Служба сетевой идентификации Kerberos (V5)
RFC 1519' Бесклассовая междоменная маршрутизация (CIDR)，стратегия присвоения адресов и объединения
RFCRFC 1531:RFC 1535,RFC 1536-RFC 1537:RFC 1591：RFC 1597:RFC 1611.RFC 1612.RFC 1627'RFC 1631.RFC 1632RFC 1637:RFC 1664-RFC 1700:RFC 1706:RFC 1712:RFC 1713：RFC 1794：RFC 1876：RFC 1884:RFC 1886:RFC 1912.RFC 1964:RFC 1982:RFC 1995.RFC 1996-RFCRFC 1531:RFC 1535,RFC 1536-RFC 1537:RFC 1591：RFC 1597:RFC 1611.RFC 1612.RFC 1627'RFC 1631.RFC 1632RFC 1637:RFC 1664-RFC 1700:RFC 1706:RFC 1712:RFC 1713：RFC 1794：RFC 1876：RFC 1884:RFC 1886:RFC 1912.RFC 1964:RFC 1982:RFC 1995.RFC 1996-Описание
RFC
RFC 1531:
RFC 1535,
RFC 1536-
RFC 1537:
RFC 1591：
RFC 1597:
RFC 1611.
RFC 1612.
RFC 1627'
RFC 1631.
RFC 1632
RFC 1637:
RFC 1664-
RFC 1700:
RFC 1706:
RFC 1712:
RFC 1713：
RFC 1794：
RFC 1876：
RFC 1884:
RFC 1886:
RFC 1912.
RFC 1964:
RFC 1982:
RFC 1995.
RFC 1996-
RFC
RFC 1531:
RFC 1535,
RFC 1536-
RFC 1537:
RFC 1591：
RFC 1597:
RFC 1611.
RFC 1612.
RFC 1627'
RFC 1631.
RFC 1632
RFC 1637:
RFC 1664-
RFC 1700:
RFC 1706:
RFC 1712:
RFC 1713：
RFC 1794：
RFC 1876：
RFC 1884:
RFC 1886:
RFC 1912.
RFC 1964:
RFC 1982:
RFC 1995.
RFC 1996-
Протокол динамической конфигурации узла
Проблема безопасности и предлагаемое решение при широко развернутом программном обеспечении DNS
Обычные ошибки реализации DNS и предлагаемые исправления
Обычные ошибки в конфигурации файлов данных DNS
Структура и делегирование доменной системы имен
Выделение адресов для частных сетей Internet
Расширение MIB сервера DNS
Расширение MIB распознавателя DNS
О вещах, которые не следует узаконивать (должны ли IP-адреса в закрытых сетях быть уникальными)
Транслятор сетевых адресов IP
Исправленный каталог доступных реализаций X 500
Записи ресурсов DNS NSAP (заменяет RFC 1348)
Использование Internet DNS для распространения таблиц отображения почтовых адресов RFC 1327
Присвоенные числа
Записи ресурсов DNS NSAP (заменяет RFC 1637)
Кодировка географического местоположения в DNS
Инструментальные средства для отладки DNS
Поддержка DNS для распределения нагрузки
Средства выражения информации о местоположении в доменной системе имен
Архитектура адресации IP версии 6
Расширения DNS для поддержки IP версии 6
Обычные ошибки в настройке и работе DNS
Механизм GSS-API Kerberos версии 5
Арифметика серийных номеров (дополняет RFC 1034 и 1035)
Добавочная передача зон в DNS
Механизм уведомления об изменениях в зоне (DNS NOTIFY)
RFC
Описание
RFC 2010：
Рабочие критерии корневых серверов имен
RFC 2025:
Простой механизм GSS-API открытых ключей (SPKM)
RFC 2044:
UTF-8, формат преобразования Unicode и ISO 10646
RFC 2052：
Запись ресурсов DNS для определения местоположения служб (DNS SRV)
RFC 2065:
Расширения безопасности системы доменных имен (документ заменен на RFC 2535)
RFC 2078:
Универсальный интерфейс прикладного программирования для службы безопасности, версия 2 (заменяет RFC 1508)
RFC 2097:
Протокол управления кадрами NetBIOS PPP (PPP NetBIOS Frames Control, NBFCP)
RIFC2100
Именование узлов
RFC 2131：
Протокол динамической конфигурации узла
RFC 2132：
Параметры DHCP и расширения вендора ВООТР
RFC 2136：
Динамические обновления в системе доменных имен (DNS UPDATE) (дополняет RFC 1035)
RFC 2137：
Безопасное динамическое обновление системы доменных имен (дополняет RFC 1035)
RFC 2148'
Развертывание службы ' Белые страницы Internet"
RFC 2151：
Учебник для начинающих по инструментальным средствам и утилитам Internet и TCP/IP
RFC 2163:
Использование DNS Internet для распространения таблицы отображения глобальных адресов MIXER (MCGAM)
RFC 2168:
Разрешение универсальных идентификаторов ресурсов с помощью системы доменных имен
RFC 2181：
RFC 2182
Пояснения к спецификации DNS
Выбор и работа дополнительных серверов DNS
RFC 2196：
RFC 2200
Руководство по защите узлов
Стандарты официальных протоколов Internet
RFC 2203:
Спецификация протокола RPCSEC_GSS
RFC 2219-
Использование псевдонимов DNS для сетевых служб
RFC 2279:
UTF-8, формат преобразования ISO 10646 (заменяет RFC 2044)
RFC
Описание
RFC 2308:RFC 2308:Негативное кэширование запросов DNS (DNS NCACHE) (дополняет RFC 1034 и 1035)
RFC 2308:
RFC 2308:
RFC 2317: Бесклассовое делегирование IN-ADDR.ARPA
RFC 2345: Доменные имена и восстановление названия компании
RFC 2352: Соглашение по использованию юридических названий как доменных имен
RFC 2478: Механизм простого и защищенного согласования GSS-API
RFC 2517: Формирование каталогов из DNS
RFC 2535' Расширения безопасности системы доменных имен (заменяет RFC 2065, обновляет RFC 2181, 1035, 1034)
RFC 2536: Ключи и подписи DSA в системе доменных имен
RFC 2537: Ключи и подписи RSA/MD5 в системе доменных имен
RFC 2538: Хранение удостоверений в системе доменных имен
RFC 2539， Хранение ключей Диффи-Хеллмана в системе доменных имен
RFC 2540: Обособленная информация системы доменных имен (DNS)
RFC 2541: Замечания по работе безопасности DNS
RFC 2606. Зарезервированные имена верхнего уровня DNS
RFC 2671: Механизмы расширения для DNS (EDNS0)
RFC 2672: Неокончательная переадресация имен DNS (запись ресурсов DNAME)
RFC 2694: Расширения DNS на трансляторы сетевых адресов (DNS ALG)
Несколько текущих изменений стандартов RFC находится на черновой стадии процесса. Можно заметить, что по некоторым элементам в Windows 2000 нет последовательного списка документов RFC, к которому можно было бы свести все, что там сделано. Microsoft выпустила несколько "белых книг", которые находятся на ее Web-сайте и в которых можно выяснить, что имелось в виду в каждом таком случае и как это соотносится с проектами IETF. Можно также обследовать указанные выше узлы, http: //www. rfceditor . org/rfc . html и http： //www.ietf.org/lD.html, чтобы увидеть, как эти проекты переходят от одной редакции к другой, чтобы в конце кониов стать (или не стать) стандартами RFC.
Ниже перечислены проекты 1ETF, на которые стоит особо обратить внимание в связи с начальной версией Windows 2000 (вероятно, вам понадобится найти версии с большими номерами).
RFC 2052, Запись ресурсов DNS для определения местоположения служб (DNS SRV), был пересмотрен; в новой редакции, которая иногда упоминалась как RFC 2052bis, в частности, был введен символ подчеркивания
Текущий проект, датированный ноябрем 1999 г., имеет такой же заголовок, что и RFC 2052 (см. http://www.ietf.org/internet- drafts/draft-ietf.dnsind-rfc2052bis-05.txt).
Проект IETF Взаимодействие между DHCP “ DNS касается обновления DNS с помошью протокола DHCP и датирован октябрем 1999 г. (см. http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcp-dns- 11. txt).
Включен в Windows 2000, но не полностью документирован Параметр класса пользователя для DHCP, датированный октябрем 1999 г. (см. http://www.ietf.org/internet.drafts/draft-ietf-dhc- userclass-04.txt).
Проект Обнаружение служб LDAP с помощью £WS, датированный сентябрем 1999 г., несколько приближается к объяснению того, как DNS используется на таких высоких уровнях, как службы каталогов в архитектуре LDAP Windows 2000 (см. http://www.ietf.org/internet- drafts/draft-ietf-Idapext-locate-00.txt)-
K безопасности DNS, особенно процесса динамического обновления, относятся следующие проекты.
Идентификация сообщения секретного ключа для DNS (TSIG), датированный декабрем 1999 г. (см. http: / /www. ietf . org/internet. drafts/ draf t-ietf-dnsind-tsig-I2 .txt).
Установка секретного ключа для DNS (запись ресурсов TKEY), датированный декабрем 1999 г. (см. http://www.ietf.org/internet- draftз/draft-ietf-dnsind-tkey-02.txt).
Алгоритм GSS для TSIG (GSS- TSIG), датированный июнем 1999 г. (см. http://www.ietf.org/internet-drafts/draft-skwan-gss-tsig- 04 .txt).
О применении меток UTF-8 в DNS: Использование набора символов UTF-8 в системе доменных имен, датированный июнем 1999 г. (см. http：//www.ietf.org/internet-drafts/draft-skwan-utf8-dns- 02 . txt).
Домены Internet верхнего уровня
В этом приложении...
Здесь представлен список доменов верхнего уровня (top-level domain, TLD). В системе доменных имен (DNS) все серверы и узлы DNS относятся к какой-то -определенной стране или организации определенного типа. Некоторые из этих TLD вы, вероятно, уже видели. Они часто фигурируют в конце имен Web-серверов: сот — для коммерческих организаций, edu — для образовательных организаций, net ——для центров поддержки сети и т.д. Эти и другие домены показаны в табл. В.2. Таблица В.1 содержит примеры TLD для стран.
TLD может содержать много имен узлов, но серверы DNS, обслуживающие TLD, обычно не хранят имена всех этих узлов. Это важно знать. Просто этих имен слишком много, чтобы с ними справился один сервер. Вместо этого серверы DNS верхнего уровня включают записи делегирования, которые указывают на серверы DNS низшего уровня.
Доменные имена низших уровней в иерархии имен DNS могут меняться часто и без особых последствий, так же как листья и ветви реального дерева могут меняться по сезону или с возрастом. Имена TLD, напротив, можно сравнить с большими ветвями дерева. Хотя они необязательно постоянны, TLD не могут изменяться легко или часто, потому что они поддерживают все более низкие домены. Другие предлагаемые TLD перечислены в табл. В.З.
Одни TLD имеют собственные серверы DNS. Другие управляются корневыми серверами DNS, например домены us и edu. показанные на рис. 2.6 в главе 2, "Как работает DNS".
Таблица В.1. Коды стран для доменов Internet верхнего уровня
Доменное имя
Страна или регион
АС
Остров Вознесения
AD
Андорра
АЕ
Объединенные Арабские Эмираты
AF
Афганистан
AG
Антигуа и Барбуда
AI
Ангилья
AL
Албания
АМ
Армения
AN
Нидерландские Антильские острова
АО
Ангола
AQ
Антарктика
AR
Аргентина
AS
Восточное Самоа (США)
АТ
Австрия
AU
Австралия
AW
Аруба
AZ
Азербайджан
ВА
Босния и Герцеговина
ВВ
Барбадос
BD
Бангладеш
BE
Бельгия
BF
Буркина-Фасо
BG
Болгария
ВН
Бахрейн
BI
Бурунди
BJ
Бенин
Доменное имя
Страна или регион
ВМ
Бермудские острова
BN
Бруней
ВО
Боливия
BR
Бразилия
BS
Багамские острова,
ВТ
Бутан
BV
Остров Буве
BW
Ботсвана
BY
Беларусь
BZ
Белиз
СА
Канада
сс
Кокосовые (Килинг) острова1
CD
Демократическая Республика Конго
CF
Центральноафриканская Республика
CG
Республика Конго
СН
Швейцария
CI
Кот д'Ивуар (Берег Слоновой Кости)
СК
Острова Кука
CL
Чили
СМ
Камерун
CN
Китай
СО
Колумбия
CR
Коста-Рика
си
Куба
CV
Кабо-Верде
сх
Остров Рождества
CY
Кипр
'Домен передан е пользование компании SamsDirea
Доменное имя
Страна или регион
CZ
Чешская Республика
DE
Германия
DJ
Джибути
DK
Дания
DM
Доминика
DO
Доминиканская Республика
DZ
Алжир
ЕС
Эквадор
ЕЕ
Эстония
EG
Египет
ЕН
Западная Сахара
ER
Эритрея
ES
Испания
ЕТ
Эфиопия
Fl
Финляндия
FJ
Фиджи
FK
Фолклендские (Мальвинские) острова
FM
Федеративные Штаты Микронезии
FO
Фарерские острова
FR
Франция
GA
Габон
GD
Гренада
GE
Грузия
GF
Французская Гвиана
GG
Гернси
GH
Гана
Gl
Гибралтар
GL
Гренландия
Доменное имя Страна или регион
GMГамбия
GNГвинея
GPГваделупа
GQЭкваториальная Гвинея
GRГреция
GSЮжная Георгия и Южные Сандвичевы острова
GTГватемала
GUГуам
GWГвинея-Бисау
GYГайана
НКГонконг
НМОстрова Хёрд и Макдональд
HNГондурас
HRХорватия
НТГаити
HUВенгрия
IDИндонезия
IEИрландия
ILИзраиль
IMОстров Мэн
INИндия
ЮБританская Территория Индийского Океана
(острова Диего-Гарсия)
IQИрак
IRИсламская Республика Иран
ISИсландия
ITИталия
JEДжерси
JMЯмайка
Доменное имя
Страна или регион
JO
Иордания
JP
Япония
КЕ
Кения
KG
Кыргызстан
КН
Камбоджа
KI
Кирибати
КМ
Коморские острова
KN
Острова Сент-Китс, Невис и Ангилья
КР
Корейская Народно-Демократическая Республика (Северная Корея)
KR
Республика Корея (Южная Корея)
KW
Кувейт
KY
Каймановы Острова
KZ
Казахстан
LA
Лаос
LB
Ливан
LC
Сент-Люсия
LI
Лихтенштейн
LK
Шри Ланка
LR
Либерия
LS
Лесото
LT
Литва
LU
Люксембург
LV
Латвия
LY
Ливийская Арабская Джамахирия
МА
Марокко
МС
Монако
MD
Молдова
MG
Мадагаскар
Доменное имя
Страна или регион
МН
Маршалловы острова
мк
ML
Македония
Мали
ММ
Мьянма
MN
МО
Монголия
Макао
МР
Северные Марианские острова
MQ
MR
Мартиника
Мавритания
MS
Монтсеррат
мт
ми
Мальта
Маврикий
MV
Мальдивские острова
MW
Малави
MX
MY
Мексика
Малайзия
MZ
Мозамбик
NA
Намибия
NC
Новая Каледония
NE
Нигер
NF
Остров Норфолк
NG
Нигерия
Nl
Никарагуа
NL
Нидерланды
NO
Норвегия-
NP
Непал
NR
Науру
NT
Нейтральная зона
Продолжение табл. B.1
Доменное имя
Страна или регион
NU
Ниуэ
NZ
Новая Зеландия
ОМ
Оман
РА
Панама
РЕ
Перу
PF
Французская Полинезия
PG
РН
Папуа-Новая Гвинея
Филиппины
РК
Пакистан
PL
РМ
Польша
Сен-Пьер и Микелон
PN
Питкэрн
PR
Пуэрто-Рико
РТ
Португалия
PW
Палау
PY
Парагвай
QA
Катар
RE
RO
Остров Реюньон
Румыния
RU
Российская Федерация
RW
Руанда
SA
Саудовская Аравия
SB
Соломоновы острова
SC
Сейшельские острова
SD
Судан
SE
Швеция
SG
Сингапур
SH
Остров Святой Елены
Доменное имя
Страна или регион
SI
SJ
Словения
Острова Свальбард и Ян-Майен
SK
SL
Словацкая Республика Сьерра-Леоне
SM
Сан-Марино
SN
Сенегал
SO
Сомали
SR
Суринам
ST
Сан-Томе и Принсипи
SV
Сальвадор
SY
Сирийская Арабская Республика
SZ
Свазиленд
TO
Острова Тёркс и Кайкос
TD
Чад
TF
TG
Французская Южная Территория
TH
Таиланд
TJ
Таджикистан
TK
TM
Токелау
Туркменистан
TN
TO
Тунис
TP
Восточный Тимор
TR
Турция
TT
Тринидад и Тобаго
TV
Тувалу2
TW
Тайвань
Домен передан в пользование компании SamsDirect
Доменное имя Страна или регион.
TZТанзания
UAУкраина
UGУганда
UKОбъединенное Королевство (Великобритания)
UMМалые отдаленные острова США
USСоединенные Штаты Америки
UYУругвай
UZУзбекистан
VAВатикан
VCСент-Винсент и Гренадины
VEВенесуэла
VGВиргинские острова (Великобритания)
VIВиргинские острова (США)
VNВьетнам
VUВануату
WFОстрова Уоллис и Футуна
WSЗападное Самоа
YEЙемен
YTОстров Майотта
YUЮгославия
ZAЮжная Африка
ZMЗамбия
ZRЗаир
ZWЗимбабве
Таблица В.2. Стандартные TLD
Доменное имя Назначение
СОМКоммерческие сайты
EDUОбразовательные сайты
Доменное имя
Назначение
GOV
Сайты правительства США
INT
MIL
Международные организации
Военные сайты США
NET
ORG
Организации, связанные с сетями Организации.
Таблица В.З. Другие предложенные TLD3
Доменное имя
Назначение
FIRM
Для компаний или фирм
SHOP
Для фирм, предлагающих товары на продажу (первоначально предлагалось STORE)
WEB
Для субъектов, деятельность которых связана с WWW
ARTS
Для субъектов культурной деятельности
REC
Для субъектов развлекательно-зрелищной деятельности
!NFO
NOM
Для субъектов, предоставляющих информационные услуги
Для тех, кому нужно индивидуальное или персональное обозначение
'Подробнее о новых доменах верхнего уровня см. на www.ieann.or^/ilds — Прим. ред.
Регистрация адресов в Internet
Делегированием DNS в Internet занимается ImerNIC (Internet Network Information Center — Информационный центр сети Internet). (Раньше регистрацию имен осуществляла исключительно компания Network Solutions, Inc.) InterNIC — это название, зарегистрированное в Министерстве торговли США; прежде его использовала исключительно компания Network Solutions. Теперь новая некоммерческая организация ICANN (Internet Corporation for Assigned Names and Numbers), уполномоченная правительством США. отвечает за множество функций Internet, включая систему доменных имен (wwv；. icann. org). ICANN уполномочила группу аккредитован ных регистраторов регистрировать имена в доменах верхнего уровня . сот. .огд и , net. Любой объект сети, лицо или организация, который намерен работать в Internet, должен иметь зарегистрированное имя. делегированное JnterNIC, чтобы оно было заметно для других. Network Solutions больше не является единственным агентом по регистрации; можно войти в контакт со многими другими. Полный список регистраторов, который ведет ICANN, можно посмотреть на www.icann,org/registrars/accreditedlist.html, а список активных регистраторов, который ведет InterNIC — на www.internic.net/reg ist.html.
Процесс регистрации относительно безболезнен, а стоимость минимальна. Многие организации в Internet оказывают услуги по регистрации доменов, но они часто требуют дополнительную плату. Стандартная плата за регистрацию домена . com, .org или .net — 35 долларов в год, но надо внести плату сразу за два первых года, т.е. 70 долларов. По прошествии двух лет выписываются ежегодные счета на 35 долларов для возобновления регистрации. Многие регистраторы также предлагают возобновление регистрации на несколько лет, до десяти лет в некоторых случаях. Впрочем, регистраторы могут сами устанавливать свои цены и предлагать сопутствующие пакеты, которые увеличивают или уменьшают стоимость регистрации имени. Домены стран могут быть значительно более дорогими, причем код каждой страны управляется независимо. Например, домен верхнего уровня .us обслуживается на www.mc.us, а Агентство по выделению имен и уникальных параметров протоколов Internet (Internet Assigned Numbers Authority, IANA) ведет на www. iana . org/cct Id, html список ответственных организаций для кодов каждой страны.
Организация, первый раз вступающая в Internet, должна решить до регистрации несколько вопросов. Вы должны иметь правильный сетевой адрес IP. Иными словами, числа, применяемые для IP-адресов ваших узлов, должны быть назначены (не выбраны случайно), а сетевая часть IP- адреса должна быть маршрутизируемой. Обе эти проблемы обычно решаются Internet-провайдером, через которого вы подключаетесь к Internet.
Следующая вешь, о которой надо позаботиться, — выбор доменного имени. На практике целесообразно иметь в резерве несколько имен, поскольку кто-то уже мог зарегистрировать первый или даже второй вариант вашего имени. Проверить, не зарегистрировано ли уже какое-то имя, можно, введя команду whois <доменное имя> или воспользовавшись Web-интерфейсом, который предоставляют многие сайты, например www.networksolutions.com/cgi-bin/whois/whois. После того как вы выбрали подходящее доменное имя, заполните регистрационные формы и отправьте их.
Доменное имя можно зарегистрировать несколькими различными способами. Самый простой из них ——выполнение поэтапной инструкции, которую можно найти на Web-странице выбранного регистратора. В предыдущей версии этой книги были представлены соглашение с Network Solutions (версия 4.0) и регистрационная форма зто访 компании, поскольку тогда это была единственный вариант. Текстовую версию формы Network Solutions можно также загрузить на ftp://rs.internic.net/templates/domain-template.txt. Иногда для запуска DNS эта форма представляет собой самый быстрый и самый простой способ регистрации имен. Адреса Internet либо делегируются вам от вашего Internet-провайдера, либо назначаются Американским реестром сетевых номеров (American Registry for Internet Numbers, ARIN), http： //www.arin.net. Многие провайдеры не делегируют полномочия
для блоков адресов меньше /24 (сети класса С). Способность управлять вашей зоной обратных адресов будет сильно зависеть от размера вашей организации и вашей потребности в адресном пространстве. Форма шаблона, доступная на узле ftp, приводится ниже. Возьмите ее в качестве примера и сверьте с текущей информацией там, где вы будете регистрировать имя. Дескриптор NIC присваивается после завершения первой регистрации; на него можно ссылаться при будущих представлениях документов. Пункты 9 и 10 присутствуют только при первой регистрации.
[Формы можно загрузить на ftp： //www. networksolutions . com/ templates]
Authorization
0a. (N)ew (M)odify (D)elete
Ob. Auth Scheme
0c. Auth Info
Comments
Complete Domain Name
Organization Using Domain Name
3a. Organization Name
3b. Street Address
3c. City
3d. State
3e. Postal Code
3f. Country
Administrative Contact
4a. NIC Handle (if known)
4b. (I)ndividual (R)ole
4c. Name (Last, First)
4d. Organization Name
4e. Street Address
4f. City
4g. State
4h. Postal Code
Country
4j. Phone Number
4k. Fax Number
E-Mailbox
Technical Contact
5a. NIC Handle (if known)
5b. (I)ndividual (R)ole
5c. Name (Last, First)
5d. Organization Name
5e. Street Address
5f. City
5g. State
5h. Postal Code
5i. Country
5j. Phone Number
5k. Fax Number
51. E-Mailbox
Billing Contact
6a. NIC Handle (if known)
6b. (l)ndividual (R)o!e
6c. Name (Last, First)
6d. Organization Name
6e. Street Address
6f. city
6g. State
6h. Postal Code
6i. Country
6j. Phone Number
6k. Fax Number
61. E-Mailbox
Primary Name Server
7a. Primary Server Hostname
7b. Primary Server Netaddress
Secondary Name Server(s) 8a. Secondary Server Hostname 8b. Secondary Server Netaddress..:
Product/Service Options (For New Reg 9a. Registration Period (l-10yrs): 9b. Bulk Whois Optoul (Y/N)
Channel Payment/Identifier Options 10a. Channel Identifier
Примеры трассировки разрешения DNS
В этом приложении...
Здесь показаны некоторые образцы информации, выдаваемой утилитой сетевой монитор (NetMon). Ее полнофункциональная версия входит в состав сервера управления системами (SMS) и позволяет перехватывать трафик на любую машину и с любой машины в сети. Версия с меньшими возможностями, поставляемая с Windows 2000, позволяет отслеживать трафик на машину м с машины, на которой она работает.
NetMon предоставляет базовые возможности перехвата и декодирова- ния пакетов. На рисунках, приведенных в этом приложении, представлены разделы заголовка пакетов, перехваченных на сервере имен при обработке нескольких запросов DNS, заданных командой nslookup.
Трассировка запроса DNS: прохождение запроса
На рис. Д.1 показан запрос DNS о reston.va.us. В приведенном списке последовательно идут свойства кадра, заголовки пакетов Ethernet, IP, UDP и, наконец, информация DNS. Выделенная строка — это вопрос в пакете DNS.
Рис. Д.1. Пакет запроса DNS, просматриваемый в NetMon
Исходя из показанной информации пакет можно идентифицировать как запрос DNS об адресе узла класса Internet reston. va. us. В верхнем кадре можно видеть перехваченные пакеты в порядке прохождения. Детали выделенного в верхнем кадре пакета отображаются в нижнем кадре. Еше более подробный, шестнадцатеричный уровень пакета здесь не отображен. Если взглянуть на верхнее окно, два первых пакета в списке имеют протокол DNS. Первый из нмх — это запрос DNS, посланный программой nslookup на сервер DCI, а следующий, который раскрыт в нижнем окне, — это результирующий запрос, отправленный сервером DNS на DC1 при рекурсивном разрешении запроса nslookup. Детали двух этих пакетов почти идентичны.
На рис. Д.2 показан возвращенный пакет с ответом на запрос. Первое, что можно заметить при поиске ответа DNS, — это то, что
reston. va. us действительно разрешен как запись адреса узла (А) и приведен его 1Р-адрес.
В верхнем кадре рисунка можно заметить, что выделенный пакет был получен сервером DC1 от того же узла, которому был послан запрос DNS. Следующий пакет DNS, исходящий из DC1, возвращает ответ исходной системе, пославшей запрос. Но, просмотрев детали ответного пакета, можно понять, что в нем к reston.va.us относится несколько больше, чем просто запись А. На том же уровне, что и раздел ответа (Answer Section), можно заметить раздел полномочий (Authority Section) н раздел дополнительных записей (Additional Records Section). На рис. Д.З показан тот же пакет с этими добавленными разделами в частично раскрытом виде.
Раздел полномочий показывает, что имя reston.va.us найдено также в трех записях NS. Первая из них раскрыта и показывает имя сервера DNS, делегируемое записью для домена reston. va. Ниже, в разделе дополнительных записей, раскрыта запись ресурсов, показывающая, что IP для использования в последующих запросах был включен в ответ.
В этом примере программа nslookup настроена так, чтобы запрашивать запнсн любого типа (type=any), поэтому для имени reston.va.us возврашены записи как А, так и сервера имен (NS).
Рис. Д.2. Ответ на запрос DNS, просматриваемый в NetMon
Рис, Д.3, Информация записей ресурсов в ответном пакете DNS
Трассировка запроса DNS Windows NT 4: DNS с интеграцией WINS
Если включен просмотр WINS, сервер DNS может запрашивать узлы, зарегистрированные в WINS и, если они существуют, сообщать о них как о членах домена Internet, обслуживаемого сервером имен. Вспомните, что любое имя NetBIOS в базе данных WINS разрешается службой DNS, как если бы оно было представлено записью ресурсов А, в доменах, допускающих разрешение WINS. Вследствие этого одно и то же имя NetBIOS потенциально может быть разрешено в несколько полностью уточненных доменных имен (FQDN), если запись WINS используется в зоне, содержащей несколько доменов DNS.
В NetMon версии 2.1, поставляемой с Windows 2000, были сделаны некоторые изменения по сравнению с версией 1.1 для Windows NT 4. Вследствие возможной путаницы из-за другого представления пакетов в NetMon для Windows NT 4 сначала рассмотрим трассировку в NetMon версии 1.1 на рис. Д.4 и Д.5. На рис. Д.4 показано прохождение запроса адреса узла с сервера DNS на сервер WINS.
В этом запросе интересны несколько моментов. Первый из них — это строка заголовка UDP, из которой видно, что исходный порт — 53 (стандартный для DNS), но порт назначения — 137 (служба имен NetBIOS).
Рис, Д.4. NetMon 1.1 показывает, как DNS запрашивает WINS в Windows NT 4Рис, Д.4. NetMon 1.1 показывает, как DNS запрашивает WINS в Windows NT 4
Рис, Д.4. NetMon 1.1 показывает, как DNS запрашивает WINS в Windows NT 4
Рис, Д.4. NetMon 1.1 показывает, как DNS запрашивает WINS в Windows NT 4
Второй момент, представляющий интерес, — это то, что имя, используемое в запросе, представляет собой закодированную буквенноцифровую строку, а тип запроса неизвестен ("Unknown"). Очевидно, это проблема. Microsoft подтвердила это в статье Q160828 Сетевой монитор анализирует запросы просмотра DNS WINS как пакеты DNS своей базы знаний. В этой статье говорится: "В колонке Protocol будет указано "DNS" даже тогда, когда пакет, посылаемый серверу WINS, является пакетом NetBT (NetBIOS через TCP), предназначенным для порта 137".
На рис. Д.5 показан ответ на запрос, разрешенный через WINS. Здесь также в пакете DNS присутствует некоторая нестандартная информация. Возвращено то же, что и в предыдущем случае, имя с типом ресурса 20 (шестнадцатеричное), который в стандартной DNS является кодом неизвестного типа ресурса, а поле RDATA. которое обычно содержит IP- адрес, отсутствует. Вместо него в строке Additional Resource Data появляется ряд чисел, похожих на адрес МАС.
Этот ответ не очень полезен, и ясно, что между серверами WINS и DNS проходит какая-то скрытая, неописанная информация. Проблема с этой трассировкой в том, что здесь по сути нет никаких указаний на то, что происходит. Запрос проходит на сервер WINS и возвращается ответ, но как действительно убедиться, что информация правильна? Кстати, строка чисел, которую возвращает сервер WINS, — это не адрес МАС, что можно доказать, запросив адрес МАС у рабочей станции.
> arp -d machine.example.NET
Net to Media TableDevice IP AddressMask FlagsNet to Media TableDevice IP AddressMask FlagsleOmachine.example.NET 255.255.255.255leOmachine.example.NET 255.255.255.255Phys Addr00:20;af:f0：77;0ePhys Addr00:20;af:f0：77;0e
Net to Media Table
Device IP AddressMask Flags
Net to Media Table
Device IP AddressMask Flags
leOmachine.example.NET 255.255.255.255
leOmachine.example.NET 255.255.255.255
Phys Addr
00:20;af:f0：77;0e
Phys Addr
00:20;af:f0：77;0e
Рис, Д.5. NetMon 1.1 показывает, как WINS отвечает DNS в Windows NT 4
Трассировка запроса DNS Windows 2000: DNS с интеграцией WINS
Синтаксический анализатор пакетов в NetMon 2.1, поставляемый с Windows 2000, разрешает такие пакеты, которые, как правило, трудно декодировать любым другим инструментом. На рис. Д,6 показан начальный запрос машины 3of 5 .pc, example .local, отправленный на сервер DNS командой nslookup.
В данном случае в зоне не найдено записи А для этого имени узла, но зато зона содержит запись WINS. В результате сервер DNS посылает серверу WINS запрос на неуточненное имя узла. В верхнем кадре на рис. Д.6 можно заметить два пакета NBT (NetBT), сопровождаемые ответом DNS на этот запрос. Эти пакеты NBT показаны на рис. Д.7 и Д.8.
На рис. Д.7 можно видеть, что это обычный запрос имени NetBIOS, направленный на порт UDP 137. Ниже, в строке Query Name, видно, что
из первоначального запроса DNS удалено все, кроме первой метки, а остаток дополнен до длины 15 символов, после чего дописан шестнадцатеричный 0, и в результате получилось запрашиваемое имя NetBIOS.
На рис. Д.8 показан нормальный ответ успешного разрешения имени WINS в уникальное имя. Если бы мы посмотрели на следующий пакет, озаглавленный DNS 0x24 Std Qry Resp., мы увидели бы совершенно обычный ответ DNS, отправляемый первоначальному распознавателю nslookup.
Несмотря на некоторые недостатки, NetMon ——превосходный инструмент для администраторов, потому что он декодирует и анализирует сообщения SMB и NBT, а также анализирует сообщения LDAP. Пока в сети будут использоваться традиционные приложения, анализ пакетов, имеющих отношение к NetBIOS (которые множеством других программ рассматриваются как неизвестные), сам по себе делает NetMon очень полезным инструментом.
Рис, Д.6. Рекурсивный запрос DNS, просматриваемый в NetMon 2.1
Рис. Д.7. NetMon 2.1 показывает, как DNS посылает WiNS запрос имени
Рис. Д.8. NetMon 2,1 показывает, как DNS получает ответ WINS
E
Записи ресурсов и файл кэша InterNIC
В этом приложении...
Здесь для справки представлена информация двух видов: список записей ресурсов (RR) и образец файла корневого кэша сервера InterNIC (оба они были действительны на момент написания книги).
Записи ресурсов
Ниже приводится список типов записей ресурсов, который в отличие от списка в главе 4, 11 Подробная информация о домене," является полным. По обычным типам записей обратитесь к главе 4. В дополнение к объяснению каждого типа RR, здесь показан его синтаксис для файла зоны и пример его применения. Обратите внимание, что поля <класс> и <ttl> в записях можно менять местами. Все упоминаемые документы RFC являются стандартами, если не указано иное.
Записи адреса (A) (RFC 1035)
Записи А служат для отображения имен узлов на адреса протокола Internet (IP) (подробнее см. главу 4, "Подробная информация о домене"). Синтаксис записи А следующий.
<владелец> <ttl> <к”асс> А <апрес>
Запись А может выглядеть так.
socrates IN А 10.1.1.1
Записи Quad А (АААА) (RFC 1886)
Записи АААА — это записи адресов узлов с использованием IP версии 6 (IPv6). Их синтаксис в основном такой же, что и у стандартных записей А.
<владелец> <ttl> <класс> АААА <адрес IPv6〉
Запись АААА может выглядеть так.
v6twy.taos.com. IN АААА 1234:5678:abc:0:0:0:35 б:7 О
Записи базы данных файловой системы Andrew (AFSDB) (RFC 1183) - экспериментальные
Записи AFSDB (на данном этапе экспериментальные) — это указатели на серверы базы данных ячейки файловой системы Andrew (Andrew File System, AFS) либо на серверы имен, авторизованные в среде DCE. AFS — это распределенная сетевая файловая система, в которой местоположения всех наборов файлов хранятся в базе данных ячейки. Информацию о расположении служб среды распределенных вычислений (distributed computer environment, DCE) компании Open Software Foundation получают от авторизованного сервера имен в ячейке DCE. Ячейка — это группа узлов, совместно используюших службы. Синтаксис записи AFSDB следующий.
<владелец> <ttl> <класс> AFSDB <подтип> <-узел>
Здесь <подтип> равен 1 для базы данных ячейки AFS и 2 для сервера имен, авторизованного в DCE. Запись AFSDB может выглядеть так.
taos.com. IN AFSDB 1 afssrv.taos.com.
Записи канонического имени (CNAME) (RFC 1035)
Записи CNAME предоставляют ^псевдонимы1' для узлов (подробнее см. главу 4). Синтаксис записи CNAME следующий.
<владелец> <ttl> <к”асс> CNAME <узел.домен.>
Запись CNAME может выглядеть так.
ftp IN CNAME www.domain.com.
Записи переадресации домена (DNAME) (RFC 2672)
Записи DNAME обеспечивают переадресацию ветвей домена. Это может быть очень полезно, если из-за слияния сетей или изменения их нумерации требуется объединение доменов. Синтаксис записи DNAME следующий.
■~владелец> <ttl> <класс> DNAME <адресат>
Запись DNAME может выглядеть так.
hq.example.comIN DNAME corp.example.net.
Кодировка DNS географического местоположения - записи глобального позиционирования (RFC 1712) - устаревшие
Записи информации узла (HINFO) (RFC 1035)
Запись HINFO предоставляет некоторую базовую информацию об архитектуре узла или типе аппаратного обеспечения и операционной системе. Первоначально предназначенные для помощи клиентам, соединяющимся с узлами, на которых работают такие службы, как, например, FTP, записи H1NFO теперь применяются прежде всего местными администраторами для слежения за машинами в сети. Их синтаксис следующий.
<владелец> <ttl> <класс> HINFO <cpu> <os>
Запись HINFO может выглядеть так.
flamer.taoslab.com. IN HINFO PC Win95
flamer. taoslab.com.IN HINFO "Intel PC" "Solaris >:86"
Если в полях <cpu> и <os> предполагается использовать пробелы, их надо заключить в кавычки.
Записи цифровой сети интегрального обслуживания (ISDN) (RFC 1183)- экспериментальные
Запись ISDN (на данном этапе экспериментальная) предоставляет адреса для ресурсов ISDN. Уникальность ISDN состоит в том. что адрес ISDN по сути является телефонным номером. Запись ISDN содержит
номер телефона (с кодами страны и города); она может также включать поле <подадрес> после основного адреса (номера телефона), содержащее добавочный телефонный номер, если такой есть. Синтаксис записи ISDN следующий.
<владелец> <ttl> <класс> ISDN <адрес ISDN〉 <лодадрес>
Запись ISDN может выглядеть так.
pbx.taos.com. IN ISDN 14083302562100
Записи KEY (RFC 2535, устаревший RFC 2065)
Запись KEY служит для идентификации открытого ключа, связанного с именем DNS. Открытый ключ требуется защищенной DNS и определяет алгоритм ключа и алгоритм MD5/RSA. Защищенный сервер DNS должен возвращать запись KEY как дополнительную информацию при выдаче записей сервера имен (NS), А илн АААА, Запись KEY заверяется записью цифровой подписи (SIG) (см. ниже). Синтаксис записи KEY следующий,
<влапепеи> <ttl> <к”асс> KEY <1024-битовый ключ зонн>
Запись KEY может выглядеть так.
domain.comIN KEY <1024-битовый клюн>
Записи обмена ключей (КХ) (RFC 2230)- информационные
Запись КХ предоставляет механизм делегирования узлу полномочий обменника ключей для других узлов через безопасную DNS. Синтаксис записи КХ следующий.
<домен-а> <ttl> <класс> КХ <предпочтение> <домен-Ь>
Запись КХ может выглядеть так.
eng.domain.com. IN КХ 10 corp.domain.com.
Записи информации о местоположении (LOC) (RFC 1876)
Запись LOC может предоставлять информацию, например широту и долготу, определяющую местоположение сети или узла. Синтаксис записи LOC следующий.
<владелец> <ttl> <кпасс> LOC <широта и ,юлгота> 〈размер〉
Запись LOC может выглядеть так.
host.mydomain.com IN LOC 21 21 N 157 56 W 500m
Записи почтового ящика (MB) (RFC 1035)- экспериментальные
Запись МВ (на данном этапе экспериментальная) первоначально предназначалась для указания на учетные записи почты в домене DNS. Эта запись так и не была реализована, хотя поле <почтовый ящик> в начальной записи зоны (SOA) использует спецификацию формата МВ. Синтаксис записи МВ следующий.
<владелец> <ttl> <класс> МВ 〈доменное имя почтового ящика>
Запись МВ может выглядеть так.
hknief.taos.com. IN MB mailhost.taos.com.
Записи назначения почты (MD) (RFC 1035)- устаревшие
Записи пересылки почты (MF) (RFC 1035)- устаревшие
Записи почтовой группы (MG) (RFC 1035)- экспериментальные
Запись MG (согласно RFC, на данном этапе экспериментальная)— другая запись обработки почты, подобная записи МВ. Запись MG представляет почтовую группу (также известную как список рассылки). Синтаксис записи MG по существу такой же, что и для записи МВ, только для одного владельца почтовой группы перечисляется несколько почтовых ЯЩИКОВ.
<владелец> <ttl> <класс> MG <доменное имя почтовой группы〉
Почтовая группа (список рассылки) может выглядеть так.
sysadmin.taos.com. IN MG hknief.taos.com.
IN MG gtal.taos.com.
IN MG mmasterson.taos.com.
Записи информации почтового ящика (MINFO) (RFC 1035) - экспериментальные
Запись MINFO (на данном этапе экспериментальная) подобна по своей функции псевдонимам 〈список рассылки> и <список рассыл- ки>—ответ во многих про граммах-диспетчерах списков рассылки.
〈ответственный почтовый ящик> — это лицо, ответственное за ведение списка, а <почтовый ящик для ошибок〉— почтовый адрес, на который следует направлять сообщения об ошибках. Формальный синтаксис этой записи следующий.
<владелец> <ttl> <класс> MINF。 〈ответственный почтовый ящик> <почтовый ящик для ошибок:-
В реальном файле зоны запись MINFO может выглядеть так.
sysadmin.taos.com. IM MINFO hknief.taos.com. hknief . taos . coin.
Записи переименования почтового ящика (MR) (RFC 1035) - экспериментальные
Функциональные возможности записи MR (экспериментальной на данном этапе) — эквивалентны возможностям переадресации для почтового псевдонима. Эта запись представляет собой альтернативный почтовый адрес, на которы(1 может быть переслана почта, или для почтовой программы — адрес, который будет переписан в поле "Кому:". Основной синтаксис этой записи следующий.
<владелец> <ttl> <класс> MR <новый почтовый ащпк>
В реальном файле зоны запись М R может выглядеть так.
hknief.Lsi.edu. IN MR hknief.taos.com.
Записи почтового обменника (MX) (RFC 1035)
Записи MX используются почтовыми агентами (МТА), чтобы определить, куда направить почту для данного домена (подробнее об этом см. главу 4). Синтаксис записи MX следующий.
<впадепеи> <ttl> <класс> MX <предпочтение>
<почтовый_обменник.домен.>
Запись MX может выглядеть так.
domain .com IN MX 10 mailhost.domain.coin.
Записи сервера имен (NS) (RFC 1035)
Запись NS служит для делегирования серверов имен для данного домена (подробнее об этом см. главу 4). Синтаксис записи NS следующий.
<владелец> <ttl> <класс> NS 〈доменное имя сервера имен〉
Запись NS может выглядеть так.
root.servers.net IN NS ns.nipte.net.
Записи точки доступа к сетевому сервису (NSAP) (RFC 1348, 1637 и 1706)
Запись NSAP представляет отображение имени DNS на NSAP для протокола сетевого обслуживания без установления соединения (Connectionless Network Protocol, CLNP) системы OSl. Эта запись применяется только для поддержки существующей системы CLNP в Internet. Ее синтаксис следующий.
〈владелец〉 <ttl> <кпасс> NSAP <длина> <адрес NSAP>
Запись NSAP может выглядеть так.
host.domain.core. IN NSAP 21
471025892834000000002344FFFF29342847AB23GD
Записи NSAP-PTR (RFC 1348 - устаревшие)
Записи NSAP-PTR обрабатываются стандартными записями указателя (PTR).'
Записи NULL (RFC 1035) - экспериментальные
Записи NULL экспериментальные и не допускаются в файлах ''главных'1 зон. Онн используются лишь как метки-заполнители в некоторых расширениях DNS. Запись может содержать любые данные нс длиннее 65535 октетов.
Записи несуществования (NXT) (RFC 2535, устаревший RFC 2065)
Запись NXT позволяет серверу имен гарантированно отрицать существование запрашиваемого имени или записи ресурсов. Вместо того, чтобы возвращать простую ошибку "имени не существует", сервер возвра- тает всю известную информацию об известной защите домена наряду с любыми указанными записями ресурсов (NS, SIG, KEY), которые надо запросить на следующем этапе. Синтаксис записей NXT следующий.
<владелец> <ttl> <класс> NXT <домен> RR RR RR
Запись NXT может выглядеть так.
yourdomain.com IN NXT mydomain.com. NS SIG KEY
Записи указателя (PTR) (RFC 1035)
Запись PTR отображает IP-адрес обратно на имя узла (подробнее об этом см. главу 4). Синтаксис записи PTR следующий.
<владелец? <ttl> <класс> PTR <узел.домен.>
Запись PTR может выглядеть так.
1.1.27.10.in-addr.arpa.IN PTR myhost.domain.com.
Записи указателя на X.400 (PX) (RFC 1664)
Запись PX подобна по своей функции записи MX за тем исключением, что она использует отображение адресов Internet доменного стиля (RFC 822) на адреса X.400 (RFC 1327). Синтаксис записи РХ следующий.
<владелец> <ttl> <кпасс> РХ <превпочтение> <адрес по RFC 822> <адрес по RFC 1327>
Запись РХ может выглядеть так.
'.domain com. IN FX 10 domain.com.
PRMD-domain.ADMD-p^ 0 0.C-com.
Записи ответственного лица (RP) (RFC 1183 - экспериментальные)
Запись RP (экспериментальная на данном этапе) позволяет администратору определять средствами DNS, кто отвечает за конкретные машины в сети. Эта возможность может быть полезной или нежелательной, в зависимости от вашей должности и качества работы запрашиваемой машины. Синтаксис записи RP следующий.
<владелец> <ttl> <кпасс> RP <почтовый яцик>
<домен записей ТХТ>
На реальном сервере эта запись может выглядеть так.
www.taos.com. ：N RP hknief.taos.com. txt.taos.com.
txt.taos.com. IN TXT "Help Desk - (408) 588-1296"
Эта запись говорит, что hknief — ответственное лицо; следующая запись текста (TXT) сообщает телефонный номер справочного стола.
Записи промежуточной маршрутизации (RT) (RFC 1183 - экспериментальные)
Запись RT (на данном этапе экспериментальная) напоминает запись типа MX; она предлагает несколько адресов, через которые можно маршрутизировать пакеты. Если узел не подключен к Internet непосредственно, но нуждается в доступе к Telnet, с помошью этих записей RT можно сделать так, чтобы промежуточные узлы действовали как шлюзы для сеанса. С разными значениями предпочтения можно указать альтернативные маршруты, которые будут включаться, если один узел выйдет из строя. Синтаксис этой записи следующий.
<влгделец> <ttl> <класс> RT <предпочтение>
<примежуточный узел>
Запись RT может выглядеть так.
internal.taos.com.IN RT 5 gateway.taos.com.
IN RT 10 bkupgtwy.taos.com.
Записи цифровой подписи (SIG) (RFC 2535, устаревший RFC 2065)
Запись SIG служит для подтверждения подлинности других записей ресурсов на указанный интервал времени с применением методов шифрования и ''личного" ключа подписавшего (см. также запись KEY) .Синтаксис записи SIG следующий.
<владелец> <tи1> <класс> SIG <подписанная запись>
<имя подписавшего
Запись SIG может выглядеть так.
my.domain.сот IN SIG SOA <подпись>
Начальная запись зоны (SOA) (RFC 1035)
Запись SOA идентифицирует авторитетный источник для записей, содержащихся в файле зоны домена (подробнее об этом см. главу 4). Синтаксис записи SOA следующий.
<владелец> <ttl> <к〃асс> SOA <источник зонн> 〈почтовый ящик> (ссерийньй №> 〈интервал обновление〉 〈интервал повтора〉 〈срок действия〉 <m-ttl> )
Запись SOA может выглядеть так.
domain.comIN SOA ns.domain.com root.domain.com
(13600300 21600 1800 )
Записи служб (SRV)
(RFC 2052 - экспериментальные)
Записи SRV (экспериментальные на данном этапе) дают клиентам возможность находить серверы, предлагающие службу определенного типа, не присваивая им специальных имен. Если группа серверов должна оказывать услуги Web, нет необходимости называть их все www или каким-то другим особым именем. Узлы можно идентифицировать как Web- серверы, указав их в записи SRV, Синтаксис записи SRV следующий.
<сиу*6а>.〈протокол〉 <ttl> <класс> 〈приоритет〉 <вес>
<порт> 〈адресат〉
Запись SRV может выглядеть так.
_ldap._tcp IN SRV 00389 adserver.example.net.
ЗаписиТХТ (RFC 1035)
Запись TXT позволяет администратору связать с некоторой записью ресурсов определенную строку текста (см. выше пример с записью RP). Основной синтаксис этой записи имеет следующий вид.
<владелец> <ttl> <класс> ТХТ 〈строка текста〉
В другом примере запись ТХТ дает информацию о местоположении данного узла.
www.taos.com. IN TXT "Santa Clara Office"
Записи известных служб (WKS) (RFC 1035)
Записи WKS позволяют внешним агентам узнать, что некоторые узлы поддерживают определенные службы. Службы связаны с протоколом (TCP или UDP) и типом службы. Протоколы могут быть любые из перечисленных В файле PROTOCOLS (\%systemroot%\system32\drivers\ etc\protocol). Службы могут быть любые с номером порта меньше 256 из указанных в файле SERVICES (\%systemroot%\system32\drivers\ etc\services). Синтаксис записи WKS следующий.
<владелец> vttl> <класс> WKS <адрес> 〈протокол〉 <служба>
Пример записи WKS.
taos.com.taos.com.IN WKSIN WKSIN WKSIN WKSIN WKSIN WKS207.33.46.130207.33.46.135207.33.46.140207.33.46.130207.33.46.135207.33.46.140top telnet upd domain ccp smtptop telnet upd domain ccp smtp
taos.com.
taos.com.
IN WKS
IN WKS
IN WKS
IN WKS
IN WKS
IN WKS
207.33.46.130
207.33.46.135
207.33.46.140
207.33.46.130
207.33.46.135
207.33.46.140
top telnet upd domain ccp smtp
top telnet upd domain ccp smtp
Записи WINS
Записи WINS позволяют внешним агентам узнавать IP-адреса систем, которые могут не иметь своих записей в зонах DNS, а регистрироваться на серверах имен NetBIOS. Запись WINS дает серверу Microsoft DNS возможность запрашивать сервер WINS для разрешения имени NetBIOS в IP-адрес, который и удовлетворяет запрос DNS. Эта запись имеется только на очень ограниченном числе серверов имен и предназначена для работы исключительно в сетевом окружении Windows. Она широко использовалась в конфигурации NT 4.0, но устарела, поскольку Windows 2000 полностью охватывает стандартный набор протоколов TCP/IP.
Синтаксис этой записи имеет следующий вид.
<зладелец> <к”асс> WINS [LOCAL] [Ъ<тай-маут_просмотра>] [С<таймаут_кэширования>] <1Р-адреса WINS>
Пример.
@ IN WINS LOCAL L10 CIO 172.16.77.100
Записи WINS-R
Запись WINS-R по своей функции подобна записи PTR, но разрешает IP-адрес в имя NetBIOS путем вызова функции NetBIOS NBTSTAT. Как и запись WINS, эта запись предназначена для работы только в сетевом окружении Microsoft и с переходом к Windows 2000 постепенно выходит из употребления.
Синтаксис этой записи имеет следующий вид.
<домен владельца〉 IN WINS-R [LOCAL] [Дл<таймаут_просмотра>] [С<таЙ14аут_кэширования>] <дописываемое доменное мм*?>
В большинстве инсталляций DNS на Windows 2000 записи WINS и WINS-R, вероятно, не будут использоваться.
Записи адресации Х.25 (Х25)
(RFC 1183 - экспериментальные)
Запись Х25 (экспериментальная на данном этапе), подобно записи ISDN, обеспечивает адресацию для сетей Х.25. Используемый здесь адрес — это фактически адрес Х.121 для сетей Х.25. Синтаксис этой записи имеет следующий вид.
<владелец> vttl> <класс> Х25 <адрес PSDN>
Запись Х25 может выглядеть так.
rerrQte.taos.com. IN Х25 31547622562
Файл кэша InterNIC
Файл корневого кэша InterNIC автоматически загружается на сервер DNS при инсталляции, причем используется самая последняя копия, полученная Microsoft перед распространением сервера. Имя этого файла — cache . dns.
Изменения в записях корневого кэша случаются редко и обычно почти не влияют на функционирование других серверов DNS. Файл корневого кэша можно также загрузить непосредственно в JnterN 1С через FTP по адресу ftp://rs.internic.net/domain/named.root.
Файл кэша содержит имена и IP-адреса серверов корневого уровня. Для каждого корневого сервера в нем имеется запись NS и, поскольку этого требует архитектура DNS, также запись А. Когда DNS была построена впервые, несколько серверов имен по всей сети были сделаны корневыми серверами имен. Чтобы упростить дело и облегчить узнавание этих важных серверов имен, они были перемешены в домен roct~ servers. net. Для справки в каждой записи приводится также старое имя сервера, которое использовалось до перемещения в домен гоог- servers.net. Оно помогает выяснить фактическое местоположение каждого сервера.
Файл cache. dns содержит следующие записи. ;ранее - NS.INTERNIC.NET
А.ROOT-SERVERS.NET.
3600000 IN NSA.ROOT-SERVERS.NET.
3600000A198.41.0.4
;ранее - NS1.ISI.EDU
3600000NSB.ROOT-SERVERS.NET.
В.ROOT-SERVERS.NET.
3600000A128.9.0.107
;ранее - C.PSI.NET
3600000NSC.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.
3600000A192.33.4 .12
;ранее - TERP.UMD.EDU
3600000NSD.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.
3600000A128.8.10.90
;ранее - NS.NASA.GOV
3600000NSE.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.
3600000A192.203.230.10
;ранее - NS.ISC.ORG
3600000NSF.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.
3600000A192.5.5.241
;ранее - NS.NIC.DDN.MIL
3600000NSG.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.
3600000A192.112.36.4
;ранее - AOS.ARL.ARMY.MIL
H.ROOT-SERVERS.NET.
3600000NSH.ROOT~SERVERS.NET.
3600000A128.63.2.53
;ранее - NIC.NORDU.NET
3600000NSI.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.
3600000A192.36.148.17
; временно размещен на NSI (InterNIC)
J.ROOT-SERVERS.NET.
3600000NSJ.ROOT-SERVERS.NET.
3600000A198.41.0.10
;размещен на LINX, управляется RIPE NCC
К.ROOT-SERVERS.NET.
3600000NSK.ROOT-SERVERS.NET.
3600000A193.0.14.129
；временно размещен на ISI {工ANA}
L. ROOT-SERVERS198.32.64.12L. ROOT-SERVERS198.32.64.12:3600000NS
L. ROOT-SERVERS
198.32.64.12
L. ROOT-SERVERS
198.32.64.12
L.ROOT-SERVERS.NET.3600000A
;размещен в Японии, управляется WIDE
M.ROOT-SERVERS202.12.27.33M.ROOT-SERVERS202.12.27.33.3600000NS
M.ROOT-SERVERS
202.12.27.33
M.ROOT-SERVERS
202.12.27.33
M.ROOT-SERVERS.NET.3600000A
； конец файла
Использование IPv6
В этом приложении...
Здесь кратко опнсано следуюшее поколение набора протоколов для Internet и дано некоторое представление об использовании DNS с этими протоколами. Значимость DNS в ближайшем будущем станет еще очевиднее, особенно для тех, кто не силен в запоминании длинных рядов чисел. Важно обратить внимание на то, что Windows 2000 предоставляет полную поддержку набора протоколов IPv6 и обеспечивает простой механизм для перехода к более новым технологиям.
Что такое IPv6
Для начала проверим, все ли понимают, что такое IPv6. Многие знают (или по крайней, мере слышали) о TCP/IP — наборе протоколов, используемых в Internet для связи. В действительности это два отдельных объекта и только часть общей картины. TCP — это протокол передачи, который обеспечивает ориентированный на соединение механизм надежной передачи данных между приложениями в Internet. TCP "стоит на плечах" протокола IP, который обеспечивает функцион^чьные возможности среды без установления соединения и отвечает за уникальные адреса узлов, которым нужно соединиться друг с другом. Другие протоко-
лы, наряду с TCP и IP, предоставляют дополнительные функииональные возможности. В число этих дополнительных протоколов входят протокол пользовательских дейтаграмм (User Datagram Protocol, UDP), протокол контроля сообщений в Internet (Internet Control Message Protocol, ICMP) и протокол разрешения адресов (Address Resolution Protocol, ARP).
Используемая в настоящее время версия TCP/IP базируется на IP версии 4, или IPv4. По этому дополнению можно догадаться, что должна быть и следующая версия, а именно IP версии 6 (IPv6). IPv6 содержит множество усовершенствований по сравнению с IPv4. Наиболее очевидное различие этих версий — используемые в них адреса. В IPv4 применяется 32-разрядный адрес, обычно представляемый четырьмя октетами в форме aaa.bbb.ccc.ddd. IPv6, в отличие от него, использует 128- разрядные адреса, выражаемые восемью секстетами, напри- мер:1111: аааа : 3333 : bbbb: 5555:eeee：7777:ffff.
Чем отличается IPv6
Теперь, когда обшая концепция IPv6 представлена, проанализируем причины, по которым IPv4 следует заменить на IPv6, и результаты этой замены. В IPv4, с его 32-разрядннм адресом, потенциально можно записать четыре миллиарда различных адресов (2 в 32-й степени = 4294967296), которые должны быть распределены среди всех компьютеров мира. Это число может показаться большим, но при ошеломляющем развитии Internet легко предсказать, что весь запас адресов будет исчерпан примерно к 2005 г. Появление трансляции сетевых Адресов (Network Address Translation. NAT) и использование частного адресного пространства Internet (RFC 1918) несколько уменьшило необходимость в том, чтобы все сетевые адреса были уникальными, но не устранило потребности в расширении адресного пространства. Другие недостатки IPv4 — слабая зашита, низкое качество услуг (Quality of Service, QoS) и недостаточная мобильность.
Возможности IPv6, определенные в RFC 1752, обеспечивают расширенную адресацию и маршрутизацию, маршрутизацию от источника, поддержку динамической адресации в форме DHCP, расширения заголовков, идентификацию, QoS м упрощенный формат заголовка. Сверх того, IPv6 позволяет простой переход к новому набору протоколов. В дополнение к IPv6 была разработана новая версия ICMP (ICMPv6), определенная в RFC 1885, ICMPv6 поддерживает базовые функции оповещения об ошибках при обработке пакетов и диагноза путей, которые выполняет и ICMPv4; кроме того, !CMPv6 также поддерживает функции протокола управления группами Internet (Internet Group Membership Protocol, IGMP), определенные в RFC 1112. Протокол разрешения адреса (ARP) заменен новым протоколом обнаружения соседей (Neighbor Discovery Protocol, NDP), который также выполняет обнаружение маршрутизаторов ICMP и переадресацию ICMP.
Структура адресов IPv6
Как было сказано выше, адреса IPv6 используют 128-разрядную шестнадцатеричную нотацию с разделением двоеточиями. Как и в IPv4, префиксы IPv6 имеют специальное значение и дают представление об использовании и формате адреса IPv6.
Например, адреса IPv6, в которых первые восемь битов равны нулю, зарезервированы в целом. Адреса, которые начинаются префиксом 0000 001 (в двоичном виде), зарезервированы для сетевого протокола доступа к подсети (Network Subnet Access Protocol, NSAP), а адреса, начинающиеся с префикса 0000 010 (в двоичном виде), зарезервированы для протокола межсетевого пакетного обмена (Internet Packet exchange, IPX). Адреса, которые начинаются с префикса 1111 1111 (в двоичном виде), зарезервированы для многоадресного трафика, как и сеть 224.0.0.0 в IPv4. Два особых адреса IPv6 — это адреса 0 ： ： 0 (или просто ： ：) и о ： ： 1 (или просто ： ： 1), в которых : ： — неопределенный адрес. Неопределенный адрес может использоваться для узлов, которые недавно подключены к сети и которым могло быть еше не присвоено значение. Другой особый адрес ； ： 1 соответствует адресу обратной петли (эквивалент 127.0.0.1 В IPv4).
Для облегчения перехода на IPv6 выделено несколько специальных категорий адресов для отображения адресов IPv4 и совместимых с ними. Отображение адресов IPv4 — это те же самые адреса IPv4, помешенные в структуру адреса IPv6. Для узлов IPv6, которые должны общаться с узлами, обладающими только адресами IPv4, адрес IPv4 можно отобразить через шлюз IPv6 следующим образом.
Адрес IPv4 207.33.46.71 (буквально 207.033.04 6.071) будет представлен как 0000:0000:0000:0000:FFFF:2070:3304:6С71 ИЛИ ::FFFF:2070:3304:6071.
Адреса, совместимые с IPv4, используются узлами IPv6, которые должны связываться друг с другом через сеть IPv4. Нотация адресов такая же, как в предыдущем примере, за одним исключением: значение FFFF заменяется на 0000. Таким образом, два узла IPv6 могут проложить "тоннель" через сеть IPv4. Совместимый с IPv6 адрес для предыдущего адреса IPv4 был бы ： ： 2070 ： 3304 : 6071.
Использование IPv6 с DNS
Вы могли бы спросить, какое отношение все это имеет к серверу DNS? Разумеется, при новой схеме адресации должны быть новые записи ресурсов, которые смогут обслуживать новый формат. Для этого введена запись Quad А (АААА) (см. приложение Е), которая обслуживает 128-разрядный адрес для IPv6. Кроме того, специальный домен IP6. INT обслуживает обратный просмотр записей указателя. Обратный про-
смотр — это серьезная проблема; здесь префиксы IPv6 могут не совпадать с четными байтами. Без этого ограничения каждая цифра адреса IPv6 в обратном отображении должна рассматриваться как отдельный и важный объект при поиске в каждой точке. С использованием домена IP6. INT записи указателя предыдущих адресов могут выглядеть так:
7.5.0.0.0.9.6.2.1.0.0.0.4.6.0.0.0.0.0.0.0.0.0.0.о.о.0.0. 0.0.0.0.IP6.INT.
И
6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0. 0.0.0.0.IP6.INT.
Это можно несколько упростить, идентифицируя префикс для адресов и определяя зону для интервала адресов, к которому принадлежат записи указателя. Префикс 一 это фактически эквивалент маски подсети для диапазона присвоенных адресов. Нотация префикса /хх перенесена из бесклассовой междоменной маршрутизации (classless inter-domain routing, CIDR). Следовательно, если сеть имеет префикс /68, результат может выглядеть так.
Сетевой адрес = 234 5:7003:F167：0А41:А000:0000:0000:0С0С/68
Домен 工Р6.工NT = 1.4.0.7.6.1.F.3.0.0.7.5.4.3.2.IF6.INT.
Записи в файле зоны теперь представляются 60-разрядными числами, к которым приписана метка 工P6.INT. Пример:
Адрес IPv6: 2345:7003:F167:А41:А000: :2 68
Запись PTR： .6.2.0.0.0.0.0.0.0.0.0.0.0.0.1.4.0.7.6.1.F,
3.0.0.7.5.4.3.2.工Р6.工NT.
Запись файла зоны для
А.1.4.А.0.7.6.1.F.3.0.0.7.5.4.3.2.工 Р6.工 NT . будет：
8.6.2.0.0.0.0.0.0.0.0.0 IN PTR <узел>
При том, что существенны значение и местоположение каждой цифры, функционирование DNS становится крайне важным. Windows 2000 обеспечивает общую поддержку IPv6 как с целью настройки узла как для работы в сети IPv6, так и для выполнения расширенных требований DNS в окружении IPv6.
Американский реестр номеров Internet (ARIN) уже начал присваивать блоки адресов IPv6, хотя большая часть этих блоков предназначается ис- следовател ьск и м организациям и крупным провайдерам. Это как бы испытатели и, надо надеяться, они более или менее подготовят дорогу для остальных к тому времени, как нам придется также переходить на IPv6. На сегодня главные причины развертывания IPv6 — качество сетевых услуг и повышенная безопасность. Но, как было сказано выше, ''частные" пространства IP и использование NAT значительно замедлили темп исчерпания запаса открыто маршрутизируемых адресов. Наряду с внедрением CIDR это позволяет исправить/или перераспределить очень много открытых адресов. Вообше, мы полагаем, что IPv6 не войдет в повсеместное использование еше в течение примерно двух лет. Дополнительную
Многосетевая адресация серверов DNS
В современном сервере BIND 8 можно настроить предоставление службы DNS очень точно, вплоть до отдельных интерфейсов и портов. В Windows 2000 DNS Server эта возможность отсутствует. В версии Windows 2000 можно задать, предоставлять ли услуги DNS через определенные интерфейсы, с помощью вкладки Интерфейсы диалогового окна Свойства сервера DNS. Эта настройка действует в пределах всего сервера. Иными словами, сервер обеспечивает разрешение всех зон на всех включенных интерфейсах. Другие настройки уровня сервера, например отклонение рекурсивных запросов или использование списка пересылочных узлов, также одинаково используются для всех включенных интерфейсов. В отличие от этого BIND 8 может предоставлять различные услуги разрешения, делая выбранные зоны доступными для определенных интерфейсов или портов.
Отчасти из-за такого ограничения настройка нескольких IP-адресов на одном адаптере обычно не приносит никакой выгоды. Клиенты могут полагать, что они стали более доступными для DNS, но, с другой стороны, это несколько увеличивает нагрузку за счет поддержки стека TCP/IP. Если таким образом используется большое количество IP, общая дополнительная нагрузка может оказаться довольно значительной.
По умолчанию, когда сервер DNS находится на машине с несколькими интерфейсами, он обслуживает все из них, если явно не указано иное. Windows 2000 DNS Server также имеет возможность назначать приоритеты IP-адресов при ответах. Когда приходит запрос о многоадресной машине, сервер DNS может найти несколько записей А, соответствующих запрашиваемому имени. В этой ситуации, если IP распознается и если набор данных, формирующий ответ, соответствует интерфейсу, на котором был принят запрос, сервер DNS может поместить этот IP первым в отправляемом ответе. Если ваш сервер DNS сам не является многосетевым, все запросы принимаются на одном и том же интерфейсе, и, таким образом, многосетевая адресация не дает никакого преимущества, даже если большинство запросов касается разрешения многосетевых машин. Если эта функция не приносит существенного снижения нагрузки в вашей многосетевой системе, ее следует отключить.
Многосетевая адресация в NetBIOS
Хотя это лишь частично касается функций DNS, иногда при работе с многосетевыми машинами требуется уйти от ограничений имен NetBIOS. Поскольку служба WINS работает в комплексе с Windows DNS Server и поэтому до некоторой степени затрагивается в этой книге, следующие сведения могут пригодиться при развертывании сервера DNS. Эта информация в равной степени относится и к последним версиям NT 4, и к системам Windows 2000.
В начале своей истории NT 4 развивала способность обслуживать реальные сети TCP/IP. Когда NT стали включать в более сложные сетевые структуры, неизбежным стало развитие некоторых аспектов службы имен NetBIOS для Net ВТ, называемой WINS. Системные программисты могут немало рассказать о ''приключениях" на пути к существующей WINS.
На сегодняшний день WINS включает групповой (многоадресный) тип регистрации, который позволяет связать с регистрацией имени NetBIOS несколько (до 25) IP-адресов. Однако надо понимать, что реализация NetBIOS в операционной системе связывает имя только с первым IP- адресом на сетевой плате. Подобным образом в WINS регистрируется только этот IP-адрес. С другой стороны, каждая сетевая плата, с которой связан ''клиент WINS'1, регистрирует свой первый IP. Хотя вначале групповая регистрация была довольно ненадежной, после Service Pack 3, когда эти ограничения были учтены, многосетевая адресация машин стала хорошо управляемой. А в NT 4 Service Pack 5 реализация WINS стала функционально эквивалентной WINS в системе Windows 2000.
Тем не менее, Microsoft не рекомендует делать сервер WINS многоадресным даже в Windows 2000. И, вероятно, это целесообразно для любой машины, используемой для служб на базе NetBT, например совместного использования файлов и принтеров, как это делается в низкоуровневых системах. Хотя каждая плата, связанная с NetBT, регистрирует один IP- адрес, скорее всего, никак нельзя установить порядок, в котором они будут связываться. Ввиду того что большинство многоадресных машин имеет несколько интерфейсов для присутствия в нескольких отдельных сетях, а не для увеличения пропускной способности в пределах одной сети, этот случайным порядок, очевидно, может вызвать проблемы. Раньше, в NT 4, это приводило, например, к неустойчивому выбору обозревателя в службе просмотра; поэтому не рекомендовалось делать в NT 4 многоадресными основные контроллеры домена, чтобы они гарантированно сохраняли роль главного обозревателя домена (DMB). Лучшей рекомендацией было не связывать NetBIOS с несколькими адаптерами на машинах, обеспечивающих критические службы на базе NetBIOS.