Лабораторная работа 6.3
	Установка и настройка сервера DNS

• аппаратные: компьютер с установленной ОС Windows XP.
• программные: приложение ВМ: VirtualBox; виртуальные машины: VM-1, VM-2; установочные образы ОС: win98.iso.

Теоретические сведения

Система доменных имен (DNS) была исходно определена в документах RFC (Request for Comments) 1034 и 1035. Эти документы определяют следующие элементы, общие для всех реализаций программного обеспечения DNS.

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

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

Рисунок 1. Пространство доменных имен.

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

Тип имени	Описание	Пример
Корень доменов	Вершина дерева, представляющая неименованный уровень, иногда обозначается парой прямых кавычек (""), указывающих пустое значение. При использовании в доменном имени DNS для этого применяется завершающая точка (.), свидетельствующая, что имя расположено в корне или на самом верхнем уровне иерархии доменов. В данном случае доменное имя DNS рассматривается как полное и указывает на точное расположение в дереве имен. Имена, установленные таким способом, называют полными доменными именами (Fully Qualified Domain Name, FQDN).	Единственная точка (.) или точка, использованная в конце имени, например, «example.microsoft.com.»
Домен верхнего уровня	Имя из двух или трех букв, которое используется, чтобы указать страну/регион или тип организации.	«.ru» указывает имя, зарегистрированное для коммерческого использования в Интернете.
Домен второго уровня	Имена переменной длины, зарегистрированные для индивидуальных пользователей или организаций для использования в Интернете. Эти имена всегда базируются на соответствующем домене верхнего уровня в зависимости от типа организации или географического расположения, в котором используется имя.	«edu.ru.» является именем домена второго уровня, зарегистрированным для образовательных учреждений регистратором доменных имен DNS Интернета.
Поддомен	Дополнительные имена, которые организация может создавать как производные от зарегистрированного имени домена второго уровня. Такие имена обеспечивают рост дерева имен DNS в организации и его распределение по отделам или по географическому расположению.	«mspu.edu.ru» представляет имя поддомена Мурманского государственного педагогического университета.
Имя узла или ресурса	Имя, представляющее лист в дереве имен DNS, которое определяет конкретный ресурс. Обычно крайняя левая метка в доменном имени DNS определяет конкретный компьютер в сети. Например, имя этого уровня, используемое в записи ресурса узла (A), используется для поиска IP-адреса компьютера по его имени узла.	«host-a.mspu.edu.ru.», где первая метка («host-a») представляет имя узла DNS для конкретного компьютера в сети.

Например, доменное имя DNS, зарегистрированное для образовательных учреждений (edu.ru.), представляет домен второго уровня. Это имя состоит из двух частей (называемых метками), показывающих, что оно находится на втором уровне сверху от корня или вершины дерева. Большинство доменных имен DNS содержат две или большее число меток, каждая из которых задает новый уровень в дереве. Точки используются в именах для разделения меток.

DNS представляет способ интерпретации полного пути к доменному имени DNS аналогично способу интерпретации полного пути к файлу или каталогу в окне командной строки. Например, путь в дереве каталогов помогает указать на точное расположение файла, сохраненного на компьютере. Для компьютеров с операционной системой Windows обратная косая черта (\) указывает каждый новый каталог, ведущий к точному расположению файла. Эквивалентным символом в DNS является точка (.), указывающая каждый новый уровень домена в имени. Для DNS примером имени с несколькими уровнями может служить следующее полное доменное имя узла: host-a.mspu.edu.ru. В отличие от имен файлов, при чтении полного доменного имени узла DNS слева направо осуществляется переход от наиболее конкретной информации (имя DNS компьютера «host-a») к наиболее общей (завершающая точка (.), которая указывает корень в дереве имен DNS). Этот пример демонстрирует четыре уровня доменов DNS, которые ведут от конкретного расположения «host-a».

