Какие типы зон dns поддерживаются службой dns систем семейства windows server

Служба DNS: домены и зоны

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

Системы семейства Windows Server поддерживают следующие типы зон:

Стандартная основная (standard primary) — главная копия стандартной зоны; только в данном экземпляре зоны допускается производить какие-либо изменения, которые затем реплицируются на серверы, хранящие дополнительные зоны;
Стандартная дополнительная (standard secondary) — копия основной зоны, доступная в режиме «только-чтение», предназначена для повышения отказоустойчивости и распределения нагрузки между серверами, отвечающими за определенную зону; процесс репликации изменений в записях зон называется «передачей зоны» ( zone transfer )
(информация в стандартных зонах хранится в текстовых файлах, файлы создаются в папке «%system root%\system32\dns», имя файла, как правило, образуется из имени зоны с добавлением расширения файла «.dns»; термин «стандартная» используется только в системах семейства Windows);
Интегрированная в Active Directory (Active Directory–integrated) — вся информация о зоне хранится в виде одной записи в базе данных Active Directory (такие типы зон могут существовать только на серверах Windows, являющихся контроллерами доменов Active Directory; в интегрированных зонах можно более жестко управлять правами доступа к записям зоны; изменения в записях зоны между разными экземплярами интегрированной зоны производятся не по технологии передачи зоны службой DNS, а механизмами репликации службы Active Directory);
Зона-заглушка ( stub ; только в Windows 2003) — особый тип зоны, которая для данной части пространства имен DNS содержит самый минимальный набор ресурсных записей (начальная запись зоны SOA, список серверов имен, отвечающих за данную зону, и несколько записей типа A для ссылок на серверы имен для данной зоны).

Рассмотрим на примере соотношение между понятиями домена и зоны. Проанализируем информацию, представленную на рис. 4.9.

Рис.
4.9.

В данном примере пространство имен DNS начинается с домена microsoft.com, который содержит 3 поддомена: sales.microsoft.com, it.microsoft.com и edu.microsoft.com (домены на рисунке обозначены маленькими горизонтальными овалами). Домен — понятие чисто логическое, относящееся только к распределению имен. Понятие домена никак не связано с технологией хранения информации о домене. Зона — это способ представления информации о домене и его поддоменах в хранилище тех серверов DNS, которые отвечают за данный домен и поддомены. В данной ситуации, если для хранения выбрана технология стандартных зон, то размещение информации о доменах может быть реализовано следующим образом:

записи, относящиеся к доменам microsoft.com и edu.microsoft.com, хранятся в одной зоне в файле «microsoft.com.dns» (на рисунке зона обозначена большим наклонным овалом);
управление доменами sales.microsoft.com и it.microsoft.com делегировано другим серверам DNS, для этих доменов на других серверах созданы соответствующие файлы «sales.microsoft.com.dns» и «it.microsoft.com.dns» (данные зоны обозначены большими вертикальными овалами).

Делегирование управления — передача ответственности за часть пространства имен другим серверам DNS.

Зоны прямого и обратного просмотра

Зоны, рассмотренные в предыдущем примере, являются зонами прямого просмотра (forward lookup zones). Данные зоны служат для разрешения имен узлов в IP-адреса. Наиболее часто используемые для этого типы записей: A, CNAME, SRV.

Для определения имени узла по его IP-адресу служат зоны обратного просмотра (reverse lookup zones), основной тип записи в «обратных» зонах — PTR. Для решения данной задачи создан специальный домен с именем in-addr.arpa. Для каждой IP-сети в таком домене создаются соответствующие поддомены, образованные из идентификатора сети, записанного в обратном порядке. Записи в такой зоне будут сопоставлять идентификатору узла полное FQDN-имя данного узла. Например, для IP-сети 192.168.0.0/24 необходимо создать зону с именем «0.168.192.in-addr.arpa». Для узла с IP-адресом 192.168.0.10 и именем host.company.ru в данной зоне должна быть создана запись «10 PTR host.company.ru».

Алгоритмы работы итеративных и рекурсивных запросов DNS

Все запросы, отправляемые DNS-клиентом DNS-серверу для разрешения имен, делятся на два типа:

итеративные запросы (клиент посылает серверу DNS запрос, в котором требует дать наилучший ответ без обращений к другим DNS-серверам);
рекурсивные запросы (клиент посылает серверу DNS запрос, в котором требует дать окончательный ответ даже если DNS-серверу придется отправить запросы другим DNS-серверам; посылаемые в этом случае другим DNS-серверам запросы будут итеративными).

Обычные DNS-клиенты (например, рабочие станции пользователей), как правило, посылают рекурсивные запросы.

Рассмотрим на примерах, как происходит взаимодействие DNS-клиента и DNS-сервера при обработке итеративных и рекурсивных запросов.

Допустим, что пользователь запустил программу Обозреватель Интернета и ввел в адресной строке адрес http://www.microsoft.com. Прежде чем Обозреватель установит сеанс связи с веб-сайтом по протоколу HTTP, клиентский компьютер должен определить IP-адрес веб-сервера. Для этого клиентская часть протокола TCP/IP рабочей станции пользователя (так называемый resolver ) сначала просматривает свой локальный кэш разрешенных ранее имен в попытке найти там имя www.microsoft.com. Если имя не найдено, то клиент посылает запрос DNS-серверу, указанному в конфигурации TCP/IP данного компьютера (назовем данный DNS-сервер «локальным DNS-сервером» ), на разрешение имени www.microsoft.com в IP-адрес данного узла. Далее DNS-сервер обрабатывает запрос в зависимости от типа запроса.

Вариант 1 (итеративный запрос).

Если клиент отправил серверу итеративный запрос (напомним, что обычно клиенты посылают рекурсивные запросы), то обработка запроса происходит по следующей схеме:

сначала локальный DNS-сервер ищет среди зон, за которые он отвечает, зону microsoft.com;

если такая зона найдена, то в ней ищется запись для узла www ; если запись найдена, то результат поиска сразу же возвращается клиенту;

в противном случае локальный DNS-сервер ищет запрошенное имя www.microsoft.com в своем кэше разрешенных ранее DNS-запросов;

если искомое имя есть в кэше, то результат поиска возвращается клиенту; если локальный DNS-сервер не нашел в своей базе данных искомую запись, то клиенту посылается IP-адрес одного из корневых серверов DNS;
клиент получает IP-адрес корневого сервера и повторяет ему запрос на разрешение имени www.microsoft.com;

корневой сервер не содержит в своей БД зоны «microsoft.com», но ему известны DNS-серверы, отвечающие за зону «com», и корневой сервер посылает клиенту IP-адрес одного из серверов, отвечающих за эту зону;
клиент получает IP-адрес сервера, отвечающего за зону «com», и посылает ему запрос на разрешение имени www.microsoft.com;

сервер, отвечающий за зону com, не содержит в своей БД зоны microsoft.com, но ему известны DNS-серверы, отвечающие за зону microsoft.com, и данный DNS-сервер посылает клиенту IP-адрес одного из серверов, отвечающих уже за зону microsoft.com;
клиент получает IP-адрес сервера, отвечающего за зону microsoft.com, и посылает ему запрос на разрешение имени www.microsoft.com;

сервер, отвечающий за зону microsoft.com, получает данный запрос, находит в своей базе данных IP-адрес узла www, расположенного в зоне microsoft.com, и посылает результат клиенту;

клиент получает искомый IP-адрес, сохраняет разрешенный запрос в своем локальном кэше и передает IP-адрес веб-сайта программе Обозреватель Интернета (после чего Обозреватель устанавливает связь с веб-сайтом по протоколу HTTP).

Вариант 2 (рекурсивный запрос).

Если клиент отправил серверу рекурсивный запрос, то обработка запроса происходит по такой схеме:

сначала локальный DNS-сервер ищет среди зон, за которые он отвечает, зону microsoft.com; если такая зона найдена, то в ней ищется запись для узла www ; если запись найдена, то результат поиска сразу же возвращается клиенту;

в противном случае локальный DNS-сервер ищет запрошенное имя www.microsoft.com в своем кэше разрешенных ранее DNS-запросов; если искомое имя есть в кэше, то результат поиска возвращается клиенту;
если локальный DNS-сервер не нашел в своей базе данных искомую запись, то сам локальный DNS-сервер выполняет серию итеративных запросов на разрешение имени www.microsoft.com, и клиенту посылается либо найденный IP-адрес, либо сообщение об ошибке.

Реализация службы DNS в системах семейства Windows Server

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

поддержка службой DNS динамической регистрации (dynamic updates);
поддержка службой DNS записей типа SRV.

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

Рассмотрим несколько простых примеров управления службой DNS:

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

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

сеть состоит из двух серверов Windows 2003 Server;
операционная система — ограниченная по времени 120-дневная русская версия Windows 2003 Server Enterprise Edition;
первый сервер установлен на ПК с процессором Intel Pentium-4 3Ггц и оперативной памятью 512 МБ, имя сервера — DC1, IP-адрес — 192.168.0.1/24 ;
второй сервер работает в качестве виртуальной системы с помощью Microsoft VirtualPC 2004, имя сервера -DC2, IP-адрес — 192.168.0.2/24 ;
имя домена в пространстве DNS и соответствующее имя в службе каталогов Active Directory — world.ru (сеть полностью изолирована от других сетей, поэтому в данном примере авторы были свободны в выборе имени домена; в реальной обстановке конкретного учебного заведения преподавателю нужно скорректировать данную информацию).

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

Источник

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

В
1983 году Пол Мокапетрис работал научным
сотрудником института информатики
(Information Sciences Institute, ISI),
входящего в состав инженерной школы
университета Южной Калифорнии (USC).
Его руководитель, Джон Постел, предложил
Полу придумать новый механизм,
устанавливающий связи между именами
компьютеров и адресами Internet, — взамен
использовавшемуся тогда централизованному
каталогу имен и адресов хостов, который
поддерживала калифорнийская компания
SRI International.

«Все
понимали, что старая схема не сможет
работать вечно, — вспоминает Мокапетрис.
— Рост Internet становился лавинообразным.
К сети, возникшей на основе проекта
ARPANET, инициированного Пентагоном,
присоединялись все новые и новые компании
и исследовательские институты».

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

«Как
только организация подключалась к сети,
она могла использовать сколь угодно
много компьютеров и сама назначать им
имена», — подчеркнул Мокапетрис.
Названия доменов компаний получили
суффикс .com,
университетов — .edu и
так далее.

Первоначально
DNS была рассчитана на поддержку 50 млн.
записей и допускала безопасное расширение
до нескольких сотен миллионов записей.
По оценкам Мокапетриса, сейчас
насчитывается около 1 млрд. имен DNS, в
том числе почти 20 млн. общедоступных
имен. Остальные принадлежат системам,
расположенным за межсетевыми экранами.
Их имена неизвестны обычным
Internet-пользователям.

Новая
система внедрялась постепенно, в течение
нескольких лет. В это время ряд
исследователей экспериментировали с
ее возможностями, а Мокапетрис занимался
в ISI обслуживанием
и поддержанием стабильной работы
«корневого сервера», построенного
на мэйнфреймах компании Digital Equipment. Копии
таблиц хостов хранились на каждом
компьютере, подключенном к Internet, еще
примерно до 1986 года. Затем начался
массовый переход на использование DNS.

Необходимость
отображения имен сетевых узлов в
IP-адреса

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

Есть
два таких механизма — локальный для
каждого компьютера файл hosts и
централизованная иерархическая служба
имен DNS.

Использование
локального файла hosts и системы доменных
имен DNS для разрешения имен сетевых
узлов

На
начальном этапе развития сетей, когда
количество узлов в каждой сети было
небольшое, достаточно было на каждом
компьютере хранить и поддерживать
актуальное состояние простого текстового
файла, в котором содержался список
сетевых узлов данной сети. Список устроен
очень просто — в каждой строке текстового
файла содержится пара «IP-адрес — имя
сетевого узла». В системах семейства
Windows данный файл расположен в папке %system
root%system32driversetc (где %system
root% обозначает
папку, в которой установлена операционная
система). Сразу после установки системы
Windows создается файл hosts с
одной записью 127.0.0.1
localhost.

С
ростом сетей поддерживать актуальность
и точность информации в файле hosts становится
все труднее. Для этого надо постоянно
обновлять содержимое этого файла на
всех узлах сети. Кроме того, такая
простая технология не
позволяет организовать пространство
имен в какую-либо структуру. Поэтому
появилась необходимость в централизованной
базе данных имен, позволяющей производить
преобразование имен в IP-адреса
без хранения списка
соответствия на каждом компьютере.
Такой базой стала DNS (Domain Name System) — система
именования доменов, которая начала
массовую работу в 1987 году.

Заметим,
что с появлением службы DNS актуальность
использования файла host совсем не исчезла,
в ряде случаев использование этого
файла оказывается очень эффективным.

Служба
DNS: пространство имен, домены

DNS
— это иерархическая
база данных,
сопоставляющая имена сетевых узлов и
их сетевых служб IP-адресам узлов.
Содержимое этой базы, с одной стороны,
распределено по большому количеству
серверов службы DNS, а с другой стороны,
является централизованно управляемым.
В основе иерархической
структуры базы данных DNS
лежит доменное пространство имен (domain
namespace), основной структурной единицей
которого является домен, объединяющий
сетевые узлы (хосты), а также поддомены.
Процесс поиска в БД службы DNS имени
некоего сетевого узла и сопоставления
этому имени IP-адреса называется
«разрешением имени узла в пространстве
имен DNS».

Служба
DNS состоит из трех основных компонент:

Пространство
имен DNS и соответствующие ресурсные
записи (RR, resource record) —
это сама распределенная база данных
DNS;
Серверы
имен DNS —
компьютеры, хранящие базу данных DNS и
отвечающие на запросы DNS-клиентов;
DNS-клиенты
(DNS-clients, DNS-resolvers) -компьютеры,
посылающие запросы серверам DNS для
получения ресурсных записей.

Пространство
имен.

Пространство
имен DNS — иерархическая древовидная
структура, начинающаяся с корня, не
имеющего имени и обозначаемого точкой
«.». Схему построения пространства
имен DNS лучше всего проиллюстрировать
на примере сети Интернет (рис.
4.8).

Рис.
4.8.

Для
доменов 1-го уровня различают 3 категории
имен:

ARPA —
специальное имя, используемое для
обратного разрешения DNS (из IP-адреса в
полное имя узла);
Общие
(generic) имена 1-го уровня —
16 (на данный момент) имен, назначение
которых приведено в табл.
4.4;
Двухбуквенные
имена для стран —
имена для доменов, зарегистрированных
в соответствующих странах (например, ru —
для России, ua —
для Украины, uk —
для Великобритании и т.д.).

Таблица 4.4.
Имя домена	Назначение
aero	Сообщества авиаторов
biz	Компании (без привязки к стране)
com	Коммерческие организации, преимущественно в США (например, домен microsoft.com для корпорации Microsoft)
coop	Кооперативы
edu	Образовательные учреждения в США
gov	Правительственные учреждения США
info	Домен для организаций, предоставляющих любую информацию для потребителей
int	международные организации (например, домен nato.int для НАТО)
mil	Военные ведомства США
museum	Музеи
name	Глобальный домен для частных лиц
net	Домен для Интернет-провайдеров и других организаций, управляющих структурой сети Интернет
org	Некоммерческие и неправительственные организации, преимущественно в США
pro	Домен для профессиональных объединений (врачей, юристов, бухгалтеров и др.)
job	Кадровые агентства
travel	Туроператоры

Для
непосредственного отображения
пространства имен в пространство
IP-адресов служат т.н. ресурсные записи
(RR, resource record). Каждый сервер DNS содержит
ресурсные записи для той части пространства
имен, за которую он несет ответственность
(authoritative). табл.
4.5 содержит
описание наиболее часто используемых
типов ресурсных записей.

Таблица 4.5.
Тип ресурсной записи	Функция записи	Описание использования
A	Host Address Адрес хоста, или узла	Отображает имя узла на IP-адрес (например, для домена microsoft.com узлу с именем www.microsoft.comсопоставляется IP-адрес с помощью такой записи: www A 207.46.199.60 )
CNAME	Canonical Name (alias) Каноническое имя (псевдоним)	Отображает одно имя на другое
MX	Mail Exchanger Обмен почтой	Управляет маршрутизацией почтовых сообщений для протокола SMTP
NS	Name Server Сервер имен	Указывает на серверы DNS, ответственные за конкретный домен и его поддомены
PTR	Pointer Указатель	Используется для обратного разрешения IP-адресов в имена узлов в домене in-addr.arpa
SOA	Start of Authority Начальная запись зоны	Используется для указания основного сервера для данной зоны и описания свойств зоны
SRV	Service Locator Указатель на службу	Используется для поиска серверов, на которых функционируют определенные службы (например, контроллеры доменов Active Directory или серверы глобального каталога)

Полное
имя узла (FQDN, fully qualified domain name) состоит из
нескольких имен, называемых метками
(label) и разделенных точкой. Самая левая
метка относится непосредственно к узлу,
остальные метки — список доменов от
домена первого уровня до того домена,
в котором находится узел (данный список
просматривается справа налево).

Серверы
имен DNS.

Серверы
имен DNS (или DNS-серверы) — это компьютеры,
на которых хранятся те части БД
пространства имен DNS, за которые данные
серверы отвечают, и функционирует
программное обеспечение, которое
обрабатывает запросы DNS-клиентов на
разрешение имен и выдает ответы на
полученные запросы.

DNS-клиенты.

DNS-клиент
— это любой сетевой узел, который обратился
к DNS-серверу для разрешения имени узла
в IP-адрес или, обратно, IP-адреса в имя
узла.

Служба
DNS: домены и зоны

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

Системы
семейства Windows Server поддерживают следующие
типы зон:

Стандартная
основная (standard primary) —
главная копия стандартной зоны; только
в данном экземпляре зоны допускается
производить какие-либо изменения,
которые затем реплицируются на серверы,
хранящие дополнительные зоны;
Стандартная
дополнительная (standard secondary) —
копия основной зоны, доступная в режиме
«только-чтение», предназначена
для повышения отказоустойчивости и
распределения нагрузки между серверами,
отвечающими за определенную зону;
процесс репликации изменений в записях
зон называется «передачей зоны»
( zone
transfer )
(информация в стандартных зонах хранится
в текстовых файлах, файлы создаются в
папке «%system root%system32dns», имя файла,
как правило, образуется из имени зоны
с добавлением расширения файла «.dns»;
термин «стандартная» используется
только в системах семейства Windows);
Интегрированная
в Active Directory (Active Directory–integrated) —
вся информация о зоне хранится в виде
одной записи в базе данных Active Directory
(такие типы зон могут существовать
только на серверах Windows, являющихся
контроллерами доменов Active Directory; в
интегрированных зонах можно более
жестко управлять правами доступа к
записям зоны; изменения в записях зоны
между разными экземплярами интегрированной
зоны производятся не потехнологии передачи
зоны службой DNS, а механизмами репликации
службы Active Directory);
Зона-заглушка ( stub ;
только в Windows 2003) — особый тип зоны,
которая для данной части пространства
имен DNS содержит самый минимальный
набор ресурсных записей (начальная
запись зоны SOA, список серверов имен,
отвечающих за данную зону, и несколько
записей типа A для ссылок на серверы
имен для данной зоны).

Рассмотрим
на примере соотношение между понятиями
домена и зоны. Проанализируем информацию,
представленную на рис.
4.9.

Рис.
4.9.

В
данном примере пространство имен DNS
начинается с домена microsoft.com,
который содержит 3
поддомена: sales.microsoft.com, it.microsoft.com иedu.microsoft.com (домены
на рисунке обозначены маленькими
горизонтальными овалами). Домен — понятие
чисто логическое, относящееся только
к распределению имен. Понятие домена
никак не связано с технологией хранения информации
о домене.
Зона —
это способ представления информации о
домене и его поддоменах в хранилище тех
серверов DNS, которые отвечают за данный
домен и поддомены. В данной ситуации,
если для хранения выбрана технология
стандартных зон, то размещение информации
о доменах может быть реализовано
следующим образом:

записи,
относящиеся к доменам microsoft.com и edu.microsoft.com,
хранятся в одной зоне в
файле «microsoft.com.dns» (на
рисунке зона обозначена большим
наклонным овалом);
управление
доменами sales.microsoft.com и it.microsoft.com делегировано
другим серверам DNS, для этих доменов на
других серверах созданы соответствующие
файлы «sales.microsoft.com.dns» и «it.microsoft.com.dns» (данные
зоны обозначены большими вертикальными
овалами).

Делегирование
управления — передача ответственности
за часть пространства имен другим
серверам DNS.

Зоны
прямого и обратного просмотра

Зоны,
рассмотренные в предыдущем примере,
являются зонами
прямого просмотра (forward lookup zones).
Данные зоны служат для разрешения имен
узлов в IP-адреса. Наиболее часто
используемые для этого типы
записей: A, CNAME, SRV.

Для
определения имени узла по его IP-адресу
служат зоны обратного просмотра (reverse
lookup zones),
основной тип записи в «обратных»
зонах — PTR. Для решения данной задачи
создан специальный домен с
именем in-addr.arpa.
Для каждой IP-сети в таком домене создаются
соответствующие поддомены, образованные
из идентификатора сети, записанного в
обратном порядке. Записи в такой зоне
будут сопоставлять идентификатору узла
полное FQDN-имя данного узла. Например,
для IP-сети 192.168.0.0/24 необходимо
создать зону с именем «0.168.192.in-addr.arpa».
Для узла с IP-адресом 192.168.0.10 и
именем host.company.ru в
данной зоне должна быть создана запись «10
PTR host.company.ru».

Алгоритмы
работы итеративных и рекурсивных
запросов DNS

Все запросы,
отправляемые DNS-клиентом DNS-серверу для
разрешения имен, делятся на два типа:

итеративные
запросы (клиент посылает серверу
DNS запрос,
в котором требует дать наилучший ответ
без обращений к другим DNS-серверам);
рекурсивные
запросы (клиент посылает серверу DNS
запрос, в котором требует дать
окончательный ответ даже если DNS-серверу
придется отправить запросы другим
DNS-серверам; посылаемые в этом случае
другим DNS-серверам запросы будут
итеративными).

Обычные
DNS-клиенты (например, рабочие станции
пользователей), как правило, посылают
рекурсивные запросы.

Рассмотрим
на примерах, как происходит взаимодействие
DNS-клиента и DNS-сервера при обработке
итеративных и рекурсивных запросов.

Допустим,
что пользователь запустил программу
Обозреватель Интернета и ввел в адресной
строке адрес http://www.microsoft.com.
Прежде чем Обозреватель установит сеанс
связи с веб-сайтом по протоколу HTTP,
клиентский компьютер должен определить
IP-адрес веб-сервера. Для этого клиентская
часть протокола TCP/IP рабочей станции
пользователя (так называемый resolver )
сначала просматривает свой локальный
кэш разрешенных ранее имен в попытке
найти там имяwww.microsoft.com.
Если имя не найдено, то клиент посылает
запрос DNS-серверу, указанному в конфигурации
TCP/IP данного компьютера (назовем данный
DNS-сервер «локальным
DNS-сервером» ),
на разрешение имени www.microsoft.com в
IP-адрес данного узла. Далее DNS-сервер
обрабатывает запрос в зависимости от
типа запроса.

Вариант
1 (итеративный запрос).

Если
клиент отправил серверу итеративный
запрос (напомним, что обычно клиенты
посылают рекурсивные запросы), то
обработка запроса происходит по следующей
схеме:

сначала
локальный DNS-сервер ищет среди зон, за
которые он отвечает, зону microsoft.com;

если
такая зона найдена, то в ней ищется
запись для узла www ;
если запись найдена, то результат поиска
сразу же возвращается клиенту;

в
противном случае локальный DNS-сервер
ищет запрошенное имя www.microsoft.com в
своем кэше разрешенных ранее DNS-запросов;

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

клиент
получает IP-адрес корневого сервера и
повторяет ему запрос на разрешение
имени www.microsoft.com;

корневой
сервер не содержит в своей БД зоны
«microsoft.com», но ему известны DNS-серверы,
отвечающие за зону «com», и корневой
сервер посылает клиенту IP-адрес одного
из серверов, отвечающих за эту зону;

клиент
получает IP-адрес сервера, отвечающего
за зону «com», и посылает ему запрос
на разрешение имени www.microsoft.com;

сервер,
отвечающий за зону com,
не содержит в своей БД зоны microsoft.com,
но ему известны DNS-серверы, отвечающие
за зону microsoft.com,
и данный DNS-сервер посылает клиенту
IP-адрес одного из серверов, отвечающих
уже за зону microsoft.com;

клиент
получает IP-адрес сервера, отвечающего
за зону microsoft.com,
и посылает ему запрос на разрешение
имени www.microsoft.com;

сервер,
отвечающий за зону microsoft.com,
получает данный запрос, находит в своей
базе данных IP-адрес узла www,
расположенного в зоне microsoft.com,
и посылает результат клиенту;

клиент
получает искомый IP-адрес, сохраняет
разрешенный запрос в своем локальном
кэше и передает IP-адрес веб-сайта
программе Обозреватель Интернета (после
чего Обозреватель устанавливает связь
с веб-сайтом по протоколу HTTP).

Вариант
2 (рекурсивный
запрос).

Если
клиент отправил серверу рекурсивный
запрос,
то обработка запроса происходит по
такой схеме:

сначала
локальный DNS-сервер ищет среди зон, за
которые он отвечает, зону microsoft.com;
если такая зона найдена, то в ней ищется
запись для узла www ;
если запись найдена, то результат поиска
сразу же возвращается клиенту;

в
противном случае локальный DNS-сервер
ищет запрошенное имя www.microsoft.com в
своем кэше разрешенных ранее DNS-запросов;
если искомое имя есть в кэше, то результат
поиска возвращается клиенту;

если
локальный DNS-сервер не нашел в своей
базе данных искомую запись, то сам
локальный DNS-сервер выполняет серию
итеративных запросов на разрешение
имени www.microsoft.com,
и клиенту посылается либо найденный
IP-адрес, либо сообщение об ошибке.

Реализация
службы DNS в системах семейства Windows
Server

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

поддержка
службой DNS динамической регистрации
(dynamic updates);
поддержка
службой DNS записей типа SRV.

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

Рассмотрим
несколько простых примеров управления
службой DNS:

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

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

сеть
состоит из двух серверов Windows 2003 Server;
операционная
система — ограниченная по времени
120-дневная русская версия Windows 2003 Server
Enterprise Edition;
первый
сервер установлен на ПК с процессором
Intel Pentium-4 3Ггц и оперативной памятью 512
МБ, имя сервера — DC1, IP-адрес — 192.168.0.1/24 ;
второй
сервер работает в качестве виртуальной
системы с помощью Microsoft VirtualPC 2004, имя
сервера -DC2, IP-адрес — 192.168.0.2/24 ;
имя
домена в пространстве DNS и соответствующее
имя в службе каталогов Active Directory —
world.ru (сеть полностью изолирована от
других сетей, поэтому в данном примере
авторы были свободны в выборе имени
домена; в реальной обстановке конкретного
учебного заведения преподавателю нужно
скорректировать данную информацию).

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

Установка
службы DNS

Установка
службы DNS (как и других компонент системы)
производится достаточно просто с помощью
мастера установки компонент Windows:

Откройте Панель
управления.
Выберите
пункт «Установка
и удаление программ».
Нажмите
кнопку «Установка
компонентов Windows».
Выберите «Сетевые
службы» —
кнопка «Дополнительно» (ни
в коем случае не снимайте галочку у
названия «Сетевые
службы» ).
Отметьте
службу DNS.

Рис.
4.10.

Кнопка «ОК»,
кнопка «Далее»,
кнопка «Готово».

Если
система попросит указать путь к
дистрибутиву системы, введите путь к
папке с дистрибутивом.

