WHOIS de dominio: cómo consultar quién es el dueño y leer el registro

¿Qué es una consulta WHOIS de dominio?

Una consulta WHOIS de dominio es una petición a la base de datos pública de registro de un nombre de dominio. Todo dominio bajo un TLD genérico como .com, .net o .org tiene una ficha que conservan su registro y su registrador, y cualquiera puede leer la parte pública de esa ficha. La consulta devuelve quién es el registrador, cuándo se creó el dominio, cuándo caduca, qué servidores de nombres utiliza y un conjunto de códigos de estado que indican si está bloqueado, suspendido o a punto de eliminarse.

El nombre viene del comando original de Unix. En 1982 el directorio de ARPANET se podía consultar escribiendo whois seguido de un nombre, y el RFC 3912 estandarizó después ese protocolo de texto plano sobre el puerto TCP 43. La palabra se quedó aunque el protocolo de debajo haya cambiado: desde el 28 de enero de 2025, la ICANN ya no obliga a los registros ni a los registradores de gTLD a mantener el WHOIS del puerto 43, y los mismos datos se sirven por RDAP, una API JSON. Casi todas las herramientas, incluida la consulta WHOIS de DNS Robot, preguntan primero a RDAP y siguen llamando ficha WHOIS al resultado.

Lo que una consulta WHOIS ya casi nunca devuelve es el nombre, la dirección y el correo del titular. Desde que el RGPD (GDPR) entró en vigor en mayo de 2018, los registradores ocultan por defecto los datos personales de contacto en todo el mundo. El resto de esta guía explica qué sigue estando ahí, cómo leerlo y cómo llegar hasta el propietario cuando los campos de contacto dicen REDACTED FOR PRIVACY.

Qué contiene una ficha WHOIS

Esta es una ficha real del registro para example.com, obtenida hoy con el comando whois en macOS. Todas las fichas de gTLD tienen la misma forma, así que en cuanto sepas leer esta sabrás leer cualquier otra:

• Identidad — Domain Name y Registry Domain ID. El ID es la clave interna del registro y no cambia nunca, ni siquiera cuando el dominio cambia de manos.

• Registrador — la empresa a la que paga el titular. Registrar IANA ID es el número único del registrador en la lista de registradores de la IANA; Registrar WHOIS Server es donde viven los campos de contacto, porque en .com y .net el propio registro no guarda ningún contacto.

• Fechas — Creation Date, Updated Date y Registry Expiry Date. Las tres van en UTC. La fecha de creación es la que informa un comprobador de antigüedad de dominios.

• Estado — uno o varios códigos de estado EPP. Son la parte más útil y la peor interpretada de la ficha; tienen su propia sección más abajo.

• Delegación — los servidores de nombres y el indicador DNSSEC. Es el puente entre WHOIS y DNS: cambia aquí los servidores de nombres y todos los registros DNS del dominio se mueven con ellos.

Domain Name: EXAMPLE.COM
Registry Domain ID: 2336799_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.iana.org
Registrar URL: http://res-dom.iana.org
Updated Date: 2026-08-14T08:01:43Z
Creation Date: 1995-08-14T04:00:00Z
Registry Expiry Date: 2027-08-13T04:00:00Z
Registrar: RESERVED-Internet Assigned Numbers Authority
Registrar IANA ID: 376
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Name Server: ELLIOTT.NS.CLOUDFLARE.COM
Name Server: HERA.NS.CLOUDFLARE.COM
DNSSEC: signedDelegation
DNSSEC DS Data: 2371 13 2 C988EC423E3880EB8DD8A46FE06CA230EE23F35B578D64E78B29C3E1C83D245A
>>> Last update of whois database: 2026-09-18T01:28:30Z <<<

La ficha se divide en cinco bloques y cada uno responde a una pregunta distinta:

Cómo hacer una consulta WHOIS

