Co to jest Reverse DNS (rDNS) i dlaczego jest ważny dla serwerów pocztowych?

Reverse DNS (rDNS), czyli odwrotny system nazw domenowych, to mechanizm sieciowy służący do tłumaczenia numerycznego adresu IP z powrotem na przypisaną do niego czytelną nazwę domeny. Jest on absolutnie wymagany dla serwerów pocztowych, ponieważ filtry antyspamowe używają rDNS do weryfikacji tożsamości nadawcy, a brak poprawnie skonfigurowanego rekordu PTR powoduje natychmiastowe odrzucenie wysyłanych wiadomości e-mail. To brutalny weryfikator tożsamości w sieci. Działa to w tle każdej wysłanej wiadomości.

Większość administratorów traktuje konfigurację sieci po macoszemu. Skupiają się na rekordach A, MX czy TXT. Zapominają o fundamencie. Kiedy wysyłasz maila z własnego serwera na adres w domenie Gmail lub Outlook, serwer odbiorcy natychmiast sprawdza, z jakiego adresu IP przyszło połączenie. Następnie odpytuje globalny system DNS o to, jaka nazwa hosta kryje się pod tym konkretnym adresem. Jeśli odpowiedź brzmi „nie wiem” albo zwraca generyczną nazwę dostawcy domowego internetu, twoja wiadomość ląduje w koszu. Bez dyskusji. System po prostu ucina komunikację na poziomie protokołu SMTP.

Jak dokładnie działa odwrotny DNS w praktyce?

Zwykły DNS tłumaczy nazwę, na przykład poczta.twojafirma.pl, na adres IP, powiedzmy 192.168.1.100. Odwrotny DNS robi coś dokładnie przeciwnego. Bierze adres 192.168.1.100 i pyta sieć, jak nazywa się ta maszyna. Z technicznego punktu widzenia realizuje się to za pomocą specjalnej strefy domenowej o nazwie in-addr.arpa dla starych adresów IPv4 oraz ip6.arpa dla nowszej adresacji IPv6.

Adres IP jest odwracany. Jeśli twój serwer ma adres 198.51.100.25, system DNS szuka rekordu PTR pod adresem 25.100.51.198.in-addr.arpa. Wymaga to odpowiedniej delegacji uprawnień. Zrobiliśmy na wdrożeniu w zeszłym miesiącu migrację dużej platformy e-commerce na nowe serwery dedykowane w lokalnym centrum danych na Śląsku. Wszystko działało poprawnie na testach. Odpaliliśmy produkcję w poniedziałek rano. Nagle telefony od klientów zaczęły dzwonić bez przerwy, bo system nie wysyłał potwierdzeń zamówień na skrzynki w WP i Onecie. Okazało się, że dostawca serwera zapomniał zaktualizować delegację strefy odwrotnej dla naszej puli adresacyjnej. Poprawka zajęła trzy minuty w panelu. Przywrócenie reputacji IP trwało dwa tygodnie.

Prawda jest zresztą absolutnie taka, że dzwonienie na infolinię lokalnego dostawcy internetu żeby poprosić o delegację strefy rDNS to droga przez mękę. Siedzisz na słuchawce, a konsultant na pierwszej linii nawet nie wie jak przeliterować skrót PTR. Musisz eskalować zgłoszenie do inżynierów z trzeciej linii wsparcia, co zajmuje czasem kilka dni, podczas gdy twój serwer pocztowy po prostu leży i odbija maile od klientów. To jest kompletna paranoja, że w trzeciej dekadzie XXI wieku takie rzeczy nie są zautomatyzowane w prostym panelu bilingowym u mniejszych operatorów.

Dlaczego brak rekordu PTR niszczy dostarczalność e-maili?

Serwery pocztowe nienawidzą anonimowości. Spam to w zdecydowanej większości ruch generowany przez zainfekowane komputery domowe, botnety i tanie serwery VPS opłacane skradzionymi kartami kredytowymi. Spamerzy mogą łatwo kupić domenę i ustawić dla niej rekord A kierujący na dowolny adres IP. Nie mają jednak kontroli nad strefą odwrotną adresu IP. Tę kontrolę ma wyłącznie właściciel fizycznej infrastruktury sieciowej, czyli operator telekomunikacyjny lub duża firma hostingowa.

Dlatego duże systemy antyspamowe stosują mechanizm FCrDNS. Forward Confirmed reverse DNS to proces podwójnej weryfikacji.

• Serwer odbiorcy sprawdza adres IP nadawcy i odpytuje o jego rekord PTR, by uzyskać nazwę hosta. Trwa to ułamek sekundy i zależy od czasu odpowiedzi serwerów autorytatywnych. Jeśli proces ten zakończy się błędem, połączenie w wielu rygorystycznych środowiskach jest zrzucane zanim w ogóle dojdzie do przesłania komendy MAIL FROM, co pozwala oszczędzić zasoby procesora na skanowaniu treści samej wiadomości filtrami bayesowskimi.
• Następnie bierze tę uzyskaną nazwę hosta i odpytuje o jej rekord A.
• Adres IP uzyskany w drugim kroku musi idealnie pasować do adresu IP z kroku pierwszego.
• Brak dopasowania to koniec.

