RDAP de ICANN explicado: el reemplazo de WHOIS (guía 2026)

WHOIS nunca se diseñó para el consumo automatizado y, tras dos décadas de formatos de salida propios de cada registrador y una década de redacción motivada por la privacidad, ha dejado de servir como fuente de datos. El Registration Data Access Protocol (RDAP) de ICANN es el sustituto estandarizado: los mismos datos de registro, entregados como JSON sobre HTTPS con un esquema coherente. Esta guía explica qué es RDAP, qué contienen realmente sus respuestas en 2026 (mucho menos de lo que se supone), en qué se diferencia de WHOIS a nivel de protocolo y cómo trabajar con datos de dominios a escala cuando las consultas dominio a dominio no resultan prácticas.

Puntos clave

• WHOIS está en retirada: el protocolo devuelve texto libre sin estructura garantizada, cambia de un registrador a otro y carece de autenticación, gestión de errores e internacionalización estándar.
• RDAP es el sustituto exigido por ICANN: definido en los RFC 7480-7484, devuelve JSON sobre HTTPS con un modelo de objetos documentado, códigos de estado HTTP estándar y un registro de arranque (bootstrap) para localizar el servidor correcto.
• La estructura es la verdadera ganancia: el registrador, las fechas de creación y expiración, los servidores de nombres, los códigos de estado y los eventos llegan como campos con nombre en lugar de texto que hay que reconocer con expresiones regulares.
• Los datos de contacto han desaparecido casi por completo: las respuestas RDAP de los gTLD se redactan por defecto. Los nombres, correos y teléfonos de los titulares no se pueden obtener a escala mediante RDAP, y ninguna herramienta legítima cambia eso.
• La consulta dominio a dominio no escala: los servidores RDAP aplican límites de frecuencia. Las preguntas de alcance poblacional (“cuántos dominios de .de usan WordPress”) requieren archivos a granel, no consultas.
• Los archivos a granel responden a otras preguntas: los archivos de zona y los conjuntos de datos enriquecidos por zona ofrecen dominio, servidores de nombres, MX, IP y CMS detectado en TLD completos, que es la entrada adecuada para dimensionar mercados, investigar infraestructura y construir conjuntos de datos.

Índice

1. RDAP de ICANN: la base moderna para los datos de dominios y por qué WHOIS está obsoleto
2. Lo que RDAP no ofrece: redacción, límites de frecuencia y escala
3. Dónde resultan útiles de verdad los datos a nivel de dominio
4. Qué ofrece WebTrackly: paquetes de datos de dominios a granel
5. Esquema de datos: qué hay dentro del CSV
6. Cómo usar la API del catálogo
7. Procesar los archivos en local
8. Errores habituales al trabajar con datos RDAP
9. Preguntas frecuentes
10. Conclusión

RDAP de ICANN: la base moderna para los datos de dominios y por qué WHOIS está obsoleto

Internet funciona sobre dominios, y saber quién los posee, quién los gestiona y cuándo se registraron resulta fundamental para un enorme abanico de actividades en línea, desde la generación de oportunidades B2B hasta las investigaciones de ciberseguridad. Durante décadas, la herramienta principal para ello fue WHOIS. Sin embargo, el protocolo WHOIS tradicional, diseñado en los primeros tiempos de la red, se ha convertido en una reliquia cada vez menos adecuada para las exigencias de la web moderna. Su salida en texto libre e inconsistente, unida a normativas de privacidad en evolución como el RGPD, lo ha vuelto notoriamente difícil de analizar de forma programática y a menudo incompleto para usos empresariales legítimos. Precisamente por eso, el panorama de RDAP de ICANN como sustituto de WHOIS no es solo una mejora, sino una necesidad para cualquiera que se tome en serio la inteligencia sobre dominios.

