Историческая справка : Систему доменных имен разработал в 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%\system32\drivers\etc (где %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.
Имя домена	Назначение
	Сообщества авиаторов
	Компании (без привязки к стране)
	Коммерческие организации, преимущественно в США (например, домен microsoft.com для корпорации Microsoft)
	Кооперативы
	Образовательные учреждения в США
	Правительственные учреждения США
	Домен для организаций, предоставляющих любую информацию для потребителей
	международные организации (например, домен nato .int для НАТО)
	Военные ведомства США
	Глобальный домен для частных лиц
	Домен для Интернет-провайдеров и других организаций, управляющих структурой сети Интернет
	Некоммерческие и неправительственные организации, преимущественно в США
	Домен для профессиональных объединений (врачей, юристов, бухгалтеров и др.)
	Кадровые агентства
	Туроператоры

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

Таблица 4.5.
Тип ресурсной записи	Функция записи	Описание использования
	Host Address Адрес хоста, или узла	Отображает имя узла на IP-адрес (например, для домена microsoft.com узлу с именем www.microsoft.com сопоставляется IP-адрес с помощью такой записи: www A 207.46.199.60)
	Canonical Name (alias) Каноническое имя (псевдоним)	Отображает одно имя на другое
	Mail Exchanger Обмен почтой	Управляет маршрутизацией почтовых сообщений для протокола SMTP
	Name Server Сервер имен	Указывает на серверы DNS, ответственные за конкретный домен и его поддомены
	Pointer Указатель	Используется для обратного разрешения IP-адресов в имена узлов в домене in-addr.arpa
	Start of Authority Начальная запись зоны	Используется для указания основного сервера для данной зоны и описания свойств зоны
	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%\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 (итеративный запрос).

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

microsoft.com ;

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

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 ):

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

Обратный запрос DNS - особая доменная зона, предназначенная для определения имени узла по его IPv4-адресу c помощью PTR-записи. Адрес узла AAA.BBB.CCC.DDD переводится в обратной нотации и превращается в DDD.CCC.BBB.AAA.in-addr.arpa. Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP-адресов . Для этого в записях авторитетного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC.000/24) отвечает отдельный сервер.

PTR-запись (от англ. pointer – указатель) связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в обратной форме вернёт имя данного хоста. Например, (на момент написания), для IP адреса 192.0.34.164: запрос записи PTR 164.34.0.192.in-addr.arpa вернет его каноническое имя referrals.icann.org.in-addr.arpa

in-addr.arpa - специальная доменная зона, предназначенная для определения имени хоста по его IPv4-адресу, используя PTR-запись. Адрес хоста AAA.BBB.CCC.DDD транслируется в обратной нотации и превращается в DDD.CCC.BBB.AAA.in-addr.arpa. Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP адресов. Для этого в записях авторитативного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC/24) отвечает отдельный сервер.

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

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

Зоной (zone) в DNS называется часть пространства имен DNS, за управление которой от­вечает определенный сервер или группа серверов DNS. Она является в DNS основным ме­ханизмом для делегирования полномочий и применяется для установки границ, в пределах которых определенному серверу разрешено выполнять запросы. Любой сервер, который обслуживает какую-то определенную зону, считается полномочным или ответственным за эту зону; исключением являются разве что зоны-заглушки.

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

Сервер, на котором устанавливается DNS, но не конфигурируется ни одна зона, называ­ется только кэширующим (caching-only) сервером. Установка такого сервера может быть выгодной в некоторых сценариях с дочерними офисами, поскольку помогает сократить объем трафика клиентских запросов по сети и устранить необходимость в репликации целых зон DNS в удаленные места.

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

Зоны прямого просмотра (forward lookup zone), как не трудно догадаться по их названию, создаются для выполнения прямого просмотра в базе данных DNS. Другими словами, зоны этого типа предусматривают реализацию преобразования имен в IP-адреса и предоставле­ние информации о ресурсах. Например, если пользователь пожелает обратиться к серверу del.company.com и запросит его IP-адрес в зоне прямого просмотра, DNS возвратит ему значение 172.16.1.11, т.е. IP-адрес данного ресурса.