Выполним
данное действие на обоих серверах.

Создание
основной зоны прямого просмотра.

На
сервере DC1 создадим стандартную основную
зону с именем world.ru.

Откроем
консоль DNS.
Выберем
раздел «Зоны
прямого просмотра».
Запустим
мастер создания зоны (тип зоны
— «Основная»,
динамические обновления — разрешить,
остальные параметры — по умолчанию).
Введем
имя зоны — world.ru.
Разрешим
передачу данной зоны на любой сервер
DNS ( Консоль
DNS —
зона world.ru — Свойства —
Закладка «Передачи
зон» —
Отметьте «Разрешить
передачи» и«На
любой сервер» ).

Создание
дополнительной зоны прямого просмотра.

На
сервере DC2 создадим стандартную
дополнительную зону с именем world.ru.

Откроем
консоль DNS.
Выберем
раздел «Зоны
прямого просмотра»
Запустим
мастер создания зоны (выбрать: тип зоны
— «Дополнительная»,
IP-адрес master-сервера (с которого будет
копироваться зона) — адрес сервера DC1,
остальные параметры — по умолчанию)
Введем
имя зоны — world.ru.
Проверим
в консоли DNS появление зоны.

Настройка
узлов для выполнения динамической
регистрации на сервер DNS.

Для
выполнения данной задачи нужно выполнить
ряд действий как на сервере DNS, так и в
настройках клиента DNS.

Сервер
DNS.

Создать
соответствующую зону.
Разрешить
динамические обновления.

Это
нами уже выполнено.

Клиент
DNS.

Указать
в настройках протокола TCP/IP адрес
предпочитаемого DNS-сервера — тот сервер,
на котором разрешены динамические
обновления (в нашем примере — сервер
DC1).
В
полном имени компьютера указать
соответствующий DNS-суффикс (в нашем
примере — world.ru ).
Для этого — «Мой
компьютер» — «Свойства» —
Закладка«Имя
компьютера» —
Кнопка «Изменить» —
Кнопка «Дополнительно» —
в пустом текстовом поле впишем название
домена world.ru —
кнопка «ОК» (3
раза)).

Рис.
4.11.

После
этого система предложит перезагрузить
компьютер. После выполнения перезагрузки
на сервер DNS в зоне world.ru автоматически
создадутся записи типаA для
наших серверов (рис.
4.12).

Рис.
4.12.

Создание
зоны обратного просмотра.

Откроем
консоль DNS.
Выберем
раздел «Зоны
обратного просмотра».
Запустим
мастер создания зоны (выбрать: тип зоны
— «Основная»,
динамические обновления — разрешить,
остальные параметры — по умолчанию)
В
поле «Код
сети (ID)» введем
параметры идентификатора сети
— 192.168.0.
Выполним
команду принудительной регистрации
клиента на сервере DNS — ipconfig
/registerdns.

Наши
серверы зарегистрируются в обратной
зоне DNS
(рис.
4.13):

Рис.
4.13.

Служба DNS: домены и зоны

Системы семейства Windows Server поддерживают следующие типы зон:

Стандартная основная (standard primary) — главная копия стандартной зоны; только в данном экземпляре зоны допускается производить какие-либо изменения, которые затем реплицируются на серверы, хранящие дополнительные зоны;
Стандартная дополнительная (standard secondary) — копия основной зоны, доступная в режиме «только-чтение», предназначена для повышения отказоустойчивости и распределения нагрузки между серверами, отвечающими за определенную зону; процесс репликации изменений в записях зон называется «передачей зоны» ( zone transfer )
(информация в стандартных зонах хранится в текстовых файлах, файлы создаются в папке «%system root%system32dns», имя файла, как правило, образуется из имени зоны с добавлением расширения файла «.dns»; термин «стандартная» используется только в системах семейства Windows);
Интегрированная в Active Directory (Active Directory–integrated) — вся информация о зоне хранится в виде одной записи в базе данных Active Directory (такие типы зон могут существовать только на серверах Windows, являющихся контроллерами доменов Active Directory; в интегрированных зонах можно более жестко управлять правами доступа к записям зоны; изменения в записях зоны между разными экземплярами интегрированной зоны производятся не по технологии передачи зоны службой DNS, а механизмами репликации службы Active Directory);
Зона-заглушка ( stub ; только в Windows 2003) — особый тип зоны, которая для данной части пространства имен DNS содержит самый минимальный набор ресурсных записей (начальная запись зоны SOA, список серверов имен, отвечающих за данную зону, и несколько записей типа A для ссылок на серверы имен для данной зоны).

Рис.
4.9.

записи, относящиеся к доменам microsoft.com и edu.microsoft.com, хранятся в одной зоне в файле «microsoft.com.dns» (на рисунке зона обозначена большим наклонным овалом);
управление доменами sales.microsoft.com и it.microsoft.com делегировано другим серверам DNS, для этих доменов на других серверах созданы соответствующие файлы «sales.microsoft.com.dns» и «it.microsoft.com.dns» (данные зоны обозначены большими вертикальными овалами).

Делегирование управления — передача ответственности за часть пространства имен другим серверам DNS.

Зоны прямого и обратного просмотра

Алгоритмы работы итеративных и рекурсивных запросов DNS

Все запросы, отправляемые DNS-клиентом DNS-серверу для разрешения имен, делятся на два типа:

итеративные запросы (клиент посылает серверу DNS запрос, в котором требует дать наилучший ответ без обращений к другим DNS-серверам);
рекурсивные запросы (клиент посылает серверу DNS запрос, в котором требует дать окончательный ответ даже если DNS-серверу придется отправить запросы другим DNS-серверам; посылаемые в этом случае другим DNS-серверам запросы будут итеративными).

Обычные DNS-клиенты (например, рабочие станции пользователей), как правило, посылают рекурсивные запросы.

Вариант 1 (итеративный запрос).

сначала локальный DNS-сервер ищет среди зон, за которые он отвечает, зону microsoft.com;

если такая зона найдена, то в ней ищется запись для узла www ; если запись найдена, то результат поиска сразу же возвращается клиенту;

в противном случае локальный DNS-сервер ищет запрошенное имя www.microsoft.com в своем кэше разрешенных ранее DNS-запросов;

если искомое имя есть в кэше, то результат поиска возвращается клиенту; если локальный DNS-сервер не нашел в своей базе данных искомую запись, то клиенту посылается IP-адрес одного из корневых серверов DNS;
клиент получает IP-адрес корневого сервера и повторяет ему запрос на разрешение имени www.microsoft.com;

корневой сервер не содержит в своей БД зоны «microsoft.com», но ему известны DNS-серверы, отвечающие за зону «com», и корневой сервер посылает клиенту IP-адрес одного из серверов, отвечающих за эту зону;
клиент получает IP-адрес сервера, отвечающего за зону «com», и посылает ему запрос на разрешение имени www.microsoft.com;

сервер, отвечающий за зону com, не содержит в своей БД зоны microsoft.com, но ему известны DNS-серверы, отвечающие за зону microsoft.com, и данный DNS-сервер посылает клиенту IP-адрес одного из серверов, отвечающих уже за зону microsoft.com;
клиент получает IP-адрес сервера, отвечающего за зону microsoft.com, и посылает ему запрос на разрешение имени www.microsoft.com;

сервер, отвечающий за зону microsoft.com, получает данный запрос, находит в своей базе данных IP-адрес узла www, расположенного в зоне microsoft.com, и посылает результат клиенту;

клиент получает искомый IP-адрес, сохраняет разрешенный запрос в своем локальном кэше и передает IP-адрес веб-сайта программе Обозреватель Интернета (после чего Обозреватель устанавливает связь с веб-сайтом по протоколу HTTP).

Вариант 2 (рекурсивный запрос).

Если клиент отправил серверу рекурсивный запрос, то обработка запроса происходит по такой схеме:

сначала локальный DNS-сервер ищет среди зон, за которые он отвечает, зону microsoft.com; если такая зона найдена, то в ней ищется запись для узла www ; если запись найдена, то результат поиска сразу же возвращается клиенту;

в противном случае локальный DNS-сервер ищет запрошенное имя www.microsoft.com в своем кэше разрешенных ранее DNS-запросов; если искомое имя есть в кэше, то результат поиска возвращается клиенту;
если локальный DNS-сервер не нашел в своей базе данных искомую запись, то сам локальный DNS-сервер выполняет серию итеративных запросов на разрешение имени www.microsoft.com, и клиенту посылается либо найденный IP-адрес, либо сообщение об ошибке.

Реализация службы DNS в системах семейства Windows Server

поддержка службой DNS динамической регистрации (dynamic updates);
поддержка службой DNS записей типа SRV.

Рассмотрим несколько простых примеров управления службой DNS:

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

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

сеть состоит из двух серверов Windows 2003 Server;
операционная система — ограниченная по времени 120-дневная русская версия Windows 2003 Server Enterprise Edition;
первый сервер установлен на ПК с процессором Intel Pentium-4 3Ггц и оперативной памятью 512 МБ, имя сервера — DC1, IP-адрес — 192.168.0.1/24 ;
второй сервер работает в качестве виртуальной системы с помощью Microsoft VirtualPC 2004, имя сервера -DC2, IP-адрес — 192.168.0.2/24 ;
имя домена в пространстве DNS и соответствующее имя в службе каталогов Active Directory — world.ru (сеть полностью изолирована от других сетей, поэтому в данном примере авторы были свободны в выборе имени домена; в реальной обстановке конкретного учебного заведения преподавателю нужно скорректировать данную информацию).

Секция: 01_Задачи сетевого администрирования

1)Какие компоненты из нижеперечисленных относятся к сетевым службам?

Кабельная система

Активное сетевое оборудование

Сетевые протоколы

+Служба DNS

+Служба DHCP

+Служба файлов и печати

+Служба каталогов

2)Какие компоненты из нижеперечисленных формируют сетевую инфраструктуру организации?

+Служба файлов и печати

+Сетевые протоколы

+Активное сетевое оборудование

Кабельная система

Служба каталогов

+Служба DNS

+Служба DHCP

3)На каком протоколе базируется работа сети Интернет?

+AppleTalk

IPX/SPX

TCP/IP

DLC

4)Что такое «Локальная Вычислительная Сеть» (ЛВС)?

+Кабельная система + Сетевое оборудование + Сетевые узлы (компьютеры)

Снасть для ловли рыбы в локальных водоёмах вашего региона

5)Какие элементы из нижеперечисленных являются уровнями сетевой модели OSI?

+Физический (Physical)

+Канальный (Data link)

+Сетевой (Network)

+Транспортный (Transport)

+Сеансовый (Session)

+Уровень представлений (Presentation)

+Уровень приложений (Application)

Кабельная система (Cabling system)

Сетевое оборудование (Network devices)

Сетевые протоколы (Network protocols)

6) Какие элементы из нижеперечисленных являются уровнями сетевой модели Министерства обороны США?

+Физический (Physical)

+Межсетевого обмена (Internetwork)

+Транспортный (Transport)

+Прикладной (Application)

Кабельная система (Cabling system)

Уровень презентаций (Presentation)

Секция: 02_Сетевые операционные системы (семейство Windows Server)

1)Назовите имя исполняемого файла, который инициирует процесс установки системы Windows Server (при запуске из-под 32-разрядной ОС семейства Windows)

+winnt32.exe

i386.exe

ntoskernel.exe

winsowssetup.exe

2)Под какие файловые системы можно отформатировать раздел жесткого диска, на который устанавливается система Windows Server?

+FAT

+NTFS

NFS

CDFS

FreeBSD

3)Какие операции выполняются во время текстового этапа установки системы Windows Server?

+Создание, выбор, форматирование раздела жесткого диска

+Изучение лицензионного соглашения на использование продукта

+Копирование установочных файлов

Установка драйвера сетевого адаптера

Установка драйвера видеоадаптера

Настройка сетевых параметров

4)Какие операции выполняются во время графического этапа установки системы Windows Server?

Создание, выбор, форматирование раздела жесткого диска

Загрузка драйвера дискового контроллера

+Установка драйвера сетевого адаптера

+Установка драйвера видеоадаптера

+Настройка сетевых параметров

+Назначение имени компьютера

+Назначение пароля администратора

5)На каких носителях может находиться дистрибутив операционной системы Windows Server?

+Сетевая папка

+Жесткий диск компьютера

+CD/DVD

Флоппи-диск

Магнитная лента

6)Укажите технологии, которые являются базовыми для систем семейства Windows Server

+TCP/IP (версия 4)

TCP/IP (версия 6)

+Протокол LDAP

+Служба DNS

Служба WINS

+Протокол аутентификации Kerberos

Динамические диски

Групповые политики

Секция: 03_Сетевая инфраструктура Windows Server

1)Какие типы зон DNS поддерживаются службой DNS систем семейства Wndows Server?

+Стандартная основная

+Стандартная дополнительная

+Интегрированная с Active Directory

Изолированная

2)Какие существуют типы запросов DNS?

+Рекурсивный

Ассоциативный

+Итеративный

Итеративный

3)Какая команда Windows отображает конфигурацию протокола TCP/IP?

+ipconfig

ping

netstat

tracert

nbtstat

format

4)Назначение службы DNS

+Разрешение имён узлов (хостов)

Разрешение имён NetBIOS

Настройка конфигурации протокола TCP/IP

5)Какое из данных чисел может быть IP-адресом сетевого узла?

+192.168.0.5

+11000000101010000000000000000101

-348

777.12.88.369

6)Какое число является двоичной формой записи маски подсети 255.255.255.0?

+11111111111111111111111100000000

00000000000000000000000011111111

7)Укажите минимальный набор параметров протокола TCP/IP для любого сетевого узла

+IP-адрес

+Маска подсети

Основной шлюз

Список серверов DNS

Один из сетевых узлов вашей компании имеет IP-адрес 180.10.254.36 и маску подсети 255.255.240.0 Каково значение идентификатора сети (Network ID) у данного узла?

10110100.00001001.11110000

10110100.00001010.11100000

10110110.00001010.1111

+10110100.00001010.1111

9) Если сетевой узел может обмениваться сетевыми пакетами с другими узлами в той же подсети, но не может обмениваться пакетами с узлами в других подсетях, то какой параметр данного узла вероятнее всего задан неверно?

IP-адрес

Маска подсети

+Основной шлюз

Предпочитаемый сервер DNS

10)Какие утверждения об использовании широковещательных запросов для разрешения сетевых имен верны?

+Широковещательные запросы порождают больший трафик, чем запросы к серверам DNS и WINS

+Широковещательные запросы могут разрешать ТОЛЬКО имена компьютеров, расположенных в той же IP-сети

Для использования широковещательных запросов компьютер должен иметь файл Lmhosts

Широковещательные запросы работают быстрее, чем запросы к серверам DNS и WINS

11)Укажите назначение ключа /flushdns команды ipconfig

+Очистка локального кэша разрешения имен DNS

Регистрация компьютера на сервере DNS

Очистка записей на сервере DNS

Репликация зон между серверами DNS

12)Укажите назначение ключа /registerdns команды ipconfig

Очистка локального кэша разрешения имен DNS

+Регистрация компьютера на сервере DNS

Очистка записей на сервере DNS

Репликация зон между серверами DNS

13)Опишите назначение команды netstat

+Отображение активных сетевых подключений по протоколу TCP/IP и «слушающих» портов компьютера

Отображение статистики обмена сетевых пакетов на сетевом адаптере

Отображение статистики разрешения запросов службой DNS

Настройка параметров TCP/IP на сетевом адаптере

Секция: 04_Служба каталогов Active Directory

1)Укажите элементы логической структуры Active Directory

+Лес

+Дерево

+Организационное подразделение (OU)

IP-сеть

+Домен

Сайт

2)Укажите элементы физической структуры Active Directory

Лес

Дерево

Организационное подразделение (OU)

+IP-сеть

Домен

+Сайт

3)Укажите назначение Организационных Подразделений (OU)

Назначение прав доступа к файловым ресурсам

+Делегирование административных полномочий

+Применение групповых политик

Управление репликацией в домене

4) Назовите назначение сайтов Active Directory

Оптимизация трафика репликации Active Directory

+Оптимизация доступа к веб-сайту организации

+Оптимизация процесса регистрации в домене (logon/logoff)

5)Какой командой производится повышение роли простого сервера до контроллера домена?

+dcpromo

ipconfig

nbtstat

netstat

6)Какой командой производится понижение роли контроллера домена до простого сервера?

+dcpromo

nbtstat

tracert

format

7)Какие типы Хозяев Операций функционируют только в масштабе всего леса Active Directory?

RID master

PDC emulator

+Domain Naming Master

+Schema Master

Infrastructure Master

Global Catalog

Какие типы Хозяев Операций функционируют в каждом домене Active Directory?

+RID master

+Infrastructure Master

Domain Naming Master

Schema Master

+PDC emulator

Global Catalog

9)Как называется процесс синхронизации экземпляров Active Directory на контроллерах доменов?

+Репликация

Перенос зоны

Регистрация

Экспорт/импорт данных

10)В каком порядке применяются групповые политики?

Локальная

Сайт

Домен

Организационные подразделения

11) Какая консоль позволяет выполнить принудительную репликацию контроллеров домена?

+Active Directory — Сайты и службы

Active Directory — Домены и доверия

Active Directory — Пользователи и компьютеры

DNS

DHCP

WINS

12)Из каких частей состоит каждая групповая политика?

+Компьютер

+Пользователь

Сервер

Сеть

Домен

Организационное подразделение

13)Какой тип зоны DNS для обслуживания Active Directory создается в результате работы программы dcpromo?

+Интегрированная в Active Directory

Стандартная основная

Стандартная дополнительная

Динамическая

14)На томе с какой файловой системой размещается системный том Active Directory (SYSVOL)?

FAT12

FAT16

FAT32

+NTFS

CDFS

15) Укажите особенности, характерные для доменной модели безопасности

Более простое администрирование

+Более сложное администрирование

+Централизованная БД учётных записей

Распределённая БД учётных записей

+Централизованное управление ресурсами

16)Укажите особенности, характерные для модели безопасности «Рабочая группа»

+Более простое администрирование

Более сложное администрирование

Централизованная БД учётных записей

+Распределённая БД учётных записей

Централизованное управление ресурсами

17)Какова роль службы DNS для функционирования службы каталогов Active Directory?

+Служба DNS используется для поиска компонент Active Directory

Служба DNS используется для поиска веб-сайтов

Служба DNS используется для регистрации пользователей в домене Active Directory

Служба DNS используется для репликации экземпляров БД Active Directory

Секция: 05_Управление файловыми ресурсами

1)Какие типы томов обеспечивают защиту от сбоев?

Простой том

Составной том

+Зеркальный том

+Том RAID-5

Чередующийся том

2)Какой тип тома обеспечивает максимальную производительность выполнения дисковых операций?

Чередующийся том

Простой том

Составной том

Зеркальный том

+Том RAID-5

3)Укажите минимальное количество дисков, необходимое для создания тома RAID-5

4)Какой тип диска требуется для создания отказоустойчивых томов?

Базовый

+Динамический

SCSI

IDE

5)Какие особенности НЕ являются свойствами исключительно файловой системы NTFS?

Локальные права доступа

+Сетевые права доступа

Квоты

Сжатие

Шифрование

Аудит доступа

+Дефрагментация

6) Какая команда производит преобразование файловой системы FAT в систему NTFS с сохранением данных на разделе?

+convert

format

copy

tracert

7) Какие типы томов можно создавать на динамическом диске в системах семейства Windows Server?

+Простой

+Составной

+Зеркальный

+Чередующийся

+Том RAID-5

Многостраничный

По какому принципу строится управление квотами?

+На диск, на пользователя

На диск, на группу пользователей

На папку, на пользователя

На папку, на группу пользователей

Все указанные варианты

9)С какой целью в системе Windows Server используются динамические диски?

+Для создания отказоустойчивых и высокопроизводительных дисковых конфигураций

Для создания резервных копий файловых хранилищ и баз данных

Для более оптимального управления доступом к файловым ресурсам

Для оптимального распределения нагрузки на дисковую подсистему сервера

10) По каким атрибутам файла определяется объем использованной квоты для пользователя?

+Владелец файла

+Размер файла

Дата создания файла

Дата последней модификации файла

Список управления доступом к файлу

11) С каким максимальным размером кластера на разделе/томе работает механизм сжатия данных?

+4 КБ

1 КБ

2 КБ

1 МБ

512 байт

Секция: 06_Сетевые протоколы и службы

1)Назначение протокола DHCP

Разрешение имён узлов (хостов)

Разрешение имён NetBIOS

+Настройка конфигурации протокола TCP/IP сетевых узлов

2)Назначение службы WINS

Разрешение имён узлов (хостов)

+Регистрация и разрешение имён NetBIOS

Настройка конфигурации протокола TCP/IP

Перенос DNS-зон

3)Какие функции может выполнять Служба маршрутизации и удаленного доступа?

+Подключение мобильных и домашних пользователей к корпоративной сети по коммутируемым телефонным линиям

+Создание защищенных VPN-подключений

+Маршрутизация IP-сетей

Основные сведения о DNS

Служба DNS (Domain Name System) предназначена для преобразования имен хостов в IP-адреса. Для ее функционирования используется два компонента: DNS-клиент и DNS-сервер. В Windows 2000 первый является частью стека протоколов TCP/IP и устанавливается на любой компьютер, сконфигурированный для использования этого протокола.

Правила именования доменов

При планировании пространства имен домена старайтесь придерживаться следующих правил.

Ограничивайте количество уровней домена. Обычно записи узлов должны содержать не более пяти уровней иерархии DNS. При увеличении их количества увеличивается объем задач администрирования и усложняется понимание структуры домена.
Используйте уникальные имена. Пространство имен домена не должно содержать поддомены с одинаковыми именами.
Используйте простые имена. Простые и точные имена доменов легче запоминаются и делают возможным интуитивный поиск компьютеров и сервисов, как в Интернете, так и в локальной сети. Используйте устоявшиеся имена для основных сервисов (например, www — для Web-серверов или ftp — для FTP-серверов).
Избегайте длинных имен. Компонент доменного имени не должен содержать больше 63 символов. Общая длина полного доменного имени не может превышать 255 символов. Регистр символов в доменных именах не учитывается.
Используйте в DNS-именах стандартные символы. По стандарту RFC 1035 допустимо использование следующих символов: A-Z, a-z, 0-9 и дефис (-).

Внимание!
DNS-сервер Microsoft поддерживает в доменных именах символы Unicode (согласно RFC 2044). Это позволяет использовать символы национальных алфавитов. Однако прибегнуть к этой возможности можно только в том случае, если все серверы и клиенты вашей сети поддерживают в доменных именах Unicode-символы.

Зоны и домены
Зона (zone) — отдельная непрерывная часть пространства имен домена (например, зона может содержать иерархически связанные домены fio.ru и center.fio.ru, но не center.fio.ru и net.fio.ru, т. к. эти домены не связаны друг с другом).

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

Типы зон
Все DNS-зоны можно разделить на зоны прямого и обратного просмотра. Кроме того, каждая из них может быть:

основной;
дополнительной (резервная копия основной);
интегрированной в Active Directory (специальный тип зоны, рекомендованный для обслуживания доменов Windows 2000).

Зона прямого просмотра
Зоны прямого просмотра (forward lookup zone) служат для преобразования доменных имен в IP-адреса. Для работы службы DNS-сервера на Windows 2000 необходимо наличие на нем как минимум одной такой зоны.

Зона обратного просмотра
Зоны обратного просмотра (reverse lookup zone) позволяют генерировать обратные запросы на поиск имени по IP-адресу. Эти зоны необязательны для функционирования системы DNS, но нужны для нормальной работы различных диагностических утилит (например, ping, tracert и т. п.). Зоны обратного просмотра регистрируются в домене in-addr.arpa. Поддоменам присваиваются имена, соответствующие IP-адресам сетей, причем порядок октетов в адресе изменяется на противоположный. То есть сети 192.168.0.0 соответствует домен 0.168.192.in-addr.arpa.

Основная зона
Стандартный тип зоны. Основные зоны хранятся в виде простого текстового файла, полностью совместимого с BIND (Berkeley Internet Name Daemon — стандарт DNS, использующийся на многих платформах, в том числе и на UNIX). Это позволяет легко переносить данные зоны с одного сервера на другой и вручную редактировать файлы зон.

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

Зона, интегрированная в Active Directory
Данные интегрированной зоны хранятся в Active Directory (AD), что обеспечивает максимальной уровень надежности Active Directory и DNS — внесение массовых изменений в зону затруднено, совмещение таких зон с расположенными на серверах под управлением UNIX проблематично, зоны теряются только при уничтожении AD.

Этот тип зоны недоступен, если компьютер не является членом домена Windows 2000.

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

Функция динамического обновления позволяет клиентам вносить изменения в зоны путем посылки определенных запросов DNS-серверу. В Windows 2000 динамическое обновление зон необходимо для нормальной работы Active Directory и автоматической регистрации DHCP-хостов в DNS. Динамические обновления должны поддерживаться обслуживающим зону сервером. Согласно стандарту RFC 2136, возможно изменение зоны не только вручную администратором сервера, но и автоматически приложениями, поддерживающими этот стандарт. DNS-сервер из состава Windows 2000 поддерживает Dynamic DNS (DDNS).

