Reverse DNS lookups for dummies
Noto molta confusione relativamente ai record DNS di tipo PTR, usati per i cosiddetti “reverse DNS lookups”. Detta così, potrebbe sembrare una cosa da tecnici, una oscura specifica persa nei meandri di una qualche RFC. Solo che da un po’ di tempo il reverse DNS lookup viene usato anche – magari eccessivamente – come controllo antispam.
Vediamo quindi di capirci un minimo.
Se c’è un argomento informatico che richiede molta logica e molta capacità di paziente analisi, è quello legato ai protocolli di rete. Diversamente da altri argomenti, quali ad esempio la programmazione, qui non c’è assolutamente bisogno di creatività: si tratta di conoscere le basi, sapere come ciascun elemento risponde a una determinata azione, e avere una “matita mentale” con cui spuntare le cose già analizzate e tracciare i diagrammi.
Il sistema DNS non fa eccezione. Non ci sono misteri; non c’è niente da inventare. Solo uno schema da tenere a mente, sigle da riconoscere, e conseguenze da trarre. Se state leggendo questo blog, probabilmente sapete già cos’è un record DNS (altrimenti, leggete qui): nella sua forma più semplice, è una associazione tra il nome di una macchina in una rete e il suo indirizzo ip.
Questo, tuttavia, è solo un record di tipo A e non esaurisce i molti possibili casi. Esiste ad esempio il record CNAME, che associa un nome ad un altro nome, creando un alias; esiste il record MX, che ci indica qual è il server di posta “ufficiale” per un certo dominio; e altri ancora. Tra questi, quello che ci interessa è il record PTR, che effettua l’operazione contraria al record A: un record PTR associa a un indirizzo IP un determinato nome.
Anche se la sintassi è leggermente diversa, per semplicità possiamo quindi dire che un record A ha una forma del tipo
www.gibilogic.com > 91.187.200.67
mentre un record PTR è del tipo
91.187.200.67 > www.gibilogic.com
Alcune cose importanti
Innanzitutto, la presenza di un record PTR non è affatto scontata. In altre parole, il fatto di aver creato un record A che associa il nome www.gibilogic.com al suo indirizzo ip non crea automaticamente anche il relativo record PTR. E’ vero che esistono strumenti grafici di gestione del DNS che ci aiutano, proponendoci come opzione o come richiesta interattiva la possibilità di far creare automaticamente anche il record PTR. Ma non è sempre così. Non avete idea di quanti server DNS vengono gestiti modificando a mano un file di testo chiamato “file di zona”…
Inoltre, il record PTR potrebbe avere anche informazioni non corrispondenti. Ad esempio, io potrei avere un record PTR su 91.187.200.67 che porta a tutt’altro nome. Questo perchè l’indirizzo IP viene solitamente gestito da un “ente superiore” che magari ha già creato tale record prima di venderci l’indirizzo IP.
Infine, possono esistere diversi record PTR per lo stesso indirizzo IP. Questo è abbastanza comprensibile: visto che possono esistere diversi nomi che puntano allo stesso indirizzo, è ovvio che quell’indirizzo può puntare a diversi nomi.
Quindi, cosa fare?
Il problema si pone soprattutto nel caso voi abbiate un server di posta e vogliate evitare di essere bloccati. Infatti, in tempi di spam abbondante, uno dei filtri si basa proprio su un controllo di questo tipo. Ad esempio, un server di posta A viene contattato da un server di posta B, che proviene dall’indirizzo IP “1.2.3.4” e dice di chiamarsi “mail.esempio.it”. Il server A, sospettoso, effettua un reverse DNS lookup sull’indirizzo 1.2.3.4, e se riceve come risposta “mail.esempio.it”, accetta la comunicazione; in caso contrario, ritiene che il server remoto stia:
- usando un indirizzo IP dinamico, solitamente usato dagli spammer (un indirizzo dinamico non potrà mai avere un PTR record attendibile);
- falsificando il suo nome.
Questo ragionamento è logico, ma non prevede tutti i casi: ci sono delle falle, che possono portare al blocco di server perfettamente validi.
Per evitare il problema, tuttavia, potete fare in modo che il vostro server di posta abbia un record PTR valido. Quindi:
- controllate con che HELO NAME si presenta il vostro server di posta
- verificate che sia corrispondente al nome host pubblico del server stesso
- fate creare al vostro provider (o al suo provider, o al provider del provider…) il record PTR necessario. Tale record, purtroppo, non fa parte della gestione del vostro dominio, ma può essere gestito solo da chi si occupa della “fetta” di indirizzi IP che comprende il vostro IP pubblico, solitamente un ente di alto livello che non rivende direttamente i servizi di hosting e housing.
luca
molto interessante, e ben scritto!
Ciao
Luca
Marc
Devo dire ke l’articolo è stato scritto molto bene ed è davvero chiaro (for dummies appunto) XD
Cmq grazie per la spiegazione, mi sarà moooolto utile…
Francesco
@Marc e @Luca:
grazie per aver commentato, siamo lieti di essere utili!
Ho approfittato dei commenti per tornare a verificare l’articolo e fare alcune piccole correzioni, al fine di essere ancora più chiaro.
Raffaele
Ottimo articolo!
Ho una domanda da farti. Se uno ha N siti in cui mette vari segmenti MX. Quindi ho tante zone quanti sono i siti.
Puoi mettere il segmento PTR a livello di sito oppure a livello di zona in-addr.arpa?
Ciao e grazie
Francesco
@Raffaele:
cito l’articolo:
“Infine, possono esistere diversi record PTR per lo stesso indirizzo IP. Questo è abbastanza comprensibile: visto che possono esistere diversi nomi che puntano allo stesso indirizzo, è ovvio che quell’indirizzo può puntare a diversi nomi.”
Quindi puoi senz’altro creare più record PTR, in modo che ce ne sia uno per ciascun host. Attenzione che tali record PTR non si creano nei vari file di zona dei singoli domini, ma sempre nel file di zona principale in-addr.arpa.
Spero di aver risposto alla tua domanda.
Francesco
Molto ben scritto il tuo articolo. Ho solo una domanda quando dici che il nome helo del server deve essere uguale al nome host pubblico, intendi dire ad esempio
helo name = “www.ilmiosito.com” ?
PErchè sto avendo problemi di invalid helo name, pur avendo settato correttamente un ptr record. Probabilmente l’helo name non è settato in modo giusto. Grazie per la risposta.
Francesco
@Francesco:
Sì, preferibilmente il parametro “helo name” dovrebbe essere uguale al nome host del server, ad esempio “posta.gibilogic.com”. Se su uno stesso host fai coincidere diversi servizi, ad esempio web e mail, puoi impostare manualmente il nome host “virtuale” del servizio di posta (su postfix è il parametro myhostname, che per default viene utilizzato anche come helo name).
Attenzione però che “invalid helo name” significa che è mal formato, NON che non corrisponde all’host name. E attenzione che il “sito” non c’entra: il server di posta non ha nulla a che fare con il servizio www.
GABRIELE
ottimo davvero molto esaudiente
Gianluca
Salve a tutti,
anche io volevo complimentarmi con Voi per la chiarezza che avete usato in questo articolo.
molto bravi
Saluti
Roberto
Ottimo articolo! Ho un dubbio, non ho capito una cosa, Poniamo che i mail server ufficiali del dominio pippo.it siano 1.1.1.1 e 1.1.1.2 e infatti se faccio un PTR record Check mi tornano i 2 indirizzi in-addr.arpa corretti ma voglio mandare mail anche dal server web 2.2.2.2. in questo caso nella zona del dominio pippo.it devo inserire solo il record ptr relativo all’ip 2.2.2.2? devo inserire record ptr per ogni IP pubblico che invia mail (quindi per 1.1.1.1, 1.1.1.2 e 2.2.2.2). Forse ha piùsense mettere nellazona dns di pippo.it un record SPF che autorizzi 2.2.2.2? Spero di essermi spiegato
Grazie e complimenti ancora per l’articolo
Francesco
@Roberto:
premetto che questo articolo è stato scritto ormai da qualche anno e non sono sicuro sia perfettamente aggiornato.
Detto questo, la risposta breve è che devi creare un record PTR anche per l’indirizzo 2.2.2.2. Infatti il controllo viene effettuato dagli altri server quando invii, quindi qualunque server di invio deve essere coperto.
Il record SPF è un altro tipo di risorsa che può aiutarti ma può anche essere inutile. Sta infatti al server di ricezione decidere quali controlli effettuare, se fidarsi di SPF o controllare i record PTR o che altro…