▸ Cómo obtener dominios recién registrados

No existe un único feed con «todos los dominios registrados en la última hora». Las registries no publican ninguno y la ICANN no se lo exige. Lo que hay son observaciones, y una lista de dominios registrados recientemente se construye eligiendo la observación que encaje con tu tolerancia al retraso y tu necesidad de cobertura:

• ▸ ¿Necesitas autoridad y exhaustividad para gTLD? Haz diff de los archivos de zona. Suelo de 24 horas, gratis, trabajo de verdad.
• ▸ ¿Necesitas velocidad y todos los TLD? Certificate Transparency. Segundos por detrás de la emisión, pero ciego a los dominios sin certificado.
• ▸ ¿Necesitas que funcione esta misma tarde? Descarga una lista ya preparada: la nuestra está más abajo, y las alternativas también.

Tres marcas de tiempo distintas reciben el mismo nombre, y confundirlas es la razón más común de que una lista de dominios recién registrados no coincida con la de otra persona:

• 1. Fecha de registro: cuándo creó el registro la registry. Autoritativa, expuesta por dominio vía RDAP/WHOIS, no publicada de forma masiva por nadie.
• 2. Aparición en la zona: cuándo obtuvo el dominio sus primeros servidores de nombres en la zona del TLD. Normalmente de minutos a horas después del registro, pero un dominio registrado y nunca apuntado a ningún sitio no aparece nunca.
• 3. Primera observación: cuándo lo vio por primera vez un registro de certificados, un resolver o un rastreador. Esto es lo que contiene realmente cualquier feed descargable, incluido el nuestro.

Lo más parecido a la verdad de base. Las registries de gTLD están obligadas por contrato a poner sus archivos de zona a disposición a través del Centralized Zone Data Service (CZDS) de la ICANN. Creas una cuenta, envías una solicitud por TLD indicando tu propósito y cada registry la aprueba o la deniega; las aprobaciones suelen concederse por un año y luego hay que renovarlas. Por esta vía se alcanzan unos 1.150 gTLD, incluidos .com y .net. La mayoría de los ccTLD no: unos pocos (los suecos .se y .nu, el suizo .ch) publican abiertamente, el resto no publica nada.

Un archivo de zona lista delegaciones, no registros. Así que la receta es: normaliza los nombres delegados de hoy y resta los de ayer.

# 1. Fetch today's zone (CZDS gives you a per-TLD download URL + API token)
curl -s -H "Authorization: Bearer $CZDS_TOKEN" \
     -o com.txt.gz "https://czds-api.icann.org/czds/downloads/com.zone"

# 2. Reduce the zone to a sorted list of delegated second-level names
zcat com.txt.gz \
  | awk '$4=="NS" {print tolower($1)}' \
  | sed 's/\.$//' \
  | sort -u > zone.today

# 3. Everything present today and absent yesterday is a new delegation
comm -13 zone.yesterday zone.today > new-domains-$(date +%F).txt
wc -l new-domains-$(date +%F).txt

# 4. Roll the window
mv zone.today zone.yesterday

Fíjate en $4=="NS" en lugar de $3: las líneas de zona llevan un TTL opcional, así que el índice de columna se desplaza. Comprueba unas cuantas líneas de tu archivo real antes de fiarte del número de campo: este es el fallo que vacía tu lista en silencio.

Comprobación de realidad sobre almacenamiento: solo la zona .com ronda los 160 millones de nombres delegados, así que la copia ordenada de cada día ocupa varios gigabytes sin comprimir. Guardar dos días más un conjunto permanente de vistos es la huella mínima viable.

Todo certificado TLS de confianza pública se envía a registros Certificate Transparency de solo anexado, y esos registros son públicos. Como un dominio recién registrado que se está configurando de verdad casi siempre obtiene un certificado en cuestión de minutos (el panel de hosting o el proxy inverso lo solicitan automáticamente), CT es el canal de descubrimiento amplio más rápido disponible gratis y, a diferencia de los archivos de zona, cubre todos los TLD, ccTLD incluidos.

Las dos vías prácticas de entrada:

# A. Consume an aggregated CT firehose (easiest)
#    e.g. CertStream-compatible websocket endpoints
websocat wss://certstream.calidog.io \
  | jq -r '.data.leaf_cert.all_domains[]?' \
  | sed 's/^\*\.//' \
  | sort -u

# B. Read the logs directly (RFC 6962) - no third party in the path
#    Each log exposes its tree head and a paged entries endpoint:
curl -s https://ct.googleapis.com/logs/us/argon2026h2/ct/v1/get-sth | jq .tree_size
curl -s "https://ct.googleapis.com/logs/us/argon2026h2/ct/v1/get-entries?start=0&end=9"

La opción B es la que ejecuta DNSniffer. Da más trabajo (mantienes un offset por registro, parseas las estructuras de las hojas y lidias con registros que limitan la tasa o topan las entradas por petición), pero no dependes de que el agregador de otro siga en pie.

Este es el sitio en el que estás, así que toma esta sección por lo que es; pero la razón por la que pertenece a la lista es que es la combinación de los dos métodos anteriores, ya en marcha. DNSniffer ingiere archivos de zona de gTLD y lee directamente los registros de Certificate Transparency, fusiona ambos en una única tabla de dominios - actualmente 368.663.940 dominios activos repartidos en 10.629 TLD, y publica la porción recién detectada como CSV plano.

exportación diaria reconstruida por última vez el 15 de octubre de 2026 · se regenera cada día

Tres formas de consumirlo, ninguna requiere cuenta:

# 1. List the newly-detected exports and grab the current download URL
curl -s 'https://dnsniffer.com/api/v1/datasets?category=newly_detected' \
  | jq -r '.data[] | "\(.periodicity)\t\(.row_count)\t\(.download_url)"'

# 2. Download and read the daily file (zipped CSV)
URL=$(curl -s 'https://dnsniffer.com/api/v1/datasets?category=newly_detected' \
      | jq -r '.data[] | select(.periodicity=="daily") | .download_url')
curl -sL "https://dnsniffer.com$URL" -o nrd-daily.zip
unzip -p nrd-daily.zip | head

# 3. Filter to one TLD without downloading everything
unzip -p nrd-daily.zip | awk -F, 'NR==1 || $1 ~ /\.com$/'

Si solo te interesan los nombres que coinciden con tu marca o una palabra clave, la función monitor hace el filtrado en el servidor y guarda un historial de coincidencias que puedes recuperar por la API: eso requiere una cuenta gratuita en vez de una descarga anónima, pero sale mucho más barato que bajar 300.000 filas al día para buscar una cadena. La página dominios más nuevos muestra el mismo flujo en el navegador, y el servidor MCP lo expone directamente a Claude, ChatGPT y otros agentes.

Varios proveedores de seguridad y aficionados publican a diario una lista de dominios nuevos como archivo de texto o comprimido: normalmente los registros de ayer, con predominio de gTLD y en un horario fijo. Son realmente útiles como punto de partida sin esfuerzo, y comparten tres debilidades que conviene conocer antes de construir sobre una: el editor rara vez documenta qué TLD cubre, el archivo aparece 24-48 horas después del hecho, y los planes gratuitos desaparecen o se esconden tras un registro sin previo aviso.

Si una lista gratuita es tu fuente principal, réplicala a diario en tu propio almacenamiento. El valor está en el historial acumulado, y un feed que desaparece no se puede rellenar a posteriori.

Proveedores como WhoisXML API, DomainTools y varias plataformas de inteligencia de amenazas venden feeds de dominios recién registrados, normalmente con entrega diaria y campos WHOIS adjuntos: registrador, fecha de registro, servidores de nombres y a veces datos de contacto cuando no están ocultos. Lo que pagas es triple: cobertura de ccTLD que no puedes obtener por tu cuenta, la fecha de registro como campo en lugar de algo que buscar dominio a dominio, y que otro opere la recolección.

Preguntas que merece la pena hacer antes de firmar nada:

• ▸ ¿Qué TLD exactamente, y la lista está publicada o es solo «representativa»?
• ▸ ¿La fecha es la de registro de la registry o su primera observación?
• ▸ ¿Cuál es la hora de corte y el retraso de entrega, en horas?
• ▸ ¿Puedes redistribuir datos derivados o solo consumirlos internamente?