Файл зоны — это обычный текстовый файл, который хранится в папке %systemroot%system32DNS и может быть изменен при помощи любого текстового редактора. Ниже приведен пример файла зоны сразу после ее создания.
;
; Database file test.fio.ru.dns for test.fio.ru zone.
; Zone version: 1
;
@ IN SOA mcio-08kwa653t4.fio.ru. admin.fio.ru. (
1 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL
;
; Zone NS records
;
@ NS mcio-08kwa653t4.fio.ru.
;
; Zone records
;
Файл зоны состоит из множества записей, причем одна запись обычно занимает одну строку. Строки, начинающиеся с точки с запятой, являются комментариями и не анализируются DNS-сервером.

Любой файл зоны должен содержать как минимум следующее:

одну запись Start Of Authority (SOA), содержащую параметры зоны;
не менее одной записи Name Server (NS), содержащей адреса DNS-серверов, ответственных за хранение и обслуживание зоны;
не менее одной записи Host (A), содержащей информацию о соответствии имени DNS-сервера, указанного в каждой записи NS, его IP-адресу.

При создании и изменении зоны вы чаще всего будете использовать следующие типы записей:

Тип записи	Для чего используется
Start Of Authority (SOA)	Описывает зону и ее параметры. В файле зоны встречается однократно и не требует редактирования вручную
Name Server (NS)	Описывает один DNS-сервер
Host (A)	Описывает соответствие имени хоста его IP-адресу. Используется часто
Canonical Name (CNAME)	Описывает альтернативное имя для уже существующего хоста
Mail Exchanger (MX)	Описывает почтовый хост, обрабатывающий электронную почту домена
Pointer (PTR)	Описывает соответствие IP-адреса имени хоста. Используется в зонах обратного просмотра
Service Location (SRV)	Описывает сервисы, предоставляемые хостами

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

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

Общий синтаксис записей зон

Любая DNS-запись имеет следующий вид:
владелец [класс] [TTL] тип данные Описание полей DNS-записи приведено в таблице.

Поле	Описание
владелец	Относительное или полное имя записи. Если значение этого поля совпадает с именем зоны, то вы можете использовать символ @ вместо полного имени зоны
класс	Определяет класс, к которому принадлежит запись. Например, IN указывает, что запись принадлежит к классу записей Интернет-ресурсов. Это единственный класс записей, поддерживаемых DNS-сервером, входящим в состав Windows 2000. В связи с этим в любой записи поле класса может быть опущено, хотя стандарт DNS требует обязательного указания класса записи
TTL	Определяет время жизни конкретной записи в кэше других DNS-серверов. Является необязательным для большинства типов записей. Если поле TTL у записи опущено, то берется соответствующее значение из параметров зоны (запись SOA). Для того, чтобы предотвратить кэширование записи указывайте значение 0 в качестве TTL
тип	Обязательное поле, содержащее один из стандартных текстовых идентификаторов, определяющих тип записи
данные	Обязательное поле, содержащее данные переменной длины. Формат данных определяется типом записи

Поля записи разделяются любым количеством пробелов или символов табуляции.

Служебные записи (SOA и NS)

Каждый файл зоны должен содержать запись SOA, которая описывает зону, параметры ее синхронизации и параметры устаревания ее записей. Кроме того, зона должна содержать не менее одной записи NS, описывающей DNS-сервер [в нотации DNS они называются серверами имен (name server)], обслуживающий зону. Если серверов два или более, то один из них является основным, а все остальные — дополнительными. Все изменения в зоне производятся на основном сервере, после чего дополнительные самостоятельно получают ее измененную копию.

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

Синтаксис записи NS

Название	Name Server
Определена в	RFC 1035
Описание	Запись, указывающая один из серверов, обслуживающих зону. В виде NS-записей указываются все сервера (основной и дополнительные). Тот сервер, который указан в SOA-записи, считается основным, все остальные — дополнительными.
Синтаксис	владелец [класс] [TTL] NS хост
Параметры	Полное DNS-имя сервера, который должен быть определен в DNS. Допускается определение серверов в той же зоне, которую они обслуживают.
Пример	@ NS mcio-08kwa653t4.fio.ru @ NS host1.test.fio.ru

Название	Start Of Authority
Определена в	RFC 1035
Описание	Запись, описывающая зону ответственности.
Синтаксис	владелец класс SOA первичный_сервер ответственный (редакция обновление повтор устаревание TTL)
Параметры	Первичный сервер — полное имя сервера, содержащего основную копию зоны.

Ответственный — почтовый адрес лица, ответственного за управление зоной. Символ @ в почтовом адресе заменяется на точку.

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

Обновление — интервал в секундах, в течение которого дополнительные DNS-серверы ожидают, прежде чем отправить запрос об изменении зоны. По истечении этого интервала дополнительный DNS-сервер запрашивает запись SOA с основного, проверяет в ней поле Редакция и определяет необходимость загрузки файла зоны. По умолчанию — 900 секунд (15 минут).

Повтор — интервал в секундах, в течение которого дополнительные DNS-серверы ожидают, прежде чем произвести повторную попытку обновления зоны с основного сервера в случае неудачи предыдущей попытки. По умолчанию — 600 секунд (10 минут).

Устаревание — интервал в секундах, по истечении которого информация зоны считается устаревшей. Этот параметр используется дополнительными серверами, которые перестают отвечать на запросы после того, как пройдет указанное количество времени с момента последнего успешного обновления. По умолчанию — 86 400 секунд (24 часа).

TTL — минимальное время жизни записей зоны, для которых не указано индивидуальное значение. Используется для указания другим DNS-серверам и DNS-клиентам, в течение какого периода времени они могут кэшировать записи зоны. По умолчанию — 3 600 секунд (1 час). Пример

@ IN SOA mcio-08kwa653t4.fio.ru. admin.fio.ru. ( 1 900 600 86400 3600)

Пример служебных записей зоны:
; Database file test.fio.ru.dns for test.fio.ru zone.
; Zone version: 2541744385
;
@ IN SOA ns1.test.fio.ru. admin.fio.ru. (
2541744385 ; serial number
10800 ; refresh
3600 ; retry
604800 ; expire
86400 ) ; minimum TTL
;
; Zone NS records
;
@ NS ns1.test.fio.ru.
@ NS ns2.test.fio.ru.
@ NS ns2.fio.ru.
;
; Zone records
;
ns1 A 195.34.17.1
ns2 A 213.128.193.119

Записи хостов (A и PTR)

Для установления соответствия между именем хоста и его IP-адресом используется запись A, для обратного соответствия — запись PTR. Для одного и того же IP-адреса допустимо использование нескольких имен хостов, однако для одного IP-адреса рекомендуется использовать только одну запись PTR. Записи A используются в зонах прямого просмотра, PTR — в зонах обратного просмотра.

Синтаксис записи A

Название	Host Address
Определена в	RFC 1035
Описание	Запись, устанавливающая соответствие имени определенному IP-адресу.
Синтаксис	владелец [класс] [TTL] A IP_адрес
Параметры	IP-адрес хоста.
Пример	host1 IN A 192.168.0.1

Название	IPv6 Host Address
Определена в	RFC 1886
Описание	Запись, устанавливающая соответствие имени определенному IP-адресу версии 6.
Синтаксис	владелец [класс] [TTL] AААА IP_адрес_v6
Параметры	IP-адрес версии 6 хоста.
Пример	host2 IN AAAA 4321:0:1:2:3:4:567:89ab

Название	Pointer
Определена в	RFC 1035
Описание	Запись, устанавливающая соответствие IP-адреса доменному имени. Используется в зонах обратного просмотра
Синтаксис	владелец [класс] [TTL] PTR имя
Параметры	Полное DNS-имя хоста, соответствующего указанному IP-адресу.
Пример	1.0.168.192.in-addr.arpa PTR host1.test.fio.ru

Записи A и PTR могут быть добавлены в зону следующим образом:

можно вручную создать необходимые записи (A и PTR) для компьютеров со статическими IP-адресами;
компьютеры, работающие под управлением Windows 2000 и использующие динамические IP-адреса, самостоятельно добавляют или изменяют необходимые записи (A и PTR) в зоне;
для компьютеров, работающих под управлением более ранних версий Windows и использующих динамические IP-адреса, добавление или изменение необходимых записей (A и PTR) осуществляется DHCP-сервером из состава Windows 2000 Server.

Примечание
Записи A и PTR не требуются для всех компьютеров. Они необходимы только для компьютеров, предоставляющих свои ресурсы в совместное использование. Тем не менее при использовании домена Active Directory Windows 2000 создает запись A для каждого компьютера в домене.

Записи альтернативных имен (CNAME)

Записи альтернативных имен позволяют использовать два или более имен для одного хоста. Использование альтернативных имен отличается от использования нескольких записей A для одного IP-адреса.

Название	Canonical Name
Определена в	RFC 1035
Описание	Указывает, что владелец записи является альтернативным именем, для DNS-имени, указываемого как параметр.
Синтаксис	владелец [класс] [TTL] CNAME имя
Параметры	Полное или относительное DNS-имя хоста.
Пример	alias CNAME host1.test.fio.ru alias2 CNAME host2

Альтернативные имена используются для:

изменения имени хоста, определенного при помощи записи A;
задания привычных имен для хостов, предоставляющих определенные сервисы;
распределения нагрузки между серверами, предоставляющими один и тот же сервис.

При изменении имени хоста, которое использовалось для обращения по сети, придерживайтесь следующей последовательности.

cоздайте запись A с новым именем, указывающую на IP-адрес хоста;
cоздайте запись CNAME со старым именем, указывающую на новое имя хоста;
удалить запись A хоста со старым именем.

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

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

Рассмотрим это на примере.

Изначально в сети существовал хост, предоставляющий Web- и FTP-сервисы. Соответствующие записи зоны имели следующий вид:

host-a IN A 10.0.0.20
www IN CNAME host-a
ftp IN CNAME host-a

Со временем было принято решение переместить FTP-сервер на отдельный хост. За счет использования записей CNAME это было сделано прозрачно для пользователей:

host-a IN A 10.0.0.20
host-b IN A 10.0.0.21
www IN CNAME host-a
ftp IN CNAME host-b

Со временем нагрузка на Web-сервер возросла, и было принято решение установить дополнительный Web-сервер, разделяя нагрузку между ними, что было сделано прозрачно для пользователей за счет записей CNAME:

host-a IN A 10.0.0.20
host-b IN A 10.0.0.21
host-c IN A 10.0.0.22
www IN CNAME host-a
www IN CNAME host-c
ftp IN CNAME host-b

Внимание!
Относитесь внимательно к удалению записей CNAME, которые ссылаются на уже несуществующие записи хостов. DNS-сервер не отслеживает взаимосвязи между записями, поэтому попытки разрешения записей CNAME, ссылающихся на несуществующие хосты, могут повысить нагрузку на DNS-сервер.

Записи почтовых хостов (MX)

Записи почтовых хостов домена используются почтовыми серверами и программами для определения хоста, на который должна быть отправлена почта. При этом почтовый сервер пытается найти запись MX в домене, имя которого получается отсечением от почтового адреса имени пользователя и символа @. Например, при отправке почты на адрес user1@fio.ru, поиск записи MX будет проводиться в домене fio.ru. Записи почтовых хостов указывают серверы, которые занимаются обработкой входящей почты для соответствующего домена. При наличии нескольких записей MX почтовый сервер пытается сначала использовать запись с наименьшим приоритетом.

Синтаксис записи MX

Название	Mail eXchanger
Определена в	RFC 1035
Описание	Запись, указывающая на сервер, осуществляющий обработку и доставку входящей почты.
Синтаксис	владелец [класс] [TTL] MX приоритет хост
Параметры	Приоритет — число от 0 до 65535, определяющее приоритет сервера при наличии в зоне нескольких MX записей с одним именем. Обработка начинается с сервера с наименьшим приоритетом.

Хост — полное или относительное имя хоста почтового сервера, который должен быть определен в DNS. Пример test.fio.ru MX 10 host1.test.fio.ru @ MX 20 host1.test.fio.ru

@ IN MX 10 mailserver1
@ IN MX 20 mailserver2

Здесь будет сначала использован сервер mailserver1, а при невозможности отправить почту через него — mailserver2. Если и второй сервер будет недоступен, автору сообщения будет отправлено уведомление о невозможности доставки почты.

Записи сервисов (SRV)

Записи сервисов — это новая возможность, не так давно используемая в DNS. Однако в Windows 2000 они используются очень активно, в основном для обеспечения работы Active Directory. Вся информация о доменах AD, контроллерах доменов, серверах глобального каталога и прочих сервисах, необходимых для ее функционирования, хранится в DNS в виде записей SRV.

Синтаксис записи SRV

Название	Service locator
Определена в	RFC 2052
Описание	Запись, определяющая сервера, предоставляющие определенные сервисы.
Синтаксис	сервис.протокол.имя [класс] [TTL] SRV приоритет вес порт хост
Параметры	Сервис — символьное имя сервиса. Имена для стандартных сервисов (_telnet, _smtp и т. п.) определены в RFC 1700.

Протокол — символьное имя протокола. Обычно используются _tcp и _udp, хотя может быть использован любой протокол, определенный в RFC 1700 .

Имя — доменное имя, которое будет использовано для поиска информации о сервисах.

Приоритет — число от 0 до 65535, определяющее приоритет сервера, указываемого в поле хост , при использовании нескольких записей SRV с одинаковым именем.

Вес — число от 1 до 65535, которое в дополнение к приоритету используется для балансировки нагрузки между несколькими серверами. Значение этого поля учитывается при использовании нескольких записей SRV с одинаковыми приоритетами. Если балансировка нагрузки не используется, в качестве веса указывается 0.

Порт — число от 0 до 65535, определяющее номер порта сервера, через который предоставляется указанный сервис. Соответствие портов стандартным сервисам определено в RFC 1700 , хотя можно использовать другие невостребованные номера портов.

prchecker.info

С сервисом доменных имен уже все знакомы давным давно. Это одна из самых «полезных» служб, назначение которой даже для обычного пользователя более чем очевидно. Мало кто хорошо разбирается в том, как DNS реально работает и что стоит за «простым» разрешением имен из имени в ip-адрес (и не только). Должен признаться, что я и сам понимаю не все нюансы, поскольку по специфике своей работы каждый день с DNS не сталкиваюсь (вписывать серверы DNS в сетевые настройки не считается). Кроме того, даже если удается в чем-то разобраться, все очень быстро забывается. Ведь в корпоративной сети DNS одна их тех служб, которые настроил и забыл.

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

Общие сведения

Для начала необходимо все разложить по полочкам ¹:

«Согласно руководящим материалам (RFC-1034, RFC-1035) система доменных имен состоит из трех основных частей:

Всего множества доменных имен (domain name space)
Серверов доменных имен (domain name servers)
Клиенты DNS (Resolver-ы)»

Структура множества доменных имен представляет из себя древовидную иерархию. Чтобы не усложнять изначально достаточно простую вещь, я подобрал наиболее подходящую картинку с описанием иерархии доменных имен ²:

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

Вообще на этом канале ⁴ огромное количество уроков, которые посвящены именно DNS. Однозначно советую к просмотру. Хоть и описание типов dns-серверов есть и на Википедии ⁵, оно там плоское и только зря сводит с толку.

Вопросов кто такие dns-клиенты возникать не должно.

Если говорить про авторитативные и неавторитативные серверы, то их отличие состоит в том, что в первом случае сервер отвечает за зону, а во втором — нет. То есть неавторитативные серверы выступают в большинстве случаев только как кэширующие и могут только копировать эту зону. Это хорошо понятно из иллюстрации выше.

Есть несколько типов авторитативных dns-серверов: primary master, master, slave. Четкие различия есть только между primary master и slave. Суть в том, что в первом случае сервер стоит во главе иерархии, на нем можно производить изменения описания зоны и этот сервер никогда не будет копировать эту зону с других серверов. Slave-серверы наоборот являются лишь вторичными и копируют зону с primary master; их главная задача — балансировка нагрузки, резервирование. Определение типа серверов master для меня несколько затруднительно. На многих источниках эти серверы также называют основными:

«Описание зоны master-сервера является первичным, т.к. его создает вручную администратор зоны. Соответственно, вносить изменения в описание зоны может только администратор данного сервера. Все остальные серверы только копируют информацию с master-сервера.»

… но, с другой стороны, этому противоречит определение primary-master даже с тех же источников:

«Для того чтобы выделить сервер, который не копирует зоны ни с какого другого сервера, вводят понятие Primary Master.»

То есть по факту не на всех master-серверах можно вносить изменения в описание зоны, а только на одном единственном master-сервере, который называется primary master. В таком случае реально существует только два «статичных» типа сервера — primary master и slave. Роль master может быть у сервера лишь какой-то определенный короткий промежуток времени — когда один slave-сервер (пусть он будет назван Сервер 1) копирует информацию с другого slave-сервера (Сервер 2). В этом случае Сервер 2 имеет право называться master-сервером для Сервер 1, но это справедливо только для конкретно взятого процесса копирования зоны. Когда же Сервер 2 будет копировать описание зоны с единственного primary master, он снова будет являться slave-сервером. Это подтверждает иллюстрация с nic.ru ⁶:

000128

Вот таки размышления. Конечно все эти определения скорее запутывают, чем помогают разобраться. Надо просто иметь в виду, что есть primary master и он стоит вверху иерархии и есть все остальные. Стоит добавить, что серверы всех трех типов будут являться авторитативными, то есть ответственными за зону.

Во главе всей иерархии доменных имен стоят серверы, обслуживающие корневую зону, они называются корневыми серверами. Именно к ним в первую очередь обращаются все другие dns-серверы, если у них нет данных о каком-либо доменном имени. В иерархии доменных имен на первом рисунке в статье они находятся на уровне «.«.

Прежде чем перейти к описанию типов запросов нужно обратить внимание на ещё один важный момент — разницу между зоной и доменом. Вопрос затрагивается в публикации на Хабре ⁷:

Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.

На мой взгляд более точно и понятно сказано в статье на nic.ru, которая упоминалась в самом начале:

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

Запросы к dns-серверам бывают двух типов — рекурсивный и нерекурсивный (итеративный). Наиболее подробно принцип работы описывается ⁸ ⁹ на упомянутом выше канале Youtube. При рекурсивном запросе клиент обращается к предпочитаемому dns-серверу и тот, если не знает ответа, начинает по очереди опрашивать ответственных за зоны серверы, начиная с корневых и далее опускаясь ниже по иерархии. Исчерпывающее объяснение работы рекурсивного запроса дается в статье ¹⁰ на oszone.ru. Итеративный запрос менее распространен. В нем клиент сам по очереди опрашивает dns-серверы, начиная с корневых и т.д.. Разумеется если не найдет результаты запроса в своем кэше.

Наглядно рекурсивный ¹¹ ¹² запрос выглядит так:

recurs

а нерекурсивный ¹³:

На этом обзор основных принципов работы dns закончен. Рассмотрение типов записей dns, а также механизмов работы обратного разрешения имен (ip-адрес по dns-имени) я в рамках этой статьи я затрагивать не планировал, хотя конечно же это очень интересные темы.

Роль DNS на Windows Server

Настройка роли dns на Windows Server представляет из себя достаточно простую задачу, как и многие другие — добавил роль в диспетчере сервера, запустил визарда и все настроил. Тем не менее встречаются парадоксальные ситуации и иногда слышишь рассказы как некоторые «админы» добавляют одни и те же учетные записи пользователей по очереди на каждом контроллере домена, не имея понятия о репликации. И ведь самое страшное, что у них это получается! То есть можно сделать вывод, что контроллеры домена хоть и поддерживают один и тот же домен, но фактически друг о друге ничего не знают (иначе учетку с аналогичным именем создать бы не получилось). А ведь это может являться следствием неправильной настройки роли DNS, которая обычно всегда идет бок о бок с AD DS.

Этот раздел будет посвящен обзору лучших практик по настройке роли DNS (интегрированной в AD) на Windows Server 2012 R2, но большинство советов актуальны и для предыдущих версий ОС. Тем не менее не стоит забывать про улучшения, которые добавляются в каждой новой версии и 2012 R2 не исключение ¹⁴ ¹⁵.

Я подразумеваю, что нет никакого смысла повторять, что в каждом домене должно быть минимум два контроллера домена. Это необходимо для отказоустойчивости. Собственный ip-адрес сервера должен быть обязательно статическим ¹⁶.

Собственно сами рекомендации:

1) «If multiple DCs are configured as DNS servers, they should be configured to use each other for resolution first and themselves second» ¹⁷.

Суть в том, что, во избежание проблем с репликацией, в списке первичных dns-серверов на каждом контроллере домена первыми должны быть указаны партнеры по репликации, то есть другие контроллеры домена. Собственный адрес отдельно взятого сервера должен быть указан самым последним ¹⁸ в его списке dns-серверов. Для увеличения производительности последним в списке используйте loopback-адрес 127.0.0.1 ¹⁹ как собственный адрес сервера (но не реальный сетевой адрес адаптера), хоть и это иногда может вызывать небольшие проблемы ²⁰.

2) На клиентских системах должны использоваться только локальные dns-серверы, но никак не публичные.

В противном случае у вас могут возникнуть проблемы ²¹ с разрешением внутренних имен, хотя выход наружу будет доступен. Тем не менее в корпоративной сети у меня доступ наружу по dns портам разрешен только контроллерам домена и серверам Exchange.

Позаботьтесь о том, чтобы ваш dhcp-сервер выдавал клиентам настройки со всеми имеющимися у вас адресами серверов dns. Их может быть два, а может быть и больше, все зависит от конкретной топологии. Если у вас структура AD с множеством сайтов, то логично, чтобы по порядку сначала шли серверы сайта, в котором этот пк находится и уже только потом выдавались адреса dns-серверов других сайтов ²².

3) Если у вас домен AD, то используйте только интегрированную с AD роль DNS (AD-integrated). Прибавится достаточно много плюсов в плане безопасности, производительности и отказоустойчивости ²³.

Если говорить про отказоустойчивость, то у вас не будет единой точки отказа в виде одного primary master-сервера для вашей зоны dns (если этот сервер выйдет из строя и не будет сразу восстановлен или заменен, запросы клиентов на изменение записей обрабатываться не будут. Не то что бы это очень большая проблема для статичного парка пк, но приятного мало). К тому же администраторам не придется возиться с двумя разными схемами репликации — dns и ad ds; у более простых и понятных схем надежность возрастает в разы.

Производительность всей инфраструктуры увеличивается, поскольку все партнеры по репликации (контроллеры домена) имеют одинаковый вес и нет master- и slave- серверов. То есть, если бы запрос поступил к slave-серверу классического dns, то он должен был бы обратиться к мастеру для инициирования процесса обновления. При интегрированной в ad dns каждый контроллер домена может писать изменения в базу dns и уже дальше неспеша реплицировать их на другие контроллеры. К тому же сам по себе механизм репликации ad ds значительно быстрее.

Безопасность увеличивается благодаря защищенным динамическим обновлениям ²⁴. О DNSSEC речь тут не идет, это общая технология, хотя и в Windows есть её реализация ²⁵ ²⁶.

Из лучших практик это наверно все. Есть некоторые размышления ²⁷ касательно того, что лучше ²⁸ использовать — корневые подсказки или серверы пересылки, но это скорее личное дело админа, чем какая-то устоявшаяся практика. Помните, что к корневым серверам ваш dns-сервер выполняет итеративные запросы, а к серверам пересылки — рекурсивные, являясь по отношению к ним клиентом. Root hints сконфигурированы изначально, т.к. они едины для всей сети интернет, а forwarder’ы придется указать вручную. Единственное, что можно отметить — не указывайте в серверах пересылки публичные серверы; пусть лучше это будут dns-ресурсы вашего провайдера.

Есть также рекомендации ²⁹ ³⁰ ³¹ ³²(обязательно к прочтению) касательно автоматической очистке записей dns. В этой статье я их подробно не рассматриваю, поскольку автоматическая очистка записей по умолчанию отключена. На деле процесс настройки очень простой, но имеет колоссальные последствия ³³ для инфраструктуры в том случае, если вы не понимаете что конкретно делаете и к чему это может привести.

comments powered by HyperComments

DNS (Domain Name System, Система Доменных имен) – система, позволяющая преобразовать доменное имя в IP-адрес сервера и наоборот.

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

Как настроить DNS-сервер:

Настройка сетевого адаптера для DNS-сервера
Установка роли DNS-сервера
Создание зоны прямого просмотра
Создание зоны обратного просмотра
Создание A-записи
Описание функции Domain Name System (DNS), которые являются новыми или измененными в Windows Server 2016.

Настройка сетевого адаптера для DNS-сервера

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

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

Наведя курсор на значок сети в системном трее, можно вызвать всплывающую подсказку с краткими сведениями о сетях. Из примера выше видно, что присоединённая сеть это Network 3.

Далее предстоит проделать цепочку действий:

Нажать правой клавишей мыши Пуск, в выпадающем меню выбрать пункт Сетевые подключения;
Правой кнопкой мыши нажать на необходимый сетевой адаптер, в меню выбрать Свойства;
В окне свойств выбрать IPv4 и нажать на кнопку Свойства;
Заполнить соответствующие поля необходимыми данными:

Здесь в качестве предпочитаемого DNS-сервера машина назначена сама себе, альтернативным назначен dns.google [8.8.8.8].

Установка роли DNS-сервера

Для установки дополнительных ролей на сервер используется Мастер Добавления Ролей и Компонентов, который можно найти в Диспетчере Сервера.

На верхней навигационной панели Диспетчера сервера справа откройте меню Управление, выберите опцию Добавить Роли и Компоненты:

Откроется окно Мастера, в котором рекомендуют убедиться что:

1. Учётная запись администратора защищена надёжным паролем.

2. Настроены сетевые параметры, такие как статические IP-адреса.

3. Установлены новейшие обновления безопасности из центра обновления Windows.

Убедившись, что все условия выполнены, нажимайте Далее;

Выберите Установку ролей и компонентов и нажмите Далее:

Выберите необходимы сервер из пула серверов и нажмите Далее:

Отметьте чек-боксом роль DNS-сервер и перейдите Далее:

Проверьте список компонентов для установки, подтвердите нажатием кнопки Добавить компоненты:

Оставьте список компонентов без изменений, нажмите Далее:

Прочитайте информацию и нажмите Далее:

В последний раз проверьте конфигурацию установки и подтвердите решение нажатием кнопки Установить:

Финальное окно Мастера сообщит, что установка прошла успешно, Мастер установки можно закрыть:

Создание зон прямого и обратного просмотра

Доменная зона — совокупность доменных имён в пределах конкретного домена.

Зоны прямого просмотра предназначены для сопоставления доменного имени с IP-адресом.

Зоны обратного просмотра работают в противоположную сторону и сопоставляют IP-адрес с доменным именем.

Создание зон и управление ими осуществляется при помощи Диспетчера DNS.

Перейти к нему можно в правой части верхней навигационной панели, выбрав меню Средства и в выпадающем списке пункт DNS:

Создание зоны прямого просмотра

Выделите каталог Зоны Прямого Просмотра, запустите Мастер Создания Новой Зоны с помощью кнопки Новая зона на панели инструментов сверху:

Откроется окно Мастера с приветствием, нажмите Далее:

Из предложенных вариантов выберите Основная зона и перейдите Далее:

Укажите имя зоны и нажмите Далее:

При необходимости поменяйте название будущего файла зоны и перейдите Далее:

Выберите, разрешить динамические обновления или нет. Разрешать не рекомендуется в силу значимой уязвимости. Перейдите Далее:

Проверьте правильность выбранной конфигурации и завершите настройку, нажав кнопку Готово:

Создание зоны обратного просмотра

Выделите в Диспетчере DNS каталог Зоны Обратного Просмотра и нажатием кнопки Новая зона на панели инструментов сверху запустите Мастер Создания Новой Зоны:

Выберите тип Основная Зона, перейдите Далее:

Выберите назначение для адресов IPv4, нажмите Далее:

Укажите идентификатор сети (первые три октета сетевого адреса) и следуйте Далее:

При необходимости поменяйте название будущего файла зоны и перейдите Далее:

Выберите, разрешить динамические обновления или нет. Разрешать не рекомендуется в силу значимой уязвимости. Перейдите Далее:

Проверьте правильность выбранной конфигурации и завершите настройку, нажав кнопку Готово:

Создание A-записи

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

Ресурсная запись — единица хранения и передачи информации в DNS, заключает в себе сведения о соответствии какого-либо имени с определёнными служебными данными.

Запись A — запись, позволяющая по доменному имени узнать IP-адрес.

Запись PTR — запись, обратная A записи.

В Диспетчере DNS выберите каталог созданной ранее зоны внутри каталога Зон Прямого Просмотра. В правой части Диспетчера, где отображается содержимое каталогов, правой кнопки мыши вызовите выпадающее меню и запустите команду «Создать узел (A или AAAA)…»:

Откроется окно создания Нового Узла, где понадобится вписать в соответствующие поля имя узла (без доменной части, в качестве доменной части используется название настраиваемой зоны) и IP-адрес. Здесь же имеется чек-бокс Создать соответствующую PTR-запись — чтобы проверить работу обеих зон (прямой и обратной), чек-бокс должен быть активирован:

Если поле имени остается пустым, указанный адрес будет связан с именем доменной зоны.

Также можно добавить записи для других серверов:

Добавив все необходимые узлы, нажмите Готово.

Проверка

Проверьте изменения в каталогах обеих зон (на примере ниже в обеих зонах появилось по 2 новых записи):

Откройте командную строку (cmd) или PowerShell и запустите команду nslookup:

Из вывода команды видно, что по умолчанию используется DNS-сервер example-2012.com с адресом 10.0.1.6.

Чтобы окончательно убедиться, что прямая и обратная зоны работают как положено, можно отправить два запроса:

Запрос по домену;
Запрос по IP-адресу:

В примере получены подходящие ответы по обоим запросам.

Можно попробовать отправить запрос на какой-нибудь внешний ресурс:

В дополнение к имени домена и адресам появилась строчка «Non-authoritative answer», это значит, что наш DNS-сервер не обладает необходимой полнотой информации по запрашиваемой зоне, а информация выведенная ниже, хоть и получена от авторитетного сервера, но сама в таком случае не является авторитетной.

Для сравнения все те же запросы выполнены на сервере, где не были настроены прямая и обратная зоны:

