Что такое обратная зона в DNS. Что такое PTR запись. Обратные доменные имена (reverse DNS) и их место в работе почтового сервера
Добрый день, уважаемые читатели и постоянные подписчики, 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 сессии.
В данном материале мы рассмотрим конфигурацию программы named при организации сервера домена, чьи хосты распределены по двум физическим IP-сетям класса C (в нотации CIDR x.x.x.x/24). Основное внимание будет уделено "обратным" зонам, т.к. "прямая" зона в этом случае не имеет существенных отличий от зоны, рассмотренной при описании небольшого корпоративного домена.
Ситуация, рассматриваемая в данном случае, характерна для организаций, которые имеют более одной сети класса C, где необходимо развернуть корпоративный домен. Если быть более точным, то речь идет не только о сетях класса C.
Предположим, что адресные пулы, которые выделены организации и ее подразделениям, представляют из себя не единое адресное пространство, а нарезку из нескольких блоков адресов. При этом эти блоки нарезаны таким образом, что адреса оказываются из разных областей, если рассматривать адресное пространство с точки зрения нотации CIDR х.х.х.х/24. Например:
192.168.0.0/24 и 192.168.10.0/24
С точки зрения описания соответствия между доменным именем и IP-адресом в "прямой" зоне здесь проблем нет:
$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
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.х, то его содержание будет выглядеть примерно так:
options {
directory "/etc/namedb";
allow-query {any;};
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";
};
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 и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.
- P. Mockapetris. RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. ISI, 1987. (
Термины DNS
DNS (Domain Name System, система доменных имен) - это служба разрешения имен в сетях на основе протокола TCP/IP.
Зоны DNS
Зона DNS - это часть пространства имен, для которого DNS-сервер может выполнять операции разрешения имен. Существуют зоны прямого и обратного просмотра, которые на практике для удобства называют прямой и обратной зонами.
Прямая зона позволяет по имени системы получать ее IP-адрес, обратная - по IP-адресу "выдает" информацию об имени хоста. Поэтому если нужно по имени компьютера узнать его адрес, то говорят о прямом разрешении имени. Если по IP-адресу хотят получить имя компьютера, то в этом случае происходит обратное разрешение имени. Строго говоря, если в DNS зарегистрировано прямое разрешение имени, то должно быть зарегистрировано и обратное.
Отсутствие обратного разрешения имени является достаточно частой ошибкой в Интернете. Обычно владельцами прямой зоны данного домена и обратной зоны, которая соответствует этому имени, являются разные люди (организации), поэтому в процессе регистрации новых DNS-записей часто забывают создать соответствующую запись обратной зоны.
Фактически прямые зоны соответствуют доменам некоторого уровня. Например, зона ask.ru позволяет разрешить все запросы имен, относящихся к домену ask.ru.
Для разрешения обратных имен в домене самого верхнего уровня создана зона in-addr.arpa. Названия зон обратного просмотра формируются добавлением к этому имени слева имени трех октетов адреса сети в обратном порядке. Например, для сети 195.161.192.0/24 имя обратной зоны будет 192.161.195.in-addr.arpa.
В большинстве случаев отсутствие регистрации в обратной зоне не мешает нормальной работе в Сети. Однако оно может и привести к ошибкам в тех случаях, когда необходимо установить по IP-адресу имя сервера. Например, при обмене почтовыми сообщениями в настоящее время принято проверять принадлежность сервера к тому домену, от имени которого он передает почту. Если обратное разрешение имени не будет проведено, то система может получить отказ в приеме почты.
Первичная и вторичная зоны
У создаваемых записей DNS должен быть один "хозяин". Чтобы все записи были корректны, их необходимо вносить на одном DNS-сервере. В этом случае говорят, что на таком DNS-сервере расположена первичная зона. Для отказоустойчивости на других серверах можно создать копии этой зоны: такие зоны будут называться вторичными зонами. Вторичная зона содержит те же записи, что и первичная, но в нее нельзя вносить изменения или добавлять новые записи. Эти операции можно делать только для первичной зоны.
Серверы имен зоны
Для каждой первичной зоны можно создать сколько угодно копий на других серверах. Обычно в настройках DNS-серверов предусматриваются специальные механизмы оповещений, которые обеспечивают синхронность записей первичной зоны и ее копий на вторичных серверах. Но, если это не запрещено настройками DNS-сервера, вы можете создать на своем сервере вторичную зону, обновления которой будут производиться по некоему графику. В результате записи такой копии могут оказаться неактуальны. Поэтому принято для домена определять серверы имен, информация которых "официальна". Такие серверы называют NS-записями соответствующего домена. Обычно для каждого домена создается два или три NS-сервера. Если ответ на запрос разрешения имени получен от NS-сервера, то он считается авторизованным, другие серверы возвращают неавторизованные ответы.
Это не значит, что в этом случае возвращаются неверные данные. DNS-сервер разрешит запрос клиента на основании данных своей копии только в том случае, если эти данные не устарели. Но если срок жизни записей на сервере имен был установлен, например, равным неделе, то в случае внесения изменений в первичную зону необходимо быть готовым к тому, что еще до недели после смены информации на NS-сервере другие серверы DNS могут возвращать ста В случае домена Windows 2000 и использования зоны DNS. интегрированной со службой каталогов, изменения можно вносить на любом DNS-сервере такой зоны.
Верные значения
То есть вы столкнетесь с ситуацией, когда часть систем уже получила правильные данные об имени, а часть - нет. Поэтому перед предполагаемой сменой записей DNS необходимо уменьшить время их жизни и выждать период, равный старому времени жизни. Это позволит сократить период такой неопределенности в разрешении имен. После выполнения операции настройки следует вернуться к старым величинам, чтобы снизить нагрузку на сеть и DNS-серверы. Если вы предполагаете, что копия DNS-записей на сервере DNS неактуальна, то следует выполнить операцию очистки кэша для соответствующей зоны. Для этого необходимо в консоли управления сервером включить опцию отображения дополнительных параметров, найти нужную зону среди структуры кэша и выполнить для нее очистку. При следующем запросе данных из этой зоны сервер загрузит копию с того сервера DNS, на который настроена пересылка запросов. Поэтому и эта операция также не гарантирует получение актуальной копии записей. При рассмотрении проблемных ситуаций следует выяснить на официальных ресурсах адреса NS-серверов данного домена и проверить записи с помощью утилиты nslookup , подключаясь к соответствующему NS-серверу.
Для обновления записей DNS на клиентских компьютерах следует очистить кэш DNS-записей (ipconfig /flushdns).
Передача зон
Так называется специальная операция копирования всех записей данной зоны с одного DNS-сервера на другой. По соображениям безопасности передача зон обычно разрешается только на заранее определенный администратором системы список IP-адресов DNS-серверов. Если операция передачи зоны запрещена, то вы не сможете создать на своем DNS-сервере вторичную зону для данного домена.
Делегирование зон
Если на DSN-сервере создана, например, прямая зона для домена test.local , то запись о домене третьего уровня level3.test.local должна содержаться на этом же сервере. Если географически домен level3.test.local удален от основного домена, то поддержание записей в его зоне на DNS-сервере становится не очень удобным. Проще поручить администратору этого домена вносить изменения в DNS-записи самостоятельно, для чего используется процесс делегирования зоны. При делегировании зоны DNS-сервер создает у себя запись, указывающую, что запросы разрешения имени для этой зоны должны перенаправляться на другой DNS-сервер, на который произведено делегирование зоны.
Stub-зона (зона-заглушка)
При делегировании зоны на исходном сервере сохраняется информация о MS-сервере делегированной зоны. Поскольку администратор делегированной зоны может изменять ее DNS-записи, то он может сменить и записи NS-сервера. Если соответствующее изменение не будет внесено на сервер,который осуществляет делегирование, то процесс разрешения имен будет нарушен (основной сервер попрежнему будет отправлять запросы на уже не существующий адрес, и в результате будет формироваться неверный ответ). Для исправления подобной ситуации в DNS-сервере Windows Server 2003 введены stub-зоны. При создании stub-зоны в ней определяются NS-записи делегированной зоны. Причем если администратор делегированной зоны меняет эти записи, то соответствующие изменения вносятся и в записи stub-зоны. В результате гарантируется целостность процесса разрешения имен.
Зона "точка"
Домен самого верхнего уровня, как уже писалось, принято называть именем "точка". Если в DNS создать зону "точка", то это будет фактически означать, что данный сервер является корневым в структуре DNS, т. е. он должен разрешать самостоятельно любые запросы имен. Если этот DNS-сервер не может разрешить имя, то его ответ будет гласить, что такого хоста не существует.
При необходимости пересылки запросов DNS на другие серверы зону "точка" следует удалить, после чего появится возможность настройки пересылки запросов DNS.
Типы запросов
Для разрешения имен в DNS предусмотрено два типа запросов: итеративный и рекурсивный. Итеративный запрос служит для получения от DNS-сервера, которому он направлен, наилучшего ответа, который может быть получен без обращения к другим DNS-серверам. Рекурсивный запрос предполагает, что сервер DNS должен выполнить все операции для разрешения имени. Обычно для Зона с таким именем создается при установке службы каталогов с одновременной установкой к настройкой сервера DNS.
Порядок разрешения имен в DNS
Последовательность разрешения DNS-имен. Процесс определения имени с использованием итеративных запросов весьма трудоемок. Нужно найти NS-сервер для данного домена и затем запросить от него данные по требуемому имени. Обычно клиенты все эти операции "возлагают" на DNS-серверы, отправляя им рекурсивный запрос. DNS-сервер после получения рекурсивного запроса просматривает собственный кэш имен. Если он находит нужную запись и она еще не устарела, то это значение возвращается клиенту. Если записи нет, то сервер предпринимает попытку поиска сервера имен для домена, содержащегося в запросе. Чтобы найти такой сервер, запрос всегда отправляется на корневой сервер, от него получают информацию по домену первого уровня, запросом на домен первого уровня получают информацию о NS-серверах домена второго уровня и т. д. После этого отправляется итерактивный запрос на NS-сервер соответствующего домена. Естественно, что большинство информации от корневых доменов уже кэшировано на данном сервере. В результате запросы "не доходят" до корневых серверов, но сама цепочка разрешения имени всегда выполняется от корня до текущего домена. Обычно администраторы локальных DNS-серверов настраивают свой сервер на пересылку (forwarding) запросов разрешения имен на тот или иной сервер DNS (обычно это DNS-сервер провайдера). Тем самым вся процедура разрешения имен будет выполняться уже другим сервером. Поскольку мощные серверы Интернета обычно имеют существенно больший кэш и лучший канал подключения к глобальной сети, то таким способом достигается уменьшение времени ответа и снижение трафика.
Для правильной работы почтового сервера важно иметь правильно настроенную зону. Настройка 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 часа после внесения изменений, у вашего партнера почта может не отправляться к вам в течении более длительного времени.
Основы
Что такое запись обратной зоны DNS?
Обычные DNS-запросы определяют неизвестный IP-адрес для известного имени хоста. Это необходимо когда, например, браузеру нужно установить TCP-соединение с сервером по введённому в адресном поле URL.
Forum.hetzner.de --> 213.133.106.33
Обратный DNS работает в другом направлении - запрос определяет имя хоста, принадлежащее IP-адресу.
213.133.106.33 --> dedi33.your-server.de
Как вы видите, именам хоста при прямом и обратном запросах необязательно совпадать!
Каково предназначение записи обратной зоны DNS?
- traceroute показывает не только IP-адреса, но и человекочитаемые имена узлов. Это значительно облегчает диагностику ошибок.
- Большое количество почтовых серверов принимает письма только если у IP-адреса отправителя есть обратная DNS-запись.
- Обратные DNS-записи могут использоваться в SPF-записях (Sender Policy Framework ; технология, предотвращающая рассылку спама и вирусов с поддельных email-адресов).
Как технически работает обратное преобразование на DNS-серверах?
Практика
Как я могу назначить несколько имён на мой IP-адрес, если различные домены размещены на моём сервере?
Это невозможно. Только одно имя назначается на каждый IP-адрес.
Более того, неважно какие обратные зоны прописаны для сервера. Для обращения к сайту браузеру достаточно провести лишь прямое преобразование (Имя --> IP). Здесь, конечно, может быть несколько имён, например несколько записей типа A или несколько записей типа CNAME, которые указывают на A-запись.
Для работы почтовых серверов необязательно иметь несколько имён хоста на один IP-адрес. Обратная DNS-запись должна соответствовать имени хоста SMTP-сервера (обратитесь к настройками соответствующего SMTP-сервера).
Если несколько доменов управляются через IP-адрес (достаточно частый случай), можно использовать нейтральное имя, не связанное с доменами пользователей. Спам-фильтры всего-лишь проверяют соответствует ли обратная DNS-запись имени в ответе на команду HELO. Это никак не влияет на доменные имена и почтовые адреса в передаваемых письмах.
- Обратная DNS-запись должна соответствовать имени почтового сервера или строиться на основании IP-адреса.
- Обратная DNS-запись должна также резолвиться "вперёд" - на тот-же IP-адрес.
- Обратная DNS-запись не должна быть похожа на автоматические-сгенерированную, например "162-105-133-213-static.hetzner.de", так так часто такие имена отрицательно оцениваются спам-фильтрами.
- Даваемое имя должно существовать. Пожалуйста, не используйте несуществующие доменные имена.
Пример хорошей записи:
Srv01.grossefirma.de --> 213.133.105.162 213.133.105.162 --> srv01.grossefirma.de > telnet 213.133.105.162 25 220 srv01.grossefirma.de ESMTP ready
Я задаю PTR на моём DNS-сервере. Почему это не работает?
Ваш DNS-сервер отвечает лишь за прямое преобразование.
Владелец блока IP-адресов (например, Hetzner Online GmbH) является ответственным за поддержание авторитативных DNS-серверов для обратных записей.
Обратные DNS-записи можно создавать только при помощи соответствующей функции панели Robot (левое меню -> "Servers" -> щелчок по серверу -> "IPs" -> щелчок по текстовому полю рядом с IP-адресом).
Обратная запись для моего сервера отличается от HELO моего почтового сервер. Является ли это проблемой?
Пример: обратная DNS-запись для IP-адреса сервера "www.grossefirma.de". В ответ на команду HELO почтовый сервер отвечает "mail.grossefirma.de".
Некоторые спам-фильтры расценивают письма от таких отправителей как "спам". Подобные несоответствия должны быть исправлены. Обратная DNS-запись и имя почтового сервера должны быть одинаковыми. В примере выше они могут быть, например, "srv01.grossefirma.de". Имя "www.grossefirma.de" может быть безо всяких последствий перенаправлено на srv01.grossefirma.de" при помощи CNAME-записи.
Подробное тестирование DNS-записей можно провести воспользовавшись
