¿Por qué el contacto del titular está censurado en la mayoría de consultas WHOIS?

El Art. 6 del GDPR (efectivo 25 de mayo 2018) convirtió la publicación de datos personales (nombre, email, teléfono, dirección del titular) sin base legal en un riesgo regulatorio para los registradores europeos. ICANN respondió con la Especificación Temporal de Datos de Registro gTLD (mayo 2018), permitiendo a los registradores censurar los datos de contacto personales por defecto. La Política de Datos de Registro de ICANN permanente entró en vigor el 21 de agosto de 2025 y codifica el comportamiento post-GDPR para todos los registros gTLD: publicación mínima de nombre del registrador + IANA ID, códigos de estado (RFC 5731), fechas de creación/expiración/última actualización y nameservers; censura permitida (y efectivamente estándar) para nombre del titular, organización, dirección postal, teléfono, fax y email. El contacto de abuso del registrador debe siempre ser público. Los ccTLDs (.es, .uk, .de, .fr) operan bajo políticas nacionales — algunos precedieron la censura GDPR, otros publican más para titulares de tipo entidad legal.

¿Qué significan los códigos de estado EPP (clientHold, serverTransferProhibited)?

EPP (Extensible Provisioning Protocol, RFC 5731 Hollenbeck, agosto 2009) es el protocolo que los registradores usan para gestionar dominios en los registros. Cada dominio lleva uno o más códigos de estado que controlan su estado operativo. Los códigos con prefijo 'client' los establece el registrador (la parte contratada más cercana al titular): clientHold (delegación DNS suspendida, a menudo renovación impagada), clientTransferProhibited (registrador bloquea transferencias — predeterminado común para prevenir secuestros no autorizados), clientDeleteProhibited, clientUpdateProhibited, clientRenewProhibited. Los códigos con prefijo 'server' los establece el registro (el operador del TLD): serverHold, serverTransferProhibited (a menudo orden judicial o disputa UDRP), serverDeleteProhibited, serverUpdateProhibited, serverRenewProhibited. Los códigos server tienen prioridad sobre los códigos client — solo el registro puede limpiarlos. Otros estados: ok (sin restricciones), pendingCreate/Delete/Renew/Transfer/Update, inactive (sin nameservers configurados).

¿Por qué .es, .uk y .com.br devuelven campos distintos que .com?

Los ccTLDs (dominios de nivel superior de código país) operan bajo autoridad nacional, no bajo el marco de contrato gTLD de ICANN, así que cada registro establece su propio modelo de datos y política de divulgación. La Política de Datos de Registro de ICANN (efectiva 21 de agosto 2025) aplica solo a gTLDs (.com/.net/.org/.info, más todos los New gTLDs como .app/.dev). El .es español lo opera Red.es y usa un protocolo basado en XML con privacidad por defecto más estricta que el WHOIS gTLD legacy. El .uk lo opera Nominet y sigue las reglas de DPA / UK GDPR; los individuos no comerciales pueden optar por no aparecer en WHOIS del todo. El .com.br brasileño requiere CAPTCHA para consultas pesadas y limita el rate agresivamente. Algunos ccTLDs (.de Alemania, .nl Países Bajos) proveen RDAP; otros siguen siendo solo WHOIS. Siempre comprueba la política específica del ccTLD cuando construyas automatización que cruza límites de TLD.

Búsqueda WHOIS Online Gratis

Q: WHOIS vs RDAP — ¿cuál es la diferencia y cuál usa esta herramienta?