Здесь машина сама себе назначена предпочитаемым DNS-сервером. Доменное имя DNS-сервера отображается как неопознанное, поскольку нигде нет ресурсных записей для IP-адреса (10.0.1.7). По этой же причине запрос 2 возвращает ошибку (Non-existent domain).

Описание функции Domain Name System (DNS), которые являются новыми или измененными в Windows Server 2016.

В Windows Server 2016 DNS-сервер предлагает обновления в следующих областях:

Политики DNS-серверов
Ограничение скорости отклика (RRL)
Аутентификация именованных объектов на основе DNS (DANE)
Поддержка неизвестных записей
Корневые подсказки IPv6
Доработка поддержки Windows PowerShell

Политики DNS-серверов

Теперь вы сможете использовать:

DNS-политики для управления трафиком на основе геолокации
Интеллектуальные ответы DNS в зависимости от времени суток, для управления одним DNS-сервером, настроенным для развертывания с разделением
Применять фильтры к DNS-запросам и многое другое.

Конкретное описание данных возможностей:

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

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

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

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

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

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

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

Ограничение скорости отклика (RRL)

Теперь вы cможете настроить параметры RRL, чтобы контролировать, как отвечать на запросы к DNS-клиенту, когда ваш сервер получает несколько запросов, направленных на одного и того же клиента. Сделав это, вы можете предотвратить отправку атаки типа «Отказ в обслуживании» (Dos) с использованием ваших DNS-серверов.
Например, бот-сеть может отправлять запросы на ваш DNS-сервер, используя в качестве отправителя IP-адрес третьего компьютера. Без RRL ваши DNS-серверы могут отвечать на все запросы, переполняя третий компьютер. При использовании RRL вы можете настроить следующие параметры:

Количество ответов в секунду. Это максимальное количество раз, когда один и тот же ответ дается клиенту в течение одной секунды.

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

Окно между запросами. Это количество секунд, на которое приостанавливаются ответы клиенту, если сделано слишком много запросов.

Скорость утечки. Это то, как часто DNS-сервер отвечает на запрос во время приостановки ответов. Например, если сервер приостанавливает ответы клиенту на 10 секунд, а уровень утечки равен 5, сервер по-прежнему отвечает на один запрос на каждые 5 отправленных запросов. Это позволяет обычным клиентам получать ответы, даже если DNS-сервер применяет ограничение скорости ответов в их подсети или полном доменном имени.

TC rate. Эта функция используется, чтобы сообщить клиенту о попытке соединения с TCP, когда ответы клиенту приостановлены. Например, если скорость TC равна 3, и сервер приостанавливает ответы данному клиенту, сервер выдает запрос на TCP-соединение для каждых 3 полученных запросов. Убедитесь, что значение скорости TC ниже, чем скорость утечки, чтобы дать клиенту возможность подключиться через TCP перед утечкой ответов.

Максимум откликов. Это максимальное количество ответов, которые сервер выдает клиенту, пока ответы приостановлены.

Белые домены. Это список доменов, которые нужно исключить из настроек RRL.

Белые подсети. Это список подсетей, которые необходимо исключить из настроек RRL.

Интерфейсы серверов белого списка. Это список интерфейсов DNS-серверов, которые необходимо исключить из настроек RRL.

Аутентификация именованных объектов на основе DNS (DANE)

Теперь вы сможете использовать поддержку DANE (RFC 6394 и 6698), чтобы указать своим DNS-клиентам, от какого CA они должны ожидать выдачи сертификатов для доменных имен, размещенных на вашем DNS-сервере.
Это предотвращает форму атаки «main in the middle», когда кто-то может повредить кэш DNS и указать DNS-имя на свой собственный IP-адрес.

Поддержка неизвестных записей

«Неизвестная запись» — это RR, формат RDATA которой неизвестен DNS-серверу. Недавно добавленная поддержка неизвестных типов записей (RFC 3597) означает, что вы cvожете добавлять неподдерживаемые типы записей в зоны DNS-сервера Windows в двоичном формате по сети.
Распознаватель кэширования Windows уже имеет возможность обрабатывать неизвестные типы записей. DNS-сервер Windows не выполняет никакой конкретной обработки неизвестных записей, но отправляет их обратно в ответах, если для них получены запросы.

Корневые подсказки IPv6

Корневые подсказки IPV6, опубликованные IANA, были добавлены на DNS-сервер Windows. Запросы имен в Интернете теперь могут использовать корневые серверы IPv6 для разрешения имен.

Доработка поддержки Windows PowerShell

В Windows Server 2016 представлены следующие новые командлеты (cmdlets) и параметры Windows PowerShell:

Add-DnsServerRecursionScope — Этот командлет создает новую область рекурсии на DNS-сервере. Области рекурсии используются политиками DNS для указания списка серверов пересылки, которые будут использоваться в запросе DNS.

Remove-DnsServerRecursionScope — Этот командлет удаляет существующие области рекурсии.

Set-DnsServerRecursionScope — Этот командлет изменяет параметры существующей области рекурсии.

Get-DnsServerRecursionScope — Этот командлет извлекает информацию о существующих областях рекурсии.

Add-DnsServerClientSubnet — Этот командлет удаляет существующие подсети DNS-клиентов.

Set-DnsServerClientSubnet — Этот командлет изменяет параметры существующей подсети DNS-клиента.

Get-DnsServerClientSubnet — Этот командлет извлекает информацию о существующих подсетях DNS-клиентов.

Add-DnsServerQueryResolutionPolicy — Этот командлет создает новую политику разрешения запросов DNS. Политики разрешения запросов DNS используются для указания того, как и следует ли отвечать на запрос на основе различных критериев.

Remove-DnsServerQueryResolutionPolicy — Этот командлет удаляет существующие политики DNS.

Set-DnsServerQueryResolutionPolicy — Этот командлет изменяет параметры существующей политики DNS.

Get-DnsServerQueryResolutionPolicy — Этот командлет извлекает информацию о существующих политиках DNS.

Enable-DnsServerPolicy — Этот командлет включает существующие политики DNS.

Disable-DnsServerPolicy — Этот командлет отключает существующие политики DNS.

Add-DnsServerZoneTransferPolicy — Этот командлет создает новую политику передачи зоны DNS-сервера. Политики передачи зоны DNS определяют, следует ли отклонять или игнорировать передачу зоны на основе различных критериев.

Remove-DnsServerZoneTransferPolicy — Этот командлет удаляет существующие политики передачи зон DNS-сервера.

Set-DnsServerZoneTransferPolicy. — Этот командлет изменяет параметры существующей политики переноса зоны DNS-сервера.

Get-DnsServerResponseRateLimiting — Этот командлет извлекает параметры RRL.

Set-DnsServerResponseRateLimiting — Этот командлет изменяет настройки RRL.

Add-DnsServerResponseRateLimitingExceptionlist — Этот командлет создает список исключений RRL на DNS-сервере.

Get-DnsServerResponseRateLimitingExceptionlist — Этот командлет извлекает списки исключений RRL.

Remove-DnsServerResponseRateLimitingExceptionlist — Этот командлет удаляет существующий список исключений RRL.

Set-DnsServerResponseRateLimitingExceptionlist — Этот командлет изменяет списки исключений RRL.

Add-DnsServerResourceRecord — Этот командлет был обновлен для поддержки неизвестного типа записи.

Get-DnsServerResourceRecord — Этот командлет был обновлен для поддержки неизвестного типа записи.

Remove-DnsServerResourceRecord — Этот командлет был обновлен для поддержки неизвестного типа записи.

Set-DnsServerResourceRecord — Этот командлет был обновлен для поддержки неизвестного типа записи.

С дополнительными сведениями вы можете ознакомится в следующих разделах справочника по командам Windows PowerShell для Windows Server 2016 от Microsoft:
Powershell DNS Server
Powershell DNS Client

Содержание

Понятие роли DNS Server
Установка DNS
Конфигурирование автономного DNS-cepвepa
Интеграция с другими DNS-серверами
Реализация зон для управления пространствами имен
Типы записей
Управление клиентами DNS и преобразованием имен
Система DNS в Active Directory
Автоматическое конфигурирование DNS
Записи SRV и клиенты
Дополнительные компоненты Windows Server 2012 R2
Поддержка преобразования имен DNS на основе Интернета
Поддержка внешних доменов DNS
Преобразование внешних пространств имен
Администрирование и устранение неполадок с помощью инструментов DNS
Администрирование DNS-cepвepa с помощью консоли управления DNS и PowerShell
Использование NsLookup и DcDiag
Полезные ссылки по устранению неполадок в DNS

Компьютеры взаимодействуют друг с другом с использованием IР-адресов,
либо 1 Pv4, либо 1 Pv6. Тем не менее, большинству людей трудно запомнить
IР-адрес излюбленного веб-сайта или файлового сервера. Людям нравится приме
нять дружественные текстовые имена. Таким образом, для преобразования этих дружественных имен компьютеров в назначенные им I Р-адреса реализуются системы имен. Система доменных имен (Domain Name System — DNS) — это система имен, используемая серверами Windows Server 2012 R2. Система DNS не только помогает пользователям легко идентифицировать устройства, она является обязательной для множества служб, таких как Active Directory, чтобы клиенты и серверы могли взаимодействовать с контроллерами доменов.
В этой главе вы изучите следующие темы:
• фундаментальные компоненты и процессы DNS;
• конфигурирование DNS для поддержки среды Active Directory;
• управление и устранение неполадок с преобразованием имен DNS для внут
ренних и внешних имен.

Система DNS существовала на протяжении десятилетий до того, как в Microsoft
разработали свою первую редакцию DNS в Windows NT 4.0. Существует много раз
новидностей реализаций DNS, которые поддерживают компоненты и процессы, определяющие DNS. В этом разделе мы раскроем концепции системы доменных имен от Microsoft и покажем, как она применяется в операционных системах Windows.
Система DNS реализована внутри ОС Windows Server 201 2 R2 для управления
преобразованием имен в I Р-адреса. После установки на сервере службе DNS по
надобится взаимодействовать с другими серверами имен DNS, что достигается с
использованием множества разных методов, таких как переадресация, корневые
подсказки и делегирование. Служба DNS будет также поддерживать базы данных,
называемые зонами, для внутреннего домена Active Directory или других пространств имен. Компьютерам домена необходимо будет опрашивать эту службу DNS, поэтому вам придется сконфигурировать отдельные компьютеры, чтобы обеспечить эффективное и быстрое преобразование имен.
Windows Server 2012 R2 и предыдушие выпуски ОС Windows Server предлагают
встроенную роль DNS Server (DNS-cepвep). Система Windows Server 201 2 R2 DNS
совместима со старыми версиями DNS вплоть до Windows Server 2003; однако версии, более ранние, чем Windows Server 2008, не поддерживают 1Pv6 и функционируют только с адресами IPv4.
Ниже приведена краткая сводка по фундаментальным концепциям DNS, имею
щим отношение к данной главе.
• Имя хоста (hostname). Это (дружественное) имя компьютера. Согласно стан
дартам DNS, оно может иметь длину до 255 символов. Имя хоста эквиваflент
но первому имени компьютера, например, ECOl.
• Пространство имен (namespace). Это имя домена, хотя и не обязательно доме
на Active Directory. Пространство имен представляет собой логический набор
хостов, обозначенных именем, которое управляется набором серверов имен.
Это эквивалент второго имени компьютера; все они являются частью одного
семейства. Например, Bigfirm. com — пространство имен для хостов в домене
Bigfirm. com.
• Полное имя домена (Fully Qualified Domain Name — FQDN). Ичя FQDN —
это имя хоста, к которому добаrшено пространство имен домена, такое как
ECOl . Bigfirm. com.
• Файл ноsтs. Это текстовый файл, в котором имена хостов статически отоб
ражаются на IР-адреса. Файл HOSTS расположен в с : windowssystem32
driversetc для стандартных установок Windows Server 2012 R2 и может при
меняться в качестве простейшей альтернативы DNS-cepвepy для преобразо
вания имен в небольших средах. Тем не менее, не пытайтесь управлять круп
ными производственными средами с помощью записей в статическом файле
ноsтs, поскольку это быстро превратится в кошмар администрирования!
• Сервер имен (name server). Это DNS-cepвep, который будет преобразовывать
имена FQDN в IР-адреса. Серверы имен также управляют пространствами
имен для указанных доменов. Они будут обрабатывать запросы для этих про
странств имен, поступающие от клиентов DNS через сеть.
• Иерархическая структура имен (blerarchical naming stгucture). Пространство имен создано, поэтому левой частью имени является подмножеством правой части
имени, как можно видеть в FQDN. С учетом этого сервера имен могут начи
нать с правой части имени, а ответы от серверов имен направят его на коррек
тный сервер имен для заданноrо пространства имен. Например, как показано
на рис. 6. 1 , Ес0 1 . Ecoast . Bigfirm. com является именем FQDN для сервера в домене Ecoast . Bigfirm. com. Данный домен в действительности представляет собой подмножество, или поддомен, находящееся под контролем домена Bigfirm. com. То же самое можно сказать
о Bigfirm. com в отношении имени доме
на верхнего уровня . com. Достоинство за
ключается в том, что вы можете запросить
у сервера доменных имен . com, где на
ходится сервер имен Bigfirm. com. То же
самое можно делать для сервера Ecoast .
Bigfirm. com и т.д. Имя FQDN направля
ет запрос правильному серверу имен пос
редством процесса, который называется
рекурсией.
Домен .com
Д о мен Bi g firm.com
+ Рекурсия (recursion). Это управляемый
сервером процесс преобразования имени
FQDN. Если сервер не может распознать
имя FQDN посредством собственной ин-
формации, он отправит запрос другим
Рис. 6.1 . Иерархическое именова-
ние DNS
серверам имен. В процесс рекурсии вовле-
чены корневые серверы и серверы имен доменов. Корневые серверы находят
ся на верхушке иерархической структуры имен. Корневые серверы содержат
списки серверов имен, которые управляют именами доменов верхнего уровня,
такими как . com, . gov и . edu. Серверы доменов верхнего уровня управля
ют реестром поддоменов, расположенных в иерархии ниже доменов верхнего
уровня. Например, серверы имен для поддомена Sybex. com зарегистрированы
на серверах домена . com. Н иже описаны действия, которые происходят при
поступлении запроса имени (рис. 6.2).
Корневой («.») DNS-cepвep
DNS-cepвep Sybex.com
www .Sybex.com
DNS-клиент
Рис. 6.2. Процесс рекурсии в DNS

. Клиент DNS запрашивает у DNS-cepвepa имя, подобное www . Sybex . com.
2. Через процесс рекурсии DNS-cepвep запрашивает у корневых серверов сер
веры имен домена . com.
3. Корневые серверы предостамяют список серверов имен Дll Я домена . com.
4. DNS-cepвep запрашивает у серверов домена . com серверы имен ДllЯ Sybex .
com.
5. Он получает еще один список серверов имен Дll Я домена Sybex. com.
6. DNS-cepвep запрашивает у предоставленных серверов имен FQDN-имя
www. Sybex . com.
7. DNS-cepвep Sybex . com выдает I Р-адрес веб-сервера исходному DNS
cepвepy.
8. Исходный DNS-cepвep передает IР-адрес клиенту.
9. Располагая этим 1 Р-адресом, клиент подключается к веб-серверу www .
Sybex . com.
• Делеrирование (delegation). Это означает разрешение другому серверу имен
управлять поддоменом заданного пространства имен. Например, серве
ры имен Bigfirm. com могут делегировать управление пространством имен
Ecoast . Bigfirm. com другому серверу.
• Переадресация (forwarding). Это является альтернативой процессу рекурсии.
Переадресация представляет собой ответвленный запрос к другому серверу
имен внугри сети. Сервер, на который бьша произведена переадресация, полу
чает ответ и ретранслирует его исходному серверу имен.
• Итерация (iteration). Это управляемый клиентом процесс преобразования име
ни FQDN. Если клиент получает отрицательный ответ от сервера имен, он бу
дет запрашивать другой сервер имен.
• Система имен NetBIOS (NetBIOS naming system). Эта унаследованная система
имен использовалась главным образом в старых сетях Microsoft NT 4.0. Тем не
менее, ее процессы по-прежнему являются частью современных операцион
ных систем Windows, особенно когда применяются компьютеры, входящие не
в домен, а в рабочую группу.
• Записи служб (service records). Записи служб (SRV) представляют собой записи
внутри пространства имен DNS, предназначенные мя преобразования службы
в имя хоста. Они являются неоrьемлемой частью поддержки DNS мя Active
Directory.
• Динамическое обновление DNS (dynamic DNS update). Динамическое обновле
ние DNS (Dynamic DNS — DDNS) — это процесс, который позволяет кли
ентам DNS регистрировать свои имена хостов в назначенном пространстве
имен, Т’Jком как DHCP. Это сокращает необходимость ручного ввода записей
администраторами в базы данных серверов имен. Динамическое обновление
DNS является еше одной неотъемлемой частью поддержки DNS для Active
Directory.

Установка DNS

Роль DNS для Windows Server 2012 R2 может быть развернута в нескольких отличающихся конфиrурациях, зависящих от выбранного сценария. Можно установить автономный DNS-cepвep на компьютере, не присоединенном к домену, или же можно развернуть его либо на серверах-членах домена, либо на серверах, являющихся контроллерами домена Active Directory. Какой бы сценарий не был выбран, установка роли DNS проста. Сначала мы покажем, что понадобится сделать для ручного развертывания DNS на компьютере, не присоединенном к домену, в автономной конфиrурации. Затем мы объясним, как автоматически сконфиrурировать DNS для интеграции с Active Directory, чтобы обеспечить гладкое выполнение преобразования имен внутри среды домена.

Конфигурирование автономного DNS-cepвepa

Самое важное: вы должны выделить серверу, на котором хотите установить
роль DNS, статический IР-адрес, поскольку попадать в движущуюся цель клиенту
DNS будет очень непросто! Если на рабочем столе вы нажмете комбинацию кла
виш <Ctrl+R>, а затем введете ncpa. cpl и нажмете , откроется окно Network
Connections (Подключения к сети). В этом окне можно щелкнуть правой кнопкой на сетевом адаптере и выбрать в контекстном меню пункт Properties (Свойства), чтобы открыть окно конфигурирования. Если вы дважды щелкнете на элементе lnternet Protocol Version 4 (TCP/1Pv4) (Протокол Интернета версии 4 ((TCP/1Pv4))), откроется
диалоговое окно lnternet Protocol Version 4 (TCP/1Pv4) Properties (Свойства протокола Интернета версии 4 (TCP/1Pv4)). В нем можно назначить статический IР-адрес, как показано на рис. 6.3.
После назначения статического 1 Р-адреса вы должны добавить первичный DNS
суффикс, такой как Bigf i rm . com, в диалоговом окне Advanced TCP/1Pv4 Settings
(Расширенные настройки TCP/1Pv4), как показано на рис. 6.4.

Добавление первичного DNS-суффикса требуется не всегда. Он модифицируется
автоматически, когда компьютер присоединяется к домену. Если по плану сервер
должен функционировать как часть рабочей группы (в рассматриваемом примере
так и есть), первичный DNS-суффикс необходимо добавить, чтобы другие DNS
cepвepы могли находить этот сервер внутри структуры DNS, а служба DNS была
корректно сконфигурирована во время установки.
После указания статического IР-адреса и DNS-суффикса на сервере, не при
соединенном к домену, выполните перечисленные ниже шаги для установки роли DNS.
l . Откройте диспетчер серверов щелкните на элементе Dashboard (Управляющая
панель) и затем щелкните на ссылке Add Roles and Features (Добавить роли и
компоненты),

2. На экране Before You Begin (Прежде чем начать) мастера добавления ролей и
компонентов (Add Roles and Features Wizard) щелкните на кнопке Next (Далее),
чтобы продолжить.
3. На экране Select lnstallation Туре (Выбор типа установки) выберите переклю
чатель Role-Based or Feature-Based installation (Установка на основе ролей или
на основе компонентов) и щелкните на кнопке Next.
4. На экране Select Destination Server (Выбор сервера назначения) мастера выберите переключатель Select а Server from the Server Pool (Выбрать сервер из пула серверов) и удостоверьтесь в том, что ваш сервер отмечен; щелкните на кнопке Next.
5. На экране Select Server Roles (Выбор серверных ролей) мастера отметьте флажок возле роли DNS Server (DNS-cepвep) и, если после выбора роли DNS
Server откроется диалоговое окно, щелкните в нем на кнопке Add Features
(Добавить компоненты), как показано на рис. 6.6.
6. На всех последующих экранах щелкайте на кнопке Next, пока не достигнете
экрана Confirm lnstallation Selections (Подтверждение выбранных настроек для
установки). Проверьте, все ли выбранные настройки корректны, и щелкните
на кнопке lnstall (Установить), чтобы начать процесс установки.

7. После завершения установки роли DNS Server щелкните на кнопке Close Закрыть) для закрытия окна мастера.
Установка роли подобным образом приводит к созданию изолированного серве
ра имен DNS, который взаимодействует только с корневыми серверами Интернета.
Он может поддерживать среду локальной вычислительной сети для преобразова
ния имен Интернета, но на этом и все. Система доменных имен использует другие серверы имен для преобразования имен по всей структуре DNS. По этой причине вы должны будете сконфигурировать сервер на взаимодействие с другими DNS серверами, которые существуют во внутренней сети. Хотя настройка DNS-cepвepa в автономной конфиrурации без присоединения к домену может иметь свои преимущества (вроде его развертывания в средах, где управление многочисленными статическими файлами ноsтs на серверах становится мучительным), действительная мощь системы Windows Server 201 2 R2 DNS проявляется при ее применении с Active Directory.

Интеграция с другими DNS-серверами

В разделе «Понятие роли DNS Server» упоминалось, что существуют разные ме
тоды для преобразования имен DNS, такие как переадресация, рекурсия, делегиро
вание и итерация. Эти методы относятся к интеграции с другими DNS-серверами.
Прежде чем начать, вспомните, что итерация по существу управляется клиентом.
Если DNS-cepвep не имеет ответа, клиент перейдет на другой DNS-cepвep. Сервер
или клиент можно настроить только на итерацию, но это не делается по умолчанию
и редко реализуется. Другие три приема — переадресация, рекурсия и делеrирова
ние — предусматривают взаимодействие запрашиваемого DNS-cepвepa с другими
D N S-серверами.
Рекурсия — это главный процесс, происходящий в Интернете. Запрашиваемый
DNS-cepвep начинает с самого верха и проходит вниз по ссылкам, получаемым от
каждого DNS-cepвepa, с которым он взаимодействует. На серверах Windows DNS
серверы верхнего уровня перечислены на вкладке Root Hiпts (Корневые подсказки)
диалогового окна свойств DNS-cepвepa (рис. 6.7). Это окно можно отобразить в
оснастке DNS Maпagemeпt (Управление DNS), щелкнув правой кнопкой мыши на
значке сервера и выбрав в контекстном меню пункт Properties (Свойства). По умол
чанию список Name servers (Серверы имен) на вкладке Root Hiпts заполнен «действующими» DNS-серверами из Интернета.
Roo t hnts resofve queries for zones that do not exist оп the 1оса1 DNS
serve- . lhey are ony used tf furwarders l>.EDU
О. ROOT-SERVERS . NЕТ.
;
; f o rmerly NS. NASA.GOV
Е. ROOT-SERVERS. NЕТ.
3600000
3600000
360000 0
36000 00
360000 0
36000 00
36000 00
36000 00
3600000
3600000
IN NS А. ROOT-SERVERS . NET.
д 198.41.0.4
NS В. ROOT -SERVERS. NET.
д 192 . 228. 79. 201
NS С . ROOT-SERVERS .NЕТ.
д 192. ЗЗ.4.12
NS О. ROOT-SERVERS .NET.
д 126.8.10.90
NS Е . ROOT -SERVERS.NEТ.
А 192.203.230.10
Рис. 6.8. Список корневых подсказок в файле cache . dns

В единственной среде домена Active Directory это можно оставить в том виде, как
есть. DNS-cepвepы могут использовать эти ссылки для распознавания пространств
имен, основанных на Интернете, таких как Sybex . сот, когда клиент их запраши
вает. В более крупных средах корневые подсказки на других серверах DNS можно
удалить и полагаться на поддержку одного сервера в преобразовании имен DNS из внешней среды. В сущности это мог бы быть кеширующий DNS-cepвep для внутренней структуры.
В то время как корневые подсказки управляют запросами, следующими вверх по
иерархической структуре DNS, делегирование управляет запросами, проходящими вниз. В рассматриваемом примере DNS-cepвepaм, которые управляют пространством имен . сот, делегируется контроль над зарегистрированными поддоменами вроде Sybex . сот. Делегирование представляет собой просто список этих серверов.
Таким образом, сервер имен . сот отправляет список серверов имен DNS-cepвepy,
ищущему пространство имен Sybex . сот.
В среде Windows делегирование можно увидеть в действии с множеством доменов Active Directory. При наличии домена Active Directory по имени Bigfirт . сот вы имеете связанное с ним пространство имен DNS под названием Bigfirт. сот. Вы могли бы создать домен Active Directory по имени Ecoast . Bigfirт. сот. Вместо
того чтобы хранить все пространства имен DNS на DNS-cepвepe Bigfirт. сот, вы
можете делегировать пространство имен DNS под названием Ecoast . Bigfirт. сот другому DNS-cepвepy.
На рис. 6.9 такое делегирование демонстрируется в консоли управления
DNS. В DNS-cepвepe по имени осо 1 поддерживается зона прямого просмот
ра Bigfirт. сот. Поддомен Ecoast, представленный значком с папкой серого
цвета с текстовым файлом поверх него, содержит только запись сервера имен для
ECl . Ecoast . Bigfirт. сот с его I Р-адресом.
Сервер пересылки — это еще один DNS-cepвep для обработки ответвленного за
проса. Когда серверу не удается преобразовать имя DNS, он может переадресовать
запрос другому DNS-cepвepy, а не проходить по корневым подсказкам.
Во внуrренней среде DNS серверы пересылки могут применяться дЛЯ распознава
ния других пространств имен. Например, DNS-cepвepy ECl . Ecoast . Bigfirm. com
необходимо распознавать серверы Bigfirm . com и другие пространстоа имен, по
этому на вкладке Forwarders (Серверы пересылки) окна его свойств указан сервер
пересылки (рис. 6.10).
На рис. 6. 10 обратите внимание на флажок Use root hints if по forwarders are
availaЫe (Использовать корневые подсказки, если нет доступных серверов пересылки). В более крупной среде его можно не отмечать, если необходимо централизовать DNS-запросы, основанные на Интернете. Кроме того, взгляните на текст, касающийся серверов условной пересылки.
Серверы условной пересылки имеют собственный узел в дереве областей внутри
левой панели окна DNS Manager (Диспетчер DNS). Для управления распознава
нием конкретного пространства имен сервер условной пересылки может направ
лять запросы определенному серверу. На рис. 6. 1 1 видно, что сервер условной
пересылки был настроен для пространства имен Otherdomain . local. В резуль
тате любые запросы к этому пространству имен будут передаваться DNS-cepвepy
OSOl . Otherdomain . local.
Серверы условной пересылки создаются путем щелчка правой кнопкой мыши
на папке Conditional Forwarder (Сервер условной пересылки) в консоли управления DNS и выбора в контекстном меню пункта New Conditional Forwarder (Новый сервер условной пересылки). Откроется диалоговое окно New Conditional Forwarder (Новыйсервер условной пересылки), которое предоставит вариант репликации настройки другим контроллерам домена в домене или лесе с использованием разделов каталога приложений Active Directory.
Переадресация также может применяться дЛЯ обработки запросов, основанных
на Интернете, вместо использования корневых подсказок.
Мы предпочитаем поступать так в небольших средах, обслуживаемых поставши
ком Интернет-услуг посредством кабеля или цифровой абонентской линии (Digital
Subscriber Liпe — DSL). Эти поставщики Интернет-услуг имеют собственные DNS
cepвepы, которые находятся в конфигурации маршрутизатора. Таким образом, ониуказаны как серверы пересылки во внутренних серверах DNS. Хотя корневые подсказки и могут работать в такой среде, мы считаем прием с переадресацией более надежным. Вдобавок он ограничивает коммуникации внутреннего DNS-cepвepa заданным внешним источником.
Интеграция с другими DNS-серверами может завершить конфигурирование
роли DNS. Один DNS-cepвep может получать запросы и затем отправлять их дру
гим DNS-cepвepaм. После того, как DNS-cepвep получит ответ, он может кеширо
вать информацию в течение определенного периода времени, который в Windows
Server 2012 R2 по умолчанию установлен равным одному часу. Такая конфигурация
называется сервером только для кеширования. Если сервер предназначен д.11я управления пространством имен, вы должны добавить зоны.