Hay tres formas de lanzar una consulta y todas devuelven los mismos datos de fondo. Elige según la frecuencia con la que la necesites y según si quieres la salida en bruto.

Método 1: usar una herramienta WHOIS online

Abre la consulta WHOIS de DNS Robot, escribe el dominio a secas (example.com, no https://www.example.com/pagina) y pulsa Intro. La herramienta consulta directamente el servidor RDAP del registro en los TLD más comunes, recurre al bootstrap de rdap.org para el resto y muestra la ficha ya interpretada: registrador con su contacto de abuso, fechas de creación, actualización y caducidad, códigos de estado explicados en lenguaje llano, servidores de nombres, estado de DNSSEC y antigüedad del dominio. En nuestras pruebas, una consulta de dnsrobot.net respondió en 387 ms.

ICANN Lookup es la alternativa oficial. Es autoritativa para cualquier gTLD, pero no devuelve nada útil para la mayoría de dominios de país, y no tiene historial, ni modo masivo, ni enlaces a datos DNS. Las webs de los registradores (GoDaddy, Namecheap, Cloudflare) también ofrecen páginas WHOIS; funcionan, pero están hechas para venderte el dominio si está libre.

Método 2: el comando whois (macOS, Linux, Windows)

macOS y casi todas las distribuciones de Linux incluyen un cliente whois. Habla el WHOIS del puerto 43, sigue automáticamente la derivación del registro al registrador e imprime las dos fichas una detrás de otra:

# Consulta básica (sigue la derivación registro -> registrador)
whois example.com

# Consultar un servidor concreto y saltarse la derivación
whois -h whois.verisign-grs.com example.com

# Solo las líneas que suelen importar
whois example.com | grep -iE 'Registrar:|Creation Date|Expiry|Domain Status|Name Server'

# Debian/Ubuntu: instalarlo si falta
sudo apt install whois

Windows no trae whois. Las dos opciones limpias son la herramienta de Sysinternals de la propia Microsoft y consultar RDAP con el curl que viene incluido en Windows 10 y 11:

Windows: whois de Sysinternals o curl

Descarga whois.exe de la suite Sysinternals, ponlo en el PATH y la sintaxis será la misma que en Unix. Si prefieres no instalar nada, pregunta directamente al servidor RDAP y deja que PowerShell dé formato al JSON:

# whois de Sysinternals (una vez descargado)
whois -v example.com

# Sin instalar nada: consulta RDAP y formatea el JSON
curl.exe -s -H "Accept: application/rdap+json" https://rdap.org/domain/example.com | ConvertFrom-Json | Select-Object ldhName, status, events, nameservers

Método 3: consultar RDAP directamente (para scripts)

Si necesitas datos WHOIS dentro de un script, olvídate del formato de texto y llama a RDAP. La respuesta es JSON con un esquema fijo, así que puedes extraer campos sin recurrir a expresiones regulares. El registro de .com responde en rdap.verisign.com; para cualquier otro TLD, rdap.org busca el servidor correcto en el fichero bootstrap de la IANA y te redirige:

# Ficha del registro de un .com, directamente desde Verisign
curl -s -H 'Accept: application/rdap+json' \
  https://rdap.verisign.com/com/v1/domain/example.com | jq '{status, events, nameservers: [.nameservers[].ldhName]}'

# Cualquier TLD: deja que rdap.org encuentre el servidor autoritativo
curl -sL https://rdap.org/domain/example.org | jq '.events'

# Salida de ejemplo
{
  "status": ["client delete prohibited", "client transfer prohibited", "client update prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z" },
    { "eventAction": "expiration",   "eventDate": "2027-08-13T04:00:00Z" },
    { "eventAction": "last changed", "eventDate": "2026-08-14T08:01:43Z" }
  ],
  "nameservers": ["ELLIOTT.NS.CLOUDFLARE.COM", "HERA.NS.CLOUDFLARE.COM"]
}

