Что такое обратная зона dns. Создание и настройка зон DNS

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

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

Создание зон

Зона DNS представляет собой базу данных, содержащую записи, которые связывают имена с адресами в описываемой области пространства имен DNS . Хотя для ответов на запросы имен DNS -сервер может использовать кэшированную информацию с других серверов, он уполномочен отвечать на запросы лишь в локально управляемой зоне. Для любой области пространства имен DNS , представленной именем домена (например, google .ru ), существует только один полномочный источник данных зоны.
При необходимости создать на DNS -сервере новую зону можновоспользоваться мастером создания новой зоны (New Zone Wizard ) в диспетчере DNS (DNS Manager ). Для запуска мастера щелкните правой кнопкой мыши значок сервера в дереве консоли диспетчера DNS и примените команду Создать новую зону (New Zone ).

Мастер создания новой зоны содержит следующие страницы конфигурации:

Тип зоны (Zone Type);

Область репликации зоны , интегрированной в Active Directory (Active Directory Zone Replication Scope);

Зона прямого или обратного просмотра (Forward or Reverse Lookup Zone );

Имя зоны (Zone Name );

Динамическое обновление (Dynamic Update ).

В следующих разделах описаны концепции конфигурации, связанные с этими пятью страницами мастера.

Выбор типа зоны

На странице Тип зоны (Zone Type) мастера создания новой зоны (New Zone Wizard) можно выбрать создание основной зоны, дополнительной или зоны-заглушки. Создав на контроллере домена основную зону или зону-заглушку, вы сможете хранить данные зоны в Active Directory.

* Основные зоны

Самым распространенным типом зон DNS является основная зона (Primary zone). Она обеспечивает исходные данные чтения/записиисточника, предоставляющие локальному DNS-серверу полномочия отвечать назапросы DNS области пространства имен DNS.

Локальный DNS-сервер, управляющий основной зоной, служит первичным источником данных об этой зоне. Сервер хранит главную копию данных зоны в локальном файле или в доменных службах Active Directory (Active Directory Domain Services , AD DS ). Если зона сохраняется в файле, а не в Active Directory, этот файл но умолчанию получает имя имя_зоны. dns и хранится в папке %systemroot %\System 32\Dns на сервере.

* Дополнительные зоны

Обеспечивают полномочную копию с правом только для чтения основной зоны или еще одной дополнительной зоны.

Дополнительные зоны (Secondary zones ) предоставляют возможностьснизить объем трафика запросов DNS в областях сети, где происходитинтенсивное запрашивание и использование данных зоны. Кроме того, в случаенедоступности сервера, который управляет основной зоной, дополнительная зона может обеспечивать разрешение имен до тех пор, пока основной сервер снова не станет доступным.

Исходные зоны, из которых дополнительные зоны получают информацию, называются мастер-зонами, а процедуры копирования данных, обеспечивающие регулярное обновление информации зоны, называются передачами зон. Мастер-зоной может быть основная зона или другая дополнительная зона. Мастер-зону можно назначить для создаваемой дополнительной зоны в мастере создания новой зоны (New Zone Wizard ). Поскольку дополнительная зона — это копия основной зоны, управляемая еще одним сервером, ее нельзя хранить в Active Directory .

* Зоны-заглушки

Аналогичны дополнительной зоне, однако содержат записи ресурсов, необходимые для идентификации полномочных DNS -серверовглавной зоны. Зоны-заглушки (Stub zone ) часто применяются для того, чтобыродительская зона (например, google .ru ) могла использовать обновляемый список серверов имен, доступных в делегированной дочерней зоне (например: translate .google .ru ). Они также служат для улучшения разрешения имен иупрощения администрирования DNS .

* Хранение зон в Active Directory

При создании основной зоны илизоны-заглушки на контроллере домена, на странице Тип зоны (Zone Type ) мастера можно выбрать опцию сохранения зоны в Active Directory . Данные зон,интегрированных в Active Directory , автоматически реплицируются в Active Directory в соответствии с параметрами, выбранными на странице Областьрепликации зоны, интегрированной в Active Directory (Active Directory Zone Replication Scope ). Благодаря этой опции нет необходимости настраивать передачу зон на дополнительные серверы.

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

ПРИМЕЧАНИЕ: Контроллеры домена с правом чтения и зоны, интегрированные в Active Directory

На традиционных контроллерах доменов копии зоны предоставляется право чтения/записи. На контроллерах доменов с доступом лишь для чтения (Read-O nly Domain Controller, RODC) копии зоны назначается лишь право чтения.

* Стандартные зоны

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

В отличие от зоны, интегрированной в Active Directory , стандартная зона сохраняет свои данные в текстовом файле на локальном DNS -сервере. Кроме того, в случае использования стандартных зон можно конфигурировать только основную копию с правом чтения и записи данных зоны. Всем остальнымкопиям зоны (дополнительные зоны) назначено право только для чтения.

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

Выбор области репликации зоны, интегрированной в Active Directory

