DNS-сервер

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Государственное образовательное учреждение высшего профессионального образования

Курсовая работа

по дисциплине: Операционные системы, среды и оболочки

тема: DNS-сервер

2011



Введение

Компьютеры в сети общаются между собой, используя IP-адреса -- числовые имена, имеющие такой вид: 217.107.217.21. IP-адрес можно сравнить с номером телефона -- чтобы один компьютер мог обратиться к другому, ему необходимо знать его IP-адрес. Однако у IP-адресов есть два недостатка: во-первых, их существует лишь ограниченное количество (что нам сейчас не очень важно), а во-вторых, что важнее, IP-адрес очень трудно запомнить человеку. Продолжая аналогию с телефонными номерами, помните ли вы номера телефонов всех своих друзей и знакомых? Вероятно, нет. Но вы всегда можете воспользоваться записной книжкой.

В интернете роль записной книжки играет DNS -- Domain Name System, система доменных имен. Каждый сайт в сети имеет свое доменное имя (например, www.tpu.ru), которое система DNS связывает с IP-адресом сервера -- компьютера, на котором расположен этот сайт. И когда в адресной строке браузера вы вводите какой-либо домен, он автоматически преобразовывается в IP-адрес, и уже используя его, ваш компьютер связывается с сервером.

В данной работе будут рассмотрены следующие вопросы: конфигурация DNS (структура DNS и использование DNS для разрешения имен, интеграция DNS с Active Directory, планирование и администрирование DNS.



1. Служба DNS

Domain Name System (система доменных имен) - это стандарт службы имен для Интернета, который используется для помощи клиентам в разрешении имен узлов в их IP-адреса и для поиска служб в сети.

DNS - это распределенная система серверов имен. В этой системе группы серверов имен отвечают за записи, относящиеся к узлам, в доменах и поддоменах. Эти группы называются зонами. Зона является полномочной или ответственной для записей, относящихся к данному домену или группе доменов. Например, Microsoft может иметь несколько серверов, полномочных для домена microsoft.com и все связанные поддомены должны быть частью этого домена. Как следствие, если эти сервера не могут предоставить вам ответ на запрос IP-адреса для имени bluscreen.microsoft.com, то это означает, что его просто не существует.

Серверы имен хранят то, что принято называть записями ресурсов. Записи ресурсов сопоставляют имя узла его IP-адресу или отдельной службы и имени узла. Например, сервер DNS может содержать запись (называемую А записью) для сервера, называемого Cerver2, которому соответствует IP-адрес 147.2.3.45. Если клиент другого сервера DNS запросит связанный IP-адрес, он может быть найден и возвращен (послан) клиенту. Подобным образом, некоторый почтовый сервер может запросить сервер DNS найти почтовый сервер, действующий в домене mailfirma.ru. В данном случае DNS сервер запрашивается на наличие записи о системе обмена почтой (запись МХ), которая предоставляет FGDN (полностью определенное имя домена) почтового сервера, которое, в свою очередь, может быть разрешено в IP-адрес.

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

Число серверов DNS, присутствующих в сети зависит от ряда факторов, таких, как потребность в отказоустойчивости, быстродействие и т.д.

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

1.1 Базовая конфигурация DNS

Установка конфигурации DNS предполагает решение двух задач: настройка сервера DNS (в пакете BIND функции сервера выполняет программа named) и администрирование домена. В данной работе рассмотрим особенности выполнения первой задачи. При настройке сервера DNS устанавливаются основные опции, указывается расположение других серверов DNS (в частности, серверов корневого домена) и задается информация о поддерживаемых зонах. Даже для небольшого домена необходим вторичный (ведомый) сервер имен. В принципе вы можете установить конфигурацию вторичного сервера, скопировав содержимое соответствующих файлов, созданных для локального сервера, но гораздо лучше настроить вторичный сервер так, чтобы от автоматически дублировал параметры первичного сервера.

Главный конфигурационный файл - BIND. Основные опции BIND задаются в главном конфигурационном файле с именем named. conf. Этот файл обычно располагается в каталоге /etc. В некоторых дистрибутивных пакетах Linux файл с опциями, установленными по умолчанию, в каталоге /etc отсутствует. В этом случае файл-образец надо искать в каталоге, содержащем документацию BIND (обычно это каталог /usr/share/doc/bind-версия).

Пример файла named, conf

options {

directory "/var/named/"; auth-nxdomain yes; forwarders {

10.232.7.98;

10.232.45.1; );

forward first;

};

zone " . " {

type hint;

file "named.ca";

);

zone "threeroomco.com" {

type master;

file "named.threeroomco.com"; };

zone "1.168.192.in-addr.arpa"{

type master;

434 _ Часть III. Серверы Internet

file "named.192.168.1"; };

zone "0. 0.127.in-addr.arpa" {

type master;

file "named.local"; };

Файл named, conf состоит из нескольких разделов. Раздел options содержит определения глобальных опций, в частности, в нем задается каталог, в котором содержатся файлы с описанием зоны. Разделы zone описывают конкретные зоны - домены либо другие группы имен или IP-адресов. Большинство строк, содержащихся в файле named, conf, оканчиваются точкой с запятой (;). Это требование надо выполнять, в противном случае BIND может некорректно интерпретировать содержимое конфигурационного файла. В основном содержимое файла named. conf представляет собой указатели на файлы, в которых находятся дополнительные сведения о зонах. Эти файлы содержатся в каталоге /var/named либо в другом каталоге, заданном с помощью опции directory.

Одна из основных задач, которые вам предстоит решить при инсталляции сервера DNS, - получить список корневых серверов. Сделать это можно несколькими способами. - Требуемый файл может входить в поставку пакета BIND. Обычно он называется named, са или db.cache и располагается в каталоге /var/named. Если содержимое этого файла устарело, вы можете получить новый файл одним из двух описанных ниже способов. - Файл named, са, содержащий список корневых серверов, можно скопировать посредством протокола FTP, обратившись по адресу ftp://ftp.rs . internic. net/domain/. - Если в вашей системе установлена программа dig, вы можете задать команду dig @a. root-servers.net . ns > named, са. Эта команда копирует файл, содержащий список корневых серверов, и присваивает ему имя named. са. Чтобы вы могли воспользоваться вторым или третьим из описанных выше способов, в вашей сети должен работать сервер DNS. Если сервер DNS в сети отсутствует, вы можете скопировать нужный файл, воспользовавшись компьютером другой сети, либо временно настроить компьютер, на котором должен быть установлен сервер DNS для преобразования посредством внешнего сервера имен.

Получив файл со списком корневых серверов, скопируйте его в каталог /var/named. Кроме того, вам следует убедиться в том, что ссылка на этот файл присутствует в конфигурационном файле /etc/named, conf.

BIND осуществляет преобразование имен одним из трех описанных ниже способов: 1. Если пакет BIND настроен для поддержки запрошенного имени, сервер возвращает адрес, указанный в его конфигурационном файле; 2. Если запрашиваемый адрес находится в кэше, сервер возвращает его. В этом случае повышается быстродействие и снижается нагрузка на сеть; 3. Если требуемый адрес в кэше отсутствует, сервер передает запрос корневому серверу и другим серверам. Типичная процедура преобразования имен была рассмотрена выше. Для выполнения преобразования требуется лишь несколько секунд, но чтение из кэша осуществляется гораздо быстрее.

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

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

Перенаправление запросов задается с помощью опций forwarders и forward. Опция forwarders позволяет задать один или несколько IP-адресов серверов DNS, к которым локальный сервер станет обращаться перед тем, как начать выполнение стандартной процедуры преобразования адресов. Опция forward допускает одно из двух значений: only или first. Если вы зададите forward only, BIND при работе будет полагаться лишь на удаленный сервер DNS, указанный с помощью опции forwarders, и не будет выполнять стандартную процедуру преобразования имен. Значение first опции forward указывает на то, что BIND должен сначала обратиться к удаленному серверу DNS, а если такое обращение не дало результатов (например, если удаленный сервер не ответил на запрос), он должен осуществить преобразование имен по стандартному алгоритму. В любом случае, если к серверу поступит запрос на преобразование имен, которые принадлежат зоне, обслуживаемой данным сервером, он будет использовать описание зоны в своем конфигурационном файле.



2. DNS для разрешения имен

Доменное имя состоит, по меньшей мере, из двух частей (меток), разделенных точками. Нумерация меток ведется справа налево. Если объяснить на конкретном примере, то в адресе hosting.web-3.ru суффикс ru является доменом первого уровня. Все последующие метки - поддомены, т.е. hosting - поддомен домена web-3, а web-3 - домена ru. Условно подобное деление может растянуться на 127 уровней. Любая метка может состоять (максимально) из 63 символов, но длина доменного имени не может быть больше 254 знаков, включая точки. Впрочем, действительность и теория, как известно, - разные вещи, посему регистраторы доменов часто устанавливают собственные лимиты. Серверы DNS находятся в определенном порядке, который организует иерархическая система DNS. Всякий поддомен или домен поддерживается несколькими авторизованными серверами DNS, содержащими о нем все необходимые сведения. Следует сказать, что наблюдается тождество соподчинения доменов и серверов DNS.

Система DNS работает следующим образом: Пользователь набирает в web-обозревателе адрес hosting.web-3.ru. Для передачи данных посредством стека протоколов TCP/IP необходимо знать IP-адрес указанного сервера, но тот, как правило, имеет лишь сведения об адресе сервера DNS (обычно интернет-провайдер предоставляет адрес одного основного и одного резервного DNS-сервера). В результате запрос об IP-адресе hosting.web-3.ru задается указанному DNS серверу. Тот, в свою очередь, запрашивает информацию у центрального сервера, например 195.42.0.3 (все IP-адреса приведены в качестве примера и могут отличаться от действительных). Сервер отвечает, что не обладает информацией о требуемом адресе, однако, знает, что доменной зоной .ru занимается сервер 214.74.142.1. В этом случае сервер DNS запрашивает информацию у 214.74.142.1. Ответом может быть: «web-3.ru занимается сервер 247.142.130.234». Этот третий по счету сервер возвращает браузеру IP-адрес нужного сайта. Очень часто рекурсивный подход заменяется запросами к буферу сервера. Если неавторитетный сервер недавно получал запрос на IP адрес hosting.web-3.ru, то вместо обращения к следующему DNS серверу он выдаст результат из буфера. Для реагирования на запрашиваемую информацию DNS-протокол применяет UDP- или TCP-порт 53. Обычно запросы и готовая информация по ним посылаются в форме UDP-датаграммы. А TCP остается для AXFR-запросов или ответов весом более 512 байт. Важно помнить, что IP-адрес не равен имени хоста и наоборот. Один компьютер может иметь большое количество web-сайтов, а это говорит о возможности хоста с определенным IP-адресом владеть целым списком имен. Подобно этому одно иметь может быть соотнесено с разными хостами. Так достигается регуляция нагрузки. С целью увеличения стабильности системы в работу вводят определенное число серверов, которые вмещают в себя одинаковые сведения. Так, в мире насчитывается 13 подобных серверов. Каждый имеет отношение к какой-либо территории. Данные о них имеются во всякой операционной системе, поскольку такие серверы не изменяют первоначального адреса. Эти сервер называют корневыми, потому что на них держится вся сеть Интернет. Теперь поговорим об обратном DNS-запросе. Помимо перекодировки символьных имен в IP-адреса DNS выполняет обратную работу. Поскольку с записями DNS можно соотнести данные разных форматов, включая символьные. Известно доменное имя in-addr.arpa, данные которого служат для реконструирования IP-адреса в имя из символов. Приведем пример: чтобы выяснить имя известного адреса (предположим, 12.13.14.15) допустимо сделать запрос в следующем виде: 51.41.31.21.in-addr.arpa. Результатом окажется должное символьное имя. Чем можно это объяснить? Тем, что в IP-адресах биты, расположенные у корня, стоят в начале, а в DNS-именах - в конце. Что касается записей DNS, то выделяют несколько категорий:

Address record (запись А) служит для связи адреса IP и хоста.

Canonical name record (сокращенно CNAME, каноническая запись имени) - инструмент переадресации на альтернативное имя.

Mail exchange (МХ, почтовый обменник) ссылается на сервер обмена почтой для представленного домена.

PTR (pointer, или запись указателя) соединяет имя хоста с его установленным (каноническим) именем.

NS (name server) называет DNS-сервер представленного доменного имени.

SOA (start of authority record) - запись, ссылающаяся на тот сервер, который содержит стандартные сведения о представленном домене.

Необходимо сказать о зарезервированных доменах (Reserved Top Level DNS Names). Документ RFC 2606 указывает на те имена доменов, которые нужно применять в роли модели (что особенно важно в документации) и при тестировании. В качестве примера можно привести test.com, test.org, test.net, а также invalid, example и т.д. В разговоре о доменных именах стоит упомянуть о том, что они могут состоять из небольшой комплектации ASCII символов. Это делает возможным набор доменного адреса вне зависимости от того языка, на котором говорит пользователь. Потому такие имена - интернациональные. ICANN ратифицировал систему IDNA, базирующуюся на Punycode. Она способна конвертировать всякую фразу в кодировке Unicode в тот набор знаков, который будет возможен для корректной работы DNS.Некоторые способы действия приложения DNS применяются в BIND (Berkeley Internet Name Domain), MaraDNS NSD (Name Server Daemon), DJBDNS (Daniel J. Bernstein's DNS), PowerDNS Microsoft DNS Server (в серверных вариантах операционных систем Windows NT). Чтобы узнать, кто владеет каким-либо доменом или IP-адресом достаточно использовать возможности сетевого протокола whois. Первоначальной идеей, положившей начало созданию данной системы, было стремление не позволять системным администраторам находить данные иных администраторов IP-адресов и доменов. Ныне доменное имя признается незарегистрированным на определенное имя, пока нельзя найти общедоступные сведения о нем в этом сервисе.

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

Да, интернет-сервисы могут располагаться не только на специально выделенных для этого серверах, но и на домашних компьютерах. На таком компьютере может размещаться сайт, каталог файлов или картинок, почтовый или игровой сервер. Но если ваш IP-адрес будет динамическим, то при каждом подключении к Сети вам нужно будет посылать его своим постоянным посетителям, чтобы они могли попасть на ваш сайт. К тому же, подключаться к сайту им придется по IP-адресу, а не по его названию. Что делать, чтобы избежать подобной проблемы?

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

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

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

Рассмотрим, какие услуги и возможности предлагают DDNS-сервисы. Возьмем, к примеру, сервис Dynu.com:

1) Поддержка доменов

2) Бесплатный сервис обеспечивает поддержку поддоменов в доменах dynu.com и dynu.net. Домены в зонах *.com, *.net, *.biz, *.co.jp, *.de и других поддерживаются в платном сервисе.

