Consultas Who-Is de dominios: cómo buscar datos de propiedad

«Who is domain listings» es la forma en que la mayoría de la gente describe la acción de averiguar quién registró un nombre de dominio. Los sistemas que hay detrás son WHOIS y su sucesor estructurado, RDAP. Este artículo explica qué devuelven realmente esos protocolos en 2026, por qué los campos de contacto del titular aparecen casi siempre ocultos y qué tipos de datos de dominios se pueden seguir obteniendo de forma masiva, incluido lo que publica WebTrackly y, igual de importante, lo que no.

RESUMEN / PUNTOS CLAVE

• WHOIS responde a una única pregunta concreta: qué anotan un operador de registro y un registrador sobre el alta de un dominio: fechas de creación y expiración, registrador, códigos de estado y servidores de nombres.
• Los campos de contacto del titular están ocultos. Desde la entrada en vigor del RGPD en 2018, la especificación temporal de la ICANN y la política que la sustituyó obligan a que la mayoría de las respuestas WHOIS/RDAP de gTLD oculten el nombre, la dirección, el teléfono y el buzón del titular. No existe ninguna vía legítima de obtener esos campos a gran escala.
• RDAP sustituyó a WHOIS como protocolo estándar. Devuelve JSON sobre HTTPS en lugar de texto sin estructura, con un mecanismo de arranque documentado para localizar el servidor correcto.
• Lo que sí escala bien son los datos de infraestructura: qué dominios existen en un TLD, sus servidores de nombres, sus servidores de correo, las direcciones IP a las que resuelven y el CMS o la plataforma web detectada en el sitio activo.
• WebTrackly publica esos datos de infraestructura como archivos descargables: El formato de descarga depende del paquete y se indica en la página del producto.
• Los archivos no contienen contactos personales. Ni nombres de titulares, ni direcciones de buzón, ni números de teléfono, ni datos de intención. Si necesitas eso, este no es el conjunto de datos adecuado.

ÍNDICE

• Qué significa realmente «Who Is Domain Listings»
• Qué contiene un registro WHOIS, campo por campo
• Por qué los contactos del titular están ocultos desde el RGPD
• RDAP: el sucesor estructurado de WHOIS
• Los límites de las consultas dominio a dominio
• Qué publica realmente WebTrackly
  • Estructura del catálogo
  • Cifras de cobertura
  • El esquema del archivo
  • Qué no contienen los archivos
• El flujo real: comprar, descargar y procesar en local
• La API: un catálogo, no un buscador de dominios
• Precios y entrega
• Errores habituales al trabajar con datos de dominios
• Preguntas frecuentes
• RECURSOS RELACIONADOS

Qué significa realmente «Who Is Domain Listings»

Todo nombre de dominio se registra a través de un registrador, que a su vez comunica el alta al operador de registro que gestiona el dominio de primer nivel. Ambas partes conservan una anotación de ese alta y ambas ofrecen al público una interfaz de consulta. WHOIS, definido en el RFC 3912, es la más antigua de esas interfaces: un servicio TCP simple en el puerto 43 que recibe un nombre de dominio y devuelve texto libre.

Ese texto es lo que la gente entiende por «who is domain listing». Es un registro de alta, no un perfil de empresa. Describe la relación administrativa entre un titular, un registrador y un operador de registro. No dice nada sobre lo que hace el sitio web, quién trabaja allí ni cómo gana dinero el negocio, y nunca se diseñó para ello.

La confusión surge porque antes ese registro incluía un nombre, una dirección postal, un número de teléfono y un buzón del titular. Durante casi dos décadas eso convirtió a WHOIS en un directorio público de facto. Esa etapa terminó en 2018, y buena parte de la decepción que sienten hoy quienes hacen una consulta se remonta a ese cambio.

Qué contiene un registro WHOIS, campo por campo

Una respuesta típica de gTLD, ya venga de WHOIS o de RDAP, incluye las siguientes categorías de información:

• Nombre de dominio y su forma internacionalizada, más el identificador interno de dominio del operador de registro.
• Registrador: nombre, ID de IANA, contacto de abuso y el propio servidor WHOIS del registrador.
• Fechas: creación, última actualización y expiración. Son los campos que aparecen rellenos de forma más fiable en todo el registro y la razón por la que los datos de fecha de alta resultan utilizables.
• Códigos de estado: estados EPP como clientTransferProhibited, serverHold, pendingDelete o redemptionPeriod. Describen el estado del ciclo de vida del alta y son realmente informativos: un dominio en redemptionPeriod ha expirado y se encuentra dentro de su ventana de recuperación.
• Servidores de nombres: los servidores DNS autoritativos delegados para el dominio. Este campo es público por política y es uno de los pocos que sigue estando completo.
• DNSSEC: si la delegación está firmada.
• Objetos de contacto: titular, administrativo, técnico y de facturación. En la inmensa mayoría de los registros de gTLD son ya marcadores ocultos.

La cobertura varía según el TLD. Los operadores de ccTLD fijan su propia política: algunos publican un registro más completo que los gTLD, muchos publican bastante menos y unos cuantos limitan la tasa de consultas o protegen su servicio WHOIS con CAPTCHA. No existe un estándar global único sobre lo que debe contener un «who is domain listing» más allá del contrato de la ICANN, que solo vincula a los gTLD.

Por qué los contactos del titular están ocultos desde el RGPD

Cuando el Reglamento General de Protección de Datos pasó a ser exigible en mayo de 2018, publicar los datos personales de cada titular de dominio residente en la UE en un directorio consultable de forma anónima se volvió insostenible. La ICANN adoptó una Especificación Temporal que obligaba a las partes contratadas a retirar de la salida pública la mayoría de los campos de contacto del titular, formalizada después mediante la Registration Data Policy. En la práctica, los registradores aplicaron la ocultación a escala global en lugar de intentar determinar qué titulares quedaban cubiertos por la normativa europea.

Las consecuencias prácticas para quien quiera construir algo sobre estos datos:

• El nombre, la organización, la calle, la ciudad, el código postal, el teléfono y el buzón del titular se sustituyen por cadenas como REDACTED FOR PRIVACY o Data Protected.
• El país y, a veces, el estado o la provincia sobreviven en muchos registros, y por eso las distribuciones por país todavía se pueden derivar en parte de los datos de alta.
• Los registradores suelen exponer un relé anonimizado (un formulario web o una dirección de reenvío por dominio) que permite contactar con el titular sin revelar su identidad. Los relés no son datos de contacto extraíbles y están limitados por diseño.
• El acceso a los datos sin ocultar solo existe a través de canales restringidos y basados en solicitud, para partes con una base legal acreditada y evaluados caso por caso. No es un flujo masivo, y ningún conjunto de datos comercial puede sustituirlo legalmente.

Los servicios de privacidad y proxy son anteriores al RGPD y añaden una segunda capa: incluso cuando un operador de registro publicaría los datos de contacto, el titular puede haber pagado por un proxy que figure como titular nominal. Entre la ocultación y el uso de proxies, tratar WHOIS como fuente de información de contacto ha dejado de ser una estrategia viable a cualquier escala.

RDAP: el sucesor estructurado de WHOIS

RDAP —el Registration Data Access Protocol, especificado en los RFC 7480 a RFC 7484 y en los RFC 9082/9083— se diseñó para corregir los problemas estructurales de WHOIS. Funciona sobre HTTPS, devuelve JSON, admite correctamente la internacionalización y define un archivo de arranque publicado por la IANA para que un cliente pueda determinar qué servidor es autoritativo para un TLD o un rango de IP concreto. Todos los operadores de registro y registradores de gTLD están obligados a ofrecer servicios RDAP desde 2019, y el requisito de WHOIS en el puerto 43 se retiró posteriormente.

Una consulta mínima tiene este aspecto:

# Find the authoritative RDAP base URL for the TLD
curl -s https://data.iana.org/rdap/dns.json | jq '.services[] | select(.[0][] == "com")'

# Query a domain
curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '{
  ldhName,
  status,
  events: [.events[] | {eventAction, eventDate}],
  nameservers: [.nameservers[].ldhName]
}'

Lo importante de esa salida es la forma de lo que se recibe. Los eventos, los estados y los servidores de nombres llegan estructurados y con contenido. El array entities, donde viven los contactos de titular, administrativo y técnico, contendrá una entidad de registrador con un contacto de abuso y una entidad de titular cuyos campos vCard están ocultos. RDAP cambió la codificación, no la política de divulgación.

RDAP también está limitado por tasa, por consulta y por dominio. Es la herramienta correcta para investigar un dominio, verificar una fecha de expiración o comprobar un código de estado antes de una transferencia. Es la herramienta equivocada para construir un conjunto de datos de un millón de dominios.

