Dlaczego wiele rekordów PTR w DNS nie jest zalecane?

I często przeczytać , że przy użyciu wielu rekordów PTR w konfiguracji DNS nie jest zalecane.

Przyczyny są jednak często niejasne lub nie tak oczywiste, że nazywa się:

„może powodować problemy”,
„może powodować błędy w programach oczekujących jednej odpowiedzi”: to problem oprogramowania, prawda ?!
„może sprawić, że pakiet odpowiedzi DNS będzie zbyt duży”: czy nie jest to naprawione w EDNS ?

Czy to są dobre powody? Czy znasz jakieś inne (dobre) powody? Wszystko to wygląda jak „stary strach” ...

— Totor
źródło

Dlaczego chcesz mieć wiele rekordów PTR dla jednego adresu IP? Nie mogę wymyślić powodu, który miałby sens.

— Per von Zweigbergk,

@PervonZweigbergk Nie o to pytałem, ale na przykład dlatego, że mam kilka nazw wskazujących na ten sam adres IP i chcę, aby odwrotność pasowała do nich wszystkich.

— Totor

@PervonZweigbergk Wyobraź sobie serwer pocztowy, który obsługuje pocztę dla wielu domen. Możesz użyć nazwy w domenie, do której wysyłasz pocztę w EHLOpoleceniu. Niektórzy odbiorcy wymagają, abyś PTRw swoim EHLOpoleceniu posiadał rekord pasujący do domeny, w przeciwnym razie nie przyjmą wiadomości od ciebie. Ale jeśli masz wiele PTRrekordów, mogą po prostu wybrać jeden z nich losowo, a jeśli ten nie pasuje do EHLOpolecenia, odrzuca pocztę.

— kasperd

Wiem, że nie o to pytałeś, dlatego zapytałem o to w komentarzu, a nie w odpowiedzi. :-) Nigdy nie wspominałeś o jakiej aplikacji mówisz. Dobrze by było, abyś był bardziej wyraźny, mówiąc o kontekście wychodzących wiadomości e-mail, o czym spekuluje @kasperd.

— Per von Zweigbergk,

@kasperd Podejrzewam, że ktoś może chcieć to zrobić, ale jest to niekonwencjonalne i niepotrzebnie powoduje problematyczną sytuację, o którą chodzi w tym pytaniu. Oczekuje się, że serwer pocztowy użyje tylko jednej nazwy w swoich EHLOpoleceniach, niezależnie od tego, dla ilu domen obsługuje pocztę. Nazwa w HELO/ EHLOma identyfikować sam serwer pocztowy, a nie odnosić się do adresów e-mail MAIL FROMlub From.

— Håkan Lindqvist

Odpowiedzi:

PTRRekord odwrotnej nazwę (np 7.2.0.192.in-addr.arpaOczekuje się), aby zidentyfikować nazwę kanoniczną , który jest skojarzony z tym adresem IP.

Zarówno wskaźniki bramy w węzłach sieci, jak i normalne wskaźniki hostów w pełnych węzłach adresu używają RR PTR, aby wskazywać z powrotem na nazwy domen głównych odpowiednich hostów.

Od: http://tools.ietf.org/html/rfc1035#section-3.5

Oczekiwania te znajdują odzwierciedlenie w oprogramowaniu, które dokonuje wyszukiwania wstecznego; często takie oprogramowanie oczekuje konkretnie pojedynczej nazwy i oczekuje, że będzie w stanie używać tej nazwy jako nazwy kanonicznej dla tego hosta. Jeśli zwróconych jest wiele nazwisk, często wybierane są losowo, ponieważ absolutnie nie mają możliwości sprawdzenia, które z nich wybrałbyś na tę szczególną okazję.

Ponieważ ogólne oczekiwania są takie, że istnieje jedna nazwa kanoniczna powiązana z adresem IP i ta nazwa jest tym, na co PTRpowinna wskazywać, dodawanie wielu nazw zasadniczo nie ma dodatniej strony (nic nie oczekuje, że dowolny losowy A/ AAAArekord będzie pasował PTR), ale ma potencjał minus, ponieważ może to powodować dziwne wyniki, ponieważ nie masz kontroli nad tym, które z twoich PTRrekordów zostaną użyte, jeśli dodasz więcej niż jeden.

