RDAP vs WHOIS: la guía completa de la transición (códigos EPP, RGPD, bloqueos)
Por CaptainDNS
Publicado el 17 de marzo de 2026
- WHOIS (puerto 43) ya no es obligatorio desde el 28 de enero de 2025 para los gTLDs. 374 TLDs ya lo han desactivado.
- RDAP (RFC 9082/9083) lo reemplaza: respuestas JSON estructuradas, HTTPS nativo, acceso diferenciado compatible con el RGPD.
- Los códigos EPP (como
clientTransferProhibited) indican el estado de protección de tu dominio. Un dominio sin transfer lock es vulnerable al robo. - Verifica tus dominios críticos con una herramienta RDAP: estados EPP, fechas de expiración, bloqueos activos.
En 2025, consultar un servidor WHOIS es como enviar un fax: el protocolo sigue funcionando, pero pertenece a otra época. Desde el 28 de enero de 2025, la ICANN ya no exige a los registros gTLD que mantengan un servicio WHOIS en el puerto 43. RDAP (Registration Data Access Protocol) es ahora el único protocolo obligatorio para acceder a los datos de registro de dominios.
Esta guía cubre la transición completa: por qué se reemplazó WHOIS, cómo funciona RDAP, qué significan los códigos EPP que aparecen en los resultados, cómo el RGPD ha transformado el acceso a los datos de contacto, y los bloqueos que debes activar para proteger tus dominios.
Prueba tus dominios ahora
WHOIS: 40 años de servicio y luego la jubilación
De RFC 812 (1982) al fin oficial (2025)
WHOIS fue formalizado en 1982 por la RFC 812, en una época en la que Internet contaba con unos pocos cientos de hosts. El protocolo es minimalista: el cliente abre una conexión TCP en el puerto 43, envía un nombre de dominio en texto plano y recibe una respuesta en texto libre. Sin formato estandarizado, sin cifrado, sin autenticación.
Durante 40 años, WHOIS cumplió su función: identificar a los responsables de un dominio. Pero sus limitaciones técnicas se convirtieron en problemas críticos a medida que Internet crecía.
Línea temporal ICANN del sunset de WHOIS
La ICANN planificó la transición a lo largo de varios años:
- 2015: publicación de las RFC 7480 a 7484 (primera versión de RDAP)
- 2019: obligación para todos los registros gTLD de soportar RDAP en paralelo con WHOIS
- 2023: publicación de las RFC 9082, 9083 y 9224 (versión consolidada de RDAP)
- 28 de enero de 2025: fin de la obligación de mantener WHOIS en el puerto 43 para los gTLDs
- Febrero de 2025: 74 registros gTLD cortan su servicio WHOIS en el mes siguiente al sunset
- Junio de 2025: el volumen de consultas RDAP supera al de WHOIS por primera vez
- Septiembre de 2025: 374 gTLDs han desactivado WHOIS
- Enero de 2026: la ICANN revoca la acreditación del registrar Brennercom por no implementar RDAP, un precedente que confirma que la conformidad RDAP no es opcional
El ritmo de la transición es claro: en enero de 2025, los registros gTLD procesaban aproximadamente 122 mil millones de consultas WHOIS al mes contra 7 mil millones en RDAP. En agosto de 2025, WHOIS había caído a 49 mil millones (descenso del 60 %) mientras que RDAP alcanzaba 65 mil millones. La inversión de las curvas se produjo en junio de 2025.
El estatus varía según el tipo de TLD. Para los gTLDs, RDAP es obligatorio y WHOIS es opcional. Para los ccTLDs (.fr, .de, .uk), la migración sigue siendo voluntaria ya que estos registros no están sujetos a los contratos ICANN. Aproximadamente el 60 % de los ccTLDs han desplegado RDAP (un incremento del 12 % desde enero de 2025), pero algunos pesos pesados como .de, .cn y .jp aún no tienen servicio RDAP.
¿Por qué había que reemplazar WHOIS?
Cinco problemas estructurales hacían a WHOIS inadecuado:
- Sin formato estandarizado: cada registro devuelve los datos en un formato diferente. Parsear las respuestas WHOIS exige código específico por registro.
- Sin cifrado: las consultas y respuestas transitan en texto claro por el puerto 43. Cualquier intermediario de red puede leerlas.
- Sin autenticación: imposible distinguir a un investigador de seguridad de un spammer. Todos reciben los mismos datos.
- Incompatible con el RGPD: WHOIS expone por defecto los datos personales del titular (nombre, dirección, email, teléfono). El RGPD prohíbe esta difusión sin base legal.
- Sin internacionalización: WHOIS no soporta Unicode. Los nombres de dominio internacionalizados (IDN) y los contactos no ASCII generan problemas.
RDAP: el sucesor moderno
¿Cómo funciona RDAP? (bootstrap IANA, consulta HTTP, respuesta JSON)
RDAP se basa en tres componentes:
1. El bootstrap IANA: ¿cómo encontrar el servidor correcto?
A diferencia de WHOIS, donde hay que conocer el servidor de cada registro, RDAP utiliza un registro centralizado mantenido por la IANA (RFC 9224). Este archivo JSON lista, para cada TLD, la URL del servidor RDAP correspondiente. El cliente RDAP consulta este archivo, identifica el servidor para el TLD buscado y envía la consulta.
2. La consulta HTTP: una simple URL
GET https://rdap.verisign.com/com/v1/domain/captaindns.com
Sin protocolo binario, sin puerto exótico. Es una consulta HTTPS estándar, compatible con cualquier navegador, cliente HTTP o herramienta de automatización.
3. La respuesta JSON: datos estructurados
El servidor devuelve un objeto JSON normalizado por la RFC 9083. Cada campo tiene un nombre definido, un tipo preciso y una semántica documentada. Ya no hay que parsear texto libre.
Comparativa WHOIS vs RDAP
| Criterio | WHOIS | RDAP |
|---|---|---|
| Protocolo | TCP puerto 43, texto plano | HTTPS, JSON estructurado |
| Cifrado | Ninguno | TLS nativo |
| Formato de respuesta | Texto libre, no estandarizado | JSON normalizado (RFC 9083) |
| Autenticación | Ninguna | OAuth 2.0, acceso diferenciado |
| Internacionalización | Limitada (ASCII) | Unicode completo (IDN soportado) |
| Descubrimiento del servidor | Manual (hardcoded por TLD) | Automático (bootstrap IANA, RFC 9224) |
| Conformidad RGPD | Imposible sin proxy | Nativa (redacción selectiva) |
| Estatus ICANN (gTLD) | Opcional desde 01/2025 | Obligatorio |
En la práctica: la misma consulta en WHOIS y en RDAP
Para hacer la diferencia tangible, aquí tienes lo que devuelven los dos protocolos para captaindns.com.
Respuesta WHOIS (texto plano, puerto 43):
Domain Name: CAPTAINDNS.COM
Registry Domain ID: 2925482234_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.infomaniak.com
Registrar URL: http://www.infomaniak.com
Updated Date: 2025-09-11T08:32:12Z
Creation Date: 2025-09-08T06:06:37Z
Registry Expiry Date: 2026-09-08T06:06:37Z
Registrar: Infomaniak Network SA
Domain Status: clientTransferProhibited
Name Server: CHELSEA.NS.CLOUDFLARE.COM
Name Server: HAL.NS.CLOUDFLARE.COM
DNSSEC: unsigned
Cada registro formatea esta respuesta de manera diferente. No hay esquema compartido, ni garantía sobre el orden o el nombre de los campos.
Respuesta RDAP (JSON estructurado, HTTPS):
{
"objectClassName": "domain",
"ldhName": "CAPTAINDNS.COM",
"status": ["client transfer prohibited"],
"events": [
{ "eventAction": "registration", "eventDate": "2025-09-08T06:06:37Z" },
{ "eventAction": "expiration", "eventDate": "2026-09-08T06:06:37Z" },
{ "eventAction": "last changed", "eventDate": "2025-09-11T08:32:12Z" }
],
"nameservers": [
{ "ldhName": "CHELSEA.NS.CLOUDFLARE.COM" },
{ "ldhName": "HAL.NS.CLOUDFLARE.COM" }
],
"secureDNS": { "delegationSigned": false },
"rdapConformance": [
"rdap_level_0",
"icann_rdap_technical_implementation_guide_1",
"icann_rdap_response_profile_1"
]
}
Los mismos datos, pero en un formato predecible, tipado y analizable por cualquier biblioteca JSON. El campo rdapConformance indica los perfiles ICANN que el servidor respeta, una información que no existía en WHOIS. Pruébalo tú mismo con el RDAP Lookup.
Thin vs thick registries: ¿por qué dos consultas para .com?
Para ciertos TLDs como .com, los datos de registro se reparten entre dos niveles:
- El registro (Verisign para .com) almacena los datos mínimos: nombre de dominio, servidores de nombres, fechas, estados EPP. Es un registro "thin".
- El registrar (el revendedor: OVHcloud, Gandi, GoDaddy, etc.) almacena los datos completos: contacto del titular, información de facturación, detalles administrativos.
Cuando consultas RDAP para un dominio .com, el registro Verisign devuelve los datos básicos e incluye un enlace hacia el servidor RDAP del registrar para los datos completos. Un cliente RDAP completo sigue este enlace automáticamente.
Otros TLDs como .fr (AFNIC) son registros "thick": todos los datos están centralizados a nivel del registro. Una sola consulta es suficiente.
Cifras clave 2025
- 374 gTLDs han desactivado WHOIS en el puerto 43
- 65 mil millones de consultas RDAP al mes procesadas por los registros gTLD (agosto de 2025)
- 100 mil millones de consultas RDAP mensuales entre todos los registros (gTLDs, RIRs, bootstrap IANA)
- 60 % de los ccTLDs han desplegado un servidor RDAP (frente al 48 % en enero de 2025)
- 100 % de los registros gTLD están obligados a soportar RDAP
Cobertura RDAP por tipo de TLD
Todos los gTLDs soportan RDAP, pero la cobertura de ccTLDs es desigual. Los registros nacionales no están vinculados por los contratos ICANN y migran a su propio ritmo.
| ccTLD | País | RDAP | Dominios registrados (est.) |
|---|---|---|---|
| .uk | Reino Unido | Sí (desde 2022) | 10,5 M |
| .fr | Francia | Sí (desde 2022) | 4 M |
| .nl | Países Bajos | Sí (desde 2024) | 6,2 M |
| .br | Brasil | Sí (desde 2017, pionero) | 5 M |
| .au | Australia | Sí (desde 2026) | 4,3 M |
| .de | Alemania | No (solo WHOIS) | 17,4 M |
| .cn | China | No (solo WHOIS) | 20 M |
| .eu | Unión Europea | No (solo WHOIS) | 3,6 M |
| .jp | Japón | No (solo WHOIS) | 1,7 M |
| .ru | Rusia | No (solo WHOIS) | 5 M |
| .us | Estados Unidos | No (solo WHOIS) | 1,8 M |
Para los ccTLDs sin RDAP, el fallback sigue siendo WHOIS en el puerto 43. Si gestionas un portafolio multi-TLD, tus herramientas deben soportar ambos protocolos en paralelo.
Rate limiting y consultas automatizadas
Como los servidores RDAP son simples APIs HTTPS, implementan rate limiting para evitar abusos (scraping masivo, recopilación de datos en bulk). Un cliente que supera el umbral autorizado recibe una respuesta HTTP 429 (Too Many Requests).
Buenas prácticas para las consultas automatizadas:
- Respeta la cabecera
Retry-After: cuando el servidor devuelve un 429, puede incluir una cabecera que indica el tiempo de espera antes de reintentar - Implementa un backoff exponencial: aumenta el intervalo entre cada intento (1s, 2s, 4s, 8s) con un componente aleatorio para evitar ráfagas sincronizadas
- Limita tu tasa de consultas: la mayoría de los servidores toleran una o dos consultas por segundo. Algunos, como Cloudflare, limitan a 10 consultas por cada 10 segundos
- Cachea los resultados: los datos RDAP cambian raramente. Un caché de unas horas reduce la carga sobre los servidores y acelera tus procesos
Códigos EPP: comprender los estados de tu dominio
Los resultados RDAP incluyen los códigos de estado EPP (Extensible Provisioning Protocol). Estos códigos indican el estado actual de tu dominio: ¿está protegido contra la transferencia? ¿En espera de eliminación? ¿Bloqueado por el registro?
Dos prefijos distinguen el origen del estado:
- client: establecido por el registrar (tu revendedor), modificable desde tu interfaz de gestión
- server: establecido por el registro (Verisign, AFNIC, etc.), modificable únicamente por el registro
Códigos de protección (buenos)
Estos códigos indican que hay protecciones activas en tu dominio. Su presencia es deseable.
| Código EPP | Significado | Por qué es importante |
|---|---|---|
clientTransferProhibited | Transferencia bloqueada por el registrar | Impide el robo de dominio mediante transferencia no autorizada |
serverTransferProhibited | Transferencia bloqueada por el registro | Protección adicional, frecuentemente asociada a un registry lock |
clientDeleteProhibited | Eliminación bloqueada por el registrar | Impide la eliminación accidental o maliciosa |
serverDeleteProhibited | Eliminación bloqueada por el registro | Protección a nivel de registro contra la eliminación |
clientUpdateProhibited | Modificación bloqueada por el registrar | Impide el cambio no autorizado de los servidores de nombres |
serverUpdateProhibited | Modificación bloqueada por el registro | Protección de registro contra modificaciones DNS |
Códigos de alerta (críticos)
Estos códigos señalan un problema o una acción urgente requerida.
| Código EPP | Significado | Acción requerida |
|---|---|---|
redemptionPeriod | Dominio eliminado, en periodo de gracia (30 días) | Contacta con tu registrar inmediatamente para restaurarlo |
pendingDelete | Eliminación definitiva inminente (5 días) | Última oportunidad de recuperación, contacta con el registro |
serverHold | Resolución DNS suspendida por el registro | El dominio ya no resuelve. Verifica las obligaciones con el registro |
clientHold | Resolución DNS suspendida por el registrar | Frecuentemente relacionado con un impago o una verificación de identidad pendiente |
Códigos transitorios (informativos)
Estos códigos indican una operación en curso. Son temporales.
| Código EPP | Significado | Duración típica |
|---|---|---|
pendingTransfer | Transferencia hacia otro registrar en curso | 5 días (periodo de aprobación) |
pendingCreate | Registro en proceso de tramitación | De unos minutos a unas horas |
pendingRenew | Renovación en proceso de tramitación | Unos minutos |
pendingUpdate | Modificación DNS en curso | Unos minutos |
addPeriod | Periodo de gracia tras el registro (eliminación con reembolso posible) | 5 días |
renewPeriod | Periodo de gracia tras la renovación | 5 días |
transferPeriod | Periodo de gracia tras la transferencia | 5 días |
autoRenewPeriod | Dominio renovado automáticamente, cancelación posible | 30 a 45 días |
Tabla completa de códigos EPP
El estado ok (o active) es el estado por defecto: indica que no hay ninguna restricción ni operación en curso. Este estado desaparece en cuanto se activa otro código de protección o restricción.
Un dominio correctamente protegido muestra como mínimo clientTransferProhibited. Un dominio crítico (marca, sitio principal) también debería tener clientDeleteProhibited y clientUpdateProhibited.
Bloqueo de dominio: la protección indispensable
Los 3 niveles de locks
Nivel 1: registrar lock (transfer lock)
Es el bloqueo básico, activable desde la interfaz de tu registrar. Establece el estado clientTransferProhibited e impide la transferencia del dominio hacia otro registrar sin tu autorización explícita.
Coste: gratuito en la mayoría de los registrars. No hay razón para no activarlo.
Nivel 2: registrar full lock
Además del transfer lock, este nivel añade clientDeleteProhibited y clientUpdateProhibited. El dominio no puede ser transferido, eliminado ni modificado (servidores de nombres, contactos) sin desactivar manualmente los locks.
Coste: generalmente gratuito, pero no siempre activado por defecto.
Nivel 3: registry lock
El propio registro bloquea el dominio con los estados serverTransferProhibited, serverDeleteProhibited y serverUpdateProhibited. Cualquier modificación exige un procedimiento manual ante el registro, frecuentemente con verificación de identidad.
Coste: de pago (de 50 a 300 EUR/año según el TLD y el registrar). Reservado a dominios críticos: marcas, sitios e-commerce, infraestructura.
Verificar tus locks con el RDAP Lookup
Para verificar el estado de tus bloqueos, consulta tu dominio mediante una herramienta RDAP. Los estados EPP devueltos indican inmediatamente qué locks están activos:
clientTransferProhibitedvisible: transfer lock activoclientDeleteProhibitedvisible: delete lock activoclientUpdateProhibitedvisible: update lock activo- Ninguno de estos estados, solo
ok: ninguna protección activa
¿Qué hacer si ningún lock está activo?
Si tu dominio solo muestra el estado ok sin ningún código de protección:
- Inicia sesión en la interfaz de tu registrar
- Busca la opción "bloqueo de transferencia", "transfer lock" o "domain lock"
- Actívala inmediatamente
- Para dominios críticos, activa también el delete lock y el update lock si están disponibles
- Verifica de nuevo mediante RDAP que los estados
clientTransferProhibitedaparezcan
Un dominio sin transfer lock puede ser transferido por un tercero que obtenga el código de autorización (authcode). El robo de dominios sigue siendo una amenaza real y los incidentes recientes lo confirman.
Caso real: el secuestro masivo durante la migración de Google Domains a Squarespace (2024)
En julio de 2024, la adquisición de los dominios de Google Domains por Squarespace provocó uno de los incidentes de domain hijacking más documentados del año. Entre el 9 y el 12 de julio, los atacantes tomaron el control de dominios pertenecientes a empresas crypto importantes: Celer Network, Compound Finance, Pendle Finance y Unstoppable Domains, entre otros.
La falla: Squarespace había migrado aproximadamente 10 millones de nombres de dominio desde Google Domains, pero sin exigir verificación por email al crear la cuenta. Los atacantes pudieron crear cuentas utilizando las direcciones email asociadas a los dominios migrados, antes de que los titulares legítimos lo hicieran. Una vez conectados, modificaron los registros DNS para redirigir el tráfico hacia sitios de phishing.
La autenticación multifactor no estaba activada por defecto en las cuentas migradas, y la plataforma no proporcionaba ni registro de auditoría ni notificación por email para las acciones sobre las cuentas.
Este incidente ilustra por qué los bloqueos EPP son esenciales. Un dominio con clientUpdateProhibited activo no habría podido ver sus servidores de nombres modificados, incluso tras una vulneración de la cuenta. Las protecciones EPP actúan como una red de seguridad independiente de la seguridad de la cuenta del registrar.
WHOIS, RDAP y RGPD: ¿qué datos siguen visibles?
Antes del RGPD (2018)
Antes de mayo de 2018, una consulta WHOIS devolvía todos los datos del titular sin restricción:
- Nombre completo y organización
- Dirección postal completa
- Email, teléfono, fax
- Contactos administrativo y técnico
Estos datos eran explotados masivamente: spam dirigido, phishing, suplantación de identidad, acoso a titulares. Los servicios de "WHOIS privacy" vendidos por los registrars eran la única protección.
Después del RGPD: redacción selectiva vs ocultación total
El RGPD (Reglamento General de Protección de Datos), aplicado desde mayo de 2018, impuso un cambio radical. Los datos personales ya no pueden difundirse sin base legal. Los registros y registrars adoptaron dos enfoques:
Redacción selectiva: los datos personales (nombre, dirección, email, teléfono) se ocultan o se reemplazan por menciones genéricas ("REDACTED FOR PRIVACY"). Los datos técnicos (servidores de nombres, fechas, estados EPP) permanecen visibles.
Ocultación total: algunos registros devuelven un mínimo absoluto de información. Solo el nombre de dominio, las fechas y los estados se exponen.
En la práctica, una consulta RDAP en 2026 devuelve típicamente:
| Dato | ¿Visible? |
|---|---|
| Nombre de dominio | Sí |
| Registrar | Sí |
| Fechas (creación, expiración, actualización) | Sí |
| Estados EPP | Sí |
| Servidores de nombres | Sí |
| Nombre del titular | No (oculto) |
| Dirección del titular | No (oculto) |
| Email del titular | No (oculto o email relay) |
| Teléfono del titular | No (oculto) |
Acceso diferenciado RDAP (anónimo, autenticado, privilegiado)
RDAP integra de forma nativa un sistema de acceso diferenciado, algo que WHOIS no podía ofrecer:
Acceso anónimo: solo datos públicos (nombre de dominio, fechas, estados, servidores de nombres). Es lo que devuelve una consulta RDAP estándar.
Acceso autenticado: mediante un token OAuth 2.0, un usuario identificado puede acceder a datos adicionales. Por ejemplo, el titular de un dominio puede consultar su propia información completa.
Acceso privilegiado: reservado a las fuerzas del orden, organismos de protección de la propiedad intelectual y equipos de ciberseguridad acreditados.
SSAD y RDRS: hacia un acceso estandarizado a los datos no públicos
La ICANN diseñó el SSAD (System for Standardized Access/Disclosure) para formalizar el acceso a los datos no públicos de los dominios. El proyecto, surgido del proceso EPDP Phase 2, abarca 18 recomendaciones interdependientes: acreditación de solicitantes, criterios de consulta, requisitos de respuesta, registro de auditorías y niveles de servicio.
En la práctica, el SSAD nunca se desplegó como tal. La evaluación operativa de enero de 2022 reveló un coste y una complejidad desproporcionados. La ICANN lanzó entonces el RDRS (Registration Data Request Service) como sistema de transición. Desde su lanzamiento, más de 13 000 cuentas de solicitantes únicos se han creado en el RDRS, enviando aproximadamente 3 600 solicitudes de divulgación de datos no públicos a los registrars gTLD.
En octubre de 2025, la junta directiva de la ICANN prorrogó el RDRS hasta diciembre de 2027. Durante este periodo, la ICANN mejora la interfaz de usuario y desarrolla un protocolo de autenticación dedicado a las fuerzas del orden. El RDRS sigue siendo un sistema de transición: la comunidad ICANN aún debate su evolución hacia un modelo permanente, ya sea el SSAD original o un sucesor simplificado.
Este modelo resuelve el conflicto fundamental entre transparencia y privacidad: los datos siguen existiendo en las bases de los registros, pero su acceso está condicionado al nivel de habilitación del solicitante.
Para los equipos de ciberseguridad, esta restricción complica las investigaciones sobre dominios maliciosos. Identificar al titular de un dominio de phishing exige ahora una solicitud formal ante el registrar, con justificación legal. El plazo de procesamiento varía de unas horas a varias semanas según el registrar y la jurisdicción.
Para los propietarios de marcas, la protección se refuerza: sus datos de contacto ya no quedan expuestos a actores maliciosos. A cambio, la vigilancia de registros de dominios abusivos (typosquatting, homoglifos) depende más de los datos técnicos (fechas, servidores de nombres, registrar) que de los datos de contacto.
🎯 Plan de acción recomendado
1. Verificar tus dominios
Consulta cada dominio crítico mediante una herramienta RDAP. Verifica los estados EPP, las fechas de expiración y los servidores de nombres. Identifica los dominios sin protección (estado ok solo). Prioridad a los dominios que soportan tráfico, email o una marca.
2. Activar los transfer locks
Para cada dominio sin clientTransferProhibited, activa el bloqueo de transferencia en la interfaz de tu registrar. Para dominios críticos (marca, sitio principal, email), añade clientDeleteProhibited y clientUpdateProhibited. El procedimiento toma menos de 2 minutos y el lock es efectivo inmediatamente.
3. Configurar DNSSEC
RDAP muestra el estado DNSSEC de tu dominio. Si aparece la mención "unsigned" o la ausencia de datos DNSSEC, activa la firma de zona. DNSSEC protege la integridad de tus registros DNS y constituye un prerrequisito para DANE (autenticación de certificados TLS por DNS). Verifica con el verificador DNSSEC que la cadena de confianza está completa, desde la raíz DNS hasta tu zona.
4. Actualizar tus scripts WHOIS
Si utilizas scripts o herramientas que consultan WHOIS en el puerto 43, mígralos a RDAP. Las bibliotecas RDAP existen en todos los lenguajes habituales (Python: rdap, Go: openrdap, JavaScript: rdap-client). El formato JSON es más sencillo de parsear que el texto libre WHOIS. Utiliza el bootstrap IANA para resolver automáticamente el servidor RDAP de cada TLD en lugar de mantener una lista estática de servidores. Verifica que tus consultas apuntan a los servidores correctos mediante el DNS Lookup para confirmar la resolución de tus dominios.
5. Planificar una auditoría periódica
Los estados EPP, las fechas de expiración y las configuraciones DNS evolucionan. Planifica una verificación trimestral de tus dominios críticos. Verifica que los transfer locks siguen activos (algunos registrars los desactivan temporalmente durante operaciones de mantenimiento), que DNSSEC funciona y que las fechas de expiración dejan un margen suficiente.
❓ FAQ - Preguntas frecuentes
FAQ
¿Cuál es la diferencia entre WHOIS y RDAP?
WHOIS utiliza el puerto TCP 43 y devuelve texto plano no estandarizado, sin cifrado ni autenticación. RDAP utiliza HTTPS y devuelve JSON estructurado (RFC 9083) con cifrado TLS nativo y soporte de acceso diferenciado mediante OAuth 2.0. RDAP es el sucesor oficial de WHOIS para los gTLDs desde enero de 2025.
¿Sigue funcionando WHOIS en 2026?
Para ciertos TLDs, sí. La ICANN ya no obliga a los registros gTLD a mantener WHOIS desde el 28 de enero de 2025, pero tampoco prohíbe mantenerlo. 374 gTLDs ya lo han cortado. Los ccTLDs (.fr, .de, .uk) no están sujetos a las reglas ICANN y pueden mantener WHOIS indefinidamente. En la práctica, prevé que WHOIS desaparecerá progresivamente.
¿Qué significa el código EPP clientTransferProhibited?
Este código indica que el registrar ha activado un bloqueo de transferencia en el dominio. No se puede iniciar ninguna transferencia hacia otro registrar mientras este estado esté activo. Es la protección básica contra el robo de dominio. Todo titular debería activarlo en sus dominios.
Mi dominio solo muestra el estado ok, ¿es normal?
El estado ok significa que no hay ninguna restricción activa. El dominio puede ser transferido, modificado o eliminado sin obstáculos. Si es un dominio importante, activa inmediatamente el transfer lock (clientTransferProhibited) a través de tu registrar para protegerlo.
¿Se pueden ver todavía los datos del propietario de un dominio?
En acceso anónimo, no. Desde el RGPD (2018), los datos personales del titular (nombre, dirección, email, teléfono) están ocultos en las respuestas WHOIS y RDAP. Solo los datos técnicos permanecen visibles: nombre de dominio, registrar, fechas, estados EPP, servidores de nombres. Un acceso autenticado o privilegiado puede revelar más datos según el nivel de habilitación.
¿Qué es el registry lock y cuánto cuesta?
El registry lock es un bloqueo aplicado a nivel del registro (Verisign, AFNIC, etc.), con los estados serverTransferProhibited, serverDeleteProhibited y serverUpdateProhibited. Cualquier modificación exige un procedimiento manual con verificación de identidad. El coste varía de 50 a 300 EUR/año según el TLD y el registrar. Se recomienda para dominios de marca y sitios de alto riesgo.
¿Cómo migrar mis scripts WHOIS a RDAP?
Reemplaza las consultas TCP puerto 43 por consultas HTTPS hacia los servidores RDAP. Utiliza el bootstrap IANA (RFC 9224) para descubrir automáticamente el servidor RDAP de cada TLD. Las respuestas JSON son más sencillas de parsear que el texto libre WHOIS. Existen bibliotecas RDAP para Python, Go, JavaScript, Ruby y la mayoría de los lenguajes habituales.
¿RDAP muestra la información DNSSEC de un dominio?
Sí. La respuesta RDAP incluye los datos de delegación segura (secure DNS) cuando DNSSEC está activo en el dominio: algoritmo, tipo de digest y huella DS. Si el dominio no tiene DNSSEC, esta sección está ausente o indica que la zona no está firmada.
Descarga las tablas comparativas
Los asistentes pueden reutilizar las cifras accediendo a los archivos JSON o CSV.
📖 Glosario
- WHOIS: protocolo de consulta de datos de registro de dominios (RFC 3912), que utiliza el puerto TCP 43. En proceso de reemplazo por RDAP.
- RDAP: Registration Data Access Protocol (RFC 9082/9083). Sucesor de WHOIS, basado en HTTPS y JSON, con cifrado y acceso diferenciado nativos.
- EPP: Extensible Provisioning Protocol (RFC 5730). Protocolo utilizado entre registrars y registros para gestionar dominios. Los códigos de estado EPP indican el estado de un dominio.
- Bootstrap IANA: archivo JSON centralizado (RFC 9224) que asocia cada TLD a la URL de su servidor RDAP. Permite el descubrimiento automático del servidor correcto.
- Registro (registry): organismo que gestiona un TLD. Verisign para .com, AFNIC para .fr. Almacena los datos de la zona y los registros de dominios.
- Registrar: revendedor acreditado que vende y gestiona nombres de dominio en nombre de los titulares. OVHcloud, Gandi, GoDaddy son registrars.
- Transfer lock: bloqueo que impide la transferencia de un dominio a otro registrar. Corresponde al estado EPP
clientTransferProhibited. - Registry lock: bloqueo aplicado a nivel del registro con verificación manual. Estados
serverTransferProhibited,serverDeleteProhibited,serverUpdateProhibited. - Thin registry: registro que almacena únicamente los datos mínimos (nombre, NS, fechas, estados). Los datos completos están en el registrar. Ejemplo: .com.
- Thick registry: registro que centraliza todos los datos, incluidos los contactos del titular. Ejemplo: .fr.
- Redemption period: periodo de gracia de 30 días tras la eliminación de un dominio, durante el cual el titular puede restaurarlo pagando unas tasas.
- RGPD: Reglamento General de Protección de Datos. Reglamento europeo que impone la protección de los datos personales y que provocó la ocultación de los datos de contacto en WHOIS y RDAP.
📚 Guías de RDAP y gestión de dominios relacionadas
- RDAP vs WHOIS: guía completa de la transición 2025 (este artículo)
- Ciclo de vida de un nombre de dominio: expiración, protección y buenas prácticas: las 7 etapas, riesgos y protecciones concretas.