El array links de una respuesta del registro contiene un enlace related al servidor RDAP del propio registrador. Síguelo y obtendrás los objetos de contacto, ocultos o no. Eso es exactamente lo que una herramienta web bien hecha hace por ti en una sola petición. Si vas a construir algo sobre esto, el método de seis pasos de cómo probar un endpoint de API pública sirve igual para servidores RDAP que para cualquier otra API JSON.

Cómo leer los resultados (campo por campo)

La mayoría de la gente lanza una consulta para responder a una de estas cuatro preguntas. Esto es dónde vive cada respuesta dentro de la ficha.

¿El dominio ya está registrado? Si devuelve ficha, sí. Un dominio registrado siempre tiene Creation Date. Si el registro responde No match for domain o RDAP devuelve un HTTP 404, el nombre está libre, o reservado por el propio registro, algo habitual con palabras cortas y de diccionario. Usa un comprobador de disponibilidad de dominios para distinguir los dos casos, porque además lo verifica por DNS.

¿Cuándo caduca y llegará a liberarse? Lee Registry Expiry Date y después los códigos de estado. Un dominio que ha pasado su fecha de caducidad con el estado autoRenewPeriod o redemptionPeriod no se ha liberado: el titular todavía puede renovarlo. Solo pendingDelete significa que se va a liberar, y aun así suelen quedar cinco días más. La sección del ciclo de vida recorre la línea temporal completa.

¿Quién lo gestiona? Registrar es la empresa con la que hay que hablar, y el Registrar Abuse Contact Email y su teléfono se publican incluso cuando todo lo demás está oculto. Es intencionado: la Registration Data Policy de la ICANN obliga a que esos campos sigan siendo públicos.

¿Ha cambiado hace poco? Updated Date se mueve cada vez que el registrador envía un cambio: una renovación, un cambio de servidores de nombres, un bloqueo puesto o quitado. Un dominio que cambió de servidores de nombres la semana pasada y caduca el mes que viene tiene un perfil de riesgo muy distinto al de uno que nadie toca desde 2015. Si los servidores de nombres han cambiado, una consulta NS muestra dónde vive ahora el DNS.

Códigos de estado de dominio explicados (EPP)

Los códigos de estado son la línea más valiosa de una ficha WHOIS y también la peor interpretada. Los define el protocolo EPP y cada código tiene un significado fijo publicado por la ICANN. Un código que empieza por client lo ha puesto el registrador, normalmente a petición del titular; uno que empieza por server lo ha puesto el registro y solo el registro puede quitarlo.

El patrón que hay que recordar: clientTransferProhibited + clientUpdateProhibited + clientDeleteProhibited es sano y aburrido. Un dominio que de repente no resuelve y muestra clientHold necesita que su titular mire el correo, no el DNS. Y si estás esperando a comprar un dominio que alguien dejó caducar, nada de lo que ocurra antes de pendingDelete merece la pena vigilarlo.

Por qué el WHOIS muestra «REDACTED FOR PRIVACY»

Hasta 2018, la ficha WHOIS de un .com solía incluir el nombre completo del titular, su dirección postal, su teléfono y su correo. Los registradores vendían la privacidad WHOIS como un extra que sustituía esos campos por los datos de un servicio proxy. Entonces el RGPD entró en vigor el 25 de mayo de 2018, la ICANN publicó una especificación temporal en cuestión de días y los registradores empezaron a ocultar los datos personales de todo el mundo en lugar de intentar decidir a quién le aplicaba. Aquella norma provisional fue sustituida por la Registration Data Policy de la ICANN, que entró en vigor plenamente el 21 de agosto de 2025 y convierte la ocultación en permanente.

Esto es lo que devuelve hoy la ficha RDAP a nivel de registrador de cloudflare.com para su titular:

