Краткий обзор DNS

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

Примечание.
Поскольку доменная система имен важна для работы Active Directory, вы должны ознакомиться с концепциями службы DNS и знать, как она реализована. Если вы не знакомы с DNS, вам следует просмотреть некоторые ресурсы, имеющиеся на веб-сайте Microsoft по адресу msdn.microsoft.com/library/en-us/dns/dns_concepts.asp.

Иерархическое пространство имен

DNS использует иерархическое пространство имен для поиска компьютеров. На рисунке 3-1 показан пример организации пространства имен. Корневой домен обозначается точкой «.». Он представляет собой верхний уровень DNS, остальное пространство имен располагается ниже. На следующем уровне под корневым доменом располагаются домены первого уровня, включая семь основных (generic) доменных имен (com, edu, mil, net, org), около двухсот сокращений названий стран (са, uk, fr, br), семь новых доменов (biz, info, pro и т.д.), которые были введены в 2001 году.

Рис. 3-1. Иерархическое пространство имен DNS

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

Другим способом представления иерархического пространства имен является полностью определенное имя домена (FQDN — Полностью Определенное Имя Домена), например, www.NAmerica.Contoso.com. FQDN представляет собой полное имя, которое можно использовать для идентификации определенного компьютера в пределах всего пространства имен DNS. Чтобы понять, как FQDN идентифицирует компьютер в пространстве имен DNS, читайте его справа налево. Справа находится точка («.»), которая идентифицирует корневой домен, она предшествует имени домена первого уровня. За ней следуют домен com первого уровня, домен Contoso второго уровня и поддомен NAmerica. Слева в имени FQDN находится www - имя определенного компьютера.

Распределенная база данных

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

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

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

Процесс разрешения имен

Иерархическое пространство имен DNS и распределенная база данных используются тогда, когда клиент пробует найти IP-адрес ресурса в интернете. Используя пример из предыдущего раздела (см. рис. 3-1), предположим, что клиент DNS (назовем его преобразователем), расположенный в какой-то точке земного шара, хочет соединиться с веб-сервером, имеющим адрес www.NAmerica.Contoso.com. Для получения IP-адреса выполняются следующие действия.

1. Клиент-преобразователь посылает рекурсивный запрос об IP-адресе на свой сконфигурированный DNS-сервер (обычно это DNS-сервер провайдера службы интернета). Рекурсивный запрос может иметь только два возможных ответа: IP-адрес, запрашиваемый клиентом, или сообщение об ошибках, указывающее, что информация не может быть найдена.
2. Если DNS-сервер провайдера имеет необходимую информацию в своем кэше, то он возвращает IP-адрес пользователю. Если нужной информации нет, то он пробует найти информацию, посылая итерационный запрос на другой сервер. Ответом на итерационный запрос может быть или разрешенное имя, запрашиваемое клиентом, или переадресация на другой DNS-сервер, который сможет выполнить запрос. В нашем примере DNS-сервер провайдера посылает итерационный запрос корневому серверу об IP-адресе, который соответствует www.NAmerica.Contoso.com.
3. Корневой сервер не может ответить на запрос, но в ответ он присылает список серверов, ответственных за домен высшего уровня com. Этот процесс предоставления списка альтернативных DNS-серверов для дальнейшего контакта называется направлением (referral). DNS-сервер интернет-провайдера посылает итерационный запрос одному из этих серверов с просьбой об IP-адресе.
4. Сервер com дает в ответ список серверов, которые являются ответственными за домен Contoso.com. Далее DNS-сервер провайдера посылает запрос DNS-серверу Contoso.com, который дает в ответ имена DNS-серверов, управляющих доменом NAmerica.Contoso.com.
5. DNS-сервер NAmerica.Contoso.com содержит всю информацию об этом домене, и он посылает DNS-серверу провайдера IP-адрес нужного хоста.
6. DNS-сервер провайдера отвечает на рекурсивный запрос, который он получил от клиента-преобразователя, и посылает IP-адрес запрошенного Web-сервера.
7. Компьютер клиента соединяется с www.NAmerica.Contoso.com.
8. Этот процесс происходит очень быстро и может не включать некоторые шаги. Когда DNS-сервер разрешает любой тип имени, он сохраняет эту информацию в кэше в течение определенного периода. Если кто-то искал этот же сайт раньше в этот день и DNS-сервер провайдера разрешил это имя, то он просмотрит свой кэш и даст ответ немедленно.

Записи ресурсов