1. Домен «mspu», в котором зарегистрировано для использования имя компьютера «host-a».
2. Домен «edu», который соответствует родительскому домену, являющемуся корнем поддомена «mspu».
3. Домен «ru», который соответствует домену верхнего уровня, предназначенному для использования организациями из России, который является корнем для домена «edu».
4. Завершающая точка (.), представляющая стандартный символ разделителя, которая используется, чтобы сделать полным доменное имя DNS в дереве пространства имен DNS.

Работа запросов DNS

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

1. указанное доменное имя DNS в виде полного доменного имени узла (FQDN);
2. указанный тип запроса, в котором задается либо тип записей ресурсов, либо тип операции запроса;
3. указанный класс доменного имени DNS.

Для DNS-серверов Windows этот класс всегда должен быть указан как класс Интернета (IN).

Например, указанное имя может представлять полное доменное имя узла для компьютера, такое как «host-a.mspu.edu.ru.», и тип запроса на поиск записей ресурсов адреса (A) для этого имени. Запрос DNS можно представить как вопрос клиента, состоящий из двух частей, например «Имеются ли записи ресурсов A для компьютера с именем 'hostname.mspu.edu.ru.'?» Когда клиент получает ответ от сервера, он читает и интерпретирует содержащуюся в ответе запись ресурса A, узнавая IP-адрес компьютера, запрошенного по имени.

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

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

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

Обе стадии процесса подробнее рассматриваются в следующих разделах.

Локальная система разрешения имен

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

1. Если имеется локальный файл Hosts, все сопоставления имен и адресов из этого файла предварительно загружаются в кэш при запуске службы «DNS-клиент».
2. Записи ресурсов, полученные в ответах на запросы из предыдущих запросов DNS, добавляются в кэш и сохраняются в нем в течение определенного периода времени.

Запрос к DNS-серверу

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

Рисунок 2. Процесс рекурсии при разрешении имени.

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

Ранее отмечалось, что процесс заканчивается возвращением клиенту утвердительного ответа. Однако запросы могут возвращать и другие ответы. Приведем наиболее общие типы таких ответов:

1. удостоверяющий ответ;
2. утвердительный ответ;
3. ссылочный ответ;
4. отрицательный ответ.

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

Утвердительный ответ может содержать запрошенную запись ресурса или список записей ресурсов (который также называют набором записей), соответствующих запрошенному доменному имени DNS и типу записи, указанному в сообщении запроса.

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

Отрицательный ответ от сервера может указывать на один из двух возможных результатов попытки сервера обработать и рекурсивно полностью и удостоверяющим образом сопоставить имя в запросе:

• Удостоверяющий сервер ответил, что запрошенное имя не существует в пространстве имен DNS.
• Удостоверяющий сервер ответил, что запрошенное имя существует, но для этого имени отсутствуют записи указанного типа.

Система сопоставления имен передает результаты запроса в виде утвердительного или отрицательного ответа в запрашивающую программу и кэширует ответ. Итерации представляют тип сопоставления имен, используемый DNS-клиентами и серверами при выполнении следующих условий.

• Клиент запрашивает использование рекурсии, но рекурсия отключена на DNS-сервере.
• Клиент не запрашивает использование рекурсии при запросе к DNS-серверу.

Итерационный запрос от клиента сообщает DNS-серверу, что клиент ожидает от DNS-сервера наиболее точный ответ немедленно без обращения к другим DNS-серверам. Когда используются итерации, DNS-сервер отвечает клиенту о запрошенных именах на основании собственной информации о пространстве имен. Например, если DNS-сервер в интрасети получает запрос от локального клиента для имени «www.edu.ru», он может возвратить ответ из кэша имен. Если в данный момент запрошенное имя не сохраняется в кэше сервера, то сервер может ответить предоставлением ссылки — т.е. списка записей ресурсов других DNS -серверов, которые ближе к имени, запрошенному клиентом. Когда предоставляется ссылка, DNS-клиент принимает на себя ответственность за продолжение итерационных запросов на сопоставление имени к другим указанным в конфигурации DNS-серверам. Например, в наиболее общем случае DNS-клиент может расширить область поиска до серверов корневого домена в Интернете в попытках обнаружить удостоверяющие DNS-серверы для домена «ru». После установления контакта с корневыми серверами Интернета клиент может получить от них дальнейшие итерационные ответы, указывающие на фактические DNS-серверы Интернета для домена «edu.ru». Когда клиенту предоставляются записи для этих DNS-серверов, он может отправить дальнейший итерационный запрос внешним DNS -серверам edu в Интернете, которые могут дать определенный и удостоверяющий ответ. При использовании итераций DNS-сервер может также содействовать в запросе на сопоставление имени, предоставив клиенту собственный наиболее точный ответ. Для большинства итерационных запросов клиент использует локальный список DNS-серверов для обращения к другим серверам имен в пространстве имен DNS, если его собственный основной DNS-сервер не может сопоставить имя в запросе.