RDAP, o Registration Data Access Protocol, nació en el seno del Internet Engineering Task Force (IETF) y de ICANN como la solución estandarizada de nueva generación. A diferencia de WHOIS, que a menudo exige que una persona interprete formatos de salida distintos procedentes de cientos de registradores, RDAP entrega datos estructurados y legibles por máquina, normalmente en formato JSON. Una consulta devuelve un objeto bien definido: el identificador del dominio, un array events con las marcas de tiempo de registro, expiración y última modificación, un array nameservers, un array status con valores estandarizados derivados de EPP y un array entities que describe al registrador y los contactos que el operador de registro decida publicar. Cada campo tiene nombre, tipo y un lugar en el esquema, que es exactamente lo que WHOIS nunca tuvo.

La escala es lo que hace que esto importe. Hay cientos de millones de nombres de dominio registrados en todo el mundo, y revisar manualmente los registros WHOIS de tan solo un millar de ellos resulta inviable. Automatizarlo con WHOIS implica escribir y mantener analizadores para cientos de formatos de salida únicos: una batalla permanente contra la inconsistencia y los cambios silenciosos de formato. La normativa de privacidad agravó el problema: tras la entrada en vigor del RGPD, los registradores empezaron a redactar o enmascarar por sistema los campos de contacto del titular en la salida WHOIS, y esa misma redacción se traslada a RDAP. La consecuencia práctica es que WHOIS perdió casi todo el valor que le quedaba como fuente de contactos, mientras que sus problemas de análisis siguieron exactamente igual.

RDAP aborda estos retos de forma directa. Proporciona un mecanismo coherente de consulta y respuesta, con una estructura estandarizada para los datos de registro de dominios sea cual sea el registrador o el dominio de primer nivel (TLD). Esto incluye información sobre el dominio, su registrador, las fechas de creación y expiración, los servidores de nombres y, a menudo, información de contacto más estructurada (cuando la ley lo permite) o al menos identificadores organizativos. Por ejemplo, en lugar de intentar extraer un “correo del titular” de un bloque de texto que podría estar etiquetado como “Admin Contact”, “Registrant Email” o “Contact Email”, RDAP ofrece campos JSON diferenciados para esos atributos, lo que hace que la extracción de datos sea precisa y fiable.

Piense en un escenario real: una empresa SaaS B2B especializada en seguridad web quiere identificar clientes potenciales que operan entornos de alojamiento antiguos y menos seguros. Con WHOIS tradicional tendría que extraer miles de registros, identificar manualmente a los proveedores de alojamiento a partir de las entradas de servidores de nombres (a menudo poco claras) y después intentar encontrar algún dato de contacto, lidiando con la redacción en todo momento. El proceso es lento, propenso a errores y produce oportunidades de baja calidad.

RDAP resuelve el problema del formato, y solo el problema del formato. Ofrece metadatos técnicos fiables y comparables: qué registrador patrocina un dominio, cuándo se creó y cuándo expira, a qué servidores de nombres delega y qué códigos de estado administrativos se le aplican. Eso resulta realmente útil para el análisis de infraestructura, para seguir la cuota de mercado de registradores y proveedores de DNS y para detectar dominios cuyo patrón de registro o delegación resulta inusual. Lo que no hace es restaurar el directorio de titulares que existía antes de 2018. Cualquier flujo de trabajo que dé por supuesto que RDAP devolverá una persona de contacto parte de una premisa falsa y fracasará en la inmensa mayoría de los dominios gTLD.

El paso a RDAP es un estándar del sector, documentado en RFC como el 7480, 7481, 7482, 7483 y 7484. Estos definen el protocolo, la estructura de consultas y respuestas y las consideraciones de seguridad, garantizando una base sólida y preparada para el futuro en el acceso a los datos de dominios. Al adoptar RDAP, ICANN y la comunidad de internet avanzan hacia una forma más segura, eficiente y compatible con las máquinas de consultar y recibir datos de registro, algo esencial para mantener la estabilidad y la utilidad de la red. Para las empresas, esto significa pasar de un enfoque manual y lleno de conjeturas a una estrategia automatizada y basada en datos para identificar a su mercado objetivo y dirigirse a él. WebTrackly pone esta capacidad directamente en sus manos y convierte los datos RDAP en bruto en información accionable para sus equipos de ventas, marketing y datos.

Lo que RDAP no ofrece: redacción, límites de frecuencia y escala

