Reverse DNS dla dzierżawionej przestrzeni IP: rekordy PTR, delegacja i poczta

Reverse DNS odwzorowuje adres IP z powrotem na nazwę, przez rekord PTR. Dla większości usług to szczegół. Dla serwera pocztowego już nie: Google wymaga, aby każdy adres wysyłający do Gmaila miał rekord PTR, którego nazwa rozwiązuje się z powrotem na ten sam adres, a wielu innych odbiorców szuka tej samej zgodności. Przy przestrzeni dzierżawionej rekord znajduje się domyślnie w strefie, której nie kontrolujesz, więc warto wiedzieć, kto go ustawia i jak.

Jak działa reverse DNS

Zapytanie w przód zamienia nazwę na adres. Zapytanie odwrotne zamienia adres na nazwę, zapisując jego cztery liczby w odwrotnej kolejności w specjalnej domenie: rekord PTR dla 203.0.113.10 znajduje się pod 10.113.0.203.in-addr.arpa. IPv6 działa tak samo w ip6.arpa, po jednej cyfrze szesnastkowej.

Strefę dla /24, w tym przykładzie 113.0.203.in-addr.arpa, rejestr deleguje na wskazane dla niej serwery nazw. W regionie obsługi RIPE NCC są to linie nserver obiektu domain w RIPE Database. Kto prowadzi te serwery nazw, ten decyduje, co mówią rekordy PTR.

dig -x 203.0.113.10 +short

Kto go kontroluje przy przestrzeni dzierżawionej

Rejestr deleguje strefę odwrotną na posiadacza bloku, więc przy przestrzeni dzierżawionej jest nim wydzierżawiający, a nie Ty. W praktyce są dwa rozwiązania.

• Wydzierżawiający ustawia rekordy, o które prosisz. Wysyłasz nazwę dla każdego adresu, a wydzierżawiający publikuje rekordy PTR. To najprostsze rozwiązanie i wystarcza prawie wszystkim.
• Wydzierżawiający deleguje strefę na Ciebie. Z obiektem domain wskazującym Twoje serwery nazw sam zarządzasz rekordami PTR. Działa to dla całego /24. Dla mniejszego fragmentu wydzierżawiający może przekazać tylko Twoje adresy za pomocą delegacji bezklasowej opisanej w RFC 2317: rekordów CNAME w jego strefie, które wskazują strefę na Twoich serwerach nazw.

Tak czy inaczej, zapytaj przed rozpoczęciem dzierżawy, jak wprowadza się zmiany i jak szybko się pojawiają, bo serwer pocztowy, któremu nie możesz nadać właściwej nazwy, to serwer, który nie dostarcza poczty.

Co sprawdzają odbiorcy poczty

Wytyczne Google dla nadawców określają zasadę dla każdego nadawcy, nie tylko masowego: „The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname.” (tłumaczenie: „Publiczny adres IP wysyłającego serwera SMTP musi mieć odpowiadający mu rekord PTR, który rozwiązuje się na nazwę hosta.”). Ta nazwa hosta musi z kolei mieć rekord A, a dla IPv6 AAAA, który rozwiązuje się na ten sam adres. To forward-confirmed reverse DNS: adres na nazwę i nazwa z powrotem na ten sam adres. Gmail odpowiada na brakujący lub niezgodny rekord błędem tymczasowym lub trwałym, a od listopada 2025 egzekwuje swoje zasady ściślej.

Wiążą się z tym dwa nawyki. Używaj tej samej nazwy w powitaniu, które wysyła Twój serwer pocztowy (HELO lub EHLO), i wybieraj nazwy, które wyglądają jak serwer, a nie pula. Yahoo, który wymaga reverse DNS od każdego nadawcy, prosi o rekordy PTR, które są „meaningful, non-generic” (tłumaczenie: „znaczące, nie generyczne”), a niektóre filtry traktują nazwę taką jak 203-0-113-10.dynamic.example.net jako oznakę łącza domowego.

Konfiguracja krok po kroku

1. Wybierz jedną nazwę dla każdego adresu nadawczego, w domenie, którą kontrolujesz: mail1.example.com.
2. Utwórz rekord w przód: mail1.example.com. A 203.0.113.10.
3. Ustaw rekord PTR: 10.113.0.203.in-addr.arpa. PTR mail1.example.com., przez wydzierżawiającego lub w delegowanej strefie.
4. Sprawdź oba kierunki z sieci spoza własnej:

dig -x 203.0.113.10 +short        # expect: mail1.example.com.
dig +short mail1.example.com A    # expect: 203.0.113.10

1. Ustaw serwer pocztowy, by używał tej samej nazwy. W Postfiksie to myhostname = mail1.example.com.

Błędy, które psują dostarczanie

• Rekord PTR bez pasującego rekordu A. Zapytanie odwrotne działa, a sprawdzenie w przód zawodzi.
• Dwa rekordy PTR dla jednego adresu. Sprawdzenia nie zgadzają się, który się liczy. Zostaw jeden.
• Zmiana nazwy przy długim TTL. Resolvery podają starą nazwę, dopóki TTL nie wygaśnie. Obniż go dzień przed planowaną zmianą.
• Zapomniane IPv6. Jeśli serwer wysyła przez IPv6, jego adres IPv6 wymaga tego samego w ip6.arpa, z pasującym rekordem AAAA.
• Delegowana strefa na serwerach nazw, które przestają odpowiadać. Rejestr sprawdza serwery nazw tylko przy tworzeniu delegacji. Jeśli później zawiodą, razem z nimi zawiedzie każde zapytanie odwrotne dla bloku.

Gdzie pasuje RTM Networks

Reverse DNS jest częścią każdej dzierżawy bez dodatkowych opłat: podaj nazwę dla każdego adresu, a ustawimy rekordy PTR (dzierżawa IPv4). Jeśli z adresów będzie wysyłana poczta, ich reputacja liczy się tak samo jak nazwy, dlatego każdy dzierżawiony przez nas blok IPv4 sprawdzamy na czarnych listach przed dostarczeniem i codziennie, dopóki go masz (jak utrzymać blok w czystości).