Perché non sono consigliati più record PTR in DNS?

Ho letto spesso che l'uso di più record PTR in una configurazione DNS non è raccomandato.

Tuttavia, i motivi sono spesso vaghi o non così evidenti:

"può causare problemi",
"può innescare bug nei programmi in attesa di una sola risposta": è il problema del software, vero ?!
"può rendere il pacchetto di risposte DNS troppo grande": non è stato risolto con EDNS ?

Queste sono buone ragioni? Conosci altri (buoni) motivi? Tutto questo sembra un "timore ereditario" ...

— totor
fonte

Perché vuoi avere più record PTR per un singolo indirizzo IP? Non riesco a pensare a una ragione che avrebbe senso fare.

— Per von Zweigbergk,

@PervonZweigbergk Non è quello che ho chiesto, ma ad esempio perché ho diversi nomi che puntano allo stesso IP e voglio che il contrario corrisponda a tutti.

— Totor

@PervonZweigbergk Immagina un server di posta che gestisce la posta per più domini. È possibile che si desideri utilizzare un nome all'interno del dominio per cui si sta inviando posta nel EHLOcomando. Alcuni destinatari richiedono che tu abbia un PTRrecord corrispondente al dominio nel tuo EHLOcomando, altrimenti non accetteranno la tua posta. Ma se hai più PTRrecord, possono semplicemente sceglierne uno a caso e se quello non corrisponde al EHLOcomando, rifiuta la posta.

— Kasperd,

So che non è quello che hai chiesto, motivo per cui l'ho chiesto tramite un commento, non come una risposta. :-) Non hai mai menzionato di quale applicazione stai parlando. Faresti bene ad essere più esplicito che stai parlando del contesto della posta elettronica in uscita, che è ciò che @kasperd sta speculando.

— Per von Zweigbergk,

@kasperd Suppongo che qualcuno potrebbe volerlo fare, ma farlo non è convenzionale e causa inutilmente la situazione problematica di cui si tratta. Un server di posta dovrebbe utilizzare un solo nome nei suoi EHLOcomandi, indipendentemente dal numero di domini per cui gestisce la posta. Il nome in HELO/ EHLOdovrebbe identificare il server di posta stesso, non correlato agli indirizzi di posta elettronica MAIL FROMo From.

— Håkan Lindqvist,

Risposte:

Il PTRrecord per un nome inverso (ad es. 7.2.0.192.in-addr.arpa) Dovrebbe identificare il nome canonico associato a quell'indirizzo IP.

Sia i puntatori gateway sui nodi di rete che i normali puntatori host su nodi indirizzo completi utilizzano PTR RR per puntare indietro ai nomi di dominio primari degli host corrispondenti.

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

Questa aspettativa si riflette nel software che esegue ricerche inverse; spesso tale software si aspetta specificamente un singolo nome indietro e si aspetta di essere in grado di utilizzare quel nome come nome canonico per quell'host. Se vengono restituiti più nomi, è comune prenderne uno a caso perché non hanno assolutamente modo di sapere quale si sarebbe preferito per questa particolare occasione.

Poiché l'aspettativa generale è che ci sia un nome canonico associato a un indirizzo IP e quel nome è ciò a cui PTRdovrebbe puntare, l'aggiunta di più nomi generalmente non ha alcun lato positivo (nulla si aspetta che nessun casuale A/ AAAArecord abbia una corrispondenza PTR) ma ha un potenziale svantaggio in quanto può causare strani risultati in quanto non hai alcun controllo su quali dei tuoi PTRrecord verranno utilizzati se ne hai aggiunto più di uno.

In sostanza, se si dispone di più PTRrecord che in realtà non fanno apparire il proprio host più legittimo, ma piuttosto il contrario, si corre il rischio di fallire una convalida o di interrompere in altro modo qualcosa.

Come metafora forse un po 'estrema, consegnare cinque passaporti tutti con la tua foto ma con nomi diversi all'aeroporto non sarà probabilmente ricevuto così come se ne consegni solo uno.

— Håkan Lindqvist
fonte

Elaborazione su "un nome canonico": nei casi in cui l'indirizzo IP potrebbe essere associato a più di un'entità, si preferisce il più specifico. Nel caso di un server Web con host virtuali basati su più nomi, il nome del server Web stesso è più appropriato. Questo è uno di quei casi in cui cercare di seguire i consigli delle RFC informative ( PTRsempre d'accordo con il Arecord) è completamente a castello.

— Andrew B,

"Il record PTR dovrebbe identificare": da chi? Sembra una regola di fatto , poiché gli sviluppatori di software hanno iniziato a considerare che solo un PTR era la norma. Ho ragione?

— Totor

@Totor Aggiunti un preventivo e un collegamento per una fonte.

— Håkan Lindqvist,

Come aneddoto, è stato recentemente notato che Apple ha alcuni record PTR che hanno oltre 9k byte di risposte. Senza dubbio non sono i soli. Questo è un esempio piuttosto estremo di cosa si può finire quando le politiche sui record PTR obbligatori non prendono in considerazione i dettagli di questa risposta.

— Andrew B,

Tutto si riduce a comportamenti imprevedibili poiché la RFC non impone un limite o un modo per gestire questi record PTR. La maggior parte delle implementazioni sceglierà il round robin e non otterrai il risultato desiderato (abbinamento perfetto tra molti nomi a un singolo IP).

Puoi leggere di più su questo qui: https://supernoc.rogerstelecom.net/pdfs/multiple-ptrs.pdf

Inoltre, controlla questo bug dalla funzione getnameinfo di Glibc ( https://sourceware.org/bugzilla/show_bug.cgi?id=5790 ). Come puoi garantire che ciò non accada nell'infinito numero di sistemi diversi su Internet (alcuni dei quali molto vecchi e senza patch)?

Per rafforzare, come regola generale, è sempre bene evitare comportamenti non specificati e imprevedibili. Sfortunatamente, più record PTR per un singolo IP rientrano in quella categoria (per quanto riguarda le RFC).

— Giovanni Tirloni
fonte

Come puoi garantire che non si stia verificando alcun problema nel numero "infinito" di diversi sistemi su Internet? La tua risposta è buona ma questo argomento non ha valore. Inoltre, i bug dei client sono IMHO irrilevanti, tranne se ne viene influenzato un numero "significativo".

— Totor,

Come garantite che un PTR corrisponderà a un particolare record forward se avete più PTR?

Ciò è particolarmente importante nelle interazioni tra server di posta, in cui la maggior parte dei server SMTP di ricezione in entrata verificherà se l'inoltro corrisponde al contrario

Abbastanza difficile è che hai più PTR e nessun modo per garantire quale PTR è selezionato e che corrisponde al forward che hai dato nella connessione

Il modo più semplice per garantire una corrispondenza perfetta è avere un PTR che corrisponda a una voce in avanti

— user274768
fonte