Текущие записи, хранящиеся в зонных файлах DNS, называются записями ресурсов (RR — Resource Records). Записи ресурсов содержат текущую информацию о домене. Вы можете создать двадцать два различных типа записей ресурсов на DNS-сервере системы Windows Server 2003. Наиболее распространенные записи ресурсов перечислены в таблице 3-1.

Табл. 3-1. Наиболее распространенные записи ресурсов в доменной системе имен Windows Server 2003

Рис. 3-2. Запись SOA для домена Contoso.com

Совет.
На рисунке 3-2 показана запись SOA в инструменте администрирования DNS. Записи DNS могут быть сохранены в стандартном текстовом формате. Например, стандартная запись хоста для сервера по имени web1.Contoso.com может быть записана как web1.Contoso.com IN A 192.168.1.100.

DNS-домены, зоны и серверы

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

Сравнение доменов и зон

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

Существует два различных типа зонных файлов в DNS: зоны прямого просмотра и зоны обратного просмотра. Зона прямого просмотра используется для разрешения имен хоста к IP-адресам. Эти функциональные возможности обеспечивают записи хоста (А). Зона прямого просмотра может включать записи SOA и NS, а также записи MX, CNAME и SRV. Зона прямого просмотра используется всякий раз, когда клиент-преобразователь делает запрос DNS-серверу, чтобы найти IP-адрес сервера в сети.

Зоны обратного просмотра выполняют противоположную функцию. Она используется тогда, когда IP-адрес хоста известен, а имя хоста не известно. Зона обратного просмотра также имеет записи SOA и NS, остальная часть записей - это записи PTR. Формат записи PTR подобен записи хоста, но он обеспечивает ответ для обратного поиска. Для получения дополнительной информации о записях см. табл. 3-1.

Имя зоны прямого просмотра является именем домена. Имя зоны обратного просмотра определить более трудно, потому что она использует IP-адрес подсети, а не имя домена, в качестве границы зоны. Когда вы создаете зону обратного просмотра, вы должны дать ей имя, основанное на IP-адресе подсети. Например, если вы создаете зону обратного просмотра для подсети 192.168.1.0, то зонное имя будет 1.168.192.in-addr.arpa. Имя in-addr.arpa специально зарезервировано в DNS для ссылок на зоны обратного просмотра. Первая часть зонного имени является сетевым адресом, записанным в обратном порядке. Если вы создаете зону обратного просмотра для подсети класса В (150.38.0.0), имя зоны обратного просмотра будет 38.150.in-addr.arpa.

Основные серверы имен

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

Дополнительные серверы имен

Дополнительный сервер имен (Secondary Name Server) имеет копию зонных файлов, которая предназначена только для чтения. Единственный способ обновления зонной информации дополнительного сервера имен состоит в зонной передаче с основного сервера имен. В ранних версиях DNS каждая зонная передача была полной зонной передачей, т.е. все содержимое зонного файла DNS передавалось с основного сервера имен на дополнительный. Документ Request for Comment 1995 (Запрос на комментарии) представил более эффективный механизм зонной передачи, называемый добавочной зонной передачей (incremental zone transfers), в котором на дополнительный сервер копируются только изменения, сделанные в зонных файлах с момента последней передачи. Другое усовершенствование представлено в документе Request for Comment 1996. Это механизм уведомлений, который позволяет основному серверу предупреждать дополнительные серверы имен о том, что были сделаны изменения к зонным файлам. Без опции уведомления дополнительный сервер имен будет контактировать с основным сервером только через интервалы времени, определенные в записях SOA для каждой зоны.

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

Кэширующие серверы имен

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

Примечание.
Все DNS-серверы Windows Server 2003, включая основной и дополнительные серверы имен, кэшируют информацию, но они не называются кэширующими (caching-only) серверами. Различие между этими серверами и только кэширующими серверами состоит в том, что последний не имеет никакой зонной информации.

Зоны полномочий

Чтобы полностью понимать DNS, вы должны познакомиться с зонами полномочий и полномочными серверами имен. Каждый основной и дополнительный серверы имен являются полномочными для своего домена. Например, если DNS-сервер содержит зонные файлы для домена Contoso.com, то этот сервер является полномочным сервером имен для этого домена. Как полномочный сервер имен, он не будет отправлять никаких запросов о хостах этой зоны другим DNS-серверам. Многие компании устанавливают конфигурацию DNS-сервера так, как показано на рисунке 3-3. В этом сценарии имеются два основных DNS-сервера, сконфигурированные для домена Contoso.com. DNS1 содержит запись хоста для сервера по имени web1.Contoso.com, а DNS2 этой записи не имеет. Когда клиент соединяется с DNS1, он сможет разрешить IP-адрес для web1. Когда клиент соединяется с DNS2 и запрашивает IP-адрес для web1, сервер ответит, что хост не может быть найден. Поскольку DNS2 сервер является полномочным для домена Contoso.com, он не будет отправлять запросы серверу DNS1. Его поведение заложено в проекте и, как показывает обсуждение примера в разделе Практический опыт, это дает определенное преимущество в безопасности.

