«No Registry RDAP Server Was Identified»: causas y soluciones

Si una consulta de dominio devuelve «no registry RDAP server was identified for this domain», esa consulta nunca llegó a alcanzar un registro. El cliente RDAP falló en el paso de bootstrap: no pudo asociar el TLD del dominio a una URL base de RDAP. Este artículo explica por qué ocurre, cómo funciona el registro bootstrap de IANA, cómo verificar tú mismo la causa y qué hacer cuando un TLD realmente no ofrece servicio RDAP, incluido cuándo un conjunto de datos masivo de archivos de zona es el sustituto práctico de las consultas dominio a dominio.

TL;DR / Ideas clave

• El mensaje significa que el cliente RDAP no encontró una URL base para el TLD del dominio en el registro bootstrap de IANA. Es un fallo de resolución, no una respuesta de «dominio no encontrado».
• Las tres causas habituales son: el TLD no tiene ningún servicio RDAP (la mayoría de los ccTLD), el cliente usa una copia en caché obsoleta del archivo bootstrap, o lo que se consulta no es un TLD real (una errata, un nombre interno o un nombre de host suelto).
• Puedes confirmar la causa con una sola petición: descarga https://data.iana.org/rdap/dns.json y busca el TLD dentro.
• ICANN exige RDAP a los gTLD sujetos a contrato. Los ccTLD quedan fuera de ese contrato, así que ahí la disponibilidad de RDAP es voluntaria y desigual: unos publican RDAP, otros solo WHOIS y algunos no publican nada en formato legible por máquina.
• Cuando existe RDAP pero no WHOIS, o al revés, una cadena de alternativas —bootstrap de RDAP, después el endpoint documentado del propio registro y por último WHOIS en el puerto 43— resuelve la mayoría de los casos.
• Cuando lo que necesitas saber es qué existe dentro de una zona y no los datos de un dominio concreto, las consultas dominio a dominio son la herramienta equivocada, haya RDAP o no. Un conjunto de datos de archivos de zona enumera directamente los dominios registrados.
• Los archivos de zona y los conjuntos enriquecidos aportan dominios e infraestructura (servidores de nombres, MX, IP, CMS detectado). No contienen contactos del titular, y ningún conjunto de datos de este sitio los incluye.

Índice

1. Qué significa realmente «No Registry RDAP Server Was Identified»
2. Cómo resuelve un servidor el bootstrap de RDAP
3. Diagnosticar la causa en tres comprobaciones
4. Alternativas que funcionan cuando falla el bootstrap
5. Cuándo el objetivo real es enumerar, no consultar
6. Qué contienen realmente los archivos
7. El flujo de trabajo real: comprar, descargar y procesar en local
8. Cómo encontrar paquetes a través de la API
9. Errores frecuentes y cómo evitarlos
10. Preguntas frecuentes
11. Conclusión
12. Recursos relacionados

Qué significa realmente «No Registry RDAP Server Was Identified»

El mensaje de error «no registry rdap server was identified for this domain» es un obstáculo habitual, y profundamente disruptivo, para cualquiera que intente reunir información sobre dominios concretos. Para entender del todo sus implicaciones y la solución de WebTrackly, primero hay que entender qué es RDAP. El Registration Data Access Protocol (RDAP) es el sucesor del veterano protocolo WHOIS y se diseñó para ofrecer una forma más estructurada, segura y estandarizada de acceder a los datos de registro de dominios. Funciona sobre HTTP(S) y usa JSON para transferir los datos, lo que lo hace más legible por máquina y más cómodo para desarrolladores que su predecesor.

ICANN (Internet Corporation for Assigned Names and Numbers) impuso la adopción de RDAP a los gTLD (dominios genéricos de primer nivel) como .com, .org, .net y muchos otros, con el objetivo de mejorar el acceso a los datos, la privacidad y la internacionalización. Sin embargo, internet es enorme y descentralizado. Mientras que los gTLD suelen cumplir, muchos ccTLD (dominios de primer nivel de código de país) como .de (Alemania) o .jp (Japón) dependen de registros distintos y presentan niveles muy dispares de implementación de RDAP, cuando no carecen de ella por completo.

Cuando te encuentras con «no registry rdap server was identified for this domain», normalmente significa una de estas cosas:

1. TLD no soportado: ese dominio de primer nivel en concreto (por ejemplo, un ccTLD poco conocido o un gTLD muy reciente) simplemente no tiene un servidor RDAP configurado o reconocido por el sistema que lanza la consulta. Es un problema habitual en muchos registros de código de país que no han completado la transición desde WHOIS o que mantienen sistemas propios.
2. Fallo técnico o configuración incorrecta: el servidor RDAP de ese TLD puede existir, pero estar caído temporalmente, mal configurado o con problemas de red, lo que provoca el fallo de la consulta.
3. Servicios de privacidad o proxy de dominio: aunque RDAP se diseñó pensando más en la privacidad, algunos dominios usan servicios de protección que ocultan deliberadamente los datos del titular. No es exactamente el error «no registry RDAP server», pero es un obstáculo relacionado a la hora de acceder a datos útiles.
4. Convenciones de nombres no estándar: algunos dominios internos o de nicho no siguen las estructuras reguladas por ICANN, lo que los hace invisibles para los resolutores RDAP estándar.

La consecuencia práctica es que no obtienes respuesta alguna, en lugar de un «este dominio no está registrado» con valor autoritativo. Ambas cosas se confunden con facilidad y llevan a conclusiones muy distintas: un fallo de bootstrap no dice absolutamente nada sobre si el dominio existe.

Los métodos manuales para sortearlo son tediosos e ineficientes. Puedes probar distintos clientes WHOIS, rebuscar en archivos de datos históricos o incluso investigar el sitio web a mano. Eso consume horas, suele dar información incompleta o desactualizada y resulta del todo inescalable para listas de cientos o miles de dominios. La generación de leads y el análisis de mercado actuales exigen automatización y datos completos.

Cómo resuelve un servidor el bootstrap de RDAP

RDAP no tiene servidor central. Cada registro opera el suyo y el cliente debe descubrir cuál es el autoritativo para un nombre dado. Ese proceso de descubrimiento está definido en el RFC 7484 y se denomina bootstrapping.

IANA publica un archivo bootstrap para nombres de dominio en https://data.iana.org/rdap/dns.json. Es un documento JSON que contiene un array services. Cada entrada es un array de dos elementos: una lista de TLD y una lista de URL base de RDAP que los atienden. Un cliente que resuelve example.com toma la etiqueta situada más a la derecha, com, busca la entrada de servicio que la contiene y lanza GET {base_url}domain/example.com contra la URL encontrada.

# Inspect the bootstrap file directly
curl -s https://data.iana.org/rdap/dns.json | head -c 400

# Check whether a specific TLD has an RDAP base URL at all
curl -s https://data.iana.org/rdap/dns.json \
  | python3 -c "import json,sys; d=json.load(sys.stdin); t=sys.argv[1]; \
print([s[1] for s in d['services'] if t in s[0]] or 'NO RDAP SERVICE FOR .'+t)" de

Si ese comando imprime NO RDAP SERVICE, el error no es un fallo de tu cliente y no habrá reintento que lo cambie. El TLD simplemente no está en el registro, que es exactamente la situación que describe el mensaje.

Hay dos detalles más que importan. Primero, el archivo lleva una marca temporal publication; los clientes que lo cachean de forma agresiva pueden tardar días en ver un TLD recién añadido. Segundo, el RFC 7484 especifica coincidencia por la etiqueta más larga, de modo que un cliente que compare ingenuamente solo la última etiqueta puede gestionar mal los nombres bajo sufijos de varias etiquetas. Ambos casos producen el mismo mensaje visible para el usuario por motivos distintos.

Diagnosticar la causa en tres comprobaciones

1. ¿El sufijo es un TLD real? Compáralo con la lista de TLD de IANA en https://data.iana.org/TLD/tlds-alpha-by-domain.txt. Los nombres internos (.local, .internal, .corp), las erratas y los nombres de host enviados con un prefijo de subdominio son las falsas alarmas más frecuentes.
2. ¿Está el TLD en el archivo bootstrap? Usa el comando anterior. Su ausencia es la respuesta definitiva: no hay ningún servidor RDAP que identificar.
3. ¿La copia de tu cliente está al día? Fuerza una descarga nueva de dns.json y vuelve a intentarlo. Muchas bibliotecas y envoltorios de CLI guardan el archivo bootstrap en disco y nunca lo caducan. Si la descarga nueva resuelve el TLD pero tu herramienta no, la culpa es de la caché.

