rDNS / PTR
Reverse DNS — поиск имени по IP-адресу. Используется для логов («откуда пришёл запрос»), почтовых серверов (проверка HELO), безопасности, трассировки. Работает через специальную зону in-addr.arpa (IPv4) и ip6.arpa (IPv6) с записями типа PTR.
Как это выглядит
# Прямой резолвинг (A-запись)
example.com. → 192.0.2.42
# Обратный (PTR-запись)
192.0.2.42 → nginx.example.com.
Формат зоны
IPv4-адрес 192.0.2.42 в reverse-зоне: октеты переворачиваются, добавляется .in-addr.arpa:
42.2.0.192.in-addr.arpa. IN PTR nginx.example.com.
Аналогично IPv6-адрес 2001:db8::1:
1.0.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.
IN PTR host.example.com.
Каждая ниббла (4 бита) — отдельный уровень, всего 32 уровня для IPv6.
Кто хостит зоны
Зоны in-addr.arpa и ip6.arpa делегированы RIR'ам (региональным реестрам):
| Диапазон | RIR |
|---|---|
| 62.0.0.0/8, 78.0.0.0/8, 85.0.0.0/8, ... | RIPE NCC (Европа + СНГ) |
| 3.0.0.0/8, 8.0.0.0/8, 24.0.0.0/8, ... | ARIN (Северная Америка) |
| 1.0.0.0/8, 43.0.0.0/8, 220.0.0.0/8, ... | APNIC (Азия) |
| 187.0.0.0/8, 190.0.0.0/8, 201.0.0.0/8, ... | LACNIC (Латинская Америка) |
| 102.0.0.0/8, 154.0.0.0/8, 197.0.0.0/8 | AFRINIC (Африка) |
RIR делегирует /24 или /48 сегменты провайдерам, те дальше клиентам.
Как посмотреть
$ dig -x 8.8.8.8
;; ANSWER SECTION:
8.8.8.8.in-addr.arpa. 86400 IN PTR dns.google.
$ host 2001:4860:4860::8888
8.8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa
domain name pointer dns.google.
$ nslookup 8.8.8.8
Server: ...
Name: dns.google
Address: 8.8.8.8
Настройка rDNS для своего VPS
Ты обычно не хостишь свою reverse-зону — провайдер уже делегировал её сам. Что делаешь:
- Заходишь в панель провайдера (Hetzner, DigitalOcean, OVH, TimeWeb).
- Ищешь «Reverse DNS», «PTR record».
- Указываешь желаемое имя, скажем
mail.example.com. - Провайдер обновляет свою reverse-зону.
- Через несколько минут
dig -x <твой IP>вернёт имя.
Forward Confirmed rDNS (FCrDNS)
Проверка «A и PTR указывают друг на друга»:
- PTR:
1.2.3.4→mail.example.com - A:
mail.example.com→1.2.3.4✅
Если оба совпадают — FCrDNS проходит. Почтовые серверы (Google, Microsoft, Mail.ru) отклоняют почту без FCrDNS. Настроить корректно — обязательно для собственных SMTP-серверов.
Приватность и вежливость
PTR-запись часто раскрывает лишнее: customer-95-30-118-172.msk.gigahost.ru. Скрывает регион, провайдера, иногда номер клиента.
Многие провайдеры дают дефолтные PTR:
- Hetzner:
static.NN-NN-NN-NN.clients.your-server.de - DigitalOcean:
NN-NN-NN-NN.example.com(задаётся именем droplet) - AWS EC2:
ec2-NN-NN-NN-NN.region.compute.amazonaws.com
rDNS в SMTP
Почтовый сервер получателя проверяет:
- PTR клиента подставлен и валиден.
- FCrDNS проходит.
- PTR-имя не выглядит «динамическим» (типа
host-95-108-...в некоторых блоклистах). - HELO/EHLO имя совпадает с PTR (не обязательно, но плюс).
Плюс дополнительно — SPF, DKIM, DMARC.
Классlessness
Для сегментов меньше /24 (например, /29 = 8 адресов) стандартное делегирование не работает — reverse-зона всё равно на границе /24. Решается через RFC 2317 — CNAME-цепочка:
# Провайдер держит 0/29.2.0.192.in-addr.arpa и делегирует тебе
;; в parent-zone
0/29.2.0.192.in-addr.arpa. IN NS ns.yourcompany.com.
1.2.0.192.in-addr.arpa. IN CNAME 1.0/29.2.0.192.in-addr.arpa.
...