DNS inverso per spazio IP in affitto: record PTR, delega e posta

Il DNS inverso associa un indirizzo IP a un nome, tramite un record PTR. Per la maggior parte dei servizi è un dettaglio. Per un mail server no: Google richiede che ogni indirizzo che invia a Gmail abbia un record PTR il cui nome risolva di nuovo allo stesso indirizzo, e molti altri destinatari cercano la stessa corrispondenza. Con lo spazio in affitto il record si trova in una zona che per impostazione predefinita non controlli, quindi vale la pena sapere chi lo imposta e come.

Come funziona il DNS inverso

Una risoluzione diretta trasforma un nome in un indirizzo. Una risoluzione inversa trasforma un indirizzo in un nome, invertendo i suoi quattro numeri sotto un dominio speciale: il record PTR per 203.0.113.10 si trova in 10.113.0.203.in-addr.arpa. L’IPv6 funziona allo stesso modo sotto ip6.arpa, una cifra esadecimale alla volta.

La zona di un /24, in questo esempio 113.0.203.in-addr.arpa, viene delegata dal registro ai name server indicati per essa. Nella regione di servizio del RIPE NCC sono le righe nserver di un oggetto domain nel RIPE Database. Chi gestisce quei name server decide cosa dicono i record PTR.

dig -x 203.0.113.10 +short

Chi lo controlla per lo spazio in affitto

Il registro delega la zona inversa al titolare del blocco, quindi per lo spazio in affitto è chi te lo affitta, non tu. In pratica ci sono due soluzioni.

• Chi affitta imposta i record che chiedi. Invii il nome per ogni indirizzo, e chi affitta pubblica i record PTR. È la soluzione più semplice e basta quasi a tutti.
• Chi affitta ti delega la zona. Con un oggetto domain che punta ai tuoi name server, gestisci tu i record PTR. Funziona per un /24 intero. Per una parte più piccola, chi affitta può passarti solo i tuoi indirizzi con la delega classless descritta nell’RFC 2317: record CNAME nella sua zona che puntano a una zona sui tuoi name server.

In entrambi i casi chiedi prima che l’affitto inizi come si fanno le modifiche e quanto in fretta compaiono, perché un mail server a cui non puoi dare un nome corretto è un mail server che non consegna.

Cosa verificano i server di posta

Le linee guida per i mittenti di Google fissano la regola per ogni mittente, non solo per quelli massivi: “The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname.” (traduzione: “L’indirizzo IP pubblico di un server SMTP mittente deve avere un record PTR corrispondente che risolve a un hostname.”). Quell’hostname deve a sua volta avere un record A, o AAAA per l’IPv6, che risolve allo stesso indirizzo. È il forward-confirmed reverse DNS: dall’indirizzo al nome, e dal nome di nuovo allo stesso indirizzo. Gmail risponde a un record mancante o non corrispondente con un errore temporaneo o permanente, e da novembre 2025 applica le sue regole in modo più rigoroso.

Due abitudini vanno insieme. Usa lo stesso nome nel saluto che invia il tuo mail server (HELO o EHLO), e scegli nomi che sembrino un server e non un pool. Yahoo, che richiede il DNS inverso a ogni mittente, chiede record PTR “meaningful, non-generic” (traduzione: “significativi, non generici”), e alcuni filtri trattano un nome come 203-0-113-10.dynamic.example.net come il segno di una connessione domestica.

Configurarlo, passo per passo

1. Scegli un nome per ogni indirizzo di invio, sotto un dominio che controlli: mail1.example.com.
2. Crea il record diretto: mail1.example.com. A 203.0.113.10.
3. Imposta il record PTR: 10.113.0.203.in-addr.arpa. PTR mail1.example.com., tramite chi ti affitta il blocco o nella tua zona delegata.
4. Verifica entrambe le direzioni da una rete esterna alla tua:

dig -x 203.0.113.10 +short        # expect: mail1.example.com.
dig +short mail1.example.com A    # expect: 203.0.113.10

1. Fai usare al mail server lo stesso nome. In Postfix è myhostname = mail1.example.com.

Errori che bloccano la consegna

• Un record PTR senza un record A corrispondente. La risoluzione inversa funziona e la verifica diretta fallisce.
• Due record PTR per un indirizzo. Le verifiche non concordano su quale conti. Tienine uno.
• Un cambio di nome con un TTL lungo. I resolver continuano a servire il vecchio nome finché il TTL non scade. Abbassalo un giorno prima di un cambio pianificato.
• L’IPv6 dimenticato. Se il server invia su IPv6, il suo indirizzo IPv6 richiede lo stesso trattamento sotto ip6.arpa, con un record AAAA corrispondente.
• Una zona delegata su name server che smettono di rispondere. Il registro verifica i name server solo quando viene fatta la delega. Se poi smettono di funzionare, ogni risoluzione inversa del blocco fallisce con loro.

Dove entra RTM Networks

Il DNS inverso fa parte di ogni affitto senza costi aggiuntivi: dicci il nome per ogni indirizzo e impostiamo i record PTR (affitto IPv4). Se gli indirizzi invieranno email, la loro reputazione conta quanto i loro nomi, quindi controlliamo ogni blocco IPv4 che affittiamo rispetto alle blocklist prima della consegna e ogni giorno finché lo hai (mantenere pulito un blocco).