{
  "objectClassName": "entity",
  "roles": ["registrant"],
  "vcardArray": ["vcard", [
    ["fn",  {}, "text", "DATA REDACTED"],
    ["org", {}, "text", "DATA REDACTED"],
    ["adr", {}, "text", ["DATA REDACTED", "DATA REDACTED", "DATA REDACTED"]]
  ]],
  "remarks": [{ "title": "REDACTED FOR PRIVACY",
                "description": ["Some of the data in this object has been removed."] }]
}

La política es precisa sobre lo que sigue siendo público. Estos campos deben publicarse siempre en un dominio gTLD: el nombre de dominio, el nombre del registrador y su IANA ID, la URL del registrador, el correo y el teléfono de abuso del registrador, la fecha de creación, la fecha de caducidad, los servidores de nombres y los códigos de estado. La ocultación tampoco es siempre total: muchos registradores siguen publicando el nombre de la organización del titular cuando el dominio lo registró una empresa (una persona jurídica, que el RGPD no protege) y la provincia y el país del titular, así que una ficha censurada aún puede decirte que el propietario es una empresa de Delaware o una persona de Baviera.

La diferencia práctica entre privacidad y ocultación: un servicio de privacidad WHOIS de pago sigue reenviando el correo que se envía a su dirección proxy, mientras que la ocultación a secas elimina el correo y lo sustituye por un enlace a un formulario de contacto o por una dirección de reenvío anonimizada, según el registrador. En cualquiera de los dos casos, alguien de fuera consigue una vía para escribir al titular sin llegar a saber quién es.

Cómo saber quién es el dueño de un dominio cuando el WHOIS está oculto

La ocultación cerró la puerta principal, pero un dominio deja huellas por todas partes. Ve por estos pasos en orden; cada uno lleva un minuto y la mayoría de titulares se identifican en el tercero.

• Lee lo que no está oculto. Los campos de organización, provincia y país suelen sobrevivir. El propio registrador acota mucho: un dominio en MarkMonitor o CSC pertenece a una gran corporación; uno en Cloudflare Registrar es probablemente de un desarrollador o de una startup.

• Usa el relé de contacto del registrador. Todo registrador está obligado a darte una forma de llegar al titular: un correo anonimizado del tipo abc123@contact.gandi.net, o un formulario web enlazado desde la salida del WHOIS. Los mensajes legítimos se reenvían.

• Mira el certificado SSL. Los certificados con validación de organización (OV) y validación extendida (EV) llevan la razón social en el campo Subject. Pasa el dominio por un comprobador SSL y lee la cadena del certificado; la guía sobre cadenas de certificados SSL muestra dónde encaja la organización.

• Fíjate en el DNS. El campo RNAME del registro SOA es el correo del administrador de la zona con la @ sustituida por un punto. Los registros TXT revelan el proveedor de correo, los tokens de verificación de Google, Microsoft y Facebook, y a veces el nombre de la empresa sin más. Una consulta DNS de SOA y TXT lleva segundos, y un buscador de subdominios saca a la luz nombres como mail., crm. o jira. que delatan las herramientas que usa una empresa.

• Consulta el historial WHOIS. Las fichas anteriores a mayo de 2018 eran públicas y varios servicios comerciales las han archivado. Un dominio registrado en 2012 casi seguro tiene una ficha histórica sin censurar con el titular original.

• WHOIS inverso. Si tienes un dato conocido (el nombre de una empresa o un correo que haya sobrevivido), los servicios de WHOIS inverso buscan todos los dominios que alguna vez lo declararon. Es caro, pero así es como los equipos de protección de marca cartografían la cartera de un ciberocupa.

• Presenta una solicitud formal. Para una necesidad legal como una disputa de marca, phishing o fraude, el Registration Data Request Service (RDRS) de la ICANN dirige una solicitud formal de divulgación al registrador. Se lanzó el 28 de noviembre de 2023 y solo funciona con gTLD; no hay equivalente para la mayoría de ccTLD.

WHOIS frente a RDAP: qué cambió en 2025