Los límites de las consultas dominio a dominio

Supongamos que quieres responder a una pregunta como «cuántos dominios de este TLD funcionan con WordPress» o «qué servidores de nombres son más habituales en .de». Un protocolo dominio a dominio no puede responderla. Primero necesitarías conocer la población de dominios, después consultar cada uno y luego descargar cada sitio web por separado, porque WHOIS y RDAP no dicen nada sobre qué software ejecuta el sitio.

Hacen falta tres fuentes de datos distintas:

1. La población: qué dominios existen realmente en una zona. Procede de archivos de zona o de listados equivalentes derivados del operador de registro, no de WHOIS.
2. La resolución DNS: los servidores de nombres, los servidores de correo y los registros A de cada dominio, obtenidos al resolverlos.
3. La detección de plataforma: lo que devuelve el sitio activo, obtenido al descargarlo y buscar firmas en el HTML, las cabeceras y las rutas de los recursos.

Hacer esto por tu cuenta es un proyecto de ingeniería en toda regla: acuerdos de acceso a archivos de zona o fuentes equivalentes, una granja de resolutores que no acabe bloqueada por límites de tasa, un rastreador respetuoso y almacenamiento para cientos de millones de filas. Comprar el resultado de ese proceso como archivo suele salir más barato que reconstruirlo.

Qué publica realmente WebTrackly

Estructura del catálogo

El catálogo de WebTrackly contiene 1,538 paquetes, divididos en cuatro tipos:

Los paquetes de zona se pueden explorar en /zones/, las recopilaciones curadas en /datasets/ y el catálogo completo en /packages/.

Cifras de cobertura

• 285,582,781 dominios en todas las zonas.
• 163,422,083 dominios solo en .com.
• 21,639,326 dominios con WordPress detectado.
• 567,680 dominios con Joomla detectado.
• 272,614,863 filas en el conjunto de datos de todos los dominios registrados.

Merece la pena leer esas cifras con atención. El dato de WordPress es un recuento de dominios en los que se detectó WordPress en el sitio activo, no un recuento de las instalaciones de WordPress que existen, ni una afirmación de que se haya descargado cada dominio del catálogo. La detección exige un sitio web que responda; los dominios aparcados, redirigidos y que no resuelven están presentes en las listas de zona, pero no aportan ningún valor de plataforma.

El esquema del archivo

Un paquete enriquecido por zona es un CSV con aproximadamente esta forma:

domain,created,ns,mx,ip,cms
example.com,2011-04-17,ns1.example-dns.net;ns2.example-dns.net,mx1.mailhost.net,203.0.113.14,WordPress
sample.com,,ns1.hoster.io;ns2.hoster.io,,198.51.100.7,

Notas sobre los campos, porque los matices importan más que la fila de cabecera:

• domain: siempre presente. Es la clave primaria.
• created: la fecha de alta, rellena solo cuando el operador de registro la publica. Muchos ccTLD no lo hacen, así que espera una columna dispersa fuera de los principales gTLD.
• ns: los servidores de nombres delegados. Útiles para analizar proveedores de hosting y de DNS, y una de las columnas más completas del archivo.
• mx: los registros de intercambio de correo del dominio, es decir, los nombres de host de los servidores que aceptan correo para él, como un endpoint de Google Workspace o Microsoft 365. Son nombres de servidor, no direcciones de buzón.
• ip: la dirección resuelta en el momento de la recogida. Los sitios que están detrás de un CDN resuelven al borde del CDN, lo que es un dato sobre el CDN y no sobre dónde reside el origen.
• cms: la plataforma detectada en el sitio activo; en blanco cuando no se detectó nada o el sitio no respondió.

Qué no contienen los archivos

Dicho sin rodeos, para que no haya ambigüedad antes de comprar:

• Ningún dato de contacto personal. Ni nombres de titulares, ni direcciones de buzón, ni números de teléfono, ni personas concretas de ninguna empresa. Es una decisión de diseño deliberada y una consecuencia de la ocultación descrita más arriba: esos datos no están disponibles legalmente a esta escala, y a cualquier proveedor que los ofrezca en volumen conviene cuestionarlo a fondo.
• Ninguna señal de intención ni de compra. Nada sobre si una organización está evaluando una compra.
• Ninguna estimación de tráfico, ingresos o plantilla.
• Ningún servicio de consulta por dominio. El producto son archivos masivos, no una API de consulta sobre dominios individuales. Para un solo dominio, usa RDAP directamente como se muestra arriba.
• Ninguna búsqueda por tecnología en la interfaz. La agrupación por tecnología existe como un conjunto de paquetes ya preparados; no es un constructor de consultas interactivo.