Ничто не мешает присвоить одному ресурсу несколько записей ресурсов. На самом деле этот прием часто используется во многих ситуациях. При определенных обстоятель­ствах может быть удобнее, чтобы сервер был способен откликаться на более чем одно имя. Обычно подобная функциональность достигается путем создания записей CNAME, которые позволяют создавать для ресурса псевдонимы.

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

Зоны обратного просмотра (reverse lookup zone) выполняют прямо противоположную операцию той, что выполняют зоны прямого просмотра. Они предусматривают сопостав­ление IP-адресов с обычным именем. Эта похоже на поиск телефонного номера, когда сам номер известен, а имя того, кому он принадлежит, нет. Зоны обратного просмотра обычно создаются вручную и вовсе необязательно присутствуют в каждой реализации. За счет при­менения мастера настройки сервера DNS (Configure a DNS Server), как описывалось ранее в главе, процесс создания такой зоны может быть автоматизирован. Как правило, зоны обратного просмотра заполняются записями PTR, которые служат для указания запросу обратного просмотра на соответствующее имя.

Основы

Что такое запись обратной зоны DNS?

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

Forum.hetzner.de --> 213.133.106.33

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

213.133.106.33 --> dedi33.your-server.de

Как вы видите, именам хоста при прямом и обратном запросах необязательно совпадать!

Каково предназначение записи обратной зоны DNS?

• traceroute показывает не только IP-адреса, но и человекочитаемые имена узлов. Это значительно облегчает диагностику ошибок.
• Большое количество почтовых серверов принимает письма только если у IP-адреса отправителя есть обратная DNS-запись.
• Обратные DNS-записи могут использоваться в SPF-записях (Sender Policy Framework ; технология, предотвращающая рассылку спама и вирусов с поддельных email-адресов).

Как технически работает обратное преобразование на DNS-серверах?

Практика

Как я могу назначить несколько имён на мой IP-адрес, если различные домены размещены на моём сервере?

Это невозможно. Только одно имя назначается на каждый IP-адрес.

Более того, неважно какие обратные зоны прописаны для сервера. Для обращения к сайту браузеру достаточно провести лишь прямое преобразование (Имя --> IP). Здесь, конечно, может быть несколько имён, например несколько записей типа A или несколько записей типа CNAME, которые указывают на A-запись.

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

Если несколько доменов управляются через IP-адрес (достаточно частый случай), можно использовать нейтральное имя, не связанное с доменами пользователей. Спам-фильтры всего-лишь проверяют соответствует ли обратная DNS-запись имени в ответе на команду HELO. Это никак не влияет на доменные имена и почтовые адреса в передаваемых письмах.

• Обратная DNS-запись должна соответствовать имени почтового сервера или строиться на основании IP-адреса.
• Обратная DNS-запись должна также резолвиться "вперёд" - на тот-же IP-адрес.
• Обратная DNS-запись не должна быть похожа на автоматические-сгенерированную, например "162-105-133-213-static.hetzner.de", так так часто такие имена отрицательно оцениваются спам-фильтрами.
• Даваемое имя должно существовать. Пожалуйста, не используйте несуществующие доменные имена.

Пример хорошей записи:

Srv01.grossefirma.de --> 213.133.105.162 213.133.105.162 --> srv01.grossefirma.de > telnet 213.133.105.162 25 220 srv01.grossefirma.de ESMTP ready

Я задаю PTR на моём DNS-сервере. Почему это не работает?

Ваш DNS-сервер отвечает лишь за прямое преобразование.

Владелец блока IP-адресов (например, Hetzner Online GmbH) является ответственным за поддержание авторитативных DNS-серверов для обратных записей.

Обратные DNS-записи можно создавать только при помощи соответствующей функции панели Robot (левое меню -> "Servers" -> щелчок по серверу -> "IPs" -> щелчок по текстовому полю рядом с IP-адресом).

Обратная запись для моего сервера отличается от HELO моего почтового сервер. Является ли это проблемой?