Conviene ser explícito sobre los límites del protocolo, porque buena parte del material publicado sobre RDAP los exagera de forma discreta.

• Los datos de contacto del titular se redactan por defecto. Según la política de datos de registro de ICANN, las respuestas RDAP de los gTLD omiten o enmascaran los datos de contacto administrativos, técnicos y del titular para el público general. Una respuesta típica contiene una entidad registrador con un contacto de abuso y una entidad titular cuyos campos vCard se eliminan o se sustituyen por una dirección de proxy. No existe ningún nivel público que devuelva los valores subyacentes, y solicitarlos exige una petición de divulgación acreditada y limitada a una finalidad, tramitada caso por caso.
• La cobertura es desigual entre TLD. RDAP es obligatorio para los gTLD. Muchos operadores de ccTLD lo ofrecen de forma voluntaria, algunos con menos campos, y unos pocos solo mantienen WHOIS o un formulario web. El registro de arranque de IANA le indica qué servidor es autoritativo para un TLD determinado, pero no puede decirle qué decidirá publicar ese servidor.
• Los límites de frecuencia hacen imposible la consulta masiva. Los puntos de acceso RDAP de operadores de registro y registradores están protegidos frente a la recolección automatizada. Las consultas secuenciales medidas en millones de dominios no son un uso admitido del protocolo, e intentarlo provoca limitaciones o bloqueos. Es una decisión de diseño, no un obstáculo que haya que sortear con ingenio.
• Las respuestas describen el registro, no el sitio web. RDAP no sabe nada sobre qué CMS usa un sitio, qué CDN tiene delante o si siquiera resuelve. Esa información procede de la observación de DNS y HTTP, que es un problema de recopilación de datos distinto.

Estos límites determinan qué preguntas puede responder con una consulta y cuáles exigen un conjunto de datos a granel. Preguntar “cuál es el registrador y la fecha de expiración de este dominio concreto” es una consulta. Preguntar “cuántos dominios de esta zona delegan en servidores de nombres de Cloudflare” es una pregunta de conjunto de datos, y ninguna cantidad de consultas la convertirá en una consulta puntual.

Dónde resultan útiles de verdad los datos a nivel de dominio

Los datos estructurados de registro e infraestructura sustentan un conjunto de casos de uso más reducido, pero más defendible, del que suele sugerir el marketing en torno a la inteligencia sobre dominios. Los tres siguientes funcionan con lo que está realmente disponible: metadatos técnicos sobre dominios, no información sobre las personas que hay detrás.

Superficie de ataque e investigación de infraestructura

Público objetivo: proveedores de servicios de ciberseguridad, empresas de pruebas de penetración, equipos de respuesta a incidentes, analistas de inteligencia de amenazas.

Problema: identificar organizaciones que operan infraestructura potencialmente vulnerable o desactualizada es un proceso manual y lento. Los datos WHOIS tradicionales son demasiado inconsistentes y a menudo están redactados como para relacionar de forma eficaz los dominios con su pila tecnológica subyacente o con patrones de registrador que puedan indicar riesgo. Las superficies de ataque son enormes, y detectar de forma proactiva objetivos con configuraciones concretas y explotables resulta crítico pero difícil.

Qué permiten los datos: los archivos a nivel de zona permiten a un equipo de seguridad enumerar los dominios de un TLD, resolver su delegación y su infraestructura de correo y cruzar las plataformas CMS detectadas con versiones vulnerables conocidas. Trabajar a partir de una zona completa en lugar de una lista muestreada significa que el denominador es real: puede afirmar cuántos dominios de una zona usan un operador de servidores de nombres o un proveedor de correo concretos, en lugar de cuántos aparecieron en la muestra que haya conseguido recopilar. RDAP completa después los metadatos de registro dominio a dominio para la lista corta que salga de ese análisis, un volumen que el protocolo puede atender sin problemas.

Qué no permiten los datos: no le dirán con quién contactar dentro de esas organizaciones. Elaborar una lista de contactos es un ejercicio aparte que debe basarse en la información que esas organizaciones publican sobre sí mismas, y no es algo que proporcione un conjunto de datos de dominios.

