Что такое ptr запись
Что Такое PTR Запись и Как Сделать Обратный IP-поиск?
Введение
Существует много типов DNS записей и для новичков может быть слишком сложно понять, какая функция у этой DNS-записи или как ее настроить. В этом уроке вы узнаете, что такое PTR запись и как проверить настроена ли она для IP-адреса.
Переходите на почтовый хостинг от Hostinger, чтобы иметь полный доступ ко всем настройкам и возможностям почтового сервиса.
Что такое PTR запись
Зачем необходима PTR запись
Она полезна для исходящих почтовых серверов. Эта запись повышает надежность отправляющего сервера и позволяет получить обратный ответ для проверки имени хоста через IP-адрес. Это отличный способ защиты от всех видов спамеров, которые используют мошеннические доменные имена для рассылки спама. Вот почему некоторые крупные провайдеры услуг почты, такие как yahoo.com, gmail.com делают обратный поиск в DNS, прежде чем принимать входящие письма.
Что вам понадобится
Перед тем, как вы начнете это руководство, вам понадобится следующее:
Способ 1 — Проверка PTR с помощью nslookup или dig
Windows, Unix и схожие операционные системы (Linux, MacOS) имеют встроенные инструменты для проверки DNS записей. Если вы являетесь пользователем Windows, следуйте данным этапам:
Как видно из результата, PTR запись — ec2-54-243-154-49.hostinger.com.
Для пользователей Linux или Mac процесс схож:
Из раздела ANSWER SECTION можно узнать значение PTR записи — ec2-54-243-154-49.hostinger.com
Способ 2 — Использование онлайн инструментов
Еще один способ для получения информации об имени хоста IP-адреса, это использовать инструмент для обратного поиска MxToolBox. Все что нужно, это вписать в поле IP адрес и нажать кнопку Reverse Lookup (Обратный поиск).
Заключение
К сожалению, если поиск показывает, что запись не настроена для IP-адреса, в большинстве случаев вам придется обратиться к вашему хостинг-провайдеру или интернет-провайдеру с просьбой создать ее. Однако теперь вы знаете, что такое PTR запись и как проверить есть ли у нее IP-адрес. Это полезно если вы столкнулись с ошибками DNS и возвратами при попытке отправить электронную почту, поскольку это поможет вам устранить проблему.
PTR-запись и ее использование
Например, на сервере с доменом sweb.ru используется IP-адрес 77.222.41.9. Для этого IP-адреса существует PTR-запись со значением «sweb.ru»:
Значение PTR-записи не обязательно будет соответствовать какому-либо доменному имени, в A-записи которого используется IP-адрес.
Использование PTR-записи
Проверка PTR-записи используется при фильтрации входящей почты от нежелательных почтовых сообщений.
Так как наличие PTR-записи можно считать нормой для работающих с почтой серверов, то для каждого входящего письма проверяется наличие PTR-записи у сервера-отправителя письма. В случае отсутствия записи письмо не принимается так как отсутствие PTR-записи означает, что сервер-отправитель либо не предназначен для отправки почты (злоумышленники могли получить доступ к компьютеру с доступом в интернет и использовать компьютер для массовых нежелательных рассылок), либо настроен некорректно (администратор почтового сервера не задал PTR-запись).
Задание PTR-записи
PTR-записи заданы для всех основных IP-адресов серверов виртуального хостинга и выделенных серверов под нашим администрированием.
PTR-записи изначально отсутствуют для услуг:
Задать PTR-запись может исключительно организация, которая выдала IP-адрес. Таким образом, мы готовы внести PTR-запись только для IP-адресов, которые были предоставлены нами.
PTR записи на DNS сервере
Для корректной работы почтового сервера важно иметь правильно настроенную DNS зону, в которой должны присутствовать A, MX и PTR-записи. Если с первыми двумя всё более-менее понятно, то настройка PTR-записи (обратной зоны, когда необходимо проверить имя сервера зная его IP-адрес) не редко вызывает сложности в понимании, где она должна быть прописана и кто за неё отвечает. Без PTR-записи часть почтовых серверов откажется принимать почту с вашего сервера, отправив вам в ответ примерно такую ругань:
550-There is no reverse (PTR) record found for your host or A record does not 550 correspond PTR record (in reply to RCPT TO command) 550-Reverse DNS lookup failed. If you think this is wrong, get in touch with 550 postmaster. (in reply to RCPT TO command) 550 5.7.1 Relaying denied. IP name forged (PTR and A records mismatch) for ###.###.###.### (in reply to MAIL FROM command)
Рассмотрим распространенную ситуацию. По каким-то причинам вам перестало хватать возможностей почтового сервера, предоставляемого хостингом, там где находится ваш сайт (или просто вы зарегистрировали домен и хотите настроить свой почтовый сервер). У своего провайдера вы получили статический ip-адрес (или даже небольшую подсеть) и на хостинге прописали А и MX записи с указанием на ваш почтовик (тот самый, выделенный вам провайдером ip-адрес).
Так вот, кто выдал вам статический ip-адрес, тот и прописывает на своем DNS-сервере PTR-записи для вашего почтового сервера в зоне in-addr.arpa. Для этого необходимо послать запрос тому, кто выдал вам статический ip-адрес с просьбой зарегистрировать PTR запись для вашего домена.
DNS-запись in-addr.arpa для почтового сервера mail.mydomain.ru с адресом 123.45.67.89 выглядит так:
123.45.67.89.in-addr.arpa. IN PTR mail.mydomain.ru.
Проверить наличие PTR записи на сервере DNS можно с помощью команды nslookup или аналогичного онлайн-сервиса (к примеру http://www.nslookup.su). В командной строке вызываем nslookup и пишем:
В поле `name` видим имя одного из почтовых серверов яндекса. При правильной настройке обратной зоны, данное поле должно отобразить имя вашего почтового сервера по соответствующему ip-адресу.
Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.
Как работают и для чего нужны PTR записи?
1. Домен IN-ADDR.ARPA это реальный физический домен, который где-то находится, и обслуживается реальными людьми, или это абстрактное название, которое просто зарезервировано под использование для E-Mail, наравне с 192.168. 172.27. и 127.0.0.1?
in-addr.arpa — реальный существующий домен. PTR — понятие DNS, к email оно имеет только косвенное отношение (email использует ptr-записи для ip-адресов).
Когда вы делаете traceroute на какой-то IP-адрес, имена доменов, которые вы видите в выводе, получаются путём запроса PTR-записи IP-адреса:
PTR был, пожалуй, первой технологией защиты от спама со взломанных серверов или недоверенных сетей, но только потому, что его «нетривиально» сменить в общем случае, когда у совершающего рассылку нет на это полномочий.
2. Почему в PTR записях IP адреса записываются в обратном порядке? Какой в этом смысл?
Лёгкость хранения «обратного» дерева в памяти DNS-сервера, быстрый поиск записей. Скорее, технологическая особенность 80-х, а не необходимость.
3. Есть ли какой-то софт, позволяющий моделировать сети, скажем поднимать несколько виртуальных машин, и настраивать им разные роли. Например одну сконфигурировать как провайдера, другую как просто компьютер и т.д, чтобы наглядно моделировать взаимодействие в сети интернет, и больше не задавать подобные вопросы здесь
PTR-запись vs. Mail.ru
Нежданно-негаданно столкнулся с непробиваемостью саппорта Mail.ru. Оно и понятно, сервис бесплатен, но раз саппорт выведен в отдельную единицу — он должен работать, а не просто изучать фидбек (моё глубокое IMHO, конечно).
Суть истории
На прошедшие выходные один их заказчиков оформил хостинг в одной известной московской телекоммуникационной компании. Заодно был зарегистрирован домен, так как хоcтер по совместительству и регистратор тоже. Так удобно заказчику — платить за хостинг с доменом в одну организацию.
Домен был делегирован и через несколько часов я отправился проверить валидность DNS.
Всё было в порядке, за исключением того, что PTR-запись осталась для прежнего домена. Такое бывает, когда при удалении аккаунта DNS-администратор «забывает» удалить PTR.
Письмо в саппорт и через пару часов на почтовый ящик упало уведомление от техподдержки, что всё исправлено. Что ж, ждем до следующего дня, так как TTL для записи составляет 24 часа, и проверяем как ходит почта на основные бесплатные почтовые сервисы: Yandex — OK, Google — OK, Mail.ru…
Хорошо, ждём еще 12 часов. Пока суть да дело, прописываем SPF, проверяем снова — ничего не поменялось. Хорошо, пишем в саппорт, особо не надеясь на ответ, с abuse отвечают не скоро и не всегда.
Сразу приходит ответ робота с тикетом, что уже приятно.
Проходят сутки и саппорт, как ни странно, отвечает. Правда вопросом: «Уточните, пожалуйста, осталась ли проблема на данный момент?»
Отвечаю, да — ничего не изменилось. Почта вашим сервером по-прежнему не принимается, несмотря на то, что ваш локальный сервер давно должен был удалить запись, так как время TTL истекло.
Проходят еще сутки. Сегодня приходит ответ.
Нет, всё понятно, плевать мы хотели на TTL ваших записей, у нас тут свой монастырь, но как можно в ответе написать про 48 часов, если прошло 84(!).
И что объяснить заказчику, который использует почту на mail.ru…
PS: Добавляю почтовые заголовки (RFC 822) успешно доставленного сообщения на ящик gmail.com, чтобы всё было видно.
UPDATE: Сегодня, 26 марта, в 12:47, практически по прошествию недели(!) с момента изменения PTR-записи на корректную smtp-сервер Mail.ru принял почту. Вот заголовки первого успешно доставленного сообщения:
Было бы очень интересно и полезно, как мне, так и другим заинтересованным в этой ветке получить комментарий от сотрудника Mail.ru, в чём же было дело — сегодня в «личку» мне пришло сообщение «Ходит ли уже почта сейчас?» от сотрудника Mail.Ru Group.
Официальный ответ получен. Всем спасибо за поддержку, советы, догадки, а quatro за подробный и честный ответ.