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 RFC 812 describía el servicio NICNAME/WHOIS de ARPANET en el puerto TCP 43, que se consultaba escribiendo whois seguido de un nombre; el RFC 3912 es la especificación vigente de ese protocolo de texto plano. 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 (salvo en .com, .name y .post), 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 de example.com, obtenida el 27 de octubre de 2026 con el comando whois en macOS. Todas las fichas de gTLD tienen la misma forma, así que si sabes leer esta, sabes leer cualquiera:

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-10-26T19:13:27Z <<<

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

• 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.

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 un dominio (una URL o un correo pegados también valen: la herramienta lee de ahí el dominio registrado) y pulsa Intro. La herramienta pregunta al servidor RDAP del propio registro (el de la lista de la IANA, más registros como DENIC que mantienen RDAP fuera de ella) y luego a la ficha del registrador por los campos de contacto; para los TLD sin RDAP, que son unos dos de cada tres dominios de país (entre ellos .jp, .ru, .it y .eu), consulta en su lugar el servidor del puerto 43 del registro. Obtienes el registrador con su contacto de abuso, las fechas de creación, actualización y caducidad, los códigos de estado explicados en claro, los servidores de nombres, el estado DNSSEC y la antigüedad del dominio.

ICANN Lookup es la alternativa oficial. Es la fuente autorizada para todos los gTLD, pero solo cubre los dominios de país cuyo registro mantiene RDAP, y no tiene historial, ni consulta masiva, ni enlaces a datos DNS. Las webs de registradores como GoDaddy y Namecheap también ofrecen páginas WHOIS que leen las mismas fichas públicas; funcionan, pero están pensadas para venderte el dominio si está libre.

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

macOS incluye un cliente whois, y las distribuciones de Linux ofrecen uno. Habla WHOIS por el puerto 43, sigue automáticamente las redirecciones hasta el registrador e imprime cada ficha una tras otra (macOS empieza por la IANA, así que salen tres):

# Basic lookup (follows registry -> registrar referral)
whois example.com

# Query one specific server and skip the referral
whois -h whois.verisign-grs.com example.com

# Only the lines you usually care about
whois example.com | grep -iE 'Registrar:|Creation Date|Expiry|Domain Status|Name Server'

# Debian/Ubuntu: install if missing
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 y ponlo en tu PATH. -v sigue la redirección hasta el registrador, y un servidor concreto va después del dominio (whois example.com whois.verisign-grs.com) en lugar de después de -h. Si prefieres no instalar nada, pregunta directamente al servidor RDAP y deja que PowerShell dé formato al JSON:

# Sysinternals whois (after download)
whois -v example.com

# No install: query RDAP and pretty-print the JSON
curl.exe -sL -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:

# Registry record for a .com, straight from Verisign
curl -s -H 'Accept: application/rdap+json' \
  https://rdap.verisign.com/com/v1/domain/example.com | jq '{status, events, nameservers: [.nameservers[].ldhName]}'

# Any TLD: let rdap.org find the authoritative server
curl -sL https://rdap.org/domain/example.org | jq '.events'

