# 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](https://www.ionos.mx/tools/whois-domain "Información Whois en IONOS"), 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](https://www.ionos.mx/digitalguide/servidores/know-how/direccion-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](https://www.icann.org/en/system/files/files/sac-051-en.pdf "SSAC Report on Domain Name WHOIS Terminology and Structure") 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](https://datatracker.ietf.org/doc/html/rfc7480 "RFC 7840: HTTP Usage in the Registration Data Access Protocol (RDAP)"). Consejo Para facilitar la implementación del protocolo a los desarrolladores, la ICANN ha proporcionado una [guía para la implementación de RDAP](https://www.icann.org/en/system/files/files/rdap-technical-implementation-guide-15feb19-en.pdf "ICANN RDAP Technical Implementation Guide"). **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](https://datatracker.ietf.org/doc/html/rfc7480 "Sobre RFC 7840 del IETF") - [RFC 7841: servicios de seguridad](https://datatracker.ietf.org/doc/html/rfc7481 "Sobre RFC 7841 del IETF") - [RFC 7842: formato de solicitud](https://datatracker.ietf.org/doc/html/rfc7482 "Sobre la RFC 7842 del IETF") - [RFC 7843: respuestas JSON](https://datatracker.ietf.org/doc/html/rfc7483 "Sobre RFC 7843 del IETF") - [RFC 7844: encontrar servidor autorizado](https://datatracker.ietf.org/doc/html/rfc7484 "Sobre RFC 7844 del IETF") ## ¿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](https://www.ionos.mx/digitalguide/servidores/know-how/que-es-el-servidor-dns-y-como-funciona/) 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](https://www.ionos.mx/digitalguide/servidores/know-how/que-es-tcp-transport-control-protocol/) y a un [puente TCP específico](https://www.ionos.mx/digitalguide/servidores/know-how/puertos-tcp-puertos-udp/) (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**.
RDAP Whois
Basado en HTTP Basado en texto
Formato JSON estandarizado Sin formato de codificación
Los datos de salida son legibles por las máquinas y fáciles de traducir Los datos de salida están en formato de texto y no pueden procesarse mecánicamente
Las respuestas redirigen automáticamente a otras autoridades de registro Las respuestas no contienen datos de registro adicionales
Posibilidad de definir permisos de acceso para diversos grupos No permite el acceso a datos diferenciado
## 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. This is a markdown version of: [https://www.ionos.mx/digitalguide/dominios/gestion-de-dominios/que-es-el-rdap-registration-data-access-protocol/](https://www.ionos.mx/digitalguide/dominios/gestion-de-dominios/que-es-el-rdap-registration-data-access-protocol/) for AI/LLM consumption.