Ejecutar estas tres comprobaciones en orden distingue un problema de entrada de un problema del cliente y de una carencia real del registro, y cada uno tiene una solución distinta.

Alternativas que funcionan cuando falla el bootstrap

El Registry Agreement de ICANN y el requisito del Registration Data Access Protocol se aplican a los gTLD. Los operadores de ccTLD no son parte de ese acuerdo, así que sus políticas sobre datos de registro se fijan a escala nacional. Por eso .com, .org, .app y los gTLD más recientes se resuelven sin problemas mientras que una larga cola de zonas de código de país no lo hace.

Una cadena de alternativas que cubre la mayoría de los casos reales:

1. Bootstrap de IANA. Es la vía estándar; úsala primero.
2. El endpoint RDAP documentado del propio registro. Algunos registros operan RDAP pero no figuran en el archivo bootstrap. Las páginas de TLD de IANA en https://www.iana.org/domains/root/db/<tld>.html indican la organización patrocinadora y su servicio de datos de registro.
3. WHOIS en el puerto 43. Consulta whois.iana.org por el propio TLD para averiguar el host WHOIS autoritativo y consulta después ese host por el dominio. La salida es texto sin estructura, así que hay que contar con un parseo específico por registro.
4. DNS como comprobación de existencia. Una consulta NS no sustituye a los datos de registro, pero un conjunto de registros NS delegados es un indicio sólido de que el dominio está registrado, que muchas veces es el único dato que hacía falta.

# Find the authoritative WHOIS host for a ccTLD, then query the domain
whois -h whois.iana.org de
whois -h whois.denic.de example.de

# Existence check via delegation
dig +short NS example.de

Ninguna de estas vías recupera los datos de contacto del titular. La mayoría de los registros los ocultan por política, y RDAP se diseñó para hacer explícita esa ocultación, no para exponer más información.

Cuándo el objetivo real es enumerar, no consultar

Buena parte del tráfico que aterriza en este error no busca consultar un solo dominio, sino responder a una pregunta de población: qué dominios existen en este TLD, cuáles usan un CMS determinado, cuáles apuntan a un proveedor de correo concreto. RDAP dominio a dominio es un mal instrumento para eso incluso donde funciona: haría falta una petición por nombre, y los registros aplican límites de frecuencia en consecuencia.

Para esa clase de preguntas la fuente de verdad es el archivo de zona, no los datos de registro. Un archivo de zona enumera los nombres delegados de un TLD y no contiene información del titular, que es precisamente por lo que puede publicarse de forma masiva.

WebTrackly distribuye esos datos en un catálogo de 1,538 paquetes:

• 716 archivos de zona de TLD: la lista de dominios delegados de cada zona cubierta.
• 716 conjuntos enriquecidos por zona: los mismos dominios con servidores de nombres, registros MX, IP resuelta y CMS detectado.
• 79 listados de sitios por CMS o tecnología: por ejemplo, WordPress con 21,639,326 dominios y Joomla con 567,680.
• 27 conjuntos de datos seleccionados: incluido el de todos los dominios registrados, con 272,614,863 filas.

La cobertura de todas las zonas suma 285,582,781 dominios, de los cuales .com aporta por sí solo 163,422,083. Explora el catálogo en /packages/, las zonas en /zones/ y los conjuntos seleccionados en /datasets/.

Qué contienen realmente los archivos

El formato de descarga depende del paquete y se indica en la página del producto. Las columnas dependen del tipo de paquete:

• Archivos de zona: el nombre de dominio y la fecha de registro cuando el registro la publica. Muchos no lo hacen, y en ese caso el campo queda vacío en lugar de estimarse.
• Conjuntos enriquecidos por zona: dominio, servidores de nombres (ns), servidores de correo (mx), dirección IP resuelta y CMS detectado cuando es identificable.
• Listados de tecnología y CMS: los dominios en los que se detectó esa tecnología.

Lo que los archivos no contienen, en ningún paquete, es igual de importante y conviene decirlo con claridad:

• Ni nombres de titulares, ni direcciones postales, ni direcciones de correo electrónico, ni números de teléfono.
• Ni fichas de empresa, ni cargos, ni identificadores personales.
• Ni señales de intención, tráfico o ingresos.
• Ni consulta interactiva dominio a dominio: el producto son archivos masivos, no una interfaz de consulta sobre nombres individuales.

