"No Registry RDAP Server": cómo obtener igualmente datos de dominios

Tarde o temprano, todo proyecto de datos de dominios se topa con el mismo mensaje: "no registry rdap server was identified for this domain". No es un fallo de tu script. Significa que la herramienta no pudo encontrar un endpoint RDAP para ese TLD, y por muchos reintentos que hagas nada cambiará. Esta guía explica por qué aparece el error, a qué partes del espacio de nombres afecta y cómo construir un conjunto de datos utilizable a partir de archivos de zona y enriquecimiento en bloque, en lugar de consultas en vivo dominio por dominio.

RESUMEN / PUNTOS CLAVE

• El error es una laguna del protocolo, no un fallo de red: la adopción de RDAP es obligatoria para los gTLD, pero opcional para la mayoría de los ccTLD, de modo que una parte enorme del espacio de nombres sencillamente no tiene servidor RDAP al que consultar.
• Las consultas en vivo no escalan: los registros aplican límites de tasa muy estrictos, ocultan los campos del titular por el RGPD y responden de un dominio en un dominio. Ese modelo se rompe mucho antes de llegar al millón de dominios.
• Los archivos en bloque son la alternativa práctica: un archivo de zona enumera directamente los dominios registrados en un TLD, sin consultas por dominio y sin depender de RDAP.
• WebTrackly distribuye archivos en bloque, no un servicio de consultas: 1.538 paquetes — 716 archivos de zona por TLD, 716 conjuntos de zona enriquecidos (NS, MX, IP, CMS detectado), 79 listas de sitios por tecnología/CMS y 27 conjuntos de datos seleccionados.
• Volumen de cobertura: 285.582.781 dominios en los paquetes de zona, incluidos 163.422.083 en .com; el conjunto de datos de todos los dominios registrados suma 272.614.863 filas.
• Qué contienen los archivos: nombres de dominio, servidores de nombres, registros MX, IP resueltas y CMS detectado cuando está disponible. No incluyen datos personales de contacto: ni correos, ni teléfonos, ni nombres de titulares.
• La entrega es una descarga: El formato de descarga depende del paquete y se indica en la página del producto. El procesamiento ocurre en tu propia máquina, con las herramientas que ya usas.

ÍNDICE

1. Por qué aparece "No Registry RDAP Server"
2. Cinco cosas para las que sirven de verdad los datos de dominios en bloque
3. Cómo son los archivos y en qué se diferencian de las consultas en vivo
4. Trabajar con los datos: comprar, descargar, procesar en local
5. Errores habituales al obtener datos de dominios
6. Preguntas frecuentes
7. Conclusión
8. Recursos relacionados

Por qué aparece "No Registry RDAP Server"

RDAP (Registration Data Access Protocol) es el sucesor estructurado de WHOIS, basado en JSON. En lugar de analizar texto libre, el cliente resuelve el servidor autoritativo de un TLD y recibe una respuesta tipada. El punto de ruptura está justo en esa resolución: el cliente RDAP consulta el registro de bootstrap de IANA y, si el TLD no figura allí, no tiene adónde enviar la consulta. Eso es exactamente lo que comunica el mensaje "no registry rdap server was identified for this domain".

La laguna es estructural. La ratificación de RDAP por parte de ICANN obliga a los registros de gTLD y a los registradores acreditados a ofrecer servicio RDAP, pero los ccTLD se gestionan bajo políticas nacionales y quedan fuera de ese contrato. Muchos ofrecen solo WHOIS, algunos un formulario web con CAPTCHA y otros no publican nada legible por máquina. Así, el mismo script que devuelve un objeto JSON limpio para example.com devuelve el error RDAP para una larga cola de dominios de código de país, y esa cola no es pequeña.

Hay otras dos limitaciones que pesan incluso cuando sí existe servidor RDAP. Primera, los límites de tasa: los registros protegen un servicio pensado para consultas puntuales, y un volumen sostenido acaba con tu IP limitada o bloqueada. Segunda, la ocultación de datos: tras el RGPD, el nombre, el correo y la dirección postal del titular se omiten de las respuestas públicas en la mayoría de los dominios, de modo que los campos que la gente suele esperar simplemente no están en la respuesta. RDAP es excelente para conocer el estado, las fechas y los servidores de nombres de un dominio concreto que ya te interesa. Nunca se diseñó como mecanismo de descubrimiento.

