WHOIS vs RDAP: cómo funcionan los datos de dominio de ICANN (guía 2026)

Todo dominio deja un rastro de registro y, durante cuarenta años, la forma de leer ese rastro ha sido WHOIS. El protocolo sucesor impulsado por ICANN, RDAP, responde a las mismas preguntas mediante una interfaz REST moderna con JSON estructurado. Ambos están pensados para consultar un dominio cada vez, que es justo el formato equivocado para investigar, dimensionar un mercado o analizar infraestructura sobre millones de nombres. Esta guía explica en qué se diferencian realmente ambos protocolos, dónde deja de ser útil cada uno y qué aportan los archivos masivos de dominios que un protocolo de consulta jamás podrá dar.

Resumen rápido / Ideas clave

• WHOIS es un protocolo de texto plano sobre el puerto 43: sin esquema, sin nombres de campo estándar, sin formatos de fecha estándar. Cada operador de registro y cada registrador formatea su salida de forma ligeramente distinta, así que analizarla a escala obliga a mantener un parser por fuente.
• RDAP es el sucesor exigido por ICANN: RESTful, solo HTTPS, respuestas en JSON, códigos de error estandarizados, soporte de internacionalización y referencias entre servidores. Resuelve el problema del parseo, no el del acceso.
• Ninguno de los dos es una fuente de datos masivos: ambos están limitados por diseño. Consultar millones de dominios por WHOIS o RDAP acaba en throttling y bloqueos, y ningún operador de registro contempla ese uso como caso soportado.
• La redacción del GDPR se aplica a ambos: desde 2018, el nombre, el correo electrónico y los datos postales del titular aparecen redactados o sustituidos por un proxy en las respuestas públicas de la mayoría de dominios. El WHOIS/RDAP público no es una base de datos de contactos.
• Ninguno dice nada sobre la tecnología que usa un sitio: CMS, servidor web, CDN, proveedor de correo e IP quedan fuera del registro de registración. Esa información sale de la resolución DNS y del fingerprinting HTTP, no del operador de registro.
• WebTrackly vende la capa masiva: El formato de descarga depende del paquete y se indica en la página del producto.
• El análisis lo haces tú: los archivos son insumos para tus propias herramientas. No hay generador de consultas en el navegador, ni búsqueda por dominio individual, ni datos de contacto.

Índice de contenidos

1. Entender WHOIS: el protocolo heredado
2. Presentamos RDAP: el estándar moderno
3. WHOIS vs RDAP: comparativa directa
4. Dónde se detienen ambos protocolos
5. Qué contienen los archivos masivos de dominios
6. Comprar y procesar un paquete
7. Automatizar con la API de catálogo
8. Errores habituales al adquirir datos de dominios & cómo evitarlos
9. Preguntas frecuentes (FAQ)
10. Recursos relacionados

Entender WHOIS: el protocolo heredado

WHOIS es un protocolo de consulta y respuesta que sirve para interrogar bases de datos con los titulares registrados de un recurso de internet: un nombre de dominio, un bloque de direcciones IP o un número de sistema autónomo. Nació en los primeros años de internet y el IETF lo estandarizó a comienzos de los años ochenta. Su propósito era el de servicio de directorio: permitir que cualquiera averiguase quién es responsable de un recurso, sobre todo para diagnosticar problemas de red y gestionar abusos.

Su estructura es deliberadamente simple. Un registro WHOIS es un bloque de texto plano devuelto por el puerto TCP 43. El cliente se conecta al servidor WHOIS que opera el registrador o el operador de registro del dominio, envía el nombre de dominio y recibe de vuelta un bloque de texto.

Un registro WHOIS típico incluye:

• Datos del titular: nombre, organización, dirección, correo electrónico y teléfono del titular del dominio — hoy redactados en la mayoría de dominios.
• Contacto administrativo: la parte responsable de las cuestiones administrativas.
• Contacto técnico: la parte responsable de las cuestiones técnicas.
• Datos del registrador: la empresa a través de la cual se registró el dominio.
• Fechas de registración: fecha de creación, fecha de última actualización, fecha de expiración.
• Servidores de nombres: los servidores DNS autoritativos del dominio.
• Estado del dominio: códigos de estado EPP como clientTransferProhibited o pendingDelete.