RDAP (Registration Data Access Protocol) lo diseñó el IETF para arreglar todo lo que estaba roto en el WHOIS del puerto 43, y es lo que tu herramienta de consulta usa hoy en realidad. Las diferencias importan si construyes algo sobre estos datos:

Dos consecuencias prácticas. La primera: si algún script tuyo hace scraping de la salida de texto de whois, tiene los días contados; los registros pueden apagar su servicio del puerto 43 en cualquier momento y algunos ya lo han hecho: whois.nic.google, de Google Registry, que servía .app y .dev, ya ni siquiera resuelve. La segunda: el bootstrap de RDAP resuelve el problema que WHOIS nunca resolvió; dado example.museum, un cliente descarga data.iana.org/rdap/dns.json una vez, busca la entrada de museum y consulta el servidor autoritativo sin ningún conocimiento grabado a fuego en el código. La ICANN informó de que RDAP gestionaba más de 10.000 millones de consultas al mes en diciembre de 2024.

Dominios de país: cada registro lo hace a su manera

Las políticas de la ICANN obligan a los gTLD. Los TLD de código de país (.es —que gestiona Red.es—, .de, .uk, .br, .jp y unos 300 más) ponen sus propias reglas, y una consulta WHOIS sobre un ccTLD puede devolver desde una identidad completa y validada hasta prácticamente nada. Esto es lo que ha devuelto hoy el servidor del puerto 43 de DENIC, el registro de .de, para example.de:

% The DENIC whois service on port 43 doesn't disclose any information concerning
% the domain holder, general request and abuse contact.
% This information can be obtained through use of our web-based whois service
% available at the DENIC website:
% https://webwhois.denic.de/?lang=en

Domain: example.de
Nserver: ns1078.ui-dns.biz
Nserver: ns1078.ui-dns.com
Nserver: ns1078.ui-dns.de
Nserver: ns1078.ui-dns.org
Status: connect
Changed: 2018-08-10T05:24:12+02:00

Ni registrador, ni fechas, ni titular, y el vocabulario de estados (connect) es propio de DENIC en lugar de EPP. Otros registros se sitúan en puntos distintos de la escala:

WHOIS de una IP: quién es el dueño de una dirección IP

El mismo comando whois funciona sobre una dirección IP, pero la respuesta viene de otra base de datos. Los nombres de dominio los gestionan registros y registradores; los bloques de direcciones IP los asignan los cinco Registros Regionales de Internet (ARIN en Norteamérica, RIPE NCC en Europa y Oriente Medio, APNIC en Asia-Pacífico, LACNIC en Latinoamérica y AFRINIC en África). Una ficha WHOIS de IP te dice qué organización tiene el bloque, su tamaño, el país de asignación y el contacto de abuso, que es justo lo que necesitas cuando una dirección ataca tu servidor o te envía spam.

# WHOIS por el puerto 43: el cliente encuentra el RIR correcto automáticamente
whois 1.1.1.1

# RDAP: rdap.org redirige al RIR correcto (aquí APNIC)
curl -sL https://rdap.org/ip/1.1.1.1 | jq '{name, handle, startAddress, endAddress, country, type}'

# Salida
{
  "name": "APNIC-LABS",
  "handle": "1.1.1.0 - 1.1.1.255",
  "startAddress": "1.1.1.0",
  "endAddress": "1.1.1.255",
  "country": "AU",
  "type": "ASSIGNED PORTABLE"
}

Una ficha de IP nunca te dice qué webs están alojadas en esa dirección; una sola IP en la nube puede dar la cara por miles de dominios. Tampoco te dice la ubicación física del usuario, solo dónde se registró el bloque. Para una respuesta rápida sin línea de comandos, IP Lookup combina los datos del RIR con la geolocalización, y ASN Lookup muestra desde qué red se anuncia el bloque. Para ir de una IP a un nombre de host, usa el DNS inverso, que lee el registro PTR en lugar del WHOIS.

