Обратный DNS-поиск

Что такое обратный DNS?

Обратный DNS (rDNS) это обратное направление обычного DNS. Если прямой DNS преобразует имя (kernelhost.com) в IP-адрес, то обратный DNS преобразует IP обратно в имя. Тип записи для этого PTR (Pointer). Обратные имена живут в двух выделенных пространствах имён: in-addr.arpa для IPv4 и ip6.arpa для IPv6, каждое строится из IP в обратном порядке октетов или ниблов.

Пример: IP 8.8.8.8 превращается в 8.8.8.8.in-addr.arpa. PTR-запрос по этому имени возвращает hostname (в данном случае dns.google). Для IPv6 адрес 2001:db8::1 превращается в 1.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, каждый шестнадцатеричный нибл адреса показан отдельно и в обратном порядке.

Кто контролирует PTR-запись? Владелец IP-диапазона, обычно это вышестоящий провайдер, хостинг-компания или ISP. Владельцы доменов не могут задавать PTR-записи сами, если только им не делегирован IP-диапазон (редкость, возможна для блоков /24 или больше). Для одиночного VPS PTR задаётся в панели управления хостинга или через тикет в поддержку.

FCrDNS: forward-confirmed reverse DNS

FCrDNS это главная причина вообще заботиться о PTR-записях. Идея простая: PTR-запись даёт hostname, дальше ты резолвишь этот hostname в прямом направлении через A или AAAA, и возвращённый IP должен совпасть с исходным. Если совпадает, PTR считается доверенной. Если нет, PTR считается подделанной и игнорируется всеми современными проверками.

Почтовые серверы (Postfix, Exim, OpenSMTPD) и спам-фильтры (SpamAssassin, rspamd, Postscreen) проверяют FCrDNS на каждое входящее соединение. Провал FCrDNS обычно добавляет от 1.0 до 3.5 баллов к спам-скору (часто этого хватает чтобы письмо улетело в спам), а многие крупные провайдеры (Gmail, Outlook, Yahoo) рвут соединение с ошибкой 550. Без валидного FCrDNS твой почтовый сервер фактически не существует.

Как этот инструмент проверяет FCrDNS: читаем PTR-запись, потом резолвим каждый возвращённый hostname в прямом направлении через A (IPv4) или AAAA (IPv6) и сравниваем полученные IP с исходным. Значок сразу подскажет: зелёный если подтверждено, жёлтый если прямой записи вообще нет, красный при несовпадении со списком того, куда оно реально указывает.

Типичные сценарии использования

Зачем эта тулза реально нужна в повседневной работе:

• Запуск почтового сервера: Перед отправкой первого письма с нового IP, PTR должен быть задан, а FCrDNS должен быть зелёным. Иначе Gmail, Outlook и остальные будут отклонять или прятать в спам каждое твоё письмо. Проверь здесь, поправь в панели хостера, проверь снова.
• Анализ спама: Когда тебе пришёл спам, проверь PTR исходного IP. Отсутствующая или сломанная PTR это сильный признак спама. PTR, указывающая на общее имя ISP-пула (dsl-broadband-pool-... и подобные), ещё один классический индикатор.
• Анализ логов и форензика: В логах засветился IP. Кто это? rDNS даёт hostname (часто что-то вроде ec2-..., crawler-..., cdn-...), а в связке с ASN расскажет про облачного провайдера, страну и организацию. За секунды решаешь, легитимный это бот, известный облачный клиент или кандидат на блокировку.
• Сетевые операции: При дебаге traceroute промежуточные хопы показываются по PTR. Маршрутизаторы по пути обычно имеют описательные PTR (frankfurt-edge1.isp.net, lhr-core2.example.com и т.п.), которые показывают географический и топологический путь твоего пакета.
• Жалобы на abuse: Нужно отправить abuse-репорт? PTR плюс ASN подскажут, к какому провайдеру обратиться (abuse@<org>). Без rDNS пришлось бы искать IP в базах whois (RIPE/ARIN), а это медленнее.

Как задать PTR-запись

PTR-записи задаются не на твоём авторитетном nameserver для прямой зоны. Они задаются в обратной зоне, которая делегируется владельцем IP (ARIN, RIPE, APNIC, LACNIC, AfriNIC) вниз до компании, держащей IP-блок. Для одиночного VPS или выделенного сервера это значит: попроси хостинг-провайдера задать PTR, не пытайся сделать это в своей DNS-панели.

Большинство хостеров предлагают самообслуживание PTR в личном кабинете. Для KernelHost VPS и выделенных серверов поле rDNS доступно прямо в панели управления сервером, а изменения PTR применяются за 5 до 10 минут. Для colocation IP стандартный процесс это тикет в поддержку с желаемым hostname для каждого IP.

Best practice для почты: PTR и HELO должны совпадать. Если твой почтовый сервер представляется как mail.example.com (HELO mail.example.com), то PTR для IP должна быть mail.example.com, и mail.example.com должен резолвиться через A обратно в этот IP. Все три выстроены в линию = FCrDNS зелёный = чистая репутация.

rDNS в KernelHost

Каждый VPS, выделенный сервер, почтовый и Minecraft сервер от KernelHost идёт с самообслуживанием PTR для IPv4 и IPv6. Hostname задаётся для каждого IP в панели управления, изменение применяется за минуты, тикет в поддержку не нужен. Для IP-блоков (/29 или больше) можно делегировать всю обратную зону на твои собственные nameserver.

Наш DNS-слой работает как DNSSEC-подписанный Anycast во Frankfurt и Wien, поэтому PTR-запросы из любой точки мира резолвятся за десятки миллисекунд. Если ты собираешься запускать почтовый сервер на новом IP и хочешь максимально чистую репутацию с первого дня, связка KernelHost rDNS + DKIM/SPF/DMARC в одной панели экономит типичный цикл дебага первого дня.

Часто задаваемые вопросы