3) Динамическое обновление IP-адресов

4) Клиентская часть сервиса есть для таких платформ, как Windows 9x/NT/2000/XP, Mac OS, Mac OS X, Linux, FreeBSD, Solaris, Unix.

5) Поддержка поддоменов (алиасов) зарегистрированного домена

6) Бесплатный сервис обеспечивает поддержку таких алиасов, как ftp, mail, www и иных, привязанных к одному и тому же адресу. А платный сервис позволяет связывать любые поддомены с различными IP-адресами (например, если ваш веб-сервер и почтовый сервер размещены на различных компьютерах, имеющих раздельное подключение к Интернету).

7) Поддержка протокола SSL

8) Перенаправление HTTP-порта

9) Позволяет перенастроить стандартный HTTP-порт (80) на любой другой. Ваш веб-сервер, соответственно, должен быть настроен на нужный порт.

10) Онлайн-перенаправление

11) Распределение нагрузки на сервер.

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

Другим популярным сервисом считается DNS2Go. Большинство предоставляемых услуг являются бесплатными. По своей функциональности сервис очень близок к сервису Dynu.com, а вот бесплатных возможностей дает несколько больше. Но, к примеру, получить домен второго уровня на этом сервисе можно только на платной основе. Кроме уже перечисленных возможностей, DNS2Go предоставляет услуги по перенаправлению электронной почты (услуга - платная). Она включает защиту от вирусов и спама, перенаправление почты, пересылку на иной адрес, хостинг почтового сервера. Услуга может быть полезной тем, кто не может держать установленный на домашнем компьютере почтовый сервер, постоянно подключенный к Интернету.

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

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