El valor de WHOIS en su intención original era la transparencia y la rendición de cuentas. Si un sitio realizaba actividad maliciosa, o si había un fallo técnico, WHOIS ofrecía una vía hasta el responsable. Para la investigación competitiva aportaba datos básicos: fecha de registración, registrador y servidores de nombres.

Sus inconvenientes pesan más hoy. El mayor es la ausencia de esquema. Cada registrador y cada operador de registro formatea su salida de forma distinta, con etiquetas de campo, formatos de fecha y orden de secciones variables. Por eso el parseo automático exige expresiones regulares y lógica propia para cada fuente; un parser escrito contra la salida de un registrador falla a menudo con la de otro.

La limitación de tasa es la segunda restricción. Los servidores WHOIS están dimensionados para consultas individuales, no para extracción masiva. Consultar miles o millones de dominios acaba en throttling, bloqueo de IP o pantallas con CAPTCHA. Y además los datos envejecen: los titulares se mudan, cambian de dirección y dejan que los detalles se desactualicen, y los registradores no fuerzan las actualizaciones con demasiado rigor.

El cambio decisivo para quien esperaba usar WHOIS como fuente de contactos llegó con el GDPR en 2018. Para cumplirlo, ICANN obligó a los registradores a redactar los datos personales de la salida pública de WHOIS de los titulares afectados. Hoy, en la mayoría de dominios, el nombre, el correo electrónico y el teléfono del titular aparecen sustituidos por "REDACTED FOR PRIVACY" o por la dirección de reenvío de un servicio de privacidad. El WHOIS público debe tratarse como fuente de hechos técnicos y de registración, no personales.

Presentamos RDAP: el estándar moderno

Consciente de la inconsistencia de la salida de WHOIS y de la necesidad creciente de controles de acceso, ICANN impulsó el desarrollo de RDAP, el Registration Data Access Protocol. RDAP se diseñó como un sustituto estandarizado, seguro y extensible. ICANN lo adoptó en 2017 y, desde entonces, operadores de registro y registradores lo han ido implementando de forma progresiva.

La diferencia arquitectónica es la clave. En lugar de texto plano por el puerto 43, RDAP es un servicio web RESTful que devuelve datos estructurados, normalmente en JSON. Eso elimina el problema del parseo: con un esquema definido, un sistema automatizado puede extraer un campo por su nombre en vez de buscar patrones dentro de un bloque de texto.

Principales ventajas de RDAP frente a WHOIS:

• Formato de datos estandarizado: la salida en JSON es legible por máquina y se integra directamente en cualquier pipeline.
• Funciones de seguridad: RDAP funciona sobre HTTPS y admite autenticación y autorización, de modo que quien esté acreditado puede, en principio, recibir respuestas más completas que un solicitante anónimo.
• Internacionalización: soporte real para nombres de dominio internacionalizados y datos de contacto multilingües.
• Gestión de errores: códigos de estado HTTP y objetos de error estandarizados, para que el cliente distinga "no encontrado" de "límite de tasa alcanzado" o de "error del servidor".
• Referencias: una respuesta RDAP puede señalar al cliente el servidor autoritativo del objeto, lo que hace viables las consultas entre distintos operadores de registro.

El empuje de ICANN a favor de RDAP busca una vía uniforme y auditable de acceder a los datos de registración. Para cualquiera que consulte registros de registración de forma programática, RDAP es una mejora clara de fiabilidad frente a su predecesor.

RDAP no cambia lo que hay dentro del registro. Opera bajo los mismos mandatos de privacidad que WHOIS: los datos personales siguen redactados en las respuestas públicas. Puedes consultarlo con más limpieza, pero los campos de contacto siguen siendo proxies o marcadores. La cobertura tampoco es uniforme: no todos los operadores de registro y registradores han completado su despliegue de RDAP, así que algunos dominios solo son accesibles por WHOIS. Y la carga útil sigue siendo dato de registración: nada sobre la tecnología operativa, el alojamiento o el contenido del sitio.

WHOIS vs RDAP: comparativa directa

Dónde se detienen ambos protocolos

Al margen de sus diferencias, WHOIS y RDAP responden a una única pregunta: ¿qué dice el registro sobre este nombre? Varias categorías de preguntas quedan completamente fuera de ese alcance.

