Как определяется состав обратных зон dns сервера в корпоративной сети

Обновлено: 07.07.2024

В данном материале мы рассмотрим конфигурацию программы named при организации сервера домена, чьи хосты распределены по двум физическим IP-сетям класса C (в нотации CIDR x.x.x.x/24). Основное внимание будет уделено "обратным" зонам, т.к. "прямая" зона в этом случае не имеет существенных отличий от зоны, рассмотренной при описании небольшого корпоративного домена.

Ситуация, рассматриваемая в данном случае, характерна для организаций, которые имеют более одной сети класса C, где необходимо развернуть корпоративный домен. Если быть более точным, то речь идет не только о сетях класса C.

Предположим, что адресные пулы, которые выделены организации и ее подразделениям, представляют из себя не единое адресное пространство, а нарезку из нескольких блоков адресов. При этом эти блоки нарезаны таким образом, что адреса оказываются из разных областей, если рассматривать адресное пространство с точки зрения нотации CIDR х.х.х.х/24. Например:

192.168.0.0/24 и 192.168.10.0/24

С точки зрения описания соответствия между доменным именем и IP-адресом в "прямой" зоне здесь проблем нет:

Из примера видно, что адресные записи могут прекрасно "перемешиваться" в описании зоны. Таким образом, прямую зону можно определить на любом множестве наборов адресов, которые могут быть, как угодно разбросаны по адресному пространству.

Конечно, есть адреса, которые нельзя мешать. Например, нельзя мешать маршрутизируемые и немаршрутизируемые адреса. Собственно, в примере мы используем именно последние (подробнее о немаршрутизируемых адресах см. RFC 1918).

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

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

И так, в "прямой" зоне мы можем "мешать" адреса, но вот как поддерживать обратные соответствия? Ведь в случае "обратных" зон мы имеем дело тоже с доменными именами, хотя они и образованы инверсией IP-адресов. Разделителем в иерархии именования доменов является символ ".", следовательно, границы байтов в адресе будут соответствовать границам вложенности доменов.

Выход простой - создать две обратных зоны 0.168.192.in-addr.arpa и 10.168.192.in-addr.arpa. Выглядеть это будет примерно так:

И для 0.168.192.in-addr.arpa. соответственно:

На master сервере должно быть объявлено две "обратных" зоны. В BIND 4.x в файле named.boot это будет выглядеть примерно так:

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

Здесь стоит только пояснить, что в данном случае адрес 192.168.20.1 - это адрес slave сервера, которому разрешено копировать зону. Назначение остальных директив управления подробно рассмотрено в "Небольшой корпоративный домен в домене ru. Описание "прямых" зон. Описание "обратных" зон. Настройки BIND.".

Что же касается файла named.conf версий BIND 8.х и 9.х, то его содержание будет выглядеть примерно так:

options directory "/etc/namedb";
allow-query ;
recursion no;
fake-iquery yes;
fetch-glue no;
use-id-pool yes;
>;
//Root server hints
zone "." < type hint; file "named.root"; >;
// Forward Loopback
zone "localhost" type master;
file "localhost";
>;
// Reverse Loopback
zone "0.0.127.in-addr.arpa" type master;
file "localhosr.rev";
>;
// Corporative domain
zone "test.ru" type master;
file "test.ru";
allow-transfer < 192.168.20.1; >;
>;
// Reverse corporative domain
zone "0.168.192.in-addr.arpa" type master;
file "0.168.192.in-addr.arpa";
allow-transfer < 192.168.20.1; >;
>;
// Reverse corporative domain
zone "10.168.192.in-addr.arpa" type master;
file "10.168.192.in-addr.arpa";
allow-transfer < 192.168.20.1; >;
>;

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

Здесь следует отметить, что несколько обратных зон появляются, например, и для сетей типа x.x.x.x/23. Вся штука в том, что, адресный пул, например, 192.168.0.0.23, объединяет два смежных блока 192.168.0.0/24 и 192.168.1.0/24. Соответствующих обратных зон, следовательно, будет две: 0.168.192.in-addr.arpa и 1.168.192.in-addr.arpa. Объединить их стандартным образом можно только на уровне 168.192.in-addr.arpa, но никак не ниже.

