Registration Data Access Protocol (RDAP): l’alternativa a Whois

In passato, era possibile identificare il proprietario o la proprietaria di un dominio tramite il servizio Whois, basato sull’omonimo protocollo. Tuttavia, nel 2015 la Internet Engineering Task Force (IETF) e la Internet Corporation for Assigned Names and Numbers (ICANN) hanno definito le prime RFC del protocollo RDAP (Register Data Acess Protocol), che dovrebbe prendere il posto di Whois il prima possibile.

Cos’è Registration Data Access Protocol (RDAP)

Il protocollo RDAP è stato elaborato da un gruppo di lavoro della IETF. Dopo una fase progettuale di quasi quattro anni, la prima versione del profilo di protocollo (1.0) è stata pubblicata il 26 giugno 2016. Le sue proprietà e applicazioni sono state descritte in diverse RFC (RFC 7480-7484 e RFC 8056). RDAP offre la possibilità di ottenere ulteriori informazioni in merito a risorse internet elementari, come:

• Nomi di dominio
• Indirizzi IP
• Numeri di sistemi autonomi (Autonomous System Numbers o ASN)

A queste, si aggiungono anche altre voci. A tale scopo, l’alternativa a Whois rappresenta uno strumento per inviare richieste ai vari registrar di dominio, che ottengono informazioni come, ad esempio, i dati di contatto del titolare del dominio, dell’amministratore (Admin-C) o ancora l’indirizzo e il gestore del name server utilizzato.

Perché è stato progettato il protocollo RDAP?

Già nel 1982 la IETF pubblicò il protocollo Whois al fine di implementare un servizio di richiesta per l’allora ARPANET. Il fatto che dopo più di un quarto di secolo sia ancora in uso è problematico per molti esperti, secondo i quali Whois non è semplicemente più in grado di soddisfare le moderne esigenze tecniche di internet e del web.

Un esempio sta nel fatto che questo tipo di protocollo non dispone di uno schema di codifica e che pertanto non supporta caratteri non latini. Altrettanto problematico è che l’accesso ai dati non sia sicuro né regolabile: persino gli utenti anonimi hanno infatti accesso a informazioni come indirizzi e-mail o recapiti.

Progetti come l’estensione Whois++ o il protocollo Denic IRIS (Internet Registry Information Service) (per i domini tedeschi) hanno inizialmente portato miglioramenti, ma non sono stati in grado di affermarsi come valida alternativa a Whois. Dopo lunghe discussioni interne alla comunità ICANN sulla necessità di ulteriori sviluppi, la spinta decisiva allo sviluppo del protocollo RDAP è stata data nel settembre del 2011 dalla relazione sulla sicurezza SAC 051 dell’organizzazione Security and Stability Advisory Committee (SSAC).

A gennaio 2023, l’ICANN ha lanciato una votazione globale per decidere se sostituire ufficialmente il servizio WHOIS con RDAP. Il numero di voti necessari è stato raggiunto e si è deciso di imporre ufficialmente il passaggio a RDAP. A partire da gennaio 2025, i registri e le società di registrazione DNS non saranno più tenuti a supportare Whois.

Come funziona RDAP?

Per implementare RDAP, è importante innanzitutto capire come funziona il protocollo, sia sul lato client che su quello server. A tale scopo, vale la pena di consultare le RFC da 7480 a 7484, dove viene descritta in dettaglio un’implementazione minima del protocollo. Inoltre, esistono altre RFC in cui vengono descritte le estensioni del protocollo RDAP. Di seguito viene illustrata la procedura di massima del protocollo tramite HTTPS, come descritto in RFC 7480.

Compiti del client:

L’implementazione di RDAP lato client non è affatto complessa. Il protocollo si basa su HTTP e di conseguenza utilizza i metodi HTTP già esistenti per trasmettere i dati. I client possono fare richieste al server utilizzando i metodi GET e HEAD. Entrambe le richieste GET e HEAD devono includere un’intestazione “Accept” che specifichi quali tipi di file JSON sono accettati dal client.

Compiti del server:

Dal lato del server, l’implementazione è un po’ più complessa, in quanto il server deve occuparsi di diversi casi speciali. In caso di richiesta andata a buon fine, il server deve restituire i dati nel formato richiesto con il codice di stato HTTP 200 (OK). Per le richieste GET, il server deve rispondere con i dati del proprietario, mentre per le richieste HEAD deve indicare se ha dati disponibili per questo dominio.

Se sa dove si trovano i dati richiesti, ma non sono in suo possesso, deve rispondere con uno dei codici di stato 301, 302, 303 o 307. L’URL in cui è possibile trovare i dati viene quindi inviato con l’intestazione HTTP “Location”.

Se il server non può elaborare la richiesta perché i dati non sono disponibili, deve rispondere con il codice di stato 404 (Not Found). Se i dati richiesti sono disponibili, ma il server non vuole rispondere per un’altra ragione, deve rispondere con un codice di stato corrispondente, compreso nell’intervallo 400. Alle richieste che contengono errori e che quindi non possono essere comprese come richieste RDAP, si deve rispondere con il codice di stato 400 (Bad Request). In questo caso, è possibile inviare informazioni aggiuntive nella sezione Entity Body HTTP.

Per informazioni più dettagliate sul processo e sulle possibilità di sicurezza ed estensione del protocollo, è possibile fare riferimento alle RFC corrispondenti, che trovi collegate in questo elenco.

• RFC 7480: uso di HTTP
• RFC 7481: servizi di sicurezza
• RFC 7482: formato della richiesta
• RFC 7483: risposte JSON
• RFC 7484: trovare un server autorevole

RDAP e Whois: quali sono le differenze?

Il protocollo RDAP è sotto molti punti di vista una versione migliorata di Whois. Il gruppo di lavoro IETF si è occupato con estrema attenzione dei punti deboli del vecchio protocollo, concentrandosi soprattutto su sicurezza, strutturazione e internazionalizzazione. L’alternativa a Whois è caratterizzata dalle seguenti innovazioni:

• Semantica strutturata di richiesta e risposta (messaggi di errore standard inclusi)
• Accesso più sicuro ai dati di contatto richiesti (ad esempio tramite HTTPS)
• Estensibilità (ad esempio aggiunta di elementi in uscita)
• Meccanismo di bootstrapping (assistito nella ricerca del server DNS autorevole appropriato)
• Inoltro standardizzato delle richieste
• Basato sul web (HTTP) e conforme a REST
• Traduzione semplice dei dati di output
• Accesso differenziato ai dati di contatto

Il protocollo RDAP si dimostra anche decisamente più flessibile del suo predecessore: a differenza di Whois, legato al protocollo testuale basato su TCP e alla porta specifica TCP (43), RDAP utilizza per la trasmissione dei dati lo standard web HTTP o HTTPS. Tutti i dati sono forniti in formato JSON standardizzato e leggibili meccanicamente. Questo offre all’alternativa di Whois più libertà nel recupero dei dati e semplifica la programmazione dei servizi di query, che possono comunicare con i diversi registri e fornire i dati richiesti in varie lingue.

Discussione sui permessi di accesso differenziati

Tra le funzioni inserite nel Registration Data Access Protocol, una delle più importanti è senza dubbio la possibilità di impostare permessi di accesso differenti in base ai gruppi di utenti. L’autorità di registrazione è in questo modo in grado di definire chi possa accedere a determinati dati: è logico, ad esempio, immaginare che agli utenti anonimi venga garantito un accesso limitato, mentre gli utenti autenticati non sono invece soggetti a limitazioni. Proprio su questo punto, tuttavia, sembra necessaria una riflessione aggiuntiva.

Una delle questioni aperte, ad esempio, è come gestire le richieste di inquirenti che necessitino pieno accesso ai dati pur rimanendo anonimi. Non sono inoltre presenti linee guida che definiscano se, in casi simili, l’accesso ai dati vada garantito oltre i confini nazionali. Allo stesso tempo, rimane l’assoluta necessità di proteggere i dati degli utenti e mantenere la fiducia di chi registra il proprio dominio. Dopo che alcuni registri hanno presentato ricorso contro il termine obbligatorio di implementazione stabilito dall’ICANN entro fine 2016, il piano dell’organizzazione è di introdurre l’alternativa a Whois attraverso contratti con società di registrazione e provider di domini.