Рис. 3-3. Множество полномочных DNS-серверов

Практический опыт

Использование нескольких полномочных серверов для одной зоны. Иногда возникает ситуация, когда компания имеет два DNS-сервера, являющимися полномочными для одного домена, и интернет-имя DNS компании и ее внутреннее имя DNS идентичны (как показано на рис. 3-3). Сервер DNS1 находится с внутренней стороны брандмауэра, а сервер DNS2 - с его внешней стороны. Сервер DNS2 используется для разрешения DNS-запросов клиентов интернета, в то время как DNS1 используется для внутренних клиентов и для SRV-записей Active Directory. Поскольку оба сервера полномочны для одной и той же зоны (Contoso.com), они не будут отправлять запросы об этом домене друг другу.

В этом случае необходимо поддерживать уникальную зонную информацию на каждом DNS-сервере. Внешний DNS-сервер, вероятно, будет иметь относительно маленький зонный файл, состоящий из веб-серверов и МХ-записей, которые должны быть доступны из интернета. Внутренний DNS-сервер будет иметь намного больший зонный файл, содержащий все записи контроллера домена, все внутренние записи сервера и, возможно, записи хоста для всех клиентских компьютеров в сети. Единственное дублирование между двумя зонными файлами может состоять из некоторых внешних записей DNS. Например, когда внутренние клиенты соединяются с www.Contoso.com, вы можете потребовать, чтобы они соединялись с тем же внешним веб-сервером, к которому обращаются интернет-клиенты. Для этого нужно включить запись хоста для веб-сервера в зонный файл на DNS1. Если вы не сделаете этого, то внутренние клиенты не смогут соединяться с веб-сервером.

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

Поскольку система DNS использует иерархическое пространство имен, должен существовать механизм соединения разных уровней иерархии. Например, если клиент соединяется с сервером, который является полномочным для домена первого уровня com и запрашивает сервер в домене Contoso.com, corn-сервер должен уметь определять, какой сервер имен является полномочным для домена Contoso.com. Это возможно при помощи записей делегирования (delegation records).

Запись делегирования представляет собой указатель на домен низшего уровня, который идентифицирует сервер имен для домена низшего уровня. Например, на рисунке 3-4 показано, что DNS1.Contoso.com является полномочным сервером имен для домена Contoso.com. DNS2 и DNS3 являются полномочными серверами имен для домена NAmerica.Contoso.com. Сервер DNS1 считается полномочным для домена NAmerica.Contoso.com, но он не имеет всех записей ресурса дочерних доменов. Однако сервер DNS1 использует запись делегирования, указывающую на DNS2 и DNS3 как на серверы имен для дочернего домена. Когда клиент соединяется с сервером DNS1, запрашивая информацию об NAmerica.Contoso.com, сервер перешлет клиента на сервера имен дочернего домена.

Ретрансляторы и корневые ссылки

Второй способ соединения различных уровней иерархии системы DNS состоит в использовании корневых ссылок и ретрансляторов. В большинстве случаев ретрансляторы и корневые ссылки используются низкоуровневыми серверами пространства имен DNS для поиска информации, находящейся на высокоуровневых серверах DNS-иерархии. Ретрансляторы и корневые ссылки используются DNS-сервером для поиска информации, которая отсутствует в их собственных зонных файлах. Например, DNS-сервер может быть полномочным только для домена Contoso.com. Когда он получит запрос от клиента, запрашивающего разрешение имени в домене Fabrikam.com (см. рис. 3-1), DNS-серверContoso.com должен иметь какой-то способ поиска этой информации.

Рис. 3-4. Делегированные зоны