По мере того как DNS-серверы обрабатывают запросы клиентов с помощью рекурсии или итераций, они находят и накапливают значительный объем информации о пространстве имен DNS. Эта информация кэшируется сервером. Кэширование дает возможность ускорить сопоставление часто используемых имен DNS в последующих запросах и существенно снижает трафик запросов DNS в сети. При выполнении рекурсивных запросов DNS-серверами для клиентов они временно кэшируют записи ресурсов. Кэшированные записи ресурсов содержат информацию, полученную от DNS-серверов, которые являются удостоверяющими для доменных имен DNS. Эта информация накапливается при выполнении итерационных запросов в процессе поиска и полного ответа на рекурсивный запрос, выполняемый в интересах клиента. Когда затем другие клиенты размещают новые запросы на информацию, отвечающую кэшированным записям ресурсов, DNS-сервер может использовать данные из кэшированных записей ресурсов для ответа. При кэшировании информации значение срока жизни применяется ко всем кэшированным записям ресурсов. Пока не истек срок жизни кэшированной записи ресурса, DNS-сервер может продолжать кэшировать и снова использовать запись ресурса при ответах на соответствующие запросы клиентов. Значения срока жизни кэширования, используемые записями ресурсов в большинстве конфигураций зон, назначаются в параметре Мин. срок жизни TTL (по умолчанию), который задается в начальной записи зоны. По умолчанию задается значение минимального срока жизни 3600 секунд (1 час), но это значение может быть изменено; могут также задаваться отдельные значения срока жизни для каждой записи ресурса.

Обратный просмотр

В большинстве операций просмотра DNS-клиенты обычно выполняют прямой просмотр, т. е. поиск, основанный на имени DNS другого компьютера, сохраненного в записи ресурса адреса (A). В этом типе запроса в качестве данных для ответа на запрос ожидается IP-адрес. DNS также обеспечивает возможность обратного просмотра, в котором клиенты используют известный IP-адрес для поиска имени компьютера по этому адресу. Обратный просмотр фактически является формой вопроса типа «Можете ли вы сказать мне имя DNS компьютера, который использует IP-адрес 192.168.1.20?».

Система DNS не разрабатывалась изначально для поддержки запросов этого типа. Одной из проблем при поддержке запросов обратного просмотра является различие в способах организации и индексации пространства имен DNS и способов назначения IP-адресов. Если бы единственным таким способом был бы поиск во всех доменах пространства имен DNS, то для обработки обратного запроса потребовалось бы слишком много времени и такой запрос оказался бы бесполезным.

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

Следующий рисунок иллюстрирует обратный запрос, инициируемый DNS-клиентом (host-b), которому требуется узнать имя другого узла (host-a) по его IP-адресу 192.168.1.20.

Рисунок 3. Обратный запрос.

Как показано на рисунке, обратный запрос включает следующие этапы.

1. Клиент «host-b» запрашивает DNS-сервер о записи ресурса указателя (PTR), сопоставляющей IP-адрес 192.168.1.20 для имени «host-a».
   Поскольку запрос относится к записям PTR, система сопоставления имен обращает адрес и добавляет имя домена «in-addr.arpa» в конец обращенного адреса. В результате образуется полное доменное имя узла («20.1.168.192.in-addr.arpa.»), для которого будет проводиться поиск в зоне обратного просмотра.