На странице Область репликации зоны, интегрированной в Active Directory (Active Directory Zone Replication Scope ) мастера создания новой зоны (New Zone Wizard ) можно выбрать контроллеры домена в сети для сохранения данных зоны. Эта страница, появляется только при выборе опции сохранения зоны и Active Directory . Опции выбора области репликации зон определяют контроллеры домена, среди которых будет выполниться репликация данных зон.

Па этой странице представлены такие опции:

Сохранение зоны на всех контроллерах домена , которые также являются DNS-серверами во всем лесе Active Directory;

Сохранение зоны на всех контроллерах домена , которые также служит DNS-серверами и локальном домене Active Directory;

Сохранение зоны на всех контроллерах домена и локальном домене Active Directory (используется для совместимости с Windows 2000);

Сохранение зоны на всех контроллерах домена , указанных и области настраиваемого раздела каталога Active Directory.

Более подробно эти опции описаны во второй теме.

Создание зон прямого и обратного просмотра

На странице Зона прямого или обратного просмотра (Forward or Reverse Lookup Zone) мастера создания попой зоны (New Zone Wizard) необходимо выбрать тип создаваемой зоны; зона прямого просмотра (Forward Lookup Zone) или зона обратного просмотра (Reverse Lookup Zone).

В зонах прямого просмотра DNS-серверы сопоставляют полные доменные имена FQDN с IP-адресами. В зонах обратного просмотра DNS-серверы сопоставляют I P-адреса именам FQDN. Таким образом, зоны прямого просмотра отвечают на запросы разрешения имен FQDN в IP-адреса, а зоны обратного просмотра отвечают на запросы разрешения IP-адресов в имена FQDN.Отметим, что зоны прямого просмотра получают имя в соответствии с доменными именами D NS, для которых выполняется разрешение, например google .com. Зоны обратного просмотра именуются и обратном порядке первых трех октетов адресного пространства, для которого обеспечивается разрешение имен, плюс, дополнительный тег in-addr.arpa. Например, при разрешении имен для подсети 192.168.1.0/24 зона обратного просмотра получит имя 1.168.192.in-addr.arpa. В зоне прямого просмотра отдельная запись базы данных, сопоставляющая имя узла с адресом, называется записью узел (А). В зоне обратного просмотра отдельная запись базы данных, сопоставляющая IP-адрес, с именем узла, называется указателем или PTR -записью.

Принцип работы мои прямого и обратного просмотра продемонстрирован на рисунке.

Зона прямого просмотра

Зона обратного просмотра

ПРИМЕЧАНИЕ: Мастер настройки DNS-сервера

Для одновременного создания зон прямого и обратного просмотра можноиспользовать мастер настройки DNS-сервера (Configure A DNS Server Wizard). Чтобы запустить мастер, в дереве консоли диспетчера DNS щелкните правой кнопкой мыши значок сервера и примените команду Настроить DNS-сервер (Configure A DNS Server).

Выбор имени зоны

На странице Имя зоны (Zone Name ) мастера создания новой зоны (New Zone Wizard ) можно выбрать имя создаваемой зоны прямого просмотра, Зоны обратного просмотра получают особые имена в соответствии с диапазоном IP -адресов, для которых являются полномочными.

Если зона создается для разрешения имен в домене Active Directory, лучше всего указать имя зоны, соответствующее имени домена Active Directory. Например, если организация содержит два домена Active Directory, с именами google .ru и translate .google .ru , инфраструктура разрешения имен должна включать две зоны с именами, соответствующими именам этих доменов.

В случае создания зоны для пространства имен DNS не в среде ActiveDirectory, нужно указать имя Интернет-домена организации, например wikipedia .org .

ПРИМЕЧАНИЕ: Добавление DNS -сервера на контроллер домена

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

Настройка параметров динамического обновления

Клиентские компьютеры DNS могут регистрировать и динамически обновлять свои записи ресурсов с помощью DNS -сервера. По умолчанию DNS -клиенты со статическими IP -адресами обновляют записи узлов (А или АААА) иуказателей (PTR ), a DNS -клиенты, являющиеся DHCP -клиентами, — лишь записи узлов. В среде рабочей группы DHCP -сервер обновляет записи указателя от лица DHCP -клиента при каждом обновлении конфигурации IP .

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

Безопасное обновление (Secure updates )

Позволяет выполнять регистрацию только с компьютеров домена Active Directory и обновление лишь с того компьютера, который изначально выполнял регистрацию.

Небезопасные обновления (Nonsecure updates )

Позволяет выполнять обновление с любого компьютера.

На странице Динамическое обновление (Dynamic Update ) мастера создания новой зоны (New Zone Wizard ) для создаваемой зоны можно разрешитьбезопасные, небезопасные динамические обновления или вообще запретить обновление.

Анализ встроенных записей ресурсов

При создании новой зоны автоматически создается два типа записей. Во-первых, такая зона всегда включает начальную запись зоны SOA (Start Of Authority ), определяющую основные свойства зоны. Кроме того, новые зоны содержат хотя бы одну запись сервера имен NS (Name Server ), указывающую имяполномочного сервера (серверов) зоны. Далее описаны функции этих двух записей ресурсов.