1. Sin detección de tecnologías. El registro de registración indica quién registró un dominio, no qué software ejecuta el sitio. El CMS, la plataforma de e-commerce, el servidor web y las librerías JavaScript se descubren descargando el sitio, no consultando al operador de registro.
2. Sin datos de contacto utilizables. El GDPR y normativas equivalentes han eliminado los datos del titular de las respuestas públicas. Existe acceso acreditado para fuerzas del orden y titulares de derechos; no es un canal de uso general.
3. Sin visión de la infraestructura. Más allá de los servidores de nombres, los protocolos no dicen nada sobre la IP resuelta, la red de alojamiento, el CDN delante del origen ni el proveedor de correo detrás de los registros MX.
4. Sin agregación. Incluso con el JSON limpio de RDAP, cubrir millones de nombres implica orquestar consultas contra cientos de servidores, cada uno con sus propios límites y su propia disponibilidad. Eso es un proyecto de infraestructura, no una consulta.
5. Sin garantía de frescura a escala. Los protocolos no tienen ningún mecanismo para indicarte qué ha cambiado desde tu última pasada. Detectar cambios significa volver a consultarlo todo.
6. Sin visión poblacional. No puedes preguntar a WHOIS ni a RDAP "cuántos dominios .de existen" ni "qué dominios resuelven a esta red". Solo responden preguntas nombre a nombre.

Esas son exactamente las preguntas que responden los archivos masivos de dominios, porque un archivo es una población, no una consulta.

¿Trabajas con datos de dominios a escala?
El formato de descarga depende del paquete y se indica en la página del producto.
Explorar el catálogo → | Ver precios →

Qué contienen los archivos masivos de dominios

El catálogo de WebTrackly se organiza en tres grupos:

• Archivos de zona por TLD — 716 paquetes que cubren .com, .net, .de, .org y cientos más. Solo el paquete de .com contiene 163.422.083 dominios. Consulta Archivos de zona por TLD.
• Listas de tecnologías y CMS — 79 paquetes de dominios agrupados por la plataforma detectada en ellos. El paquete de WordPress contiene 21.639.326 dominios. Consulta Domain Data.
• Datasets curados — 27 paquetes, incluido el dataset de todos los dominios registrados, con 272.614.863 filas. Consulta Datasets.

El formato de descarga depende del paquete y se indica en la página del producto. El fichero se genera en el momento de la compra, así que refleja el estado de los datos de origen en esa fecha y no una instantánea cacheada de un rastreo anterior. Los precios arrancan en $3.50 por paquete; consulta Precios para ver los planes de suscripción.

Campos que puedes esperar

Las columnas varían según el tipo de paquete: un archivo de zona es estrecho, mientras que una lista de tecnologías incluye los campos de detección y de resolución. La tabla siguiente muestra la forma de los datos, no una promesa de que cada columna aparezca en cada paquete.

Lo que no hay en los archivos: nombres de personas, direcciones de correo electrónico, números de teléfono, firmográficos de empresa ni señales de intención de compra. WebTrackly vende datos de dominios. Todo lo relativo a las personas que hay detrás de un dominio queda fuera de alcance, tanto por decisión de producto como por cumplimiento normativo.

Comprar y procesar un paquete

El flujo es deliberadamente corto: no hay ningún generador de consultas que aprender, porque el análisis ocurre en tu máquina y con tus propias herramientas.

1. Localiza el paquete. Explora el catálogo o ve directamente a /zones/ para archivos de zona por TLD, a /domaindata/ para listas de tecnologías o a /datasets/ para datasets curados. Cada ficha muestra el número de filas, así que conoces el tamaño antes de comprar.
2. Compra. Las compras puntuales arrancan en $3.50. Las suscripciones (Pro por $29/mes, Enterprise por $99/mes) incluyen una cuota mensual de paquetes y datasets más cuota de API; los detalles están en la página de precios.
3. Descarga. El ZIP se produce bajo demanda y queda disponible inmediatamente después del pago.
4. Procesa en local. Descomprime y trabaja el CSV con lo que ya utilices.

Para un fichero de varios cientos de millones de filas, las herramientas de línea de comandos y un motor columnar superarán a una hoja de cálculo por un margen enorme:

unzip com-zone.zip
wc -l com-zone.csv

# filter rows by name server with plain grep
grep -i 'cloudflare' com-zone.csv > cloudflare-hosted.csv

# or query the CSV directly with DuckDB, no import step
duckdb -c "SELECT ns, count(*) AS n FROM 'com-zone.csv' GROUP BY ns ORDER BY n DESC LIMIT 20"