Dimensionamiento de mercado para fundadores SaaS y equipos de producto

Público objetivo: fundadores SaaS, responsables de producto, investigadores de mercado, capital riesgo.

Problema: validar la idea de un nuevo producto SaaS exige un conocimiento profundo del mercado: quiénes son los clientes potenciales, qué tecnologías usan hoy y cuál es el tamaño del mercado abordable. Basarse en pruebas anecdóticas o en informes sectoriales genéricos no basta. Los fundadores necesitan datos granulares sobre adopción tecnológica e infraestructura subyacente.

Qué permiten los datos: contar. Si su producto se dirige a sitios WordPress, el tamaño de la población abordable es una cantidad contable, no una estimación: en las zonas cubiertas aquí, 21.639.326 dominios se detectan como WordPress y 567.680 como Joomla. Si su producto es específico de una región, los archivos por zona le permiten acotar el recuento a los TLD que importan. Comparar recuentos entre zonas o entre instantáneas tomadas en momentos distintos muestra dónde gana o pierde terreno una plataforma, lo que constituye una base mucho más sólida para un plan de negocio que el gráfico de cuota de mercado publicado por un proveedor.

Cómo hacerlo: tome el conjunto enriquecido de las zonas que le interesen, cuente filas por CMS detectado y por operador de servidores de nombres, y repita con una instantánea posterior cuando quiera una tendencia en lugar de una foto fija.

Construcción de conjuntos de datos para análisis y aprendizaje automático

Público objetivo: científicos de datos, ingenieros de datos, investigadores, analistas de inteligencia de negocio.

Problema: construir conjuntos de datos completos para análisis a gran escala, modelos de aprendizaje automático o previsión de tendencias se ve lastrado por fuentes de datos inconsistentes. Los datos WHOIS tradicionales carecen de estructura, requieren una limpieza y un análisis exhaustivos y a menudo no tienen la coherencia necesaria para canalizaciones de datos robustas. Integrar datos dispares procedentes de diversas fuentes web es complejo y lleva mucho tiempo.

Qué permiten los datos: un punto de partida estable y columnar. Cada archivo enriquecido por zona es un CSV con una fila por dominio y un conjunto fijo de columnas, que se carga directamente en pandas, DuckDB, ClickHouse o un almacén de datos sin fase de análisis previo. Dominio, servidores de nombres, MX, IP y CMS detectado son todos utilizables como variables: la concentración de proveedores de alojamiento y correo, los patrones de delegación y la elección de plataforma son señales informativas para tareas de clasificación como separar dominios aparcados de sitios activos o agrupar dominios por operador de infraestructura. Cuando un operador de registro publica las fechas de registro, estas se incluyen y aportan al conjunto de datos una dimensión temporal.

Salvedades que conviene incorporar: la detección es observacional y llegará con retraso en sitios que hayan cambiado hace poco; un dominio presente en un archivo de zona está registrado, pero no necesariamente sirve contenido; y la ausencia de un registro MX significa que no hay correo configurado para ese nombre, no que la organización no tenga correo.

Qué ofrece WebTrackly: paquetes de datos de dominios a granel

WebTrackly es un catálogo de datos de dominios descargables, no una interfaz de búsqueda ni una base de datos de contactos. El catálogo contiene 1.538 paquetes, organizados en cuatro grupos.

La cobertura en esas zonas es de 285.582.781 dominios. La zona individual más grande es .com, con 163.422.083 dominios. En el plano tecnológico, 21.639.326 dominios se detectan como WordPress y 567.680 como Joomla. El conjunto de datos seleccionado más grande, todos los dominios registrados, contiene 272.614.863 filas.

La entrega es deliberadamente sencilla. El formato de descarga depende del paquete y se indica en la página del producto. Las compras puntuales parten de $3.50. Hay dos planes de suscripción disponibles para un uso continuado: Pro, a $29/mes, incluye 50 paquetes más 10 conjuntos de datos y 30.000 llamadas a la API; Enterprise, a $99/mes, incluye 200 paquetes más 50 conjuntos de datos y 300.000 llamadas a la API.

