Re­gi­s­tra­tion Data Access Protocol (RDAP): la al­te­r­na­ti­va a Whois

Antes se podía conocer quién era el pro­pie­ta­rio de un dominio con un servicio Whois, basado en el protocolo homónimo. Con todo, en 2015 el IETF (Internet En­gi­nee­ri­ng Task Force) y la ICANN (Internet Co­r­po­ra­tion for Assigned Names and Numbers) de­fi­nie­ron las primeras Request for Comments (RFC) del protocolo RDAP (Re­gi­s­tra­tion Data Access Protocol), el cual va a terminar su­s­ti­tu­ye­n­do a Whois.

¿Qué es el RDAP (Re­gi­s­tra­tion Data Access Protocol?

El Protocolo de Acceso a Datos de Registro o RDAP fue creado por el grupo de trabajo de in­ge­nie­ría de Internet (Internet En­gi­nee­ri­ng Task Force, IETF). Tras apenas 4 años de proyecto, el 26 de julio de 2016 apareció la primera versión del perfil del protocolo (1.0), cuyas ca­ra­c­te­rí­s­ti­cas y apli­ca­ción aparecen descritas en di­fe­re­n­tes Requests for Comments (RFC 7480-7484 y RFC 8056). El protocolo RDAP ofrece la po­si­bi­li­dad de obtener in­fo­r­ma­ción adicional sobre recursos fu­n­da­me­n­ta­les de Internet como

• nombres de dominio,
• di­re­c­cio­nes IP o
• Au­to­no­mous System Numbers (ASN),

pero también de obtener registros afines. Para ello esta al­te­r­na­ti­va a Whois ofrece la base para formular so­li­ci­tu­des a las di­fe­re­n­tes au­to­ri­da­des de registro de dominios, in­fo­r­ma­ción que abarca, por ejemplo, los datos de contacto de los pro­pie­ta­rios de los dominios, los datos de contacto de los re­s­po­n­sa­bles ad­mi­ni­s­tra­ti­vos (Admin C) o la dirección del servidor de nombres utilizado, incluidos los ad­mi­ni­s­tra­do­res de sus bases de datos.

¿Por qué se de­sa­rro­lla el RDAP?

El protocolo Whois fue publicado en 1982 de la mano del IETF con el fin de im­ple­me­n­tar un servicio de consulta para la red de or­de­na­do­res ARPANET y el que hoy siga uti­li­zá­n­do­se tras más de un cuarto de siglo, es para muchos expertos una piedra en el zapato. En este sentido, el aspecto más cri­ti­ca­ble es que Whois ya no satisface los re­qui­si­tos técnicos ni de Internet ni de la Web.

Esto hace re­fe­re­n­cia, por ejemplo, a la pro­ble­má­ti­ca de que el protocolo de consultas no se encarga de la co­di­fi­ca­ción y, por lo tanto, no soporta alfabetos no latinos (lo que excluye el uso, por ejemplo, de la diéresis). También agrava la situación el hecho de que el acceso a los datos de dominio no se realiza a través de una conexión segura ni se puede regular y los usuarios anónimos tienen acceso completo al correo ele­c­tró­ni­co y a las di­re­c­cio­nes.

La im­ple­me­n­ta­ción Whois++ y el protocolo IRIS (Internet Registry In­fo­r­ma­tion Service) del grupo Denic in­tro­du­je­ron las primeras mejoras, aunque estas no co­n­si­guie­ron es­ta­ble­ce­r­se como al­te­r­na­ti­vas duraderas a Whois. Tras un largo período de tiempo en el que también surgieron di­s­cu­sio­nes en la comunidad de la ICANN sobre la im­po­r­ta­n­cia de realizar im­ple­me­n­ta­cio­nes, el informe de seguridad SAC 051 del Security and Stability Advisory Committee (SSAC) de se­p­tie­m­bre de 2011 fue de­te­r­mi­na­n­te para la creación del grupo de trabajo del RDAP.

En enero de 2023, la ICANN realizó un proceso de votación a nivel mundial para decidir si se sustituía ofi­cia­l­me­n­te WHOIS por RDAP. Como se alcanzó el número necesario de votos para que esto pasase, se ha tomado la decisión de aplicar ofi­cia­l­me­n­te el cambio a RDAP. A partir de enero de 2025, los registros DNS y los re­gi­s­tra­do­res ya no estarán obligados a ser co­m­pa­ti­bles con WHOIS.

¿Cómo funciona RDAP?

Para una im­ple­me­n­ta­ción de RDAP es im­po­r­ta­n­te entender el fu­n­cio­na­mie­n­to del protocolo tanto en el lado del cliente como en el del servidor. Para ello, se puede echar un vistazo a los RFC 7480 a 7484, que describen en detalle una im­ple­me­n­ta­ción mínima del protocolo. Además, hay otros RFC que describen ex­te­n­sio­nes del protocolo RDAP. A co­n­ti­nua­ción, se explica el pro­ce­di­mie­n­to del protocolo a través de HTTPS, tal y como se describe en RFC 7840.

Tareas del cliente

La im­ple­me­n­ta­ción de RDAP en el lado del cliente no es en absoluto compleja. RDAP se basa en HTTP, y por lo tanto utiliza los métodos HTTP ya exi­s­te­n­tes en la tra­n­s­mi­sión de datos. Los clientes pueden hacer pe­ti­cio­nes al servidor uti­li­za­n­do los métodos GET y HEAD. Tanto las pe­ti­cio­nes GET como HEAD deben incluir una cabecera “Accept”, donde se es­pe­ci­fi­ca qué tipos de archivos JSON son aceptados por el cliente.

Tareas del servidor

En el lado del servidor, la im­ple­me­n­ta­ción es un poco más compleja, pues el servidor tiene que cubrir una serie de casos es­pe­cia­les. En caso de que la solicitud se lleve a cabo con éxito, el servidor deberá devolver los datos so­li­ci­ta­dos en el formato so­li­ci­ta­do con el código de estado HTTP 200 (OK). En las pe­ti­cio­nes GET, el servidor debe responder con los datos del pro­pie­ta­rio so­li­ci­ta­do, y en las pe­ti­cio­nes HEAD, debe indicar si dispone de datos para ese dominio.

Si sabe dónde se en­cue­n­tran los datos so­li­ci­ta­dos, pero no tiene acceso a ellos, el servidor re­s­po­n­de­rá con uno de los códigos de estado 301, 302, 303 o 307. La URL donde se pueden encontrar los datos se envía entonces bajo la cabecera HTTP “Location”.

Si el servidor no puede procesar la solicitud porque los datos so­li­ci­ta­dos no están di­s­po­ni­bles, re­s­po­n­de­rá con el código de estado 404 (no en­co­n­tra­do). Si los datos so­li­ci­ta­dos están di­s­po­ni­bles, pero el servidor responde por otra razón, re­s­po­n­de­rá con un código de estado del rango 400. Las so­li­ci­tu­des que contengan errores y, por tanto, no puedan ser co­n­si­de­ra­das so­li­ci­tu­des RDAP, se re­s­po­n­de­rán con el código de estado 400 (Bad Request). En este caso, se puede enviar in­fo­r­ma­ción adicional en el cuerpo de la entidad de solicitud HTTP.

Para obtener in­fo­r­ma­ción más detallada sobre el pro­ce­di­mie­n­to, así como sobre las po­si­bi­li­da­des de seguridad y am­plia­ción del protocolo, puedes consultar las RFC co­rre­s­po­n­die­n­tes:

• RFC 7840: flujo HTTP
• RFC 7841: servicios de seguridad
• RFC 7842: formato de solicitud
• RFC 7843: re­s­pue­s­tas JSON
• RFC 7844: encontrar servidor au­to­ri­za­do

¿Qué di­fe­re­n­cia al Re­gi­s­tra­tion Data Access Protocol de Whois?

RDAP se erige en muchos aspectos como una versión mejorada de Whois. El grupo de trabajo del IETF ha trabajado in­te­n­sa­me­n­te en las de­bi­li­da­des del protocolo anterior y se ha centrado sobre todo en los aspectos de seguridad, es­tru­c­tu­ra­ción e in­te­r­na­cio­na­li­za­ción a la hora de de­sa­rro­llar el nuevo protocolo de consulta. Así, la al­te­r­na­ti­va a Whois destaca por las si­guie­n­tes novedades:

• Semántica es­tru­c­tu­ra­da de preguntas y re­s­pue­s­tas (incluidos mensajes de error es­ta­n­da­ri­za­dos)
• Acceso seguro a los datos de contacto so­li­ci­ta­dos (por ejemplo, vía HTTPS)
• Capacidad de am­plia­ción (mediante, por ejemplo, la in­tro­du­c­ción de elementos de salida)
• Mecanismo de boots­tra­p­pi­ng (sirve de ayuda para la búsqueda del servidor DNS au­to­ri­ta­ti­vo apropiado)
• Tra­n­s­mi­sión es­ta­n­da­ri­za­da de las so­li­ci­tu­des
• Basado en la web (HTTP) y de co­n­fo­r­mi­dad con REST (Re­pre­se­n­ta­tio­nal State Transfer)
• Tra­du­c­ción sencilla de los datos de salida
• Po­si­bi­li­dad de pro­po­r­cio­nar acceso di­fe­re­n­cia­do a los datos de contacto

El Re­gi­s­tra­tion Data Access Protocol también es más flexible que su pre­de­ce­sor en muchos aspectos: mientras que Whois está vinculado a TCP y a un puente TCP es­pe­cí­fi­co (43) como protocolo basado en texto, RDAP recurre a los es­tá­n­da­res web HTTP o HTTPS para la tra­n­s­fe­re­n­cia de datos. Con ello, todos los datos se entregan en el formato JSON es­ta­n­da­ri­za­do y son legibles para las máquinas. Así, la al­te­r­na­ti­va a Whois concede mayores li­be­r­ta­des en la consulta de datos y si­m­pli­fi­ca la pro­gra­ma­ción de servicios de consulta que se comunican con las di­fe­re­n­tes au­to­ri­da­des de registro y emiten los datos so­li­ci­ta­dos en varios idiomas.

Los permisos de acceso siguen avivando el debate

Una de las funciones nuevas más im­po­r­ta­n­tes que ha sido im­ple­me­n­ta­da en el Re­gi­s­tra­tion Data Access Protocol es, sin duda, la po­si­bi­li­dad de definir di­fe­re­n­tes permisos de acceso para grupos de usuarios. De esta manera, la autoridad de registro puede regular con exactitud el tipo de datos que puede utilizar cada uno. Así sería posible, por ejemplo, conceder a los usuarios anónimos un acceso limitado, pudiendo acceder los usuarios au­te­n­ti­ca­dos a todo el registro de datos. En este punto, muchos re­s­po­n­sa­bles ven la necesidad de ofrecer las acla­ra­cio­nes pe­r­ti­ne­n­tes.

Entre otras, surge la pregunta, por ejemplo, de cómo se pueden evitar las acciones de cri­mi­na­les que pe­r­ma­ne­cen anónimos con el objetivo de lograr opciones de acceso. Además, no hay di­re­c­tri­ces acerca de si en casos como estos se deben otorgar permisos in­te­r­na­cio­na­les para acceder a los datos de dominio. Ante todo, prima la pro­te­c­ción de los datos de los usuarios y la confianza de aquellos que registran sus dominios, algo que no debe verse afectado con el nuevo método de so­li­ci­tu­des RDAP. Tras la apelación a finales de 2016 de varios registros al plazo de im­ple­me­n­ta­ción impuesto por la ICANN, la or­ga­ni­za­ción está planeando in­tro­du­cir la al­te­r­na­ti­va RDAP por medio de contratos con las entidades de registro y los pro­vee­do­res de dominios.