Para análisis repetidos, carga el archivo una vez en PostgreSQL o ClickHouse con una copia masiva e indexa las columnas por las que filtras. Cruzar dos paquetes —por ejemplo, una lista de tecnologías contra un archivo de zona— es un simple join por la columna del dominio.

Automatizar con la API de catálogo

Los planes de suscripción incluyen acceso a la API para explorar el catálogo y obtener metadatos de los paquetes de forma programática. Pro incluye 30.000 llamadas al mes; Enterprise, 300.000. La API es una interfaz de catálogo: lista y describe paquetes y datasets. No es un servicio de consulta por dominio.

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=zone"

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=technology&q=wordpress"

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/com-zone/"

La referencia completa de endpoints, incluidos los de datasets y cuenta, está en la página de documentación de la API.

Errores habituales al adquirir datos de dominios & cómo evitarlos

Trabajar con datos de whois vs rdap icann a escala real saca a la luz siempre el mismo puñado de errores. Estos son los que conviene evitar.

1. Tratar WHOIS o RDAP como fuente masiva

   • Qué sale mal: escribir un script que recorra una lista de un millón de dominios y consulte cada uno por WHOIS o RDAP.
   • Por qué sale mal: ambos protocolos limitan la tasa por fuente y ningún operador de registro admite ese patrón. Te aplicarán throttling en cuestión de minutos y la ejecución tardará más de lo que los datos siguen siendo válidos.
   • La solución: parte de un archivo masivo que ya contenga la población y reserva las consultas nombre a nombre para el pequeño subconjunto en el que necesites el registro actual.

2. Esperar datos de contacto de los registros de registración

   • Qué sale mal: planificar un flujo de prospección alrededor de los correos electrónicos de los titulares.
   • Por qué sale mal: esos campos están redactados o sustituidos por un proxy en la mayoría de dominios desde 2018. El plan fracasa por los datos, no por la ejecución.
   • La solución: usa los datos de dominios para lo que son —un mapa de nombres, infraestructura y tecnología— y obtén los datos de contacto por canales donde el consentimiento y la procedencia estén documentados.

3. Construir un parser por registrador y llamarlo pipeline

   • Qué sale mal: un parseo de WHOIS basado en regex que funciona con los registradores que probaste y destroza en silencio el resto.
   • Por qué sale mal: WHOIS no tiene esquema. Las etiquetas de campo, los formatos de fecha y el orden de las secciones varían, y cambian sin previo aviso.
   • La solución: usa RDAP siempre que el operador de registro lo soporte, porque su esquema JSON es estable. Y cuando necesites un TLD entero, recurre al archivo de zona en lugar de reconstruirlo nombre a nombre.

4. Ignorar la rapidez con la que envejecen los datos

   • Qué sale mal: reutilizar el archivo del año pasado para el análisis de este año.
   • Por qué sale mal: los dominios expiran, migran de hosting, cambian de CMS y se colocan detrás de CDNs continuamente. Las conclusiones extraídas de una población obsoleta describen una web que ya no existe.
   • La solución: vuelve a descargar cuando el análisis importe. WebTrackly genera el archivo en el momento de la compra, así que una descarga nueva es un extracto nuevo y no una copia cacheada.

5. Subestimar el coste de construir la capa de recolección

   • Qué sale mal: decidir rastrear y hacer fingerprinting de la web en casa porque cada paso por separado parece sencillo.
   • Por qué sale mal: la resolución a escala, la lógica de reintentos, el mantenimiento de las huellas, el almacenamiento y la planificación de re-rastreos son un compromiso de ingeniería permanente, no un sprint.
   • La solución: compra el archivo de población para los casos en los que necesites cobertura y construye en casa solo donde tus requisitos se separen de verdad de lo que ya existe listo para usar.

6. Cargar cientos de millones de filas en la herramienta equivocada

   • Qué sale mal: abrir un CSV de varios gigabytes en una hoja de cálculo, o recorrerlo fila a fila desde un lenguaje de scripting.
   • Por qué sale mal: aquí hablamos de cientos de millones de filas. Las herramientas que lo mantienen todo en memoria no llegarán a terminar.
   • La solución: procésalo en streaming. Los filtros de línea de comandos, DuckDB directamente sobre el CSV o una carga masiva en un almacén columnar gestionan este tamaño sin dificultad.