WHOIS (RFC 3912 Daigle 2004) es el protocolo legacy sobre TCP puerto 43: envías una consulta de texto libre, recibes texto libre como respuesta. Cada registrador inventa sus propias etiquetas de campo ('Registrar:', 'Sponsoring Registrar:', 'Registrar Name:'), haciendo el parseo automatizado frágil. RDAP (Registration Data Access Protocol) es el reemplazo moderno bendecido por el IETF, especificado en RFC 7480 (uso HTTP, Newton/Ellacott/Kong, marzo 2015), RFC 9082 (formato de query, Hollenbeck y Newton, junio 2021, que deja obsoleto el RFC 7482), RFC 7483 (esquema de respuesta JSON, Newton y Hollenbeck, marzo 2015) y RFC 7484 (registro de bootstrap para encontrar el servicio autoritativo, Blanchet, marzo 2015). RDAP devuelve JSON estructurado con nombres de campo predecibles ('ldhName', 'events', 'nameservers'), haciendo el parseo automatizado fiable. Esta herramienta usa RDAP vía el bootstrap de IANA (rdap.iana.org/dns/example.com), luego analiza el JSON para mostrarlo. La mayoría de gTLDs y ccTLDs modernos publican RDAP; unos pocos ccTLDs legacy aún son solo WHOIS.

Q: ¿Cuán actualizados están los datos, y cómo es el ciclo de vida?

RDAP refleja el estado actual del registro, que el registrador empuja vía EPP (RFC 5731 Hollenbeck 2009). La mayoría de actualizaciones propagan en 24 horas; algunos registradores hacen batch diario o reconciliación al final del día. Los registros nuevos normalmente son visibles en 60 minutos. Las transferencias siguen una ventana de Forma de Autorización (FOA) de 5 días según la Política de Transferencias de ICANN (aprobación por defecto si el Registrador de Récord no responde) durante la cual el dominio muestra estado pendingTransfer; las expiraciones pasan a autoRenewPeriod (45 días), luego redemptionPeriod (30 días, restaurable por una tarifa), luego pendingDelete (5 días), luego se borra. Las políticas de ICANN establecen estos plazos; los registros pueden añadir periodos de retención adicionales. Los cambios de delegación DNSSEC (registros DS en la zona padre) aparecen inmediatamente si están firmados. La expirationDate en RDAP es la expiración contractual; el borrado real sigue los periodos de gracia de redención + pendingDelete.

Búsqueda WHOIS — RDAP, Registrador, Códigos de Estado y Antigüedad de Dominio

Las consultas WHOIS recuperan metadatos de registro de dominio: registrador, fechas de creación/expiración, nameservers, códigos de estado EPP y (donde no esté censurado) datos de contacto del titular. El stack del protocolo tiene dos capas: WHOIS legacy sobre TCP puerto 43 (RFC 3912 Daigle, septiembre 2004) y la suite RDAP moderna sobre HTTPS — RFC 7480 (uso HTTP; Newton, Ellacott y Kong, marzo 2015), RFC 9082 (formato de query; Hollenbeck y Newton, junio 2021, que deja obsoleto el RFC 7482), RFC 7483 (esquema de respuesta JSON; Newton y Hollenbeck, marzo 2015) y RFC 7484 (registro de bootstrap; Blanchet, marzo 2015). RDAP devuelve JSON estructurado con nombres de campo predecibles; WHOIS legacy devuelve texto libre que varía por TLD. Los códigos de estado del dominio (clientHold, serverTransferProhibited, etc.) vienen del RFC 5731 (Hollenbeck, agosto 2009) EPP. Desde el GDPR (mayo 2018) la mayoría de titulares de gTLD están censurados; la Política de Datos de Registro de ICANN efectiva el 21 de agosto de 2025 codifica los mínimos de publicación post-Especificación-Temporal y las reglas de censura. Esta herramienta consulta el servicio RDAP público vía el bootstrap de IANA (rdap.iana.org), analiza el JSON, y muestra registrador, fechas, nameservers y códigos de estado analizados.

Cómo hacer una consulta WHOIS