2. После обнаружения имени удостоверяющий DNS-сервер для имени «20.1.168.192.in-addr.arpa» может возвратить ответ с информацией записи PTR. В этой информации содержится доменное имя DNS узла «host-a», что приводит к завершению процесса обратного просмотра. Необходимо помнить, что если запрошенное обратное имя не может быть возвращено DNS-сервером, можно использовать сопоставление имен DNS (либо рекурсию, либо итерации) для обнаружения DNS-сервера, который является удостоверяющим для зоны обратного просмотра и содержит запрашиваемое имя. В этом смысле процесс сопоставления имен при обратном просмотре аналогичен процессу прямого просмотра

Инвертированные запросы

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

Служба DNS распознает и принимает сообщения инвертированных запросов и отвечает на них с имитацией ответа на инвертированный запрос.

Динамическое обновление

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

Клиентские и серверные службы DNS поддерживают использование динамических обновлений, как описано в документе RFC 2136, «Dynamic Updates in the Domain Name System». Служба DNS-сервер поддерживает включение и отключение динамических обновлений отдельно для каждой зоны на каждом сервере, настроенном для загрузки либо стандартной основной зоны, либо зоны, интегрированной в каталоги. Служба DNS-клиент будет по умолчанию динамически обновлять свои записи ресурсов узла (A) в DNS, когда была выполнена настройка для TCP/IP.

Динамические обновления обычно запрашиваются, когда изменяется имя DNS или IP-адрес компьютера. Например, предположим, что для клиента с именем «oldhost» в окне Свойства системы заданы следующие имена:

Имя компьютера	oldhost
Доменное DNS-имя компьютера	mspu.edu.ru.
Полное имя компьютера	oldhost. mspu.edu.ru

Таблица 2. Старые имена компьютера.

В этом примере в конфигурации компьютера нет доменных имен DNS, специфических для подключения. В дальнейшем компьютер переименовывается из «oldhost» в «newhost», в результате чего имена изменяются следующим образом.

Имя компьютера	newhost
Доменное DNS-имя компьютера	mspu.edu.ru.
Полное имя компьютера	newhost.mspu.edu.ru

Таблица 3. Новые имена компьютера.

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

1. Служба DHCP-клиент отправляет запрос для типа начальной записи зоны (SOA) с использованием доменного имени DNS компьютера. Клиентский компьютер использует текущее полное доменное имя узла компьютера (в данном случае «newhost. mspu.edu.ru») как имя, указанное в этом запросе.
2. Удостоверяющий DNS-сервер зоны, содержащей полное доменное имя узла клиента, отвечает на запрос типа SOA.
3. После этого служба DHCP-клиент пытается установить контакт с основным DNS-сервером.
   Клиент обрабатывает ответ на запрос SOA для его имени, чтобы определить IP-адрес DNS-сервера, удостоверенного как основной сервер, для принятия его имени. Далее он выполняет такую последовательность шагов, необходимых, чтобы установить контакт и динамически обновить его основной сервер.
   1. Клиент отправляет запрос на динамическое обновление основному серверу, определенному в ответе на запрос SOA.
      Если обновление выполняется успешно, другие действия не предпринимаются.
   2. При отказе на обновление клиент отправляет запрос типа NS (о серверах имен) для зоны, имя которой указано в записи SOA.
   3. Когда клиент получает ответ на этот запрос, он отправляет запрос SOA на первый DNS-сервер, перечисленный в ответе.
   4. После разрешения имен в запросе SOA клиент отправляет динамическое обновление серверу, указанному в возвращенной записи SOA. Если обновление выполняется успешно, другие действия не предпринимаются.
   5. При отказе на обновление клиент повторяет запрос SOA, отправляя его к следующему DNS-серверу, перечисленному в ответе.
4. Как только находится основной сервер, который может выполнить обновление, клиент отправляет запрос на обновление, который обрабатывается сервером.