El catálogo se puede explorar en /packages/, con los archivos de zona listados en /zones/, las listas por tecnología en /domaindata/ y las recopilaciones entre zonas en /datasets/. Los detalles de los planes están en /pricing/.

Esquema de datos: qué hay dentro del CSV

Un paquete enriquecido por zona se descomprime en un CSV con una fila por dominio y las siguientes columnas.

Los paquetes de archivo de zona simple contienen únicamente la columna de dominio. Las listas por tecnología contienen los dominios en los que se detectó una plataforma determinada.

Es igual de importante dejar claro qué no contienen los archivos:

• Ningún contacto personal de ningún tipo. Ni nombres, ni direcciones de correo, ni números de teléfono, ni perfiles sociales.
• Ningún dato de identidad del titular. La fecha de registro es un metadato publicado por el operador de registro; el titular que hay detrás de un dominio no forma parte de estos archivos.
• Ninguna señal de intención, firmográfica o de tamaño de empresa.
• Ninguna estimación de tráfico, posicionamiento o facturación.

Si lo que necesita es una lista de personas a las que contactar, estos conjuntos de datos son la entrada equivocada, y ningún filtro ni opción de exportación cambiará eso.

Cómo usar la API del catálogo

La API sirve el catálogo: permite descubrir qué paquetes existen, inspeccionar sus metadatos y automatizar la compra y la descarga. No es un punto de acceso de consulta dominio a dominio, y no existe ninguna interfaz de consulta que devuelva registros de dominios individuales. Cada petición lleva un token bearer.

Listar los paquetes de archivos de zona:

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

Buscar entre los paquetes por tecnología:

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

Obtener el registro detallado de un paquete concreto, incluidos su número de filas y su precio actual:

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

Un patrón de automatización habitual consiste en sondear el catálogo en busca de los paquetes de los que depende su canalización, comparar los recuentos de filas notificados con los de su última ingesta y lanzar una nueva descarga cuando una zona haya crecido o menguado de forma significativa. Las asignaciones de llamadas a la API son de 30.000 al mes en Pro y 300.000 al mes en Enterprise, cifras de sobra suficientes para el sondeo del catálogo y muy por encima de lo que necesita una canalización programada. La documentación completa de los puntos de acceso está en /api/.

Procesar los archivos en local

El formato de descarga depende del paquete y se indica en la página del producto. Como los archivos son CSV planos, las herramientas de línea de comandos habituales bastan para la primera pasada y un motor columnar se encarga de todo lo demás.

Descomprima y observe la forma de los datos:

unzip com-enriched.zip
head -3 com-enriched.csv
wc -l com-enriched.csv

Para un archivo de una sola zona, grep y awk suelen ser suficientes:

# domains delegating to Cloudflare name servers
grep -i 'ns.cloudflare.com' com-enriched.csv | wc -l

# domains with Google Workspace mail
grep -i 'aspmx.l.google.com' com-enriched.csv | wc -l

Para cualquier trabajo analítico, cargue el CSV en DuckDB. Lee el archivo en su sitio, así que no hay fase de importación:

duckdb -c "
  SELECT cms, count(*) AS domains
  FROM read_csv_auto('com-enriched.csv')
  WHERE cms IS NOT NULL
  GROUP BY cms
  ORDER BY domains DESC
  LIMIT 20;
"

Para consultas repetidas sobre muchas zonas a la vez, ClickHouse encaja mejor. Cree una tabla con las seis columnas, cargue los CSV y las agregaciones sobre cientos de millones de filas se ejecutarán en segundos:

clickhouse-client --query "
  CREATE TABLE domains (
    domain String, reg_date Nullable(Date),
    ns String, mx String, ip String, cms String
  ) ENGINE = MergeTree ORDER BY domain"

clickhouse-client --query "INSERT INTO domains FORMAT CSVWithNames" < com-enriched.csv

Una nota sobre la escala: el conjunto de datos de todos los dominios registrados tiene 272.614.863 filas, así que cuente con decenas de gigabytes sin comprimir y use un almacén columnar en lugar de una hoja de cálculo. Los archivos de zona individuales son mucho más pequeños y la mayoría se abren sin problemas en DuckDB en un portátil.

