PTR-запись и обратный DNS (rDNS): как проверить, кто её задаёт и как настроить для почты

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

dig -x 1.1.1.1 +short

one.one.one.one.

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

DNS умеет искать только имена, поэтому адрес записывается в виде имени. Для IPv4 четыре части адреса переставляют в обратном порядке и добавляют in-addr.arpa; для IPv6 в обратном порядке записывают каждую шестнадцатеричную цифру (полубайт, nibble) полного адреса и добавляют ip6.arpa. PTR-запись под этим именем и хранит имя хоста:

Имя для IPv6 в таблице сокращено. Полностью, со всеми 32 полубайтами, обратное имя адреса 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

Обратный порядок ставит сетевую часть адреса справа, там, где в DNS происходит делегирование. Зона с такими записями называется обратной зоной DNS (reverse zone): кто управляет зоной 113.0.203.in-addr.arpa, тот управляет именами всех 256 адресов сети 203.0.113.0/24. Именно поэтому PTR-запись не задаётся в зоне вашего домена.

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

Три инструмента, один ответ. dig -x сам строит обратное имя и показывает ответ целиком:

dig -x 1.1.1.1

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45673
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;1.1.1.1.in-addr.arpa.		IN	PTR

;; ANSWER SECTION:
1.1.1.1.in-addr.arpa.	1647	IN	PTR	one.one.one.one.

;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

host 1.1.1.1
nslookup 1.1.1.1

1.1.1.1.in-addr.arpa domain name pointer one.one.one.one.
1.1.1.1.in-addr.arpa	name = one.one.one.one.

В Windows nslookup 1.1.1.1 работает так же в cmd и в PowerShell, а в PowerShell команда Resolve-DnsName -Name 1.1.1.1.in-addr.arpa -Type PTR запрашивает запись явно. С IPv6 работают те же команды: dig -x 2606:4700:4700::1111 тоже возвращает one.one.one.one..

Если у адреса нет PTR-записи, запрос заканчивается ответом NXDOMAIN:

Host 154.23.20.104.in-addr.arpa. not found: 3(NXDOMAIN)
** server can't find 154.23.20.104.in-addr.arpa: NXDOMAIN

Если терминала под рукой нет, введите адрес в инструмент DNS lookup (англ.): он вернёт PTR-запись IP-адреса вместе с TTL так, как её видит наш резолвер в Амстердаме.

Кто управляет PTR-записью

Владелец блока IP-адресов, и никогда не DNS-хостинг вашего домена. Это самая частая путаница: PTR-запись добавляют в Cloudflare или у регистратора, видят, что она сохранилась, и не понимают, почему dig -x её не видит. Обратный запрос вообще не заходит в зону вашего домена. Он идёт по делегированию адресного пространства: от корня к региональному интернет-регистратору и дальше к сети, которой принадлежит блок. Цепочку показывает +trace:

dig +trace -x 1.1.1.1

in-addr.arpa.		172800	IN	NS	a.in-addr-servers.arpa.
1.in-addr.arpa.		86400	IN	NS	ns1.apnic.net.
1.1.1.in-addr.arpa.	86400	IN	NS	alec.ns.cloudflare.com.
1.1.1.1.in-addr.arpa.	1800	IN	PTR	one.one.one.one.

APNIC, региональный регистратор для этой части адресного пространства, делегирует зону 1.1.1.in-addr.arpa тем DNS-серверам, которые выбрал владелец блока, здесь серверам Cloudflare, и PTR-запись лежит в этой зоне. Для вашего сервера на последнем шаге NS будут указаны DNS-серверы вашего провайдера. Узнать, чья это зона, можно и быстрее: запросите SOA обратного имени. В ответе будут имя зоны и её первичный DNS-сервер, и та же SOA приходит вместе с каждым NXDOMAIN.

dig SOA 1.1.1.1.in-addr.arpa +noall +answer +authority

1.1.1.in-addr.arpa.	1800	IN	SOA	alec.ns.cloudflare.com. dns.cloudflare.com. 2347919506 10000 2400 604800 1800

Чтобы узнать, кому принадлежит блок и к кому обращаться, выполните whois для адреса: строки inetnum или NetRange показывают блок, netname или OrgName — владельца, и обычно там же есть контакт для жалоб (abuse).