Содержимое запроса на обновление включает инструкции добавить записи ресурсов A (и возможно PTR) для имени «newhost.mspu.edu.ru» и записи этих типов для ранее зарегистрированного имени «oldhost.mspu.edu.ru».

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

Динамические обновления отправляются или выполняются периодически. По умолчанию компьютер отправляет обновления каждые 7 дней. Если в результате обновления данные в зоне не изменяются, зона остается в текущей версии и никакие изменения не записываются. Обновления выполняются только при фактических изменениях имен и адресов в зоне или в результате добавочной зонной передачи.

Безопасное динамическое обновление

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

• DNS-клиенты сначала предпринимают попытки выполнить небезопасные динамические обновления. При отказе на небезопасные обновления клиенты пытаются выполнить безопасные обновления.
  Кроме того, клиенты используют политику обновления по умолчанию, которая позволяет им пытаться переписывать ранее зарегистрированную запись ресурса, если она специально не заблокирована условиями безопасности обновления.
• После интегрирования зоны в службу каталогов Active Directory DNS-серверам Windows Server 2003 по умолчанию разрешаются только безопасные динамические обновления.
  При использовании стандартного сохранения зон настройки по умолчанию службы DNS-сервер не разрешают динамические обновления зон. И для зон, интегрированных в каталоги, и для использующих стандартное сохранение в файлах можно изменить параметры зоны и разрешить динамические обновления. Это позволяет принимать любые обновления.

При развертывании DNS-серверов совместно с Active Directory необходимо иметь в виду следующее:

• Служба DNS требуется для обнаружения контроллеров доменов Windows Server 2003. Служба сетевого входа в систему использует новые средства поддержки DNS-серверов для обеспечения регистрации контроллеров доменов в пространстве доменных имен DNS.
• DNS-серверы Windows Server 2003 могут использовать службу каталогов Active Directory для сохранения и репликации зон.
  При интегрировании зон в службу каталогов пользователи получают возможность использовать дополнительные средства DNS, такие как безопасные динамические обновления и средства устаревания и очистки записей.

Способы интеграции DNS со службой каталогов Active Directory:

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

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

• Стандартное сохранение зоны с помощью файла в текстовом формате.
  Зоны, сохраняемые в этом способе, размещаются в файлах с раширением DNS, которые сохраняется в папке systemroot\System32\Dns на каждом компьютере, на котором выполняется DNS-сервер. Имя файла зоны соответствует имени, которое пользователь выбрал для зоны при ее создании, например, mspu.edu.ru.dns, если именем зоны является «mspu.edu.ru.dns».
• Сохранение зон, интегрированных в службу каталогов, с помощью базы данных Active Directory. Зоны, сохраняемые таким образом, размещаются в дереве Active Directory под разделом каталога домена или приложения. Каждая зона, интегрированная в службу каталогов, сохраняется в контейнере dnsZone, который идентифицируется по имени, выбранному пользователем при ее создании.

Преимущества интеграции с 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 выполняется на уровне отдельных свойств, распространяются только необходимые изменения. При этом для зон, интегрированных в службу каталогов, используется и отправляется меньший объем данных.

Выполнение работы

Задание 1. Установка сервера DNS

1. Запустите виртуальную машину ВМ VM-2.
2. Подключите к виртуальной машине образ установочного диска win2003.iso.
3. Откройте диалоговое окно Управление данным сервером (Пуск/Администрирование/Управление Данным Сервером).
4. Активизируйте установку сервера имен:
   • запустите мастер добавления ролей сервера, кнопкой Добавить или удалить роль ;
   • ознакомьтесь с информацией мастера и продолжите установку кнопкой Далее;
   • укажите тип установки Особая конфигурация и продолжите установку кнопкой Далее.
   • выберите в списке доступных ролей сервера пункт DNS-сервер. Нажмите Далее.
   • Ознакомьтесь с сводкой выбранных параметров и продолжите установку кнопкой Далее.
