Gli standard Internet richiedono DNS inverso per ogni dispositivo?

I requisiti relativi al DNS inverso sono confusi! Le persone spesso parlano di tutto ciò che non funziona se non è presente il DNS inverso, e questo sembra spaventoso. Anche nei casi in cui le applicazioni non richiedono DNS inverso, gli RFC sono spesso citati a supporto della creazione obbligatoria di record PTR.

Alcuni di questi RFC includono:

RFC1912 : errori operativi e di configurazione DNS comuni

Ogni host raggiungibile da Internet dovrebbe avere un nome. ... Assicurati che i tuoi record PTR e A corrispondano. Per ogni indirizzo IP, dovrebbe esserci un record PTR corrispondente nel dominio in-addr.arpa. Se un host è multihome, (più di un indirizzo IP) assicurati che tutti gli indirizzi IP abbiano un record PTR corrispondente (non solo il primo). La mancata corrispondenza dei record PTR e A corrispondenti può causare la perdita di servizi Internet simili alla mancata registrazione nel DNS.

RFC1033 : GUIDA ALLE FUNZIONI DEGLI AMMINISTRATORI DEL DOMINIO

Aggiunta di un host.

 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.

Nonostante tutto, alcune persone insistono ancora nel dire che la creazione di record PTR non è richiesta dagli standard che regolano l'amministrazione DNS. Quali sono i requisiti effettivi?

Risposta breve

Gli standard che regolano il funzionamento del DNS richiedono che tutti i dispositivi abbiano un record PTR corrispondente? No.

Gli standard per determinati protocolli richiedono PTRrecord che concordano con corrispondenti Ao AAAArecord? Sì.

Alcune applicazioni non governate da una RFC hanno gli stessi requisiti? Sì.

Un record PTR può puntare a un CNAME? Sì, ma il target CNAME deve essere il nome univoco del dispositivo in questione (e non un altro CNAME). ( RFC 2181§10.2 , RFC1034 §3.6.2 )

La creazione obbligatoria dei record PTR è una buona pratica? Comunemente creduto di sì, ma ha i suoi problemi.

Risposta lunga

Queste domande e risposte hanno lo scopo di contribuire a porre fine a un malinteso comune.

Una sezione tragicamente sottotitolata di RFC1796 si applica qui:

È purtroppo male diffuso l'idea che la pubblicazione come RFC offra un certo livello di riconoscimento. Non lo è, o almeno non più della pubblicazione su un normale diario. In effetti, ogni RFC ha uno stato, relativo alla sua relazione con il processo di standardizzazione di Internet: traccia informativa, sperimentale o standard (proposta di standard, bozza di standard, standard di Internet) o storica.

RFC1912 è informativo. RFC1033 non è chiaramente etichettato e ha una designazione ufficiale di SCONOSCIUTO , il che significa che è così vecchio che non dovrebbe essere considerato un riferimento per nulla . Non definiscono gli standard, né possono essere utilizzati per aumentare ufficialmente uno standard. Non dovrebbero mai essere citati nel contesto che implica che stanno definendo uno standard.

Pensa ai suggerimenti informativi di RFC come a buoni consigli e alle migliori pratiche comunemente accettate. Le raccomandazioni DNS inverse hanno senso a colpo d'occhio: seguire queste linee guida riduce il rischio di essere messo in situazioni in cui un'applicazione non funziona perché DNS inverso era necessario e non pianificato. Non puoi certo aspettarti che un amministratore DNS conosca ogni applicazione / protocollo che lo richiede, e purtroppo lo stesso tende ad essere vero per i proprietari dei servizi che richiedono tali record.

Detto questo, al di fuori di un'ottima automazione , anche le politiche obbligatorie per la creazione di record PTR creano inquinamento.

• È estremamente comune che i PTRrecord non vengano sincronizzati con i corrispondenti A/ AAAArecord poiché i dispositivi vengono disattivati, con il risultato di uno scorrimento di PTRdati fasulli nel tempo. Questi dati servono solo a fuorviare coloro che tentano di trattare tali informazioni come credibili. Alcuni proprietari di applicazioni non vedono l'ora di saltarci sopra quando cercano la causa di un problema fantasma. Il problema continuerà a peggiorare man mano che l'adozione di IPv6 diventa più comune, in particolare per gli amministratori DNS responsabili dello spazio IP delle dimensioni dell'operatore.
• Avere più record PTR per lo stesso indirizzo IP è piuttosto inutile e aderire ai consigli delle RFC informative porterà inevitabilmente a questo. Vedi: Perché non è consigliato più record PTR in DNS?

Che cosa è peggio: assenza di un record PTR o un record PTR impreciso? Se un protocollo si interrompe perché il suo standard richiede DNS valido, entrambi sono cattivi e quest'ultimo potrebbe effettivamente peggiorare . A parte questo, ognuno ha un'opinione diversa in merito. Va bene: sei libero di mettere insieme le politiche e gli strumenti che funzionano meglio per il tuo team e la tua azienda. Assicurati solo che si ridimensionino e producano risultati coerenti e ricorda che il DNS inverso sarà accurato solo quanto il tempo e la disciplina che i membri del tuo team devono dare.

Ma i record PTR mancanti causano il blocco di sshd!

Inoltre non è vero. La gente spesso confonde il confine tra assenza di un record PTR (NXDOMAIN), e rotto reverse DNS.

Una risposta di NXDOMAINcauserà un problema solo se si sta comunicando con un servizio che richiede il DNS inverso (FCrDNS) confermato in avanti. Server di posta, Kerberos, Oracle scan VIPs, ecc.

Il DNS inverso rotto è quando è impossibile per te ottenere una NXDOMAINrisposta in modo tempestivo. Molte applicazioni (la più nota sshd) bloccheranno la ricerca DNS inversa se si verificano problemi nell'acquisizione tempestiva di una risposta da fonti upstream, causando ritardi all'interno dell'applicazione.