Начальные записи зоны

При загрузке зоны DNS-сервер использует начальную запись зоны SOA (Start Of Authority) для определения основных свойств и полномочий зоны. Эти параметры также характеризуют частоту передачи зон между основным идополнительным сервером. Если дважды щелкнуть запись SOA, откроется вкладка Начальная запись зоны (SOA) (Start Of Authority (SOA)) диалогового окна свойств зоны.

Серийный номер (Serial Number)

Это текстовое поле вкладки Начальная запись зоны (SOA) содержит номер редакции файла зоны. Указанное здесь число увеличивается каждый раз при изменении записей ресурсов в зоне. Его также можно увеличить вручную с помощью кнопки Увеличить (Increment).

Если зоны отконфигурированы для выполнения передач зон на один или несколько дополнительных серверов, эти дополнительные серверыпериодически запрашивают серийный номер зоны на главном сервере. Такие запросы называются запросами SOA. Если в запросе SOA получен серийный номер основной зоны, равный серийному номеру дополнительной зоны, передача не выполняется. Если же серийный номер зоны на главном сервере больше соответствующего значения на запрашивающем дополнительном сервере, последний инициирует передачу зоны.

ПРИМЕЧАНИЕ: Передача зон на основном сервере

Щелчком кнопки Увеличить (Increment) инициируется передача зоны.

Основной сервер (Primary Server )

Ответственное лицо (Responsible Person)

В это поле вводится имяответственного лица (RP), соответствующее доменному почтовому ящикуадминистратора зоны. Имя, введенное в это поле, всегда должно завершаться точкой. По умолчанию используется имя hostmaster.

Интервал обновления (Refresh Interval)

Значение в этом поле определяет время ожидания дополнительного DNS-сервера перед запросом обновления зоны на главном сервере. По истечении интервала обновлениядополнительный DNS-сервер запрашивает на главном сервере копию текущей записи SOA. После получения ответа дополнительным DNS-сервер сравниваетсерийный номер текущей записи SOA главного сервера (указанной в ответе) с серийным номером своей локальной записи SOA. Если эти значенияотличаются, дополнительный DNS-сервер запрашивает передачу зоны с главного DNS-сервера. По умолчанию назначается интервал обновления 15 минут.

Интервал повтора (Retry Interval)

Срок истекает после (Expires After)

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

Минимальный срок жизни TTL (Minimum (Default) T TL)

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

Срок жизни (TTL) записи (TTL For This Record)

Значение , указанное в этом иоле, определяет срок жизни текущей записи SOA . Это значение заменяет значение по умолчанию, указанное в предыдущем поле.

Записи серверов имен

Запись сервера имен (NS) указывает полномочный сервер для зоны. Присоздании зоны в Windows Server 2008 каждый сервер, управляющий основной копией зоны, интегрированной в Active Directory, получит собственную запись NS в новой зоне по умолчанию. При создании стандартной основной зоны по умолчанию будет добавлена запись NS локального сервера.

Для серверов, управляющих дополнительными зонами, нужно вручную добавить записи NS в основную копию зоны.

Записи NS создаются с помощью иной процедуры, чем в случае создания других типов записей ресурсов. Чтобы добавить записи NS, в диспетчере DNS дважды щелкните любую существующую запись NS. Откроется вкладкаСерверы имен (Name Servers) диалогового окна свойств зоны. На вкладке Серверы имен щелкните кнопку Добавить (Add), чтобы добавить имя FQDN и IP-адрес сервера, управляющего дополнительной зоной локальной основной зоны. Добавив новый сервер, щелкните ОК - в диспетчере DNSпоявится новая запись NS, указывающая этот сервер.

ПРИМЕЧАНИЕ: Включение передачи в дополнительные зоны

Дополнительная зона не распознает эту запись как действительный сервер имен, пока содержит действительную копию данных зоны. Чтобы дополнительная зона получила эти данные, нужно включить передачу зон для этого сервера на вкладке Передача зон (Zone Transfers) диалогового окна свойства зоны. Эта вкладка более детально описана в следующей теме.

Ниже приведен пример записи, созданной в файле стандартной зоны:

@ NS dns1.lucernepublishing.com.

Символ @ представляет зону, определенную записью SOA в файле зоны. Затем полная запись сопоставляет домен wikipedia .org с DNS-сервером dns1.wikipedia .org .

Создание записей ресурсов

Помимо записей SOA и NS автоматически создаются еще некоторые записи ресурсов. Например, во время установки нового DNS -сервера, когда сервер назначается контроллером домена, многие записи SRV доменных служб Active Directory (AD DS ) создаются автоматически в локально управляемой зоне. Помимо этого, посредством динамического обновления многие DNS -клиенты по умолчанию автоматически регистрируют записи узлов (А и АААА) иуказателей (PTR ) в зоне.