Пример: обратная DNS-запись для IP-адреса сервера "www.grossefirma.de". В ответ на команду HELO почтовый сервер отвечает "mail.grossefirma.de".

Некоторые спам-фильтры расценивают письма от таких отправителей как "спам". Подобные несоответствия должны быть исправлены. Обратная DNS-запись и имя почтового сервера должны быть одинаковыми. В примере выше они могут быть, например, "srv01.grossefirma.de". Имя "www.grossefirma.de" может быть безо всяких последствий перенаправлено на srv01.grossefirma.de" при помощи CNAME-записи.

Подробное тестирование DNS-записей можно провести воспользовавшись

В доменах Windows информация о необходимых для работы систем службах хранит DNS. И основное количество проблем функционирования домена (службы каталогов) связано именно с неверной настройкой администраторами службы DNS. Поэтому стоит рассмотреть сервер DNS более подробно.

Термины DNS

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

Зоны DNS

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

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

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

Фактически прямые зоны соответствуют доменам некоторого уровня. Например, зона ask.ru позволяет разрешить все запросы имен, относящихся к домену ask.ru.
Для разрешения обратных имен в домене самого верхнего уровня создана зона in-addr.arpa. Названия зон обратного просмотра формируются добавлением к этому имени слева имени трех октетов адреса сети в обратном порядке. Например, для сети 195.161.192.0/24 имя обратной зоны будет 192.161.195.in-addr.arpa.

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

Первичная и вторичная зоны

У создаваемых записей DNS должен быть один "хозяин". Чтобы все записи были корректны, их необходимо вносить на одном DNS-сервере. В этом случае говорят, что на таком DNS-сервере расположена первичная зона. Для отказоустойчивости на других серверах можно создать копии этой зоны: такие зоны будут называться вторичными зонами. Вторичная зона содержит те же записи, что и первичная, но в нее нельзя вносить изменения или добавлять новые записи. Эти операции можно делать только для первичной зоны.

Серверы имен зоны

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

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

Верные значения

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

Для обновления записей DNS на клиентских компьютерах следует очистить кэш DNS-записей (ipconfig /flushdns).

Передача зон

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

Делегирование зон

Если на DSN-сервере создана, например, прямая зона для домена test.local , то запись о домене третьего уровня level3.test.local должна содержаться на этом же сервере. Если географически домен level3.test.local удален от основного домена, то поддержание записей в его зоне на DNS-сервере становится не очень удобным. Проще поручить администратору этого домена вносить изменения в DNS-записи самостоятельно, для чего используется процесс делегирования зоны. При делегировании зоны DNS-сервер создает у себя запись, указывающую, что запросы разрешения имени для этой зоны должны перенаправляться на другой DNS-сервер, на который произведено делегирование зоны.

Stub-зона (зона-заглушка)

При делегировании зоны на исходном сервере сохраняется информация о MS-сервере делегированной зоны. Поскольку администратор делегированной зоны может изменять ее DNS-записи, то он может сменить и записи NS-сервера. Если соответствующее изменение не будет внесено на сервер,который осуществляет делегирование, то процесс разрешения имен будет нарушен (основной сервер попрежнему будет отправлять запросы на уже не существующий адрес, и в результате будет формироваться неверный ответ). Для исправления подобной ситуации в DNS-сервере Windows Server 2003 введены stub-зоны. При создании stub-зоны в ней определяются NS-записи делегированной зоны. Причем если администратор делегированной зоны меняет эти записи, то соответствующие изменения вносятся и в записи stub-зоны. В результате гарантируется целостность процесса разрешения имен.

Зона "точка"

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

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

Типы запросов

Для разрешения имен в DNS предусмотрено два типа запросов: итеративный и рекурсивный. Итеративный запрос служит для получения от DNS-сервера, которому он направлен, наилучшего ответа, который может быть получен без обращения к другим DNS-серверам. Рекурсивный запрос предполагает, что сервер DNS должен выполнить все операции для разрешения имени. Обычно для Зона с таким именем создается при установке службы каталогов с одновременной установкой к настройкой сервера DNS.

Порядок разрешения имен в DNS

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