Reverse DNS Lookup
Inserisci un indirizzo IPv4 o IPv6 e scopri istantaneamente a chi appartiene l'IP: record PTR, verifica FCrDNS, ASN e organizzazione di origine. Il controllo più importante in assoluto prima di mettere qualsiasi IP su internet, soprattutto per la posta. Il lookup viene eseguito da Frankfurt FRA01, senza logging.
Che cos'è il DNS inverso?
Il DNS inverso (rDNS) è la direzione opposta del DNS normale. Mentre il DNS diretto associa un nome (kernelhost.com) a un indirizzo IP, il DNS inverso associa l'IP a un nome. Il tipo di record dedicato è il PTR (Pointer). I nomi inversi vivono in due namespace specifici, in-addr.arpa per IPv4 e ip6.arpa per IPv6, costruiti a partire dall'IP con ottetti o nibble in ordine inverso.
Esempio: l'IP 8.8.8.8 diventa 8.8.8.8.in-addr.arpa. Una query PTR su questo nome restituisce l'hostname (in questo caso dns.google). Per IPv6 l'indirizzo 2001:db8::1 diventa 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa, con ogni nibble esadecimale dell'indirizzo mostrato separatamente e invertito.
Chi controlla un record PTR? Il proprietario del range IP, di solito il provider upstream, la società di hosting o l'ISP. I proprietari di dominio non possono impostare i record PTR autonomamente, a meno che il range IP non venga loro delegato (raro, possibile per blocchi /24 o più grandi). Per un singolo VPS il PTR si imposta dal pannello di controllo del provider o tramite ticket di supporto.
FCrDNS: forward-confirmed reverse DNS
FCrDNS è il motivo principale per cui i record PTR sono importanti. L'idea è semplice: il record PTR fornisce un hostname, poi quell'hostname viene risolto in avanti tramite A o AAAA e l'IP restituito deve coincidere con l'IP originale. Se coincide, il PTR è considerato attendibile. In caso contrario il PTR è considerato falsificato e ignorato dalla maggior parte dei controlli moderni.
I mail server (Postfix, Exim, OpenSMTPD) e i filtri antispam (SpamAssassin, rspamd, Postscreen) verificano FCrDNS su ogni connessione in ingresso. Un fallimento FCrDNS aggiunge tipicamente da 1.0 a 3.5 punti allo spam score (spesso sufficienti per finire nello spam) e molti grandi provider (Gmail, Outlook, Yahoo) rifiutano direttamente la connessione con un errore 550. Senza un FCrDNS valido, il tuo mail server di fatto non esiste.
Come questo tool verifica FCrDNS: leggiamo il record PTR, poi risolviamo in avanti ogni hostname restituito tramite A (IPv4) o AAAA (IPv6) e confrontiamo gli IP ottenuti con l'IP originale. Il badge te lo indica subito: verde se verificato, giallo se non esiste alcun record forward, rosso in caso di mancata corrispondenza con la lista degli IP a cui punta effettivamente.
Casi d'uso comuni
A cosa ti serve davvero questo tool nelle operazioni quotidiane:
- Messa in servizio di mail server: Prima di inviare la prima mail da un nuovo IP, il PTR deve essere impostato e FCrDNS deve essere verde. Altrimenti Gmail, Outlook e altri rifiuteranno o filtreranno come spam ogni mail inviata. Verifica qui, correggi dal pannello del provider, verifica di nuovo.
- Analisi dello spam: Quando ricevi spam, controlla il PTR dell'IP sorgente. Un PTR mancante o non valido è un forte indicatore di spam. Un PTR che punta a un nome generico di pool ISP (dsl-broadband-pool-... ecc.) è un altro classico indicatore.
- Analisi log e forense: Un IP compare nei tuoi log. Di chi è? Il rDNS fornisce l'hostname (spesso qualcosa come ec2-..., crawler-..., cdn-...) e combinato con l'ASN indica cloud provider, paese e organizzazione. Decidi in pochi secondi se si tratta di un bot legittimo, di un cliente cloud noto o di qualcosa da bloccare.
- Operazioni di rete: Quando esegui il debug di un traceroute, gli hop intermedi vengono mostrati tramite PTR. I router lungo il percorso hanno di solito PTR descrittivi (frankfurt-edge1.isp.net, lhr-core2.example.com ecc.) che indicano il percorso geografico e topologico dei tuoi pacchetti.
- Segnalazioni di abuso: Devi inviare una segnalazione di abuso? PTR più ASN ti indicano quale provider contattare (abuse@<org>). Senza rDNS dovresti consultare l'IP nei database whois di RIPE/ARIN, operazione più lenta.
Come impostare un record PTR
I record PTR non vengono impostati sul tuo nameserver autoritativo della zona forward. Vengono impostati sulla zona inversa, delegata dal proprietario dell'IP (ARIN, RIPE, APNIC, LACNIC, AfriNIC) fino alla società che detiene il blocco IP. Per un singolo VPS o server dedicato questo significa: chiedere al provider di hosting di impostare il PTR, non provare a configurarlo dal proprio pannello DNS.
La maggior parte dei provider di hosting offre la gestione self-service del PTR dal portale clienti. Per i VPS e i server dedicati KernelHost, il campo rDNS è disponibile direttamente nel pannello di gestione del server e le modifiche PTR sono attive entro 5-10 minuti. Per gli IP in colocation, la procedura standard è un ticket di supporto con l'hostname desiderato per ogni IP.
Best practice per la posta: PTR e HELO devono coincidere. Se il tuo mail server si presenta come mail.example.com (HELO mail.example.com), allora il PTR dell'IP deve essere mail.example.com e mail.example.com deve risolversi in A sullo stesso IP. Tutti e tre allineati = FCrDNS verde = reputazione pulita.
rDNS con KernelHost
Ogni VPS, server dedicato, mail server e server Minecraft di KernelHost include la gestione self-service del PTR sia per IPv4 sia per IPv6. Imposti l'hostname per ogni IP dal pannello di controllo e la modifica è attiva in pochi minuti, senza ticket di supporto. Per i blocchi IP (/29 o più grandi) l'intera zona inversa può essere delegata ai tuoi nameserver.
Il nostro piano DNS funziona in Anycast firmato DNSSEC tra Frankfurt e Vienna, così i lookup PTR da qualsiasi parte del mondo si risolvono in decine di millisecondi. Se stai per mettere in servizio un mail server su un nuovo IP e vuoi la reputazione più pulita possibile fin dal primo giorno, la combinazione di rDNS KernelHost + DKIM/SPF/DMARC nello stesso pannello ti risparmia il tipico ciclo di debugging del primo giorno.
Domande frequenti
Qual è la differenza tra lookup DNS e lookup DNS inverso?
Il lookup DNS diretto prende un hostname (kernelhost.com) e restituisce un IP tramite record A o AAAA. Il lookup DNS inverso prende un IP e restituisce un hostname tramite record PTR. I due sono indipendenti: si può modificare uno senza l'altro. FCrDNS è il controllo incrociato che verifica la loro coerenza.
Perché il mio IP non ha un record PTR?
Perché nessuno lo ha impostato. I record PTR non hanno un valore predefinito, il detentore del blocco IP (il tuo provider) deve impostarli per ogni IP. Per le connessioni consumer di solito l'ISP imposta automaticamente un nome generico di pool (qualcosa come dsl-host-...-isp.net). Per i clienti hosting la gestione del PTR si trova nel pannello del provider o tramite supporto.
Perché FCrDNS mostra mismatch anche se il PTR è impostato?
Perché l'hostname del PTR non si risolve in avanti sullo stesso IP. O mancano i record A o AAAA per quell'hostname, oppure puntano a un IP diverso. Per correggere: assicurati che il PTR sia esattamente l'hostname a cui puntano i tuoi record A/AAAA, ad esempio PTR = mail.example.com e A mail.example.com = lo stesso IP.
Il lookup viene registrato?
No. Non registriamo l'IP consultato, non impostiamo cookie di tracciamento e non chiamiamo alcuna API di terze parti tranne il servizio Team-Cymru DNS-Whois, che è una normale query DNS-TXT verso origin.asn.cymru.com (niente HTTP, nessuna API key). Cymru vede l'IP del nostro resolver e l'IP consultato, non il tuo IP.
Il tool supporta IPv6?
Sì, completamente. Inserisci un indirizzo IPv6 in qualunque notazione standard (compressa come 2001:db8::1 o estesa), il tool costruisce automaticamente il nome ip6.arpa corretto (con nibble invertiti) e consulta il record AAAA forward per FCrDNS.
Posso eseguire il lookup DNS inverso per IP privati (10.x.x.x, 192.168.x.x)?
No. I range di indirizzi privati e riservati (10/8, 172.16/12, 192.168/16, 127/8, link-local, multicast) non possono essere consultati tramite DNS pubblico, perché le loro zone inverse non sono delegate alla radice pubblica. Il PTR per IP privati è risolvibile solo all'interno della rete che li possiede, sul resolver locale.
Perché ci sono più record PTR per un solo IP?
Tecnicamente è lecito avere più record PTR per IP (un IP che serve più hostname) ed era comune all'epoca dello shared hosting. Oggi è sconsigliato per i mail server (solo uno dei PTR supererà FCrDNS per un dato HELO), tollerato per i web server e raro in generale. Se il tuo IP ha più di un PTR, decidi quale sia quello canonico e rimuovi gli altri.
rDNS / PTR è obbligatorio?
Per i mail server: sì, di fatto è obbligatorio. Senza un PTR pulito a livello FCrDNS la posta finisce nello spam o viene rifiutata. Per i web server: non obbligatorio ma consigliato (log più puliti, segnalazioni di abuso più semplici). Per servizi interni o workload cloud di breve durata: opzionale.
Tutti i prodotti KernelHost
Hai bisogno di più di semplici strumenti? Scopri la nostra offerta di hosting commerciale.