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ą PTR
zapisów zgodnych z odpowiednimi A
lub AAAA
zapisami? 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
PTR
rejestrów nie być zsynchronizowany z odpowiadającymi im A
/ AAAA
ewidencji jako urządzenia są wycofane z eksploatacji, w wyniku pełzania fałszywych PTR
danych 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ź NXDOMAIN
spowoduje 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ć NXDOMAIN
odpowiedzi 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.
sshd
reaguje powoli można uniknąć poprzez umieszczenieUseDNS no
wsshd_config
. (Ale nawet jeśli możesz obejść ten problem, oczywiście nadal nie można go zaakceptować, jeśli odwróci się czas DNS lub wygeneruje odpowiedź na awarię serwera.)