Одним из способов конфигурирования сервера для этих целей является использование ретрансляторов. Ретранслятор (forwarder) - это просто другой DNS-сервер, который используется определенным DNS-сервером, когда он не может разрешить запрос. Например, полномочный сервер имен для Contoso.com может получить рекурсивный запрос для домена Fabrikam.com. Если DNS-сервер Contoso был сконфигурирован с ретранслятором, то он отправит рекурсивный запрос ретранслятору, запрашивая эту информацию. Ретрансляторы часто используются во внутренней сети организации. Организация может иметь несколько DNS-серверов, главной задачей которых является внутреннее разрешение имен. Пользователям внутри организации может потребоваться разрешение IP-адресов интернета. Это можно выполнить, сконфигурировав все внутренние DNS-серверы так, чтобы они могли разрешать адреса интернета. Более распространенным вариантом является конфигурирование внутренних DNS-серверов с ретранслятором, указывающим на DNS-сервер, являющийся ответственным за разрешение имен интернета. Этот вариант показан на рисунке 3-5. Все внутренние DNS-серверы отправляют любой запрос для неполномочной зоны на один DNS-сервер, который разрешает интернет-адреса. Если DNS-сервер сконфигурирован с несколькими ретрансляторами, то он будет отправлять запросы всем ретрансляторам по порядку, прежде чем попытается использовать любой другой способ разрешения IP-адресов.

Рис. 3-5. Использование ретрансляторов для разрешения имен в интернете

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

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

По умолчанию DNS-серверы Windows Server 2003 используют ретрансляторы и корневые ссылки, когда они пытаются разрешать имена. Если сервер конфигурирован с ретрансляторами, он сначала отправит рекурсивные запросы всем ретрансляторам. Если ни один из ретрансляторов не может обеспечить необходимую информацию, то DNS-сервер начнет посылать повторяющиеся запросы серверам, сконфигурированным как корневые ссылки. В некоторых случаях необходим DNS-сервер, использующий только ретрансляторы и не использующий корневые ссылки. Чтобы сконфигурировать такой сервер, выберите опцию Do Not Use Recursion For This Domain (Не использовать рекурсию для этого домена) на вкладке Forwarders (Передатчики) в окне Properties (Свойства) DNS-сервера. После этого DNS-сервер сначала будет пытаться разрешить любые запросы с помощью своей местной зонной или кэшированной информации, посылая рекурсивные запросы каждому из своих ретрансляторов. Если ретрансляторы не смогут обеспечить необходимую информацию, DNS-сервер не будет использовать другие средства, чтобы найти эту информацию. Он сообщит клиенту, что хост не может быть найден.

Примечание.
В системе DNS Windows Server 2003 возможности традиционных ретрансляторов расширены за счет реализации условных ретрансляторов. Эта тема подробно рассматривается в разделе «Условная ретрансляция» далее в этой главе.

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

В прошлом сложность работы с DNS состояла в том, что вся зонная информация должна была вводиться вручную. До выхода документа RFC 2136 не существовало никакого способа автоматического обновления зонной информации DNS-сервера. В документе RFC 2136 описано, как DNS-серверы должны быть сконфигурированы, чтобы автоматически принимать обновления к записям ресурсов в зонных файлах. Эта опция называется динамической службой DNS (DDNS).

DNS-серверы Windows Server 2003 поддерживают динамическую службу DNS. По умолчанию все клиенты Windows 2000 и Windows XP Professional, а также Windows 2000 Server; Windows 2000 Advanced Server; Windows 2000 Datacenter Server; Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition автоматически обновляют свои записи ресурсов в DNS. Windows 2000 и контроллеры домена Windows Server 2003 автоматически регистрируют SRV-записи на DNS-серверах, которые используются для поиска контроллеров домена. DNS-серверы Windows Server 2003 будут также принимать динамическую регистрацию записей с серверов динамической конфигурации хостов (DHCP). DHCP-сервер Windows Server 2003 может конфигурироваться для автоматического обновления DNS-записей для любого из его клиентов, включая Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows Me или Microsoft Windows NT.

Одна из проблем динамической системы DNS связана с безопасностью. Без какого-либо контроля над тем, кому позволено обновлять записи ресурсов DNS, любой, имеющий доступ к вашей сети, потенциально может создать запись ресурса в ваших зонных файлах DNS, а затем использовать эту запись для переадресации сетевого трафика. Чтобы решить эту проблему в системе DNS Windows Server 2003 существуют безопасные обновления. Безопасные обновления имеются только в интегрированных зонах Active Directory. С помощью безопасных обновлений вы можете управлять тем, кому дается право регистрировать и обновлять DNS-записи. По умолчанию члены группы Authenticated Users (Уполномоченные пользователи) имеют право обновлять свои записи в системе DNS. Вы можете изменить это, изменяя список управления доступом ACL (ACL - Access Control List) для DNS-зоны.

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

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

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