# Output of the first command (trimmed: Verisign also returns a "last update of RDAP database" event)
{
  "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 va a quedar libre? Lee la fecha de caducidad y luego los códigos de estado. Un dominio en autoRenewPeriod o redemptionPeriod no se ha liberado; su titular aún puede renovarlo o restaurarlo. Solo pendingDelete significa que se va a liberar, y suele faltar todavía unos cinco días. La sección sobre el ciclo de vida, más abajo, recorre toda la línea de tiempo. No te fíes solo de la fecha del registro: cuando caduca un dominio gTLD, el registro lo renueva automáticamente por un año, así que Registry Expiry Date puede mostrar ya el año siguiente mientras la ficha del propio registrador (Registrar Registration Expiration Date) sigue mostrando el día en que el titular dejó de pagar. Cuando no coinciden, los códigos de estado deciden si el dominio se libera.

¿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 conviene recordar: clientTransferProhibited + clientUpdateProhibited + clientDeleteProhibited es sano y aburrido. Un dominio que de pronto no resuelve nada y muestra clientHold necesita que su titular revise el correo, no el DNS. Y si estás esperando para comprar un dominio que alguien dejó caducar, nada anterior a pendingDelete merece tu atención.

Por qué el WHOIS muestra «REDACTED FOR PRIVACY»

Hasta 2018, la ficha WHOIS de un .com solía mostrar el nombre completo del titular, su dirección postal, su teléfono y su correo. Los registradores vendían la privacidad WHOIS como extra, que sustituía esos campos por los datos de un servicio proxy. Después, el RGPD (GDPR) entró en vigor el 25 de mayo de 2018, el mismo día que una Temporary Specification que la ICANN había adoptado una semana antes, y los registradores empezaron a ocultar los datos personales de todos en lugar de intentar decidir quién entraba en el ámbito del reglamento. Esa norma provisional fue sustituida por la Registration Data Policy de la ICANN, plenamente en vigor desde el 21 de agosto de 2025: los registradores deben ocultar los datos personales cuando la ley de privacidad lo exija y pueden ocultarlos también para todos los demás.

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

{
  "objectClassName": "entity",
  "roles": ["registrant"],
  "vcardArray": ["vcard", [
    ["fn",  {}, "text", "DATA REDACTED"],
    ["org", {"type": "work"}, "text", "DATA REDACTED"],
    ["adr", {"cc": "US", "type": "work"}, "text",
      ["", "", ["DATA REDACTED", "DATA REDACTED"], "DATA REDACTED", "CA", "DATA REDACTED", ""]],
    ["contact-uri", {}, "uri", "https://domaincontact.registrar.cloudflare.com/cloudflare.com"]
  ]],
  "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. Además, la ocultación nunca es completa: la política exige publicar la provincia/estado y el país del titular, y también el nombre de la organización cuando el titular aceptó publicarlo, así que una ficha oculta aún puede decirte que el dueño está en California o en Baviera. En la ficha de arriba son CA y US, más un enlace contact-uri al formulario de contacto de Cloudflare.

La diferencia práctica entre privacidad y ocultación: un servicio de privacidad WHOIS de pago sigue reenviando el correo enviado a su dirección proxy, mientras que la simple ocultación 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 ambos casos, un tercero dispone de una vía para escribir al dueño sin 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. Sigue estos pasos en orden; cada uno lleva un minuto.

• Lee lo que no está oculto. La provincia/estado y el país se publican siempre, y la organización también cuando el titular lo aceptó. El propio registrador acota: un dominio en MarkMonitor o CSC es de una gran corporación; uno en Cloudflare Registrar probablemente es de un desarrollador o 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 mucho antes suele tener una ficha histórica sin ocultar con el titular original, salvo que ya entonces usara un servicio de privacidad.
• 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. Para una necesidad legal, como una disputa de marca, phishing o fraude, el Registration Data Request Service (RDRS) de la ICANN envía una solicitud formal de divulgación al registrador. Solo funciona con gTLD y solo con registradores participantes. En su piloto de dos años (del 28 de noviembre de 2023 al 30 de noviembre de 2025) recibió más de 3700 solicitudes, de las cuales el 26 % se aprobó y el 55 % se denegó (ICANN); la ICANN lo mantiene en marcha mientras la comunidad decide qué viene después.

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. Primera: si un script tuyo analiza la salida de texto de whois, vive de prestado: fuera de .com, .name y .post, los registros y registradores pueden apagar su servicio del puerto 43 en cualquier momento, y algunos ya lo han hecho. El whois.nic.google de Google Registry, que atendía .app y .dev, ya ni siquiera resuelve, y el servidor WHOIS del registrador GoDaddy responde a cada consulta con «This WHOIS server is being retired. Please use our RDAP service instead.» (ambos comprobados el 27 de octubre de 2026).

Segunda: el bootstrap de RDAP resuelve el problema que el WHOIS nunca resolvió: dado example.museum, un cliente descarga una vez data.iana.org/rdap/dns.json, encuentra la entrada de museum y consulta al servidor autorizado sin ningún conocimiento fijo en el código. El cambio se nota en el tráfico: los informes mensuales de la ICANN muestran que las consultas RDAP de gTLD pasaron de unos 7000 millones al mes en enero de 2025 a 65 000 millones en agosto de 2025, superando al WHOIS del puerto 43 en junio de 2025 (APNIC).

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

Las políticas de la ICANN solo obligan a los gTLD. Los dominios de país (.de, .uk, .br, .jp y unos 300 más) fijan sus propias reglas, y un WHOIS de un ccTLD puede devolver desde una identidad completa y validada hasta casi nada. Esto es lo que devolvió una consulta pública en ocho registros el 27 de octubre de 2026:

En el extremo opuesto de la escala, esta es toda la respuesta de DENIC por el puerto 43 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

Sin registrador, sin fecha de creación ni de caducidad, sin dueño, y el vocabulario de estados (connect) es el propio de DENIC y no el de EPP.

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.

# Port-43 WHOIS: the client finds the right RIR automatically
whois 1.1.1.1

# RDAP: rdap.org redirects to the right RIR (APNIC here)
curl -sL https://rdap.org/ip/1.1.1.1 | jq '{name, handle, startAddress, endAddress, country, type}'

# Output
{
  "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:

• About 30 days and again about 7 days before expiry — the registrar must email the owner. A third notice follows within 5 days after expiry.
• Day 0 (expiry) — the registry auto-renews the domain and sets autoRenewPeriod. The registrar has up to 45 days to keep it or delete it. Before deleting it, the registrar must stop it resolving for at least the last 8 days (or from expiry, if it deletes sooner), so the site goes dark; many registrars park it on a page that says the domain has expired.
• Day 1–45 (registrar grace) — the owner can still renew. ICANN only guarantees this while the domain is interrupted (ERRP); how long the registrar allows beyond that, and at what price, is its own policy, and it must publish its post-expiry fees on its website.
• Deletion → redemptionPeriod (30 days) — the registrar deleted it. The owner can still restore it, for a restore fee the registrar must show on its website, on top of the renewal. Nobody else can register it.
• pendingDelete (5 days) — restoration is no longer possible. At the end of this window, at a time the registry does not announce, the name is purged and becomes available.
• Drop — the domain is free to register, and drop-catching services that have been polling the registry compete for it within milliseconds.

Así, un dominio cuya ficha del registrador muestra una fecha de caducidad de hace dos semanas puede estar aún a entre 35 y 66 días de quedar realmente disponible, y puede que nunca lo esté: el titular puede recuperarlo en cualquier momento hasta pendingDelete. Vigila la línea de estado, no la fecha de caducidad. Basta con hacer una consulta WHOIS una vez al día y anotar el cambio 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 ha caducado ni está en clientHold; si lo está, ningún cambio de DNS ayudará. Tras migrar los servidores de nombres, las líneas Name Server del WHOIS confirman que el registrador aplicó de verdad el cambio; los resolvers pueden conservar en caché los servidores antiguos hasta 48 horas, el TTL de los registros de delegación de .com. Una consulta NS muestra lo que ve ahora el mundo.

Comprar un dominio que ya está ocupado. El WHOIS te dice el registrador (algunos tienen servicio de corretaje), si el dominio está bloqueado, cuánto tiempo lo lleva el titular actual y si se acerca a la caducidad.

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 propio portafolio. Los dominios se pierden por tarjetas de crédito caducadas tanto como por hackers. Un repaso WHOIS trimestral de todos tus dominios, revisando 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.