El flujo real: comprar, descargar y procesar en local

El flujo es deliberadamente simple, y todo lo que viene después de la descarga ocurre en tu propia máquina:

1. Elige un paquete en /packages/, /zones/ o /datasets/, según la zona o la plataforma que te interese.
2. Cómpralo. La exportación se genera al momento con la compra, en lugar de servirse desde un archivo precompilado y desactualizado.
3. Descarga el ZIP al instante: la entrega es una descarga directa, con el CSV dentro del archivo comprimido.
4. Descomprime y consulta en local. Sin viajes de ida y vuelta a una API ni medición por fila.

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

# Quick filtering with standard tools
grep -c ',WordPress$' com-enriched.csv
awk -F, '$6 == "Joomla" { print $1 }' com-enriched.csv > joomla-domains.txt

Para cualquier volumen superior a unos pocos millones de filas, un motor columnar resulta mucho más cómodo que las herramientas de shell. DuckDB lee CSV directamente, sin paso de importación:

-- DuckDB: top name server providers in a zone
SELECT
    regexp_extract(split_part(ns, ';', 1), '([^.]+\.[^.]+)$', 1) AS ns_domain,
    count(*) AS domains
FROM read_csv_auto('com-enriched.csv')
WHERE ns IS NOT NULL AND ns <> ''
GROUP BY 1
ORDER BY domains DESC
LIMIT 25;

-- Registration cohorts, where the registry publishes creation dates
SELECT date_trunc('year', created) AS cohort, count(*) AS domains
FROM read_csv_auto('com-enriched.csv')
WHERE created IS NOT NULL
GROUP BY 1
ORDER BY 1;

ClickHouse es la mejor opción si tu intención es mantener varias zonas cargadas y consultarlas de forma repetida:

CREATE TABLE domains
(
    domain  String,
    created Nullable(Date),
    ns      String,
    mx      String,
    ip      String,
    cms     LowCardinality(String)
)
ENGINE = MergeTree
ORDER BY domain;

INSERT INTO domains
SELECT * FROM file('com-enriched.csv', 'CSVWithNames');

Análisis típicos que esto permite: cuota de mercado de hosting y DNS por zona, distribución de CMS entre TLD, concentración de proveedores de correo, curvas de cohortes de alta en las zonas que publican fechas de creación y agrupación por rangos de IP para identificar infraestructura operada por un mismo proveedor.

La API: un catálogo, no un buscador de dominios

La API expone el catálogo de paquetes. Permite descubrir e inspeccionar lo que hay disponible y automatizar las decisiones de compra; no busca dominios individuales, porque los datos de dominios se entregan como archivos.

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

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

# Inspect a single package
curl -s "https://webtrackly.com/api/v1/packages/{slug}/" \
  -H "Authorization: Bearer YOUR_API_KEY"

Un cliente mínimo en Python sobre esos mismos endpoints:

import requests

BASE = "https://webtrackly.com/api/v1"
HEADERS = {"Authorization": "Bearer YOUR_API_KEY"}

zones = requests.get(f"{BASE}/packages/", headers=HEADERS,
                     params={"type": "zone"}).json()

for pkg in zones.get("results", []):
    print(pkg["slug"], pkg.get("domains_count"))

detail = requests.get(f"{BASE}/packages/com/", headers=HEADERS).json()
print(detail)

La documentación completa de los endpoints está en /api/.

Precios y entrega

Los paquetes individuales son compras únicas desde $3.50: El formato de descarga depende del paquete y se indica en la página del producto. Dos planes de suscripción cubren el uso recurrente:

Los detalles actualizados están en /pricing/.

Errores habituales al trabajar con datos de dominios

1. Esperar que WHOIS identifique a una empresa. Identifica un alta. Incluso antes de la ocultación, el titular era con frecuencia una empresa de hosting, una agencia o un servicio de proxy, y no la organización que hay detrás del sitio web. Usa los datos de alta para cuestiones de ciclo de vida y delegación, y los datos de infraestructura para las cuestiones relativas al sitio en sí.

2. Tratar una IP resuelta como el servidor de origen. Cualquier dominio que esté detrás de un CDN o de un proxy inverso resuelve al borde. Agregar direcciones IP sin tenerlo en cuenta produce un gráfico sobre adopción de CDN con apariencia de gráfico sobre hosting.

