Среда, 22.11.2017, 01:15
Приветствую Вас Гость | RSS

Я - за павсимесную и всиоблемущюю паддершку Аброзования!

Меню сайта
Форма входа
Опрос
Как вы относетесь к порнографии
Всего ответов: 697
Облако тегов
апокриф библия история история религии маска сети настройка IP-адреса НОВЫЙ ЗАВЕТ Альбион гастарбайтер Гражданин и ты Брут Митридат политическая реклама Понт воскрешение гармония Дух плоть праведная плоть канон Аид гомер Мифология моментальность дружба женщина мужчина отношение VPN dns корневой домен DNS клиент FQDN HOSTS пространство имен разрешение имен MX зона DNS корневые Мастер установки Active Directory глобальный каталог раздел домена Раздел конфигурации Раздел схемы GUID.контроллер домена.Серверы плац Внутрисайтовая репликация межсайтовая репликация лес Домен Планирование Active Directory подразделение DNS-сервера DnsCmd DomainDnsZones ForestDnsZones SUPTOOLS.MSI настройка зоны DNS область распространения зоны DNS SOA Primary Name Server Start of Authority Transfer Zone зонная передача Начальная запись зоны DNS Основной сервер DNS передача зоны DNS nslookup дерево доверие доверительные отношения ADSL DMT ISP POTS xDSL Ntds.dit Active Directory.Зоны прямого просм Netlogon SVR Sysvol _msdcs _saites _tcp _udp Dcdiag Dcpromo.log Dcpromos.log Dcpromoui.log Netdiag Ntdsutil консоль ммс панель задач оснастка авторский параметры пользовательский расширение режим консоли
AdSense
Счетчики
PR-CY.ru Каталог@Mail.ru - каталог ресурсов интернет реклама в интернете, реклама сайта
Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0
Главная » 2010 » Декабрь » 1 » Способы хранения зон DNS
17:21
Способы хранения зон DNS
Продолжение начало смотрите здесь.

Способы хранения зон DNS.

В Windows Server 2003 существует три метода хранения зон DNS, а именно:
  • хранение зоны в отдельном файле,
  • хранение зоны в доменном разделе каталога,
  • хранение зоны в разделе приложений.
Рассмотрим каждый из этих способов хранения зоны. 

Хранение зоны в файле.

Этот метод есть традиционный метод хранения зон DNS описанный в спецификациях DNS. При таком методе хранения зоны вся информация о зоне хранится в специальном текстовом файле. Имя файла образуется из "названия зоны" с расширением ".dns". 

К примеру в случае если мы решили сохранить информацию о зоне нашего домена RK.COM то у нас это информация на сервере будет сохранена в файле "rk.com.dns". На DNS сервере мы можем располагать и несколько зон, и в данном случае каждая зона будет иметь свой отдельный файл, смотрите рисунок 1. На рисунке показан еще файл зоны xu.com. Такой метод хранения является достаточно простым методом хранения зон и более старым, по сравнению с остальными которые приведены здесь. Именно такой метод применяется для хранения зон в Windows NT 4. 



Рисунок 1.

Хранятся данные файлы с окончанием dns в папке %SystemRoot% \system32\dns.

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


  Рисунок 2.

На рисунке в данном файле мало записей так как данный файл создан только для примера, в жизни такие файлы куда более насыщены информацией но формат записей такие же как и на рисунке 2.

Хранение зоны в доменном разделе каталога.

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

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

Зона которая хранится в каталоге Active Directory получила название - "зоной интегрированной в Active Directory" (Active Directory integrated zone).

Надо заметить что подобный метод хранения зоны возможен только в случае когда служба DNS установлена на контролере домена. А что такое контролер домена Вы если читали рассылку с начала должны помнить. Но я напомню вкратце. Контролер домена считается компьютер на котором установлена служба каталога Active Directory. 

Для размещения зоны DNS используется доменный раздел Active Directory (о разделах Active Directory смотри здесь). 

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

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

Хранение зоны DNS в разделе приложений.

Данный метод работает только в 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-сервер или группу серверов. 

Пересылка запросов 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-сервер моей сети, то помешать этому практически нельзя, но это не разумно, так как в результате существенно замедлится процесс разрешения имен для данного администратора.

Продолжение темы смотрите здесь.

Категория: Категория Windows Server | Просмотров: 13955 | Добавил: AlterEgo25 | Теги: зона DNS, хранение зоны, DNS-сервера
Поиск
Подписатся
Подписаться на рассылку
"Active Directory - от простого к сложному."


 
Mail.Ru
Подписатся
Подписаться на:
Active Directory от простого к сложному | RSS
Имя:
E-mail

Посетите Каталог Maillist.ru.
Maillist.ru: Active Directory от простого к сложному
Календарь
«  Декабрь 2010  »
ПнВтСрЧтПтСбВс
  12345
6789101112
13141516171819
20212223242526
2728293031
Поделись с другом
Поиск
Loading
Рейтинг чатов Поисковый каталог Эхо Ру счетчик посещений
счетчик посещений

Copyright MyCorp © 2017
Используются технологии uCoz