To jest system naczyń połączonych. Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Ustawiasz wszystko poprawnie w strefie domeny, ale zapominasz o rewersie na adresie IPv6, który serwer podniósł sobie domyślnie z autokonfiguracji interfejsu. Postfix radośnie wysyła maile po nowym protokole, a Google odrzuca je z komunikatem błędu 550-5.7.1. Wtedy serwer po prostu ODRZUCA cały ruch.

Czy rekord PTR musi dokładnie pasować do domeny nadawcy e-mail?

To najczęstsze nieporozumienie wśród początkujących administratorów. Rekord PTR dla adresu IP nie musi zgadzać się z domeną, z której wysyłasz wiadomość e-mail. Musi zgadzać się z nazwą hosta serwera pocztowego (tzw. HELO/EHLO name).

Wyobraź sobie sytuację, w której prowadzisz agencję marketingową. Obsługujesz pocztę dla pięćdziesięciu różnych klientów na jednym serwerze fizycznym. Każdy klient ma własną domenę. Nie możesz ustawić pięćdziesięciu rekordów PTR dla jednego adresu IPv4. Ustawiasz jeden. Twój serwer przedstawia się w sieci jako poczta.twoja-agencja.pl. Ten adres ma przypisany rekord A na IP 203.0.113.10. Odwrotny DNS dla 203.0.113.10 musi wskazywać na poczta.twoja-agencja.pl. Kiedy wysyłasz maila jako [email protected], serwer odbiorcy weryfikuje tożsamość maszyny wysyłającej, a nie samej domeny nadawcy w polu „From”. Do weryfikacji domeny nadawcy służą inne mechanizmy, takie jak SPF, DKIM oraz DMARC.

Jak samodzielnie sprawdzić konfigurację rDNS dla adresu IP?

Nie potrzebujesz skomplikowanych narzędzi. Wystarczy terminal w systemie Linux, macOS lub wiersz poleceń w Windowsie. Rzuciliśmy okiem na logi i okazuje się, że podstawowa diagnostyka rozwiązuje większość problemów na pierwszej linii wsparcia.

Używamy kilku podstawowych poleceń do odpytywania serwerów nazw.

Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku. Coraz więcej narzędzi analitycznych przenosi się do przeglądarki. Mimo to, twarda znajomość polecenia dig ratuje skórę na awaryjnych wdrożeniach u klienta w serwerowni bez dostępu do interfejsów graficznych.

Kto odpowiada za ustawienie odwrotnego DNS?

To jest miejsce, w którym ludzie tracą najwięcej nerwów. Masz wykupioną domenę u rejestratora A. Twój serwer VPS stoi w firmie B. Gdzie ustawiasz rekord PTR? Zawsze u właściciela adresu IP.

Rejestrator domeny nie ma nic do gadania w kwestii strefy odwrotnej. Zmieniasz te dane w panelu dostawcy serwera. Większość dużych graczy na rynku chmurowym udostępnia do tego proste pola tekstowe w ustawieniach instancji. Wpisujesz tam nazwę hosta, klikasz zapisz, a ich automatyczne skrypty przeładowują strefy DNS w tle. Problem pojawia się przy własnej adresacji PI (Provider Independent) z RIPE. Wtedy to ty, jako administrator sieci, musisz podnieść własne serwery DNS i poprosić RIPE o delegację konkretnej podsieci na twoje maszyny. Zmieniliśmy te zasady na robocie w zeszłym roku, przechodząc całkowicie na zarządzanie strefami przez zewnętrzne API, co ukróciło błędy ludzkie przy ręcznej edycji plików konfiguracyjnych demona BIND.

Jakie błędy najczęściej popełniają administratorzy przy konfiguracji?

Zawsze te same. Rutyna zabija czujność.

• Brak rDNS dla protokołu IPv6. Maszyny mają często podwójny stos sieciowy (Dual Stack). Administrator ustawia idealnie rekord PTR dla adresu IPv4, po czym oprogramowanie pocztowe preferuje wysyłkę po nowszym protokole. Odbiorca odrzuca ruch, bo adres IPv6 nie ma przypisanej nazwy.
• Niespójność nazwy hosta. Serwer uważa, że nazywa się srv1.lokalna-siec.local, a w rekordzie PTR wpisano poczta.firma.pl. Kiedy demon pocztowy nawiązuje połączenie, mówi „HELO srv1.lokalna-siec.local”. Odbiorca widzi rozbieżność między przywitaniem a rekordem z globalnego systemu nazw i odcina komunikację.

Wpływ rDNS na logi serwera pocztowego i analizę spamu

