RDAP vs WHOIS: la guida completa alla transizione (codici EPP, GDPR, blocco dominio)
Di CaptainDNS
Pubblicato il 17 marzo 2026
- WHOIS (porta 43) non è più obbligatorio dal 28 gennaio 2025 per i gTLD. 374 TLD lo hanno già disattivato.
- RDAP (RFC 9082/9083) lo sostituisce: risposte JSON strutturate, HTTPS nativo, accesso differenziato compatibile con il GDPR.
- I codici EPP (come
clientTransferProhibited) indicano lo stato di protezione del tuo dominio. Un dominio senza transfer lock è vulnerabile al furto. - Verifica i tuoi domini critici con uno strumento RDAP: stati EPP, date di scadenza, blocchi attivi.
Nel 2025, interrogare un server WHOIS è come inviare un fax: il protocollo funziona ancora, ma appartiene a un'altra epoca. Dal 28 gennaio 2025, l'ICANN non richiede più ai registri gTLD di mantenere un servizio WHOIS sulla porta 43. RDAP (Registration Data Access Protocol) è ormai l'unico protocollo obbligatorio per accedere ai dati di registrazione dei domini.
Questa guida copre la transizione completa: perché WHOIS è stato sostituito, come funziona RDAP, cosa significano i codici EPP mostrati nei risultati, come il GDPR ha trasformato l'accesso ai dati di contatto e i blocchi da attivare per proteggere i tuoi domini.
Testa i tuoi domini adesso
WHOIS: 40 anni di servizio, poi il pensionamento
Da RFC 812 (1982) alla fine ufficiale (2025)
WHOIS è stato formalizzato nel 1982 dalla RFC 812, in un'epoca in cui Internet contava poche centinaia di host. Il protocollo è minimalista: il client apre una connessione TCP sulla porta 43, invia un nome di dominio in testo semplice e riceve una risposta in testo libero. Nessun formato standardizzato, nessuna crittografia, nessuna autenticazione.
Per 40 anni, WHOIS ha svolto il suo ruolo: identificare i responsabili di un dominio. Ma le sue limitazioni tecniche sono diventate problemi critici man mano che Internet cresceva.
Timeline ICANN del sunset WHOIS
L'ICANN ha pianificato la transizione su diversi anni:
- 2015: pubblicazione delle RFC 7480-7484 (prima versione di RDAP)
- 2019: obbligo per tutti i registri gTLD di supportare RDAP in parallelo con WHOIS
- 2023: pubblicazione delle RFC 9082, 9083 e 9224 (versione consolidata di RDAP)
- 28 gennaio 2025: fine dell'obbligo di mantenere WHOIS sulla porta 43 per i gTLD
- Febbraio 2025: 74 registri gTLD disattivano il servizio WHOIS nel mese successivo al sunset
- Giugno 2025: il volume di richieste RDAP supera quello di WHOIS per la prima volta
- Settembre 2025: 374 gTLD hanno disattivato WHOIS
- Gennaio 2026: l'ICANN revoca l'accreditamento del registrar Brennercom per mancata implementazione di RDAP, un precedente che conferma che la conformità RDAP non è opzionale
Il ritmo della transizione è netto: a gennaio 2025, i registri gTLD elaboravano circa 122 miliardi di richieste WHOIS al mese contro 7 miliardi in RDAP. Ad agosto 2025, WHOIS era sceso a 49 miliardi (calo del 60 %) mentre RDAP raggiungeva 65 miliardi. L'inversione delle curve si è verificata a giugno 2025.
Lo stato varia in base al tipo di TLD. Per i gTLD, RDAP è obbligatorio e WHOIS è facoltativo. Per i ccTLD (.fr, .de, .uk), la migrazione resta volontaria perché questi registri non sono soggetti ai contratti ICANN. Circa il 60 % dei ccTLD ha implementato RDAP (in aumento del 12 % da gennaio 2025), ma alcuni pesi massimi come .de, .cn e .jp non dispongono ancora di un servizio RDAP.
Perché WHOIS doveva essere sostituito?
Cinque problemi strutturali rendevano WHOIS inadeguato:
- Nessun formato standardizzato: ogni registro restituisce i dati in un formato diverso. Analizzare le risposte WHOIS richiede codice specifico per registro.
- Nessuna crittografia: le richieste e le risposte transitano in chiaro sulla porta 43. Qualsiasi intermediario di rete può leggerle.
- Nessuna autenticazione: impossibile distinguere un ricercatore di sicurezza da uno spammer. Tutti ricevono gli stessi dati.
- Incompatibile con il GDPR: WHOIS espone per impostazione predefinita i dati personali del titolare (nome, indirizzo, email, telefono). Il GDPR vieta questa diffusione senza base giuridica.
- Nessuna internazionalizzazione: WHOIS non supporta Unicode. I nomi di dominio internazionalizzati (IDN) e i contatti non ASCII creano problemi.
RDAP: il successore moderno
Come funziona RDAP? (bootstrap IANA, richiesta HTTP, risposta JSON)
RDAP si basa su tre componenti:
1. Il bootstrap IANA: come trovare il server giusto?
A differenza di WHOIS, dove bisogna conoscere il server di ogni registro, RDAP utilizza un registro centralizzato mantenuto dall'IANA (RFC 9224). Questo file JSON elenca, per ogni TLD, l'URL del server RDAP corrispondente. Il client RDAP consulta questo file, identifica il server per il TLD cercato e invia la richiesta.
2. La richiesta HTTP: un semplice URL
GET https://rdap.verisign.com/com/v1/domain/captaindns.com
Nessun protocollo binario, nessuna porta esotica. È una richiesta HTTPS standard, compatibile con qualsiasi browser, client HTTP o strumento di automazione.
3. La risposta JSON: dati strutturati
Il server restituisce un oggetto JSON normalizzato dalla RFC 9083. Ogni campo ha un nome definito, un tipo preciso e una semantica documentata. Non serve più analizzare testo libero.
Confronto WHOIS vs RDAP
| Criterio | WHOIS | RDAP |
|---|---|---|
| Protocollo | TCP porta 43, testo semplice | HTTPS, JSON strutturato |
| Crittografia | Nessuna | TLS nativo |
| Formato di risposta | Testo libero, non standardizzato | JSON normalizzato (RFC 9083) |
| Autenticazione | Nessuna | OAuth 2.0, accesso differenziato |
| Internazionalizzazione | Limitata (ASCII) | Unicode completo (IDN supportato) |
| Scoperta del server | Manuale (hardcoded per TLD) | Automatica (bootstrap IANA, RFC 9224) |
| Conformità GDPR | Impossibile senza proxy | Nativa (redazione selettiva) |
| Stato ICANN (gTLD) | Opzionale dal 01/2025 | Obbligatorio |
In pratica: la stessa richiesta in WHOIS e in RDAP
Per rendere la differenza tangibile, ecco cosa restituiscono i due protocolli per captaindns.com.
Risposta WHOIS (testo semplice, porta 43):
Domain Name: CAPTAINDNS.COM
Registry Domain ID: 2925482234_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.infomaniak.com
Registrar URL: http://www.infomaniak.com
Updated Date: 2025-09-11T08:32:12Z
Creation Date: 2025-09-08T06:06:37Z
Registry Expiry Date: 2026-09-08T06:06:37Z
Registrar: Infomaniak Network SA
Domain Status: clientTransferProhibited
Name Server: CHELSEA.NS.CLOUDFLARE.COM
Name Server: HAL.NS.CLOUDFLARE.COM
DNSSEC: unsigned
Ogni registro formatta questa risposta in modo diverso. Nessuno schema condiviso, nessuna garanzia sull'ordine o sul nome dei campi.
Risposta RDAP (JSON strutturato, HTTPS):
{
"objectClassName": "domain",
"ldhName": "CAPTAINDNS.COM",
"status": ["client transfer prohibited"],
"events": [
{ "eventAction": "registration", "eventDate": "2025-09-08T06:06:37Z" },
{ "eventAction": "expiration", "eventDate": "2026-09-08T06:06:37Z" },
{ "eventAction": "last changed", "eventDate": "2025-09-11T08:32:12Z" }
],
"nameservers": [
{ "ldhName": "CHELSEA.NS.CLOUDFLARE.COM" },
{ "ldhName": "HAL.NS.CLOUDFLARE.COM" }
],
"secureDNS": { "delegationSigned": false },
"rdapConformance": [
"rdap_level_0",
"icann_rdap_technical_implementation_guide_1",
"icann_rdap_response_profile_1"
]
}
Gli stessi dati, ma in un formato prevedibile, tipizzato e analizzabile da qualsiasi libreria JSON. Il campo rdapConformance indica i profili ICANN rispettati dal server, un'informazione che non esisteva in WHOIS. Prova tu stesso con il RDAP Lookup.
Thin vs thick registry: perché due richieste per .com?
Per alcuni TLD come .com, i dati di registrazione sono distribuiti su due livelli:
- Il registro (Verisign per .com) conserva i dati minimi: nome di dominio, server dei nomi, date, stati EPP. È un registro "thin".
- Il registrar (il rivenditore: OVHcloud, Gandi, GoDaddy, ecc.) conserva i dati completi: contatto del titolare, informazioni di fatturazione, dettagli amministrativi.
Quando interroghi RDAP per un dominio .com, il registro Verisign restituisce i dati di base e include un link verso il server RDAP del registrar per i dati completi. Un client RDAP completo segue questo link automaticamente.
Altri TLD come .fr (AFNIC) sono registri "thick": tutti i dati sono centralizzati a livello di registro. Una sola richiesta è sufficiente.
Cifre chiave 2025
- 374 gTLD hanno disattivato WHOIS sulla porta 43
- 65 miliardi di richieste RDAP al mese elaborate dai registri gTLD (agosto 2025)
- 100 miliardi di richieste RDAP mensili su tutti i registri (gTLD, RIR, bootstrap IANA)
- 60 % dei ccTLD ha implementato un server RDAP (contro il 48 % a gennaio 2025)
- 100 % dei registri gTLD è tenuto a supportare RDAP
Copertura RDAP per tipo di TLD
Tutti i gTLD supportano RDAP, ma la copertura ccTLD è disomogenea. I registri nazionali non sono vincolati dai contratti ICANN e migrano al proprio ritmo.
| ccTLD | Paese | RDAP | Domini registrati (stima) |
|---|---|---|---|
| .uk | Regno Unito | Sì (dal 2022) | 10,5 M |
| .fr | Francia | Sì (dal 2022) | 4 M |
| .nl | Paesi Bassi | Sì (dal 2024) | 6,2 M |
| .br | Brasile | Sì (dal 2017, pioniere) | 5 M |
| .au | Australia | Sì (dal 2026) | 4,3 M |
| .de | Germania | No (solo WHOIS) | 17,4 M |
| .cn | Cina | No (solo WHOIS) | 20 M |
| .eu | Unione europea | No (solo WHOIS) | 3,6 M |
| .jp | Giappone | No (solo WHOIS) | 1,7 M |
| .ru | Russia | No (solo WHOIS) | 5 M |
| .us | Stati Uniti | No (solo WHOIS) | 1,8 M |
Per i ccTLD senza RDAP, il fallback resta WHOIS sulla porta 43. Se gestisci un portafoglio multi-TLD, i tuoi strumenti devono supportare entrambi i protocolli in parallelo.
Rate limiting e richieste automatizzate
Poiché i server RDAP sono semplici API HTTPS, implementano il rate limiting per evitare abusi (scraping massivo, recupero dati in bulk). Un client che supera la soglia autorizzata riceve una risposta HTTP 429 (Too Many Requests).
Buone pratiche per le richieste automatizzate:
- Rispetta l'header
Retry-After: quando il server restituisce un 429, può includere un header che indica il tempo di attesa prima di riprovare - Implementa un backoff esponenziale: aumenta il tempo tra ogni tentativo (1s, 2s, 4s, 8s) con una componente casuale per evitare raffiche sincronizzate
- Limita il tuo throughput: la maggior parte dei server tollera una o due richieste al secondo. Alcuni, come Cloudflare, limitano a 10 richieste per fascia di 10 secondi
- Memorizza i risultati in cache: i dati RDAP cambiano raramente. Una cache di qualche ora riduce il carico sui server e velocizza le tue elaborazioni
Codici EPP: comprendere gli stati del tuo dominio
I risultati RDAP includono i codici di stato EPP (Extensible Provisioning Protocol). Questi codici indicano lo stato attuale del tuo dominio: è protetto dal trasferimento? In attesa di eliminazione? Bloccato dal registro?
Due prefissi distinguono l'origine dello stato:
- client: impostato dal registrar (il tuo rivenditore), modificabile tramite la tua interfaccia di gestione
- server: impostato dal registro (Verisign, AFNIC, ecc.), modificabile solo dal registro
Codici di protezione (positivi)
Questi codici indicano che delle protezioni sono attive sul tuo dominio. La loro presenza è auspicabile.
| Codice EPP | Significato | Perché è importante |
|---|---|---|
clientTransferProhibited | Trasferimento bloccato dal registrar | Impedisce il furto di dominio tramite trasferimento non autorizzato |
serverTransferProhibited | Trasferimento bloccato dal registro | Protezione aggiuntiva, spesso legata a un registry lock |
clientDeleteProhibited | Eliminazione bloccata dal registrar | Impedisce l'eliminazione accidentale o dolosa |
serverDeleteProhibited | Eliminazione bloccata dal registro | Protezione a livello di registro contro l'eliminazione |
clientUpdateProhibited | Modifica bloccata dal registrar | Impedisce la modifica non autorizzata dei server dei nomi |
serverUpdateProhibited | Modifica bloccata dal registro | Protezione del registro contro le modifiche DNS |
Codici di allerta (critici)
Questi codici segnalano un problema o un'azione urgente necessaria.
| Codice EPP | Significato | Azione richiesta |
|---|---|---|
redemptionPeriod | Dominio eliminato, in periodo di grazia (30 giorni) | Contatta immediatamente il tuo registrar per il ripristino |
pendingDelete | Eliminazione definitiva imminente (5 giorni) | Ultima possibilità di recupero, contatta il registro |
serverHold | Risoluzione DNS sospesa dal registro | Il dominio non risolve più. Verifica gli obblighi presso il registro |
clientHold | Risoluzione DNS sospesa dal registrar | Spesso legato a un pagamento mancante o a una verifica d'identità in sospeso |
Codici transitori (informativi)
Questi codici indicano un'operazione in corso. Sono temporanei.
| Codice EPP | Significato | Durata tipica |
|---|---|---|
pendingTransfer | Trasferimento verso un altro registrar in corso | 5 giorni (periodo di approvazione) |
pendingCreate | Registrazione in fase di elaborazione | Da pochi minuti a qualche ora |
pendingRenew | Rinnovo in fase di elaborazione | Pochi minuti |
pendingUpdate | Modifica DNS in corso | Pochi minuti |
addPeriod | Periodo di grazia dopo la registrazione (cancellazione con rimborso possibile) | 5 giorni |
renewPeriod | Periodo di grazia dopo il rinnovo | 5 giorni |
transferPeriod | Periodo di grazia dopo il trasferimento | 5 giorni |
autoRenewPeriod | Dominio rinnovato automaticamente, cancellazione possibile | Da 30 a 45 giorni |
Tabella completa dei codici EPP
Lo stato ok (o active) è lo stato predefinito: indica che nessuna restrizione né operazione è in corso. Questo stato scompare non appena un altro codice di protezione o restrizione viene attivato.
Un dominio correttamente protetto mostra almeno clientTransferProhibited. Un dominio critico (marchio, sito principale) dovrebbe avere anche clientDeleteProhibited e clientUpdateProhibited.
Blocco di dominio: la protezione indispensabile
I 3 livelli di lock
Livello 1: registrar lock (transfer lock)
È il blocco di base, attivabile dall'interfaccia del tuo registrar. Imposta lo stato clientTransferProhibited e impedisce il trasferimento del dominio verso un altro registrar senza la tua autorizzazione esplicita.
Costo: gratuito presso la maggior parte dei registrar. Nessun motivo per non attivarlo.
Livello 2: registrar full lock
Oltre al transfer lock, questo livello aggiunge clientDeleteProhibited e clientUpdateProhibited. Il dominio non può essere né trasferito, né eliminato, né modificato (server dei nomi, contatti) senza disattivare manualmente i lock.
Costo: generalmente gratuito, ma non sempre attivato per impostazione predefinita.
Livello 3: registry lock
Il registro stesso blocca il dominio con gli stati serverTransferProhibited, serverDeleteProhibited e serverUpdateProhibited. Qualsiasi modifica richiede una procedura manuale presso il registro, spesso con verifica d'identità.
Costo: a pagamento (da 50 a 300 EUR/anno a seconda del TLD e del registrar). Riservato ai domini critici: marchi, siti e-commerce, infrastrutture.
Verificare i tuoi lock con RDAP Lookup
Per verificare lo stato dei tuoi blocchi, interroga il tuo dominio tramite uno strumento RDAP. Gli stati EPP restituiti indicano immediatamente quali lock sono attivi:
clientTransferProhibitedvisibile: transfer lock attivoclientDeleteProhibitedvisibile: delete lock attivoclientUpdateProhibitedvisibile: update lock attivo- Nessuno di questi stati, solo
ok: nessuna protezione attiva
Cosa fare se nessun lock è attivo?
Se il tuo dominio mostra solo lo stato ok senza alcun codice di protezione:
- Accedi all'interfaccia del tuo registrar
- Cerca l'opzione "blocco trasferimento", "transfer lock" o "domain lock"
- Attivala immediatamente
- Per i domini critici, attiva anche il delete lock e l'update lock se disponibili
- Verifica nuovamente tramite RDAP che gli stati
clientTransferProhibitedappaiano
Un dominio senza transfer lock può essere trasferito da un terzo che ottiene il codice di autorizzazione (authcode). Il furto di dominio resta una minaccia reale e gli incidenti recenti lo confermano.
Caso reale: il dirottamento massivo durante la migrazione Google Domains verso Squarespace (2024)
A luglio 2024, l'acquisizione dei domini Google Domains da parte di Squarespace ha provocato uno degli incidenti di domain hijacking più documentati dell'anno. Tra il 9 e il 12 luglio, degli attaccanti hanno preso il controllo di domini appartenenti a importanti aziende crypto: Celer Network, Compound Finance, Pendle Finance e Unstoppable Domains, tra le altre.
La falla: Squarespace aveva migrato circa 10 milioni di nomi di dominio da Google Domains, ma senza richiedere la verifica via email durante la creazione dell'account. Gli attaccanti hanno potuto creare account utilizzando gli indirizzi email associati ai domini migrati, prima che i titolari legittimi lo facessero. Una volta connessi, hanno modificato i record DNS per reindirizzare il traffico verso siti di phishing.
L'autenticazione multi-fattore non era attivata per impostazione predefinita sugli account migrati, e la piattaforma non forniva né registro di audit né notifica email per le azioni sugli account.
Questo incidente illustra perché i blocchi EPP sono essenziali. Un dominio con clientUpdateProhibited attivo non avrebbe potuto vedere i suoi server dei nomi modificati, anche dopo una compromissione dell'account. Le protezioni EPP agiscono come una rete di sicurezza indipendente dalla sicurezza dell'account registrar.
WHOIS, RDAP e GDPR: quali dati restano visibili?
Prima del GDPR (2018)
Prima di maggio 2018, una richiesta WHOIS restituiva tutti i dati del titolare senza restrizioni:
- Nome completo e organizzazione
- Indirizzo postale completo
- Email, telefono, fax
- Contatti amministrativo e tecnico
Questi dati venivano sfruttati massicciamente: spam mirato, phishing, furto d'identità, molestie ai titolari. I servizi di "WHOIS privacy" venduti dai registrar erano l'unica difesa.
Dopo il GDPR: redazione selettiva vs mascheramento totale
Il GDPR (General Data Protection Regulation), in vigore da maggio 2018, ha imposto un cambiamento radicale. I dati personali non possono più essere diffusi senza base giuridica. I registri e i registrar hanno adottato due approcci:
Redazione selettiva: i dati personali (nome, indirizzo, email, telefono) vengono mascherati o sostituiti con menzioni generiche ("REDACTED FOR PRIVACY"). I dati tecnici (server dei nomi, date, stati EPP) restano visibili.
Mascheramento totale: alcuni registri restituiscono un minimo assoluto di informazioni. Solo il nome di dominio, le date e gli stati vengono esposti.
In pratica, una richiesta RDAP nel 2026 restituisce tipicamente:
| Dato | Visibile? |
|---|---|
| Nome di dominio | Sì |
| Registrar | Sì |
| Date (creazione, scadenza, aggiornamento) | Sì |
| Stati EPP | Sì |
| Server dei nomi | Sì |
| Nome del titolare | No (mascherato) |
| Indirizzo del titolare | No (mascherato) |
| Email del titolare | No (mascherato o email relay) |
| Telefono del titolare | No (mascherato) |
Accesso differenziato RDAP (anonimo, autenticato, privilegiato)
RDAP integra nativamente un sistema di accesso differenziato, cosa che WHOIS non poteva offrire:
Accesso anonimo: solo dati pubblici (nome di dominio, date, stati, server dei nomi). È ciò che restituisce una richiesta RDAP standard.
Accesso autenticato: tramite un token OAuth 2.0, un utente identificato può accedere a dati supplementari. Ad esempio, il titolare di un dominio può consultare le proprie informazioni complete.
Accesso privilegiato: riservato alle forze dell'ordine, agli organismi di protezione della proprietà intellettuale e ai team di cybersicurezza accreditati.
SSAD e RDRS: verso un accesso standardizzato ai dati non pubblici
L'ICANN ha progettato l'SSAD (System for Standardized Access/Disclosure) per formalizzare l'accesso ai dati non pubblici dei domini. Il progetto, derivato dal processo EPDP Fase 2, copre 18 raccomandazioni interdipendenti: accreditamento dei richiedenti, criteri di richiesta, requisiti di risposta, registrazione e livelli di servizio.
In pratica, l'SSAD non è mai stato implementato così com'è. La valutazione operativa di gennaio 2022 ha rivelato un costo e una complessità sproporzionati. L'ICANN ha quindi lanciato il RDRS (Registration Data Request Service) come sistema di transizione. Dal suo lancio, più di 13 000 account di richiedenti unici sono stati creati nel RDRS, inviando circa 3 600 richieste di divulgazione di dati non pubblici ai registrar gTLD.
A ottobre 2025, il consiglio di amministrazione dell'ICANN ha prorogato il RDRS fino a dicembre 2027. Durante questo periodo, l'ICANN migliora l'interfaccia utente e sviluppa un protocollo di autenticazione dedicato alle forze dell'ordine. Il RDRS resta un sistema di transizione: la comunità ICANN dibatte ancora sulla sua evoluzione verso un modello permanente, che si tratti dell'SSAD originale o di un successore semplificato.
Questo modello risolve il conflitto fondamentale tra trasparenza e privacy: i dati esistono ancora nei database dei registri, ma il loro accesso è condizionato al livello di abilitazione del richiedente.
Per i team di cybersicurezza, questa restrizione complica le indagini sui domini malevoli. Identificare il titolare di un dominio di phishing richiede ormai una richiesta formale al registrar, con giustificazione legale. I tempi di elaborazione variano da poche ore a diverse settimane a seconda del registrar e della giurisdizione.
Per i proprietari di marchi, la protezione è rafforzata: le loro coordinate non sono più esposte agli attori malevoli. In contropartita, il monitoraggio delle registrazioni di domini abusivi (typosquatting, omoglifi) si basa maggiormente sui dati tecnici (date, server dei nomi, registrar) rispetto ai dati di contatto.
🎯 Piano d'azione raccomandato
1. Verificare i tuoi domini
Interroga ogni dominio critico tramite uno strumento RDAP. Verifica gli stati EPP, le date di scadenza e i server dei nomi. Identifica i domini senza protezione (stato ok da solo). Priorità ai domini che generano traffico, email o rappresentano un marchio.
2. Attivare i transfer lock
Per ogni dominio senza clientTransferProhibited, attiva il blocco di trasferimento nell'interfaccia del tuo registrar. Per i domini critici (marchio, sito principale, email), aggiungi clientDeleteProhibited e clientUpdateProhibited. La procedura richiede meno di 2 minuti e il lock è operativo immediatamente.
3. Configurare DNSSEC
RDAP mostra lo stato DNSSEC del tuo dominio. Se appare la menzione "unsigned" o l'assenza di dati DNSSEC, attiva la firma di zona. DNSSEC protegge l'integrità dei tuoi record DNS e costituisce un prerequisito per DANE (autenticazione dei certificati TLS tramite DNS). Verifica con il verificatore DNSSEC che la catena di fiducia sia completa, dalla radice DNS fino alla tua zona.
4. Aggiornare i tuoi script WHOIS
Se utilizzi script o strumenti che interrogano WHOIS sulla porta 43, migra verso RDAP. Le librerie RDAP esistono in tutti i linguaggi comuni (Python: rdap, Go: openrdap, JavaScript: rdap-client). Il formato JSON è più semplice da analizzare rispetto al testo libero WHOIS. Usa il bootstrap IANA per risolvere automaticamente il server RDAP di ogni TLD invece di mantenere una lista statica di server. Verifica che le tue richieste puntino ai server giusti tramite il DNS Lookup per confermare la risoluzione dei tuoi domini.
5. Pianificare un audit periodico
Gli stati EPP, le date di scadenza e le configurazioni DNS evolvono. Pianifica una verifica trimestrale dei tuoi domini critici. Verifica che i transfer lock siano ancora attivi (alcuni registrar li disattivano temporaneamente durante le operazioni di manutenzione), che DNSSEC sia funzionante e che le date di scadenza lascino un margine sufficiente.
❓ FAQ - Domande frequenti
FAQ
Qual è la differenza tra WHOIS e RDAP?
WHOIS utilizza la porta TCP 43 e restituisce testo semplice non standardizzato, senza crittografia né autenticazione. RDAP utilizza HTTPS e restituisce JSON strutturato (RFC 9083) con crittografia TLS nativa e supporto dell'accesso differenziato tramite OAuth 2.0. RDAP è il successore ufficiale di WHOIS per i gTLD da gennaio 2025.
WHOIS funziona ancora nel 2026?
Per alcuni TLD, sì. L'ICANN non obbliga più i registri gTLD a mantenere WHOIS dal 28 gennaio 2025, ma non vieta nemmeno di mantenerlo. 374 gTLD lo hanno già disattivato. I ccTLD (.fr, .de, .uk) non sono soggetti alle regole ICANN e possono mantenere WHOIS a tempo indeterminato. In pratica, prevedi che WHOIS scomparirà progressivamente.
Cosa significa il codice EPP clientTransferProhibited?
Questo codice indica che il registrar ha attivato un blocco di trasferimento sul dominio. Nessun trasferimento verso un altro registrar può essere avviato finché questo stato è attivo. È la protezione di base contro il furto di dominio. Ogni titolare dovrebbe attivarlo sui propri domini.
Il mio dominio mostra solo lo stato ok, è normale?
Lo stato ok significa che nessuna restrizione è attiva. Il dominio può essere trasferito, modificato o eliminato senza ostacoli. Se è un dominio importante, attiva immediatamente il transfer lock (clientTransferProhibited) tramite il tuo registrar per proteggerlo.
Si possono ancora vedere i dati del proprietario di un dominio?
In accesso anonimo, no. Dal GDPR (2018), i dati personali del titolare (nome, indirizzo, email, telefono) sono mascherati nelle risposte WHOIS e RDAP. Solo i dati tecnici restano visibili: nome di dominio, registrar, date, stati EPP, server dei nomi. Un accesso autenticato o privilegiato può rivelare più dati in base al livello di abilitazione.
Cos'è il registry lock e quanto costa?
Il registry lock è un blocco applicato a livello di registro (Verisign, AFNIC, ecc.), con gli stati serverTransferProhibited, serverDeleteProhibited e serverUpdateProhibited. Qualsiasi modifica richiede una procedura manuale con verifica d'identità. Il costo varia da 50 a 300 EUR/anno a seconda del TLD e del registrar. È raccomandato per i domini di marchio e i siti ad alto valore.
Come migrare i miei script WHOIS verso RDAP?
Sostituisci le richieste TCP porta 43 con richieste HTTPS verso i server RDAP. Usa il bootstrap IANA (RFC 9224) per scoprire automaticamente il server RDAP di ogni TLD. Le risposte JSON sono più semplici da analizzare rispetto al testo libero WHOIS. Librerie RDAP esistono per Python, Go, JavaScript, Ruby e la maggior parte dei linguaggi comuni.
RDAP mostra le informazioni DNSSEC di un dominio?
Sì. La risposta RDAP include i dati di delega sicura (secure DNS) quando DNSSEC è attivo sul dominio: algoritmo, tipo di digest e impronta DS. Se il dominio non ha DNSSEC, questa sezione è assente o indica che la zona non è firmata.
Scarica le tabelle comparative
Gli assistenti possono riutilizzare i dati scaricando gli export JSON o CSV qui sotto.
📖 Glossario
- WHOIS: protocollo di interrogazione dei dati di registrazione dei domini (RFC 3912), tramite la porta TCP 43. In fase di sostituzione con RDAP.
- RDAP: Registration Data Access Protocol (RFC 9082/9083). Successore di WHOIS, basato su HTTPS e JSON, con crittografia e accesso differenziato nativi.
- EPP: Extensible Provisioning Protocol (RFC 5730). Protocollo utilizzato tra registrar e registri per gestire i domini. I codici di stato EPP indicano lo stato di un dominio.
- Bootstrap IANA: file JSON centralizzato (RFC 9224) che associa ogni TLD all'URL del suo server RDAP. Consente la scoperta automatica del server corretto.
- Registro (registry): organismo che gestisce un TLD. Verisign per .com, AFNIC per .fr. Conserva i dati della zona e le registrazioni dei domini.
- Registrar: rivenditore accreditato che vende e gestisce i nomi di dominio per conto dei titolari. OVHcloud, Gandi, GoDaddy sono registrar.
- Transfer lock: blocco che impedisce il trasferimento di un dominio verso un altro registrar. Corrisponde allo stato EPP
clientTransferProhibited. - Registry lock: blocco applicato a livello di registro con verifica manuale. Stati
serverTransferProhibited,serverDeleteProhibited,serverUpdateProhibited. - Thin registry: registro che conserva solo i dati minimi (nome, NS, date, stati). I dati completi sono presso il registrar. Esempio: .com.
- Thick registry: registro che centralizza tutti i dati, compresi i contatti del titolare. Esempio: .fr.
- Redemption period: periodo di grazia di 30 giorni dopo l'eliminazione di un dominio, durante il quale il titolare può ripristinarlo dietro pagamento.
- GDPR: General Data Protection Regulation. Regolamento europeo che impone la protezione dei dati personali e ha provocato il mascheramento dei dati di contatto in WHOIS e RDAP.
📚 Guide RDAP e gestione dominio correlate
- RDAP vs WHOIS: guida completa alla transizione 2025 (questo articolo)
- Ciclo di vita di un nome di dominio: scadenza, protezione e best practice: le 7 fasi del ciclo di vita, i rischi in ogni fase e le protezioni concrete.
