Ознакомление с DNS

Введение в DNS (Domain Name System)

Систему доменных имен DNS (Domain Name System) разработал Пол Мокапетрис (Paul Mokapetris), который на заре интернета (в начале 1980-х) задался вопросом, как работать в системе (она стала со временем называться DNS), которая преобразует Web-адрес в состоящий из четырех октетов IP-адрес, который используется сетевыми машинами для связи через TCP/IP (см. "Работа в сети с использованием TCP/IP" ). Мокапетрис разработал иерархическое пространство имен, которое позволяло присваивать машинам понятные (дружественные) пользователям имена и связывать эти имена с IP-адресами. Эти группы машин разбивались на домены, и в каждом домене предусматривалось свое собственное управление

DNS можно также использовать для поиска элементов, хранящихся в базе данных LDAP. DNS – это клиент/серверный процесс, который читает текстовый ("плоский") файл, аналогичный файлам HOSTS, которые вы можете иногда видеть и в настоящее время. В Windows DNS начали применять еще в версии NT4, и служба DNS стала составной частью операционной системы в Windows 2000. Это в основном произошло потому, что Microsoft перешла в используемом по умолчанию методе разрешения имен от имен NetBIOS и службы WINS (Windows Internet Naming Service) к полностью уточненным доменным именам FQDN (Fully Qualified Domain Names) и службе DNS. С появлением Active Directory (AD) и DNS, согласующейся с документом RFC 2136 (динамическое обновление записей) все изменилось еще больше. Еще больше вещей изменилось (и еще больше изменится) с появлением предложений по таблице для расширений DNSSEC (RFC 2541). DNS по-прежнему является службой с серверной и клиентской (resolver) частями. Взаимодействие между DNS и Active Directory является взаимозависимым, то есть предлагается одна система вместо двух.

Создается впечатление, что эта интеграция с AD является обязательной, но это не так, если вы не планируете создавать домены и леса (более подробно об этом см. в "Описание Active Directory" ). И даже в этом случае она не является обязательной, но вам следует объединить эти два компонента, если вы хотите свести к минимуму администрирование. Возможно, у вас есть UNIX-станции; можно использовать DNS на Microsoft-станциях в стандартной (классической) конфигурации с первичным (primary) и вторичным (secondary) серверами DNS, если вам не нужен или вы не хотите использовать домен в своем окружении. Однако предпочтительно использовать конструкции леса/домены с контроллерами доменов через Active Directory.

Цель этой лекции – способствовать пониманию разрешения имен в целом, и, в частности, DNS, с выделением отличий между Windows 2000 и 2003. Вы также узнаете о прежней форме разрешения имен, которая применялась фирмой Microsoft: разрешение имен NetBIOS, которое происходило с помощью службы WINS (Windows Internet Naming Service).

Как это начиналось

Все началось с файлов HOSTS. Это "плоские" текстовые файлы ASCII, содержащие построчный набор записей. Эти записи только представляли связь IP-адреса с именем машины, например, 192.168.1.1 Trucker.Truckstp.com. Идея состояла в том, что Trucker – это легко запоминаемое имя машины, а resolver (клиентский компонент, состоящий из программной части и библиотек на клиентском компьютере) читает этот файл, находит имя машины, извлекает ее IP-адрес и выполняет поиск по этому адресу.

Вы можете все еще использовать файлы HOSTS; обычно они находятся в подпапке %SYSTEMROOT\system32\drivers\... Вы можете редактировать такой файл с помощью Блокнота (Notepad) и добавлять в него любую машину, если у вас есть имя и IP-адрес этой машины, и вы знаете об изменениях в сети, которые могут повлиять на эти записи. Использование файла HOSTS сопряжено с ошибками, например, возможно дублирование имен или адресов. Этот подход не позволяет поддерживать масштабирование; достаточно представить себе, сколько затруднений может вызвать поддержка этих файлов для крупного предприятия. На каждой машине! Без каких-либо средств безопасности!

Разрешение имен в целом

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

Компьютеры делают это также в небольших немаршрутизируемых локальных сетях. Но локальные сети разрастаются: широковещательные сообщения являются одной из причин, по которым они становятся маршрутизируемыми. Разрешение имен почти всегда предусматривает связь между IP-адресом и именем машины с намерением поиска и подсоединения к некоторой службе, которая предоставляется этой машиной. В среде TCP/IP соединение создается с машиной и, тем самым, с портом в стеке протоколов, которому направлено сообщение (например, с портом 80 для посещения веб-сайта). Все это позволяет вам иметь легко запоминаемое имя машины, например, www.skillet.com. Рассмотрим процесс разрешения пути к машине http://www.skillet.com.

Вам нужна новая сковородка (skillet). Вы подсоединены к сети, поэтому запускаете браузер и вводите имя www.skillet.com, которое передается клиентскому компоненту (resolver), задачей которого является поиск сервера Skillet. Resolver – это набор библиотек, которому передается имя http://www.skillet.com, после чего происходит обращение к серверу DNS. Resolver выполняет операции в определенном порядке. Он всегда начинает с локального поиска (то есть с поиска на вашем компьютере), и если у вас есть что-либо в файле HOSTS, он будет обработан (независимо от последствий).

Затем resolver анализирует вашу конфигурацию TCP/IP, определяет, какая машина является предпочтительным сервером DNS, и затем запрашивает этот сервер. Ваши клиенты более ранних версий Windows действуют иным образом; продукты на основе Windows 9x (DOS) сначала выполняют поиск среди имен NetBIOS. Они обращаются к DNS, если не удается поиск NetBIOS, но в некоторых случаях ожидание, пока не истечет период тайм-аута для NetBIOS, может вызывать ощутимую задержку. Причина очевидна: эти системы были созданы для работы в первую очередь с разрешением имен NetBIOS, которое происходило с помощью службы WINS. Со временем появилась DNS, и порядок поиска этих операционных систем теперь устарел, поскольку не отражает разрешение хост-имен сетью TCP/IP.

NT4 тоже выполняет разрешение имен таким способом, если имя NetBIOS не превышает 15 символов, и в нем нет точек. В противном случае NT4 обращается сначала к DNS. Но вернемся все же к Skillet.com.

Напомним, что resolver запрашивает у первичного (primary) сервера DNS, может ли он преобразовать данное имя в IP-адрес. Этот сервер DNS проверяет свою зону и кэш, не находит соответствия и, тем самым, не может выполнить разрешение имени. Затем этот сервер DNS ищет другой сервер DNS и обращается к нему. Сервер DNS обычно устанавливается на "границе" сети компании, и все, что он делает, это пересылка запросов какому-либо серверу DNS снаружи. Этот тип сервера DNS называется сервером перенаправления запросов (forwarder). Внутренний сервер DNS запрашивает сервер перенаправления запросов, который сначала проверяет, может ли он сам выполнить разрешение имени. Если нет, то он передает данный запрос другим серверам DNS в интернете, пока не будет найдено соответствие или не произойдет отказ запроса. Успешно разрешенное имя возвращается в кэш локального сервера DNS, поэтому при повторных попытках посещения вебсайта Skillet разрешение будет происходить быстрее.

Итак, нам удалось заказать сковородку (skillet); благодаря DNS мы нашли путь к Skillet.com, а также увидели за это время, как выполняется процесс разрешения имени. DNS – превосходная система, и она использует для поиска средства, которые называются запросами. Она использует следующие типы запросов.

• Рекурсивный (Recursive). Resolver (клиентский компонент) направляет запрос серверу DNS и не предполагает никакого взаимодействия для попытки найти ответ. Все проведение поиска возлагается на сервер DNS, который начнет использовать другие серверы, будет направлять запросы и действовать как представитель для resolver. Эти дальнейшие запросы называются итеративными.
• Итеративный (Iterative). Итеративный запрос является противоположностью рекурсивного запроса (его также называют нерекурсивным); с его помощью у сервера DNS запрашивается наилучший ответ, и он должен отвечать без каких-либо запросов любым другим серверам DNS.
• Обратный (Inverse). Этот тип запроса направляется машиной, которая ищет хост имя и отправляет IP-адрес, чтобы получить это хост-имя. Этот запрос необычен в том смысле, что сервер DNS выполняет просмотр только своей собственной зоны. Поиск ограничивается этой зоной при любом исходе – успешном или неудачном. Такой запрос используется редко, и он поддерживается только в Windows DNS для обеспечения обратной совместимости с прежними версиями DNS.
• Только кэширующий сервер (Caching-only server). Эта функция DNS не является формально запросом, но она должна использоваться с запросами. Такой сервер не авторизуется и не содержит никакой зоны. Он получает запрос от клиента и передает этот запрос сети DNS для разрешения. Получив результат разрешения, он кэширует его на некоторый период времени на тот случай, если какой-либо другой клиент повторит тот же запрос. Это ускоряет разрешение имен.

Используя эти методы, сервер DNS последовательно ищет IP-адрес, начиная с URL (Uniform Resource Locator) вашего браузера, передаваемого в resolver. В результате вы получаете один из двух ответов: то, что вы ищете, или сообщение об ошибке.

Домены

Чтобы понять, как действует DNS, полезно ознакомиться с окружением, в котором выполняет свою работу эта служба. Начнем с иерархии DNS. Корневой домен известен просто как ".". Верхний домен находится на один уровень ниже, и на этом уровне находится целый ряд доменов DNS. Вы знаете все эти суффиксы: .COM (коммерческие), .GOV (правительственные), .EDU (образование), .INT (международные), .ORG (организация), .NET (Net-провайдеры, ISP [Провайдеры услуг Интернет] и т.д.) и .MIL (военные). Достаточно интересно, что ICANN (новая некоммерческая организация по назначению адресов и имен в интернете) ссылается на эти "обобщенные" домены верхнего уровня, и в период между 2000 и 2002 гг. она ввела еще семь: .BIZ, .INFO, .NAME, .PRO, .AERO, .COOP и .MUSEUM. Но пока еще используются не все эти новые имена.

На следующем уровне обычно находится домен, поддерживаемый частной фирмой; я буду использовать для своих примеров корпоративный домен .COM, но для этого можно было бы использовать любой из только что перечисленных доменов. Вы можете рассматривать домены DNS аналогично структуре папок на жестком диске в смысле разбиения пространства имен DNS. Домен "." аналогичен корневой папке; далее идет верхний уровень (.COM), и на следующем уровне находится "папка", представляющая корпоративный объект некоторого рода (частный или общественный). Имя верхнего уровня (.COM) и корпоративная "папка", например, Microsoft, совместно образуют доменное имя. Пространство имен Microsoft может разбиваться на меньшие домены ("подпапки") Active Directory/DNS, представляющие в компании Microsoft различные подразделения или службы, например, accounting.microsoft.com (бухгалтерский учет). Такой домен обычно недоступен из Internet в отличие от microsoft.com; однако имеются исключения, например, http://support.microsoft.com/default.aspx?scid=fh;[ln];kbhowto представляет службы поддержки Microsoft. Здесь находится Knowledge Base вместе с различными рекомендациями от MS Support. Каждая субзона отвечает за правильность собственной работы.

Это обычное пространство DNS, известное как зона прямого поиска (forward lookup zone). Существует также зона обратного поиска (reverse lookup zone), известная также как in-addr.arpa, что является ее техническим названием. При запросе обратного поиска вместо дружественного для пользователя имени (как это происходит при поиске в зоне прямого поиска) выполняется поиск определенного IP-адреса машины. Записи в зоне обратного поиска содержат IP-адрес и затем имя машины. Resolver может определить, соответствует ли в действительности определенный IP-адрес дружественному имени, которое он указывает. Поскольку IP-адреса регистрируются вместе с доменными имена DNS, поиск по IP-адресу позволяет определить, из какого домена происходит этот IP-адрес. Если он не соответствует тому, что он должен представлять, то это может быть "самозванец".

IP-адреса организованы таким образом, что их "старшинство" повышается слева направо, а в доменных именах "старшинство" снижается слева направо. Но IP-адреса в домене in-addr.arpa (зона обратного поиска) записываются в обратном порядке. В записях-указателях (ptr-записях), которые добавляются в зону обратного поиска, сначала указывается IP-адрес и затем – хост-имя, – в отличие от зоны прямого поиска, где сначала идет хост-имя и затем – IP-адрес. Для выполнения успешного обратного поиска по заданному IP-адресу, например, 121.41.113.10, выполняющий поиск сервер DNS ищет PTR-запись для 10.113.41.121.in-addr.arpa, которая содержит определенное хост-имя и IP-адрес 121.41.113.10.

FQDN (Полностью уточненное доменное имя)

А теперь предположим, что нам известен хост внутри домена. Вернемся к примеру субдомена accounting в Microsoft. Домен внутри другого домена называется дочерним доменом, а microsoft.com в данном случае является родительским доменом. Если имя хоста – Syscrusher, то полностью это выглядит как syscrusher.accounting.microsoft.com. Любое хост-имя, выраженное таким способом, называется полностью уточненным доменным именем (FQDN – fully qualified domain name).

Зоны

Теперь пришло время поговорить о зонах. Каждый домен является объектом со своей собственной политикой. Если посмотреть, как устроен один из серверов DNS внутри Microsoft, мы увидим в оснастке DNS определенные зоны. Зона может содержать домен, часть домена или ряд доменов; каждый из них может иметь сервер или серверы DNS, отвечающие за эти зоны. Должен существовать хотя бы один сервер DNS, поддерживающий каждую зону. Каждая зона имеет набор записей. Они называются ресурсными записями. Сервер DNS, который работает с определенной зоной, называют "руководящим" ("authority") для этой зоны. Он отвечает на любые запросы по этой зоне. Чтобы понять это, мы рассмотрим существующие виды зоны. Сюда относится их хранение, доступ и репликация, но не их содержимое (то есть записи – мы скоро увидим, как они устроены). Классические зоны DNS в Windows хранились и продолжают храниться в текстовых файлах с расширением .dns.

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

Первая зона называется первичной (primary) зоной. Эта зона создается на первичном (основном) сервере и является только доступным для записи экземпляром базы данных. Эта зона должна содержать хотя бы две записи – запись SOA (Start of Authority) и NS (name server). В классической DNS файл этой зоны должен был редактироваться вручную, но последующие версии DNS (в Windows 2000 и 2003) позволяют выполнять защищенное и незащищенное динамическое обновление. Большинство записей – это "A"-записи, представляющие хосты, добавленные вручную или зарегистрированные ими самостоятельно; но существует также много других типов записей. Вскоре мы рассмотрим наиболее употребительные типы записей. Классическая DNS в Windows Server 2003 позволяет выбрать один из двух вариантов: запрет динамических обновлений или разрешение защищенных и незащищенных обновлений.

Вторичная зона

Вторичная (secondary) зона извлекается из первичной и доступна только по чтению. Соответствующий сервер должен находиться в другой подсети и создается в небольших окружениях для избыточности; в более крупных окружениях это позволяет распространять вторичные серверы DNS в удаленные сайты для повышения производительности.

Зона, интегрированная с Active Directory

Эта версия зоны находится в Active Directory на каждом контроллере домена. Главная копия базы данных DNS реплицируется на каждый контроллер домена, и в нее может вносить изменения каждый контроллер домена (конечно, при соответствующих полномочиях). Нужно следить, сколько записей/зон используется в Active Directory (AD); слишком большое количество может вызывать снижение производительности.

Фиктивная (Stub) зона

Это новый тип зоны, появившийся в Windows 2003. Это копия дочерней зоны с записями, идентифицирующими дочерний сервер имен, который является "руководящим" для этой дочерней зоны. Она содержит SOA-запись, NS-запись и связывающую A-запись. Это известно как делегирование. Сервер родительской зоны может получать обновления от дочерней зоны, которые будут сохраняться в кэше сервера родительской зоны. Записи в такой зоне не изменяются. Ее назначение – это "склеивание" двух пространств имен, чтобы обеспечивать правильность ссылок из родительской зоны в дочернюю зону.

Конечно, делегирование не является чем-то новым. Stub-зоны позволяют исправить ситуацию, которая возникала в связи с делегированием, я объясню это сейчас. У нас имеется родительский домен – microsoft.com. У нас имеется также дочерний домен – accounting.microsoft.com. При первом делегировании этой дочерней зоны в зоне accounting был только один "руководящий" сервер DNS. Но поскольку со временем пространство имен accounting разрослось, администраторы решили установить два новых сервера для этого дочернего домена.

Однако сервер DNS, содержащий родительскую зону (microsoft.com), остается "в неведении" об их существовании и продолжает "упорно" обращаться к исходному (руководящему) серверу DNS по поводу accounting.microsoft.com. Чтобы справиться с этой ситуацией балансирования нагрузки, родительский сервер конфигурируется, чтобы хранить stub-зону для дочернего домена, и при обновлении этой зоны он обращается к руководящему серверу этой зоны, что позволяет ему узнать о двух новых серверах DNS и выполнять рекурсивный опрос всех этих серверов.

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

Продолжим наш пример. Родительская зона (microsoft.com) имеет дочернюю зону (accounting.microsoft.com), и управление этой дочерней зоной называют делегированием от родительской зоны. Делегирование, которое позволяет передавать управление в разделенном пространстве имен, можно осуществлять по целому ряду причин, например, необходимость для другого отдела управлять отдельной зоной или балансирование нагрузки и отказоустойчивость. Дочерняя будет руководящей для самой себя. Важно помнить, что можно создавать дочерние зоны без делегирования для них. В этом случае управление остается за родительской зоной.

Записи

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

• A-запись. Указывает адрес хоста. Она отображает хост-имя на адрес и может выглядеть следующим образом:

  Myhost.mycompany.com IN A 192.168.0.1
• AAAA-запись. Эта запись пока используется не слишком много, но ожидается, что она будет активно использоваться с появлением IPv6. Считалось, что все доменные имена и IP-адреса будут скоро исчерпаны из-за потребительского роста. Это не происходит, и пока повсеместно используется IPv4. Вот пример хостзаписи из зоны, которая хранится в среде IPv6.

  IN AAAA 1234:1:2:3:4:567:89cd
• CNAME-запись. Это каноническая запись, обычно используемая для алиасов (псевдонимов). Она позволяет отображать несколько хост-имен на заданный IP-адрес. Многие компании используют этот метод, чтобы убедиться, что их посетил предполагаемый заказчик, даже если этот посетитель немного ошибся в URL или имеется несколько вариантов написания URL компании. В этом случае заказчик будет уверен, что попал на нужный сайт.
• SRV-запись (локатор служб). Эта запись особенно важна для Windows 2000 и 2003 в конфигурации лес/домены. Она используется для регистрации контроллеров домена (DC) в DNS и для объявления несколькими серверами информации о том, что они предоставляют определенную службу TCP/IP. Если вы пытаетесь создать новую запись, то имеете возможность задания для нее определенной службы TCP/IP. После размещения такой записи клиент, направляющий SRV-запрос, может использовать определенную службу TCP/IP, которая предоставляется в данном домене несколькими серверами. Если вы не можете найти контроллер домена для присоединения к домену, то SRV-записи – это одно из средств, которое вам следует использовать. Эта запись позволяет находить контроллеры домена, которые используют службу LDAP (AD) через порт TCP 389.
• NS-запись. Эта запись идентифицирует сервер(ы) имен для заданного домена DNS. В NS-записях указываются первичные и вторичные серверы для пространства имен плюс дочерние зоны, происходящие из него.
• SOA-запись (Start of Authority). эта запись определяет зону, для которой данный сервер является руководящим. Она имеет такие параметры конфигурирования для сервера, как срок действия (time to live), кто несет ответственность за указанный сервер, имена сервера имен (NS server), частоту обновления, последовательный (или "магический") номер, используемый для маркировки изменений зон, и запускаемая репликация (trigger replication).
• PTR-запись. Эта запись позволяет быстро выполнять обратный поиск с помощью зоны обратного поиска (inaddr.arpa). Она считается обратной A-записью, но не похожа на нее ввиду использования inaddr.arpa в реальной записи. Такая запись для хоста syscrusher.skillet.com с IP-адресом 100.200.252.1 имеет следующий вид: 1.252.200.100.in-addr.arpa IN PTR syscrusher.skillet.com.
• MX-запись. Эта запись для почтового обмена. Вы можете иметь несколько записей, которые указывают несколько ближайших почтовых серверов, и можете располагать их в нужном вам порядке.

Microsoft имеет несколько особых записей для собственных целей; эти записи используются для связи с различными окружениями WINS. Это следующие записи:

• WINS. Позволяет MS DNS использовать сервер WINS для разрешения хост-имени. Это полезно, если у вас имеются клиенты более ранних версий Windows, которые не получают регистрации в какой-либо зоне DNS. Нужно найти такую запись, после чего будет запрошен сервер WINS.
• WINS-R. Эта запись позволяет осуществлять обратный поиск. Это только записи Microsoft, и они могут быть ограничены при пересылке зон.

Пересылка/Репликация зон

Серверы DNS реплицируют свои зоны. Они делают это по целому ряду причин в зависимости от структуры сети, но две наиболее важные причины – это отказоустойчивость и производительность. В начале использования DNS существовали первичный и вторичный серверы DNS. Оба содержали идентичные копии своих зон, и вторичный сервер обычно помещали в другую сеть, чтобы выход из строя первичной сети или отказ соответствующего сервера не приводили к потере функции разрешения имен. Они реплицировались по какому-либо событию, например, загрузка серверов или обновление зон первичного сервера, поэтому в случае появления "магического номера" в записи Start of Authority (SOA-записи) вторичный сервер обнаруживал это и извлекал базу данных, если были отличия.

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

Изменения могли вноситься только на первичном сервере; все вторичные системы были копиями первичной, что снижало риск повреждения базы данных. Это характерный тип конфигурации для среды UNIX, но ее можно создавать и с помощью Windows 2003. Как я уже говорил выше, предпочтительный метод – это использование лесов и доменов. Репликация происходит здесь в другом смысле; в домене, работа которого основывается на Active Directory (AD) и DNS, нет понятия первичных и вторичных серверов. В AD имеются только зоны AD.

В этой конфигурации, которая называется репликацией с несколькими основными контроллерами ( multimaster-репликацией ), зоны DNS хранятся на контроллерах доменов, и зоны реплицируются через Active Directory. Здесь действует определенный "симбиоз": AD требуется служба DNS для поиска объектов, других контроллеров доменов и сайтов в дереве; службе DNS требуется AD для репликации на остальные контроллеры каждого домена. Это происходит следующим образом: после создания зоны она сохраняется в интегрированном с AD хранилище зон. Они хранятся в дереве Active Directory под доменом или разделом каталога приложений.

Раздел приложений (application partition) – это новое понятие, введенное в Windows 2003; в нем хранятся данные приложений, которые могут выборочно реплицироваться на определенные контроллеры домена (более подробно об этом см. в гл. 19, и мы рассмотрим соответствующее средство, DNSCMD, ниже в разделе "Средства DNS"). В классической DNS зоны всегда реплицировались полностью. Начиная с Windows 2000, репликацию зон можно конфигурировать для полной репликации (вся зона копируется с помощью запроса AXFR) или добавочной формы пересылки зон (с помощью запроса IXFR). Если вам нужно подробное описание, см. документ RFC 1995.

Это дает вам селективную форму multimaster-репликации: все или некоторые контроллеры домена содержат копии зоны и могут выполнять разрешение имен, обеспечивая при этом безопасность зоны. Какой вид безопасности? Вы можете вносить изменения в список контроля доступа (ACL) для защиты контейнера объектов dnsZone в дереве каталога. Это дает вам полный контроль над зоной или указанной ресурсной записью (RR – resource record) в этой зоне. С помощью списка ACL вы можете запрещать группам и/или хостам динамическое обновление любой RR данной зоны.

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

Файлы

DNS состоит из набора файлов. Ниже приводится список этих файлов и описывается их назначение.

• Cache.dns. Этот файл называют также файлом "корневых подсказок" (root hints). Он содержит корневые серверы для Интернет. Если вы подсоединены к Интернет, то все в порядке, но если нет, то требуются небольшие поправки. Просто замените серверы Интернет на SOA- и NS-записи для сервера DNS, который является руководящим для вашей зоны. Назначение этого файла – помогать в поиске корневых серверов для использования в инициализации кэша сервера. Если вы находитесь в Интернет, то, используя серверы, которые включаются в этот файл, вам еще проще изменять его из вкладки Root Hints (Корневые подсказки), находящейся в окне свойств вашего сервера.
• Root.dns. Этот файл используется в том случае, если ваш сервер DNS является корневым сервером для вашей сети.
• Your_Zone.dns. Вы увидите этот файл, только если используете стандартную первичную или вторичную зону. Этот файл отсутствует, если вы используете интегрированную с Active Directory DNS.
• Boot. Возможно, вы знаете такой файл под именем named.boot, если использовали BIND DNS. Он не присутствует по умолчанию, но если у вас есть BIND-система, из которой требуется его импортировать, используйте вариант From File (Из файла) в окне свойств сервера оснастки DNS.

Имеется также исполняемый файл DNS.EXE и клиентский компонент (resolver), который запускается на клиентской машине.