Rekord PTR i reverse DNS – czym są i kto je ustawia

DNS „w przód” i „wstecz”

Zwykły DNS odpowiada na pytanie jaki adres IP ma ta nazwa? – rekordem A dla IPv4 i AAAA dla IPv6. Odwrotny DNS odpowiada na pytanie przeciwne: jaka nazwa należy do tego adresu IP? Odpowiedź zapisuje się w rekordzie PTR (pointer).

Rekordy PTR nie znajdują się w strefie Twojej domeny, tylko w dwóch specjalnych gałęziach DNS: in-addr.arpa dla IPv4 i ip6.arpa dla IPv6. Adres IP zapisuje się w nich od tyłu, bo nazwy DNS stają się bardziej szczegółowe od prawej do lewej, a adresy IP – od lewej do prawej.

10.2.0.192.in-addr.arpa.  3600  IN  PTR  poczta.firma.pl.

W IPv6 adres rozwija się do pełnych 32 cyfr szesnastkowych, które odwraca się cyfra po cyfrze:

0.1.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  poczta.firma.pl.

Takich nazw raczej nie wpisuje się ręcznie – panel dostawcy prosi o adres IP i nazwę hosta, a resztę buduje sam.

Forward-confirmed reverse DNS

Sam rekord PTR niewiele dowodzi: kto zarządza adresem IP, może przypisać mu dowolną nazwę, nawet mail.google.com. Dlatego serwery odbiorców sprawdzają oba kierunki. Nazywa się to zwykle forward-confirmed reverse DNS (FCrDNS):

1. Pobierz rekord PTR adresu IP, z którego przyszło połączenie – otrzymasz nazwę hosta.
2. Pobierz rekordy A (lub AAAA) tej nazwy.
3. Sprawdź, czy jest wśród nich pierwotny adres IP.

PTR może ustawić tylko właściciel adresu IP, a rekord A – tylko właściciel domeny. Gdy oba się zgadzają, obie strony naprawdę są ze sobą powiązane. Dokładnie ten test opisują wytyczne Google dla nadawców: IP serwera nadawczego musi mieć rekord PTR wskazujący nazwę hosta, a ta nazwa – rekord A lub AAAA wskazujący z powrotem na ten sam adres.

10.2.0.192.in-addr.arpa.  PTR  poczta.firma.pl.
poczta.firma.pl.          A    192.0.2.10

Dlaczego serwery odbiorców go wymagają

Praktycznie każdy prawdziwy serwer pocztowy działa na stałym adresie IP z celowo ustawioną nazwą. Przejęte domowe komputery rozsyłające spam – nie: ich adresy nie mają rekordu PTR albo mają ogólnikowy, nadany przez operatora, w rodzaju host-192-0-2-10.dynamic.isp.example. Brak PTR lub PTR „generyczny” to więc jeden z najtańszych i najstarszych sygnałów spamu.

• Gmail wymaga poprawnego DNS w przód i wstecz dla adresów nadawczych od wszystkich nadawców, nie tylko masowych. Poczta, która tego nie spełnia, może zostać odrzucona albo trafić do spamu.
• Yahoo prosi o „poprawne, znaczące, niegeneryczne” rekordy PTR dla wszystkich adresów nadawczych i o unikanie nazw, które wyglądają jak dynamicznie przydzielane adresy.
• Wiele innych serwerów i filtrów antyspamowych obniża ocenę lub odrzuca pocztę z adresów bez działającego PTR.

Jak wygląda dobry rekord PTR

• Wskazuje nazwę serwera pocztowego, np. poczta.firma.pl, w domenie, którą zarządzasz.
• Ta nazwa wskazuje z powrotem na ten sam adres IP (opisany wyżej test FCrDNS).
• Nie jest generyczny: nie zawiera adresu IP ani słów takich jak „dynamic”, „dsl” czy „pool”, które kojarzą się z łączami domowymi.
• Najlepiej, żeby zgadzał się z nazwą, którą serwer przedstawia się w powitaniu SMTP (EHLO). To nie sztywna reguła, ale jedna spójna tożsamość wygląda lepiej niż trzy różne nazwy.
• Jeden adres IP – jeden rekord PTR. Kilka nazw dla jednego adresu bardziej szkodzi, niż pomaga.