Errores habituales al trabajar con datos RDAP

RDAP es sencillo de consultar y fácil de malinterpretar. Estos son los errores que con más frecuencia llevan a conclusiones engañosas.

1. Error: depender en exceso de los datos de contacto directos del RDAP en bruto.

   • Qué sale mal: muchos usuarios esperan que RDAP proporcione direcciones de correo y números de teléfono de los titulares sin redactar. Debido a normativas de privacidad (como el RGPD) y a las políticas de los registradores, buena parte de esa información suele estar redactada, sustituida por un proxy (p. ej., [email protected]) o simplemente no disponible directamente a través de RDAP. Basarse solo en el RDAP en bruto para obtener contactos producirá listas de oportunidades vacías o de calidad pésima.
   • Por qué: la Especificación Temporal de ICANN para los datos de registro de gTLD y diversas leyes nacionales de privacidad obligan a proteger los datos personales. Los registradores cumplen redactando o enmascarando los datos de contacto.
   • La solución: trate RDAP como una fuente de metadatos técnicos y nada más. El registrador, las fechas, los servidores de nombres y los códigos de estado son fiables; los campos de contacto no. Si su proyecto necesita llegar a organizaciones, eso debe partir de la información que esas organizaciones publican por su cuenta, recopilada bajo la base legal que corresponda a su jurisdicción y a su caso de uso. Ningún producto de datos de dominios, incluido este, proporciona contactos de titulares, y cualquier proveedor que afirme extraerlos de RDAP está describiendo algo que el protocolo no hace.

2. Error: ignorar los matices de los códigos de estado de RDAP.

   • Qué sale mal: RDAP proporciona códigos de estado detallados (p. ej., clientDeleteProhibited, serverHold, pendingDelete). Malinterpretarlos puede llevar a dirigirse a dominios que no están activos, están en disputa o están a punto de expirar. Por ejemplo, dirigir una propuesta comercial a un dominio en pendingDelete es tiempo perdido.
   • Por qué: estos códigos indican el estado administrativo actual de un dominio. Son fundamentales para entender su disponibilidad y su estabilidad.
   • La solución: aprenda el vocabulario de estados EPP que RDAP reutiliza. clientTransferProhibited es un bloqueo normal y no dice nada negativo sobre un dominio; serverHold significa que el dominio no se está publicando en el DNS; pendingDelete significa que está en el ciclo de borrado y caducará en breve; redemptionPeriod significa que ya ha expirado y su titular todavía puede recuperarlo. Decida de forma explícita qué estados incluye su análisis y deje constancia de esa decisión junto a los resultados para que las cifras se puedan reproducir.

3. Error: dar por hecho que la frescura de los datos es universal e instantánea.

   • Qué sale mal: creer que todos los datos RDAP son en tiempo real y se actualizan de forma simultánea en todos los registradores. Aunque RDAP está pensado para el acceso programático, los registradores tienen ciclos de actualización distintos y pueden producirse retrasos de propagación.
   • Por qué: los datos de registro de dominios circulan por varias partes (titular, registrador, operador de registro). Las actualizaciones no siempre son instantáneas en todo el ecosistema.
   • La solución: trate cada conjunto de datos y cada consulta como una instantánea con marca de tiempo, y guarde esa marca junto a los datos. Los archivos a granel reflejan el estado de una zona en el momento en que se generó la exportación; RDAP refleja el estado de un dominio en el momento de la consulta. Ninguno de los dos es un flujo en vivo. Para el trabajo de tendencias esto es una ventaja más que una limitación, ya que comparar instantáneas fechadas es precisamente lo que hace medible una tendencia.