3. Suponer que una columna CMS vacía significa «sin CMS». En blanco significa que no se detectó nada, lo que también abarca los sitios que no respondieron, que redirigieron a otro lugar, que bloquearon la descarga o que ejecutan algo sin una firma fiable. Informa de las tasas de detección junto a los recuentos de detección, o el denominador mentirá en silencio.

4. Leer las fechas de creación ausentes como altas recientes. Muchos operadores de ccTLD no publican fechas de creación en absoluto. Una columna dispersa es un artefacto de política, no una señal sobre la antigüedad del dominio.

5. Ignorar la rapidez con la que envejecen estos datos. Los dominios expiran, los servidores de nombres cambian, los sitios se rehacen. Cualquier instantánea es una observación en un momento concreto. Si una decisión depende del estado actual, vuelve a descargar el paquete correspondiente en lugar de reutilizar un archivo del trimestre pasado.

6. Cargar cientos de millones de filas en una hoja de cálculo. Las hojas de cálculo llegan a su límite mucho antes que estos archivos. Un motor columnar en un portátil maneja la zona .com completa sin problemas; una hoja de cálculo ni siquiera llegará a abrirla.

Preguntas frecuentes

P: ¿Puedo obtener nombres y datos de contacto del titular con una consulta WHOIS?
R: En la mayoría de los dominios gTLD, no. Los campos de contacto del titular están ocultos desde que entró en vigor en 2018 la política post-RGPD de la ICANN. Los registradores suelen ofrecer un relé anonimizado para contactar con un titular sin revelar su identidad, y existe un acceso restringido basado en solicitud para partes con una base legal acreditada. Ninguno de los dos es una fuente masiva, y los archivos de WebTrackly no contienen datos de contacto personales de ningún tipo.

P: ¿Cuál es la diferencia entre WHOIS y RDAP?
R: RDAP es el sustituto estandarizado. Sirve JSON sobre HTTPS, admite correctamente el texto internacionalizado y publica un archivo de arranque de la IANA para que los clientes localicen el servidor autoritativo de cualquier TLD. WHOIS devuelve texto sin estructura por el puerto 43, con un formato que varía de un operador de registro a otro. RDAP cambió la codificación y el transporte; no cambió lo que se divulga.

P: ¿En qué formato llegan los paquetes de WebTrackly?
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 en lugar de servirse desde un archivo precompilado.

P: ¿Cuántos dominios se cubren?
R: 285,582,781 en todas las zonas, incluidos 163,422,083 en .com. El conjunto de datos de todos los dominios registrados contiene 272,614,863 filas. Los paquetes de tecnología cubren 21,639,326 dominios con WordPress detectado y 567,680 con Joomla.

P: ¿Puedo consultar un solo dominio a través de WebTrackly?
R: No. El producto son archivos masivos organizados por zona, tecnología o conjunto de datos curado. Para un solo dominio, consulta RDAP directamente: es gratuito, autoritativo para los datos de alta y requiere una única petición HTTP.

P: ¿La API permite filtrar dominios por tecnología o país?
R: La API sirve el catálogo de paquetes, no un motor de consulta a nivel de dominio. Puedes listar y filtrar paquetes por tipo y término de búsqueda, y después comprar y descargar los que necesites. El filtrado de filas individuales se hace en local, en DuckDB, ClickHouse o la herramienta que prefieras.

P: ¿Cómo de actualizados están los datos?
R: Las exportaciones se generan en el momento de la compra a partir del estado actual del catálogo. Como la web cambia continuamente, trata cualquier descarga como una instantánea y vuelve a descargarla antes de tomar decisiones que dependan del estado presente.

P: ¿Cuáles son los límites de cada plan?
R: Pro cuesta $29 al mes e incluye 50 paquetes, 10 conjuntos de datos y 30,000 llamadas a la API. Enterprise cuesta $99 al mes e incluye 200 paquetes, 50 conjuntos de datos y 300,000 llamadas a la API. Los paquetes individuales también pueden comprarse de forma puntual desde $3.50. Consulta /pricing/.

WebTrackly publica datos de zonas de dominios, DNS y detección de CMS como archivos descargables.
Explorar datos de dominios → | 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
• Conjuntos de datos curados — todos los dominios registrados, servidores MX, comercio electrónico
• Precios — compras únicas desde $3.50