WHOIS y RDAP: qué datos de un dominio se pueden consultar hoy

Quien hizo su última consulta WHOIS hace diez años recordará un bloque de texto con nombre, dirección postal, teléfono y correo electrónico. Hoy casi todo eso ha desaparecido: la ficha es más corta, la mitad de los campos dice "REDACTED" y es muy posible que la herramienta utilizada ya ni siquiera hable el protocolo WHOIS.

Esta guía explica qué cambió, qué siguen diciendo los datos de registro y cómo leer las partes que de verdad importan: los códigos de estado y las fechas.

Qué sigue mostrando una ficha WHOIS

Los datos públicos de registro de un dominio genérico típico (.com, .net, .org, .app y similares) incluyen de forma fiable:

el registrador que gestiona el dominio, con su identificador IANA
las fechas de creación, última actualización y vencimiento
uno o varios códigos de estado
los servidores de nombres (nameservers) a los que está delegado el dominio
si el dominio está firmado con DNSSEC
el contacto de abuso del registrador

Con eso se responde a la mayoría de las preguntas operativas. ¿Está a punto de caducar este dominio? ¿A qué empresa hay que llamar para arreglarlo? ¿Cambiaron los servidores de nombres la semana pasada? ¿Hay un bloqueo de transferencia activo?

Lo que normalmente no aparece es la identidad del titular.

Por qué los datos del titular aparecen ocultos

Hasta mayo de 2018, los contratos de ICANN obligaban a los registradores a publicar los datos de contacto completos de cada titular de un gTLD. Cuando empezó a aplicarse el Reglamento General de Protección de Datos (RGPD) de la UE, publicar datos personales de ese tipo para cualquiera que los pidiera dejó de tener una base jurídica defendible. ICANN respondió con una Especificación Temporal que permitía a registros y registradores retirar los campos personales de la salida pública. La política permanente de datos de registro (Registration Data Policy) que vino después mantiene el mismo principio.

Algunas consecuencias prácticas:

La ocultación suele ser global. Muchos registradores la aplican a todos sus clientes, porque clasificar a los titulares según la ley de privacidad que los ampara es una fuente segura de errores.
Las organizaciones pueden seguir apareciendo. Una persona jurídica puede optar por que se publique el nombre de su organización. Algunas lo hacen.
Los servicios de privacidad y proxy son una capa aparte. Sustituyen los datos del titular por los del propio servicio. Existían mucho antes de 2018 y siguen siendo habituales.
Hay una vía para las solicitudes legítimas. Los registradores deben ofrecer una forma de contactar con el titular sin revelar su dirección, normalmente un formulario web o un correo de reenvío, y deben estudiar las solicitudes de divulgación de partes como las fuerzas de seguridad o los titulares de marcas.

Ninguna herramienta de consulta puede esquivar la ocultación, porque los datos se eliminan en origen. Un sitio que promete mostrar al "verdadero dueño" de un dominio con datos ocultos enseña datos antiguos recopilados en su día o, sencillamente, adivina.

Qué falla en el protocolo WHOIS

WHOIS nació a principios de los años ochenta. Un cliente abre una conexión TCP al puerto 43, envía un nombre de dominio seguido de un salto de línea y recibe texto libre. Ese es todo el protocolo. Las consecuencias:

Sin formato estándar. Cada registro inventa sus propios nombres de campo y su propia disposición. Los analizadores se rompen constantemente.
Sin errores estándar. "No encontrado", "límite de consultas superado" y "servidor averiado" son solo texto.
Sin internacionalización. No hay una codificación de caracteres definida.
Sin cifrado ni autenticación. Todo viaja en texto claro y no hay manera de dar a distintos usuarios distintos niveles de acceso.
Sin descubrimiento. Los clientes necesitan una lista mantenida a mano de qué servidor responde por cada TLD.

RDAP: el sustituto

El protocolo de acceso a datos de registro (RDAP, Registration Data Access Protocol) fue normalizado por el IETF en 2015 para resolver exactamente esos problemas. Es una API HTTPS que devuelve JSON:

Estructura definida. Las fechas son events con una acción como registration o expiration. Los contactos son entities con roles como registrar o abuse. Los valores de estado proceden de una lista cerrada.
Gestión de errores real. Un dominio que no existe devuelve HTTP 404. El límite de frecuencia devuelve 429.
Descubrimiento por bootstrap. IANA publica un archivo legible por máquinas que asocia cada TLD con la URL base de su servidor RDAP, de modo que los clientes siempre saben dónde preguntar.
Remisiones. La respuesta del registro puede enlazar con el servidor RDAP del registrador, que quizá tenga más detalle.
Margen para el acceso por niveles. Al funcionar sobre HTTPS, un servidor puede autenticar a quien pregunta y devolver más campos a quien tenga derecho a verlos.

Se puede probar con curl y nada más. La forma de una respuesta, recortada, es esta:

{
  "objectClassName": "domain",
  "ldhName": "example.com",
  "status": ["client transfer prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "2015-03-02T10:15:00Z" },
    { "eventAction": "expiration",   "eventDate": "2027-03-02T10:15:00Z" }
  ],
  "nameservers": [
    { "ldhName": "ns1.example.net" },
    { "ldhName": "ns2.example.net" }
  ],
  "secureDNS": { "delegationSigned": false }
}