El descubrimiento es otro problema y requiere otra fuente de datos: los archivos de zona. Un archivo de zona es la lista propia del registro con los dominios delegados en un TLD junto con sus registros de servidor de nombres. No exige ninguna consulta por dominio, no le afectan las lagunas del bootstrap de RDAP y es el único método que aporta un denominador real en lugar de una muestra. Si tu pregunta es "qué dominios existen en este TLD y cuál es su infraestructura", un archivo de zona la responde directamente; RDAP nunca lo hará, por muchos reintentos que programes.

WebTrackly está construido en torno a esa distinción. El catálogo reúne 1.538 paquetes descargables: 716 archivos de zona por TLD, 716 conjuntos enriquecidos que cubren esas mismas zonas con servidores de nombres, registros MX, IP resueltas y CMS detectado, 79 listas de sitios agrupadas por tecnología y 27 conjuntos de datos seleccionados. En conjunto, los paquetes de zona cubren 285.582.781 dominios, de los cuales 163.422.083 están en .com. El formato de descarga depende del paquete y se indica en la página del producto.

¿Necesitas la lista de dominios y no una consulta suelta?
Explora el catálogo de datos de dominios: archivos de zona y conjuntos de zona enriquecidos con NS, MX, IP y CMS.
Ver bases de datos → | Ver precios →

Cinco cosas para las que sirven de verdad los datos de dominios en bloque

Los datos de zona y enriquecimiento en bloque responden preguntas de nivel poblacional. Te dicen cuántos dominios existen, sobre qué funcionan y dónde resuelven. No te dicen a quién escribir: eso es otra categoría de datos y no está en estos archivos. Los casos de uso que siguen son los que los datos sostienen realmente.

1. Dimensionar el mercado por tecnología

• Para quién es: fundadores de SaaS, product managers y analistas que dimensionan un mercado abordable.
• El problema: las cifras de adopción publicadas por los proveedores suelen derivarse de una muestra de los N sitios más populares, lo que sobrerrepresenta sistemáticamente las herramientas empresariales e infravalora la larga cola.
• Cómo ayudan los datos en bloque: el campo de detección de CMS de los conjuntos de zona enriquecidos y las listas de sitios por tecnología aportan recuentos absolutos frente a un denominador conocido. WordPress aparece en 21.639.326 dominios del catálogo; Joomla, en 567.680. Son recuentos sobre la población de zonas rastreada, no una extrapolación a partir de una muestra de sitios famosos.
• Cómo interpretarlo: indica siempre el denominador junto al recuento. "21,6 M de dominios con WordPress sobre 279,9 M cubiertos" es una afirmación defendible; "WordPress mueve el X % de la web" no lo es, salvo que puedas precisar qué web mediste.

2. Análisis de infraestructura y alojamiento

• Para quién es: proveedores de alojamiento, empresas de CDN y analistas de infraestructura.
• El problema: la cuota de mercado en alojamiento es casi siempre una conjetura, porque nadie publica su número de clientes.
• Cómo ayudan los datos en bloque: los conjuntos enriquecidos incluyen el servidor de nombres y la IP resuelta de cada dominio. Agrupar por sufijo de NS aproxima el proveedor de DNS; asociar las IP a los ASN que las anuncian aproxima la red de alojamiento. Ambas cosas se pueden contar directamente en toda una zona.
• Una advertencia necesaria: un CDN delante del origen enmascara la IP real. Trata las cuotas de alojamiento derivadas de la IP como una medida del borde de red, no del lugar donde reside físicamente el servidor.

3. Investigación de infraestructura de correo

• Para quién es: equipos de entregabilidad, investigadores de seguridad del correo y analistas antiabuso.
• El problema: preguntas como "qué porcentaje de este TLD usa Google Workspace frente a Microsoft 365 o correo autoalojado" no tienen respuesta pública.
• Cómo ayudan los datos en bloque: los registros MX están incluidos en los conjuntos de zona enriquecidos. Clasificar los nombres de host MX por patrón de proveedor convierte la zona entera en una distribución representable en un gráfico, y repetir el ejercicio sobre una instantánea posterior muestra las migraciones entre proveedores.
• Lo que no te da: un registro MX es un destino de enrutamiento de correo, no un buzón. En estos archivos no hay direcciones.

4. Investigación de seguridad y medición de la superficie de ataque

