No Image

Dns прямая и обратная зона

СОДЕРЖАНИЕ
3 647 просмотров
10 марта 2020

Что такое обратная зона в DNS. Что такое PTR запись.

Что такое обратная зона в DNS. Что такое PTR запись.

Добрый день, уважаемые читатели и постоянные подписчики, IT блога Pyatilistnik.org. В прошлый раз мы разобрали, что такое 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 сессии.

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

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

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

192.168.0.0/24 и 192.168.10.0/24

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

Читайте также:  Как отформатировать диск в fat

$ORIGIN ru.
test IN SOA ns.test.ru. hostmaster.test.ru (
233 3600 300 9999999 3600 )
;
IN NS ns.test.ru.
IN NS ns.privider.ru.
IN A 192.168.10.1
IN MX 10 mail.test.ru.
IN MX 20 mail.provider.ru.
;
ns IN A 192.168.10.1
mail IN A 192.168.0.1
www IN A 192.168.10.2
ftp IN A 192.168.0.2

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

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

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

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

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

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

$TTL 3600
$ORIGIN 168.192.in-addr.arpa.
10 IN SOA ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600 )
IN NS ns.test.ru.
IN NS ns.privider.ru.
1 IN PTR ns.test.ru.
2 IN PTR www.test.ru.

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

$TTL 3600
$ORIGIN 168.192.in-addr.arpa.
0 IN SOA ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600 )
IN NS ns.test.ru.
IN NS ns.privider.ru.
1 IN PTR ns.test.ru.
2 IN PTR www.test.ru.

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

directory /etc/namedb
primary test.ru test.ru
primary localhost localhost
primary 127.in-addr.arpa localhost.rev
primary 10.168.192.in-addr.arpa 10.168.192.in-addr.arpa
primary 0.168.192.in-addr.arpa 0.168.192.in-addr.arpa
xfrnets 192.168.20.1&255.255.255.255
cаche . named.root
options no-recursion no-fetch-glue fake-iquery

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

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

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

Читайте также:  Пропал звук на ноутбуке prestigio

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, рассмотренный выше.

Зоной (zone) в DNS называется часть пространства имен DNS, за управление которой от­вечает определенный сервер или группа серверов DNS. Она является в DNS основным ме­ханизмом для делегирования полномочий и применяется для установки границ, в пределах которых определенному серверу разрешено выполнять запросы. Любой сервер, который обслуживает какую-то определенную зону, считается полномочным или ответственным за эту зону; исключением являются разве что зоны-заглушки.

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

Читайте также:  Готика 3 забытые боги

Сервер, на котором устанавливается DNS, но не конфигурируется ни одна зона, называ­ется только кэширующим (caching-only) сервером. Установка такого сервера может быть выгодной в некоторых сценариях с дочерними офисами, поскольку помогает сократить объем трафика клиентских запросов по сети и устранить необходимость в репликации целых зон DNS в удаленные места.

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

Зоны прямого просмотра (forward lookup zone), как не трудно догадаться по их названию, создаются для выполнения прямого просмотра в базе данных DNS. Другими словами, зоны этого типа предусматривают реализацию преобразования имен в IP-адреса и предоставле­ние информации о ресурсах. Например, если пользователь пожелает обратиться к серверу del.company.com и запросит его IP-адрес в зоне прямого просмотра, DNS возвратит ему значение 172.16.1.11, т.е. IP-адрес данного ресурса.

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

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

Зоны обратного просмотра (reverse lookup zone) выполняют прямо противоположную операцию той, что выполняют зоны прямого просмотра. Они предусматривают сопостав­ление IP-адресов с обычным именем. Эта похоже на поиск телефонного номера, когда сам номер известен, а имя того, кому он принадлежит, нет. Зоны обратного просмотра обычно создаются вручную и вовсе необязательно присутствуют в каждой реализации. За счет при­менения мастера настройки сервера DNS (Configure a DNS Server), как описывалось ранее в главе, процесс создания такой зоны может быть автоматизирован. Как правило, зоны обратного просмотра заполняются записями PTR, которые служат для указания запросу обратного просмотра на соответствующее имя.

  • Вторичные зоны DNS для особого преобразования именВ некоторых ситуациях в Active Directory.

">Вторичные зоны в среде AD DS – 25/01/2013 04:36
Встроенные в каталог зоны DNSНаиболее важным изменением в реализации DNS в Windows 2000 Server.

">Зоны интегрированные в Active Directory – 24/01/2013 04:18
Первичные зоны В традиционной DNS (не интегрированной в Active Directory) какой-то один сервер.

  • Копирование базы данных DNSКопирование базы данных DNS с одного сервера на другой производится с.

">Выполнение переносов зон DNS – 22/01/2013 04:31
Концепция зон-заглушекКонцепция зон-заглушек является уникальной и встречается только в DNS.

">Создание зоны заглушки DNS – 22/01/2013 04:29
Первичные зоны В традиционной DNS (не интегрированной в Active Directory) какой-то один сервер.

  • Ключевые записи ресурсовВ иерархии DNS объекты идентифицируются за счет применения так называемых.

">Записи ресурсов DNS – 22/01/2013 04:16
Конфигурирование DNS-сервера для указания на самого себя Одной из дополнительных задач, которая.

">Дополнительное конфигурирование DNS – 21/01/2013 05:53
Установка DNS с помощью мастера добавления ролейХотя существует несколько различных способов для.

Комментировать
3 647 просмотров
Комментариев нет, будьте первым кто его оставит

Это интересно
Adblock
detector