Реализация зон для управления пространствами имен

Зона — это база данных д.11я пространства имен. В И нтернете имеется DNS
cepвep, который управляет пространством имен Sybex . сот. Если вам необходим
1 Р-адрес для www . s уЬех . сот, то д.11я нахождения ответа этот DNS-cepвep будет
просматривать свою зону (базу данных). Таким образом, д.11 я управления пространс
твами имен на серверах DNS можно создать зоны.
На серверах Wiпdows DNS существуют зоны четырех типов:
• стандартная основная зона;
• стандартная дополнительная зона;
• зона, интегрированная с Active Directory;
• зона-заглушка.

Зона-заглушка не управляет пространством имен и
больше похожа на сервер условной пересылки. Все типы
зон обсуждаются в последующих разделах.
стандартная основная зона
Серверы имен были спроектированы для централиза
ции преобразования имен в сети. Первоначально DNS
cepвep отвечал на запросы, основываясь на своем текс
товом файле ноsтs. По существу это то, что в Microsoft
называют стандартной основной зоной. Стандартная ос
новная зона представляет собой текстовый файл, в ко
тором сервер поддерживает записи для заданного про
странства имен. Это то, что характеризует реализацию
Windows DNS как стандартную. Характеристика основная
относится к репликации.
Во времена Windows NT существовал один ведущий
контроллер домена, называемый главным контроллером
домена (primary domain controller — РОС), который уп
равлял всеми операциями записи в свою базу данных. Остальные операции управ
лялись резервными контроллерами домена (backup domain controller — BDC), которые представляли собой копии только для чтения. В терминах DNS основные зоны означают, что имеется только один хозяин, и им является данный сервер. Другие
DNS-cepвepы могут содержать лишь копии этой зоны, предназначенные только для
чтения; они являются дополнительными зонами.
Рис. б.12.
Создание НОВОЙ ЗОНЫ
Зона создается с помощью мастера новой зоны (New Zone Wizard), который
можно запустить, щелкнув правой кнопкой мыши на папке Forward Lookup Zones
(Зоны прямого просмотра) в диспетчере DNS и выбрав в контекстном меню пункт
New Zone (Новая зона), как показано на рис. 6.12.
Мастер новой зоны запросит перечисленную ниже информацию.
• Пространство имен или имя домена, такое как Primaryzone . local.
• Имя текстового файла, который по умолчанию имеет расширение . dns.
• Возможность динамического обновления DNS. Мы обсудим это в разделе
«Динамическое обновление DNS» далее в главе.
После создания зоны можно просмотреть содержимое текстового файла, кото
рый хранится в папке c : windowssystem32dns (рис. 6.13). Созданные для при
меров дополнительные записи CNAME и А находятся в конце файла.
Стандартная дополнительная зона
Стандартная дополнительная зона — это копия только для чтения стандартной
основной зоны или зоны, интегрированной с Active Directory. Репликация выполня
ется посредством процесса переноса зоны, который конфигурируется через свойс
тва зоны. На серверах Windows DNS стандартная настройка предусматривает раз
решение переносов зоны только на зарегистрированные серверы имен этой зоны,
что можно видеть на вкладке Zone Transfers (Переносы зоны), представленной на
рис. 6.14.
Чтобы разрешить репликацию на сервер имен ECl . Ecoast . Bigfirm . com, его
необходимо добавить в список Name servers (Серверы имен) на вкладке Name Servers
(Серверы имен), как показано на рис. 6.15.
Теперь можно запустить мастер New Zone Wizard для создания стандартной до
полнительной зоны на сервере ECl. Это потребует указания IР-адреса сервера-хозяина, у которого может запрашиваться перенос зоны. Он не обязательно должен
быть DNS-cepвepoм со стандартной основной зоной. Результатом будет успеш ный
перенос зоны на ECl (рис. 6.16).
Процесс переноса зоны не отличается особой сложностью. Сервер для основной
зоны отслеживает вносимые им изменения, назначая каждому из них серийный номер. Когда сервер для дополнительной зоны контактирует с сервером для основной
зоны, он проверяет этот серийный номер в записи Start of Authority (Начало зоны).
Если серийный номер на сервере для дополнительной зоны не совпадает, значит,
наступил момент для репликации изменений. Это просто текстовый способ заталкивания информации в базу данных. Ранние версии DNS поддерживали репликацию
AXFR (все переносы зоны), которая означала, что на сервер для дополнительной
зоны реплицировалась вся зона целиком. В результате по линии передавался намного больший объем трафика. В Windows DNS поддерживается репликация IXFR (инкрементные переносы зоны), при которой реплицируются только изменения. Кроме
того, в DNS поддерживается уведомление серверов для дополнительных зон, что сокращает время ожидания для запуска репликации.

Зона, интегрированная с Active Directory
Зона, интегрированная с Active Directory, является преобладаюшей реализацией
серверов Windows DNS. Присугствие в ее названии Active Directory говорит о многом.
• Во-первых, записи DNS хранятся в базе данных Active Directory, а не в тексто
вом файле.
• Во-вторых, зоны реплицируются всем другим контроллерам домена Active
Directory в домене, а не посредством процесса переноса зоны.
Поскольку в базе данных Active Directory применяется репликация с нескольки
ми хозяевами, изменения могуг вноситься в зону DNS на любом контроллере домена, и они будуг реплицироваться на другие контроллеры домена. Благодаря интеграции DNS с Active Directory, связка ролей DNS и контроллера домена становится
нормой. За дополнительными сведениями о процессе репликации обращайтесь в
главу 22.
Подобно стандартным зонам, зона, интегрированная с Active Directory, может
быть создана с помощью мастера New Zопе Wtzard. На экране Zone Туре (Тип зоны)мастера
На экране Active Directory Zone Replication Scope (Область действия репликации зоны Active Directory) мастера (рис. 6.1 на выбор предусмотрены четыре опции: науровне леса, на уровне домена, на уровне домена (совместимого с Windows 2000) и
хранение базы данных зоны в указанном специальном разделе каталога приложений
(последняя опция по умолчанию обычно недоступна, но в следующем абзаце мы
объясним, как сделать ее доступной). Первые две опции приводят к размешению
базы данных в автоматически созданном стандартном разделе каталога приложе
ний: один для леса и один для домена, членом которого является контроллер домена. Местоположением, совместимым с Windows 2000, является раздел домена базыданных Active Directory, поэтому база данных зоны будет реплицироваться только контроллерам этого домена.
Если вы хотите создать специальные разделы каталога приложений, такие как
отображаемый в последней опции на рис. 6. 18, то вам придется воспользоваться
либо утилитой DNSCmd, либо командлетом Add-DNSServerDirectoryParti tion
в PowerShell. Оба средства встроены в Windows Server 201 2 R2 и предоставляют
возможность управления указанными типами специальных разделов. В сеансе
PowerShell с разрешениями администратора введите показанную ниже команду, чтобы создать новый раздел каталога приложений для упомянутой ранее зоны, интегрированной с Active Directory. Имя раздела не обязательно должно совпадать с именем зоны; тем не менее, применение того же самого имени способствует лучшему пониманию конфигурации:
C : Usersadministrator . BIGFIRM>Add-DNSServerDirectoryPartition
-Name «adintegratedzone . local»
После того, как новый раздел создан, ему можно назначить зону, интегрирован
ную с Active Directory (см. рис. 6.18).
Затем также с помощью PowerShell можно сконфигурировать другие контролле
ры домена для поддержки зоны. Давайте предположим, что на сервере ECl, который является контроллером домена Ecoast . Bigfirm . com, необходимо добавить следующие две зоны Active Directory:
+ зону adintegratedzone . local, которая помещена в собственный раздел ка
талога приложений;
• зону обратного просмотра для подсети 192.168.0.0, которая помещена в общий
раздел леса.
Для начала добавьте сервер в список на вкладке Name Servers окна свойств жела
емых зон подобно тому, как было показано на рис. 6.15 ранее в главе.
Затем запустите следующий командлет для вывода доступных разделов на серве
ре ECl:
C : Usersadministrator . BIGFIRM>Get-DNSServerDirectoryPartition
В выводе можно заметить наличие четырех разделов каталога приложений.
Первый из них — это специальный раздел, созданный недавно, который сервер вовлек в совместное использование. Второй является разделом каталога приложенийдомена, который совместно используется всеми контроллерами домена, отличными от Windows 2000, внутри домена Bigfirm. com. Третий раздел предназначен для домена Ecoast . Bigfirm. сот. Четвертый раздел ориентирован на все контроллеры доменов в рамках леса доменов. Сервер ECl уже вовлечен в совместное использование этих двух разделов.
Использование зон-заглушек для интеграции с другими DNS-серверами
Зона-заглушка — это еще одно усовершенствование, впервые появившееся в
Windows Seiver 2003. В версии Windows Seiver 2012 R2 концепции и функциональность зоны-заглушки не изменились, и по суmеству она представляет собой дополнительный метод для интеграции с другими DNS-серверами. В зоне-заглушке перечислены только серверы имен для заданного пространства имен. Она не имеет никакого контроля над зоной, так что она указывает только на то, какой сервер мог бы поддерживать преобразование имен для пространства имен. Подобно серверам условной пересылки, зона-заглушка предоставляет ответвленное взаимодействие с авторитетным DNS-cepвepoм. Эти зоны также могут реплицироваться между конт
роллерами домена.
Мастер New Zone Wiz.ard настраивает зону-заглушку со следующими параметрами:
• тип зоны Stub (Зона-заглушка);
• необязательное хранение в Active Directory с заданным разделом каталога приложений;
• пространство имен зоны, такое как Арех. сот;
• DNS-cepвep, который поддерживает это пространство имен.
После создания зоны-заглушки можно просмотреть ее содержимое (рис. 6. 19).
В нем присутствует запись Start of Authority для пространства имен, запись Nam
Seiver (Сервер имен) для пространства имен и запись Host (Хост) для сервера имен.
Использование зон обратного просмотра для увеличения безопасности
Вы можете заметить, что созданные зоны находятся в папке Forward Lookup Zones
(Зоны прямого просмотра) внутри консоли управления DNS. При прямом просмот
ре клиент предоставляет полное имя домена (FQDN), а DNS-cepвep возвращает IР
адрес. При обратном просмотре делается противоположное: клиент предоставляет
IР-адрес, а DNS-cepвep возвращает имя FQDN.

Вас может интересовать, мя чего это может потребоваться? Основные причины
связаны с безопасностью. Представьте себе взломшика, который настроил вредонос
ную службу мя прослушивания DNS-запросов к именам FQDN, начинаюшимся с
www . , внутри сети. Когда эта служба получает запрос, она автоматически отправляет
клиенту поддельный ответ с 1 Р-адресом веб-сервера взлом шика, который загрузит
черви, вирусы, «троянские кони» еще до того, как пользователь узнает, что про
изошло. Если веб-браузер можно было бы сконфигурировать на выполнение обратного просмотра для предоставленного IР-адреса, то он мог бы сравнивать результат
с запрошенным именем и в случае несовпадения не подключаться к веб-серверу.
В качестве реального примера работы такого обратного просмотра при преобра
зовании имен можно привести службу SMTP в Windows. Эта служба позволяет вы
полнять обратный просмотр для подключений к серверу. Серверы SMTP предостав
ляют при взаимодействии свои доменные имена, а при подключении указывается адрес TCP/IP. Затем может быть выполнен обратный просмотр для проверки, соответствуют ли имена адресам, как должно быть.
Команда NsLookup иллюстрирует использование обратного просмотра. Как по
казано ниже, эта команда запушена в интерактивном режиме для сервера, который
не имеет записи указателя (PTR) в зоне обратного просмотра. Обратите внимание,
что стандартный сервер обозначен как UnKnown. В этом случае запросы DNS могут быть ненадежными.
C : UsersAdministrator . BFl>Nslookup
De fault Server : UnKnown
Address : 1 92 . 1 6 8 . 0 . 1 0
Если в зоне обратного просмотра создана запись PTR, то вывод команды
NsLookup выглядит гораздо лучше. Легко заметить, что в выводе присутствует имя
сервера:
C : UsersAdministrator . BFl>Nslookup
Default Server: BFl . bigfi rm . com
Address : 1 92 . 1 6 8 . 0 . 1 0
Для корректного конфигурирования зон обратного просмотра внутри сети не
обходимо понимать, как работает обратное преобразование. Адрес 1Pv4 представля
ется в десятичной точечной нотаuии с помощью четырех октетов — x.y.w.z. Адрес
1 Pv6 похож, но в нем применяются шестнадuатеричные числа, и их намного больше. В обоих случаях проuесс обратного преобразования один и тот же. DNS-cepвep,получающий запрос, изменяет порядок следования числе в IР-адресе. Таким образом, запрос имени FQDN мя IР-адреса x.y.w.z становится z.w.y.x, а в конuе добавляется . in-addr . arpa. Затем DNS-cepвep пытается преобразовать FQDN-имя z . w. у . х. in-addr . arpa подобно обычному имени FQDN. Преобразование начинается с домена верхнего уровня . arpa и проходит вниз к серверам имен in-addr . ,
при этом каждое десятичное значение становится поддоменом пространства имен справа от него. В небольших средах, которые включают только одну подсеть, эта подсеть может быть представлена единственной зоной. В рассматриваемом примере подсеть 192. 1 68.0.0 является одной зоной (рис. 6.20). При создании зоны обратного просмотра мастер New Zone Wuard запрашивает имя подсети.
В более крупных средах, имеющих несколько подсетей, потребуется создать зону
для октета с наибольшим приоритетом, а октеты с меньшими приоритетами должны быть представлены как поддомены или делегированные поддомены. Например,
если крупная организация использует схему частной I Р-адресации 10.0.0.0, то в ней можно создать зону обратного просмотра для доменного имени 1 О . in-addr . arpa.
Когда происходят динамические обновления, поддомены будут автоматичес
ки создаваться для следующего октета от l до 254, а записи PTR будут заполняться
подпапками структуры. В определенный момент поддомены можно делегировать
другому множеству DNS-cepвepoв, вроде контроJUiеров домена, находящихся внутри сайта, который содержит эти подсети. Затем записи PTR можно зарегистрировать в
соответствующей зоне, представляющей подсеть.
На рис. 6.21 видно, что на сервере BFl была создана зона 10 . in-addr . arpa.
Если нужно, чтобы подсети 10. 1 1.0.0 управлялись другим сервером, понадобится делегировать 1 1 поддоменов. Это было делегировано серверу ECl. Внутри него действительная подсеть 10. 1 1 .12.0 также представлена как делегированный поддомен.

На вкладJСе Advanced (Дополнительно) окна свойств DNS-cepвepa имеется несколь
ко отмеченных флажком, два из которых приведены ниже:
• ЕnаЫе round roЬin (Включить циклический перебор)
• ЕnаЫе netmask ordering ( Включить упорядочение сетевых масок)
Циклический перебор (round rоЬiп). Это прием балансировки сетевой нагрузки (network
load balancing — N LB) «для бедняков». Если вы зарегистрировали несколько записей
хостов с одним и тем же именем, но разными I Р-адресами, то DNS-cepвep будет от
вечать последовательно с отличающимся I Р-адресом для каждого запроса, начиная с самого меньшего IР-адреса. Хотя такой прием не распределяет клиентскую нагрузку равномерно или интеллектуально по доступным хостам, он все же предоставляет возможность некоторой балансировки между серверами.
Упорядочение сеrевых масок (пetmask ordering). Подобно циклическому перебору, при упорядочении сетевых масок используется множество записей хостов с одинаковым именем, но разными IР-адресами. Вместо выбора случайным образом выбирается запись, которая определена математически как более близкая. Это делается путем сравнения подсетей. Такой прием хорош при наличии географически разделенных хостов и клиенту необходимо взаимодействовать с хостом, находящимся в его сети. Таким
образом, когда примен яютс я географически разнесенные серверы, вы должны решить, какой метод лучше избрать. Упорядочение сетевых масок сохранит время отклика на минимальном уровне из-за более короткого маршрута. Циклический перебор более равномерно распределит нагрузку, если клиенты сконцентрированы в одном месте.
Однако эти процессы доступны в случае применения Wmdows Server 20 l 2 R2 с
Windows 7 или Windows 8. Стек TCP/IP для I Pv6 и I Pv4, «когда возможно», будет
выполнять процесс похожий на упорядочение сетевых масок, который называется стандартным выбором адресов. Это значит, что он получает I Р-адреса от DNS-cepвepa и самостоятельно решает, какой из них лучше использовать.
Подобно большинству конфигураций, это можно переопределить с помощью объекта групповой политики, указанного в следующем параметре реестра:
Hkey_Local_MachineSystemCurrentControlSet
ServicesTcpip ParametersOverrideDefaultAddressSelection
Значение 1 отключает стандартный выбор и разрешает произвольный выбор циклических серверов NLB.
Увидеть эффект от всего этого можно при использовании циклического перебора
географически ра:щеленных серверов. Например, среда с сайтом для восстановления после аварий может предлагать два сервера, которые выполняют одну и ту же службу,но расположены на разных сайтах. В таком случае для загрузки данных доступны два сервера FГР. DNS-cepвep сконфигурирован на предоставление двух I Р-адресов для одного имени ftp . Bigfirm. сот. Циклический перебор обеспечит последовательную обработку записей. Даже когда один из серверов FГР прекращает функционирование из-за аварийной ситуации, у клиентов по-прежнему сохранится подключаемость к ftp. Bigf irm. сот. (Время от времени будет выбираться IР-адрес нерабочегосервера, но после повторного подключения поток данных возобновится.)Тем не менее, если включено упорядочение сетевых масок или стандартный выбор адресов, то клиенты могут никогда не получить IР-адрес функционирующего сервера FГР. Выбор будет делать либо DNS-cepвep, либо клиент. Таким образом, этот сценарий наталкивает на применение проверенного временем правила: «тестировать,тестировать, тестировать». Проверяйте, какие серверы используются в нормальном сценарии, и что происходит в аварийной ситуации.

Типы записей

Теперь, когда базы данных настроены для извлечения информаuии клиента
ми, необходимо добавить в них записи. Как упоминалось ранее, Dynamic DNS
(DDNS) — это проuесс, который позволяет DNS-клиентам регистрировать свои
имена хостов в назначенном пространстве имен, таком как DHCP, и это приводит
к добавлению записей для компьютеров Windows внутри среды. Тем не менее, не
которые записи по-прежнему придется добавлять вручную, равно как и проверять
корректность записей, созданных динамически. Для зоны DNS доступно свыше
25 типов записей. В этом разделе мы рассмотрим наиболее распространенные типы записей в рамках реализации Windows DNS.
Записи хостов и указателей
Записи хостов (А) и указателей (PTR) наиболее распространены в зонах прямого
просмотра и зонах обратного просмотра, соответственно. В записи А указывается
имя хоста компьютера и возвращается !Р-адрес. В записи PTR указывается !Р-адрес
и возвращается имя FQDN. Эти записи может потребоваться создать дnя компьютеров, не имеющих доступного протокола обномения DDNS.
записи псевдонимов
Записи псевдонимов (CNAME) создаются для определения второго имени ком
пьютера. В записи CNAME указывается имя и возвращается имя FQDN, назначен
ное компьютеру. Эти записи полезны в случае замены сервера с опубликованным
именем, которое клиенты применяют для доступа к приложениям или службам. Безнеобходимости в переконфигурировании после замены клиенты по-прежнему будут иметь доступ через псевдоним.
записи обмена почтой
Записи обмена почтой (mail exchanger — МХ) предназначены для коммуникаций
по протоколу SMTP. Почтовые серверы запрашивают записи МХ пля взаимодейс
твия с получающим сервером SMTP в данном пространстве имен. Обычно записи
МХ настраиваются во внешней зоне DNS. Тем не менее, для специализированных
приложений они могут потребоваться и внутренне. Записи МХ нужно имя FQDN
сервера SMTP и значение приоритета.
Приоритет помогает определить, с какой записью МХ контактировать сначала,
а с какой впоследствии, если записей несколько. Чем меньше значение, тем выше
приоритет. Запомните это как «приоритет номер один».
Предположим, что у вас есть основной SМТР-сервер и SМТР-сервер типа смарт
хост (smart host), предназначенный для поддержки получения электронной почты, когда основной сервер недоступен. Вам необходимо создать записи МХ для обоих серверов. Основной SМТР-сервер должен иметь меньшее значение приоритета, чем смарт-хост, например 10 и 20, соответственно. Когда основной SМТР-сервер недоступен, взаимодействие производится со смарт-хостом.
Записи служб
Записи служб (SRV) являются «знатным шаманом» для реализаuий Windows
DNS. Без записей SRV рабочие станции и серверы не смогли бы находить контрол
леры доменов.

Сами по себе записи SRV имеют дело только с пятью значениями.
• Имя службы. Стандартное значение, обычно предваренное символом подчер
кивания, такое как _gc или _ ladp. Оно является эквивалентом имени хоста и
будет присоединено к имени FQDN службы.
• Имя FQDN сервера. Сервер, который предоставляет службу.
• Порт. Порт ТСР или UDP, на котором доступна служба. Протокол обозначает
ся своим зарегистрированным именем, например, _ ТСР.
• Приоритет. Работает точно так же, как в записях МХ — имеет «приоритет но
мер один».
• Вес. Используется для разрешения конфликтов с приоритетами. Оставьте его
равным О, если вас это не заботит.
Вы обнаружите изобилие записей SRV в зоне Windows DNS, которая поддерживает
Active Directory. Они находятся в папках поддоменов, поскольку именам служб назначаются разные имена FQDN. Запрашиваемая служба описывается с помощью имени
FQDN наподобие _gс . tcp .Ьigfirrn. corn. Записи SRУ можно видеть на рис.
Записи начала зон
Запись начала зоны (Start of Authority — SOA) в единственном экземпляре при
сутствует в каждой зоне. Она определяет информацию о том, какой DNS-cepвep уп
равляет этой зоной, а также параметры, касающиеся того, каким образом трактовать
распознанные записи. Запись SOA содержит несколько значений, которые не должны изменяться при редактировании записи. Редактирование производится на вкладке Start of Authority (SOA) (Запись начала зоны (SOA)) в окне свойств зоны (рис. 6.23).
Ниже описаны поля, находящиеся на вкладке Start of Authority (SOA).
• Serial Number (Серийный номер). Номер ревизии файла зоны. На самом деле
он имеет значение для стандартных основных зон, т.к. репликация Active
Directory поддерживает собственный серийный номер. Дополнительные зоны
могут сравнивать с ним свои номера, чтобы выяснять, актуальна ли информа
ция в них. Если информация не актуальна, необходим перенос зоны.

• Primary Server (Основной сервер). Сервер, на котором зона была изначально
настроена. Если вы хотите изменить способ обновления зон в среде посредс
твом репликации, можете переключать основной сервер на дополнительный
сервер и наоборот.
• ResponsiЫe Person (Ответственное лицо). Предположительно это должен быть
адрес электронной почты лица, администрирующего зону. Обратите внимание,
что символ @ заменяется точкой ( . ). Если хотите кого-то по-настоящему свес
ти с ума, можете указать здесь его электронный адрес.
• Refresh lnterval (Интервал обновления). Период времени, в течение которого
дополнительный сервер может ожидать до того, как начнет попытки прове
рить наличие изменений на основном сервере. В этот момент он сравнивает
серийный номер из записи SOA со своим номером. По умолчанию интервал
обновления составляет 1 5 минут. Внутри самой записи это значение указыва
ется в секундах.
• Retry lnterval (Интервал повтора). Период времени, в течение которого допол
нительный сервер ожидает до того, как повторить попытку после отказавшего
переноса зоны. По умолчанию интервал повтора составляет 10 минут и также
внутри самой записи указывается в секундах.
• Expires After (Истекает после). Период времени, в течение которого дополни
тельный сервер может продолжать отвечать на запросы в этой зоне после того,
как перенос зоны был выполнен. По умолчанию составляет один день. Внутри
самой записи это значение также указывается в секундах и равно 86 400.
• Minimum (Detault) TTL (Минимальное (стандартное) время ТТL). Период време
ни, в течение которого запись должна находиться в кеше или, другими слова
ми, значение времени существования (Time То Live — ТТL). По умолчанию
составляет один час, или 3 600 секунд.

записи серверов имен
Записи серверов имен (NS) перечисляют серверы, которые могут отвечать на за
просы для этой зоны. В зоне должна присутствовать, по меньшей мере, одна такаязапись. Подобно записи SOA, запись NS модифицируется на вкладке Name Servers(Серверы имен) окна свойств зоны, которая была показана ранее на рис. 6.15.Единственным обязательным значением в записи NS является имя FQDN сервера.В нижней части вкладке Name Servers вы заметите короткое примечание, указывающее на то, что 1 Р-адрес представляет собой извлеченное значение.

Управление клиентами DNS и преобразованием имен

Вы можете прийти к выводу, что каждый компьютер является клиентом DNS.
Служба DNS — это жизненно важный компонент сети, даже если Active Directory не входит в ее состав. Вдобавок он представляет собой единственный метод для перехода на ваши избранные веб-сайты в И нтернете, такие как www . Sybex . сот.
В операционных системах Windows есть две области, касающиеся клиентов DNS:
преобразование имен хостов и регистрация имен хостов и I Р-адресов через динами
ческие обновления DNS.
Преобразование имен хостов
Процесс преобразования имен на компьютере Windows делится на две части.
Данный процесс настолько важен, что мы будет называть его «жизненным циклом».
Одной частью, которая близка к исчезновению, является NetBIOS, в друтой — DNS.
(Вы могли бы назвать ее процессом имени хоста, но большинство администраторов
называют его DNS.) Этот цикл состоит из набора шагов, которые компьютер дол
жен предпринять для преобразования заданного имени (рис. 6.24).
Преобразование имен NetBios,__-+- —
Ретрансляция
Поиск в DNS
Поиск вWINS
Файл HOSTS
Файл LMHOSТS
Преобразование (имен хостов) DNS

Процесс NetBIOS предусматривает выполнение следующих шагов.
1 . Ретрансляция имени в сети и ожидание, ответит ли кто.
2. Поиск имени в WNS.
3. Поиск имени в файле LMHOSTS. Это еще один текстовый файл, аналогич
ный файлу ноsтs, который находится в том же самом месте: с : windows
system32 drivers etc. Вместо имен хостов в нем перечислены имена
NetBIOS.
Порядок следования первых двух шагов можно изменять, особенно через сервер
DHCP. Шаг с ретрансляuией или шаг с поиском в WINS может быть опущен. По
умолчанию в Windows Server 2012 R2 сначала производится поиск имени посред
ством WINS, а затем с помощью ретрансляции. Однако поиск в файле LMHOSTS
всегда выполняется последним.
Список шагов для процесса DNS короче.
1. Поиск имени в файле HOSTS.
2. Поиск имени в DNS.
Порядок следования шагов в процессе DNS настройке не поддается, но можно
изменить поведение просмотра DNS. С тем, что поиск имени сначала производится
в файле ноsтs, связаны как положительные, так и отрицательные моменты. Если
получить доступ к DNS-cepвepy невозможно или требуется переадресовать преобра
зование имени в другое место, то редактирование файла ноsтs дает замечательные
результаты. Если же файл ноsтs содержит устаревшие или вредоносные записи, то
устранение неполадок DNS может оказаться затруднительным.
Процесс преобразования имен циркулирует по обеим частям до тех пор, пока не
будет получен IР-адрес. Кроме того, имеется выбор с чего начинать — NetBIOS или
DNS. В основном это зависит от приложения. Старые унаследованные приложения
Windows рассматривают имя как относящееся к NetBIOS. Приложения, основанные
на TCP/IP, считают его именем хоста. Это влияет на способ преобразования имен и является частью операционных систем Windows.
Примерами могут служить команды net view и ping.
Комама net view существует со времен LAN Manager, когда все полагалось uе
ликом на NetBIOS. Если вы попытаетесь подключиться к серверу с применением
указанной команды, то увидите, что имя сервера заносится в кеш имен NetBIOS.
Содержимое этого кеша можно отобразить с помощью команды nЬtstat — с . Для
очистки кеша предназначена команда nbtstat -R.
rem Просмотр кеша имен NetBios
С: Users Adrnini strator . BFl >nhtstat -с
Local Area Connection :
Node IpAddress : [ 1 92 . 1 68 . 0 . 1 0 ] Scope Id: [ ]
No names in cache
rem Доступ к общим ресурсам на сервере Ьfscl
С: UsersAdrninistra�or . BFl>net view Ьfscl
Shared resources at \bfscl
Share name Туре Used as Comment
NETLOGON Disk Logon server share
SALES Disk
SYSVOL Disk Logon server share
Users Disk
The command completed success fully .
rem Повторный просмос>р кеша имен NetBios
С : UsersAdminis trator. BFl>nЬtstat -с
Local Area Connection :
Node IpAddress : ( 1 92 . 1 68 . 0 . 10 ] Scope I d : [ ]
NetBIOS Remote Cache Name ТаЫе
Name Туре
Host Address
BFSCl UNIQUE 1 92 . 1 68 . 0 . 1 1
ГЛАВА 6
Life [ sec]
6 0 0
При пинговании сервера используется проuесс DNS, т.к. команда ping являет
ся утилитой ТСР /1 Р. Вы можете убедиться, что эта утилита распознает сервер че
рез DNS, отобразив содержимое кеша DNS с применением команды ipconfig
/di splaydns. Кеш DNS очищается с помощью команды ipconfig / flushdns.
rem Очистка кеша DNS
С : Users Administrator . BFl>ipconfiq /flushdns
Windows I P Configuration
Success fully flushed the DNS Resolver Cache .
С : Users Administrator. BFl>pin9 BFSCl
Pinging BFSCl . bigfirm . com [ 1 92 . 1 68 . 0 . 1 1 ] with 32 bytes o f data :
Reply from 1 92 . 1 68 . 0 . 1 1 : bytes=32 time Reply from 192 . 1 68 . 0 . 1 1 : bytes=32 time Reply from 1 92 . 1 68 . 0 . 1 1 : bytes=32 time< lms TTL=128
Reply from 1 92 . 1 68 . 0 . 1 1 : bytes=32 timeipconfiq /displaydns
Nindows I P Con figuration
BFSCl
Record Name .
Record Туре .
Time То Live
Data Length .
Section . . .
А ( Host ) Record .
BFSCl . bigfirm . com
1
1 1 8 5
4
Answer
1 92 . 1 68 . 0 . 1 1
Такие сведения помогают решить, каким образом поддерживать проuесс преоб
разования имен DNS для клиентов и устранить либо поддерживать (при необходи
мости) имена NetBIOS. Проuесс NetBJOS потребляет излишние uиклы ЦП. В слу
чае корректной конфигурации сервера и клиентов DNS поддержку преобразования
имен NetBIOS можно отключить или, по крайней мере, свести к минимуму.
Конфигурирование клиентов
Конфигураuии DNS и NetBIOS можно просмотреть в окне свойств протокола IP
для сетевого подключения. Конфигурация NetBIOS находится на вкладке WINS. На
рис. 6.25 показана вкладка WINS со стандартными настройками.

По умолчанию включен поиск в файле LMHOSTS и выбрано использование на
строек NetBTOS из сервера DHCP. По умолчанию файл LMHOSTS пуст. Было бы не
плохо отключить поиск в этом файле, поскольку вредоносное ПО могло в прошлом
занести в него данные.
Настройки NetBIOS получаются от сервера DHCP. Области видимости сервера
DHCP имеют опцию под названием NBT Node Туре (046) (Тип узла NBT (046)). Эта
настройка предписывает первые два шага проuесса NetBIOS в жизненном uикле.
Четыре опuии задаются десятичным значением:
• только ретрансляция: «Ь-узел», 1
• только обращение к WINS: «р-узел», 2
• сначала ретрансляция, а затем обращение к WINS: «m-узел», 4
• обращение к WINS, а затем ретрансляция: «h-узел», 8
Н-узел лучше всего подходит для сети, полагающейся на NetВIOS, т.к. он сокра
щает объем обмена в среде, поддерживающей WINS. При отсутствии доступных сер
веров WINS компьютер может, по крайней мере, получить какой-то ответ в подсети,
например, дома или в рабочей группе. Если сервер DHCP не сконфигурирован с этим значением, применяется стандартная конфигурация, установленная в ОС. В Windows Server 2012 R2 по умолчанию используется h-узел, т.е. rибридный (hybrid) режим.
Дrtя сред Active Directory лучше отключать NetBIOS, поскольку это сокращает объ
ем дополнительного обмена и количество процессов. Кроме тоrо, это помогает снизить
угрозы безопасности со стороны ботов, которые ищут в сетях компьютеры с целью
атаки с применением данной системы имен. Однако прежде чем отключать NetBIOS,
удостоверьтесь в отсутствии слабых мест в системе преобразования имен DNS.
Конфигурация клиента DNS находится на вкладке DNS окна свойств сети, по
казанной на рис. 6.26. Вполне очевидно, что обязательным является IР-адрес DNS cepвepa. Подключение должно осуществляться к ближайшему серверу, как правило,
на контроллере домена внутри локального сайта. Рекомендуется указать также дополнительный DNS-cepвep.
Advanced TCP/IP Settings

Средняя часть вкладки DNS имеет отношение к неполным именам. Это имя хос
та без его «второго имени», суффикса DNS (такого как BFSCl, используемого ра
нее в примере команды ping). DNS-cepвepy необходимо имя FQDN, поэтому пе
ред отправкой запроса клиент DNS добавляет суффиксы DNS, т.е. «второе имя».
Основной суффикс DNS отображается на странице System (Система) панели уп
равления, в области Computer Name (Имя компьютера). Он управляется автомати
чески ОС, когда компьютер присоединяется к домену, поэтому заботиться об этом
суффиксе не придется. Дополнительные суффиксы могут понадобиться в крупных
средах, но для сред с одним доменом стандартных настроек вполне достаточно.
Добавлять суффикс DNS подключения нужно только в редких случаях.
Все это становится спорным в случае регулярного применения имен FQDN.
Используйте имена FQDN серверов при конфигурировании приложений, папок
или переадресации папок, равно как при написании сценариев, которые подклю
чают сетевые диски. Уловили смысл? Вдобавок применение имен FQDN обходит
процесс NetBIOS. Приложения могут определить разницу между именами NetBIOS
и FQDN и прибегнуть к DNS, когда они распознают FQDN.

динамическое обновление DNS
Чтобы сделать процесс преобразования имен DNS надежным, понадобится пе
речислить все компьютеры в зонах DNS. В прошлом система DNS требовала от
системных администраторов работы в полную смену, т.к. нужно было вводить постоянно растущее количество записей для их сети. Для сокращения объема работы системных администраторов в Microsoft при создании ОС Windows NT нашли динамическое решение через WINS и затем перешли на DNS, когда стал доступным протокол обновлений Dynamic DNS (DDNS). Сам процесс довольно прост.
1. Клиент запрашивает запись SOA мя пространства имен с основным суффик
сом DNS. Это сообщит, может ли сервер принимать DDNS. То же самое дела
ется для зоны обратного просмотра, с которой связан 1 Р-адрес сервера.
2. Клиент отправляет запрос DDNS этому серверу.
В записях Start of Authority стандартных зон указан основной сервер. В зонах,
интегрированных с Active Directory, контроллер домена, получающий запрос, моди
фицирует запись SOA с таким именем. Поскольку он может изменять содержимое
базы данных Active Directory, нет нужды выискивать контроллер домена, находя
шийся где-то в другом месте. Если процесс обновления терпит неудачу, производится поиск других серверов имен для выполнения обновлений.
На вкладке DNS с протоколом обновлений DDNS связаны два флажка в самом
низу (см. рис. 6.26). Имеется возможность зарегистрировать имя с основным суффиксом DNS или с суффиксом подключения. Второй флажок по умолчанию не отмечен.
Странно то, что служба клиента DNS не выполняет обновления DDNS. Это де
лает служба клиента DHCP. Это напоминает нам богатый событиями день, когда
один из нас отключил службу клиента DHCP на контроллере домена. Он наивно
полагал, что эта служба не нужна, т.к. имеется статический IР-адрес. Как уже упоминалось, �процесс DDNS используется контроллерами домена с целью предоставления записей SRV для Active Directory. В конечном итоге клиенты не смогли найти контроллер домена, т.к. для него не было никаких записей SRY. К счастью, все это происходило в испытательной среде.
Существуют еше два места, где производится управление процессом DDNS: зона
для пространства имен и сервер DHCP.
Зона DNS может быть включена для обновлений DDNS в мастере New Zone
Wizard или же путем изменения свойств зоны. На рис. 6.27 показаны опции для обновлений DDNS — только безопасные, безопасные и небезопасные, а также пол
ное отключение обновлений. Безопасные динамические обновления означают, что до их выполнения клиент DNS проходит аутентификацию на контроллере домена. Небезопасные динамические обновления означают, что они принимаются без аутентификации. Учитывая название, вы легко можете предположить, что злоумышленники способны воспользоваться этой опцией. В случае отключения никакие обнов
ления DDNS поступать не будут.
Сервер DHCP также может участвовать в процессе DDNS. В самых ранних вер
сиях Windows Server было много клиентов Windows, которые не обладали возмож
ностями DDNS. Для решения этой проблемы сервер DHCP идентифицирует такие
ОС и выполняет мя них обновления. Кроме того, сервер DHCP может выполнять
обновления по запросу. На рис. 6.28 приведена вкладка DNS окна свойств 1 Pv4 для сервера DHCP.
Здесь показаны стандартные настройки, которые редко изменяются. В сущности,
сервер DHCP не выполняет никаких обновлений, поскольку клиенты делают это
самостоятельно. Сервер DHCP производит очистку, когда истекает срок аренды.
Защита имен, включаемая за счет отметки флажка в окне, открывающемся по щелчку на кнопке Configure (Конфигурировать) в области Name Protectioп (Защита имен),предотврашает обновление сервером DHCP существуюшей записи DNS.

Система DNS в Active Directorv

В Microsoft настолько тесно интегрировали DNS и Active Directory, что обсуж
дать их по отдельности довольно трудно. Во время создания среды Active Directory с Windows Server 2012 R2 проuесс установки Active Directory автоматически конфигурирует DNS при добавлении роли. Это освобождает спеuиалистов по 1Т от ручной настройки DNS.
В последующих разделах мы раскроем способ, которым Active Directory конфиrу
рирует систему DNS и применяет ее для поддержки клиентов. За дополнительными
сведениями о терминах и конuепuиях Active Directory обращайтесь в главу 7.

Автоматическое конфигурирование DNS

ОС Windows Server 2012 R2 предлагает два способа установки службы DNS: до
бавление роли DNS самой по себе (как было показано ранее для автономной кон
фигурации, не присоединенной к домену) или добавление роли Active Directory
Domain Services (Службы домена Active Directory). В случае выбора второго спо
соба вы должны запустить мастер установки служб домена Active Directory (Active
Diгectory Domain Services lnstalation Wizard), который проведет ряд настроек для
роли Active Directory Domain Services, включая автоматическое конфигурирование
и интеграцию с ролью DNS. В главе 7 процесс установки Active Directory будет рас
смотрен во всех деталях, а здесь мы лишь посмотрим, что произоЙдет с ролью DNS.
Первым делом вы должны понять предварительные условия, которые должны
быть удовлетворены для проведения установки Active Directory. Будущему конт
роллеру домена необходима возможность подключения к существующей структуре
Active Directory DNS. В противном случае нельзя будет подключиться к контрол
лерам домена и получить нужную информацию. Таким образом, в настройках IР
адресов должен быть указан DNS-cepвep внутри среды Active Directory, желательно
DNS-cepвep корня леса или DNS-cepвep в том же самом домене, к которому пла
нируется присоединение. Единственным исключением является ситуация, когда создается самый первый контроJVIер домена в среде Active Directory. В этот момент нет
никакой структуры Active Directory DNS, на которую можно было бы указывать.
Во время выполнения мастера Active Directory Domain Services конфигурируется
новый контроллер домена. В зависимости от опций, выбранных в мастере, может
быть создан новый контроллер домена. В любом случае служба DNS и соответству
ющие настройки конфигурируются автоматически. В среду вносятся описанные далее изменения.
Создание разделов каталога приложений
Разделы каталога приложений — это граниuы внутри базы дан ных Active
Directory, которые создаются для совместного использования зон DNS разными до
менами при создании нового домена или леса.
Раздел Doma inDNSZones . doma in . name создается для контроллеров домена
внутри домена. Раздел ForestDNSZones . domain . name создается для совместного
использования контроллерами домена в рамках леса Active Directory.
Если вы снова взглянете на рис. 6.9, то заметите, что поддомен msdcs .
Ьigfirm . com делегирован подобно Ecoast. Он делегирован на тот же самый конт
роллер домена, в рассматриваемом случае это DCOl . Bigfirm. com.
Зона _msdcs . Bigfirm . com создается в разделе ForestDNSZone . Bigfirm . com
каталога приложений. Это позволяет данной порции пространства имен реплицироваться на все домены внутри леса.
После создания дополнительных контроллеров доменов они автоматически по
являются в этих разделах каталога приложений.
Добавление сервера пересылки
Сервер пересылки можно добавить, просмотреть и сконфигурировать на вкладке
Forwarders (Серверы пересылки) окна свойств DNS-cepвepa. Обычно это будет IР
адрес исходного DNS-cepвepa, которым пользовался данный сервер.
Изменение /Р -адреса
Новый контроллер домена, созданный мастером Active Directory Domain Services
Wizard, также является новым DNS-cepвepoм. Адрес основного DNS-cepвepa кон
фигурируется на I Р-адреса обратной связи ::1 (для 1Pv6) и 127.0.0. 1 (для 1Pv4).
делегирование поддомена
Дочерний домен имеет имя, являющееся поддоменом внутри существующе
го пространства имен домена. Например, Ecoast . Bigfirrn . corn — это поддомен
в пространстве имен Bigfirrn . corn. В результате работы мастера Active Directory
Domain Services Wizard пространство имен нового домена будет поддерживаться в
новом контроллере домена в виде делегированного поддомена.
В родительском домене поддомен вроде Ecoast . Bigfirrn. corn делегируется но
вому контроллеру домена. Делегирование свяжет родительский и дочерний домены дпя преобразования имен. Это иллюстрировалось ранее на рис. 6.9.
дополнительные рекомендации по конфигурированию
После создания контроллера домена мы рекомендуем внести в настройки DNS
перечисленные ниже изменения.
1 . В свойствах ТСР /1 Pv4 сетевого адаптера измените основной DNS-cepвep на 1 Р
адрес основного сетевого подключения. Например, если IР-адресом сервера яв
ляется 192.168.0. l, его понадобится указать в качестве основного DNS-cepвepa.
При поиске и устранении неполадок в DNS с помощью утилиты NsLookup ад
рес обратной связи ( 1 27.0.0. 1) указывается как «неавторитетный». Мы нахо
дим результаты применения адреса обратной связи несколько ненадежными,
поэтому лучше придерживаться основного I Р-адреса.
2. Создайте зоны обратного просмотра в разделе ForestDNSZones . dornain . name каталога приложений.Зону обратного просмотра для подсетей может потребоваться совместно использовать в контроллерах различных доменов.
3. Создайте зону-заглушку для новых деревьев доменов на корневом DNS
cepвepe.
Дерево домена имеет имя, отличающееся от имени корневого DNS-cepвepa.
Поскольку запись об исходном DNS-cepвepe указана как сервер пересылки,
подобно поднятиям других контроллеров домена, этот DNS-cepвep может
взаимодействовать с остальной структурой Active Directory DNS. Тем не ме
нее, для остальной структуры Active Directory DNS никакого автоматического
конфигурирования для преобразования имен в новом пространстве имен не
предусмотрено. Например, нам придется настроить сервер условной пересыл
ки или зону-заглушку, чтобы нацелить DNS-cepвepы на новый контроллер до
мена для Арех. сот. На рис. 6. 19 демонстрируется применение зоны-заглушки
для содействия преобразования имен FQDN домена Арех . com.

Записи SRV и клиенты

Глядя на зону DNS нового домена, вы заметите наличие в ней множества новых папок или поддоменов. Открывая эти папки, вы найдете множество записей расположения служб, как было показано ранее на рис. 6.22. Как уже упоминалось, записи SRV и динамические обновления DNS необходимы для обеспечения работы Active Directory.
Они представляют собой результат совместного функuионирования двух технологий.
Служба netlogon выполняет запросы DDNS для создания записей SRV внутри
пространства имен Active Directory DNS. Единственная причина заключается в гарантировании того, что компьютеры смогут найти контроллеры домена.
Внутри проuессов ОС Windows определенные службы находятся с исполhЗовани
ем DNS. На рис. 6.22 присутствовало несколько служб:
• _gc (global catalog — глобальный каталог) — служба LDAP для поиска данных
в глобальном каталоге;
• kerberos — проuесс аутентификаuии;
• kpassword — еще одна часть процесса аутентификации;
• ldap — служба LDAP для поиска данных в домене.
Каждая из перечисленных служб выполняется контроллерами домена внут
ри домена или леса. На рис. 6.22 было видно, что все эти роли выполнялись на
DCOl . Bigfirm. сот и прослушивался порт ТСР.
Таким образом, когда компьютеру Windows требуется какая-то служба контроллера домена, например, LDAP, он запросит запись SRV для ldap . tcp . Bigf i rrn . сот.
После этого он получит все, что необходимо мя взаимодействия с IР-адресом и
портом.
Если компьютеру Windows нужно найти контроллер домена внутри собственного
сайта, он может искать его в поддомене sites . Bigfirm . com. В этом поддомене будут отображаться все созданные сайты в консоли Active Diгectory Sites and Services(Сайты и службы Active Directory).
Вероятность того, что администраторы могли бы поддерживать все это множес
тво записей DNS вручную, довольно низка. Для одного контроллера домена можно
ожидать регистрации, по меньшей мере, 16-20 разных записей SRV. Изучение их
всех — задача, безусловно, не из простых. Именно здесь в игру вступают инструменты, подобные DcDiag. Инструкции по работе с этими утилитами приведены в разделе «Использование NsLookup и DcDiag» далее в главе.

Дополнительные компоненты Windows Server 2012 R2

К этому моменту мы обсудили существенные компоненты и способы обраще
ния с ними, что уже позволяет вам достаточно квалифицированно управлять средой Windows Server 2012 R2 DNS. В настоящем разделе будут рассматриваться дополнительные компоненты DNS в Windows Server 2012 R2, которые развертываются не так
часто, как основные компоненты, но о которых, тем не менее, полезно знать.
rлобальный список блокировки запросов
Существует несколько распространенных записей хостов, которые могут быть за
регистрированы в DNS другими службами. Одной из таких служб является протокол
автоматического обнаружения веб-прокси (\еЬ Proxy Automatic Discovery Protocol —
WPAD). Он помогает веб-браузерам автоматически загружать конфигураuии прок
си из сервера. Так как эта запись не относится к конкретному компьютеру, любой
компьютер, включая потенциально скомпрометированный злоумышленниками, может попытаться зарегистрировать свое имя. Другой распространенной записью хоста является протокол автоматической внутрисайтовой адресаuии туннелей (lntra-Site Automatic Tunneliпg Addressing Protocol — ISATAP). Как объяснялось в главе 4, протокол ISATAP предназначен для выполнения маршрутизации из сети 1Pv4 в сеть 1Pv6.
В глобальном списке блокировки запросов (global query Ыосk list) указаны имена, для которых регистраuия DDNS заблокирована. Таким образом, попытки компьютера злоумышленника зарегистрировать имена WPAD или ISATAP отклоняются.
Показанные ниже команды иллюстрируют способы администрирования это
го списка. Для просмотра списка служит командлет Get — DNSSe rverGl oba l
QueryBlocklist. Обратите внимание, что по умолчанию в списке находятся wpad
и isatap.
C : UsersAdministrator . BFl>Get-DNSServerGlobalQueryBlocklist
ЕnаЫе : True
List : { wpad, isatap }
Чтобы добавить в этот список имя вроде www, можно воспользоваться командле
том Set-DNSServerGlobalQueryBlocklist. По умолчанию компонент глобально
го списка блокировки запросов включен. Он отключается и повторно включается с применением опции -ЕnаЫе со значением $True или $False.
Преобразование глобальных имен и одиночных имен
Даже с учетом того, что использование WINS идет на убыль, возникает пот
ребность в поддержке для некоторых приложений процесса преобразования имен
NetBIOS. Компонент GlobalNames (глобальные имена) — это специальная зона, созданная для преобразования имен NetBIOS (15 символов безо всяких точек). Клиент
DNS осуществляет запрос в зону GlobaName, когда поиски с основным и дополни
тельным суффиксом DNS завершились неудачей.
Конфигурирование компонента GlobalNames выполняется несложно.
1. Создайте новую зону по имени GlobalNames.
Рекомендуется выбрать тип зоны, интегрированной с Active Directory, чтобы
обеспечить репликацию в другие контроллеры домена.
2. Включите поддержку зоны Gl oba lNames с помощью командлета Set
DNSServerGlobalNameZone:
C : UsersAdmiпistrator . BFl>Set-DNSServerGlobalNameZoпe -ЕпаЫе $True
3. Проведите репликацию зоны в другие контроллеры домена.
Не забудьте добавить эти контроллеры домена в список серверов имен для зоны.
4. Добавьте в зону записи CNAME для переадресации на определенные хосты.
В данном примере www переадресуется на hostrecord . Pr imaryZone . local
(рис. 6.29).
5. Добавьте запись местоположения службы, если необходимо, чтобы эту зону
запрашивали другие леса Active Directory.
DNS И ПРЕОБРАЗОВАНИЕ ИМЕН В WINDOWS 5ERVER 201 2 R2
DNS Manager
———-�.— — ——
� � С a:ched Lookups
� ..::J Forwгrd loolcup Zont’S
1> ,Vf _msda.Bigfirm.com
1> :Р 1dint�nite:hone.loc1J
1> …; Bigfirm.com
.:,c_Gl_o_balNomt:’:
� Prim1ryZone.lcк.al
1> _. R�erse lookup Zon�
1> _.; Trust:Po1nts
1>
Cond» rtionlll Fo�rders
1> IDJ G l o bal log:.
! Name Туре Dat.• Тimm:.Jmp
{] (same 1Js p1tr.» SЬrt of Authonty(SOA) 111 dc01.bigfirm.com» hostm.itst.» static
� (same IS rur». N t!t m e Smrer (NS) dc01.Ьigfirm.com. stnic
{ijwww AJi1s (СNАМЕ) hostrecord.Prim1ryZone.loc1’i
< f . » Рис. 6.29. Зона GlobalNames 277 Протестировать преобразование глобальных имен можно посредством уrилиты NsLookup: C: UsersAdrninistrator . DCl>Nslookup
Default Server : DCOl .Ыgfirm. com
Address : 1 92 . 1 68 . 0 . 1
> www
Server :
Address :
Name :
Address :
Aliases :
DCOl .Ыgfirm. com
1 92 . 1 68 . 0 . 1
hostrecord.primaryzone . local
1 92 . 1 68 . 0 . 2 1
www . Ьigfirm. com
Как обсуждалось ранее, в большинстве сред, полагающихся на серверы Windows,
потребность в преобразовании одиночных имен (NetBIOS) сведена к минимуму.
Она также была минимизирована за счет подходящего развертывания приложений с
применением имен FQDN и привлечения DNS.
Фоновая загрузка зон
Некоторые старые среды имеют настолько большие зоны DNS, что перезапуск
службы DNS контроллерами доменов занимает более часа. Для решения этой про
блемы предназначено средство фоновой загрузки зон. Чтобы такая проблема воз
никла, зона DNS должна содержать огромное количество записей.
Во время запуска службы DNS она начинает реагировать на запросы к зонам,
которые уже загрузились. Запросы к пока еще не загруженным зонам будуr отсы
латься другим DNS-cepвepaм.
DNSSEC
Подобно НТТР, система DNS является нешифрованной и неауrентифицируе
мой. Как упоминалось при рассмотрении зон обратного просмотра, злоумышленни
ки мoryr подделывать ответы DNS. Чтобы противостоять этому, были разработаны
стандарты DNSSEC (DNS Security Extensions — расширения безопасности DNS),
которые позволяют DNS-cepвepy добавлять цифровую подпись к записям ресурсов.
ОС Windows Server 2012 R2 обеспечивает поддержку дополнительных зон как зон
DNSSEC. Она реагирует только на запросы записей из зоны с цифровой подписью.
ОС также будет предостамять необходимые записи ресурсов для аутентификации
подписи.
Такими записями ямяются КЕУ, SIG и NXT Запись КЕУ — это открытый ключ
подписи DNS-cepвepa. Запись SIG представляет цифровую подпись записи ресурса.
В записи NXT перечислены все допустимые записи в пространстве имен.
В версии Windows Server 2012 R2 стандарты DNSSEC претерпели следующие
улучшения:
• интеграция с Active Directory и поддержка динамических обновлений DNS;
• обновленная поддержка стандартов DNSSEC (NSECЗ и RSA/SHA-2);
• проверка достоверности записей с использованием обноменных стандартов
DNSSEC;
• дополнительная поддержка DNSSEC в PowerShell.
Если вы хотите протестировать DNSSEC в испытательной среде, обратитесь к
пошаговому руководству от Microsoft, доступному по ссылке http : / /tinyurl . сот/
dnsseclab.
якори доверия
Якори доверия (trust anchors) — это открытые сертификаты серверов DNSSEC,
которым DNS-cepoep будет доверять при взаимодействии. Сертификаты якорей до
верия будут применяться для проверки достоверности цифровых подписей ответов.
Они добавляются в снойства DNS-cepвepa в форме открытых ключей.
В якори доверия Windows Server 201 2 R2 внесены следующие усовершенствова-
ния:
• использование Active Directory для распространения якорей доверия;
• поддержка автоматического перебора;
• упрошенное извлечение корневого якоря доверия.
В Windows Server 2012 R2 якори доверия отображаются о консоли DNS Manager,
внутри расположенной в левой части папки Trust Points (Точки доверия).

Поддержка преобразования именDNS на основе Интернета

В рамках организации существует также потребность в управлении пространс
твами имен Интернета. Пользователям локальной сети понадобится доступ к веб
сайтам и другим основанным на Интернете службам. Внешним пользователям будет
нужен доступ к оеб-сайтам организации и, как минимум, постовым серверам. Таким образом, вы не должны упускать из виду и эти требования.
Чтобы разрешить внешним пользователям обращаться к веб-сайтам организа
uии, должен существовать внешний домен DNS. Следовательно, вам придется об
думать вопрос о необходимости развертывания внешнего DNS-cepвepa. Внутренние
компьютеры будут преобразовывать внешние имена с помощью внутренних DNS
cepвepoo. По этой причине требуется интеграuия со структурой DNS из Интернета.

Поддержка внешних доменов DNS

Большинство компаний мя поддержки веб-сайта и электронной почты регист
рируют какое-то пространство имен DNS. Мелкие и некоторые средние компании
поручают управлять пространством имен на внешних DNS-cepвepax поставщикам
Интернет-услуг. Преимущества такого подхода связаны с готовностью серверов
и устранению потребности в обслуживании дополнительных серверов в подсети,
открытой мя Интернета. Эти серверы управляются посредством неб-интерфейса
и позволяют работать только с небольшим набором типов записей, таких как А,
CNAME и МХ.
Допускается применение сервера Windows Server 2012 R2 мя внешних операций
DNS. Роль DNS можно установить на сервере, не являющемся членом домена (как
обсуждалось в разделе «Конфигурирование автономного DNS-cepвepa» ранее в главе), и затем изменить запись сервера имен мя зарегистрированного пространства
имен DNS, указав публичный IР-адрес сервера. Конечно, открыть Интернету ав
тономный DNS-cepnep можно и таким способом, но в реальности существует не
сколько аргументов против такого подхода.
• ОС Windows Server 2012 R2 не является бесплатной, и ее использование в ка
честве внешнего решения DNS нельзя считать экономически оправданным
подходом.
• Сервер Windows Server 2012 R2 нуждается в ограничении функциональных воз
можностей и зашите, когда он открыт внешне.
• Сервер должен обладать высокой доступностью, поэтому вам придется класте
ризировать его или настроить несколько DNS-cepвepoв.
• Если вы еще об этом не позаботились, вам также понадобится высокоскорост
ное подключение к Интернету.
Общая цена, которую придется заплатить, двигаясь в таком направлении, вы
сока, поэтому многие компании предпочитают тратить свои деньги по-другому.
Именно здесь преимущество следует отдать простой реализации DNS на базе Linux.
Тем не менее, мы рекомендуем наиболее распространенный подход — поручить уп
равление внешним пространством имен поставщику Интернет-услуг.
Разделение
Когда дело доходит до DNS, многие компании также внедряют сценарий с раз
делением (spit-brain), хотя и неумышленно. Это означает, что они имеют внутреннее пространство имен, совпадающее с внешним пространством имен. Например,компания регистрирует внешнее пространство имен Eigfirrrc. corn и затем решает строить среду Active Directory с тем же самым именем.
Управление данным сценарием на единственном сервере было бы идеальным.
Реализация разделенной DNS — хорошая идея, предназначенная для решения про
блемы. Можно бьuю бы иметь один DNS-cepвep, поддерживающий внутреннюю и
внешнюю зону того же самого пространства имен. Тогда бы 1 Р-адреса мя внешней
зоны предоставлялись бы внешним запросам, а внутренние 1 Р-адреса — внутрен
ним запросам.
ПРЕДОСТЕРЕЖЕНИЯ ОТНОСИТЕЛЬНО ПРИМЕНЕНИЯ РАЗДЕЛЕННОЙ DNS
Разные специалисты и различные технические документы тто DNS могут утверждать
о том, что использовать одно и то же доменное имя для внугреннего и внешнего
пространства имен DNS компании не рекомендуется. Взамен предлагается выбрать
другое имя, которое не встречается в Интернете, или зарегистрированное имя, которым вы не пользовались.
Когда компании не следуют этой рекомендации, они вскоре обнаруживают кон
фликт при распознавании внешних ресурсов, которыми владеют, таких как www .
Bigfirm . com. Внутренний DNS-cepвep не может найти это имя, и запрос терпит
неудачу. Администраторы пытаются исправить это путем ручного добавления имени с внешним 1Р-адресом, но добавление внешнего IР-адреса вызьшает проблемы с маршрутизацией. Кроме того, разработчики будут жаловаться на невозможность загрузки нового содержимого по внешнему IР-адресу. Им нужен внугренний IР-адрес.
Такие дополнительные трудности администрирования становятся нормой при разделении DNS.
Идея неплоха, но Windows Server 201 2 R2 это не поддерживает. В первую очередь
не поддерживается организация, открывающая контроллер домена, на котором размещено внутреннее пространство имен DNS, даже на границе Интернета. Так сделано не только из соображений безопасности. База данных Active Directory слишком ценна, чтобы помещать ее в демилитаризованную зону (DMZ), где она станет лакомым кусочком для злоумышленников. Поэтому придется прибегнуть к альтернативе.
Цель заключается в том, чтобы обеспечить предоставление внешним запросам
внешних IР-адресов, а внутренним запросам — внутренних IР-адресов. Для подде
ржки такого сценария вы должны будете администрировать (минимум) два DNS
cepвepa с помощью Microsoft DNS. Ниже перечислены базовые шаги.
1. Реализуйте внешний DNS-cepвep для поддержки Bigfirrn. corn. Обычно это
становится готовым после регистрации доменного имени с помощью постав
щика Интернет-услуг.
2. Реализуйте внутреннюю структуру DNS. Это делается с применением мастера
Active Directory Domain Services lnstalation Wizard.
3. Добавьте любые внешние записи во внугреннюю зону для Bigfirrn. corn.
Помните, что DNS-cepвepы внутри сети будут авторитетными для домена
Bigfirm. corn. Если не удается найти сайт www . Bigfirrn. corn, то он не существует. Внешние записи должны быть продублированы во внутренней зоне, чтобы мог возвращаться положительный результат. Вам придется протестировать
маршрутизацию, удостоверившись в доступности указанного IР-адреса. В слу
чае возникновения проблем с маршрутизацией может понадобиться использо
вать внутренний адрес.
4. Сконфигурируйте преобразование внешних пространств имен с применени
ем корневых подсказок или серверов пересылки. Данная тема раскрывается в
следующем разделе.

Преобразование внешних пространств имен

Мы обсуждали, каким образом интегрировать DNS-cepвep с другими. Основными
методами преобразования имен DNS в Интернете являются корневые подсказки
или серверы пересылки. Корневые подсказки содержат список DNS-cepвepoв, на
ходящихся наверху структуры DNS Интернета. DNS-cepвep может взаимодейство
вать с такими серверами дЛЯ выполнения рекурсивных запросов к внешним про
странствам имен. Серверы пересылки производят ответвленные запросы к другому
DNS-cepвepy, чтобы посмотреть, не распознает ли он имя. Ранее мы упоминали,
что в небольших средах предпочитаем использовать серверы пересылки на внешний
DNS-cepвep, поддерживаемый поставщиком Интернет-услуг, но корневые подсказ
ки в данном сценарии также работают.
Важно не смешивать эти два подхода. Не определяйте в корневых подсказках
серверы как серверы пересылки. Запрос к корневой подсказке — это направленный
запрос, который всегда возвращает сервер имен лля домена. Он не отвечает записями хостов и не выполняет рекурсивную операцию, которую будет делать сервер пересылки. Кроме того, серверы пересылки имеют приоритет перед корневыми подсказками. На приведенном ранее рис. 6. 1 О вкладка Forwarders (Серверы пересылки)
содержала флажок Use root hints if по forwarders are availaЫe (Использонать корневые
подсказки, если нет доступных серверов пересылки). Вы можете сделать вывод, что если сервер пересылки указан, но получен отрицательный ответ, запрос завершится, а корневые подсказки вообще затрагиваться не будут.
В обширных внутренних средах DNS обдуманное применение серверов пере
сылки и корневых подсказок является обязательным. Внутренние серверы имен
поддоменов должны распознавать запросы от корневого DNS-cepвepa. Они также
должны распознавать запросы, основанные на И нтернете. Получая преимущес
тво возможности кеширования DNS, они могут полагаться на сервер в распозна
вании и сохранять распространен ные запросы, чтобы сократить внешний трафик.
В Microsoft рекомендуют, чтобы кеширующий сервер не был корневым, что поз
волит не перегружать корневой сервер дополнительной рабочей нагрузкой. Кроме того, в Microsoft предостерегают от прямого взаимодействия с Интернетом внутренних DNS-cepвepoв, на которых размещены зоны, чтобы уменьшить их видимость в
Интернете. На рис. 6.30 показано одно решение, которое могло бы работать с нашейвымышленной структурой DNS.
В этом примере серверы пересылки используются для отправки запросов корне
вому DNS-cepвepy в Bigfirm . com. Корневые подсказки можно было бы задейство
вать, уда,1ив корневые подсказки И нтернета и указав B F l . Bigfirm . com в качестве сервера корневых подсказок. Кеширующий сервер предотвращает отправку запросов
в Интернет DNS-серверами, на которых размещены зоны, интегрированные с Active
Directory. Он осуществляет преобразование имен посредством корневых подсказок.
Дr�я обработки запросов в домене Арех . сот применяется зона-заглушка или сервер
условной пересьшки.
Возможны другие решения, обеспечивающие преимущества по разным причи
нам. Мы отдаем предпочтение простоте использования серверон пересылки дr1я уп
равления интеграцией серверов.
Кеширующий
DNS-cepвep
Сервер пересылки
�
DNS-cepвep
Ecoast. Bigfirm.com
Зона-заглушка или
сервер условной пересылки
DNS-cepвep
Apex.com
Рис. 6.30. Внутренняя структура DNS

Администрирование и устранение неполадок с помощью инструментов DNS

В этом разделе мы обсудим доступные инструменты и приемы устранения непо
ладок в преобразовании имен DNS. Учитывая важность DNS, вы должны хорошо
знать инструменты, которые предоставляют ценную информацию, позволяющую
выявить возможные проблемы с преобразованием имен. Вдобавок к конфигурированию стандартные инструменты администрирования, консоль управления DNS и PowerShell предлагают также и дополнительную информацию такого рода. Утилиты
NsLookup, DcDiag и DNSLint предоставляют удобные начальные признаки нали
чия проблем, касающихся преобразования имен DNS.

Администрирование DNS-cepвepa с помощью консоли управления DNS и PowerShell

Для администрирования DNS-cepвepa придется иметь дело с двумя инструмен
тами: консолью управления DNS, которая является оснасткой М МС, и PoweгShell,
представляющим собой инструмент командной строки. Подобно оснастке ММС,
инструмент PowerShell предлагает возможность администрирования всего сервера, а также немного дополнительной функциональности. Например, как вы уже знаете,консоль управления DNS не позволяет изменять глобальный список блокировки запросов или создавать разделы каталога.
Повсюду в этой главе демонстрировалось применение консоли управления DNS
для создания зон и редактирования свойств серверов и зон, что является обыденными задачами, с которыми приходится иметь дело.

Вы также можете воспользоваться внутри консоли несколькими диагностически
ми конфигураuиями. Они настраиваются в свойствах DNS-cepвepa.
• Вкладка Event Logging (Ведение журнала событий). Для службы DNS создается
отдельный журнал, который можно открыть в программе просмотра событий
(Event Viewer). Он связан с консолью управления DNS. Вдобавок сервер по
умолчанию собирает все события, что настраивается на вкладке Event Logging.
+ Вкладка Debug Logging (Ведение журнала отладки). В целях анализа можно
собрать в журнале более детальные сведения о действительных коммуникаци
ях, возникающих на DNS-cepвepe. Ведение журнала отладки по умолчанию
отключено, но может быть включено через свойства DNS-cepвepa; вкладка
Debug Logging представлена на рис. 6.3 1 . Эта возможность полезна при выяв
лении причин ненадежной работы DNS-cepвepa. Хотя большинство проблем
с DNS решаются путем подходящей подключаемости IP, вы найдете данное
средство полезным, когда подключаемость IP не имеет отношения к пробле
ме. В редких случаях мы должны проверять, попадают ли специфичные запро
сы на сервер, и это средство предоставляет нужную информацию.
• Вкладка Monitoring (Мониторинг). Эта вкладка также доступна из окна свойств
DNS-cepвepa; она показана на рис. 6.32. Она позволяет проверить запросы
DNS из этого сервера или предназначенные другому серверу — обратите вни
мание, не конкретному серверу, а любому произвольно выбранному серверу.
Можно задать частоту запуска этого теста.
В выводе указывается только о том, прошел тест или нет. По существу, если на
DNS-cepвepe имеются проблемы, тест не проходит. Нам не удалось обнаружить на
этой вкладке сколько-нибудь полезные данные при решении проблем с DNS и,
скорее всего, вы не найдете здесь ничего нового. Для мониторинга DNS-cepвepoв
рекомендуется применять инструменты вроде диспетчера операций системного центра 2012 R2 (Microsoft System Center 2012 R2 Operations Manager), и эта тема обсуждается в главе 30 (том 2).
Инструмент PowerShell предлагает несколько диагностических командлетов, ко
торые могут оказаться полезными при сборе и анализе данных.
• Get-DNSServer предоставляет конфигурационные настройки для DNS
cepвepa.
• Get-DnsServer 1 Export-Clixml -Path «c: configDnsServerConfig.xml»
генерирует текстовый файл с конфигурацией и свойствами зон.
• Get-DNSServerDiagnostics предоставляет сведения о ведении журналов со
бытий для специфических операций DNS на сервере.
• Clear-DNSServerCache опустошает кеш. Иногда устаревшие распознанные
записи должны быть удалены после решения проблемы. Данная задача также
доступна в консоли управления DNS.
Все эти инструменты предоставляют средства администрирования и мониторин
га. Мы находим их полезными для проведения более глубоких исследований, когдапередовые инструменты, такие как NsLookup, DcDiag и DNSLint, не сразу указывают на проблему.

Использование NsLookup и DcDiag

При устранении проблем с DNS чаще всего используются инструменты
NsLookup, DcDiag и DNSLint. Утилита NsLookup предоставляет немедленное ука
зание на проблемы с преобразованием имен. Утилиты DcDiag и DNSLint обеспе
чивают указание на наличие проблем, связанных с Active Directory, таких как регистрация DDNS и записи SRV. Если с помощью этих инструментов не удается
идентифицировать проблему, можно положиться на средства консоли управления
DNS и PowerShell.

NsLookup
Утилита NsLookup является первым инструментом, который мы применяем при
поиске и устранении проблем с преобразованием имен. Она подключается к указан
ному в конфигурации IР-адресов основному DNS-cepвepy и делает запросы DNS.
Обратите внимание, что данная утилита не выполняет полный процесс преоб
разования имен, т.е. весь жизненный цикл. Она ограничивается одной частью этого цикла. Во время обсуждения клиентов приводились примеры команд ping и
net view, демонстрирующие различные части процесса. Пример команды ping
показывал процесс DNS, включающий первый шаг поиска имени в файле ноsтs.
Если файл ноsтs содержит записи для того же имени хоста, вы заметите расхождение между ping и NsLookup.
ВИРУС CONFICKER
Одним из примеров вредоносного ПОf использующего DNS мя нарушения нор
мальной работы, является вирус Conficker. Он появился в 2008 году, и, верите вы или нет, его до сих пор можно обнаружить на компьютерах, где не применялись
исправления системы и обновления антивирусного ПО. В зараженных вирусом
Coпficker системах предотвращается доступ из браузеров к важным сайтам внутри
определенных пространств имен DNS, таких как Microsoft . сот, Symantec . сот
и Norton . сот.
В результате ПО становится непригодным для использования. Компьютер не может
загрузить обновления Wi11dows; он не может найти возможные решения проблемы.
Даже если на машине установлено ПО Norton AntiVirus, ему не удается получить до
ступ к сайту обновлений Symantec для загрузки последних обновлений. Машина не может исправить сама себя!
Когда мы столкнулись с Co11ficker, утилита NsLookup была первым инструментом,
задействованным в процессе обнаружения проблемы. Запросы к Microsoft . сот и
Symantec . сот проходили нормально, но обращение к указанным сайтам из браузера Inteшet Explorer или Firefox оказывалось невозможным. Это помогло сузить область поиска. Таким образом, браузеры были заражены.
Конечно, утилита NsLookup предоставляет I Р-адреса мя сайтов, к которым нам необходим доступ. Однако веб-сайты Мicrosoft не функционируют в случае указания в URL только I Р-адреса. В результате такой обходной путь не срабатьmает.
Мы нашли решение с применением инструмента удаления вредоносного ПО
(Microsoft Windows Malicio11s Software Removal Tool — MSRT). Этот инструмент должен быть загружен на отдельном компьютере и затем физически перенесен на зараженный компьютер. С помощью MSRT вирус удалось идентифицировать и удалить.
К счастью, в наши дни распространение вируса Conficker ограничивается старыми ОС с устаревшим или отсутствующим антивирусным ПО и обновлениями Windows.
Тем не менее, это хороший пример того, как за счет изменения в преобразовании
имен нарушается работа системы и каким образом с помощью инструментов, подоб
ных NsLookup, найти и идентифицировать причину.
Если приложению не удается получить доступ к серверу, то после проверки
подключаемости ТСР /1 Р мы начинаем исследования с использованием команды
NsLookup.

Ниже перечислены вопросы, которые требуют прояснения.
• Отвечает ли DNS-cepвep? Команда в самом начале сообщит, можно ли под
ключиться к DNS-cepвepy. При наличии задержки или тайм-аута нет необхо
димости продолжать. Имеется проблема с подключаемостью.
• Является ли стандартный сервер неизвестным’? Это указывает на сбой обрат
ного просмотра, инициируемого утилитой NsLookup. При таком состоянии
остальные проверки NsLookup становятся бессмысленными.
• Можно ли преобразовать локальное имя FQDN’? Это обходит часть обработки
со стороны клиента. Для поиска имен хостов клиент будет добавлять основ
ные суффиксы DNS.
• Можно ли преобразовать имя хоста без суффикса DNS? Это то, что делает
клиент, и данный шаг можно проверить.
• Можно ли преобразовать внешние имена FQDN’? Это позволит проверить воз
можность выхода в Интернет стандартного DNS-cepвepa.
С утилитой NsLookup можно работать двумя способами: с помощью командных
запросов и в интерактивном режиме. Интерактивный режим намного мощнее, по
этому вначале используется именно он. Он предлагает возможность выполнять запросы к разным типам записей ресурсов и позволяет переключаться на другой сервер. Ниже приведены примеры распространенных запросов (вместе с поясняющими комментариями):
C : Use r s Ad.rninis t r ator . BFl>Nslookup
De fault Server : BFl . bigfirm . com
Address : 1 92 . 1 68 . 0 . 1 0
rem Запрос записи хоста
> BFl .bigfirm. com
Server : BFl . bigfirm . com
Address : 1 92 . 1 68 . 0 . l J
Name :
Addres s :
BFl . Ьigfirm . com
1 92 . 1 68 . 0 . 1 0
rem Запрос обратной записи PTR
> set q=ptr
> 192 . 168 . 0 . 10
Server :
l’.ddres s :
BFl . Ьigfi rm . com
1 92 . 1 68 . 0 . 1 0
10 . 1 . 1 68 . 1 92 . in-addr . a rpa
rem Запрос записи SOA
> set q=soa
> Ьigfirm . com
Server : BFl . Ьigfi rm . com
Address : 1 9 2 . 1 68 . О . 1 0
Ыgfirm . com
name = BFl . Ьigfirm . com
primary name server BFl . Ьigfirm . com
DNS и ПРЕОБРАЗОВАНИЕ ИМЕН в WINDOWS SERVER 201 2 R2
responsiЫe rnail addr = hostrnaster . bigfirm . com
serial = 124
ref resh = 900 ( 1 5 mins )
retry = 600 ( 10 min s )
expire = 8 6400 ( 1 day)
default TTL = 3600 ( 1 hour )
BFl . Ьigfirrn . сот
rem Запрос записи NS
> set <i»‘ns > bigfirrn . corn
interпet address
Server : BFl . bigfirm . com
Address : 1 92 . 1 68 . О . 1 0
1 92 . 1 68 . 0 . 1 0
bigfirm . com
BFl . Ьigfirm . com
nameserver = BFl . Ьigfirm . com
iпternet address = 1 92 . 1 68 . 0 . 1 0
rem Запрос записи SRV
> set q,zsrv
> _1dap._tcp .biqf’irm. com
Server : BFl . Ыgfir�. com
Address : 1 92 . 1 68 . 0 . 10
ldap . tcp . Ьigfirm . com SRV service locatioп :
priority О
weight 100
port 389
svr hostпame BFl . Ыgfirm . com
BFl . Ьigfirm . com iпterпet address = 1 92 . 1 68 . 0 . 1 0
DcDiaq
287
Утилита DcDiag изначально была частью набора инструментов для поддержки
администрирования (которые нужно было устанавливать отдельно) в ранних версиях Windows Server, но теперь она по умолчанию является частью установки Windows Server 2012 R2. Это инструмент, который нужно применять первым для быстрой проверки работоспособности структуры DNS. Поскольку утилита DcDiag проводит диагностику контроллеров домена, она должна проверить корректность работы DNS. После выполнения стандартного набора тестов вы можете заметить ошибки при попытках подключения к контроллерам домена. После этого можно запустить дополнительные тесты DcDiag, ориентированные специально на DNS. В следующем примере осуществляется проверка, может ли контроллер домена выполнять DDNS для регистрации записей SRV:
dcdiaq /test:ReqisterrnDNS /DnsDomain:biqf’irm. com
/f : docшnentsdcdiaqRegisterinDNS . txt
Н иже показан вывод этой команды:
Startiпg tes t : Regis teriпDNS
DNS coпfiguratioп is suf f icieпt to allow this domaiп coпtroller to
dyпamicall y register the domaiп controller Locator records i n DNS .
The DNS coпfiguration is sufficient to allow this computer to dyпarnically
register the А record correspoпdiпg to its DNS паmе .
. . . . . . . . . . . . . . . . . . . . . . . . . BFl passed test RegisteriпDNS
288
Запуск теста : Regis terinDNS
Конфигурация DNS доста точна для того, чтобы позволить этому
контроллеру домена динамически регистрировать записи Loca tor
контроллеру домена в DNS .
Конфигурация DNS достаточна для того, чтобы позволить этому
контроллеру домена динамически регистрировать запись А,
соответствующую его имени DNS .
. . . . . . . . . . . . . . . . . . . . . . . . . Brl прошел тест RegisterinDNS
Утилита DcDiag выполняет множество тестов, относящихся к контроллеру доме
на, включая несколько тестов DNS. Выше был упомянут один из таких тестов —
RegisterinDNS. Эти тесты в первую очередь сосредоточены на интеграции между
DNS-серверами внутри среды Active Directol)’. Тесты могут быть выполнены в отно
шении делегирования, серверов пересылки, обновлений и преобразовании внешних
имен DNS.
Ниже приведена часть справочной информации по утилите DcDiag. В ней при
сутствует список тестов, доступных для DNS. При тестировании преобразования
внешних имен мы обычно полагаемся на NsLookup, поэтому никогда не пользуемся
тестами /DnsForwarders и /DnsResolveExtName, но для полноты они здесь пока
заны.
DNS
Этот тест проверяет работоспособность настроек DNS для целого
предприятия . Подтесты могут запускаться по отдельности с применением
перечисленных далее ключей . По умолчанию запускаются все тесты кроме
тех , кото�:;ые проверяют преобразование внешних имен .
/DnsBas ic
/Dпs Forwarders
/DnsDelegation
/DnsDynamicUpda te
/DnsRecordRegistrat ion
/DnsResolveExtName
/DnsAll
/Dns internetName :
( базовые тесты, не могут быть пропущены)
(тесты для серверов пересылки и корневых подсказок)
( тесты для делегирования )
( тесты для динамических обновлений )
( тесты для регистрацv.и записей )
(тесты для преобразования вl-!ешних имен)
includes all tests above )
<Интер!-!ет-имя> (для теста /DnsResolveExtName )
( по умолчанию www .microsof t . com)
Как обсуждалось ранее при рассмотрении записей SRV, количество та
ких записей, зарегистрированных контроллером домена, настолько велико,
что определить на глаз, корректно ли они работают, достаточно трудно. В до
полнение к тесту / regi sterinDNS прогоняются тесты /DnsDynamicUpdate и
/DnsRecordRegistration, проверяющие регистрацию записей SRV контроллерами
доменов. В отличие от /registerinDNS, они не обязательно должны запускаться
локально на контроллере домена. Представленная ниже команда будет верифици
ровать записи SRV мя контроллера домена. Опция /v означает «verЬose» («подроб
но»). Вывод получаетсs� минным, поскольку в нем перечислены все записи SRV мя контроллера домена.
С : Jsers Administrator . БFl >dcdiag /s :BFl .Ьigfirm. com
/test : dns /dnsrecordregistration /v
DNS И ПРЕОБРАЗОВАНИЕ ИМЕН В WINDOWS 5ERVER 201 2 R2 289
Следующая команда будет проверять работоспособность обновлений DDNS мя
зоны. Она зарегистрирует хост и удалит его из зоны DNS сервера. В данном случае сервером является Ecoast . Bigfirm. сот.
C : UsersAdministrator . BFl>dcdiag /s :ecl . Ecoast . Bigfirm. com
/test:dns /dnsdynamicupdate /v
ИНСТРУМЕНТ DIG МОЩНЕЕ, ЧЕМ NsLookup
Существует инструмент для устранения неполадок в DNS, который эксплуатиру
ется в мире Unix на протяжении продолжительного времени и называется Domain
Wormation Groper (Прощупывание доменной информации), или DJG. Если вы спро
сите у пользователей DJG их мнение о том, насколько сравнима утилита NsLookup с DIG как инструмент для устранения неполадок в DNS, то не удивляйтесь, если они сначала рассмеются, после чего вежливо скажут, что они вообще несравнимы!
Однако хорошая новость в том, что DIG можно загрузить совершенно бесплатно
(http: //www . isc . org/software/Ьind) и установить в среде Windows Server 2012 R2, тем самым серьезно усилив уровень устранения неполадок в DNS. Инструмент DIG можно запускать в обычном формате командной строки, но он располагает также пакетным режимом, который поддерживает чтение запросов просмотра из файла.
Сведения по установке DIG в системе Windows Server доступны по ссылке http : / /tinyurl . com/DIGinstall. Можете также просмотреть онлайновое руководство поработе с DIG, воспользовавшись ссылкой http : //tinyurl . com/DIGusage.

Полезные ссылки по устранению неполадок в DNS

Все рассмотренные до сих пор инструменты основаны на том, что доступно в
готовом виде в ОС Windows Serveг 2012 R2. Именно с этих инструментов вы должны начинать поиск и устранение проблем в сети. В настоящем разделе мы поделимся с вами адресами нескольких веб-сайтов, имеющих отношение к DNS, которые окажут содействие в решении проблем с внешними именами DNS.
• www . IntoDNS . com. Это простой, но эффективный веб-сайт, который вы должны добавить в свой арсенал инструментов для поиска и устранения неполадок
в DNS. Когда вы достигаете домашней страницы, понадобится лишь ввести
DNS-имя домена, о котором нужно получить информацию, и щелкнуть на
кнопке Report (Отчет). В результате возвратится все доступные сведения по записям А (родительской), NS, SOA, МХ и WWW мя домена. Располагая этой
информацией, вы можете быстро идентифицировать некорректно сконфигу
рированные записи или же просто использовать ее при перекрестном контро
ле предоставленных вам сведений.
• www . мхтоо lЬо х . com. Этот сайт делает намного больше того, что заявлено на
его начальной странице. Он предназначен для содействия в поиске и устра
нении проблем с записями МХ и может оказаться полезным при попытках
выяснить, почему почтовый поток для отдельного домена электронной почты
не работает. В отношении любого домена можно запускать несколько разных
тестов, таких как просмотр МХ, проверка черного списка (Blacklist), просмотр
Whois и верификация SMTP. Если вы не пользовались этим сайтом ранее, то
самое время добавить его в список закладок.
290 ГЛАВА 6
• http://www.DNSStuff . com. Это еще один популярный сайт, который можно приме
нять мя формирования отчетов по DNS, просмотров Whois и информаuии об
1 Р-адресах. Здесь вы можете также получить доступ к большому количеству
дополнительных инструментов дЛЯ поиска и устранения проблем с DNS, если
приобретете учетную запись на нем, но сначала имеет смысл оценить обещан
ные преимущества, воспользовавшись пробным периодом.

Источник

Настроим DNS-сервер пошагово.

Настройка сетевого адаптера для DNS-сервера

Далее предстоит проделать цепочку действий:

Нажать правой клавишей мыши Пуск, в выпадающем меню выбрать пункт Сетевые подключения;
Правой кнопкой мыши нажать на необходимый сетевой адаптер, в меню выбрать Свойства;
В окне свойств выбрать IPv4 и нажать на кнопку Свойства;
Заполнить соответствующие поля необходимыми данными:

Здесь в качестве предпочитаемого DNS-сервера машина назначена сама себе, альтернативным назначен dns.google [8.8.8.8].

Установка роли DNS-сервера

Откроется окно Мастера, в котором рекомендуют убедиться что:

1. Учётная запись администратора защищена надёжным паролем.

2. Настроены сетевые параметры, такие как статические IP-адреса.

3. Установлены новейшие обновления безопасности из центра обновления Windows.

Убедившись, что все условия выполнены, нажимайте Далее;

Выберите Установку ролей и компонентов и нажмите Далее:

Выберите необходимы сервер из пула серверов и нажмите Далее:

Отметьте чек-боксом роль DNS-сервер и перейдите Далее:

Проверьте список компонентов для установки, подтвердите нажатием кнопки Добавить компоненты:

Оставьте список компонентов без изменений, нажмите Далее:

Прочитайте информацию и нажмите Далее:

В последний раз проверьте конфигурацию установки и подтвердите решение нажатием кнопки Установить:

Финальное окно Мастера сообщит, что установка прошла успешно, Мастер установки можно закрыть:

Создание зон прямого и обратного просмотра

Доменная зона — совокупность доменных имён в пределах конкретного домена.

Зоны прямого просмотра предназначены для сопоставления доменного имени с IP-адресом.

Зоны обратного просмотра работают в противоположную сторону и сопоставляют IP-адрес с доменным именем.

Создание зон и управление ими осуществляется при помощи Диспетчера DNS.

Создание зоны прямого просмотра

Выделите каталог Зоны Прямого Просмотра, запустите Мастер Создания Новой Зоны с помощью кнопки Новая зона на панели инструментов сверху:

Откроется окно Мастера с приветствием, нажмите Далее:

Из предложенных вариантов выберите Основная зона и перейдите Далее:

Укажите имя зоны и нажмите Далее:

При необходимости поменяйте название будущего файла зоны и перейдите Далее:

Выберите, разрешить динамические обновления или нет. Разрешать не рекомендуется в силу значимой уязвимости. Перейдите Далее:

Проверьте правильность выбранной конфигурации и завершите настройку, нажав кнопку Готово:

Создание зоны обратного просмотра

Выделите в Диспетчере DNS каталог Зоны Обратного Просмотра и нажатием кнопки Новая зона на панели инструментов сверху запустите Мастер Создания Новой Зоны:

Выберите тип Основная Зона, перейдите Далее:

Выберите назначение для адресов IPv4, нажмите Далее:

Укажите идентификатор сети (первые три октета сетевого адреса) и следуйте Далее:

При необходимости поменяйте название будущего файла зоны и перейдите Далее:

Выберите, разрешить динамические обновления или нет. Разрешать не рекомендуется в силу значимой уязвимости. Перейдите Далее:

Проверьте правильность выбранной конфигурации и завершите настройку, нажав кнопку Готово:

Создание A-записи

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

Запись A — запись, позволяющая по доменному имени узнать IP-адрес.

Запись PTR — запись, обратная A записи.

В Диспетчере DNS выберите каталог созданной ранее зоны внутри каталога Зон Прямого Просмотра. В правой части Диспетчера, где отображается содержимое каталогов, правой кнопки мыши вызовите выпадающее меню и запустите команду “Создать узел (A или AAAA)…”:

Откроется окно создания Нового Узла, где понадобится вписать в соответствующие поля имя узла (без доменной части, в качестве доменной части используется название настраиваемой зоны) и IP-адрес. Здесь же имеется чек-бокс Создать соответствующую PTR-запись — чтобы проверить работу обеих зон (прямой и обратной), чек-бокс должен быть активирован:

Если поле имени остается пустым, указанный адрес будет связан с именем доменной зоны.

Также можно добавить записи для других серверов:

Добавив все необходимые узлы, нажмите Готово.

Проверка

Проверьте изменения в каталогах обеих зон (на примере ниже в обеих зонах появилось по 2 новых записи):

Откройте командную строку (cmd) или PowerShell и запустите команду nslookup:

Из вывода команды видно, что по умолчанию используется DNS-сервер example-2012.com с адресом 10.0.1.6.

Чтобы окончательно убедиться, что прямая и обратная зоны работают как положено, можно отправить два запроса:

Запрос по домену;
Запрос по IP-адресу:

В примере получены подходящие ответы по обоим запросам.

Можно попробовать отправить запрос на какой-нибудь внешний ресурс:

Для сравнения все те же запросы выполнены на сервере, где не были настроены прямая и обратная зоны:

Новые и измененные функции DNS в Windows Server 2016

В Windows Server 2016 DNS-сервер предлагает обновления в следующих областях:

Политики DNS-серверов

Теперь вы сможете использовать:

DNS-политики для управления трафиком на основе геолокации
Интеллектуальные ответы DNS в зависимости от времени суток, для управления одним DNS-сервером, настроенным для развертывания с разделением
Применять фильтры к DNS-запросам и многое другое.

Конкретное описание данных возможностей:

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

Ограничение скорости отклика (RRL)

Белые домены. Это список доменов, которые нужно исключить из настроек RRL.

Белые подсети. Это список подсетей, которые необходимо исключить из настроек RRL.

Аутентификация именованных объектов на основе DNS (DANE)

Поддержка неизвестных записей

Корневые подсказки IPv6

Доработка поддержки Windows PowerShell

В Windows Server 2016 представлены следующие новые командлеты (cmdlets) и параметры Windows PowerShell:

Add-DnsServerRecursionScope – Этот командлет создает новую область рекурсии на DNS-сервере. Области рекурсии используются политиками DNS для указания списка серверов пересылки, которые будут использоваться в запросе DNS.

Remove-DnsServerRecursionScope – Этот командлет удаляет существующие области рекурсии.

Set-DnsServerRecursionScope – Этот командлет изменяет параметры существующей области рекурсии.

Get-DnsServerRecursionScope – Этот командлет извлекает информацию о существующих областях рекурсии.

Add-DnsServerClientSubnet – Этот командлет удаляет существующие подсети DNS-клиентов.

Set-DnsServerClientSubnet – Этот командлет изменяет параметры существующей подсети DNS-клиента.

Get-DnsServerClientSubnet – Этот командлет извлекает информацию о существующих подсетях DNS-клиентов.

Add-DnsServerQueryResolutionPolicy – Этот командлет создает новую политику разрешения запросов DNS. Политики разрешения запросов DNS используются для указания того, как и следует ли отвечать на запрос на основе различных критериев.

Remove-DnsServerQueryResolutionPolicy – Этот командлет удаляет существующие политики DNS.

Set-DnsServerQueryResolutionPolicy – Этот командлет изменяет параметры существующей политики DNS.

Get-DnsServerQueryResolutionPolicy – Этот командлет извлекает информацию о существующих политиках DNS.

Enable-DnsServerPolicy – Этот командлет включает существующие политики DNS.

Disable-DnsServerPolicy – Этот командлет отключает существующие политики DNS.

Add-DnsServerZoneTransferPolicy – Этот командлет создает новую политику передачи зоны DNS-сервера. Политики передачи зоны DNS определяют, следует ли отклонять или игнорировать передачу зоны на основе различных критериев.

Remove-DnsServerZoneTransferPolicy – Этот командлет удаляет существующие политики передачи зон DNS-сервера.

Set-DnsServerZoneTransferPolicy. – Этот командлет изменяет параметры существующей политики переноса зоны DNS-сервера.

Get-DnsServerResponseRateLimiting – Этот командлет извлекает параметры RRL.

Set-DnsServerResponseRateLimiting – Этот командлет изменяет настройки RRL.

Add-DnsServerResponseRateLimitingExceptionlist – Этот командлет создает список исключений RRL на DNS-сервере.

Get-DnsServerResponseRateLimitingExceptionlist – Этот командлет извлекает списки исключений RRL.

Remove-DnsServerResponseRateLimitingExceptionlist – Этот командлет удаляет существующий список исключений RRL.

Set-DnsServerResponseRateLimitingExceptionlist – Этот командлет изменяет списки исключений RRL.

Add-DnsServerResourceRecord – Этот командлет был обновлен для поддержки неизвестного типа записи.

Get-DnsServerResourceRecord – Этот командлет был обновлен для поддержки неизвестного типа записи.

Remove-DnsServerResourceRecord – Этот командлет был обновлен для поддержки неизвестного типа записи.

Set-DnsServerResourceRecord – Этот командлет был обновлен для поддержки неизвестного типа записи.

Источник

In this guide, I’ll provide a quick overview of the different DNS Zone types for Windows Server and Active Directory.

This will help you better understand and manage DNS and Active Directory.

DNS Zones store DNS resource record information. Some common DNS records include:

A Record: Name to IP address mapping
CNAME: Maps an alias to the canonical name
MX Record: Used to identify mail servers
NS Record: Identifies the name servers for a particular zone
SOA: Start of Authority records
TXT: Allows any text to be inserted into a DNS record

There are many more record types, and without these records, everything would be accessed by an IP address.

DNS Zones provide us with a way to maintain these records on one or more servers.

List of Active Directory DNS Zones Types

Below are the zone types supported by Active Directory.

Active Directory Integrated Zones

Active Directory Integrated Zones stores its zone data in Active Directory. Integrated zones can be replicated to all domain controllers in the domain and forest. Active Directory integrated zones use multi-master replication, which means any domain controller running the DNS server service can write updates to the zone for which they are authoritative.

Advantages of Active Directory integrated Zones

Replication is faster, more secure, and more efficient
Better redundancy due to zone data being copied to all Domain Controllers
Improved Security if secure dynamic update is enabled
No need to schedule or manage zone transfers

Primary Zone

This is the main zone and has a read/write copy of the zone data. All changes to the zone are made in the primary zone and are replicated to the secondary zones.

The zone data is stored in a text file located in this folder c:\windows\system32\DNS on the Windows server running DNS.

Secondary Zone

A secondary Zone is a read-only copy of the primary zone. This zone cannot process updates and can only retrieve updates from the primary zone. This zone can answer DNS name resolution queries from clients nodes, this helps reduce the workload on the primary zone. Secondary zones cannot be active directory integrated.

Stub Zone

Stub zones are like a secondary zone but only stores partial zone data. These zones are useful to help reduce zone transfers by passing the requests to authoritative servers. These zones only contain the SOA, NS, and A records.

Forward Lookup Zone

A forward lookup zone provides hostname to IP address resolution.

When you access a system or website by its hostname such as mcirosoft.com DNS checks the forward lookup zone for the IP information related to the hostname.

Reverse Lookup Zone

Reverse lookup zones resolve IP addresses into hostnames.

For example, when you look up the IP 8.8.8.8 it resolves to google-public-dns-a.google.com. A reverse DNS record had to be created for the IP to resolve to the hostname.

Reverse lookup zones are not as common as forwarding lookups and in most cases are not needed.

Zone Transfers

Zone transfers take place when they are not integrated with Active Directory. A Zone transfer is where the master DNS servers transfer zone data from the master to the secondary.

Zone transfers can occur during any of the following

When the refresh interval expires
When a master server notifies a change has occurred
When the server has rebooted or DNS service has restarted
A manual transfer has occurred from the DNS console

Related: How to Use NSLookup to Check DNS Records

Источник

Время на прочтение
11 мин

Количество просмотров 98K

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

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

Содержание:

1. Основные сведения
2. Немного о формате сообщения DNS
3. TCP и UDP
4. DNS в Windows Server 2008 и 2012
5. DNS и Active directory
6. Источники информации

(анкеров нет, поэтому содержание без ссылок)

1. Основные сведения

DNS — это база данных, содержащая, в основном, информацию о сопоставлении имён сетевых объектов их IP-адресам. «В основном» — потому что там и ещё кое-какая информация хранится. А точнее, ресурсные записи (Resource Records — RR) следующих типов:

А — то самое сопоставление символьного имени домена его IP адресу.

АААА — то же что А, но для адресов IPv6.

CNAME — Canonical NAME — псевдоним. Если надо чтобы сервер с неудобочитаемым именем, типа nsk-dc2-0704-ibm, на котором вертится корпоративный портал, откликался также на имя portal, можно создать для него ещё одну запись типа А, с именем portal и таким же IP-адресом. Но тогда, в случае смены IP адреса (всякое бывает), нужно будет пересоздавать все подобные записи заново. А если сделать CNAME с именем portal, указывающий на nsk-dc2-0704-ibm, то ничего менять не придётся.

MX — Mail eXchanger — указатель на почтовый обменник. Как и CNAME, представляет собой символьный указатель на уже имеющуюся запись типа A, но кроме имени содержит также приоритет. MX-записей может быть несколько для одного почтового домена, но в первую очередь почта будет отправляться на тот сервер, для которого указано меньшее значение в поле приоритета. В случае его недоступности — на следующий сервер и т.д.

NS — Name Server — содержит имя DNS-сервера, ответственного за данный домен. Естественно для каждой записи типа NS должна быть соответствующая запись типа А.

SOA — Start of Authority — указывает на каком из NS-серверов хранится эталонная информация о данном домене, контактную информацию лица, ответственного за зону, тайминги хранения информации в кэше.

SRV — указатель на сервер, держатель какого-либо сервиса (используется для сервисов AD и, например, для Jabber). Помимо имени сервера содержит такие поля как Priority (приоритет) — аналогичен такому же у MX, Weight (вес) — используется для балансировки нагрузки между серверами с одинаковым приоритетом — клиенты выбирают сервер случайным образом с вероятностью на основе веса и Port Number — номер порта, на котором сервис «слушает» запросы.

Все вышеперечисленные типы записей встречаются в зоне прямого просмотра (forward lookup zone) DNS. Есть ещё зона обратного просмотра (reverse lookup zone) — там хранятся записи типа PTR — PoinTeR — запись противоположная типу A. Хранит сопоставление IP-адреса его символьному имени. Нужна для обработки обратных запросов — определении имени хоста по его IP-адресу. Не требуется для функционирования DNS, но нужна для различных диагностических утилит, а также для некоторых видов антиспам-защиты в почтовых сервисах.

Кроме того, сами зоны, хранящие в себе информацию о домене, бывают двух типов (классически):

Основная (primary) — представляет собой текстовый файл, содержащий информацию о хостах и сервисах домена. Файл можно редактировать.

Дополнительная (secondary) — тоже текстовый файл, но, в отличие от основной, редактированию не подлежит. Стягивается автоматически с сервера, хранящего основную зону. Увеличивает доступность и надёжность.

Для регистрации домена в интернет, надо чтоб информацию о нём хранили, минимум, два DNS-сервера.

В Windows 2000 появился такой тип зоны как интегрированная в AD — зона хранится не в текстовом файле, а в базе данных AD, что позволяет ей реплицироваться на другие контроллеры доменов вместе с AD, используя её механизмы репликации. Основным плюсом данного варианта является возможность реализации безопасной динамической регистрации в DNS. То есть записи о себе могут создать только компьютеры — члены домена.

В Windows 2003 появилась также stub-зона — зона-заглушка. Она хранит информацию только о DNS-серверах, являющихся полномочными для данного домена. То есть, NS-записи. Что похоже по смыслу на условную пересылку (conditional forwarding), которая появилась в этой же версии Windows Server, но список серверов, на который пересылаются запросы, обновляется автоматически.

Итеративный и рекурсивный запросы.

Понятно, что отдельно взятый DNS-сервер не знает обо всех доменах в интернете. Поэтому, при получении запроса на неизвестный ему адрес, например metro.yandex.ru, инициируется следующая последовательность итераций:

DNS-сервер обращается к одному из корневых серверов интернета, которые хранят информацию о полномочных держателях доменов первого уровня или зон (ru, org, com и т.д.). Полученный адрес полномочного сервера он сообщает клиенту.

Клиент обращается к держателю зоны ru с тем же запросом.

DNS-сервер зоны RU ищет у себя в кэше соответствующую запись и, если не находит, возвращает клиенту адрес сервера, являющегося полномочным для домена второго уровня — в нашем случае yandex.ru

Клиент обращается к DNS yandex.ru с тем же запросом.

DNS яндекса возвращает нужный адрес.

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

Клиент, как правило, обращается с запросом, имеющим флаг «требуется рекурсия».

2. Немного о формате сообщения DNS

Сообщение состоит из 12-байтного заголовка, за которым идут 4 поля переменной длины.

Заголовок состоит из следующих полей:

Формат DNS-сообщения

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

Флаги — 16-битовое поле, поделенное на 8 частей:

QR (тип сообщения), 1-битовое поле: 0 обозначает — запрос, 1 обозначает — отклик.
opcode (код операции), 4-битовое поле. Обычное значение 0 (стандартный запрос). Другие значения — это 1 (инверсный запрос) и 2 (запрос статуса сервера).
AA — 1-битовый флаг, который означает «авторитетный ответ» (authoritative answer). Сервер DNS имеет полномочия для этого домена в разделе вопросов.
TC — 1-битовое поле, которое означает «обрезано» (truncated). В случае UDP это означает, что полный размер отклика превысил 512 байт, однако были возвращены только первые 512 байт отклика.
RD — 1-битовое поле, которое означает «требуется рекурсия» (recursion desired). Бит может быть установлен в запросе и затем возвращен в отклике. Этот флаг требует от DNS сервера обработать этот запрос самому (т.е. сервер должен сам определить требуемый IP адрес, а не возвращать адрес другого DNS сервера), что называется рекурсивным запросом (recursive query). Если этот бит не установлен и запрашиваемый сервер DNS не имеет авторитетного ответа, запрашиваемый сервер возвратит список других серверов DNS, к которым необходимо обратиться, чтобы получить ответ. Это называется повторяющимся запросом (iterative query). Мы рассмотрим примеры обоих типов запросов в следующих примерах.
RA — 1-битовое поле, которое означает «рекурсия возможна» (recursion available). Этот бит устанавливается в 1 в отклике, если сервер поддерживает рекурсию. Мы увидим в наших примерах, что большинство серверов DNS поддерживают рекурсию, за исключением нескольких корневых серверов (коневые сервера не в состоянии обрабатывать рекурсивные запросы из-за своей загруженности).
0 — Это 3-битовое поле должно быть равно 0.
rcode это 4-битовое поле кода возврата. Обычные значения: 0 (нет ошибок) и 3 (ошибка имени). Ошибка имени возвращается только от полномочного сервера DNS и означает, что имя домена, указанного в запросе, не существует.

Следующие четыре 16-битных поля указывают на количество пунктов в четырех полях переменной длины, которые завершают запись. В запросе количество вопросов (number of questions) обычно равно 1, а остальные три счетчика равны 0. В отклике количество ответов (number of answers) по меньшей мере равно 1, а оставшиеся два счетчика могут быть как нулевыми, так и ненулевыми.

Пример (получен с помощью WinDump при выполнении команды ping www.ru):

IP KKasachev-nb.itcorp.it.ru.51036 > ns1.it.ru.53: 36587+ A? www.ru. (24)
IP ns1.it.ru.53 > KKasachev-nb.itcorp.it.ru.51036: 36587 1/2/5 A 194.87.0.50 (196)

Первая строка — запрос: имя моего ПК, 51036 — случайно выбранный порт отправки, 53- заранее известный порт DNS-сервера, 36587 — идентификатор запроса, + — «требуется рекурсия», А — запрос записи типа А, знак вопроса означает, что это запрос, а не ответ. В скобках — длина сообщения в байтах.

Вторая строка — ответ сервера: на указанный исходный порт с указанным идентификатором запроса. Ответ содержит одну RR (ресурсную запись DNS), являющуюся ответом на запрос, 2 записи полномочий и 5 каких-то дополнительных записей. Общая длина ответа — 196 байт.

3. TCP и UDP

На слуху сведения о том, что DNS работает по протоколу UDP (порт 53). Это действительно по умолчанию так — запросы и ответы отправляются по UDP. Однако, выше упоминается наличие в заголовке сообщения флага TC (Truncated). Он выставляется в 1, если размер отклика превысил 512 байт — предел для UDP-отклика — а значит был обрезан и клиенту пришли только первые 512 байт. В этом случае клиент повторяет запрос, но уже по TCP, который ввиду своей специфики, может безопасно передать большие объёмы данных.

Также передача зон от основных серверов к дополнительным осуществляется по TCP, поскольку в этом случае передаётся куда больше 512 байт.

4. DNS в Windows Server 2008 и 2012

В Windows 2008 появились следующие возможности:

Фоновая загрузка зон

В очень крупных организациях с крайне большими зонами, использующих для хранения данных DNS доменные службы Active Directory, перезапуск DNS-сервера может длиться час или более, пока данные DNS извлекаются из службы каталогов. При этом DNS-сервер недоступен для обслуживания клиентских запросов все время, пока длится загрузка зон доменных служб Active Directory.
DNS-сервер с ОС Windows Server 2008 теперь во время перезагрузки загружает данные зоны из доменных служб Active Directory в фоновом режиме, благодаря чему может при этом обрабатывать запросы данных из других зон. При запуске DNS-сервера выполняются следующие действия:

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

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

Поддержка IPv6-адресов

Протокол Интернета версии 6 (IPv6) определяет адреса, длина которых составляет 128 бит, в отличие от адресов IP версии 4 (IPv4), длина которых составляет 32 бита.
DNS-серверы с ОС Windows Server 2008 теперь полностью поддерживают как IPv4-адреса, так и IPv6-адреса. Средство командной строки dnscmd также принимает адреса в обоих форматах. Cписок серверов пересылки может содержать и IPv4-адреса, и IPv6-адреса. DHCP-клиенты также могут регистрировать IPv6-адреса наряду с IPv4-адресами (или вместо них). Наконец, DNS-серверы теперь поддерживают пространство имен домена ip6.arpa для обратного сопоставления.

Изменения DNS-клиента

Разрешение имен LLMNR
Клиентские компьютеры DNS могут использовать разрешение имен LLMNR (Link-local Multicast Name Resolution), которое также называют многоадресной системой DNS или mDNS, для разрешения имен в сегменте локальной сети, где недоступен DNS-сервер. Например, при изоляции подсети от всех DNS-серверов в сети из-за сбоя в работе маршрутизатора клиенты в этой подсети, поддерживающие разрешение имен LLMNR, по-прежнему могут разрешать имена с помощью одноранговой схемы до восстановления соединения с сетью.
Кроме разрешения имен в случае сбоя в работе сети функция LLMNR может также оказаться полезной при развертывании одноранговых сетей, например, в залах ожидания аэропортов.

Изменения Windows 2012 в части DNS коснулись, преимущественно, технологии DNSSEC (обеспечение безопасности DNS за счет добавления цифровых подписей к записям DNS), в частности — обеспечение динамических обновлений, которые были недоступны, при включении DNSSEC в Windows Server 2008.

5. DNS и Active directory

Active Directory очень сильно опирается в своей деятельности на DNS. С его помощью контроллеры домена ищут друг друга для репликации. С его помощью (и службы Netlogon) клиенты определяют контроллеры домена для авторизации.

Для обеспечения поиска, в процессе поднятия на сервере роли контроллера домена, его служба Netlogon регистрирует в DNS соответствующие A и SRV записи.

SRV записи регистрируемые службой Net Logon:

_ldap._tcp.DnsDomainName
_ldap._tcp.SiteName._sites.DnsDomainName
_ldap._tcp.dc._msdcs.DnsDomainName
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName
_ldap._tcp.pdc._msdcs.DnsDomainName
_ldap._tcp.gc._msdcs.DnsForestName
_ldap._tcp.SiteName._sites.gc._msdcs. DnsForestName
_gc._tcp.DnsForestName
_gc._tcp.SiteName._sites.DnsForestName
_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName
_kerberos._tcp.DnsDomainName.
_kerberos._udp.DnsDomainName
_kerberos._tcp.SiteName._sites.DnsDomainName
_kerberos._tcp.dc._msdcs.DnsDomainName
_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName
_kpasswd._tcp.DnsDomainName
_kpasswd._udp.DnsDomainName

Первая часть SRV-записи идентифицирует службу, на которую указывает запись SRV. Существуют следующие службы:

_ldap — Active Directory является службой каталога, совместимой с LDAP-протоколом, с контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV идентифицирует LDAP серверы, имеющиеся в сети. Эти серверы могут быть контроллерами домена Windows Server 2000+ или другими LDAP-серверами;

_kerberos — SRV-записи _kerberos идентифицируют все ключевые центры распределения (KDC — Key Distribution Centers) в сети. Они могут быть контроллерами домена с Windows Server 2003 или другими KDC-серверами;

_kpassword — идентифицирует серверы изменения паролей kerberos в сети;

_gc — запись, относящаяся к функции глобального каталога в Active Directory.

В поддомене _mcdcs регистрируются только контроллеры домена Microsoft Windows Server. Они делают и основные записи и записи в данном поддомене. Не-Microsoft-службы делают только основные записи.

Записи, содержащие идентификатор сайта SiteName, нужны для того чтобы клиент мог найти контроллер домена для авторизации в своём сайте, а не лез авторизовываться в другой город через медленные каналы.

DomainGuid — глобальный идентификатор домена. Запись, содержащщая его, нужна на случай переименования домена.

Как происходит процесс поиска DC

Во время входа пользователя, клиент инициирует DNS-локатор, при помощи удалённого вызова процедуры (Remote Procedure Call — RPC) службой NetLogon. В качестве исходных данных в процедуру передаются имя компьютера, название домена и сайта.

Служба посылает один или несколько запросов с помощью API функции DsGetDcName()

DNS сервер возвращает запрошенный список серверов, рассортированный согласно приоритету и весу. Затем клиент посылает LDAP запрос, используя UDP-порт 389 по каждому из адресов записи в том порядке, как они были возвращены.

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

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

Служба Netlogon кэширует информацию о местонахождении контроллера домена, чтобы не инициировать всю процедуру при каждой необходимости обращения к DC. Однако, если используется «неоптимальный» DC (расположенный в другом сайте), клиент очищает этот кэш через 15 минут и инициирует поиски заново (в попытке найти свой оптимальный контроллер).

Если у комьютера отсутствует в кэше информация о его сайте, он будет обращаться к любому контроллеру домена. Для того чтобы пресечь такое поведение, на DNS можно настроить NetMask Ordering. Тогда DNS выдаст список DC в таком порядке, чтобы контроллеры, расположенные в той же сети, что и клиент, были первыми.

Пример: Dnscmd /Config /LocalNetPriorityNetMask 0x0000003F укажет маску подсети 255.255.255.192 для приоритетных DC. По умолчанию используется маска 255.255.255.0 (0x000000FF)

Источники информации:

www.hardline.ru/4/49/1236/1630-25.html

www.inadmin.ru/2010/02/26/dns-internet-domain

minergimn.ru/statii/16-adwin2003132

technet.microsoft.com/ru-ru/library/cc728909.aspx

support.microsoft.com/kb/247811/en-us?fr=1

Источник