доменный имя сервер конфигурация

2.1 Интеграция DNS с Active Directiry

Служба DNS-сервер интегрирована в структуру и реализацию службы каталогов Active Directory. Служба каталогов Active Directory является инструментом организации, управления и расположения ресурсов в сети на уровне предприятия.

При установке Active Directory на сервер выполняется повышение сервера до роли контроллера указанного домена. Когда данный процесс завершается, пользователю выводится приглашение указать доменное имя DNS для домена Active Directory, для которого выполняется присоединение и повышение сервера.

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

После установки Active Directory имеются две возможности сохранения и репликации зон при работе с DNS-сервером на новом контроллере домена:

1) Стандартное сохранение зоны с помощью файла в текстовом формате.

Зоны, сохраняемые в этом способе, размещаются в файлах с раширением DNS, которые сохраняются в папке системный_корневой_каталог\System32\Dns на каждом компьютере, на котором выполняется DNS-сервер. Имя файла зоны соответствует имени, которое пользователь выбрал для зоны при ее создании, например, еxample.microsoft.com.dns, если именем зоны является «example.microsoft.com».

2) Сохранение зон, интегрированных в службу каталогов, с помощью базы данных Active Directory. Зоны, сохраняемые таким образом, размещаются в дереве Active Directory под разделом каталога домена или приложения. Каждая зона, интегрированная в службу каталогов, сохраняется в контейнере dnsZone, который идентифицируется по имени, выбранному пользователем при ее создании.