4. Error: descuidar los límites de frecuencia y las políticas de uso razonable.

   • Qué sale mal: consultar de forma agresiva los servidores RDAP, directamente o a través de la API de una plataforma, sin tener en cuenta los límites de frecuencia puede provocar bloqueos de IP, bloqueos temporales o degradación del servicio. Esto es especialmente cierto si se intenta raspar RDAP en bruto.
   • Por qué: los servidores RDAP, como cualquier API pública, están protegidos frente al abuso. Incluso la API de WebTrackly tiene límites de frecuencia para garantizar un uso justo para todos los clientes.
   • La solución: no intente enumeraciones masivas mediante RDAP. Reserve las consultas para los casos en los que necesite información actual y autoritativa sobre un dominio concreto, implemente retroceso exponencial y respete las cabeceras Retry-After cuando lo haga, y use archivos a granel para todo lo que tenga escala poblacional. Intentar reconstruir una zona mediante consultas dominio a dominio es a la vez más lento y menos completo que descargar la zona.

5. Error: confundir “registrador” con “proveedor de alojamiento”.

   • Qué sale mal: confundir la entidad que registró el dominio (el registrador, que aparece en RDAP) con la entidad que aloja el contenido del sitio web (el proveedor de alojamiento, que se descubre mediante consultas de DNS/IP). Un dominio registrado en GoDaddy puede estar alojado en AWS, y viceversa.
   • Por qué: son servicios distintos. Un registrador gestiona el nombre de dominio en sí, mientras que un proveedor de alojamiento sirve los archivos del sitio web.
   • La solución: mantenga los dos atributos en columnas separadas y no deduzca nunca uno a partir del otro. El registrador procede de RDAP. Los proveedores de alojamiento y de correo se deducen de las columnas de servidores de nombres, MX e IP de un archivo a granel. Un archivo de zona le mostrará, por ejemplo, que un dominio delega en servidores de nombres de Cloudflare mientras su registro A apunta a un proveedor completamente distinto, que es justo el tipo de distinción que se pierde cuando ambos conceptos se mezclan.

6. Error: ignorar el cumplimiento legal y ético (RGPD, CCPA, uso aceptable).

   • Qué sale mal: usar los datos extraídos, en especial los de contacto, sin atender a las normativas de privacidad ni a las políticas de uso aceptable de los proveedores de datos. Esto puede acarrear sanciones legales, daño reputacional y cancelación de la cuenta.
   • Por qué: las leyes de protección de datos son estrictas. Aunque los datos sean públicos, su recopilación y uso deben cumplir normativas como el RGPD y la CCPA.
   • La solución: conozca qué régimen legal se aplica a los datos que maneja. El dominio, los servidores de nombres, MX, IP y el CMS detectado son atributos técnicos de infraestructura, no datos personales sobre individuos identificables, y por eso los archivos de dominios a granel resultan comparativamente sencillos de manejar. En cuanto los combina con información sobre personas, está tratando datos personales y se le aplica todo el peso del RGPD, la CCPA y regímenes equivalentes. Mantenga esa frontera visible en su propia canalización en lugar de descubrirla durante una auditoría.

Evitar estos errores mantiene defendible cualquier análisis basado en RDAP: correcto sobre lo que el protocolo informa, explícito sobre lo que omite y honesto acerca de la diferencia entre una instantánea y una vista en vivo.

Preguntas frecuentes

P: ¿Qué es exactamente RDAP y en qué se diferencia de WHOIS?
R: RDAP (Registration Data Access Protocol) es el sustituto moderno y estandarizado del anticuado protocolo WHOIS. La diferencia clave es que RDAP entrega datos estructurados y legibles por máquina (normalmente en formato JSON), mientras que WHOIS devuelve información en texto libre e inconsistente que varía mucho según el registrador. Ese formato estructurado hace que los datos RDAP sean mucho más fáciles de analizar, estudiar e integrar en sistemas automatizados. RDAP ofrece además funciones de seguridad mejoradas y soporte de internacionalización, lo que lo hace superior para el acceso programático y la inteligencia global sobre dominios.

P: ¿Puedo obtener nombres, correos o teléfonos de los titulares mediante RDAP?
R: No, no a ninguna escala útil. Las respuestas RDAP de los gTLD se redactan por defecto según la política de ICANN, y la mayoría de los operadores de registro devuelven un proxy o un valor vacío en los campos de contacto del titular. La divulgación existe únicamente como un proceso de petición acreditada y limitada a una finalidad, tramitada caso por caso. Los conjuntos de datos de WebTrackly tampoco contienen contactos personales: dominio, fecha de registro cuando se publica, servidores de nombres, MX, IP y CMS detectado es todo lo que incluyen los archivos.