Несмотря на то что многие записи ресурсов создаются автоматически, вкорпоративных средах обычно требуется создать некоторые записи ресурсоввручную, например почтовые обменники MX (Mail Exchanger ) для почтовыхсерверов, псевдонимы (CNAME ) для веб-серверов и серверов приложений, а также записи узлов для серверов и клиентов, которые не могут выполнять собственные обновления.

Чтобы вручную добавить запись ресурса для зоны, в консоли Диспетчер DNS (DNS Manager ) щелкните правой кнопкой мыши значок зоны и в контекстном меню выберите тип создаваемой записи.

После выбора записи в контекстном меню откроется диалоговое окно, где можно указать имя записи и связанный с ней компьютер. Отметим, что имя компьютера с IP -адресом связывают толькозаписи узла. Большинство типов записей связывают имя службы или псевдоним с исходной записью узла. Таким образом, запись MX полагается на присутствие в зоне записи узла SRV 12.nwtraders .msft .

Типы записей

Ниже приведены распространенные записи ресурсов, создаваемые вручную:

узел (А или АЛАА );

псевдоним (CNAME );

почтовый обменник (MX );

указатель (PTR );

расположение службы (SRV ).

Узел (А или АААА)

Для большинства сетей основную часть записей ресурсов в базе данных зоны составляют записи ресурсов узлов. Эти записи используются в зоне для связывания компьютерных имен (имен узлов) с IP -адресами.

Даже при включении динамических обновлений для зон в некоторыхсценариях записи узлов нужно будет добавлять записи в зону вручную. На рисунке далее компания Contoso , Inc . использует доменное имя contoso .com в общедоступном пространстве имен и внутреннем домене Active Directory . В этом случаепубличный веб-сервер www .contoso .com расположен вне домена Active Directory ивыполняет обновления лишь на публичном полномочном DNS -сервере contoso .com . Но внутренние клиенты пересылают свои запросы DNS на внутренние DNS - серверы. Так как запись А сервера www .contoso .com не обновляется динамически на внутренних DNS -серверах, ее добавляют вручную, чтобы внутренниеклиенты могли разрешать имена и подключаться к общественному веб-серверу.

Записи узлов можно добавлять вручную, если в сети используется сервер UNIX. Например, компания Fabrikam, Inc. имеет в своей частной сети один домен Active Directory с именем fabrikam ,com . Эта сеть такжевключает UNIX-сервер App1.fabrikam,com, который запускает важное приложение для выполнения ежедневных операций компании. Так как UNIX-серверы не могут выполнять динамические обновления, придется вручную добавить запись узла сервера Арр1 на DNS-сервер, управляющий зоной fabrikam,com. Впротивном случае пользователи не смогут подключаться к серверу приложений, указывая его имя FQDN.

Псевдоним (CNAME)

Эти записи иногда называют каноническими именами. Они позволяют использовать несколько имен для указания одного узла. Например, известные имена серверов (ftp, www), как правило, регистрируются спомощью записей CNAME. Эти записи сопоставляют имена узлов, соответствующие их службам, с реальной записью Акомпьютера, управляющего службой.

Когда требуется переименовать узел , указанный в записи А той же зоны .

Когда групповое имя известного сервера (например , www) требуется разрешить в группу отдельных компьютеров (каждый из которых содержит индивидуальные записи А), обеспечивающих одну и ту же службу (например, группа резервных веб-серверов).

Почтовый обменник (MX )

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

Часто записи MX создаются для обеспечения отказоустойчивости ещеодного почтового сервера на случай недоступности предпочтительного сервера.

Множеству серверов назначаются значения предпочтений. Чем ниже это значение, тем выше порядок предпочтения сервера.

ПРИМЕЧАНИЕ: Символ @

В данном примере символ @ представляет локальное доменное имя, содержащееся в адресе электронной почты.

Указатель PTR

Эта запись используется лишь в зонах обратного просмотра для поддержки обратного просмотра, который производится при разрешении IP -адресов в имена узлов или имена FQDN . Обратный просмотр выполняется в корневых зонах домена in -addr .arpa . Записи PTR можно добавлять в зоны вручную или автоматически.

Ниже приведен пример текстового представления в файле зоны записи PTR , созданной в диспетчере DNS , которая сопоставляет IP -адрес 192.168.0.99 имени узла server 1.google .ru :

99 PTR server 1. google . ru .

ПРИМЕЧАНИЕ: Номер 99 записи PRT

В зоне обратного просмотра последний октет IPv 4-адреса эквивалентен имени узла. Поэтому число 99 представляет имя, назначенное узлу внутри зоны 0.168.192.in -addr .arpa . Эта зона соответствует подсети 192.168.0.0.

Расположение службы SRV

Записи SRV применяют для указаниярасположения служб в домене. Клиентские приложения, использующие SRV , посредством DNS могут извлекать записи SRV серверов приложений.

В качестве приложения, использующего SRV , можно привести Windows Server 2008 Active Directory . Служба сетевого входа в систему Netlogon использует записи SRV для локализации контроллеров домена, выполняя поискдомена Службы Active Directory облегченного доступа к каталогам (Lightweight Directory Access Protocol , LDAP ). DNS , чтобы повысить отказоустойчивость или устранить неполадки сетевых служб.