Introduce un nombre de dominio (sin protocolo ni ruta — example.com, no https://example.com/path).
La herramienta consulta el bootstrap RDAP de IANA para encontrar el servidor RDAP autoritativo del TLD, luego emite una consulta RDAP.
Revisa el JSON analizado: registrador (con IANA ID), fechas clave, nameservers, códigos de estado EPP (con descripciones breves según RFC 5731).
Usa el contacto de abuso (siempre público según política ICANN) para denunciar malware/phishing — el contacto del titular está normalmente censurado bajo la Política de Datos de Registro post-GDPR.

Casos de uso comunes

Comprobar la expiración de un dominio antes de renovar o comprar uno similar — RDAP devuelve fechas ISO-8601 con zona horaria.
Identificar el registrador de un dominio para iniciar una transferencia — los IANA registrar IDs distinguen registradores con nombres similares.
Encontrar el contacto de abuso de un dominio que aloja contenido malicioso — público por mandato de la Política de Datos de Registro de ICANN.
Verificar la antigüedad de un dominio vía creationDate — los dominios nuevos correlacionan con phishing en el scoring de confianza; los antiguos llevan historial de reputación.

Preguntas frecuentes

¿Por qué el contacto del titular está censurado en WHOIS?

El Art. 6 del GDPR (mayo 2018) convirtió la publicación de datos personales sin base legal en un riesgo regulatorio. La Política de Datos de Registro de ICANN efectiva el 21 de agosto de 2025 codifica las reglas post-GDPR: registrador/fechas/estado/nameservers públicos, contacto del titular censurado por defecto. El contacto de abuso siempre es público según política ICANN.

WHOIS vs RDAP — ¿cuál usa esta herramienta?

RDAP vía bootstrap IANA (RFC 7484). RDAP devuelve JSON estructurado con campos nombrados (esquema RFC 7483); WHOIS legacy sobre TCP puerto 43 (RFC 3912) devuelve texto libre por registrador. RDAP es el reemplazo moderno IETF; WHOIS legacy queda como fallback para algunos ccTLDs.

¿Qué significan clientHold y serverTransferProhibited?

Según RFC 5731 (EPP, Hollenbeck 2009): los códigos con prefijo 'client' los establece el registrador (clientHold = delegación DNS suspendida, a menudo renovación impagada); los con prefijo 'server' el registro (serverTransferProhibited = el registro bloquea transferencias, a menudo orden judicial o UDRP). Los códigos server tienen prioridad sobre los client.

¿Por qué .es, .uk, .com.br devuelven campos distintos que .com?

Los ccTLDs operan bajo autoridad nacional, no bajo el marco gTLD de ICANN. La Política de Datos de Registro de ICANN (21 ago 2025) aplica solo a gTLDs (.com/.net/.org + New gTLDs). El .es usa Red.es, el .uk usa Nominet — cada uno con privacidad más estricta y conjuntos de campos distintos.

¿Cuán actualizados están los datos, y cómo es el ciclo de vida?

La mayoría de actualizaciones propagan en 24h vía EPP. Las transferencias pasan por una ventana de Forma de Autorización (FOA) de 5 días según la Política de Transferencias de ICANN (aprobación por defecto si el Registrador de Récord no responde) — estado pendingTransfer durante la ventana; las expiraciones pasan autoRenewPeriod (45d) → redemptionPeriod (30d, restaurable) → pendingDelete (5d) → borrado.

Cómo RDAP modernizó WHOIS — y qué le hizo la censura GDPR a los datos públicos

WHOIS como protocolo precede al propio DNS; el RFC 812 (1982) lo formalizó y el RFC 3912 (Daigle, 2004) modernizó la especificación. El formato de cable es una petición TCP al puerto 43: envías una cadena de query, recibes texto libre. Cada registrador inventa sus propias etiquetas de campo ('Registrar:', 'Sponsoring Registrar:', 'Registrar Name:'), haciendo el parseo automatizado frágil y forzando al tooling a mantener bibliotecas de regex por registrador. RDAP arregla esto reemplazando TCP+texto con HTTPS+JSON: el RFC 7480 especifica cómo emitir peticiones HTTP GET con patrones de URL predecibles (/domain/example.com), el RFC 9082 (la sintaxis de query actual, que reemplaza al RFC 7482 en junio de 2021) define la estructura de path, y el RFC 7483 especifica el esquema de respuesta JSON con campos nombrados como 'ldhName', 'events', 'nameservers' y 'status'. El registro de bootstrap RDAP de IANA (RFC 7484) le dice a los clientes qué servidor RDAP es autoritativo para un gTLD o bloque IP dado. Los códigos de estado EPP (RFC 5731, 2009) clasifican el estado del dominio: los códigos con prefijo 'client' los establece el registrador (clientHold, clientTransferProhibited), los códigos con prefijo 'server' el registro. Los códigos server tienen prioridad sobre los client — solo el registro puede limpiarlos. Post-GDPR (mayo 2018), ICANN publicó la Especificación Temporal que censuraba los datos personales del titular; esto evolucionó hacia la Política de Datos de Registro permanente efectiva el 21 de agosto de 2025, que codifica la publicación mínima (info del registrador, estado, fechas, nameservers) mientras permite la censura de los datos de contacto personales. El impacto práctico: el WHOIS de la mayoría de gTLDs ahora te muestra quién opera el dominio técnicamente (registrador) pero raramente quién es el dueño (titular) sin una petición legal o acreditación.

Identificación del registrador con IANA Registrar ID
Fechas de creación/actualización/expiración como ISO-8601 con zona horaria
Listado de nameservers analizado del array 'nameservers' de RDAP
Parseo de códigos de estado EPP según RFC 5731 con descripciones
Parseo de JSON RDAP según RFC 9082 (especificación actual, deja obsoleto el RFC 7482)
Consulta en vivo del bootstrap IANA (RFC 7484) para encontrar el servicio RDAP autoritativo

Gratis. Sin registro. Las tools de navegador (subred, JWT, fuerza de contraseña) corren localmente; las de consulta usan APIs públicas (Cloudflare DoH, RDAP, registros de certs). Detalle por herramienta en /es/methodology/.

Fuentes (7)

Daigle, L. (2004). WHOIS Protocol Specification. RFC 3912, IETF (September 2004 — TCP port 43, obsoletes RFC 954).
Newton, A., Ellacott, B., & Kong, N. (2015). HTTP Usage in the Registration Data Access Protocol (RDAP). RFC 7480, IETF (March 2015).
Hollenbeck, S., & Newton, A. (2021). Registration Data Access Protocol (RDAP) Query Format. RFC 9082, IETF (June 2021 — obsoletes RFC 7482).
Newton, A., & Hollenbeck, S. (2015). JSON Responses for the Registration Data Access Protocol (RDAP). RFC 7483, IETF (March 2015).
Blanchet, M. (2015). Finding the Authoritative Registration Data (RDAP) Service. RFC 7484, IETF (March 2015 — RDAP bootstrap registry; obsoleted by RFC 9224 in 2022).
Hollenbeck, S. (2009). Extensible Provisioning Protocol (EPP) Domain Name Mapping. RFC 5731, IETF (August 2009 — domain status codes: clientHold, serverTransferProhibited, etc.).
ICANN (2025). Registration Data Policy. ICANN consensus policy effective 21 August 2025 (codifies post-GDPR Temporary Specification, redaction rules and minimum publication requirements for gTLD registries).

Son los RFCs del IETF, las publicaciones del NIST y los estándares del W3C que la herramienta implementa o consulta. Localízalos en el IETF Datatracker (datatracker.ietf.org) o en el organismo correspondiente.

Guías relacionadas

Propagación DNS — Por qué "esperar 48 horas" es casi siempre incorrectoLos cambios DNS no se propagan — los cachés expiran. Cómo funcionan realmente TTL, negative caching y los resolvers públicos durante una migración.

Por Marco B. · Última verificación junio 2026 — corre en tu navegador