P: ¿Ofrece WebTrackly consultas dominio a dominio o una interfaz de búsqueda?
R: No. El producto es un catálogo de paquetes descargables. El formato de descarga depende del paquete y se indica en la página del producto. No hay interfaz para consultar un dominio individual ni búsqueda filtrada sobre las filas subyacentes; el filtrado se hace de su lado, después de la descarga.

P: ¿Qué formatos y modos de entrega hay disponibles?
R: El formato de descarga depende del paquete y se indica en la página del producto. La exportación se genera en el momento de la compra, de modo que refleja el estado actual de los datos y no un archivo precompilado de antigüedad desconocida. La API devuelve los metadatos del catálogo en JSON.

P: ¿Qué tamaño tienen los conjuntos de datos?
R: La cobertura es de 285.582.781 dominios en 716 zonas. Solo la zona .com representa 163.422.083 dominios. El conjunto de datos de todos los dominios registrados contiene 272.614.863 filas. Las listas por tecnología son más pequeñas y específicas: 21.639.326 dominios para WordPress y 567.680 para Joomla.

P: ¿Qué hace la API del catálogo?
R: Expone el catálogo de paquetes. GET /api/v1/packages/?type=zone lista los paquetes de zona, GET /api/v1/packages/?type=technology&q=wordpress busca entre los paquetes por tecnología y GET /api/v1/packages/{slug}/ devuelve el registro detallado de un paquete. Las peticiones se autentican con una cabecera Authorization: Bearer YOUR_API_KEY. Las asignaciones son de 30.000 llamadas al mes en Pro y 300.000 en Enterprise.

P: ¿Cuánto cuesta?
R: Las compras puntuales de paquetes parten de $3.50. Para un uso continuado hay dos planes: Pro, a $29/mes, que incluye 50 paquetes más 10 conjuntos de datos y 30.000 llamadas a la API, y Enterprise, a $99/mes, que incluye 200 paquetes más 50 conjuntos de datos y 300.000 llamadas a la API. Los detalles están en la página de precios.

P: ¿Cómo debería cargar un archivo tan grande?
R: Descomprímalo y consúltelo con un motor columnar. DuckDB lee el CSV en su sitio y maneja un archivo de una sola zona sin problemas en un portátil; ClickHouse es la mejor opción cuando quiere agregaciones repetidas sobre muchas zonas o sobre la recopilación completa entre zonas. Las hojas de cálculo no son una opción realista con este número de filas.

Conclusión

El paso de WHOIS a RDAP es una mejora real, pero limitada. Resuelve el problema del formato: los metadatos de registro llegan ahora como JSON con un esquema documentado, semántica HTTP estándar y un registro de arranque que le indica dónde preguntar. No resuelve el problema del acceso, ni se pretendió nunca que lo hiciera. Los datos de contacto del titular se retiraron de los registros públicos por decisión normativa, y RDAP reproduce fielmente esa decisión.

Lo que esto significa en la práctica es que los datos de dominios son datos técnicos. El registrador, las fechas, los servidores de nombres, la configuración de correo, las direcciones resueltas y las plataformas detectadas son reales, comparables y están disponibles a escala. Las preguntas formuladas en esos términos se pueden responder con precisión. Las preguntas que presuponen un directorio de titulares no tienen respuesta posible, con ninguna herramienta.

Si su trabajo necesita respuestas de alcance poblacional sobre la infraestructura de dominios, los archivos a granel son la vía práctica: elija la zona, la lista por tecnología o la recopilación que necesita en el catálogo de paquetes, descargue el CSV y analícelo en local con herramientas que ya controla.

Recursos relacionados

• Catálogo de paquetes — más de 1.500 bases de datos de dominios descargables
• Archivos de zona por TLD — .com, .net, .de y más de 700 adicionales
• Conjuntos de datos seleccionados — todos los dominios registrados, servidores MX, comercio electrónico
• Precios — compras puntuales desde $3.50