Czy standardy internetowe wymagają odwrotnego DNS dla każdego urządzenia?

Wymagania dotyczące odwrotnego DNS są mylące! Ludzie często mówią o tym, że wszystko się psuje, jeśli nie ma odwrotnego DNS, a to brzmi przerażająco. Nawet w przypadkach, gdy aplikacje nie wymagają odwrotnego DNS, często wymieniane są RFC na poparcie obowiązkowego tworzenia rekordów PTR.

Niektóre z tych RFC obejmują:

RFC1912 : Typowe błędy operacyjne i konfiguracyjne DNS

Każdy host z dostępem do Internetu powinien mieć nazwę. ... Upewnij się, że Twoje rekordy PTR i A są zgodne. Dla każdego adresu IP powinien istnieć pasujący rekord PTR w domenie in-addr.arpa. Jeśli host ma wiele baz, (więcej niż jeden adres IP) upewnij się, że wszystkie adresy IP mają odpowiedni rekord PTR (nie tylko pierwszy). Brak pasujących rekordów PTR i A może spowodować utratę usług internetowych, podobnie jak w ogóle brak rejestracji w DNS.

RFC1033 : PRZEWODNIK DZIAŁANIA ADMINISTRATORÓW DOMENY

Dodanie hosta.

 To add a new host to your zone files:

    Edit the appropriate zone file for the domain the host is in.

    Add an entry for each address of the host.

    Optionally add CNAME, HINFO, WKS, and MX records.

    Add the reverse IN-ADDR entry for each host address in the
    appropriate zone files for each network the host in on.

Mimo to niektóre osoby nadal nalegają, aby powiedzieć, że tworzenie rekordów PTR nie jest wymagane przez standardy rządzące administracją DNS. Jakie są aktualne wymagania?

Krótka odpowiedź

Czy standardy regulujące działanie DNS wymagają, aby wszystkie urządzenia miały zgodny rekord PTR? Nie.

Czy standardy niektórych protokołów wymagają PTRzapisów zgodnych z odpowiednimi Alub AAAAzapisami? Tak.

Czy niektóre aplikacje nieobjęte RFC mają takie same wymagania? Tak.

Czy rekord PTR może wskazywać na CNAME? Tak, ale celem CNAME musi być unikalna nazwa danego urządzenia (a nie innej CNAME). ( RFC 2181§10.2 , RFC1034 §3.6.2 )

Czy obowiązkowe tworzenie rekordów PTR jest najlepszą praktyką? Powszechnie się uważa, ale ma swoje własne problemy.

Długa odpowiedź

Niniejsze pytania i odpowiedzi mają na celu pomóc w rozwiązaniu powszechnego nieporozumienia.

Obowiązuje tu tragicznie niedoceniona sekcja RFC1796 :

Niestety, rozpowszechnione jest błędne przekonanie, że publikacja jako RFC zapewnia pewien poziom uznania. Nie, a przynajmniej nie więcej niż publikacja w zwykłym czasopiśmie. W rzeczywistości każdy RFC ma status związany z jego relacją z procesem standaryzacji Internetu: Informacyjny, Eksperymentalny lub Standardowy ślad (Proponowany standard, Wersja robocza, Standard internetowy) lub Historyczny.

RFC1912 ma charakter informacyjny. RFC1033 nie jest wyraźnie oznakowany i ma oficjalne oznaczenie UNKNOWN , co oznacza, że ​​jest tak stary, że nie powinien być traktowany jako odniesienie do czegokolwiek . Nie definiują one Standardów, ani nie można ich używać do oficjalnego rozszerzenia standardu. Nigdy nie powinny być cytowane w kontekście, który sugeruje, że definiują standard.

Pomyśl o sugestiach informacyjnych RFC jako dobrych radach i powszechnie przyjętych najlepszych praktykach. Zalecenia dotyczące odwrotnego DNS na pierwszy rzut oka mają sens: przestrzeganie tych wskazówek obniża ryzyko sytuacji, w której aplikacja nie działa, ponieważ odwrotny DNS był konieczny i nie został zaplanowany. Z pewnością nie można oczekiwać, że administrator DNS zna każdą aplikację / protokół, który tego wymaga, i niestety to samo dotyczy właścicieli usług żądających tych rekordów.

To powiedziawszy, poza bardzo dobrą automatyzacją , obowiązkowe zasady tworzenia rekordów PTR również powodują zanieczyszczenie.

• To bardzo powszechne dla PTRrejestrów nie być zsynchronizowany z odpowiadającymi im A/ AAAAewidencji jako urządzenia są wycofane z eksploatacji, w wyniku pełzania fałszywych PTRdanych w czasie. Dane te służą jedynie wprowadzeniu w błąd tych, którzy próbują traktować te informacje jako wiarygodne. Niektórzy właściciele aplikacji chętnie wskakują na nią, gdy szukają przyczyny problemu fantomowego. Problem będzie się nasilał, gdy adopcja IPv6 stanie się bardziej powszechna, szczególnie dla administratorów DNS odpowiedzialnych za przestrzeń IP wielkości operatora.
• Posiadanie wielu rekordów PTR dla tego samego adresu IP jest dość bezużyteczne, a przestrzeganie rad Informacyjnych RFCs nieuchronnie to spowoduje. Zobacz: Dlaczego wiele rekordów PTR w DNS nie jest zalecane?

Co gorzej: brak rekordu PTR lub niedokładny rekord PTR? Jeśli protokół się zepsuje, ponieważ jego standard wymaga prawidłowego DNS, oba są złe, a ten drugi może być gorszy . Poza tym każdy ma inne zdanie na ten temat. W porządku: możesz dowolnie łączyć zasady i narzędzia, które najlepiej pasują do Twojego zespołu i firmy. Upewnij się tylko, że skalują się i dają spójne wyniki, i pamiętaj, że odwrotny DNS będzie tak dokładny, jak czas i dyscyplina, którą muszą dać członkowie zespołu.

Ale brakujące rekordy PTR powodują zawieszenie sshd!

Również nieprawda. Ludzie często mylą linię między brakiem rekordu PTR (NXDOMAIN) a zepsutym zwrotnym DNS.

Odpowiedź NXDOMAINspowoduje tylko problem, jeśli komunikujesz się z usługą, która wymaga zwrotnego DNS potwierdzonego do przodu (FCrDNS). Serwery pocztowe, Kerberos, VIP skanują VIPy itp.

Zepsuty zwrotny DNS występuje wtedy, gdy nie można uzyskać NXDOMAINodpowiedzi w odpowiednim czasie. Wiele aplikacji (najbardziej znanych sshd) blokuje się podczas wyszukiwania wstecznego DNS, jeśli wystąpią problemy z uzyskaniem odpowiedzi ze źródeł upstream w odpowiednim czasie, powodując opóźnienia w aplikacji.