Re­gi­stra­tion Data Access Protocol (RDAP): l’al­ter­na­ti­va a Whois

In passato, era possibile iden­ti­fi­ca­re il pro­prie­ta­rio o la pro­prie­ta­ria di un dominio tramite il servizio Whois, basato sull’omonimo pro­to­col­lo. Tuttavia, nel 2015 la Internet En­gi­nee­ring Task Force (IETF) e la Internet Cor­po­ra­tion for Assigned Names and Numbers (ICANN) hanno definito le prime RFC del pro­to­col­lo RDAP (Register Data Acess Protocol), che dovrebbe prendere il posto di Whois il prima possibile.

Cos’è Re­gi­stra­tion Data Access Protocol (RDAP)

Il pro­to­col­lo RDAP è stato elaborato da un gruppo di lavoro della IETF. Dopo una fase pro­get­tua­le di quasi quattro anni, la prima versione del profilo di pro­to­col­lo (1.0) è stata pub­bli­ca­ta il 26 giugno 2016. Le sue proprietà e ap­pli­ca­zio­ni sono state descritte in diverse RFC (RFC 7480-7484 e RFC 8056). RDAP offre la pos­si­bi­li­tà di ottenere ulteriori in­for­ma­zio­ni in merito a risorse internet ele­men­ta­ri, come:

• Nomi di dominio
• Indirizzi IP
• Numeri di sistemi autonomi (Au­to­no­mous System Numbers o ASN)

A queste, si ag­giun­go­no anche altre voci. A tale scopo, l’al­ter­na­ti­va a Whois rap­pre­sen­ta uno strumento per inviare richieste ai vari registrar di dominio, che ottengono in­for­ma­zio­ni come, ad esempio, i dati di contatto del titolare del dominio, dell’am­mi­ni­stra­to­re (Admin-C) o ancora l’indirizzo e il gestore del name server uti­liz­za­to.

Perché è stato pro­get­ta­to il pro­to­col­lo RDAP?

Già nel 1982 la IETF pubblicò il pro­to­col­lo Whois al fine di im­ple­men­ta­re un servizio di richiesta per l’allora ARPANET. Il fatto che dopo più di un quarto di secolo sia ancora in uso è pro­ble­ma­ti­co per molti esperti, secondo i quali Whois non è sem­pli­ce­men­te più in grado di sod­di­sfa­re le moderne esigenze tecniche di internet e del web.

Un esempio sta nel fatto che questo tipo di pro­to­col­lo non dispone di uno schema di codifica e che pertanto non supporta caratteri non latini. Al­tret­tan­to pro­ble­ma­ti­co è che l’accesso ai dati non sia sicuro né re­go­la­bi­le: persino gli utenti anonimi hanno infatti accesso a in­for­ma­zio­ni come indirizzi e-mail o recapiti.

Progetti come l’esten­sio­ne Whois++ o il pro­to­col­lo Denic IRIS (Internet Registry In­for­ma­tion Service) (per i domini tedeschi) hanno ini­zial­men­te portato mi­glio­ra­men­ti, ma non sono stati in grado di af­fer­mar­si come valida al­ter­na­ti­va a Whois. Dopo lunghe di­scus­sio­ni interne alla comunità ICANN sulla necessità di ulteriori sviluppi, la spinta decisiva allo sviluppo del pro­to­col­lo RDAP è stata data nel settembre del 2011 dalla relazione sulla sicurezza SAC 051 dell’or­ga­niz­za­zio­ne Security and Stability Advisory Committee (SSAC).

A gennaio 2023, l’ICANN ha lanciato una votazione globale per decidere se so­sti­tui­re uf­fi­cial­men­te il servizio WHOIS con RDAP. Il numero di voti necessari è stato raggiunto e si è deciso di imporre uf­fi­cial­men­te il passaggio a RDAP. A partire da gennaio 2025, i registri e le società di re­gi­stra­zio­ne DNS non saranno più tenuti a sup­por­ta­re Whois.

Come funziona RDAP?

Per im­ple­men­ta­re RDAP, è im­por­tan­te in­nan­zi­tut­to capire come funziona il pro­to­col­lo, sia sul lato client che su quello server. A tale scopo, vale la pena di con­sul­ta­re le RFC da 7480 a 7484, dove viene descritta in dettaglio un’im­ple­men­ta­zio­ne minima del pro­to­col­lo. Inoltre, esistono altre RFC in cui vengono descritte le esten­sio­ni del pro­to­col­lo RDAP. Di seguito viene il­lu­stra­ta la procedura di massima del pro­to­col­lo tramite HTTPS, come descritto in RFC 7480.

Compiti del client:

L’im­ple­men­ta­zio­ne di RDAP lato client non è affatto complessa. Il pro­to­col­lo si basa su HTTP e di con­se­guen­za utilizza i metodi HTTP già esistenti per tra­smet­te­re i dati. I client possono fare richieste al server uti­liz­zan­do i metodi GET e HEAD. Entrambe le richieste GET e HEAD devono includere un’in­te­sta­zio­ne “Accept” che spe­ci­fi­chi quali tipi di file JSON sono accettati dal client.

Compiti del server:

Dal lato del server, l’im­ple­men­ta­zio­ne è 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 re­sti­tui­re i dati nel formato richiesto con il codice di stato HTTP 200 (OK). Per le richieste GET, il server deve ri­spon­de­re con i dati del pro­prie­ta­rio, mentre per le richieste HEAD deve indicare se ha dati di­spo­ni­bi­li per questo dominio.

Se sa dove si trovano i dati richiesti, ma non sono in suo possesso, deve ri­spon­de­re con uno dei codici di stato 301, 302, 303 o 307. L’URL in cui è possibile trovare i dati viene quindi inviato con l’in­te­sta­zio­ne HTTP “Location”.

Se il server non può elaborare la richiesta perché i dati non sono di­spo­ni­bi­li, deve ri­spon­de­re con il codice di stato 404 (Not Found). Se i dati richiesti sono di­spo­ni­bi­li, ma il server non vuole ri­spon­de­re per un’altra ragione, deve ri­spon­de­re con un codice di stato cor­ri­spon­den­te, compreso nell’in­ter­val­lo 400. Alle richieste che con­ten­go­no errori e che quindi non possono essere comprese come richieste RDAP, si deve ri­spon­de­re con il codice di stato 400 (Bad Request). In questo caso, è possibile inviare in­for­ma­zio­ni ag­giun­ti­ve nella sezione Entity Body HTTP.

Per in­for­ma­zio­ni più det­ta­glia­te sul processo e sulle pos­si­bi­li­tà di sicurezza ed esten­sio­ne del pro­to­col­lo, è possibile fare ri­fe­ri­men­to alle RFC cor­ri­spon­den­ti, 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 au­to­re­vo­le

RDAP e Whois: quali sono le dif­fe­ren­ze?

Il pro­to­col­lo RDAP è sotto molti punti di vista una versione mi­glio­ra­ta di Whois. Il gruppo di lavoro IETF si è occupato con estrema at­ten­zio­ne dei punti deboli del vecchio pro­to­col­lo, con­cen­tran­do­si so­prat­tut­to su sicurezza, strut­tu­ra­zio­ne e in­ter­na­zio­na­liz­za­zio­ne. L’al­ter­na­ti­va a Whois è ca­rat­te­riz­za­ta dalle seguenti in­no­va­zio­ni:

• Semantica strut­tu­ra­ta di richiesta e risposta (messaggi di errore standard inclusi)
• Accesso più sicuro ai dati di contatto richiesti (ad esempio tramite HTTPS)
• Esten­si­bi­li­tà (ad esempio aggiunta di elementi in uscita)
• Mec­ca­ni­smo di boo­tstrap­ping (assistito nella ricerca del server DNS au­to­re­vo­le ap­pro­pria­to)
• Inoltro stan­dar­diz­za­to delle richieste
• Basato sul web (HTTP) e conforme a REST
• Tra­du­zio­ne semplice dei dati di output
• Accesso dif­fe­ren­zia­to ai dati di contatto

Il pro­to­col­lo RDAP si dimostra anche de­ci­sa­men­te più fles­si­bi­le del suo pre­de­ces­so­re: a dif­fe­ren­za di Whois, legato al pro­to­col­lo testuale basato su TCP e alla porta specifica TCP (43), RDAP utilizza per la tra­smis­sio­ne dei dati lo standard web HTTP o HTTPS. Tutti i dati sono forniti in formato JSON stan­dar­diz­za­to e leggibili mec­ca­ni­ca­men­te. Questo offre all’al­ter­na­ti­va di Whois più libertà nel recupero dei dati e sem­pli­fi­ca la pro­gram­ma­zio­ne dei servizi di query, che possono co­mu­ni­ca­re con i diversi registri e fornire i dati richiesti in varie lingue.

Di­scus­sio­ne sui permessi di accesso dif­fe­ren­zia­ti

Tra le funzioni inserite nel Re­gi­stra­tion Data Access Protocol, una delle più im­por­tan­ti è senza dubbio la pos­si­bi­li­tà di impostare permessi di accesso dif­fe­ren­ti in base ai gruppi di utenti. L’autorità di re­gi­stra­zio­ne è in questo modo in grado di definire chi possa accedere a de­ter­mi­na­ti dati: è logico, ad esempio, im­ma­gi­na­re che agli utenti anonimi venga garantito un accesso limitato, mentre gli utenti au­ten­ti­ca­ti non sono invece soggetti a li­mi­ta­zio­ni. Proprio su questo punto, tuttavia, sembra ne­ces­sa­ria una ri­fles­sio­ne ag­giun­ti­va.

Una delle questioni aperte, ad esempio, è come gestire le richieste di in­qui­ren­ti che ne­ces­si­ti­no pieno accesso ai dati pur rimanendo anonimi. Non sono inoltre presenti linee guida che de­fi­ni­sca­no se, in casi simili, l’accesso ai dati vada garantito oltre i confini nazionali. Allo stesso tempo, rimane l’assoluta necessità di pro­teg­ge­re i dati degli utenti e mantenere la fiducia di chi registra il proprio dominio. Dopo che alcuni registri hanno pre­sen­ta­to ricorso contro il termine ob­bli­ga­to­rio di im­ple­men­ta­zio­ne stabilito dall’ICANN entro fine 2016, il piano dell’or­ga­niz­za­zio­ne è di in­tro­dur­re l’al­ter­na­ti­va a Whois at­tra­ver­so contratti con società di re­gi­stra­zio­ne e provider di domini.