Leer las fechas de caducidad: el ciclo de vida de un dominio

Los códigos de estado solo cobran sentido sobre la línea temporal que sigue un dominio gTLD cuando su titular deja de pagar. La Expired Registration Recovery Policy de la ICANN fija los mínimos, registros y registradores añaden sus propios márgenes, y el resultado es un camino más largo de lo que la mayoría espera:

• Unos 30 días antes de caducar, y otra vez unos 7 días antes — el registrador tiene que avisar al titular por correo. Un tercer aviso llega en los 5 días siguientes a la caducidad.

• Día 0 (caducidad) — el registro renueva el dominio automáticamente y le pone autoRenewPeriod. El registrador tiene hasta 45 días para quedárselo o borrarlo. Además, debe romper la resolución DNS al menos 8 días antes de borrarlo, así que la web se apaga; muchos registradores la aparcan en una página que avisa de que el dominio ha caducado.

• Días 1–45 (gracia del registrador) — el titular puede renovar al precio normal. La mayoría de registradores recortan este plazo a 30 días o menos.

• Borrado → `redemptionPeriod` (30 días) — el registrador lo ha borrado. El titular todavía puede recuperarlo, normalmente pagando entre 80 y 200 dólares además de la renovación. Nadie más puede registrarlo.

• `pendingDelete` (5 días) — ya no es posible recuperarlo. Al final de esta ventana, a una hora que el registro no anuncia, el nombre se purga y queda disponible.

• Caída — el dominio queda libre para registrar, y los servicios de drop-catching que llevan tiempo sondeando el registro compiten por él en cuestión de milisegundos.

Así que un dominio cuyo WHOIS muestra una fecha de caducidad de hace dos semanas está normalmente a entre 60 y 75 días de quedar realmente disponible, y puede que no llegue nunca: el titular puede recuperarlo en cualquier momento hasta pendingDelete. Vigila la línea de estado, no la fecha de caducidad. Basta con lanzar una consulta WHOIS al día y anotar la transición de estado.

Para qué se usan de verdad las consultas WHOIS

Más allá de «¿está libre este nombre?», hay un puñado de tareas que aparecen una y otra vez en las colas de soporte y en los equipos de seguridad.

Verificar una web antes de fiarte de ella. Una tienda que dice llevar diez años en el negocio y cuyo dominio se creó hace tres semanas te está diciendo algo. La fecha de creación, el registrador y los servidores de nombres se comprueban en diez segundos y son imposibles de falsear en la ficha del registro.

Diagnosticar una web que ha dejado de resolver. Antes de tocar el DNS, confirma que el dominio no está caducado ni en clientHold; si lo está, ningún cambio de DNS servirá de nada. Después de migrar de servidores de nombres, las líneas Name Server del WHOIS confirman que el registrador aplicó el cambio de verdad, algo que puede tardar hasta 48 horas en propagarse.

Comprar un dominio que ya está cogido. El WHOIS te dice el registrador (que normalmente tiene servicio de intermediación), si el dominio está bloqueado, cuánto tiempo lleva el titular actual con él y si va camino de caducar.

Investigar phishing o abuso. El Registrar Abuse Contact Email se publica precisamente para que puedas denunciar un dominio malicioso a quien puede suspenderlo. Combínalo con el contacto de abuso del WHOIS de IP del proveedor de alojamiento.

Auditar tu propia cartera. Las empresas pierden más dominios por tarjetas de crédito caducadas que por ataques. Un repaso WHOIS trimestral de todos tus dominios, comprobando fechas de caducidad y estado de bloqueo, es un seguro barato.

Referencia de campos WHOIS

Una referencia rápida de todos los campos que verás en una ficha gTLD, con su equivalente en RDAP para quien tenga que parsear el JSON:

Si una ficha que estás mirando no encaja en esta tabla, casi seguro que tienes delante un ccTLD, y entonces la referencia es la documentación del propio registro.