WHOIS vs RDAP: qué cambió y por qué importa

RDAP reemplaza a WHOIS con JSON estructurado sobre HTTPS. Comparación técnica, ejemplos reales y lo que significa para tus herramientas.

RDAP (Registration Data Access Protocol) es el sucesor oficial de WHOIS, estandarizado por el IETF y adoptado por la ICANN. Ambos protocolos exponen los mismos datos de registro de dominio, información del registrante, fechas, servidores de nombres, códigos de estado EPP. La diferencia está en cómo lo hacen: RDAP usa HTTPS con respuestas JSON estructuradas, mientras que WHOIS devuelve texto plano por TCP en el puerto 43, sin formato consistente alguno. Para alguien que hace una búsqueda puntual, la diferencia es invisible. Para un desarrollador que construye herramientas o automatización, es fundamental.

El problema central de WHOIS

WHOIS lleva funcionando desde 1982. En cuatro décadas ha acumulado defectos de diseño que no pueden corregirse sin reemplazar el protocolo:

Sin estándar de formato. Cada registro formatea su respuesta de manera distinta. La salida de Verisign para .com no se parece a la de RIPE para dominios europeos, ni a la de NIC.mx para .mx. Parsear WHOIS implica escribir y mantener expresiones regulares frágiles y específicas de cada registro.
Sin autenticación. El protocolo trata a todos los clientes de manera idéntica, un bot que extrae millones de registros tiene el mismo acceso que un administrador verificando su propio dominio. Un control de acceso real es imposible de implementar.
Rate limiting artesanal. Cada operador lo implementa a su manera: algunos bloquean tras 10 peticiones por minuto, otros tras 5 o tras 1. No hay estándar sobre cómo debe comportarse un cliente bloqueado.
Sin internacionalización. Los caracteres no ASCII en nombres o direcciones de registrantes corrompen regularmente la salida WHOIS.
Sin compatibilidad nativa con el RGPD. WHOIS fue diseñado para mostrarlo todo a todos. Cuando llegó el RGPD en 2018, fue técnicamente imposible diferenciar qué podía mostrar un registrador al público, a terceros acreditados o a fuerzas del orden.
Puerto TCP 43, no HTTPS. Sin cifrado, sin certificados, sin códigos de error estandarizados.

Lo que RDAP aporta concretamente

RDAP resuelve cada uno de estos problemas:

Formato JSON normalizado (RFC 7483): cada servidor RDAP devuelve la misma estructura de campos, independientemente del registro. Sin ambigüedades al parsear.
Transporte HTTPS: cifrado, códigos de estado HTTP estándar, cabeceras de caché y toda la infraestructura web existente.
Control de acceso diferenciado: RDAP soporta autenticación y visibilidad de campos según el rol. Un registrador puede mostrar datos completos del registrante a terceros acreditados y campos redactados al público general.
Soporte Unicode nativo: nombres de registrantes en árabe, chino o cirílico llegan sin corrupción.
Bootstrapping estandarizado: un cliente puede encontrar automáticamente el servidor RDAP correcto para cualquier TLD consultando el archivo bootstrap de IANA en https://data.iana.org/rdap/dns.json. No hace falta mantener una tabla estática.
Enlaces relacionales: la respuesta JSON incluye enlaces href a entidades relacionadas (registrador, registrante), lo que permite seguir relaciones programáticamente.

WHOIS vs RDAP cara a cara

Criterio	WHOIS	RDAP
Formato de respuesta	Texto plano (variable)	JSON (RFC 7483)
Transporte	TCP puerto 43	HTTPS
Autenticación	Ninguna	Opcional (OAuth)
Formato estandarizado	No	Sí
Soporte Unicode	Limitado	Completo
Rate limiting	Ad hoc por operador	Estandarizado (HTTP 429 + Retry-After)
Control de acceso	No	Sí
Adopción ICANN	Legacy	Obligatorio para gTLDs desde 2019

Un ejemplo real: el mismo dominio, dos protocolos

Aquí se muestra cómo luce la consulta de github.com a través de cada protocolo.

Salida WHOIS (Verisign, puerto 43):

Domain Name: GITHUB.COM
Registry Domain ID: 1264983250_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.markmonitor.com
Updated Date: 2022-09-07T09:10:44Z
Creation Date: 2007-10-09T18:20:50Z
Registry Expiry Date: 2024-10-09T18:20:50Z
Registrar: MarkMonitor Inc.
Domain Status: clientTransferProhibited
Name Server: DNS1.P08.NSONE.NET
Name Server: DNS2.P08.NSONE.NET

Respuesta RDAP (rdap.verisign.com, JSON):

{
  "ldhName": "github.com",
  "handle": "1264983250_DOMAIN_COM-VRSN",
  "status": ["client transfer prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "2007-10-09T18:20:50Z" },
    { "eventAction": "expiration",   "eventDate": "2024-10-09T18:20:50Z" },
    { "eventAction": "last changed", "eventDate": "2022-09-07T09:10:44Z" }
  ],
  "nameservers": [
    { "ldhName": "dns1.p08.nsone.net" },
    { "ldhName": "dns2.p08.nsone.net" }
  ],
  "entities": [
    {
      "roles": ["registrar"],
      "vcardArray": ["vcard", [["fn", {}, "text", "MarkMonitor Inc."]]]
    }
  ]
}

En la salida WHOIS, extraer la fecha de vencimiento requiere parsear una línea que empieza por Registry Expiry Date:, y ese nombre de campo cambia según el registro. En la respuesta RDAP, siempre es events[?(@.eventAction=="expiration")].eventDate. Una ruta JSON predecible, cada vez.

¿Va a desaparecer WHOIS?

No de inmediato. WHOIS sigue siendo accesible en la mayoría de los registros, y muchos operadores lo mantendrán por razones de compatibilidad. Pero la dirección es clara: la ICANN exige a todos los registros gTLD el soporte de RDAP desde 2019, y el número de ccTLDs con endpoints RDAP crece cada año. Las herramientas construidas hoy deben consultar RDAP primero y recurrir a WHOIS solo si RDAP no está disponible para un TLD determinado. Eso es exactamente lo que hace Domain Sentinel.

Qué significa esto para los desarrolladores

Si estás construyendo algo que toca datos de registro de dominios, algunas conclusiones prácticas:

No escribas parsers de texto WHOIS. El costo de mantenimiento es real y la fiabilidad es pobre. Usa RDAP.
Usa el bootstrap de IANA para encontrar automáticamente el servidor RDAP correcto por TLD: curl https://data.iana.org/rdap/dns.json.
Una consulta RDAP simple se ve así: curl https://rdap.verisign.com/com/v1/domain/github.com
Gestiona correctamente las respuestas HTTP 429. Los servidores RDAP devuelven una cabecera Retry-After cuando se supera el límite de peticiones, respétala o tu IP quedará bloqueada.
Domain Sentinel expone una API que abstrae el bootstrapping RDAP, el rate limiting y el fallback a WHOIS. Si necesitas datos de dominio en producción sin construir esa infraestructura, es el camino más rápido.

Domain Sentinel consulta RDAP primero, con fallback automático a WHOIS para TLDs que aún no han migrado.

Prueba una consulta RDAP en tiempo real sobre cualquier dominio directamente en Domain Sentinel, la respuesta se parsea, anota y monitoriza automáticamente.