Из выше сказанного, следует, что владелец зоны 168.192.in-addr.arpa должен делегировать ответственность за управления двумя обратными зонами своему клиенту, если не хочет управлять ими самостоятельно.

Аналогичные замечания справедливы и для адресных пулов x.x.x.x/16 и для адресных пулов x.x.x.x.8, т.е. сетей классов B и A соответственно. Пространство доменных имен "обратных" зон построено с учетом старой классификации адресов, в то время, когда нотация CIDR широко еще не использовалась.

В документе RFC 1519 подробно разбирается отображение адресного пространства CIDR на "суперсети" сетей класса C, т.е. пулов адресов, которые составлены из подсетей сетей класса B и A. Провайдер в этом случае должен делегировать соответствующие обратные зоны клиентам, а те обеспечить их поддержку способом, похожим на случай 192.168.0.0/23, рассмотренный выше.

В этой статье приводятся общие сведения о работе обратной службы DNS и сценарии, для которых обратная служба DNS поддерживается в Azure.

Что такое обратная зона DNS

Принцип работы обратной зоны DNS

При назначении организации блока IP-адресов она получает права на управление соответствующей зоной ARPA. Корпорация Майкрософт размещает зоны ARPA, соответствующие блокам IP-адресов, используемым Azure, а также управляет ими. Поставщик услуг Интернета может предоставить зону ARPA для IP-адресов, которыми вы владеете. Кроме того, вам может быть разрешено разместить зону ARPА в службе DNS, например в Azure DNS.

Имя зоны обратного просмотра IPv4 должно быть представлено в формате <IPv4 network prefix in reverse order>.in-addr.arpa .

Предположим, вы создаете обратную зону для записей узлов с IP-адресами в префиксе 192.0.2.0/24. Чтобы создать имя зоны, вам нужно отделить сетевой префикс адреса (192.0.2), записать его в обратном порядке (2.0.192) и добавить суффикс .in-addr.arpa .

Класс подсети	Сетевой префикс	Обратный сетевой префикс	Стандартный суффикс	Имя обратной зоны
Класс A	203.0.0.0/8	203	.in-addr.arpa	203.in-addr.arpa
Класс B	198.51.0.0/16	51.198	.in-addr.arpa	51.198.in-addr.arpa
Класс C	192.0.2.0/24	2.0.192	.in-addr.arpa	2.0.192.in-addr.arpa

Бесклассовое делегирование IPv4

Иногда диапазон IP-адресов, выделенных для организации, меньше диапазона класса C (/24). В таком случае диапазон IP-адресов не попадает в границы зоны в иерархии зоны .in-addr.arpa и не может быть делегирован как дочерняя зона.

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

Предположим, поставщик услуг Интернета предоставил организации диапазон IP-адресов 192.0.2.128/26. В него входят 64 IP-адреса — с 192.0.2.128 по 192.0.2.191. Обратная служба DNS для этого диапазона реализуется следующим образом:

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

После этого организация управляет отдельными записями типа PTR в дочерней зоне.

При обратном просмотре IP-адреса "192.0.2.129" отправляется запрос на запись типа PTR с именем "129.2.0.192.in-addr.arpa". Этот запрос поступает через CNAME в родительской зоне в запись типа PTR в дочерней зоне.

Имя зоны обратного просмотра IPv6 должно быть представлено в формате <IPv6 network prefix in reverse order>.ip6.arpa

Например, при создании зоны обратных записей узлов для узлов с IP-адресами, которые находятся в префиксе 2001:db8:1000:abdc::/64. Имя зоны создается путем изоляции префикса сети адреса (2001:db8:abdc::). Далее нужно развернуть сетевой префикс IPv6, удалив сжатие за счет нулей (если оно использовалось для сокращения префикса адреса IPv6 (2001:0db8:abdc:0000::)). Запишите префикс в обратном порядке, используя точку как разделитель между каждым шестнадцатеричным числом, чтобы сформировать обратный сетевой префикс ( 0.0.0.0.c.d.b.a.8.b.d.0.1.0.0.2 ), и добавьте суффикс .ip6.arpa .