2.2 Преимущества интеграции с Active Directory

В сетях с развертыванием DNS для поддержки службы каталогов Active Directory настоятельно рекомендуется использовать основные зоны, интегрированные в службу каталогов, которые предоставляют следующие преимущества.

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

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

За счет сохранения баз данных зон DNS в Active Directory имеется возможность рационализировать репликацию баз данных в сети. Когда пространство имен DNS и домены Active Directory сохраняются и реплицируются независимо, необходимо обеспечить планирование и администрирование каждого из них в отдельности. Например, при одновременном использовании стандартного сохранения зон DNS и службы каталогов Active Directory необходимо обеспечить структуру, реализацию, тестирование и управление для двух различных топологий репликации баз данных. Одна топология требуется для репликации данных из каталогов между контроллерами домена, а другая топология может потребоваться для репликации баз данных зон между DNS-серверами. Это приведет к дополнительным трудностям при планировании и разработке структуры сети с учетом ее естественного роста. За счет интеграции сохранения информации DNS появляется возможность унифицировать вопросы управления и репликации для DNS и Active Directory, объединяя их в единое административное целое.

Репликация каталогов выполняется быстрее и эффективнее, чем стандартная репликация DNS. Поскольку репликация Active Directory выполняется на уровне отдельных свойств, распространяются только необходимые изменения. При этом для зон, интегрированных в службу каталогов, используется и отправляется меньший объем данных.

