Reverse DNS (PTR): как работает rDNS, зачем нужен и как настроить без боли

Reverse DNS (обратная зона DNS) — механизм, который позволяет получить имя хоста по IP-адресу (тот самый ip to hostname). На практике это почти всегда означает запись PTR в обратной DNS-зоне. Если прямой DNS отвечает на вопрос «какой IP у домена?», то rDNS отвечает «какое имя у этого IP?». Для админов и DevOps это не теория: PTR влияет на доставляемость почты, корректность логов, некоторые проверки безопасности и репутацию IP.

Ниже разберём, как устроен PTR, как его проверить через dig -x, что такое forward-confirmed reverse DNS (FCrDNS), и почему «PTR на домен сайта» часто оказывается плохой идеей.

Что такое PTR и где он живёт

PTR (Pointer record) — DNS-запись в специальной обратной зоне:

• для IPv4 это зона in-addr.arpa;
• для IPv6 — ip6.arpa.

Например, у IP 203.0.113.10 обратный запрос строится так: октеты разворачиваются в обратном порядке, и к ним добавляется in-addr.arpa. Получится имя:

10.113.0.203.in-addr.arpa.

И уже на него в DNS хранится запись PTR, указывающая на FQDN (полное доменное имя), например mail01.example.com.

PTR — это не «ещё одна запись в вашей зоне example.com». Это запись в обратной зоне, которая обычно контролируется владельцем подсети (провайдером/ДЦ) или тем, кому делегировали reverse-зону.

Reverse DNS и forward DNS: почему важно соответствие

Один PTR сам по себе часто недостаточен. В реальном мире проверяют связку:

• Reverse: IP → PTR → hostname;
• Forward: hostname → A/AAAA → тот же IP.

Когда обе стороны сходятся, говорят про forward-confirmed reverse DNS (FCrDNS). Это важный сигнал «IP действительно принадлежит этому имени», особенно для SMTP и антиспам-скоринга.

Почему «PTR на домен сайта» — частая ошибка

Новички нередко ставят PTR на example.com (корневой домен). Технически так можно, но в эксплуатации это часто неудобно:

• сайт может мигрировать на другой IP, а PTR остаётся «почтовым» и ломает ожидания;
• для почты логичнее выделять имя вроде mail01.example.com или smtp.example.com;
• если на IP крутится несколько сервисов, нейтральный hostname для PTR снижает путаницу в логах и проверках.

Если вы управляете доменом и DNS, полезно заранее привести делегирование и NS к порядку: см. материал про делегирование поддомена на отдельные NS (помогает, когда разные команды ведут разные зоны).

Где PTR реально нужен: SMTP, антиспам и репутация

Сильнее всего отсутствие PTR бьёт по исходящей почте. Многие принимающие серверы оценивают rDNS как часть скоринга. Это не всегда жёсткий блок, но типичные последствия такие:

• растёт вероятность попадания в спам;
• встречаются временные 4xx отказы уровня «no reverse dns»;
• при агрессивных политиках возможны и 5xx отказы.

SMTP HELO/EHLO и FQDN: как связаны с PTR

В SMTP сервер при соединении представляет себя строкой HELO/EHLO — и по хорошим практикам это должен быть корректный FQDN. Некоторые антиспам-системы сравнивают HELO-имя с PTR и/или с forward DNS.

Здравый минимум для исходящей почты с вашего сервера:

1. HELO/EHLO = mail01.example.com (существует в DNS);
2. PTR(IP) = mail01.example.com;
3. A/AAAA(mail01.example.com) = ваш IP.

В идеале один внешний IP — один устойчивый hostname для почтового сервера, и он согласован в PTR, A/AAAA и HELO.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Как проверить reverse DNS и FCrDNS (dig, host, nslookup)

Проверка должна ответить на три вопроса: «есть ли PTR», «куда он указывает», «сходится ли forward обратно в тот же IP».

Проверка PTR через dig

dig -x 203.0.113.10 +short

Ожидаемый результат — hostname (часто с точкой на конце), например:

mail01.example.com.

Если пусто — PTR не настроен или ответ не доходит (ошибка делегации reverse-зоны, проблемы с авторитативными NS, блокировки UDP/53 на пути и т. п.).

Проверка forward (A/AAAA) для FCrDNS

dig A mail01.example.com +short

dig AAAA mail01.example.com +short

Сверьте: среди ответов должен быть тот же IP. Если PTR указывает на имя, у которого A/AAAA другой (или записи нет) — FCrDNS не проходит.

Проверка «в лоб» через host

host 203.0.113.10

host mail01.example.com

Проверка того, что видит конкретный резолвер

Иногда у вас «всё ок», но внешний мир видит иначе из-за кеша/TTL или разных резолверов. Полезно уточнять у конкретного DNS-сервера:

dig -x 203.0.113.10 @1.1.1.1 +short

dig -x 203.0.113.10 @8.8.8.8 +short

Если ответы отличаются — ищите рассинхрон в делегации reverse-зоны, проблемы с авторитативными NS или старый кеш у отдельных резолверов.

Как настроить PTR: что реально можно сделать на вашей стороне

Ключевой момент: PTR почти всегда настраивается не в панели домена, а у владельца IP-адреса или подсети. Сценарии обычно такие:

• Провайдер ставит PTR по запросу (вы задаёте hostname);
• делегирование reverse-зоны на ваши NS (чаще для подсети, чем для одиночного IP);
• настройка PTR в панели провайдера (для VPS/VDS встречается часто).

На вашей стороне важно подготовить «прямую» часть, иначе FCrDNS не получится:

1. выберите имя, например mail01.example.com;
2. создайте A-запись mail01.example.com → ваш IPv4;
3. если используете IPv6 для исходящей почты — добавьте AAAA;
4. настройте MTA так, чтобы HELO/EHLO совпадал с этим FQDN;
5. после установки PTR перепроверьте dig -x/host и дождитесь обновления по TTL.

Какое имя выбрать для PTR (практика)

Хороший PTR hostname обычно:

• принадлежит вашему домену (которым вы управляете);
• не меняется при переезде сайта/приложения;
• не выглядит как «динамический» или «пуловый» (если вы хотите нормальную почтовую репутацию);
• имеет корректный A/AAAA без лишних цепочек.

Если домен вы только планируете зарегистрировать или переносите инфраструктуру на новый бренд, удобнее сделать это заранее через регистрацию доменов, чтобы сразу закрепить «почтовые» имена и не перестраивать PTR позже.

Типовые проблемы и быстрый чек-лист диагностики

1) PTR есть, но FCrDNS не проходит

Самый частый кейс: PTR указывает на mail01.example.com, но A-запись этого имени смотрит на другой IP (или отсутствует). Проверьте:

dig -x 203.0.113.10 +short
DIGPTR=$(dig -x 203.0.113.10 +short)
echo "$DIGPTR"
dig A mail01.example.com +short

Если PTR возвращает имя с точкой на конце, сравнивайте аккуратно (точка не влияет на смысл FQDN, но может мешать скриптам).

2) PTR указывает на имя с CNAME

PTR указывает на доменное имя, а дальше вы делаете CNAME на другое имя. Формально это может работать, но многие проверки любят прямой A/AAAA без цепочек. Практичнее дать A/AAAA именно тому имени, которое указано в PTR.

3) Отправляете почту с IPv6, а PTR настроен только для IPv4

При dual-stack некоторые MTA охотно используют IPv6. Если для IPv6 нет PTR (или он «провайдерский»), можно получить неожиданные проблемы с доставкой. Проверяйте исходящий IP в логах и на него делайте rDNS.

4) Изменили PTR, но «в мире» ещё старое значение

Чаще всего причина — кеш резолверов и TTL, либо изменили не тот объект: не тот IP, не тот интерфейс, не тот пул адресов (особенно при NAT и нескольких адресах). Перепроверьте через несколько публичных резолверов и убедитесь, что правили rDNS именно для исходящего адреса.

5) Несколько PTR на один IP

Технически возможно несколько PTR, но на практике это плохая идея для предсказуемости: разные резолверы и библиотеки могут выбирать значения по-разному. Для почты держите один IP → один PTR.

Практический пример: приводим сервер к «чистому» FCrDNS для почты

Сценарий: у вас есть IP 203.0.113.10, домен example.com, вы хотите отправлять почту с mail01.example.com.

Шаг 1. Forward DNS

В зоне example.com создайте:

• A: mail01 → 203.0.113.10;
• (опционально) AAAA: mail01 → ваш IPv6.

Проверка:

dig A mail01.example.com +short

Шаг 2. Reverse DNS (PTR)

Задайте у провайдера PTR для IP 203.0.113.10 на mail01.example.com.

Проверка:

dig -x 203.0.113.10 +short

Шаг 3. Настройте HELO/EHLO на том же FQDN

Конкретные параметры зависят от MTA, но принцип один: имя, которое сервер объявляет при SMTP-сессии, должно быть существующим FQDN и желательно совпадать с PTR. После настройки проверьте в логах исходящих соединений, какое имя уходит в HELO.

Шаг 4. Финальная проверка FCrDNS

Если хочется проверить «IP → PTR → A → IP» в один проход без сложных конструкций, сделайте это двумя командами:

dig -x 203.0.113.10 +short

dig A mail01.example.com +short

Совпало — базовая связность есть. Для IPv6 аналогично используйте dig -x по IPv6 и dig AAAA по имени.

Reverse DNS не про «магическую доставку»: что ещё важно для почты

PTR — необходимая гигиена, но он не заменяет остальные настройки: SPF, DKIM, DMARC, корректные MX, адекватный контент и стабильную репутацию IP. Однако отсутствие rDNS или сломанный FCrDNS — это красный флаг для многих систем фильтрации.

Считайте PTR базовым «паспортом» IP для инфраструктуры: без него часто «можно», но почти всегда хуже и менее предсказуемо.

Короткий чек-лист перед тем, как просить PTR у провайдера

• определите исходящий IP (особенно при NAT, нескольких адресах и IPv6);
• выберите устойчивый FQDN для PTR, например mail01.example.com;
• сделайте A/AAAA для этого имени на нужный IP;
• настройте SMTP HELO/EHLO на этот FQDN;
• после изменения проверьте dig -x через несколько резолверов.

FAQ: частые вопросы про rDNS

Можно ли настроить PTR в обычной DNS-панели домена?

Чаще всего нет, потому что reverse-зона принадлежит владельцу IP-подсети. Исключение — если вам делегировали reverse-зону или провайдер дал управление PTR в своей панели.

PTR обязателен для веб-сайта?

Для HTTP/HTTPS обычно нет. Для почты, некоторых API-интеграций и общей «репутационной гигиены» — крайне желательно.

Что важнее: PTR или A-запись?

Они решают разные задачи. Но если говорить про FCrDNS и почту, важна связка: PTR должен указывать на имя, которое в forward DNS возвращает тот же IP.

Как понять, что письмо отклоняют из-за rDNS?

Смотрите текст отказа (bounce) и логи SMTP-диалога: часто там прямо упоминаются reverse dns, ptr, rDNS или «no PTR». Но даже без явного сообщения rDNS может быть частью скоринга.

Если хотите быстро локализовать проблему, соберите три факта: исходящий IP, результат dig -x и результат dig A/dig AAAA для имени из PTR. Этого достаточно, чтобы понять, где именно расхождение.