Zasadniczo, jeśli masz wiele PTRrekordów, w rzeczywistości nie czynisz hosta bardziej wiarygodnym, ale wręcz przeciwnie, ryzykujesz nieudaną weryfikację lub inne uszkodzenie.

Jako być może nieco ekstremalna metafora, przekazanie pięciu paszportów wszystkim ze swoim zdjęciem, ale o różnych nazwiskach na lotnisku, prawdopodobnie nie zostanie odebrane tak dobrze, jak w przypadku wręczenia jednego.

— Håkan Lindqvist
źródło

Opracowanie „jednej nazwy kanonicznej”: w przypadkach, w których adres IP może być powiązany z więcej niż jedną jednostką, preferowana jest najbardziej konkretna. W przypadku serwera z wieloma wirtualnymi hostami opartymi na nazwach, nazwa samego serwera jest najbardziej odpowiednia. Jest to jeden z tych przypadków, w których próba podążania za radą informacyjnych RFC ( PTRzawsze zgadzających się z Azapisami) jest całkowicie niepotrzebna.

— Andrew B,

„ Oczekuje się, że rekord PTR pozwoli zidentyfikować”: przez kogo? Wygląda to jak zasada de facto , ponieważ twórcy oprogramowania zaczęli uważać, że tylko jeden PTR jest normą. Czy mam rację?

— Totor

@Totor Dodano ofertę i link do źródła.

— Håkan Lindqvist

Jako anegdotę ostatnio zauważono, że Apple ma kilka rekordów PTR, które mają ponad 9k bajtów odpowiedzi. Bez wątpienia nie są jedynymi. Jest to raczej skrajny przykład tego, co możesz skończyć, gdy obowiązkowe zasady dotyczące rekordów PTR nie uwzględniają szczegółów tej odpowiedzi.

— Andrew B,

Wszystko sprowadza się do nieprzewidywalnego zachowania, ponieważ RFC nie narzuca limitu ani sposobu obsługi tych rekordów PTR. Większość implementacji wybierze round-robin i nie osiągniesz pożądanego rezultatu (idealne dopasowanie wielu nazw do jednego adresu IP).

Możesz przeczytać więcej na ten temat tutaj: https://supernoc.rogerstelecom.net/pdfs/multiple-ptrs.pdf

Sprawdź także ten błąd w funkcji getnameinfo Glibc ( https://sourceware.org/bugzilla/show_bug.cgi?id=5790 ). Jak możesz zagwarantować, że tak się nie dzieje w nieskończonej liczbie różnych systemów w Internecie (niektóre z nich są bardzo stare i niezałatane)?

Aby wzmocnić, jako ogólną zasadę, zawsze dobrze jest unikać zachowań, które są nieokreślone i nieprzewidywalne. Niestety, wiele rekordów PTR dla jednego adresu IP należy do tej kategorii (jeśli chodzi o RFC).

— Giovanni Tirloni
źródło

Jak możesz zagwarantować, że żaden problem nie występuje w „nieskończonej” liczbie różnych systemów w Internecie? Twoja odpowiedź jest miła, ale ten argument nie ma żadnej wartości. Co więcej, błędy klienta są nieistotne dla IMHO, z wyjątkiem przypadku, gdy ma to wpływ na „znaczną” ich liczbę.

— Totor

Jak możesz zagwarantować, że PTR będzie pasował do określonego rekordu przekazywania, jeśli masz wiele PTR?

Jest to szczególnie ważne w interakcjach serwera pocztowego, gdzie większość przychodzących serwerów SMTP sprawdza, czy przekazanie jest zgodne z odwrotnością

Całkiem trudne jest to, że masz wiele PTR i nie ma sposobu, aby zagwarantować, który PTR jest wybrany i czy pasuje do przekazanego do przodu połączenia

Najprostszym sposobem na zagwarantowanie idealnego dopasowania jest posiadanie jednego PTR, który pasuje do wpisu do przodu

— użytkownik274768
źródło