Active Directory может использовать любую стандартную, законченную реализацию службы DNS. Для примера можно задействовать DNS-сервер, входящий в Windows 2000 Server, поскольку его модули согласованы друг с другом (хранение и репликация зон и т. п.), ведь необходимо, чтобы выбранный DNS-сервер соответствовал последним стандартам. Например, для Active Directory нужен DNS-сервер, поддерживающий записи типа SRV. Записи подобного типа (SRV records), в соответствии с RFC 2052, позволяют клиентам находить нужные сетевые службы. В Active Directory служба LDAP каждого домена Windows 2000 представлена некоторой SRV-записью службы DNS. Такая запись содержит DNS-имя контроллера этого домена, по которому клиенты Active Directory могут находить IP-адрес компьютера-контроллера домена. После того как нужный контроллер обнаружен, для доступа к данным Active Directory, хранящихся на нем, клиент может использовать протокол LDAP.

Windows 2000 Server поддерживает также службу динамического именования хостов, Dynamic DNS. В соответствии с RFC 2136 служба Dynamic DNS расширяет протокол DNS, позволяя модифицировать базу данных DNS со стороны удаленных систем. Например, при подключении некоторый контроллер домена может сам добавлять SRV-запись для себя, освобождая администратора от такой необходимости.

Следует добавить, что DNS-сервер, используемый вместе с Active Directory, должен лишь поддерживать SRV-записи и символы подчеркивания в именах, наличие Dynamic DNS не строго обязательно: такое требование только облегчает работу с сетью. Этот факт очень важен при развертывании Windows 2000 в гетерогенных сетях, где имеются DNS-серверы на других платформах.