• Para quién es: investigadores de seguridad, equipos CERT y analistas de inteligencia de amenazas.
• El problema: el reconocimiento que depende de RDAP o WHOIS en vivo se atasca de inmediato: los límites de tasa y el error de servidor RDAP inexistente hacen imposible cubrir una zona completa.
• Cómo ayudan los datos en bloque: parte de la lista de la zona en lugar de las consultas. Filtra en local la población que te interesa (un CMS, un servidor de nombres, un rango de IP) y dirige después tus propias herramientas de escaneo o verificación a ese subconjunto. La lista de dominios es la entrada de tu análisis, no el análisis en sí.
• Nota de responsabilidad: cualquier prueba activa debe limitarse al alcance para el que tengas autorización. Una lista de dominios descargable no es una autorización.

5. Crear y mantener tu propio conjunto de datos

• Para quién es: ingenieros y científicos de datos que necesitan una tabla base a nivel de dominio.
• El problema: montar un rastreador propio con cobertura de zona completa implica resolutores, reintentos, almacenamiento, deduplicación y mantenimiento continuo: un proyecto considerable antes de responder a una sola pregunta.
• Cómo ayudan los datos en bloque: un paquete de zona ya es un CSV plano con una fila por dominio. Cárgalo en DuckDB, ClickHouse o Postgres, únelo a tus tablas internas y vuelve a descargar una instantánea nueva cuando necesites comparar. Cada paquete se genera en el momento de la compra, así que una compra posterior te da una instantánea actual para contrastar con la anterior.
• Nota práctica: conserva y fecha todas las instantáneas que descargues. La evolución en el tiempo es lo más valioso que producen estos datos, y solo puedes calcularla si guardaste el archivo anterior.

Cómo son los archivos y en qué se diferencian de las consultas en vivo

Conviene ser concretos en dos puntos: la forma de los datos que recibes y en qué se diferencia de lo que devuelve una consulta RDAP o WHOIS en vivo.

Tabla 1: filas de ejemplo de un paquete de zona enriquecido

El formato de descarga depende del paquete y se indica en la página del producto. Un paquete de archivo de zona contiene la lista de dominios; un paquete enriquecido añade las columnas de resolución y detección que se muestran abajo. Los campos se rellenan cuando se ha podido determinar el valor y quedan vacíos en caso contrario.

Y eso es todo. No hay columna de contacto, ni de empresa, ni de titular, porque los datos personales de registro están ocultos en origen para la mayoría de los dominios y estos paquetes no intentan reconstruirlos. Si tu flujo de trabajo da por hecho que junto al dominio llegará una dirección de correo, este es el momento de rediseñarlo.

Tabla 2: archivos en bloque frente a RDAP/WHOIS en vivo y escáneres en vivo

Son enfoques complementarios, no sustitutivos. RDAP sigue siendo la herramienta adecuada cuando necesitas el estado autoritativo de un dominio concreto. Un escáner en vivo es lo indicado cuando quieres una huella tecnológica profunda de un sitio en este preciso momento. Los archivos en bloque son la herramienta adecuada cuando la pregunta es sobre una población, y son los únicos de los tres inmunes al problema del servidor RDAP inexistente, porque nunca realizan una consulta.

Trabajar con los datos: comprar, descargar, procesar en local

No hay una interfaz de búsqueda para filtrar ni una consulta que ejecutar en el servidor. El flujo es: elegir un paquete, comprarlo, descargar el ZIP y filtrar en tu propia máquina.

Paso 1: encontrar el paquete

Explora /zones/ para los archivos de zona por TLD y los conjuntos de zona enriquecidos, /datasets/ para las colecciones seleccionadas y /packages/ para el catálogo completo, incluidas las listas de sitios por tecnología. Cada ficha indica el número de filas antes de comprar, así que sabes qué volumen estás adquiriendo.

Paso 2: comprar y descargar

Los paquetes parten de 3,50 $ y se descargan al instante. El archivo se exporta en el momento de la compra, de modo que la instantánea refleja el estado del catálogo en ese momento y no una versión obsoleta. Los planes de suscripción cubren el uso recurrente: Pro, a 29 $/mes, incluye 50 paquetes y 10 conjuntos de datos con 30.000 llamadas a la API; Enterprise, a 99 $/mes, incluye 200 paquetes y 50 conjuntos de datos con 300.000 llamadas a la API. Tienes los detalles en /pricing/.

Paso 3: descomprimir e inspeccionar

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

Paso 4: filtrar con herramientas de línea de comandos para cortes rápidos

# domains whose detected CMS is WordPress
awk -F',' '$5 == "WordPress"' com-enriched.csv > wordpress.csv

# domains on Google Workspace mail
grep -i 'google.com' com-enriched.csv | cut -d',' -f1 > gsuite-domains.txt

# name server distribution, top 20
cut -d',' -f2 com-enriched.csv | sort | uniq -c | sort -rn | head -20