Nazwa w PTR nie musi należeć do domeny, z której wysyłasz pocztę. Dostawca, który wysyła pocztę tysięcy domen klientów, używa dla swojego adresu jednej własnej nazwy, a Twoja domena jest uwierzytelniana przez SPF, DKIM i DMARC.

IPv6 też potrzebuje rekordu PTR

Jeśli Twój serwer pocztowy ma adres IPv6 i łączy się z odbiorcami przez IPv6, ten adres potrzebuje własnego rekordu PTR – rekord dla IPv4 go nie obejmuje. To częsta niespodzianka: serwer działa bez zarzutu po IPv4, dostaje adres IPv6, zaczyna go preferować i nagle poczta wraca. Gmail odrzuca taką wiadomość błędem 550 5.7.1 z informacją, że nie spełnia ona wytycznych dla wysyłki przez IPv6 dotyczących rekordów PTR i uwierzytelniania („does not meet IPv6 sending guidelines regarding PTR records and authentication”).

Ustaw więc PTR także dla adresu IPv6 (z pasującym rekordem AAAA dla nazwy hosta) albo skonfiguruj serwer tak, żeby nie wysyłał poczty przez IPv6.

Kto ustawia rekord PTR

Odwrotny DNS deleguje się razem z samymi adresami IP: regionalne rejestry internetowe (w Europie RIPE NCC) przekazują strefy odwrotne dla bloków adresów organizacjom, które je posiadają – operatorom, firmom hostingowym, platformom chmurowym – i to one decydują, co mówi PTR każdego adresu. W praktyce:

• Rejestrator domeny go nie ustawi. Rekord „PTR” dodany w panelu DNS domeny powstaje pod nazwą w Twojej domenie, o którą żaden serwer odbiorcy nigdy nie zapyta. Nie ma żadnego efektu.
• Na VPS-ie lub serwerze dedykowanym opcja nazywa się zwykle „reverse DNS” albo „rDNS” i znajduje się w ustawieniach sieci lub adresów IP u dostawcy. Wielu dostawców przyjmuje tylko nazwę, która już wskazuje na ten adres IP – dlatego najpierw dodaj rekord A.
• Niektóre platformy chmurowe wymagają osobnego wniosku, zanim w ogóle włączą odwrotny DNS albo wysyłkę na porcie 25 – sprawdź dokumentację swojego dostawcy.
• Na łączu domowym lub biurowym PTR kontroluje operator. W ofertach firmowych ze stałym IP czasem da się go ustawić, w domowych zwykle nie – a wiele serwerów i tak nie ufa poczcie z takich pul adresów.

Jeśli korzystasz z hostowanej poczty

Odwrotny DNS dotyczy serwera, który łączy się z odbiorcą – a przy hostowanej poczcie jest to serwer dostawcy, na adresie IP dostawcy. Nie masz tu nic do ustawienia, a nawet gdybyś chciał, nie możesz: nie zarządzasz jego adresami. Twoja część to rekordy we własnej domenie – MX, SPF, DKIM i DMARC.

Tak samo działa AnyMail: odwrotny DNS naszego adresu nadawczego konfigurujemy po naszej stronie, więc strona konfiguracji DNS nigdy nie poprosi Cię o rekord PTR. Podobnie z rekordami A i AAAA Twojej domeny – poczta ich nie potrzebuje, więc strona internetowa może zostać tam, gdzie jest.

Jak sprawdzić odwrotny DNS

dig -x 192.0.2.10 +short
# poczta.firma.pl.

dig A poczta.firma.pl +short
# 192.0.2.10

W Windows zapytanie wstecz wykonasz poleceniem nslookup 192.0.2.10. Żeby ustalić adres IP, z którego faktycznie przyszła wiadomość, otwórz jej oryginalne nagłówki i znajdź najwyższy wiersz Received: dodany przez serwer odbiorcy; wiele serwerów zapisuje w nim też nazwę z odwrotnego DNS, którą zobaczyło.