Таким образом, мы можем отметить для себя несколько преимуществ использования зон DNS, которые интегрированы с Active Directory:

Интегрированные зоны позволяют выполнять безопасные обновления. То есть, если зона DNS интегрирована в AD DS, то в ней вы можете настроить только использование безопасных обновлений, тем самым обеспечив возможность управления пользователями и компьютерами организации, которые могут обновлять записи ресурсов в Active Directory;

Процесс передачи зон заменяется репликацией доменных служб Active Directory. В связи с тем, что информация зон сохраняется не в текстовый файл, а в Active Directory, репликация таких данных выполняется посредствам стандартного процесса репликации доменных служб Active Directory. То есть, сама репликация выполняется на уровне атрибутов и касается лишь изменений данных зоны, тем самым экономя полосу пропускания и, соответственно, сжимая ваш трафик;

Интегрированные зоны обеспечивают дополнительную безопасность. Так как зоны DNS сохраняются непосредственно в Active Directory, для защиты объекта dnsZone в каталоге используются списки контроля доступа, обеспечивая гранулированный доступ к зоне;

Интегрированные зоны позволяют создавать для серверов DNS конфигурацию Multi-Master. С использованием зон, интегрированных в Active Directory, каждый DNS-сервер получает копию информации домена с правом записи, чтобы изменения данных зоны можно было вносить во всех организациях, что нельзя реализовать с серверами DNS без AD DS.



3. Планирование и администрирование DNS

3.1 Планирование

После того как для каждой модели будут выбраны домены Active Directory, вам необходимо спроектировать инфраструктуру DNS, так как каждое доменное имя является частью именного пространства DNS. Полагаю, что вам не нужно объяснять, что для локализации ресурсов в сети доменных служб Active Directory используется система доменных имен (Domain Name System, DNS), так как службы Active Directory не могут функционировать без стабильной конфигурации DNS. По сути, DNS является распределенной базой данных, которая предоставляет пространство имен и которая хранит все сведения, необходимые для того, чтобы любой пользователь организации мог свободно подключаться к компьютерам и другим IP-сетям, используя понятные и легко запоминающиеся имена. Без ее стабильной инфраструктуры у доменных служб не будет возможности выполнять репликацию среди контроллеров домена в сети, а такие серверы, как Microsoft Exchange Server не смогут отправлять электронную почту. Поэтому можно сделать такой вывод, что проектирование инфраструктуры DNS является не менее важным этапом эффективного построения доменных служб в организации, причем, ключевым моментом является определение, где нужно локализовать домены Active Directory в текущем именном пространстве. Именно благодаря службе разрешения имен DNS, доменные службы Active Directory предоставляют для пользователей возможность без проблем находить все контроллеры доменов, а также контроллерам доменов обмениваться друг с другом сведениями. В большинстве случаев проект пространство имен для Active Directory разрабатывается проектировщиком службы каталогов совместно хозяином DNS. Сразу хотелось бы отметить, что большинство организаций имеют одно именное пространство как внутри организации Active Directory, так и в Интернете, и в итоге, в Интернете регистрируется лишь одно DNS-имя. Желательно, чтобы такие имена существовали отдельно от зарегистрированного доменного имени организации.

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