ICANN exige a los registros y registradores de gTLD que operen RDAP desde agosto de 2019. En enero de 2025 terminó la obligación contractual de mantener el WHOIS del puerto 43 para los gTLD, lo que convierte a RDAP en la fuente de referencia. La gente sigue diciendo "consulta WHOIS", y como nombre de la tarea no tiene nada de malo, pero los datos llegan cada vez más por RDAP.

Los dominios de código de país (ccTLD) son otra historia. Cada uno fija su propia política: muchos operan RDAP, algunos siguen solo con WHOIS o con un formulario web, y unos pocos publican muy poca cosa. El .es, por ejemplo, lo administra Red.es con sus propias reglas de consulta.

Cómo leer los códigos de estado

Los códigos de estado proceden de EPP, el protocolo que se usa entre registradores y registros. RDAP los escribe con espacios ("client transfer prohibited"); la salida WHOIS usa camelCase. El prefijo indica quién puso el código: client es el registrador, server es el registro.

Códigos de todos los días

ok / active: sin restricciones. No hay nada bloqueado.
clientTransferProhibited: bloqueo de transferencia del registrador. Normal y deseable en los dominios propios.
clientUpdateProhibited, clientDeleteProhibited: bloqueos del registrador contra cambios o eliminación. Frecuentes en nombres de mucho valor.
serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited: bloqueos a nivel de registro. Se ven con los productos de "registry lock" y durante disputas.

Códigos que significan que el dominio no resuelve

clientHold: el registrador ha retirado el dominio de la zona. Causas típicas: renovación impagada, correo de contacto sin verificar, gestión de un caso de abuso.
serverHold: lo mismo, pero hecho por el registro. Suele ser un asunto legal o de política.
inactive: no hay servidores de nombres definidos, así que no hay nada que publicar.

Códigos del ciclo de vida

addPeriod: recién registrado. El registrador todavía puede eliminarlo con reembolso, normalmente dentro de cinco días.
autoRenewPeriod: el registro renovó el dominio automáticamente al vencer. El registrador aún puede revertirlo, por lo general durante un máximo de 45 días.
transferPeriod, renewPeriod: periodos de gracia breves tras una transferencia o una renovación explícita.
pendingTransfer: hay una transferencia a otro registrador en curso.
redemptionPeriod: el dominio fue eliminado. El titular anterior puede restaurarlo, normalmente dentro de 30 días y pagando una tarifa considerable.
pendingDelete: ya no es posible la restauración. Pasados unos cinco días, el nombre se libera.

Las duraciones exactas varían según el TLD y el registrador, y los ccTLD suelen tener ciclos de vida completamente distintos. Las cifras anteriores son el patrón habitual de los gTLD, no una promesa. El recorrido completo está en qué pasa cuando caduca un dominio.

Fechas de vencimiento: la del registro y la del registrador

Aquí es donde más gente tropieza.

Cuando un dominio gTLD llega a su fecha de vencimiento, la mayoría de los registros no lo elimina. Lo renueva automáticamente por un año, se lo cobra al registrador y lo pone en autoRenewPeriod. Si el cliente no paga nunca, el registrador elimina el dominio dentro del periodo de gracia y recupera el importe.

Durante esa ventana, la ficha pública puede mostrar una fecha de vencimiento un año en el futuro para un dominio cuyo dueño no ha pagado y cuya web ya ha sido sustituida por una página de aparcamiento. La fecha es exacta desde el punto de vista del registro. Simplemente no es la fecha que rige la relación entre usted y su registrador.

Algunas fichas exponen ambos valores:

Registry Expiry Date: 2027-03-02T10:15:00Z
Registrar Registration Expiration Date: 2026-03-02T10:15:00Z

Cuando difieren, la fecha del registrador es la que decide si su servicio sigue en pie. Reglas prácticas:

Renueve los dominios importantes mucho antes de la fecha de vencimiento, no durante los periodos de gracia.
Lea las fechas junto con los códigos de estado. Un vencimiento lejano más autoRenewPeriod significa "todavía sin pagar", no "a salvo".
Si espera registrar un nombre que está venciendo, tenga en cuenta que el titular actual puede recuperarlo normalmente hasta el final de redemptionPeriod.

La antigüedad del dominio

La fecha de creación se usa a menudo como indicio aproximado de lo asentado que está un dominio. Conviene recordar una salvedad: si un nombre se eliminó y se volvió a registrar, la fecha de creación se reinicia. Indica cuándo empezó el registro actual, no cuándo se usó el nombre por primera vez.

Compruébelo con OrbitProbe

La consulta WHOIS de OrbitProbe pregunta directamente por RDAP y muestra el registrador, las fechas, los códigos de estado, los servidores de nombres y el estado de DNSSEC, junto con el servidor de origen y la hora de la consulta. Los campos ocultos se muestran como ocultos. Si administra varios dominios, el portafolio del espacio de trabajo reúne sus fechas de vencimiento en una lista y envía recordatorios de renovación.

Si lo que busca es cambiar de registrador, los códigos de bloqueo descritos aquí vuelven a aparecer en cómo transferir un dominio.