Paso 5: usar un motor columnar para todo lo analítico

En cuanto empieces a cruzar archivos o a agregar cientos de millones de filas, pasa a DuckDB o ClickHouse. DuckDB lee el CSV directamente, sin paso de importación:

-- CMS distribution across the zone
SELECT cms, count(*) AS domains
FROM read_csv_auto('com-enriched.csv')
WHERE cms IS NOT NULL
GROUP BY cms
ORDER BY domains DESC;

-- domains present in this month's snapshot but not last month's
SELECT n.domain
FROM read_csv_auto('com-2026-07.csv') n
LEFT JOIN read_csv_auto('com-2026-06.csv') o USING (domain)
WHERE o.domain IS NULL;

Esa segunda consulta merece convertirse en costumbre. Una instantánea describe un estado; dos instantáneas describen un cambio, y en el cambio está la señal.

Paso 6: automatizar el acceso al catálogo mediante la API

La API expone el catálogo de paquetes (qué existe, cuánto cuesta, cuántas filas contiene) para que puedas automatizar el descubrimiento y las descargas. No es un endpoint de consulta de dominios.

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

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

# details for one package
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/com-zone/"

La referencia completa de endpoints está en /api/. Un patrón habitual es una tarea programada que lista los paquetes que sigues, comprueba si hay una versión más reciente, la descarga y la carga en tu almacén de datos junto a la instantánea anterior.

Errores habituales al obtener datos de dominios

1. Tratar las consultas en vivo como una fuente de datos en bloque.

   • Qué sale mal: los límites de tasa, los tiempos de espera agotados y el error de servidor RDAP inexistente convierten un trabajo de 500.000 dominios en un script que nunca termina y que produce resultados parciales en los que no puedes confiar.
   • Por qué: RDAP y WHOIS son protocolos por dominio, con expectativas de servicio por dominio. El uso en bloque queda fuera de su alcance por diseño.
   • La solución: obtén la población de un archivo de zona y reserva las consultas para el pequeño subconjunto en el que realmente necesites el estado autoritativo de cada dominio.

2. Esperar datos de contacto en los datos de dominios.

   • Qué sale mal: se diseña una tubería en torno a una columna de correo que nunca llega y el proyecto se atasca en el último paso.
   • Por qué: los campos de contacto del titular están ocultos en las respuestas públicas de WHOIS y RDAP desde el RGPD para la mayoría de los dominios. Los conjuntos de datos de dominios en bloque, estos incluidos, contienen atributos de infraestructura, no datos personales.
   • La solución: decide de antemano si necesitas un conjunto de datos a nivel de dominio o un conjunto de datos de contactos. Son productos distintos, con bases legales distintas; no des por hecho que uno te dará el otro.

3. Trabajar con una sola instantánea.

   • Qué sale mal: puedes describir el estado actual, pero no mostrar ninguna tendencia, que suele ser justo lo que te preguntan.
   • Por qué: el cambio exige dos observaciones. Un solo archivo no puede producir una diferencia.
   • La solución: archiva y fecha cada descarga. Comparar dos instantáneas revela nuevos registros, dominios caídos y migraciones entre proveedores de alojamiento o de correo.

4. Leer la detección de CMS como una certeza.

   • Qué sale mal: un análisis publica una cifra precisa que un competidor con un método de detección algo distinto contradice.
   • Por qué: la detección se basa en huellas. Los front-ends headless, el almacenamiento en caché agresivo y las transformaciones de CDN ocultan la plataforma subyacente, y un campo de CMS vacío significa "no detectado", no "sin CMS".
   • La solución: indica la tasa de detección junto a cada porcentaje y deja claro que las cifras describen instalaciones detectadas.

5. Suponer que la IP resuelta identifica al proveedor de alojamiento.

   • Qué sale mal: las cifras de cuota de mercado en alojamiento acaban dominadas por un puñado de redes CDN.
   • Por qué: cuando un sitio está detrás de un CDN o un proxy inverso, el registro A publicado pertenece a la red de borde, no al servidor de origen.
   • La solución: separa en tu modelo el "proveedor de borde/CDN" del "alojamiento de origen" y usa los datos del servidor de nombres como segunda señal independiente.

6. Infrautilizar los registros NS y MX.

   • Qué sale mal: el análisis se detiene en el campo CMS y las columnas más ricas quedan sin explorar.
   • Por qué: NS y MX son baratos de analizar y sorprendentemente estables: las organizaciones cambian de CMS mucho más a menudo que de proveedor de DNS o de correo.
   • La solución: define una vez tus reglas de clasificación de proveedores sobre los nombres de host NS y MX, y reutilízalas en todas las zonas que descargues.