Рассмотрим несколько вариантов.

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

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

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

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

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

Во втором случае, при проектировании инфраструктуры DNS для Active Directory, вы можете вынести домены AD DS дочерними доменами существующего внутреннего пространства имен, тем самым не затронув имеющуюся инфраструктуру. То есть, в случае существующего именного пространства Biopharmaceutics.com, вы можете создать дочерний домен corp. Biopharmaceutics.com.

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

В процессе создания конфигурации DNS-сервера необходимо выполнить следующие действия:

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

Настроить контроллер корневого домена Active Directory так, чтобы он содержал зону DNS леса Active Directory;

В случае необходимости, настроить все региональные контроллеры домена так, чтобы они содержали зоны DNS, соответствующие доменам контроллеров доменов Active Directory;

Для корректной настройки службы DNS на клиентских компьютерах, вам, как владельцу службы DNS доменных служб Active Directory, нужно указать схему именования компьютеров, а также способ поиска DNS-серверов для клиентов. Лучше всего использовать стандартную схему именования клиентских компьютеров, то есть полное доменное имя FQDN должно состоять из имени узла компьютера и имени домена AD. Также необходимо настроить клиентские компьютеры так, чтобы они указывали на все DNS-сервера, которые есть в сети.

3.2 Администрирование DNS

Ниже приведены рекомендации по обеспечению бесперебойной работы при администрировании службы доменных имен (DNS).

1) Настройка DNS-сервера на использование статического IP-адреса.

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

2) Необходимо соблюдать осторожность при добавлении записей ресурсов псевдонима в зоны. Лучше избегать использования записей ресурсов псевдонима (CNAME) для сопоставления имен узлов, которые используются в записях ресурсов узла (A), там, где они не требуются. Также следует убедиться, что используемые имена-псевдонимы не задействованы в других записях ресурсов.

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

4) При применении доменных служб Active Directory в целях повышения уровня безопасности, обеспечения отказоустойчивости, а также упрощения развертывания и управления следует использовать для зон DNS хранилище, интегрированное в службу каталогов. Интеграция зон DNS в доменные службы Active Directory позволяет упростить планирование сети. Например, при использовании интегрированных в Active Directory зон DNS контроллеры доменов для каждого из доменов Active Directory напрямую соответствуют своим DNS-серверам. Это позволяет упростить планирование и облегчить устранение неполадок, связанных с DNS и репликацией Active Directory, так как в обеих топологиях используются одни и те же серверы. Если для зон используется хранилище, интегрированное в службу каталогов, можно выбирать различные области репликации, которые реплицируют данные зоны DNS по всему каталогу. Можно выбрать области репликации, реплицирующие данные зоны DNS на все DNS-серверы в лесу Active Directory, на все DNS-серверы в указанном домене Active Directory или на все контроллеры домена, указанные в настраиваемой области репликации. Любой DNS-сервер, размещающий зону, интегрированную в службу каталогов, является основным DNS-сервером для этой зоны. Это позволяет использовать модель с несколькими хозяевами, в рамках которой обновлять одни и те же данные зоны могут несколько DNS-серверов. Использование модели с несколькими хозяевами исключает проблему, возникающую в обычной топологии с одним главным DNS-сервером, когда только один DNS-сервер может обновлять данные для указанной зоны. Одним из важных преимуществ интеграции в каталог является поддержка безопасных динамических обновлений имен в пределах зоны.