Включение DNS для разрешения WINS

На вкладке WINS окна свойств зоны можно указать WINS -сервер, к которому будет обращаться служба DNS -сервер для просмотра имен, не найденных с помощью запросов DNS . При указании WINS -сервера на вкладке WINS диалогового окна свойств зоны прямого просмотра в эту зону добавляется особая запись WINS , ссылающаяся на этот WINS -сервер. При указанииWINS -сервера на вкладке WINS диалогового окна свойств зоны обратного просмотра в зону добавляется особая запись WINS -R , определяющая этот WINS -сервер.

Например, если DNS -клиент запрашивает имя ClientZ .contoso .com ипредпочитаемый DNS -сервер не может найти ответ в обычных источниках (кэше, данных локальной зоны и с помощью опроса других серверов), серверзапрашивает имя CLIENTZ . на WINS -сервере, указанном в записи WINS . Если WINS -сервер отвечает на запрос, DNS -сервер возвращает его ответ клиенту.

Очистка и удаление устаревших записей

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

Включение очистки

Чтобы включить очистку для отдельной зоны, нужно включить эту функцию на уровне сервера и уровне зоны.

Чтобы включить очистку на уровне сервера, в дереве консоли Диспетчера DNS (DNS Manager ) щелкните правой кнопкой мыши значок сервера ипримените команду Установить свойства очистки для всех зон (Set Aging /Scavenging For All Zones ). Затем в открывшемся диалоговом окне Свойства очистки сервера (Server Aging /Scavenging Properties ) установите флажок Удалять устаревшие записи ресурсов (Scavenge Stale Resource Records ). Хотя этот параметр включает на уровне сервера штампы времени и очистку для всех новых зон, он не включает штампы времени и очистку существующих зон, интегрированных в Active Directory .

Чтобы задействовать их, щелкните ОК, а затем в открывшемся диалоговом окне Подтверждение очистки сервера от устаревших ресурсов (Server Aging/ Scavenging Confirmation) установите флажок для применения этих параметров к существующим зонам, интегрированным в Active Directory.

Чтобы включить штампы времени и очистку на уровне зоны, откройте Свойства зоны, а затем на вкладке Общие (General) щелкните кнопку Очистка (Aging). В открывшемся диалоговом окне Свойства очистки для зоны (Zone Aging/Scavenging Properties) установите флажак Удалять устаревшие записи ресурсов (Scavenge Stale Resource Records ).

Штампы времени DNS-сервер выполняет очистку с помощью штампов времени, установленных для записей ресурсов в зоне. Зоны, интегрированные в Active Directory, устанавливают значения штампов времени для динамически регистрируемых записей по умолчанию еще до включения очистки, Однако основные стандартные зоны устанавливают штампы времени для динамически регистрируемых записей в зоне лишь после включения очистки. Записям ресурсов, создаваемым вручную для всех типов зон, назначается штамп времени 0; это означает, что их возраст определяться не будет. — это время между последним обновлением штампа и его возможным следующим обновлением. Блокирование не позволяет серверу обрабатывать ненужные обновления и снижает объем трафика. По умолчанию назначается интервал блокирования 7 дней.

Модификация интервала обновления

Интервал обновления — это промежуток между самым ранним временем обновления штампа времени и самым ранним временем начала очистки записи. По истечении интерваловблокирования и обновления записи могут удаляться из зоны. По умолчаниюинтервал равен 7 дням. Поэтому при включении штампов времени динамически регистрируемые записи ресурсов могут быть удалены через 14 дней.

Выполнение очистки

Очистка выполняется в зоне автоматически или вручную. Для автоматического выполнения очистки нужно разрешить, автоматическое удаление устаревших записей ресурсов на вкладке Дополнительно (Advanced) диалогового окна свойств DNS-сервера.

Если эта опция не включена, вы можете выполнить очистку в зонах вручную, щелкнув правой кнопкой мыши значок сервера в дереве консоли Диспетчер DNS (DNS Manager) и применив команду Удалить устаревшие записи (Scavenge Stale Resource Records).

Зона GlobalNames

В Windows Server 2008 включен новый компонент, позволяющий всем DNS-клиентам в лесу Active Directory использовать имена из одной метки, например Mail, для подключения к ресурсам сервера. Этот компонент удобноиспользовать, если список просмотра DNS-суффиксов по умолчанию для DNS-клиентов не позволяет пользователям быстро подключаться (или подключаться вообще) к ресурсу с помощью такого имени из одной метки.

DNS-сервер в Windows Server 2008 позволяет создавать зону GlobalNames. По умолчанию зона GlobalNames не существует, однако, развернув зону с этим именем, можно обеспечить доступ к выбранным ресурсам с помощью имен из одной метки, не используя WINS. Как правило, имена из одной меткиназначаются важным и широко используемым серверам, которым уже назначены статические IP-адреса. GlobalNames на удаленном сервере, вместо точки введите имя удаленного сервера.

Создание з оны GlobalNames