Los proveedores de DNS pasivo registran las resoluciones observadas por resolvers recursivos que colaboran, y te dan una marca de primera detección por nombre. Capta cosas que los archivos de zona se pierden (subdominios, ccTLD y dominios que ya resuelven antes de tener certificado) y está sesgado por construcción: solo ves lo que ve la red de sensores del proveedor, así que un dominio usado por cien personas en un país puede no aparecer siquiera. Trátalo como un buen complemento de CT y no como fuente de descubrimiento autónoma, y cuenta con pagar por cualquier volumen serio.

RDAP es el sustituto estructurado de WHOIS y el único sitio donde vive la fecha de registro real. No puede enumerar (por diseño no existe una consulta «lista todos los dominios registrados hoy»), pero zanja la cuestión para cualquier nombre concreto:

# rdap.org follows the IANA bootstrap, so you need not know the registry
curl -s https://rdap.org/domain/example.com \
  | jq -r '.events[] | select(.eventAction=="registration") | .eventDate'

# Filter a candidate list down to genuinely new registrations
while read -r d; do
  created=$(curl -s "https://rdap.org/domain/$d" \
            | jq -r '.events[]? | select(.eventAction=="registration") | .eventDate')
  [ -n "$created" ] && echo "$d,$created"
  sleep 1        # be polite: registry RDAP endpoints rate-limit aggressively
done < new-domains.txt > verified.csv

Elijas las fuentes que elijas, los mismos cinco pasos separan una lista que sigue siendo útil de otra que se pudre en silencio:

1. 1. Normaliza. Pasa a minúsculas, quita el punto final, convierte los IDN a punycode (xn--) y reduce cada nombre a su forma registrable con la Public Suffix List. Example.CO.UK., www.example.co.uk y example.co.uk son un mismo dominio.
2. 2. Mantén un conjunto permanente de vistos. «Nuevo» se define frente a todo lo que hayas registrado alguna vez, no frente al archivo de ayer. Sin esto vuelves a reportar dominios antiguos cada vez que una fuente cambia de forma.
3. 3. Guarda por separado la primera detección y la fuente. Un dominio visto en CT a las 09:00 y en el diff de zona a las 03:00 del día siguiente es una fila con dos observaciones. Sobrescribir pierde la señal más temprana, que es la que te importa.
4. 4. Puntúa antes de actuar. El volumen NRD en bruto es demasiado alto para revisarlo. Filtra a lo que necesitas (cadenas cercanas a tu marca, parecidos por distancia de edición, TLD sospechosos, combinaciones de palabras clave) y verifica esa lista corta con RDAP.
5. 5. Cuenta con la rotación. Una gran parte de los dominios recién registrados caduca en días, y el drop-catching hace que el mismo nombre reaparezca una y otra vez. Vuelve a comprobar que sigue vivo antes de tratar una entrada como un activo real.

• ▸ Contar puntos para hallar el dominio registrable. foo.co.uk y foo.uk tienen ambos una forma registrable de dos etiquetas, pero por reglas distintas. Usa la Public Suffix List.
• ▸ Tomar la ausencia en la zona por inexistencia. Un dominio registrado y no delegado es invisible para cualquier método basado en zonas.
• ▸ Ignorar la zona horaria y la hora de corte. Los archivos de zona son instantáneas en un momento definido por la registry; «ayer» en tu tubería y en el archivo no son la misma ventana.
• ▸ Dar por hecho que la primera detección en CT equivale al registro. Es una buena aproximación y un mal dato.
• ▸ Bloquear un feed NRD entero. Cada día se registran cientos de miles de dominios legítimos; el bloqueo indiscriminado genera muchos más falsos positivos que incidentes evita. Puntúa y después actúa.

El acceso a los archivos de zona por CZDS se concede bajo condiciones que aceptas por registry, y restringen la redistribución: en general puedes usar los datos, no republicar la zona. Los datos de contacto de WHOIS y RDAP son datos personales según el RGPD y están ocultos por defecto en la mayoría de los registros; la fecha de registro no es un dato personal, pero los campos del registrante sí. Si estás construyendo un producto sobre cualquier feed, lee la cláusula de redistribución antes de diseñar la exportación.