5) Введите правильный адрес электронной почты лица, ответственного за каждую добавленную и управляемую зону на DNS-сервере. Приложения используют это поле в начальной записи зоны (SOA) для оповещения администраторов DNS по ряду причин. Например, это поле может использоваться при возникновении ошибок запроса, возврате неверных данных в запросе, а также при появлении проблем с безопасностью. Хотя обычно адрес электронной почты в программах электронной почты содержит символ «@», при вводе электронного адреса в этом поле данный символ необходимо заменить на точку (.). Например, вместо administrator@microsoft.com следует использовать запись administrator.microsoft.com.

3.2.1 Добавление DNS-сервера

При установке DNS с доменными службами Active Directory мастер установки доменных служб Active Directory (Dcpromo.exe), используемый для установки контроллера домена, автоматически устанавливает и настраивает локальный DNS-сервер. Мастер устанавливает службу DNS-сервера на тот компьютер, где он запущен, и настраивает параметр предпочитаемого DNS-сервера компьютера на использование нового локального DNS-сервера. Необходимо настроить другие компьютеры, которые будут присоединяться к этому домену, на использование IP-адреса этого сервера в качестве предпочитаемого DNS-сервера. Перед запуском мастера установки доменных служб Active Directory рекомендуется вручную настроить использование статического IP-адреса на компьютере. Если DNS-сервер настроен на использование динамических адресов, назначаемых с помощью DHCP, при назначении DHCP-сервером нового IP-адреса для DNS-сервера DNS-клиенты, в параметрах которых указан предыдущий IP-адрес DNS-сервера, не смогут разрешить предыдущий IP-адрес и найти DNS-сервер.

3.2.2 Удаление DNS-сервера

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

1. Удаление записи ресурса. Данная процедура используется для удаления записи ресурса узла (A) для указанного сервера.

2. Изменение существующей записи ресурса. Данная процедура используется для обновления записей ресурсов сервера имен (NS) в зонах, где данный сервер является заслуживающим доверия, для исключения сервера по имени (в виде, в котором оно присутствовало в записи ресурса узла (А), которая была удалена в процедуре 1).

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

4. Проверка делегирования зоны. Данная процедура используется для проверки родительской зоны, чтобы убедиться, что все записи ресурса (сервера имен (NS) или записи ресурсов узла (А)), используемые для делегирования в зону, изменены и не указывают на удаленный сервер.

5. Удаление DNS-сервера из раздела каталога приложений DNS. Данная процедура используется для удаления DNS-сервера, если он был указан в разделе каталога приложений DNS.

3.2.3 Управление DNS-сервером

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

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

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

3) Работа с корневыми ссылками для обеспечения получения сведений и обнаружения службой DNS заслуживающих доверия серверов, управляющих доменами, расположенными на более высоком уровне или в других поддеревьях пространства имен домена DNS. Корневые ссылки -- это данные DNS, хранящиеся на DNS-сервере, который определяет заслуживающие доверия DNS-серверы для корневой зоны пространства имен DNS. Корневые ссылки можно использовать для настройки заслуживающих доверия серверов для некорневых зон, чтобы они могли обнаруживать заслуживающие доверия серверы, размещающие более высокоуровневые домены или домены в других поддеревьях пространства имен домена DNS. Эти корневые ссылки необходимы для заслуживающих доверия серверов, расположенных на более низких уровнях пространства имен, когда эти серверы пытаются найти другие серверы при этих условиях. По умолчанию служба DNS-сервера настраивается со стандартным набором корневых ссылок. Набор корневых ссылок по умолчанию содержит записи ресурсов сервера имен (NS) и узла (A) для корневых серверов в Интернете. Тем не менее, если служба DNS-сервера используется в частной сети, можно заменить корневые ссылки по умолчанию записями, которые будут указывать на внутренние корневые DNS-серверы. Если DNS-сервер настроен на доступ к другим DNS-серверам, например, по списку DNS-серверов, настроенному в его клиентских свойствах TCP/IP для установленного сетевого подключения, то служба DNS-сервера может собирать корневые ссылки самостоятельно во время настройки нового сервера. Для выполнения этой задачи можно использовать мастер настройки DNS-сервера.