Следующий шаг а развертывании зоныGlobalNames состоит в создании зоны для DNS-сервера, служащегоконтроллером домена Windows Server 2008. Зона GlobalNames представляет собой не особый тип зоны, а всего лишь интегрированную в Active Directory зону прямого просмотра с именем GlobalNames. При создании зоны выберите репликацию данных зоны для всех DNS-серверов в лесу. Эта опциянаходится на странице Область репликации зоны, интегрированной в Active Directory (обеспечить возможность разрешения имен из одной метки, создайте и зоне G lobalNames запись псевдонима (CNAME ) ресурса. Имя, назначенноекаждой записи CNAME , представляет имя из одной метки, с помощью которого пользователи смогут подключаться к ресурсу. Отметим, что каждая запись CNAME указывает запись узла в еще одной зоне.

Система доменных имён - основа современного интернета. Люди не желают затруднять себя запоминанием набора цифр 63.245.217.105, а хотят чтобы по имени mozilla.org компьютер соединил их с указанным узлом. Этим и занимаются DNS-серверы: переводят запросы людей в понятный им цифровой формат. Однако в некоторых случаях может потребоваться обратное (reverse) преобразование IP-адрес → DNS-имя. О таких именах и пойдёт речь ниже.

Для чего нужно?

Наличие корректно настроенного rDNS адреса совершенно необходимо, чтобы отправлять сообщения с вашего собственного сервера корпоративной почты . Практически все почтовые серверы отвергнут приём сообщения ещё на стадии начала сессии, если у IP-адреса вашего сервера отсутствует запись в обратной зоне DNS. Причина отказа удалённым почтовым сервером будет, скорее всего, указана такой:
550-"IP address has no PTR (address to name) record in the DNS, or when the PTR record does not have a matching A (name to address) record. Pls check and correct your DNS record."

или
550-There"s no corresponding PTR for your IP address (IP-address), which is 550 required. Sorry, bye.

или просто
550 Your IP has no PTR Record

Число 550 во всех трёх случаях является стандартным кодом почтового SMTP сервера, сообщающего о критической ошибке, которая непреодолимо препятствует дальнейшей работе в рамках данной почтовой сессии. Надо сказать, что вообще все ошибки серии 500 являются критическими и продолжение передачи почты после их появления невозможно. Текст же поясняет причину отказа более подробно и сообщает, что администратор почтового сервера-получателя настроил его на проверку наличия у почтового сервера-отправителя записи в обратной зоне DNS (rDNS) и в случае её отсутствия сервер-получатель обязан отказывать отправителю в соединении (SMTP-ошибки серии 5XX).

Как настроить и использовать?

Правами на настройку обратной зоны DNS (reverse DNS) обладает лишь владелец соответствующего блока IP-адресов, которой эта зона соответствует. Как правило этим владельцем оказывается провайдер, владеющий собственной автономной системой. Подробнее о регистрации своей автономной системы (AS) и блока IP-адресов можно прочитать в этой статье . Если кратко, то оператору блока IP-адресов для регистрации обратной зоны DNS необходимо зарегистрировать в своём личном кабинете на сайте RIPE объект типа «domain», указать адрес DNS-серверов, которые будут поддерживать зону rDNS и настроить поддержку зоны вида 3.2.1.in-addr.arpa на них. За ресурсы в обратной зоне отвечает указатель (pointer) - запись типа PTR. К ней-то и идут запросы о разрешении IP-адреса в имя хоста.

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

Примеры хороших имён для сервера почты:

mail.domain.ru
mta.domain.ru
mx.domain.ru

Примеры плохих имён:

host-192-168-0-1.domain.ru
customer192-168-0-1.domain.ru
vpn-dailup-xdsl-clients.domain.ru

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

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

  • так для почтового сервера Postfix необходимо включить опцию
    reject_unknown_client
  • в другом популярном почтовом сервере Exim
    verify = reverse_host_lookup
  • MS Exchange Server
    В оснастке Exgange Server перейти в раздел Servers далее выбрать сервер в развернутом списке, выбрать Protocols, далее протокол SMTP, в правом окне выделить SMTP сервер и по клику правой клавишей мыши выбрать из списка Properties. Далее закладка Delivery → Perform reverse DNS lookup on incoming messages
  • Теперь все сообщения с IP-адресов не имеющих обратной записи в DNS (записей типа PTR) будут отвергаться, поток спама, значительно сократится. Пожалуй, это самый простой, действенный и наименее ресурсоёмкий из всех методов фильтрации спама: проверкой reverse DNS отсекается подавляющее большинство спама, рассылаемого с заражённых компьютеров обычных пользователей, составляющих ботнеты спамеров.


    При перепубликации статьи установка активной индексируемой гиперссылки на источник - сайт сайт обязательна!

    Прямой просмотр нужен для разрешения доменных имен в ІР-адреса, обратный просмотр – для разрешения ІР-адресов в доменные имена.

    В каждом сегменте сети должна быть зона обратного просмотра. В частности, если у вас есть подсети 192.168.10.0, 192.168.11.0 и 192.168.12.0, у вас должно быть три зоны обратного просмотра.

    Стандартное имя зоны обратного просмотра составляется из идентификатора сети, выстроенного в обратном порядке, и суффикса in-addr.arpa. Зоны обратного просмотра из предыдущего примера будут называться 10.168.192. in-addr.arpa, 11.168.192.in-addr.arpa и 12.168.192.in-addr.arpa. Записи зон обратного и прямого просмотра должны быть синхронизированы. В случае сбоя синхронизации в домене может произойти сбой проверки подлинности.

    Чтобы создать зону обратного просмотра, выполните следующие действия:

    1. Откройте, консоль Диспетчер DNS (DNS Manager) и подключитесь к нужному серверу.

    2. Щелкните правой кнопкой элемент сервера и выберите команду Создать новую зону (New Zone). Откроется Мастер создания новой зоны (New-Zone Wizard). Щелкните Далее (Next).

    3. Если вы настраиваете основной сервер, интегрированный с Active Directory, установите переключатель Основная зона (Primary Zone) и убедитесь, что установлен флажок . Если вы не хотите интегрировать DNS в Active Directory, установите переключатель Основная зона (Primary Zone) и сбросьте флажок Сохранять зону в Active Directory (Store The Zone In Active Directory) . Щелкните Далее (Next).

    4. Если вы настраиваете зону обратного просмотра для дополнительного сервера, установите переключатель Дополнительная зона (Secondary Zone) и щелкните Далее (Next).

    5. Если вы интегрируете зону с Active Directory, выберите одну из следующих стратегий репликации:

    Для всех DNS-серверов в этом лесу (То All DNS Servers In This Forest) Это обширнейшая стратегия репликации. Помните, что лес Active Directory включает все деревья доменов, использующие данные каталога совместно с текущим доменом.

    Для всех DNS-серверов в этом домене (То All DNS Servers In This Domain) Выберите эту стратегию, чтобы реплицировать информацию DNS внутри текущего домена и его дочерних доменов.

    Для всех контроллеров домена в этом домене (То All Domain Controllers In This Domain) Выберите эту стратегию, если хотите реплицировать информацию DNS на все контроллеры домена внутри текущего домена и его дочерних доменов. Хотя эта стратегия обеспечивает более широкую репликацию информации DNS внутри домена, не каждый контроллер домена является DNS-сервером (вам и не нужно настраивать каждый контроллер домена как DNS-сервер).

    6. Установите переключатель Зона обратного просмотра (Reverse Lookup Zone) . Щелкните Далее (Next).

    7. Укажите, для каких адресов вы хотите создать зону обратного просмотра (IPv4 или IPv6) и щелкните Далее (Next) . Выполните одно из следующих действий:

    Если вы проводите настройку для IPv4, введите идентификатор сети для зоны обратного просмотра. Вводимые значения определяют стандартное имя зоны обратного просмотра. Щелкните Далее (Next).

    Если вы проводите настройку для IPv6, введите префикс сети для зоны обратного просмотра. Имена зон автоматически генерируются на основе вводимых значений. В зависимости от введенного префикса вы можете создать до восьми зон. Щелкните Далее (Next).

    8. Если вы настраиваете основной или дополнительный сервер, не интегрированный в Active Directory, задайте имя файла зоны. Стандартное имя файла для БД зоны DNS должно быть уже введено. Оставьте его неизменным или введите новое имя. Щелкните Далее (Next).

    9. Укажите, следует ли разрешить динамические обновления. У вас есть три возможности:

    Разрешить только безопасные динамические обновления (Allow Only Secure Dynamic Updates) Если зона интегрирована в Active Directory, вы можете воспользоваться списками ACL, чтобы ограничить круг клиентов, которые могут выполнять динамические обновления. Если вы установите этот переключатель, динамически обновлять записи ресурсов смогут только клиенты с учетными записями компьютеров, прошедшими проверку, и одобренными ACL.

    Разрешить любые динамические обновления (Allow Both Nonsecure And Secure Dynamic Updates) Установите этот переключатель, чтобы позволить любому клиенту обновлять его записи ресурса в DNS при наличии изменений.

    Запретить динамические обновления (Do Not Allow Dynamic Updates) Этот переключатель отключает динамические обновления DNS. Его следует использовать только при отсутствии интеграции зоны с Active Directory.

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

    Для правильной работы почтового сервера важно иметь правильно настроенную зону. Настройка DNS зоны относится к подготовительным операциям перед развертыванием почтового сервера и от нее непосредственно зависит работоспособность системы электронной почты.

    Неправильные настройки способны привести к тому, что почту будет невозможно доставить вашему почтовому серверу или сервера получателей будут отклонять вашу почту. Действительно, если записи вашей зоны не содержат сведений о почтовом сервере, куда должна отправляться почта? На деревню дедушке? Можно, конечно, попросить настроить DNS зону вашего провайдера, но лучше сделать это самим.

    Что нам понадобиться? Выделенный IP адрес (допустим 11.22.33.44), который вы должны получить у своего провайдера. Доменное имя (например example.com), его можно зарегистрировать у любого регистратора или их партнера. При регистрации у партнера уточняйте, предоставляет ли он доступ к управлению DNS зоной, иначе придется потратить дополнительное время, нервы и деньги на перенос домена к регистратору.

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

    Итак, домен у нас есть. Какие записи содержит его DNS зона? Во первых это SOA запись - описание зоны. Мы не будем подробно разбирать все записи, это выходит за рамки нашей статьи, но иметь общее представление о них необходимо. Также должны быть две NS записи, указывающие на сервера имен (DNS сервера) обслуживающие данный домен, это будут сервера регистратора или хостинг провайдера.

    Первой записью, которую необходимо добавить будет A запись или запись имени. Она должна указывать на IP-адрес вашего сервера, если вы решите обслуживать все запросы к домену у себя или на IP адрес хостинг провайдера, если решите разместить свой сайт на хостинге. При размещении сайта у хостера домен обычно делегируется на его DNS сервера (прописываются соответствующие NS записи) и A запись будет сделана автоматически при парковке домена.

    Чаще всего встречается этот вариант, но при необходимости вы всегда сможете создать A запись сами. Данная запись имеет вид:

    example.com. IN A 22.11.33.44

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

    Для работы почтового сервера нужно создать MX запись, которая должна указывать на наш почтовый сервер. Для этого создадим запись:

    example.com. IN MX 10 mail.example.com.

    Также можно написать просто:

    example.com. IN MX 10 mail

    К такому имени (без точки на конце) example.com будет добавлено автоматически. Цифра 10 определяет приоритет сервера, чем она меньше, тем выше приоритет. Кстати, DNS зона уже может содержать MX запись вида:

    example.com. IN MX 0 example.com.

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

    Теперь создадим A запись для mail.example.com

    mail.example.com. IN A 11.22.33.44

    Теперь вся почта для домена example.com будет направляться хосту mail имеющему адрес 11.22.33.44, т.е. вашему почтовому серверу, в то-же время сайт example.com продолжит работать на сервере провайдера по адресу 22.11.33.44.
    Может возникнуть вопрос, а почему нельзя сразу указать в MX записи IP адрес почтового сервера? В принципе можно, некоторые так и делают, но это не соответствует спецификациям DNS.

    Также можно сделать алиасы для почтового сервера типа pop.example.ru и smtp.example.ru . Зачем это надо? Это позволит клиенту не зависеть от особенностей вашей инфраструктуры, один раз прописав настройки. Допустим, что ваша компания разрослась и выделила для обслуживания внешних клиентов отдельный почтовый сервер mail1 , все что вам понадобиться, это изменить две DNS записи, клиенты и не заметят того, что работают с новым сервером. Для создания алиасов используются записи типа CNAME:

    Pop IN CNAME mail.example.com.
    smtp IN CNAME mail.example.com.

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

    44.33.22.11.in-addr.arpa. IN PTR mail.example.com.

    Немного странный вид, не правда ли? Разберем структуру PTR записи более подробно. Для обратного преобразования имен используется специальный домен верхнего уровня in-addr.arpa. Это сделано для того, чтобы использовать для прямого и обратного преобразования имен одни и те же программные механизмы. Дело в том, что мнемонические имена пишутся слева направо, а IP адреса справа налево. Так mail.example.com. означает что хост mail находится в домене example, который находится в домене верхнего уровня com., 11.22.33.44 означает что хост 44 находится в подсети 33, которая входит в подсеть 22, принадлежащую сети 11. Для сохранения единого порядка PTR записи содержат IP адрес "задом наперед" дополненный доменом верхнего уровня in-addr.arpa.

    Проверить MX и PTR записи также можно командой nslookup используя дополнительный параметр -type=MX или -type=PTR

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

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

    Обратный запрос DNS - особая доменная зона, предназначенная для определения имени узла по его IPv4-адресу c помощью PTR-записи. Адрес узла AAA.BBB.CCC.DDD переводится в обратной нотации и превращается в DDD.CCC.BBB.AAA.in-addr.arpa. Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP-адресов . Для этого в записях авторитетного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC.000/24) отвечает отдельный сервер.

    PTR-запись (от англ. pointer – указатель) связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в обратной форме вернёт имя данного хоста. Например, (на момент написания), для IP адреса 192.0.34.164: запрос записи PTR 164.34.0.192.in-addr.arpa вернет его каноническое имя referrals.icann.org.in-addr.arpa

    in-addr.arpa - специальная доменная зона, предназначенная для определения имени хоста по его IPv4-адресу, используя PTR-запись. Адрес хоста AAA.BBB.CCC.DDD транслируется в обратной нотации и превращается в DDD.CCC.BBB.AAA.in-addr.arpa. Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP адресов. Для этого в записях авторитативного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC/24) отвечает отдельный сервер.

    Использование

    В целях уменьшения объёма нежелательной почтовой корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.



    Есть вопросы?

    Сообщить об опечатке

    Текст, который будет отправлен нашим редакторам: