WHOIS vs. RDAP: El futuro de los directorios de dominios

Por qué importan los servicios de directorio de dominios

Detrás de cada dominio registrado hay un registro con datos clave: qué registrador lo gestiona, cuándo se creó, cuándo caduca, a qué servidores de nombres está delegado y qué códigos de estado lo bloquean o restringen. Los equipos de seguridad usan esta información para investigar campañas de phishing, los titulares de marcas para detectar registros abusivos y los administradores para asegurarse de que sus propios dominios no caduquen sin que nadie se dé cuenta. Durante más de treinta años, la herramienta para leer esos datos fue WHOIS. Hoy la está sustituyendo RDAP, el Registration Data Access Protocol.

En esta guía veremos cómo funcionan ambos protocolos, qué ha cambiado a nivel técnico, qué implican las decisiones de ICANN en la práctica y cómo hacer consultas con cada uno.

Cómo funciona el protocolo WHOIS

WHOIS es anterior a la web comercial. Su especificación actual, la RFC 3912 de 2004, ocupa apenas unas páginas porque el protocolo es mínimo: el cliente abre una conexión TCP al puerto 43, envía una línea de texto (normalmente el nombre de dominio) y el servidor responde con texto libre antes de cerrar la conexión.

whois ejemplo.es
whois -h whois.verisign-grs.com example.com

Esa sencillez facilitó su implantación, pero también dejó carencias importantes que se volvieron evidentes a medida que crecía el sector.

Las limitaciones de WHOIS

• Sin formato de salida estándar. Cada registro y registrador elige sus propios nombres de campo, formatos de fecha y estructura. Uno muestra Registry Expiry Date, otro expires y otro paid-till. El software necesita analizadores frágiles para cientos de variantes.
• Sin descubrimiento de servidores. El protocolo no indica qué servidor es autoritativo para cada TLD. Los clientes dependen de listas fijas o de referencias incluidas en el texto de respuesta.
• Sin internacionalización. La RFC 3912 no define codificación de caracteres, así que las eñes, los acentos y otros caracteres no ASCII suelen aparecer corruptos.
• Sin autenticación ni cifrado. El tráfico viaja en texto plano y no hay forma de ofrecer distintos niveles de acceso según el usuario.
• Modelos thin y thick. En registros «thin» como .com, el registro solo guarda datos básicos y el cliente debe seguir una referencia al servidor WHOIS del registrador para obtener el resto.

Qué es RDAP y cómo funciona

RDAP se desarrolló en el grupo de trabajo WEIRDS del IETF como sucesor deliberado de WHOIS. En lugar de un protocolo de texto propio, utiliza peticiones HTTPS normales y devuelve JSON. Las consultas son URL de estilo REST, de modo que cualquier cliente HTTP, navegador o lenguaje de scripting puede usarlo sin bibliotecas especiales.

Las RFC que definen RDAP

Tipos de consulta

RDAP define un pequeño conjunto de rutas de objeto. Las más útiles para quien gestiona dominios son:

• /domain/ejemplo.es – datos de registro de un dominio
• /nameserver/ns1.ejemplo.es – información sobre un servidor de nombres
• /entity/IDENTIFICADOR – un registrador, titular u otro objeto de contacto
• /ip/192.0.2.0 y /autnum/64496 – bloques IP y números de sistema autónomo, servidos por los registros regionales de internet

Bootstrap: encontrar el servidor adecuado

IANA publica archivos JSON de bootstrap que asocian cada TLD, rango IP y rango de ASN con la URL base de su servicio RDAP. Para dominios, el archivo está en https://data.iana.org/rdap/dns.json. El cliente extrae el TLD de la consulta, lo busca en el archivo y envía la petición a la URL indicada. Así desaparecen las conjeturas y las listas codificadas a mano que necesitaban los clientes WHOIS.

Comparativa entre WHOIS y RDAP

Cómo consultar RDAP en la práctica

Como RDAP es simplemente HTTPS, basta con curl. Puede consultar directamente al registro o usar un servicio de redirección como rdap.org, que lee los datos bootstrap de IANA y le reenvía al servidor autoritativo.

curl -s https://rdap.verisign.com/com/v1/domain/example.com
curl -sL https://rdap.org/domain/example.com

Una respuesta abreviada tiene este aspecto:

{
  "objectClassName": "domain",
  "ldhName": "EXAMPLE.COM",
  "status": ["client delete prohibited", "client transfer prohibited"],
  "events": [
    {"eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z"},
    {"eventAction": "expiration", "eventDate": "2026-08-13T04:00:00Z"}
  ],
  "nameservers": [{"ldhName": "A.IANA-SERVERS.NET"}]
}

