Что такое обратный DNS и PTR-запись: как проверить и настроить

Обычный DNS отвечает на вопрос «какой адрес у этого имени?». Обратный DNS отвечает на противоположный: «какое имя у этого адреса?». Ответ хранится в PTR-записи. Вещь небольшая, но важная в нескольких местах (прежде всего в доставке почты), и людей она сбивает с толку, потому что не живёт в зоне вашего домена и задать её в панели DNS обычно нельзя.

Как работает обратный DNS

DNS умеет искать только имена, поэтому IP-адрес сначала нужно превратить в имя. Для IPv4 четыре октета записываются в обратном порядке и к ним добавляется .in-addr.arpa:

192.0.2.25   →   25.2.0.192.in-addr.arpa.

Обратный порядок ставит старшую часть справа, как в любом доменном имени, и это делает возможным делегирование: тот, кто отвечает за 192.0.2.0/24, ведёт зону 2.0.192.in-addr.arpa и может опубликовать запись для каждого адреса в ней:

25.2.0.192.in-addr.arpa.   3600   IN   PTR   mail.example.com.

Для IPv6 адрес записывается полностью, в обратном порядке по одной шестнадцатеричной цифре (полубайту), под ip6.arpa:

2001:db8::25   →
5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

Вручную это никогда не набирают; dig -x строит имя за вас:

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short -x 2001:db8::25
mail.example.com.

host 192.0.2.25 и nslookup 192.0.2.25 делают то же самое.

Кто контролирует PTR-запись

Обратное дерево следует за выделением адресов, а не за владением доменом. Региональные интернет-регистраторы (RIPE NCC, ARIN, APNIC, LACNIC, AFRINIC) делегируют обратные зоны организациям, владеющим блоками адресов (интернет-провайдерам, хостинг- и облачным провайдерам), а те решают, как клиенты могут задавать PTR-записи.

Следствия:

Добавить PTR-запись в зону example.com бесполезно. Там её никто никогда не запросит.
VPS или выделенный сервер: у большинства провайдеров в панели управления есть поле «обратный DNS» для каждого IP. Многие требуют, чтобы прямая запись существовала заранее.
Облачные платформы: обычно поддерживается для статических или зарезервированных адресов, иногда только через вызов API или запрос в поддержку, а иногда для исходящей почты не поддерживается вовсе.
Домашнее или офисное подключение: PTR задаёт интернет-провайдер. Для бизнес-линий со статическим IP собственную PTR часто можно получить по запросу; для домашних линий, как правило, нет.
Виртуальный хостинг: адрес общий для множества сайтов, и PTR называет сервер хостинг-компании. Это нормально, чинить здесь нечего.
Собственный блок адресов: вы ведёте обратную зону сами или получаете её делегированной. Для блоков меньше /24, где целую зону in-addr.arpa нельзя делегировать по границам октетов, провайдеры используют технику на основе CNAME из RFC 2317.

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

Обратный DNS с прямым подтверждением

Одна PTR-запись доказывает мало, потому что владелец обратной зоны может вписать туда любое имя, включая mail.yourbank.example. Получатели на самом деле проверяют, согласуются ли оба направления:

IP → PTR → имя;
это имя → A/AAAA → тот же IP.

$ dig +short -x 192.0.2.25
mail.example.com.
$ dig +short mail.example.com A
192.0.2.25

Если цикл замыкается, это называется обратным DNS с прямым подтверждением (forward-confirmed reverse DNS, FCrDNS). Оно показывает, что тот, кто контролирует адрес, и тот, кто контролирует имя, действуют согласованно, а это скромный, но реальный сигнал.

Почему это важно для почты

Почтовые получатели десятилетиями используют обратный DNS как один из входов спам-фильтра, потому что машина без PTR или с типовой записью вроде host-192-0-2-25.dynamic.isp.example куда чаще оказывается заражённым домашним компьютером, чем почтовым сервером. Крупные почтовые провайдеры в своих правилах для отправителей прямо указывают, что у отправляющих IP должны быть действительные прямая и обратная записи; без них ждите отказов или отсрочек с сообщениями, в которых упоминаются «PTR record» или «reverse DNS».

Для почтового сервера выровняйте три имени:

Что	Должно быть
PTR отправляющего IP	`mail.example.com`
`A`/`AAAA` для `mail.example.com`	отправляющий IP
Имя в приветствии SMTP (`HELO`/`EHLO`)	`mail.example.com`

PTR не обязана совпадать с доменом в адресе From. Сервер mail.hosting.example может отправлять почту для сотен клиентских доменов; выравнивание этих доменов — задача SPF, DKIM и DMARC, о которых рассказано в статье MX, SPF, DKIM и DMARC: как они работают вместе.

Если вы отправляете через сервис рассылок или хостинговую почту, отправляющие IP принадлежат им, как и PTR. Настраивать вам нечего.

Отдельное предупреждение про IPv6: если у сервера есть IPv6-адрес, он часто будет предпочитать его для исходящей почты, а получатели к PTR на IPv6 обычно строже. Либо задайте PTR и AAAA и для этого адреса, либо заставьте почтовый сервер отправлять только по IPv4.

Где ещё встречаются PTR-записи

traceroute и mtr показывают имена маршрутизаторов из PTR-записей, которые часто выдают сеть и город каждого узла.
Журналы и средства безопасности разрешают адреса клиентов в имена. Относитесь к этим именам как к подсказкам: их контролирует другая сторона.
Правила доступа на основе обратного DNS (например, «разрешить *.crawler.example») безопасны, только если программа подтверждает имя прямым запросом. Именно так поисковые системы рекомендуют проверять своих роботов.
Некоторые серверы SSH и FTP делают обратный запрос при каждом подключении; сломанная обратная зона проявляется как задержка в несколько секунд при входе (UseDNS в OpenSSH).

Чего PTR-запись не сообщает

Не сообщает, какие сайты там работают. На одном IP могут жить тысячи сайтов; PTR — единственное имя, выбранное владельцем адреса. Сервисы «reverse IP», перечисляющие домены на адресе, используют собственные собранные данные, а не PTR-записи.
Не сообщает, кто владеет сервером. server42.hosting.example называет хостинг-компанию. Регистрационные данные блока адресов сообщают то же самое, но надёжнее.
Не сообщает, где он находится. Коды аэропортов в именах маршрутизаторов — в лучшем случае подсказка.
Довольно часто не сообщает ничего. У многих адресов PTR нет вовсе. Для веб-сервера это безобидно.

Настройка: чек-лист

Выберите имя хоста в домене, который вы контролируете: mail.example.com. Избегайте корневого домена и имён, которые уже служат другой цели.
Сначала создайте прямую запись: mail.example.com A 192.0.2.25 (и AAAA, если применимо).
Задайте PTR в панели провайдера или попросите провайдера или интернет-провайдера задать её, ровно на это имя хоста.
Настройте почтовый сервер так, чтобы он представлялся тем же именем (например, myhostname в Postfix).
Проверьте оба направления с помощью dig, для IPv4 и IPv6.
Прежде чем судить о результате, учтите TTL старой PTR. Как работает кэширование, описано в статье что такое TTL в DNS.

Частые ошибки

Создать PTR-запись в прямой зоне и удивляться, почему ничего не меняется.
PTR, указывающая на имя, которое не разрешается или разрешается в другой IP.
Несколько PTR-записей на одном адресе. Это допустимо, но многие проверки берут только одну из них, непредсказуемо. Используйте ровно одну.
Оставить типовую PTR провайдера на адресе, с которого уходит почта.
Аккуратно настроить IPv4 и забыть, что сервер отправляет и по IPv6.
Сменить IP сервера и обновить только прямую запись.
Считать PTR доказательством личности. Без прямого подтверждения она не доказывает ничего.

Проверьте в OrbitProbe

Проверка IP в OrbitProbe разрешает имя хоста в его IPv4- и IPv6-адреса и показывает для каждого адреса имя обратного DNS вместе с автономной системой и владельцем сети. Введите имя хоста вашего почтового сервера: если обратное имя для каждого адреса совпадает с введённым именем, цикл замкнут. Если обратное имя отсутствует или типовое, владелец сети, показанный рядом, — это организация, которая может его изменить.