PTR-запись для почтового сервера

Здесь PTR-запись перестаёт быть украшением. Принимающий сервер видит только IP-адрес, который к нему подключился, и проверяет три вещи:

• у адреса есть PTR-запись;
• имя из неё разрешается (A для IPv4, AAAA для IPv6) обратно в тот же адрес; это называется прямым подтверждением обратного DNS (forward-confirmed reverse DNS, FCrDNS);
• имя, которое сервер назвал в приветствии EHLO, совпадает с ним или хотя бы является настоящим именем хоста.

Gmail требует первые два пункта от всех отправителей и при ошибке отвечает 550 5.7.25 или временным 451 4.7.23. Так же может поступать и почтовый сервер, который вы держите сами: ограничение Postfix reject_unknown_client_hostname отклоняет ровно такие случаи, по умолчанию с временным кодом 450. Стандарт SMTP запрещает отклонять почту только из-за того, что имя в EHLO не совпадает с адресом, но спам-фильтры всё равно начисляют за это штрафные баллы, поэтому сделайте так, чтобы все три совпадали:

Берите имя в домене, которым управляете сами, а не типовое имя, которое генерирует провайдер: в нём часто есть цифры IP-адреса, и спам-фильтрам оно кажется домашним подключением. Направляйте PTR на имя хоста с A-записью, а не на CNAME; об этом прямо говорит RFC 1912. Скрипт ниже проверяет путь туда и обратно; замените YOUR_SERVER_IP на адрес, с которого уходит почта, а IPv6-адрес укажите в коротком виде строчными буквами, как его печатает dig:

ip=YOUR_SERVER_IP
name=$(dig +short -x "$ip" | grep -v -e '^;' -e '\.arpa\.$' | head -n 1)
if [ -z "$name" ]; then
  echo "no PTR record for $ip"
elif dig +short "$name" A "$name" AAAA | grep -qxF "$ip"; then
  echo "OK: $ip -> $name -> $ip"
else
  echo "MISMATCH: $name does not resolve back to $ip"
fi

grep отбрасывает два вида строк, которые dig +short может напечатать перед именем: предупреждение ;; после повторного запроса и псевдоним, который делегирование по RFC 2317 ставит перед PTR-записью.

OK: 1.1.1.1 -> one.one.one.one. -> 1.1.1.1
OK: 2606:4700:4700::1111 -> one.one.one.one. -> 2606:4700:4700::1111
OK: 8.8.8.8 -> dns.google. -> 8.8.8.8
no PTR record for 104.20.23.154

Инструмент Mail server check (англ.) выполняет ту же проверку для MX-хостов домена, рядом с SPF, DKIM и DMARC, а Blacklist check (англ.) покажет, не попал ли адрес в публичный чёрный список: правильная PTR-запись этого не исправит. Какие порты нужны самому почтовому серверу, описано в статье о портах SMTP (англ.).

Как настроить PTR-запись в VMHeaven

В VMHeaven обратный DNS вы настраиваете сами в личном кабинете, и для VPS, и для выделенных серверов. Действуйте в таком порядке, потому что PTR-запись полезна, только когда её имя разрешается:

1. 1Сначала создайте A-запись

   У DNS-хостинга вашего домена направьте mail.example.com на IPv4-адрес сервера (и добавьте AAAA-запись, если будете использовать IPv6), затем проверьте её. Имя должно быть полным именем хоста, то есть FQDN (англ.), например mail.example.com.

   dig +short mail.example.com A

2. 2Задайте PTR для IPv4-адреса

   Откройте сервер в личном кабинете и перейдите на вкладку IP-адреса. У каждого адреса рядом с кнопкой Изменить показано текущее значение rDNS. Введите имя хоста в поле Имя хоста для PTR и сохраните.

3. 3Задайте PTR для IPv6, если у сервера есть префикс

   Там, где в пуле локации есть IPv6, VPS получает целый префикс, а не один адрес; на вкладке IP-адресов он показан как делегированная подсеть /64. Кнопка Управлять открывает его обратный DNS: добавьте адрес, который вы действительно используете (он должен лежать внутри префикса), и его имя хоста.