7. Saltarse la revisión legal de lo que has recopilado

   • Qué sale mal: dar por hecho que, si un dato es accesible públicamente, cualquier uso está permitido.
   • Por qué sale mal: el GDPR, la CCPA y los términos de uso de los operadores de registro limitan cómo pueden tratarse y republicarse los datos de registración, con independencia de cómo se obtuvieran.
   • La solución: mantén los datos personales completamente fuera del pipeline. Los nombres de dominio, los registros DNS, las IP y las huellas tecnológicas no identifican a personas; los datos del titular sí.

Preguntas frecuentes (FAQ)

P: ¿Cuál es la diferencia práctica entre WHOIS y RDAP?
R: WHOIS devuelve texto sin estructura por el puerto 43 y exige un parser propio para cada registrador. RDAP devuelve JSON sobre HTTPS con un esquema definido, admite autenticación, usa códigos de error HTTP estándar y puede derivar al cliente al servidor autoritativo. Para uso programático, RDAP es claramente más cómodo. Ambos están sujetos a la misma redacción por privacidad y a los mismos límites de tasa.

P: ¿Puedo obtener correos o teléfonos de los titulares con alguno de los dos protocolos?
R: En la mayoría de dominios, no. Desde que el GDPR entró en vigor en 2018, ICANN obliga a los registradores a redactar los datos personales de las respuestas públicas de WHOIS y RDAP. Existen vías de acceso acreditado para partes concretas, como las fuerzas del orden. WebTrackly no vende datos de contacto de ningún tipo.

P: ¿WebTrackly ofrece búsqueda para un dominio individual?
R: No. El producto son archivos masivos. El formato de descarga depende del paquete y se indica en la página del producto. No hay interfaz de búsqueda por dominio.

P: ¿En qué formato están las descargas y cómo de recientes son?
R: El formato de descarga depende del paquete y se indica en la página del producto. El fichero se genera en el momento de la compra, no se sirve desde una instantánea preconstruida.

P: ¿Cómo de grande es el catálogo?
R: 1.538 paquetes: 716 archivos de zona por TLD, 79 listas de tecnologías y CMS, y 27 datasets curados. Para hacerse una idea de la escala: el paquete de la zona .com contiene 163.422.083 dominios, el de WordPress 21.639.326 y el dataset de todos los dominios registrados 272.614.863 filas.

P: ¿Cuánto cuesta?
R: Las compras puntuales de paquetes arrancan en $3.50. Pro cuesta $29/mes e incluye 50 paquetes, 10 datasets y 30.000 llamadas a la API. Enterprise cuesta $99/mes con 200 paquetes, 50 datasets y 300.000 llamadas a la API. Los detalles actualizados están en la página de precios.

P: ¿Hay API?
R: Sí, para el catálogo. La API lista paquetes y datasets y devuelve sus metadatos, con autenticación mediante bearer token. Consulta la documentación de la API. No realiza consultas de dominios.

P: ¿Cómo debería procesar un archivo con cientos de millones de filas?
R: En streaming, no cargándolo entero. Las herramientas estándar de línea de comandos sirven para filtrar y contar; DuckDB consulta un CSV en su sitio, sin paso de importación; y para análisis repetidos, haz una carga masiva en PostgreSQL o ClickHouse e indexa las columnas por las que filtras.

Conclusión

WHOIS y RDAP hacen aquello para lo que se diseñaron: te dicen qué guarda un operador de registro sobre un nombre. RDAP lo hace con esquema, sobre HTTPS y con una gestión de errores real —una mejora genuina, y vale la pena migrar cualquier código que consulte datos de registración—. Lo que ninguno de los dos hará jamás es entregarte una población. Son consultas, limitadas por diseño, despojadas de datos personales por regulación y mudas sobre todo lo que ocurre después de la resolución.

Cuando la pregunta va de un TLD entero, de una plataforma entera o de un segmento entero de la web, el insumo correcto es un archivo. Eso es lo que publica WebTrackly: archivos de zona, listas de tecnologías y datasets curados, en CSV, generados en el momento de la compra, para que los analices con tus propias herramientas.

Empieza por el catálogo.
El formato de descarga depende del paquete y se indica en la página del producto.
Explorar paquetes → | Ver precios →

Recursos relacionados

• Catálogo de paquetes — 1.538 bases de datos de dominios descargables
• Archivos de zona por TLD — .com, .net, .de y más de 700 más
• Domain Data — listas de dominios por CMS y tecnología
• Datasets curados — todos los dominios registrados, servidores MX, e-commerce
• Precios — compras puntuales desde $3.50