Si tu flujo de trabajo depende de los contactos del titular, estos datos no los proporcionan, y RDAP tampoco lo hace para la gran mayoría de dominios, ya que la ocultación es hoy la norma en los gTLD.

El flujo de trabajo real: comprar, descargar y procesar en local

1. Elige un paquete. Escoge la zona, el listado de tecnología o el conjunto de datos seleccionado que responda a tu pregunta. Los precios arrancan en $3.50 por compra única; consulta /pricing/.
2. Cómpralo. La exportación se genera en el momento de la compra, así que el archivo refleja el estado del catálogo en ese instante y no una instantánea prefabricada de antigüedad desconocida.
3. Descárgalo. El formato de descarga depende del paquete y se indica en la página del producto.
4. Procésalo en local. Los archivos son lo bastante grandes como para que una hoja de cálculo sea la herramienta equivocada. Las utilidades de Unix se encargan del filtrado; un motor analítico embebido, de los joins y las agregaciones.

unzip -o zone_example.zip -d ./data

# Count rows and inspect the header
wc -l ./data/*.csv
head -3 ./data/*.csv

# Filter by a nameserver operator without loading the file into memory
grep -F ',ns1.example-dns.net,' ./data/enriched.csv > ./data/subset.csv

-- DuckDB reads the CSV directly; no import step, no server
SELECT mx, count(*) AS domains
FROM read_csv_auto('./data/enriched.csv')
WHERE cms = 'WordPress'
GROUP BY mx
ORDER BY domains DESC
LIMIT 25;

Para análisis repetidos sobre varias zonas, cargar los CSV en ClickHouse y consultarlos como una sola tabla compensa el tiempo de configuración. Para una única pregunta sobre una única zona, DuckDB directamente contra el CSV llega antes a la respuesta.

Cómo encontrar paquetes a través de la API

La API sirve el catálogo: indica qué paquetes existen y qué cubre cada uno. No es un endpoint de búsqueda de dominios y no ofrece consulta dominio a dominio. La autenticación se hace con un bearer token.

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

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

# Fetch details for one package
curl -s "https://webtrackly.com/api/v1/packages/{slug}/" \
  -H "Authorization: Bearer YOUR_API_KEY"

Los planes de suscripción incluyen cuotas de llamadas a la API: Pro, a $29/mes, cubre 50 paquetes y 10 conjuntos de datos con 30,000 llamadas; Enterprise, a $99/mes, cubre 200 paquetes y 50 conjuntos de datos con 300,000 llamadas. La documentación completa está en /api/.

Errores frecuentes y cómo evitarlos

1. Leer el fallo de bootstrap como «el dominio no existe».

   • Qué sale mal: un pipeline marca nombres como no registrados porque la llamada RDAP falló, y la lógica posterior actúa sobre ese dato.
   • La solución: trata el fallo de bootstrap como un resultado desconocido, con su propio código de estado y distinto de una respuesta negativa autoritativa. Confirma la existencia por separado con una comprobación de delegación DNS.

2. Cachear el archivo bootstrap indefinidamente.

   • Qué sale mal: un TLD que estrenó soporte RDAP hace meses sigue fallando en local porque el dns.json en caché es anterior.
   • La solución: actualiza el archivo de forma periódica y respeta su campo publication. Con un refresco diario basta.

3. Construir una estrategia de ccTLD apoyada solo en RDAP.

   • Qué sale mal: las suposiciones de cobertura heredadas del comportamiento de los gTLD fallan en las zonas de código de país y generan huecos silenciosos en el conjunto de datos.
   • La solución: mantén un mapa explícito, TLD a TLD, de qué protocolo está disponible —RDAP, WHOIS o ninguno— y enruta las consultas en consecuencia, en lugar de reintentar un protocolo que nunca se ofreció.

4. Usar consultas dominio a dominio para responder preguntas de población.

   • Qué sale mal: millones de peticiones secuenciales, límites de frecuencia, direcciones de origen bloqueadas y semanas de ejecución para algo que resuelve un solo archivo.
   • La solución: usa datos a nivel de zona cuando la pregunta es sobre una zona y reserva las consultas dominio a dominio para el pequeño conjunto de nombres que de verdad necesita datos de registro actualizados.

5. Esperar contactos del titular de cualquiera de estas fuentes.

   • Qué sale mal: un proyecto se define en torno a datos de contacto que ni las políticas de ocultación ni los formatos de datos masivos proporcionan, y se atasca en cuanto eso queda claro.
   • La solución: define el alcance en torno a lo que sí se publica: el dominio, su delegación, su infraestructura de correo y alojamiento y el stack de software detectado.

6. Parsear el texto de WHOIS como si fuera un único formato.

   • Qué sale mal: un parser escrito contra la salida de un registro asigna mal los campos de otro sin avisar, porque el WHOIS en el puerto 43 no tiene esquema.
   • La solución: prioriza el JSON de RDAP allí donde exista y trata el formato de cada servidor WHOIS como un objetivo de parseo independiente, con sus propias pruebas.

Preguntas frecuentes

P: ¿Este error significa que el dominio no está registrado?
R: No. Significa que el cliente no pudo determinar a qué servidor RDAP preguntar. Tras este error, el estado de registro del dominio es desconocido, no negativo. Una consulta DNS de los registros NS del dominio es una comprobación independiente y rápida de si está delegado.

P: ¿Por qué fallan tantos ccTLD?
R: El requisito de RDAP de ICANN deriva del Registry Agreement de los gTLD, del que los operadores de ccTLD no son parte. Sus servicios de datos de registro se rigen por la política nacional, así que algunos publican RDAP, otros solo WHOIS en el puerto 43 y otros no publican nada en formato legible por máquina.

P: ¿Se arregla cambiando de cliente RDAP?
R: Solo si la causa era una caché obsoleta o una mala implementación de la coincidencia más larga. Si el TLD no está en dns.json, todo cliente conforme fallará igual.

P: ¿Qué contienen los paquetes de WebTrackly?
R: El formato de descarga depende del paquete y se indica en la página del producto. Los paquetes de zona enumeran los dominios de un TLD, más la fecha de registro cuando el registro la publica. Los paquetes enriquecidos añaden servidores de nombres, registros MX, IP resuelta y CMS detectado. Los paquetes de tecnología enumeran los dominios en los que se detectó una tecnología concreta.

P: ¿Los archivos incluyen correos o teléfonos del titular?
R: No. Ningún paquete contiene datos de contacto personales de ningún tipo, y no existe una interfaz de consulta dominio a dominio. Los datos describen dominios y su infraestructura.

P: ¿Cómo de actualizado está un archivo descargado?
R: La exportación se genera en el momento de la compra a partir de los datos actuales del catálogo, así que no descargas un archivo prefabricado de antigüedad desconocida.

P: ¿Cuál es el precio?
R: Las compras únicas de paquetes arrancan en $3.50. Las suscripciones son Pro a $29/mes (50 paquetes y 10 conjuntos de datos, 30,000 llamadas a la API) y Enterprise a $99/mes (200 paquetes y 50 conjuntos de datos, 300,000 llamadas a la API). Los detalles están en /pricing/.

P: ¿Qué permite hacer la API?
R: Expone el catálogo de paquetes: listarlos y filtrarlos por tipo, buscarlos y recuperar los detalles de un paquete concreto por su slug. No realiza consultas de dominios.

Conclusión

«No registry RDAP server was identified for this domain» es un fallo de resolución del bootstrap con tres causas corrientes: una entrada que no es un TLD real, un archivo bootstrap en caché y obsoleto, o un TLD que no dispone de servicio RDAP. Una sola petición a https://data.iana.org/rdap/dns.json revela cuál de las tres tienes delante, y cada una tiene su propia solución: corregir la entrada, refrescar la caché o recurrir al host WHOIS documentado del registro.

Si el objetivo de fondo nunca fue un dato de registro concreto, sino un inventario de lo que existe en una zona, el protocolo era el instrumento equivocado desde el principio. Un conjunto de datos de archivos de zona responde a esa pregunta directamente, en un solo archivo, con los dominios y su infraestructura, y sin los contactos del titular que ni RDAP ni los datos masivos van a darte.

¿Trabajas con datos a nivel de zona?
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 — más de 1,500 bases de datos de dominios descargables
• Archivos de zona por TLD — .com, .net, .de y más de 700 zonas
• Conjuntos de datos seleccionados — todos los dominios registrados, servidores MX, comercio electrónico
• Precios — compras únicas desde $3.50