После завершения установки сервера имен, автоматически запуститься Мастер настройки DNS-сервера.
5. Выполните первоначальную настройку DNS-сервера с помощью мастера:
   • ознакомьтесь с информацией мастера (Далее);
   • ознакомьтесь с предлагаемыми вариантами настройки сервера;
   • выберите создание зоны прямого просмотра для небольших сетей, соответствующей радиокнопкой (Далее);
   • укажите ваш DNS-сервер в качестве DNS-сервера, который будет обслуживать зону прямого просмотра, радиокнопкой Управление зоной выполняется этим сервером. Продолжите установку кнопкой Далее;

     
     Рисунок 4. Размещение основного сервера

   • задайте имя зоны, например example.edu.ru и продолжите установку кнопкой Далее.
   • введите в поле Создать новый файл имя файла (например example.edu.ru.dns)в котором будет храниться конфигурация зоны. Продолжите установку кнопкой Далее;
   • запретите динамическое обновление соответствующей радиокнопкой и продолжите настройку кнопкой Далее;
   • откажитесь от пересылки запросов на другие DNS-сервера, выбрав радиокнопку Нет, не пересылать запросы (Далее);
   • ознакомьтесь с информацией о недоступности корневых сертификатов и щелкните ОК;
   • завершите первоначальную настройку DNS-сервера кнопкой Готово.

Задание 2. Настройка сервера DNS.

1. Переключитесь в диалоговое окно Управления данным сервером.
2. Перейдите в управление DNS-сервером, кнопкой Управление этим DNS-сервером.
   Появится окно консоли администрирования, с открытой оснасткой управления DNS-сервером

   
   Рисунок 5. Создание зоны прямого просмотра.

3. Настройте зону прямого просмотра:
   • откройте диалоговое окно свойств созданной ранее зоны example.edu.ru (контекстное меню/Свойства)
   • настройте очистку и обновление содержимого DNS-сервера:
     • откройте окно очистки, кнопкой Очистка;
     • установите флажок Удалять устаревшие записи ресурсов;
     • установите интервал блокирования - 1 день;
     • установите интервал обновления - 7 дней;
     • подтвердите изменения кнопкой ОК.
   • установите срок жизни (TTL) записи – 2 часа:
     • перейдите на вкладку Начальная запись зоны (SOA);
     • введите в поле Срок жизни (TTL) записи – 0: 2: 0: 0;
     • установите желаемые интервалы для обновления и повтора - не менее 1 и не более 15 минут.
   Завершите настройку кнопкой ОК.
4. Создайте запись в DNS-сервере соответствующую физическому компьютеру:
   • откройте диалоговое окно добавления новых узлов (контекстное меню example.edu.ru/Создать узел (А));
   • введите в поле Имя - <имя_физического_компьютера>;
   • введите в поле IP-адрес - 192.168.1.1;
   • завершите добавление кнопкой Добавить.
5. Создайте новую основную зону обратного просмотра:
   • откройте мастер создания новых зон (контекстное меню Зоны обратного просмотра/Создать новую зону);
   • ознакомьтесь с информацией мастера и щелкните Далее;
   • укажите тип создаваемой зоны - Основная зона (Далее);
   • укажите код сети – 192.168.1 (Далее);
     Поскольку IP-адреса создаваемой сети к сети класса C, то в IP-адресах сети будет меняться только последний разряд адреса.

     
     Рисунок 6. Задание кода сети

   • укажите имя файла для зоны по умолчанию и продолжите установку кнопкой Далее.
   • установите запрет динамических обновлений (Далее);
   • завершите создание зоны кнопкой Готово.
6. Протестируйте работу DNS-сервера:
   • откройте диалоговое окно свойств DNS-сервера (контекстное меню Wind2003/Свойства);
   • перейдите на вкладку Наблюдение;
   • установите флажок Простой запрос к этому DNS-серверу;
   • активируйте тестирование кнопкой Тест;
     Результат отобразиться в поле Результаты теста.
   • создайте и сохраните в своей папке снимок экрана с результатами теста;
   • закройте диалоговое окно свойств кнопкой ОК.
7. Выключите ВМ.

Задание 3. Выполните cамостоятельные задания к модулю 3-4.