4. 4Подождите и проверьте

   Изменения вступают в силу примерно за 30 минут. Затем выполните dig -x и скрипт проверки выше. Если имя не разрешается обратно в IP, почтовые сервисы проигнорируют PTR-запись.

5. 5Пусть сервер использует то же имя

   sudo postconf -e myhostname=mail.example.com
   sudo systemctl reload postfix

   При отправке почты Postfix представляется именем из myhostname, если smtp_helo_name не задаёт другое; postconf myhostname smtp_helo_name покажет оба значения. В других почтовых серверах есть аналогичная настройка.

Нужна ли PTR-запись серверу, который не отправляет почту?

Не обязательна, но полезна. С PTR-записью ваш адрес понятнее в чужих логах и в трассировках, а на сервере для сканирования из линейки Pentesting KVM PTR-запись, указывающая на имя хоста, на сайте которого описан проект и дан контактный адрес, сокращает число жалоб (abuse). Обратный DNS встречается и на принимающей стороне: параметр OpenSSH UseDNS заставляет sshd искать имя каждого клиента и проверять его прямым запросом. В актуальном OpenSSH он по умолчанию выключен, поэтому клиент без PTR-записи входит как обычно; но если на сервере его кто-то включил, обратный запрос, ушедший в таймаут, задерживает каждый вход.

Обратный DNS для IPv6

PTR-запись для IPv6 работает так же, но в обратном имени 32 полубайта, по одному на каждую шестнадцатеричную цифру полного адреса, поэтому 2001:db8::25 сначала превращается в 2001:0db8:0000:0000:0000:0000:0000:0025. Не считайте нули вручную, пусть имя напишет инструмент: dig -x принимает короткую форму, а в Python ipaddress.ip_address("2001:db8::25").reverse_pointer печатает готовое имя.

В /64 слишком много адресов, чтобы давать запись каждому, поэтому PTR задают только для адресов, которые отправляют почту или которым нужно имя. Здесь есть ловушка: если у сервера есть IPv6, Postfix с inet_protocols = all доставляет почту и по IPv6, а Gmail отклоняет письма с IPv6-адреса без правильной PTR-записи кодом 550 5.7.1, ссылаясь на свои требования к отправке по IPv6. Либо дайте IPv6-адресу тоже PTR- и AAAA-запись, либо ограничьте Postfix протоколом IPv4 через inet_protocols = ipv4; эта настройка требует полной остановки и запуска Postfix, а не reload.

PTR-запись не обновляется или не принимается

• Всё ещё видно старое значение. Резолверы кешируют PTR-запись на время её TTL, это число после имени в выводе dig -x. Если раньше PTR-записи не было, они кешируют NXDOMAIN на срок, равный меньшему из двух значений: TTL самой SOA-записи и её последнего поля (в примере ниже — 3600 секунд). dig +trace -x обходит кеши резолверов и показывает, что DNS-сервер провайдера отвечает прямо сейчас.
• Устарел кеш на вашей машине. Очистите его командой resolvectl flush-caches в Linux с systemd-resolved или ipconfig /flushdns в Windows.
• PTR-запись верная, а почту всё равно отклоняют. Запустите скрипт проверки: A-записи нет, она указывает на другой адрес, или PTR называет CNAME.
• У одного IP несколько PTR-записей. DNS это допускает, но получатель возьмёт одну из них, и не обязательно ту, что совпадает с именем в EHLO. Держите одну PTR-запись на адрес; при этом много адресов могут указывать на одно имя хоста.
• PTR-запись создана у DNS-хостинга домена. Её никто никогда не запрашивает; удалите её и задайте PTR у провайдера, которому принадлежит IP.
• В обратной зоне, которую вы ведёте сами, появляются странные имена. В синтаксисе BIND к цели PTR без точки в конце дописывается имя зоны: mail.example.com превращается в mail.example.com.113.0.203.in-addr.arpa.. Пишите mail.example.com..

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18648
20.104.in-addr.arpa.	3600	IN	SOA	cruz.ns.cloudflare.com. dns.cloudflare.com. 2288625501 10000 2400 604800 3600

Каждый сервер VMHeaven, от VPS Standard KVM до выделенного сервера, получает собственный IPv4-адрес, обратный DNS которого вы настраиваете в личном кабинете. О прямой стороне тех же записей читайте в статье Что такое DNS.

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