Para el seguimiento de renovaciones, lo más importante es el array events: el evento expiration es una marca de tiempo legible por máquina en formato ISO 8601, así que ya no hay que adivinar si 03/04/2027 significa marzo o abril. Los valores de estado reflejan los códigos EPP definidos en la RFC 5731, escritos en minúsculas y con espacios. Los datos de contacto aparecen en entities, tradicionalmente codificados como jCard (RFC 7095); las implementaciones más recientes están añadiendo JSContact como alternativa.

Errores y límites de consulta

Los servidores RDAP siguen la semántica HTTP habitual. Un 404 indica que el objeto no existe en ese servidor, lo que en un dominio suele significar que no está registrado. Un 429 indica que ha superado el límite de peticiones, así que un cliente correcto espera y vuelve a intentarlo más tarde. Las redirecciones (301, 302, 307) sirven para enviarle de un servidor a otro, por lo que conviene seguirlas siempre.

La política de ICANN y el fin de WHOIS en 2025

ICANN obligó a los registros y registradores de gTLD a ofrecer RDAP a partir del 26 de agosto de 2019. Durante varios años ambos protocolos convivieron. Tras modificar los contratos de registros y registradores, ICANN fijó el 28 de enero de 2025 como fecha a partir de la cual las partes contratadas ya no están obligadas a operar WHOIS en el puerto 43 para los TLD genéricos. Desde entonces, RDAP es la fuente definitiva de datos de registro para .com, .net, .org y los nuevos gTLD.

Algunos operadores siguen respondiendo en el puerto 43 de forma voluntaria, pero no conviene depender de ello. Cualquier script o sistema de monitorización que analice texto WHOIS de dominios genéricos debería migrarse a RDAP.

¿Y los dominios de código de país?

Los ccTLD como .es, .mx o .ar no están sujetos a los contratos de ICANN y fijan sus propias políticas. Cada vez más publican servicios RDAP en el archivo bootstrap de IANA, pero muchos siguen ofreciendo solo WHOIS y algunos no ofrecen ningún servicio público. Por eso, un cliente práctico comprueba primero el bootstrap y, si no figura una URL RDAP, recurre al servidor WHOIS del ccTLD.

Privacidad, ocultación de datos y RGPD

Desde la entrada en vigor del RGPD en mayo de 2018, la mayoría de los datos personales de los titulares en los registros de gTLD están ocultos. RDAP no revela por sí mismo más información que WHOIS; se aplican las mismas políticas. Lo que aporta es una forma estándar de indicar qué se ha ocultado y, en principio, de conceder a usuarios autenticados, como las fuerzas de seguridad, acceso a registros más completos. La Registration Data Policy de ICANN, que las partes contratadas debían aplicar antes del 21 de agosto de 2025, define qué campos se recogen, se publican o se ocultan.

Para la mayoría de los titulares esto significa que una consulta pública muestra el registrador, las fechas, los servidores de nombres y los códigos de estado, pero no el nombre ni el correo del titular. Si necesita contactar con él, el registro del registrador suele enlazar a un formulario de contacto o a una dirección de abuso.

RDAP para controlar renovaciones y caducidades

Para quien gestiona más de un puñado de dominios, el paso a RDAP es una buena noticia. Las fechas de caducidad llegan en un formato coherente y fácil de procesar, los códigos de estado están normalizados y el registrador se identifica con su ID de IANA. Todo ello hace que la monitorización automática sea mucho más fiable que extraer datos del texto WHOIS.

1. Localice el servidor RDAP autoritativo en el archivo bootstrap de IANA.
2. Obtenga el objeto del dominio y lea el evento expiration.
3. Revise códigos de estado como client hold, redemption period o pending delete, que indican un problema.
4. Recurra a WHOIS en los TLD sin RDAP y guarde los resultados en caché para respetar los límites de consulta.

TLDix sigue exactamente este enfoque. Su consulta WHOIS y RDAP de dominios prueba primero RDAP y recurre a WHOIS cuando hace falta, y la consulta de hosting usa la parte de IP y ASN de RDAP para identificar quién opera el servidor de un dominio. En la documentación se explica cómo se vigila la caducidad de los dominios que sigue.

Ideas clave

WHOIS sirvió bien a internet durante décadas, pero nunca se diseñó para datos estructurados, internacionalización ni control de acceso. RDAP resuelve esos problemas apoyándose en HTTPS y JSON, con un conjunto claro de RFC y un mecanismo de descubrimiento gestionado por IANA. En los TLD genéricos la transición está prácticamente completada; los ccTLD avanzan a su propio ritmo. Si desarrolla herramientas, escriba el código nuevo sobre RDAP y mantenga WHOIS solo como alternativa. Si simplemente es titular de dominios, el cambio se traduce en fechas de caducidad más precisas y menos sorpresas.