Jeśli czytasz logi swojego Postfixa lub Exima, widzisz dokładnie, jak bezlitosny jest to mechanizm. Kiedy twój serwer odbiera wiadomości z zewnątrz, odpytuje odwrotny DNS każdego nadawcy. W logach pojawiają się wpisy typu connect from unknown[198.51.100.7]. Słowo „unknown” to wyrok. Oznacza to, że system nie był w stanie przetłumaczyć tego adresu na nazwę.

Możesz skonfigurować swój serwer tak, by odrzucał takie połączenia na twardo. Dodajesz regułę reject_unknown_client_hostname w konfiguracji restrykcji SMTP. To odcina bez mała prawie pięćdziesiąt procent na plusie uderzając do przodu u wyników spamu próbującego dostać się na twoje skrzynki. Botnety rzadko kiedy mają poprawne rekordy PTR. Z drugiej strony, musisz uważać. Czasami małe firmy mają źle skonfigurowane serwery. Wdrożenie tak rygorystycznej zasady sprawi, że nie dostaniesz od nich faktury. To ciągłe balansowanie między bezpieczeństwem a użytecznością biznesową. Ucinasz zbyt dużo, biznes krzyczy. Puszczasz luźniej, użytkownicy toną w niechcianych ofertach przedłużenia gwarancji na samochód.

Warto spojrzeć na to z perspektywy list RBL (Real-time Blackhole Lists). Wiele z tych czarnych list automatycznie dopisuje adresy IP, które wysyłają maile bez poprawnego rDNS. Spamhaus, Barracuda czy Spamcop mają swoje sondy i pułapki w sieci. Jeśli uderzysz w ich serwer pułapkę bez rekordu PTR, twój adres IP ląduje na liście w ciągu kilku minut. Usunięcie go stamtąd po poprawieniu błędu wymaga ręcznego wypełniania formularzy i czekania na łaskę moderatorów.

Odwrócony DNS to nie jest jakaś nowa funkcja. To standard opisany w dokumentach RFC dekady temu. A jednak każdego dnia widzę administratorów, którzy próbują debugować problemy z dostarczalnością, grzebiąc w nagłówkach DKIM, podczas gdy ich serwer przedstawia się światu adresem z puli domowej neostrady. Masz tu do czynienia z binarną sytuacją. Albo masz to ustawione poprawnie, albo twoja poczta nie działa. Idź teraz do terminala, wpisz polecenie dig z flagą -x dla swojego adresu IP i sprawdź, czy wynik zgadza się z nazwą twojego hosta. Zrób to, zanim twoi użytkownicy zaczną zgłaszać problemy z niedochodzącymi wiadomościami do kontrahentów.

Często zadawane pytania (FAQ)

• Czym różni się zwykły DNS od odwrotnego DNS (rDNS)?
  Zwykły DNS tłumaczy czytelną nazwę domeny (np. domena.pl) na numeryczny adres IP. Odwrotny DNS robi proces odwrotny – pyta sieć o to, jaka nazwa hosta jest przypisana do konkretnego adresu IP.
• Gdzie ustawia się rekord PTR?
  Rekord PTR ustawia się u właściciela adresu IP, czyli najczęściej w panelu firmy hostingowej, dostawcy serwera dedykowanego lub operatora telekomunikacyjnego, a nie u rejestratora samej domeny.
• Czy brak rekordu PTR powoduje trafienie do spamu?
  Większość dużych dostawców poczty (jak Gmail, Outlook, Yahoo) w ogóle nie przyjmie wiadomości z serwera bez poprawnego rDNS. Wiadomość nie trafi nawet do folderu spam, lecz zostanie całkowicie odrzucona na poziomie protokołu SMTP.
• Czy rekord PTR musi być taki sam jak adres e-mail nadawcy?
  Nie. Rekord PTR musi zgadzać się z nazwą hosta serwera pocztowego (HELO/EHLO), z którego wychodzi wiadomość. Z jednego serwera można wysyłać maile dla setek różnych domen, mając tylko jeden główny rekord PTR.
• Jak sprawdzić mój własny rekord rDNS?
  W systemach Linux i macOS użyj polecenia terminala: dig -x TWOJ_ADRES_IP. W systemie Windows możesz użyć narzędzia nslookup wpisując nslookup TWOJ_ADRES_IP.
• Dlaczego IPv6 sprawia problemy z odwrotnym DNS?
  Administratorzy często konfigurują rDNS tylko dla starej puli IPv4. Kiedy serwer automatycznie zaczyna używać nowoczesnego stosu IPv6 do wysyłania poczty, odbiorcy odrzucają ruch ze względu na brak rekordu PTR dla nowego protokołu.

Bibliografia

1. Naukowa i Akademicka Sieć Komputerowa (NASK) – https://www.nask.pl
2. Internet Engineering Task Force (IETF) – https://www.ietf.org
3. The Spamhaus Project – https://www.spamhaus.org
4. RIPE Network Coordination Centre – https://www.ripe.net
5. Wydawnictwo Naukowe PWN – https://pwn.pl