Зоны DNS, интегрированные с Active Directory
Twitter LinkedIn Facebook Адрес электронной почты
- Статья
- Чтение занимает 2 мин
Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
серверы службы доменных имен (DNS), работающие на контроллерах домена, могут хранить свои зоны в доменные службы Active Directory (AD DS). Таким образом, нет необходимости настраивать отдельную топологию репликации DNS, которая использует обычные передачи зон DNS, так как все данные зоны реплицируются автоматически с помощью Active Directory репликации. Это упрощает процесс развертывания DNS и предоставляет следующие преимущества:
Для репликации DNS создается несколько образцов. Таким образом, любой контроллер домена в домене, на котором запущена служба DNS-сервера, может записывать обновления в зоны DNS, интегрированные в Active Directory, для доменного имени, для которого они являются полномочными. Отдельная топология зонных передач DNS не требуется.
Поддерживаются безопасные динамические обновления. Безопасные динамические обновления позволяют администратору управлять тем, какие компьютеры обновляют имена, и предотвращать перезапись существующих имен в DNS неавторизованными компьютерами.
Active Directory интегрированные службы DNS в Windows Server 2008 хранят данные зоны в разделах каталога приложений. (нет изменений в поведении интеграции DNS на основе Windows Server 2003 с Active Directory.) Во время установки AD DS создаются следующие разделы каталога приложений, относящиеся к DNS.
Дополнительные сведения о том, как AD DS хранит сведения о DNS в разделах приложений, см. в техническом справочнике по DNS.
Примечание
рекомендуется устанавливать DNS при запуске мастера установки доменные службы Active Directory (Dcpromo.exe). В этом случае мастер автоматически создает делегирование зоны DNS. дополнительные сведения см. в разделе развертывание корневого домена леса Windows Server 2008.
Настройка репликации и передачи зон DNS
В организации DNS нужно конфигурировать не только на отдельном сервере, но и для всей сети. DNS-серверы следует размешать таким образом, чтобы можно было управлять рабочей нагрузкой при обработке данных серверами, снизить объем трафика между серверами и клиентами и сократить время реагирования DNS-серверов на запросы клиентом. Во всех организациях, кроме самых мелких, для выполнения таких задач нужно развернуть больше одного DNS-сервера.
При развёртывании нескольких DNS-серверов в организации согласованность данных на таких серверах становится важным аспектом конфигурирования и управления DNS в сети. Чтобы DNS-серверы в организации обеспечивали синхронизированную текущую информацию для клиентов, нужно отконфигурировать репликацию и передачу зон.
Репликация зон — это процесс синхронизации данных зон, интегрированных в Active Directory. Передача зон — это синхронизация данных зон между главной и дополнительной стандартной зоной. Эти два механизма основаны на разных технологиях, поэтому настраиваются отдельно.
Настройка репликации зон, интегрированных в Active Directory
Зоны, интегрированные в Active Directory, можно устанавливать только на контроллерах домена, где установлена роль DNS-сервер. Зоны, интегрированные в Active Directory, в отличие от стандартных зон обеспечивают многоуровневую репликацию данных, упрощенную конфигурацию, а также повышенную безопасность и эффективность. С помощью хранилища, интегрированного в Active Directory, DNS-клиенты могут отправлять обновления на любой DNS-сервер, интегрированный в Active Directory. Затем эти обновления копируются с помощью репликации на другие DNS-серверы, интегрированные в Active Directory.
Репликация и раздел каталога приложений
Данные DNS для отдельной зоны можно реплицировать среди контроллеров домена различными способами, в зависимости от раздела каталога приложения, где хранятся данные зоны DNS.
Раздел — это структура данных в Active Directory, которая определяет данные для репликации. По умолчанию контроллеры домена включают два раздела каталога приложений, зарезервированные для данных DNS: DomainDnsZones и ForestDnsZones. Репликация раздела DomainDnsZones выполняется на всех контроллерах домена, также являющихся DNS-серверами в отдельном домене, а репликация раздела ForestDnsZones выполняется на всех контроллерах домена, также служащих DNS-серверами в каждом домене леса Active Directory.
Каждый из этих разделов каталога приложений получает имя в соответствии с именем FQDN дочернего домена DNS. Эти разделы можно просмотреть в диспетчере DNS. Кроме того, каждая зона содержит имя DomainDnsZones, указывающее раздел, репликация которого выполняется лишь в локальных доменах.
Помимо этих двух разделов в каталоге приложений можно также создать настраиваемый или определяемый пользователем раздел и присвоить ему имя по своему усмотрению. Затем можно отконфигурировать зону для хранения данных в этой новой структуре. По умолчанию новый раздел каталога приложений существует только на сервере, где создается, однако в этом разделе можно перечислить и другие серверы, чтобы туда копировались данные репликации его содержимого.
Хранение данных DNS в разделе домена Данные зоны, интегрированной в Active Directory, хранятся в разделе домена вместе с остальными данными домена. В этой конфигурации репликация данных DNS выполняется не только на контроллерах домена, которые также являются DNS-серверами, но и па всех контроллерах локального домена. Однако при использовании этой опции генерируется дополнительный трафик репликации. Ее следует применять для репликации данных DNS на компьютерах Windows Server 2000.
Выбор области репликации зон
Раздел, в котором хранится зона, эффективно определяет область репликации для этой зоны, интегрированной в Active Directory. При использовании программы Dcpromo для назначения сервера контроллером нового домена в разделе DomainDnsZones автоматически создается новая зона, интегрированная в Active Direcrory. Однако при создании новой зоны с помощью мастера создания новой зоны на странице Область репликации зоны, интегрированной в Active Directory (Active Directory Zone Replication Scope), можно выбрать раздел для сохранения зоны.
На странице Область репликации зоны, интегрированной в Active Directory (Active Directory Zone Replication Scope), представлены четыре опции.
■ Для всех DNS-серверов в этом лесу (То All DNS Servers In This Forest)
Новая зона сохраняется в разделе ForestDnsZones. Каждый контроллер домена во всем лесу, где установлен DNS-сервер, получит копию этой зоны.
■ Для всех DNS серверов в этом домене (То All DNS Servers In This Domain)
Новая зона сохраняется в разделе DomainDnsZones. Каждый контроллер локального домена, где установлен DNS-сервер, получит копию этой зоны.
■ Для всех контроллеров домена в этом домене (То All Domain Controllers In This Domain)
Зона сохраняется в разделе домена. Каждый контроллер локального домена получит копию этой зоны независимо от наличия па нем установленного DNS-сервера.
■ На все контроллеры домена, указанные в области данного раздела каталога (То All Domain Controllers Specified In The Scope Of This Directory Partition)
Зона сохраняется в созданном пользователем разделе каталога приложения, который указан в раскрывающемся списке. Чтобы контроллер домена попадал в область такого раздела каталога, нужно вручную указать этот контроллер домена в разделе.
Область репликации созданной зоны можно изменить в любое время. Для этого на вкладке Общие (General) щелкните кнопку Изменить (Change) напротив параметра репликации.
Откроется диалоговое окно Изменение области видимости зоны репликации (Change Zone Replication Scope), в котором представлены те же опции выбора области репликации, что и на странице мастера создания новой зоны.
При выборе области репликации нужно учесть, что увеличение этой области приводит к повышению объема сетевого трафика, связанного с репликацией. Например, если выбрать репликацию интегрированной в Active Directory зоны для всех DNS-серверов в лесу, объем сетевого трафика будет больше, чем при репликации данных зоны DNS лишь на все DNS-серверы в локальном домене. С другой стороны, репликация данных зоны на все DNS-серверы в лесу может ускорить разрешение имен и обеспечить отказоустойчивость.
ПРИМЕЧАНИЕ: Повторное создание зон DomalnDnsZones и ForestDnsZones
Удаленные или поврежденные разделы каталога приложений можно воссоздать в диспетчере DNS, щелкнув правой кнопкой мыши узел сервера и применив команду Создать используемые по умолчанию разделы каталога приложений (Create Default Application Directory Partitions).
Создание настраиваемого раздела каталога приложения
Вы можете создавать собственные настраиваемые разделы каталога приложения для использования DNS, а затем перечислить выбранные контроллеры доменов в сети для управления репликами этого раздела. Для выполнения этой задачи сначала создайте раздел с помощью такой команды:
dnscmd имя_сервера /createdirectorypartition hmp_FQDN
Затем перечислите в разделе другие DNS-серверы с помощью следующей команды:
dnscmd имя_сервера /enlistdirectorypartition имя_FQDN
Так, чтобы создать раздел каталога приложений DNSpartitionA на компьютере Server1 в домене Active Directory с именем microsoft. com, введите такую команду:
dnscmd server1 /createdirectorypartition DNSpartitionA.microsoft.com
ПРИМЕЧАНИЕ: Использование точки (.) для указания имени локального сервера
Если команда выполняется на том же сервере, где был создан раздел, вместо имени локального сервера можно использовать точку.
Чтобы перечислить в разделе каталога приложений компьютер Server2, введите такую команду:
dnscmd server2 /enlistdirectorypartition DNSpartitionA.microsoft.com
ПРИМЕЧАНИЕ: Кто может создавать раздел каталога приложений
Раздел каталога приложений может создать лишь член группы Администраторы предприятия (Enterprise Admins).
Созданный раздел каталога приложений появится в раскрывающемся списке на странице Область репликации зоны, интегрированной в Active Directory (Active Directory Zone Replication Scope) мастера создания новой зоны и в диалоговом окне Изменение области видимости зоны репликации (Change Zone Replication Scope). Чтобы сохранить зону в новом разделе, выберите опцию На все контроллеры домена, указанные в области данного раздела каталога (То Аll Domain Controllers Specified In The Scope Of This Directory Partition), и в раскрывающемся списке укажите этот раздел.
Передача зон
Если все DNS-серверы расположены на контроллерах доменов, для обеспечения согласованности данных зон среди всех DNS-серверов используется репликация Active Directory. Однако эта возможность недоступна при установке DNS-сервера на компьютере, не являющемся контроллером домена. В таком случае зону нельзя сохранять в Active Directory, вместо этого нужно использовать стандартную зону, которая сохраняет данные в локальном текстовом файле на каждом DNS-сервере. Если в организации используется много DNS-серверов, то исходные данные можно копировать в управляемые другими серверами дополнительные зоны с правом только для чтения. Для того чтобы обеспечить согласованность и обновление данных между основной и дополнительными зонами, нужно настроить передачу зон.
Передача зон, по сути, представляет собой извлечение данных, инициируемое в дополнительных зонах, копирование данных главной зоны, которая сама по себе может быть основной или еще одной дополнительной зоной. Главной зоне необязательно даже быть стандартной по отношению к дополнительной зоне — вы можете отконфигурировать дополнительную зону для основной зоны, интегрированной в Active Directory. К примеру, у вас есть два сайта — один в Нью-Йорке, другой в Лос-Анджелесе, причем каждый сайт принадлежит отдельному домену Active Directory. В каждом домене можно обеспечить разрешение имен для противоположного домена, не устанавливая новый контроллер домена и не управляя трафиком репликации между двумя сайтами.
Включение передачи зон
Передача данных для дополнительных зон может быть инициирована в любом из трех случаев.
■ По истечении интервала обновления начальной записи SOA основной зоны.
■ При загрузке дополнительной зоны сервером.
■ В результате изменения конфигурации основной зоны, если эта зона настроена для уведомления дополнительной зоны об обновлениях.
По умолчанию передача для всех зон отключена. Ее нужно включить на вкладке Передача зон (Zone Transfers) окна свойств зоны. Установив флажок разрешения передачи зон, можно выбрать одни из трех параметров передачи.
■ На любой сервер (To Any Server) Этот параметр обеспечивает минимальную безопасность. Поскольку передача зоны представляет собой копирование данных зоны, этот параметр позволяет кому угодно с сетевым доступом к DNS-серверу просмотреть содержимое зоны, включая имена всех серверов и компьютеров с их IP-адресами. Поэтому данный параметр следует использовать только в частных сетях с высоким уровнем безопасности.
■ Только на серверы, перечисленные на странице серверов зон (Only To Servers Listed On The Name Servers Tab) Этот параметр позволяет выполнять передачу зон с записью NS только на те дополнительные DNS-серверы, которые полномочны для данных зон.
■ Только на серверы из этого списка (Only To The Following Servers) Этот параметр позволяет указать список дополнительных серверов, на которые будет выполняться передача зон. Для этих дополнительных серверов не требуется идентификация с помощью записи NS в зоне.
Настройка уведомлений
На вкладке Передача зон (Zone Transfers) можно также настроить уведомление, которое будет отправлено дополнительным серверам в случае изменений в основной зоне. Поскольку передача зон представляет собой операции PULL, их нельзя конфигурировать для переноса новых данных на дополнительные серверы. Вместо этого при модификации данных основная зона отправляет уведомление на все указанные серверы, управляющие дополнительными зонами. Дополнительная зона, получившая уведомление, инициирует передачу зоны.
Для настройки уведомлений на вкладке Передача зон (Zone Transfers) щелкните кнопку Уведомить (Notify). Откроется диалоговое окно Уведомление (Notify), где можно указать дополнительные серверы, которые будут оповещаться при обновлении зоны на локальном главном сервере.
По умолчанию при включении передачи зон все серверы, перечисленные на вкладке Серверы имен (Name Servers), автоматически уведомляются об обновлениях зоны.
Обновление дополнительной зоны вручную
Если щелкнуть дополнительную зону правой кнопкой мыши, откроется контекстное меню, в котором можно использовать следующие операции для обновления зоны.
■ Перезагрузка (Reload)
Перезагружается дополнительная зона из локального хранилища.
■ Передать зону с основного сервера (Transfer From Master)
Сервер, управляющий локальной дополнительной зоной, определяет истечение интервала обновления серийного номера дополнительной зоны в записи SOA и выполняет передачу зоны с главного сервера.
■ Перезагрузить повторно зону с основного сервера (Reload From Master)
Выполняется передача зоны с главного сервера дополнительной зоны независимо от серийного номера в записи SOA дополнительной зоны.
Использование зон-заглушек
Зона-заглушка — это копия, которая содержит лишь основные записи главной зоны. Назначают зону-заглушку, чтобы локальный DNS-сервер мог пересылать запросы на уполномоченные серверы имен в главной зоне. Таким образом, зона-заглушка функционально идентична делегированию зон. Тем не менее, поскольку зоны-заглушки могут инициировать и принимать передачу зон из главной (делегированной) зоны, они обеспечивают дополнительное информирование родительских зон об обновлениях в записях NS дочерних зон.
Зоны-заглушки можно использовать в следующих целях:
■ Обновление данных делегированной зоны
Регулярно обновляя зону заглушку для одной из своих дочерних зон, DNS-сервер, управляющий родительской зоной и зоной-заглушкой, будет поддерживать текущий список полномочных DNS-серверов для дочерней зоны.
■ Разрешение имен
Зоны-заглушки позволяют DNS-серверу выполнять рекурсию, используя список серверов имен в зоне-заглушке и не запрашивая при этом Интернет или сервер в локальном пространстве имен DNS. В такой ситуации все зоны-заглушки развертываются не между родительской и дочерней зонами, а в доменах большого леса Active Directory или пространстве имен DNS.
ПРИМЕЧАНИЕ: Делегированная зона
Делегированная зона — это дочерняя зона родительской зоны, управление которой осуществляется па собственном DNS-сервере. В случае делегирования родительская зона содержит запись NS для сервера, управляющего этой дочерней зоной. Таким образом, при получении запросов имен в дочерней зоне родительская перенаправляет их па сервер, указанный в записи NS.
Пример зоны-заглушки
Предположим, вы работаете администратором DNS-сервера Dns1.microsoft.com, который уполномочен для зоны Microsoft.com. Ваша компания имеет дочерний домен Active Directory с именем India.microsoft.com, для которого выполняется делегирование. При начальном делегировании дочерняя зона, интегрированная и Active Directory, содержит только два полномочных DNS-сервера — 192.168.2.1 и 192.168.2.2. Позже администраторы домена India.microsoft.com развертывают дополнительные контроллеры домена и устанавливают роль DNS-сервер (DNS Server) на новых контроллерах. Однако администраторы не уведомили вас о том, что добавили полномочные DNS-серверы на свой домен. В результате на сервере Dns1.microsoft.com оказались не отконфигурированными записи новых DNS-серверов, уполномоченных для домена lndia. microsoft.com, и запросы продолжают пересылаться лишь на два DNS-сервера, заданный в начальном делегировании.
Эту проблему можно устранить, создав зону-заглушку на сервере Dns1. microsoft.com для домена India.microsoft.com. С помощью новой зоны-заглушки компьютер Dns1 посредством передачи зон изучает новые серверы имен, уполномоченные для родительской зоны India.microsoft.com. Таким образом, сервер Dns1 сможет направлять запросы пространства имен Inclia.microsoft.com на все полномочные DNS-серверы дочерней зоны.
Другие примеры использования зон-заглушек
Зоны-заглушки могут использоваться для разрешения имен между доменами, предотвращая поиск родительского сервера в пространстве имен DNS. Зоны-заглушки, таким образом, заменяют дополнительные зоны в ситуациях, когда требуется обмен данными DNS между доменами без избыточности данных для главной зоны. Кроме того, зоны-заглушки оптимизируют процесс разрешения имен и снижают нагрузку сетевых ресурсов при передаче данных зон.
Непосредственная репликация AD DNS — Opentechtips
Home » Непосредственная репликация DNS
— до ZSolt Agoston — Последнее отредактированное на 9000
быть зарегистрированным на доступном для записи контроллере домена. Эти изменения включают добавление, изменение или удаление учетных записей пользователей или компьютеров, объектов групповой политики и т. д. Когда эти изменения вносятся в контроллер домена-члена, требуется время, чтобы это изменение реплицировалось на все другие контроллеры домена в домене.
В этом лабораторном занятии мы рассмотрим запуск мгновенной репликации как объектов AD, так и их особого подмножества: зон DNS.
В нашей лаборатории мы используем следующую топологию: два сайта AD, один называется NY и содержит DC01, другой называется CA и содержит контроллеры домена DC02 и DC03. Стоимость связи между двумя сайтами установлена равной 1000. Все серверы имеют соединения репликации со всеми остальными, формируя правильную топологию сетки.
I. Репликация Active Directory 1. Репликация внутри сайтаРепликация между контроллерами домена в ОДНОМ и том же сайте AD выполняется почти мгновенно. Когда происходит изменение, исходный контроллер домена ждет 15 секунд, а затем начинает уведомлять партнерские контроллеры домена об изменении. Если партнеров несколько, уведомления отправляются с интервалом в 3 секунды каждому отдельно. После получения уведомлений каждый из них будет запрашивать репликацию у источника.
2. Межсайтовая репликацияРепликация между сайтами происходит реже, чтобы сэкономить драгоценную полосу пропускания, поскольку сайты обычно подключены через более медленные соединения WAN. По умолчанию межсайтовая репликация выполняется каждые 180 минут, но при необходимости можно установить интервал до 15 минут с помощью фрагмента Active Directory Sites and Services.
Чтобы запустить немедленный цикл репликации, используйте следующую команду на членском контроллере домена:
repadmin /syncall /APed
Это запустит репликацию во всем домене между всеми подключенными контроллерами домена.
Переключатели:
- /syncall Синхронизирует указанный контроллер домена со всеми партнерами по репликации
- /A Синхронизирует все контексты именования, хранящиеся на домашнем сервере controller
- /e Синхронизирует контроллеры домена на всех сайтах предприятия. По умолчанию эта команда не синхронизирует контроллеры домена на других сайтах
- /d Идентифицирует серверы по отличительному имени в сообщениях
Репликация изменений записи домена внутри одного сайта AD почти так же мгновенна, как репликация объекта AD, в наших тестах мы добавили «NewIntraTest.protectigate.com» A запись на DC02. Новая запись была реплицирована в течение 2 минут на DC03 без какого-либо вмешательства.
2. Репликация между сайтамиАналогично циклу репликации AD, когда мы вносим изменения в DNS на контроллере домена и принудительно выполняем репликацию для передачи изменений на другие контроллеры домена, записи DNS также реплицируются.
Однако изменения DNS опрашиваются каждые 15 минут по умолчанию для интегрированных зон AD.
Чтобы ускорить этот процесс, мы можем использовать следующую команду для обновления записей зоны на целевом контроллере домена после репликации AD, но до опроса DNS
dnscmd /zoneupdatefromds protectigate. com
Так что помните: сначала используйте команду repadmin НА ИСХОДНОМ DC, где произошло изменение. Затем используйте команду dnscmd НА ЦЕЛЕВОМ контроллере домена, куда мы хотим реплицировать изменения DNS!
На следующей диаграмме показана успешная мгновенная репликация DNS между сайтами.
Взаимодействия читателей
сообщить об этом объявленииПланирование репликации зоны DNS — Tech-FAQ
Зона DNS — это непрерывная часть пространства доменных имен DNS, над которой DNS-сервер имеет полномочия или является полномочным. Зоны DNS содержат либо домены, либо поддомены. Пространство имен DNS можно разделить на несколько зон. Пользователи могут даже размещать все свои зоны на одном DNS-сервере. DNS-сервер Windows Server 2003 может содержать до 20 000 зон DNS.
Зона DNS содержит базу данных зоны, которая содержит записи ресурсов для всех доменов в зоне. Файлы зоны используются, если DNS не интегрирован с Active Directory. Файлы зоны содержат записи ресурсов базы данных DNS, которые определяют зону. Если DNS и Active Directory интегрированы, данные зоны хранятся в Active Directory.
Различные типы зон, которые можно настроить в DNS Windows Server 2003:
- Основная зона: Это единственный тип зоны, который можно редактировать или обновлять, поскольку данные в зоне являются исходным источником данных для все домены в зоне. DNS-сервер, уполномоченный для конкретной основной зоны, выполняет обновления для основной зоны. Данные также могут быть скопированы из основной в дополнительную зону.
- Вторичная зона: Вторичная зона — это доступная только для чтения копия зоны, которая была скопирована с главного сервера во время переноса зоны.
- Зона, интегрированная с Active Directory: Зона, интегрированная с Active Directory, — это зона, данные которой хранятся в Active Directory. Файлы зоны DNS не используются для хранения данных для этих зон. Интегрированная зона Active Directory — это доверенная первичная зона.
- Зона обратного просмотра: Зоны обратного просмотра в основном используются для преобразования IP-адресов в имена ресурсов в сети. Зоны прямого просмотра содержат сопоставления имен с IP-адресами, а зоны обратного просмотра содержат сопоставления IP-адресов с именами.
- Зона-заглушка: Зона-заглушка — это новая функция Windows Server 2003. Зоны-заглушки содержат только те записи ресурсов, которые необходимы для идентификации полномочных DNS-серверов для основной зоны. Зоны-заглушки содержат следующее:
- Запись ресурса Start Of Authority (SOA) для зоны.
- Запись ресурса сервера имен (NS) для зоны.
- Записи ресурсов узла (A), которые определяют полномочные серверы для определенной зоны.
Перенос зоны — это процесс, который копирует записи ресурсов файла зоны на первичном DNS-сервере на вторичные DNS-серверы. Вторичный DNS-сервер также может передавать данные своей зоны другим вторичным DNS-серверам, которые ниже его в иерархии DNS. В этом случае вторичный DNS-сервер считается главным DNS-сервером для других вторичных серверов.
Можно настроить следующие методы передачи зоны:
- Полная передача: Когда пользователи настраивают вторичный DNS-сервер для зоны и запускают вторичный DNS-сервер, вторичный DNS-сервер запрашивает полную копию зоны из первичный DNS-сервер. Вся информация зоны полностью передана. Полная передача зоны, как правило, требует больших ресурсов. Этот недостаток привел к развитию добавочных переносов зон.
-
Инкрементальная передача зоны: При добавочном переносе зоны на вторичные DNS-серверы передаются только те записи ресурсов, которые с тех пор изменились в зоне. Во время переноса зоны базы данных DNS на первичном DNS-сервере и вторичном DNS-сервере сравниваются, чтобы определить, есть ли различия в данных DNS. Если DNS-данные первичного и вторичного DNS-серверов совпадают, передача зоны не выполняется. Если DNS-данные двух серверов различаются, начинается передача дельта-записи ресурса. Это происходит, когда серийный номер в базе данных первичного DNS-сервера выше, чем серийный номер вторичного DNS-сервера. Чтобы произошла добавочная передача зоны, первичный DNS-сервер должен записывать добавочные изменения в свою базу данных DNS. Для инкрементной передачи зоны требуется меньшая полоса пропускания, чем для полной передачи зоны. - Передачи Active Directory: Эти передачи зон происходят, когда зоны, интегрированные в Active Directory, реплицируются на контроллеры домена в домене. Репликация происходит посредством репликации Active Directory.
- DNS Notify — это механизм, который позволяет первичному DNS-серверу информировать вторичные DNS-серверы об обновлении его базы данных. Уведомление DNS информирует вторичные DNS-серверы, когда им необходимо инициировать передачу зоны, чтобы на них можно было реплицировать обновления основного DNS-сервера. Когда дополнительный DNS-сервер получает уведомление от основного DNS-сервера, он может начать добавочную передачу зоны или полную передачу зоны, чтобы получить изменения зоны с основных DNS-серверов.
Определение требований к ресурсной записи DNS (RR)
Наиболее часто используемые ресурсные записи (RR):
- Начало полномочий (SOA): Запись SOA является первой записью в файле базы данных DNS. Запись SOA включает информацию о свойствах зоны, таких как первичный DNS-сервер для зоны и номер версии базы данных.
- Сервер имен (NS): Запись ресурса сервера имен (NS) содержит список полномочных DNS-серверов для домена и полномочных DNS-серверов для любых делегированных поддоменов.
- Узел (A): Запись ресурса узла (A) содержит IP-адрес определенного узла и сопоставляет полное доменное имя с этими 32-разрядными адресами IPv4. Записи ресурсов хоста (A) в основном связывают доменные имена компьютеров (FQDN) или имена хостов с их IP-адресами.
- Псевдоним (CNAME): Записи ресурсов псевдонима (CNAME) связывают псевдоним с соответствующим доменным именем. Записи ресурсов псевдонимов (CNAME) называются каноническими именами. Используя канонические имена, сетевая информация может быть скрыта от клиентов, подключающихся к сети.
- Почтовый обменник (MX): Ресурсная запись почтового обменника (MX) обеспечивает маршрутизацию сообщений на почтовые серверы и резервные серверы. Запись ресурса MX предоставляет информацию о том, какие почтовые серверы обрабатывают электронную почту для определенного доменного имени.
- Указатель (PTR): Запись ресурса указателя (PTR) используется для обратного поиска, чтобы указать на записи ресурсов A. Обратный поиск разрешает IP-адреса в имена хостов или полные доменные имена.
- Сервисный центр (SRV): Active Directory обычно использует записи ресурсов службы (SRV) для обнаружения контроллеров домена, серверов LDAP и серверов глобального каталога.
Основные записи ресурсов , которые идентифицируют хосты в сети DNS :
- Start of Authority (SOA)
- Адресные записи: записи A и AAAA
- Каноническое имя (CNAME) или запись псевдонима
Для работы Active Directory DNS-серверы, на которых размещаются зон, интегрированных с Active Directory, должны поддерживать записи ресурсов (SRV), определенные в RFC 2052: DNS RR для указания местоположения служб (DNS SRV). Это связано с тем, что клиенты и контроллеры домена запрашивают у DNS записи SRV, когда им нужно найти IP-адреса контроллера домена.
Определение требований к зоне
При определении способа разбиения пространства имен DNS на зоны учитывайте следующие факторы:
- Передача файлов зоны между зонами увеличивает трафик передачи зоны DNS и трафик репликации Active Directory.
- Определите шаблоны трафика, существующие между клиентами и DNS-сервером. Обратите особое внимание на запросы, которые передаются через WAN-соединение. Инструмент System Monitor можно использовать для получения статистики DNS-сервера.
- Учитывайте сетевые каналы между DNS-серверами и скорость этих каналов.
- Определите, требуются ли полные DNS-серверы или только кэширующие DNS-серверы для разных местоположений.
Первичные зоны и зоны, интегрированные с Active Directory
При принятии решения о реализации первичных зон DNS или зон DNS, интегрированных в Active Directory, не забудьте включить требования к дизайну DNS среды. Первичные и вторичные зоны — это стандартные зоны DNS, в которых используются файлы зон. Зона, интегрированная с Active Directory, хранит данные своей зоны в Active Directory и поэтому может использовать репликацию с несколькими мастерами и функции безопасности Active Directory.
При реализации зон, интегрированных с Active Directory, выберите один из следующих вариантов области репликации зоны:
- На все DNS-серверы в лесу Active Directory Параметр: Данные зоны реплицируются на все DNS-серверы, работающие на контроллерах домена в лесу Active Directory.
- На все DNS-серверы в домене Active Directory Параметр: Данные зоны реплицируются на все DNS-серверы, работающие на контроллерах домена в домене Active Directory.
- На все контроллеры домена в домене Active Directory Параметр: Данные зоны реплицируются на все контроллеры домена в домене Active Directory.
- На все контроллеры домена, указанные в области действия следующего параметра раздела каталога приложений: Данные зоны реплицируются на основе области репликации конкретного раздела каталога приложений.
Основными преимуществами зон, интегрированных в Active Directory, по сравнению со стандартными первичными зонами DNS являются:
- Репликация Active Directory быстрее, что означает, что время, необходимое для передачи данных зоны между зонами, намного меньше.
- Топология репликации Active Directory используется для репликации Active Directory и репликации зон, интегрированных в Active Directory. При интеграции DNS и Active Directory репликация DNS больше не требуется.
- зон, интегрированных с Active Directory, могут пользоваться функциями безопасности Active Directory.
- Устранена необходимость управлять доменами Active Directory и пространствами имен DNS как отдельными объектами. Это, в свою очередь, снижает административные издержки.
- При интеграции DNS и Active Directory зоны, интегрированные с Active Directory, автоматически реплицируются и сохраняются на любых новых контроллерах домена. Синхронизация происходит автоматически при развертывании новых контроллеров домена.
Определение размещения зоны
Процесс, используемый DNS для пересылки запроса, который один DNS-сервер не может разрешить другому DNS-серверу, называется переадресацией DNS. Серверы пересылки DNS — это DNS-серверы, используемые для пересылки DNS-запросов для разных пространств имен DNS на те DNS-серверы, которые могут ответить на запрос. Создание серверов пересылки DNS может повысить эффективность разрешения имен.
В DNS Windows Server 2003 появилась функция условной переадресации. При условной пересылке пользователи создают в своей среде средства условной пересылки, которые будут пересылать DNS-запросы на основе конкретных доменных имен, запрошенных в запросе. Это отличается от серверов пересылки DNS, где для разрешения запроса использовался стандартный путь разрешения DNS к корню. Условная пересылка может пересылать только запросы для доменов, определенных в конкретном списке условных пересылок. Запрос передается серверу пересылки DNS по умолчанию, если в списке серверов пересылки нет записей для конкретного запрошенного домена.
При планировании среды DNS очевидно, что необходимо внедрить серверы пересылки или условные серверы пересылки, рассмотрите рекомендации по планированию серверов пересылки, которые приведены ниже:
- Используйте серверы пересылки для ограничения количества DNS-серверов, другие через брандмауэры. Эта стратегия повышает безопасность DNS.
- Пользователи также могут повысить отказоустойчивость, настроив несколько серверов пересылки и включив рекурсию для тех запросов, которые не могут быть перенаправлены на указанные серверы пересылки.
- Реализуйте только то количество серверов пересылки DNS, которое необходимо для среды. Воздержитесь от создания множества серверов пересылки для внутренних DNS-серверов.
- Избегайте объединения DNS-серверов в цепочку в конфигурации переадресации.
- Чтобы избежать превращения сервера пересылки DNS в узкое место, не настраивайте один внешний сервер пересылки DNS для всех внутренних DNS-серверов.
Рекомендации по определению репликации зоны
Ниже приведен ряд рекомендаций по планированию репликации зоны:
- Ограничение количества зон полномочий в среде DNS. Чем больше зон полномочий, тем больше административных усилий требуется для управления средой DNS.
- Передача файлов зон между зонами увеличивает трафик передачи зон DNS и трафик репликации Active Directory.
- Чтобы свести к минимуму трафик передачи зоны, когда DNS-серверы существуют на контроллерах домена Windows Server 2003 и используются зоны, интегрированные в Active Directory, рассмотрите возможность использования раздела каталога приложений для хранения данных зоны.
- При использовании стандартной передачи зон DNS полезно реализовать следующее:
- Инкрементальные передачи зон
- Быстрая передача зоны
- Чтобы уменьшить пропускную способность, которую использует стандартная передача зоны DNS, рассмотрите возможность изменения расписания передачи зоны во вторичные зоны DNS.
- Рассмотрите возможность внедрения зон-заглушек для минимизации трафика DNS.
- Используйте зоны, интегрированные с Active Directory, чтобы указать, что разрешены только безопасные обновления зон.
- Для защиты данных зон стандартных типов рассмотрите возможность реализации следующего:
- Ограничьте количество хостов, которым разрешено получать передачи зоны.
- Шифровать данные передачи зоны через туннели VPN или IPSec.
Как создать зону DNS
- Нажмите «Пуск», «Администрирование», затем «DNS», чтобы открыть консоль DNS.
- Разверните папку «Зоны прямого просмотра».
- Выберите папку «Зоны прямого просмотра».
- В меню «Действие» выберите «Новая зона».
- Запускается мастер создания новой зоны.
- На начальной странице мастера нажмите «Далее».
- На странице «Тип зоны» убедитесь, что выбран параметр «Основная зона создает копию зоны, которую можно обновить непосредственно на этом сервере». Этот параметр выбран по умолчанию.
- Снимите флажок Сохранять зону в Active Directory (доступно, только если DNS-сервер является контроллером домена). Нажмите «Далее.
- На странице «Имя зоны» введите правильное имя зоны в текстовом поле «Имя зоны». Нажмите «Далее.
- Убедитесь, что на странице «Файл зоны» выбран параметр по умолчанию «Создать новый файл с этим именем файла». Нажмите «Далее.
- На странице «Динамическое обновление» убедитесь, что параметр «Не разрешать динамические обновления». Динамические обновления записей ресурсов не принимаются этой зоной. Вы должны обновить эти записи вручную.