Preguntas frecuentes

P: ¿Por qué recibo "no registry rdap server was identified for this domain" en unos TLD y en otros no?
R: el servicio RDAP es una obligación contractual para los gTLD, pero opcional para los ccTLD, que se rigen por políticas nacionales. Si un TLD no figura en el registro de bootstrap de IANA, el cliente RDAP no puede determinar adónde enviar la consulta y notifica exactamente ese error. Es una laguna en la adopción del protocolo, no un fallo de tu cliente.

P: ¿WebTrackly hace consultas RDAP o WHOIS por mí?
R: no. WebTrackly distribuye archivos en bloque ya preparados. El formato de descarga depende del paquete y se indica en la página del producto. No hay servicio de consulta por dominio.

P: ¿Qué contiene realmente un paquete?
R: los paquetes de archivo de zona contienen la lista de dominios de un TLD. Los paquetes de zona enriquecidos añaden servidores de nombres, registros MX, IP resueltas y CMS detectado cuando ha podido determinarse. Los paquetes de tecnología son listas de sitios en los que se detectó un CMS o una tecnología concreta. Los conjuntos de datos seleccionados son recopilaciones que cruzan varias zonas; el mayor es el de todos los dominios registrados, con 272.614.863 filas.

P: ¿Se incluyen direcciones de correo o números de teléfono?
R: no. Los paquetes contienen únicamente atributos de dominio e infraestructura. Ningún archivo incluye datos de contacto personales ni de empresa.

P: ¿Cuál es el alcance de la cobertura?
R: 1.538 paquetes en total: 716 archivos de zona, 716 conjuntos de zona enriquecidos, 79 listas de sitios por tecnología y 27 conjuntos de datos seleccionados. Los paquetes de zona cubren en conjunto 285.582.781 dominios, de los cuales 163.422.083 son .com. WordPress se detecta en 21.639.326 dominios y Joomla en 567.680.

P: ¿Están actualizados los datos?
R: cada paquete se exporta en el momento de la compra, así que recibes la versión actual y no un archivo preparado meses antes. Para seguir la evolución, vuelve a comprar el mismo paquete más adelante y compara las dos instantáneas.

P: ¿Qué hace la API?
R: expone el catálogo. GET /api/v1/packages/?type=zone lista los paquetes de zona, ?type=technology&q=wordpress filtra los paquetes de tecnología por palabra clave y /api/v1/packages/{slug}/ devuelve los detalles de un paquete. La autenticación es por token bearer. La API no acepta un nombre de dominio para devolver datos sobre él.

P: ¿Cuánto cuesta?
R: los paquetes individuales parten de 3,50 $ como compra única. Pro cuesta 29 $/mes por 50 paquetes y 10 conjuntos de datos con 30.000 llamadas a la API; Enterprise cuesta 99 $/mes por 200 paquetes y 50 conjuntos de datos con 300.000 llamadas a la API. Consulta /pricing/.

P: ¿Cómo se compara esto con BuiltWith o Wappalyzer?
R: esas herramientas identifican en profundidad la huella tecnológica de sitios concretos y son la mejor opción para analizar una propiedad en detalle. Los paquetes en bloque cubren zonas enteras con menos profundidad por dominio, que es lo que exigen las preguntas de nivel poblacional. Responden a preguntas distintas.

Conclusión

"No registry rdap server was identified for this domain" es un rasgo permanente del espacio de nombres, no una caída pasajera. La cobertura de RDAP es desigual por diseño, los campos del titular están ocultos y los protocolos por dominio no pueden responder preguntas de nivel poblacional, por muy bien que los programes.

La respuesta práctica es cambiar la fuente de datos, no la lógica de reintentos. Los archivos de zona y los conjuntos de zona enriquecidos te dan la lista de dominios, sus servidores de nombres, su enrutamiento de correo, sus direcciones resueltas y, cuando es detectable, su CMS, en CSV plano que procesas en local con grep, DuckDB o ClickHouse. No contienen datos de contacto, y saberlo desde el principio es lo que evita que un proyecto fracase en el último paso.

Explora el catálogo de datos de dominios →

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 adicionales
• Conjuntos de datos seleccionados — todos los dominios registrados, servidores MX, comercio electrónico
• Documentación de la API — acceso al catálogo con token bearer
• Precios — compras únicas desde 3,50 $