Registration Data Access Protocol (RDAP): la alternativa a Whois

Antes se podía conocer quién era el propietario de un dominio con un servicio Whois, basado en el protocolo homónimo. Con todo, en 2015 el IETF (Internet Engineering Task Force) y la ICANN (Internet Corporation for Assigned Names and Numbers) definieron las primeras Request for Comments (RFC) del protocolo RDAP (Registration Data Access Protocol), el cual va a terminar sustituyendo a Whois.

¿Qué es el RDAP (Registration Data Access Protocol?

El Protocolo de Acceso a Datos de Registro o RDAP fue creado por el grupo de trabajo de ingeniería de Internet (Internet Engineering 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 características y aplicación aparecen descritas en diferentes Requests for Comments (RFC 7480-7484 y RFC 8056). El protocolo RDAP ofrece la posibilidad de obtener información adicional sobre recursos fundamentales de Internet como

• nombres de dominio,
• direcciones IP o
• Autonomous System Numbers (ASN),

pero también de obtener registros afines. Para ello esta alternativa a Whois ofrece la base para formular solicitudes a las diferentes autoridades de registro de dominios, información que abarca, por ejemplo, los datos de contacto de los propietarios de los dominios, los datos de contacto de los responsables administrativos (Admin C) o la dirección del servidor de nombres utilizado, incluidos los administradores de sus bases de datos.

¿Por qué se desarrolla el RDAP?

El protocolo Whois fue publicado en 1982 de la mano del IETF con el fin de implementar un servicio de consulta para la red de ordenadores ARPANET y el que hoy siga utilizándose tras más de un cuarto de siglo, es para muchos expertos una piedra en el zapato. En este sentido, el aspecto más criticable es que Whois ya no satisface los requisitos técnicos ni de Internet ni de la Web.

Esto hace referencia, por ejemplo, a la problemática de que el protocolo de consultas no se encarga de la codificació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 electrónico y a las direcciones.

La implementación Whois++ y el protocolo IRIS (Internet Registry Information Service) del grupo Denic introdujeron las primeras mejoras, aunque estas no consiguieron establecerse como alternativas duraderas a Whois. Tras un largo período de tiempo en el que también surgieron discusiones en la comunidad de la ICANN sobre la importancia de realizar implementaciones, el informe de seguridad SAC 051 del Security and Stability Advisory Committee (SSAC) de septiembre de 2011 fue determinante 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 oficialmente WHOIS por RDAP. Como se alcanzó el número necesario de votos para que esto pasase, se ha tomado la decisión de aplicar oficialmente el cambio a RDAP. A partir de enero de 2025, los registros DNS y los registradores ya no estarán obligados a ser compatibles con WHOIS.

¿Cómo funciona RDAP?

Para una implementación de RDAP es importante entender el funcionamiento 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 implementación mínima del protocolo. Además, hay otros RFC que describen extensiones del protocolo RDAP. A continuación, se explica el procedimiento del protocolo a través de HTTPS, tal y como se describe en RFC 7840.

Tareas del cliente

La implementació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 existentes en la transmisión de datos. Los clientes pueden hacer peticiones al servidor utilizando los métodos GET y HEAD. Tanto las peticiones GET como HEAD deben incluir una cabecera “Accept”, donde se especifica qué tipos de archivos JSON son aceptados por el cliente.

Tareas del servidor

En el lado del servidor, la implementación es un poco más compleja, pues el servidor tiene que cubrir una serie de casos especiales. En caso de que la solicitud se lleve a cabo con éxito, el servidor deberá devolver los datos solicitados en el formato solicitado con el código de estado HTTP 200 (OK). En las peticiones GET, el servidor debe responder con los datos del propietario solicitado, y en las peticiones HEAD, debe indicar si dispone de datos para ese dominio.

Si sabe dónde se encuentran los datos solicitados, pero no tiene acceso a ellos, el servidor responderá 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 solicitados no están disponibles, responderá con el código de estado 404 (no encontrado). Si los datos solicitados están disponibles, pero el servidor responde por otra razón, responderá con un código de estado del rango 400. Las solicitudes que contengan errores y, por tanto, no puedan ser consideradas solicitudes RDAP, se responderán con el código de estado 400 (Bad Request). En este caso, se puede enviar información adicional en el cuerpo de la entidad de solicitud HTTP.

Para obtener información más detallada sobre el procedimiento, así como sobre las posibilidades de seguridad y ampliación del protocolo, puedes consultar las RFC correspondientes:

• RFC 7840: flujo HTTP
• RFC 7841: servicios de seguridad
• RFC 7842: formato de solicitud
• RFC 7843: respuestas JSON
• RFC 7844: encontrar servidor autorizado

¿Qué diferencia al Registration 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 intensamente en las debilidades del protocolo anterior y se ha centrado sobre todo en los aspectos de seguridad, estructuración e internacionalización a la hora de desarrollar el nuevo protocolo de consulta. Así, la alternativa a Whois destaca por las siguientes novedades:

• Semántica estructurada de preguntas y respuestas (incluidos mensajes de error estandarizados)
• Acceso seguro a los datos de contacto solicitados (por ejemplo, vía HTTPS)
• Capacidad de ampliación (mediante, por ejemplo, la introducción de elementos de salida)
• Mecanismo de bootstrapping (sirve de ayuda para la búsqueda del servidor DNS autoritativo apropiado)
• Transmisión estandarizada de las solicitudes
• Basado en la web (HTTP) y de conformidad con REST (Representational State Transfer)
• Traducción sencilla de los datos de salida
• Posibilidad de proporcionar acceso diferenciado a los datos de contacto

El Registration Data Access Protocol también es más flexible que su predecesor en muchos aspectos: mientras que Whois está vinculado a TCP y a un puente TCP específico (43) como protocolo basado en texto, RDAP recurre a los estándares web HTTP o HTTPS para la transferencia de datos. Con ello, todos los datos se entregan en el formato JSON estandarizado y son legibles para las máquinas. Así, la alternativa a Whois concede mayores libertades en la consulta de datos y simplifica la programación de servicios de consulta que se comunican con las diferentes autoridades de registro y emiten los datos solicitados en varios idiomas.

Los permisos de acceso siguen avivando el debate

Una de las funciones nuevas más importantes que ha sido implementada en el Registration Data Access Protocol es, sin duda, la posibilidad de definir diferentes 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 autenticados a todo el registro de datos. En este punto, muchos responsables ven la necesidad de ofrecer las aclaraciones pertinentes.

Entre otras, surge la pregunta, por ejemplo, de cómo se pueden evitar las acciones de criminales que permanecen anónimos con el objetivo de lograr opciones de acceso. Además, no hay directrices acerca de si en casos como estos se deben otorgar permisos internacionales para acceder a los datos de dominio. Ante todo, prima la protecció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 solicitudes RDAP. Tras la apelación a finales de 2016 de varios registros al plazo de implementación impuesto por la ICANN, la organización está planeando introducir la alternativa RDAP por medio de contratos con las entidades de registro y los proveedores de dominios.