Сетевой префикс	Развернутый обратный сетевой префикс	Стандартный суффикс	Имя обратной зоны
2001:db8:abdc::/64	0.0.0.0.c.d.b.a.8.b.d.0.1.0.0.2	.ip6.arpa	0.0.0.0.c.d.b.a.8.b.d.0.1.0.0.2.ip6.arpa
2001:db8:1000:9102::/64	2.0.1.9.0.0.0.1.8.b.d.0.1.0.0.2	.ip6.arpa	2.0.1.9.0.0.0.1.8.b.d.0.1.0.0.2.ip6.arpa

Поддержка обратной зоны DNS в Azure

Azure поддерживает два отдельных сценария, касающихся обратной зоны DNS:

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

Настройка обратной записи DNS для IP-адреса, назначенного службе Azure. Azure позволяет настроить обратный поиск IP-адресов, предоставленных службе Azure. Служба Azure настраивает обратный поиск как запись типа PTR в соответствующей зоне ARPA. Эти зоны ARPA, соответствующие всем используемым в Azure диапазонам IP-адресов, размещаются корпорацией Майкрософт.

На любом компьютере, где запущен сервер имен named, обязательно должен присутствовать файл , описывающий обратную зону самого компьютера (т.е. соответствие имени localhost адресу 127.0.0.1). Этот файл часто носит имя localhost . rev или 127.0.0. Естественно, этот файл описания локальной обратной зоны обязан быть упомянут в конфигурации сервера имен named.conf :

Файл обратной зоны не обязательно является копией файла прямой зоны с "переставленными" столбцами, поскольку в одном домене могут присутствовать компьютеры из разных IP-сетей, а одна IP- сеть может объединять компьютеры из разных доменов.

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

Еще раз отметим, что выделение IP-сети не обеспечивает автоматического делегирования соответствующей обратной зоны. Чтобы получить право администрирования обратной зоны сети, адреса из которой назначены вашим компьютерам, следует написать заявку о делегировании обратной зоны по стандартной форме. Имеет смысл проконсультироваться у своего провайдера, как это сделать, или просто заказать ему выполнение этой работы.

Имя обратной зоны всегда пишется как адрес IP-сети "наоборот", а за ним добавляется суффикс in -addr. arpa . Такая " запись наоборот" была введена с учетом иерархической структуры DNS : левая часть имени обозначает компьютер , правая - домен. В случае с IP-адресами все наоборот. В адресе номер сети идет слева, а номер компьютера в сети - справа. Для встраивания в DNS это не годилось, и адреса сетей "подогнали" под стандарт DNS .

Рассмотрим в качестве примера файл обратной зоны сети 192.177.16/24:

Один компьютер может иметь несколько IP-адресов (принадлежащих одному или - чаще - нескольким сетевым интерфейсам). Один IP- адрес может соответствовать нескольким именам компьютера, потому что компьютер может иметь несколько имен.

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

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

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

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

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

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

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

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

Частые вопросы

PTR-запись для почтового сервера — какую указать?

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

Как создать PTR-запись?

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

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

Добавить обратную DNS-зону можно в меню Сеть > DNS > Зоны. Для этого выполните следующие действия:

адрес зоны — вводится в формате CCC.BBB.AAA. Это первые три октета подсети AAA.BBB.CCC.DDD/24 (в обратном порядке), в которой располагается домен;
DNS-сервер — имя сервера, который отвечает за данную зону (соответствующая NS-запись появится в списке записей зоны автоматически);
e-mail администратора — почтовый адрес администратора, который отвечает за данную зону;
TTL — допустимое время хранения данной ресурсной записи в кеше неответственного DNS-сервера (в секундах);
обновление — временной интервал, через который вторичный сервер будет проверять необходимость обновления информации (в секундах);
повторение попытки — временной интервал, через который вторичный сервер будет повторять обращения при неудаче (в секундах);
устаревание — временной интервал, через который вторичный сервер будет считать имеющуюся у него информацию устаревшей (в секундах);
отрицательное TTL — значение времени жизни информации на кеширующих серверах (TTL в последующих записях ресурсов).

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

Читайте также: