Этот метод есть традиционный метод хранения зон DNS описанный в спецификациях DNS. При таком методе хранения зоны вся информация о зоне хранится в специальном текстовом файле. Имя файла образуется из "названия зоны" с расширением ".dns".
К примеру в случае если мы решили сохранить информацию о зоне нашего домена RK.COM то у нас это информация на сервере будет сохранена в файле "rk.com.dns". На DNS сервере мы можем располагать и несколько зон, и в данном случае каждая зона будет иметь свой отдельный файл, смотрите рисунок 1. На рисунке показан еще файл зоны xu.com. Такой метод хранения является достаточно простым методом хранения зон и более старым, по сравнению с остальными которые приведены здесь. Именно такой метод применяется для хранения зон в Windows NT 4.
При таком методе хранения зоны в случае необходимости администратор всегда может перенести зону на любой другой DNS сервер и редактировать ее в любом текстовом редакторе. Формат такого файла смотрите рисунок 2.
На рисунке в данном файле мало записей так как данный файл создан только для примера, в жизни такие файлы куда более насыщены информацией но формат записей такие же как и на рисунке 2.
Этот способ хранения нас в данном случае больше всего интересует так как мы затронули тему DNS по причине изучения Active Directory, который трудно понять без знания принципов функционирования службы DNS.
Надо заметить что подобный метод хранения зоны возможен только в случае когда служба DNS установлена на контролере домена. А что такое контролер домена Вы если читали рассылку с начала должны помнить. Но я напомню вкратце. Контролер домена считается компьютер на котором установлена служба каталога Active Directory.
Размещение зоны в Active Directory позволяет задействовать множество механизмов Active Directory и в первую очередь механизм репликации Active Directory который распространяется и на службу DNS. Это связано с тем что при интеграции зоны DNS в Active Directory зона рассматривается как объект Active Directory и любое изменение на одной из копий зон, будет приводить к распространению этой информации на все остальные копии по правилам репликации Active Directory которые мы уже рассмотрели в других статьях на сайте и в рассылке.
Данный метод работает только в Windows Server 2003 и только так как реализован впервые на данной сетевой операционной системе.
Само название говорит что зона будет хранится в разделе приложений Active Directory (application partitions). Характерной особенностью данного метода хранения зоны DNS есть то что администратор может избирательно размещать раздел приложений и размешать данный раздел приложений только на тех контроллерах домена, что являются DNS-серверами. На других контроллерах домена реплика подобных разделов не создается.
Зона заглушка (stub zone), новый тип зоны которая появилась в Windows 2003. Зона-заглушка вместо всех записей зоны хранит лишь записи Start of Authority (SOA), Name Server (NS) и связывающую A-запись (о типах ресурсных записях смотрите здесь). Благодаря зонам-заглушкам DNS-сервера Windows 2003 создают зоны, которые отличаются от зон созданных и находящиеся на стандартных первичных и вторичных DNS-серверах. В зонах на стандартных первичных и вторичных DNS-серверах содержится полный экземпляр файла зоны, а в зоне-заглушке хранится лишь минимальный файл зоны. Другими словами, единственная информация, которую можно получить от DNS-сервера с зоной-заглушкой для данной зоны, — это имена DNS-серверов и сведения о том, какой из них является первичным DNS-сервером зоны.
IP-адрес определенной хост-машины в зоне из зоны-заглушки получить нельзя.
Примечание: С зонами заглушками в Windows 2003 связано одно существенное ограничение, а именно - зона заглушка не может быть создана на DNS - серверах, которые одновременно выступают в качестве носителя полной версии зоны.
Чем может быть полезна зона, которая лишь сообщает, какие серверы являются серверами имен зоны? Предположим что у нас есть домен rk.com имеющий большую зону с огромным количеством записей в ней. Учитывая то что зона большая то и количество серверов DNS в ней естественно будет большим что бы обслуживать запросы клиентов, снизить сетевой трафик и повысить надежность зоны. Администраторы сети при проектирование сети создали первичный DNS и группу вторичных DNS-серверов, ну все как положено в таких случаях.
Но в процессе работы, при анализе сетевого трафика выяснилось, что DNS-серверы тратят больше времени на синхронизацию копии зоны (приведение к одинаковости всех копий зоны находящихся на других DNS серверах (передача зоны смотрите здесь) от первичного DNS-сервера, и тем самым тормозят работу первичного сервера DNS данной зоны и создают избыточный трафик в сети, нагружая сеть. То есть, создают избыточный трафик на синхронизации копии зон , чем на рассылку ответов по разрешению имен.
Проанализировав данную ситуацию с учетом большого трафика между основным DNS сервером и вторичными DNS серверами сетевые администраторы пришли к выводу что необходимо преобразовать некоторое количество вторичных DNS серверов в DNS сервера с зонами заглушками. В этой ситуации если DNS-серверы получают запрос по разрешению имен относительно rk.com, то они не дадут ответа, но им известно, на какой сервер точно нужно направить запрос. То есть DNS серверы не создают некие, допустим рекурсивные запросы по разрешении имени rk.com и не проходят всю иерархию DNS серверов в поисках ответа на запрос о rk.com, и данный процесс упрощается, а именно - запрашиваемый DNS сервер задает вопрос DNS серверу содержащий зону заглушку и зона заглушка передает ответ с указанием сервера DNS который точно ответственен за разрешение имен запрашиваемого ресурса.
И еще при создание DNS серверов с зонами заглушками в процессе разрешения имени не вовлекаются корневые серверы DNS что очень важно и полезно для всех живущих на просторах интернета.
Кроме того серверы с зонами заглушками играют роль серверов кэширования (как практически все DNS-серверы) что убыстряют ответ на запрос так как не обязательно просматривать базу данных зоны а запрашиваемые данные извлекаются из кэша.
То есть, как мы видим из приведенного примера, как бы происходит локализация запросов. И если говорить по большому то -
основное назначение зоны заглушки - идентификация DNS - серверов способных выполнить разрешение имени принадлежащей к данной зоне.
Еще одно применение зон заглушек в Windows Server 2003 это организация взаимодействия двух лесов доменов. В таком сценарии в каждом лесу имеются собственные корневые серверы (о лесах и корневых серверах смотрите здесь и здесь). Так вот создавая зоны заглушки сетевой админ может создать ссылки на домены расположенные в другом пространстве имен.
И еще, маленькая зона-заглушка быстро обновляется, поэтому не создает серьезной нагрузки на оперативную память и процессор DNS-сервера, а также не загружает сетевой трафик. Содержание зоны заглушки в активном состоянии происходит как и для обычной зоны. Периодически один из носителей полной зоны выполняет обновление зоны заглушки передавая необходимые ресурсные записи с учетом требуемых ресурсных записей для данного типа записей. Конфигурация процесса передачи зоны определяется параметрами записи SOA данной зоны и мы их рассмотрели в предыдущей теме.
Тут можно было бы закончить но что бы понять лучше что такое зоны заглушки и механизм условных пересылок запросов которые схожи надо в данном контексте рассмотреть и данный механизм.
Условные пересылки запросов (conditional forwarding)
Механизм условных пересылок запросов или вы еще можете их встретить как "выборочного перенаправления запросов" (conditional forwarding) позволяет осуществлять перенаправление пользовательских запросов на другие DNS-серверы, основываясь на информации о доменном имени, включенном в запрос.
Обычный режим перенаправления (forwarding) предполагает перенаправление всех запросов на определенный DNS-сервер или группу серверов.
Рисунок 3.
Фактически условных пересылок позволяет выполнять на DNS-сервере сортировку запросов. Некоторую часть запросов сервер способен разрешить сам, другая часть будет перенаправлена различным серверам имен. Смотрите рисунок 3.
Для условной пересылки DNS-сервер настраивается таким образом, что при поступлении запроса о конкретном домене (например, xu.com), на который у сервера нет ответа, он просит другой DNS-сервер найти ответ.
Следует обратить внимание на различие: стандартная пересылка— это передача безответных запросов о любом домене конкретному DNS-серверу, а условная пересылка заставляет передавать ретранслятору только запросы о конкретном домене.
Условные пересылки позволяет повысить эффективность разрешения запросов за счет сокращения количества операций. Так же, как и механизм упрощенных зон, выборочное перенаправление может быть использовано как средство организации взаимодействия двух лесов доменов, реализующих собственные пространства имен DNS.
Поскольку механизм условных пересылок способен решать те же задачи, что и зоны заглушки, очень трудно увидеть различия между ними. Какой из двух механизмов выбрать в той или иной ситуации?
Механизм условных пересылок позволяет перенаправить запросы клиентов по разрешению определенного доменного имени (например xu.com) на конкретный DNS-сервер (например на rk.com) .
Использование же зон заглушек для разрешения определенного доменного имени дает ссылку на некоторый набор DNS-серверов, способных выполнить это разрешение. Поэтому, если администратору необходимо контролировать процесс обращения пользователей к корпоративным DNS-серверам (например, с целью управления нагрузкой на серверы или для сокращения нагрузки на линии связи с ограниченной пропускной способностью), он должен использовать механизм условных пересылок.
С другой стороны, использование механизма зон заглушек позволяет реализовать большую гибкость в управлении DNS-серверами. Изменение списка DNS-серверов, выступающих в качестве носителей полной копии зоны (а соответственно, способных выполнить разрешение определенного множества доменных имен), приводит к автоматическому обновлению зоны заглушки на всех ее носителях. В случае же использования механизма условных пересылок администратору придется вручную изменить конфигурацию всех вовлеченных DNS-серверов.
Поясняю подробней. Допустим, что в зону добавлен DNS-сервер. Как информировать сервер зоны-заглушки или сервер с условной пересылкой об этом событии? В случае с сервером зоны-заглушки делать ничего не потребуется — новый сервер появится в зоне-заглушке после репликации. Но если используется условная пересылка, то необходимо посетить каждый DNS-сервер и изменить список серверов, к которым следует обращаться в поисках необходимой записи по разрешении имени.
Еще одна проблема, возникающая при сравнении зон-заглушек с условной ретрансляцией, связана с полномочиями. Допустим у нас два домена одной компании rk.com и xu.com, и эти домены администрируются вместе из одного места. Но если допустим эти домены когдато были разные а потом в силу каких то обстоятельств (допустим приказом по министерству) было необходимо объединить в одном лесе, а соперничество в администрировании осталось?
В таком случае размещать зоны-заглушки для серверов rk.com на серверах xu.com можно лишь с разрешения администраторов rk.com. Для того чтобы серверы xu.com получали при репликации DNS информацию от серверов rk.com, серверы rk.com должны дать согласие на передачу этой информации при пересылке зоны.
Если в нашей сети находятся DNS сервера на базе Windows Server 2000 то по умолчанию DNS-серверы Windows 2000 передают данные любому запросившему их серверу DNS. Но если на базе Windows 2003 то находящиеся в зоне DNS-серверы по умолчанию выполняют пересылки зоны только на серверы, имеющие в этой зоне NS-записи. Поэтому, прежде чем DNS-сервер xu.com с зоной-заглушкой rk.com сможет обновить информацию о зоне с DNS-сервера rk.com, этот сервер xu.com должен получить NS-запись в зоне xu.com.
Поэтому допустим если кто-то захочет настроить свои DNS-серверы на пересылку всех запросов для сайтов microsoft.com на какой то доступный DNS-сервер моей сети, то помешать этому практически нельзя, но это не разумно, так как в результате существенно замедлится процесс разрешения имен для данного администратора.
Продолжение темы смотрите здесь.
