Información de dominios

Madurezreviewed

Última revisión29 jul 2026

Publicado20 de julio de 2026

Última actualización30 de julio de 2026

Un dominio conecta varias partes de la infraestructura: registro, DNS autoritativo, certificados, correo, proveedores y direcciones IP. La tarea no consiste en acumular subdominios, sino en demostrar qué relación mantiene cada nombre con el objetivo y cuándo se observó.

Los ejemplos utilizan DOMAIN como dominio raíz, FQDN como nombre completo y TARGET_IP como dirección ya atribuida. Sustitúyelos por valores del inventario.

Entender primero la organización

El sitio principal aporta contexto antes de ejecutar herramientas. Productos, portales de soporte, acceso de clientes, documentación, páginas de estado y referencias a socios explican qué servicios necesita la organización. El HTML y las peticiones del navegador también pueden mostrar nombres de API, CDN, plataformas de analítica, almacenamiento y proveedores de identidad.

Registra cada señal como hipótesis. Un enlace a Microsoft 365 demuestra una dependencia visible. No demuestra que todo el correo, la identidad y los documentos utilicen el mismo tenant.

Registro del dominio con RDAP

Desde enero de 2025, RDAP es la fuente definitiva para consultar datos de registro de dominios gTLD. Sustituye la salida de texto libre de WHOIS por respuestas JSON, códigos HTTP y referencias explícitas a otros servidores RDAP. También permite consultar direcciones IP y sistemas autónomos mediante el mismo modelo.

Con la CLI oficial de ICANN instalada, el cliente selecciona el servidor adecuado a partir de los registros de bootstrap de IANA. El primer argumento puede ser un dominio, una dirección IP o un número de sistema autónomo:

rdap DOMAIN
rdap TARGET_IP
rdap as64496

rdap DOMAIN consulta el registro del dominio. rdap TARGET_IP obtiene la red que contiene la dirección y las entidades asociadas. El prefijo as indica que 64496 es un ASN, no otro tipo de identificador. La salida predeterminada está pensada para lectura interactiva. -O pretty-json conserva la respuesta estructurada y -p registrar sigue el enlace al registro que mantiene el registrar cuando está disponible:

rdap -O pretty-json DOMAIN > rdap-domain.json
rdap -p registrar DOMAIN

ICANN Lookup ofrece la misma clase de consulta desde el navegador. Según el recurso y la política aplicable, RDAP puede mostrar:

registrar y estado del dominio
fechas de creación, actualización y expiración
nameservers
estado de DNSSEC
contactos públicos o campos redactados

Los datos pueden estar ocultos por políticas de privacidad y varían entre registros. Una ausencia no demuestra que el campo no exista. Conserva la fecha de consulta y la fuente autoritativa indicada por RDAP.

Cuándo aparece todavía WHOIS

whois DOMAIN sigue siendo útil para TLD y registros que aún publican este servicio, para consultar sistemas antiguos o para comparar una respuesta durante una transición:

whois DOMAIN

WHOIS devuelve texto sin un esquema uniforme. El primer servidor puede responder con una referencia a otro servicio y los nombres de campo cambian entre operadores. Por eso, una expresión regular que funciona con un TLD puede perder datos en otro. Conserva la respuesta completa y utiliza RDAP como fuente principal cuando el recurso lo admita.

Certificado presentado por el servicio

Antes de usar fuentes históricas, observa el certificado que entrega el endpoint actual. openssl s_client abre una conexión TLS. -connect FQDN:443 fija el destino y -servername FQDN envía Server Name Indication (SNI), necesario cuando una dirección aloja varios sitios. La segunda orden, openssl x509, analiza el certificado recibido. -noout oculta su codificación y las demás opciones muestran identidad, emisor, fechas y Subject Alternative Names.

La redirección </dev/null cierra la entrada estándar para que la sesión no quede esperando. 2>/dev/null oculta los mensajes de diagnóstico de s_client, pero no la información del certificado que pasa por el pipe:

openssl s_client -connect FQDN:443 -servername FQDN </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Los SAN pueden revelar otros nombres servidos por el mismo certificado. También pueden contener wildcards o nombres ya retirados. Cada candidato debe resolverse y validarse por separado.

Certificate Transparency

Los logs de Certificate Transparency son registros públicos y auditables de certificados emitidos. Sirven para descubrir nombres actuales e históricos, incluso cuando ya no aparecen en el certificado presentado por el sitio.

crt.sh permite consultar esos logs. En el siguiente ejemplo, %25 es el carácter % codificado en una URL y representa el wildcard %.DOMAIN. output=json solicita JSON. curl -s oculta la barra de progreso y jq -r extrae name_value como texto sin comillas JSON:

curl -s "https://crt.sh/?q=%25.DOMAIN&output=json" |
  jq -r '.[].name_value' |
  sort -u

sort -u ordena y elimina líneas duplicadas. Un campo puede contener varios nombres separados por un salto de línea escapado, y los wildcards requieren normalización antes de utilizar la lista como entrada de otra herramienta. Conserva también la fecha de emisión y el identificador del certificado cuando necesites reconstruir la cronología.

Reunir candidatos desde varias fuentes pasivas

subfinder amplía los nombres obtenidos de Certificate Transparency mediante otros proveedores públicos y las APIs configuradas. -d DOMAIN fija el dominio, -silent deja un nombre por línea y -o guarda el resultado:

subfinder -d DOMAIN -silent -o passive-candidates.txt

La cobertura depende de las fuentes disponibles y de sus API keys. Un nombre devuelto puede ser histórico, resolver mediante wildcard o pertenecer a un servicio externo. El archivo es una lista de candidatos, no un inventario validado.

Para conservar procedencia, -json selecciona JSONL y -collect-sources añade las fuentes que devolvieron cada nombre. -rate-limit fija un máximo global de peticiones por segundo. -rate-limits permite límites distintos por proveedor con valores como github=20/m o urlscan=2/s. Las cuotas reales dependen de cada API y de la cuenta utilizada.

-timeout limita en segundos la espera de cada fuente. -max-time limita en minutos el proceso completo. -proxy encamina las peticiones HTTP mediante el proxy indicado. Ese cambio altera dirección de origen, latencia y, en algunos proveedores, resultados regionales:

subfinder -d DOMAIN \
  -json \
  -collect-sources \
  -rate-limit 10 \
  -rate-limits 'github=20/m' \
  -rate-limits 'urlscan=2/s' \
  -timeout 30 \
  -max-time 10 \
  -o passive-candidates.jsonl

El límite global no sustituye las cuotas por proveedor. Si una fuente devuelve errores de autenticación o 429, conserva el error y ajusta solo esa fuente. -all habilita todos los proveedores disponibles y suele aumentar tiempo y fallos por claves ausentes. Una ejecución reproducible registra la configuración efectiva, las fuentes activas y los errores, no solo los nombres aceptados.

Cuando debas revisar el tráfico, añade -proxy http://127.0.0.1:8080 después de preparar la escucha. El fichero de configuración y las variables de entorno pueden contener API keys. No forman parte de la evidencia publicable.

Consultar los registros DNS por tipo

Una consulta ANY no es un inventario fiable. Los servidores pueden devolver una respuesta mínima o rechazarla. Es preferible pedir cada tipo necesario. En dig, +short muestra solo la respuesta y el último argumento indica el tipo de registro:

dig +short DOMAIN A
dig +short DOMAIN AAAA
dig +short DOMAIN MX
dig +short DOMAIN NS
dig +short DOMAIN TXT
dig +short DOMAIN SOA
dig +short DOMAIN CAA

Cada tipo responde una pregunta distinta:

Tipo	Qué aporta	Qué no demuestra por sí solo
`A`	Dirección IPv4 asociada al nombre.	Propiedad de la IP ni servicio activo.
`AAAA`	Dirección IPv6 asociada al nombre.	Que la ruta IPv6 sea alcanzable desde nuestro origen.
`MX`	Hosts y prioridad de recepción de correo.	Que pertenezcan a la organización en lugar de a un proveedor.
`NS`	Nameservers autoritativos de la zona DNS.	Que permitan una transferencia de zona.
`TXT`	SPF, verificaciones y datos publicados por aplicaciones.	Que cada integración siga activa o que un token sea una credencial.
`SOA`	Servidor principal, serial y timers de la zona DNS.	Inventario completo de nombres.
`CAA`	Autoridades autorizadas para emitir certificados.	Lista de certificados ya emitidos.

Los TXT suelen revelar proveedores mediante include, nombres de tenant o verificaciones. Trátalos como relaciones candidatas. Una entrada antigua puede permanecer después de retirar el servicio.

La enumeración de DNS desarrolla la resolución contra un servidor concreto, las respuestas negativas, los wildcards, las transferencias de zona y la validación de listas de candidatos. Esta página conserva la relación entre las fuentes. La referencia de DNS explica la interacción con el servicio.

Resolver y atribuir candidatos

Una lista de nombres solo es útil si se conserva su relación con las direcciones. Para una comprobación pequeña, host FQDN muestra A, AAAA, aliases y, según el nombre, otros datos relevantes:

host FQDN

Después se atribuye cada IP a su RIR, ASN y netblock mediante RDAP. Compara la organización que anuncia la dirección con el servicio observado. Una IP de un CDN, una plataforma SaaS o alojamiento compartido no equivale a infraestructura administrada directamente por la empresa.

Shodan y otros buscadores de servicios aportan banners y puertos observados previamente desde Internet:

shodan host TARGET_IP

El comando necesita la CLI configurada con una API key. Su resultado es histórico y depende de la cobertura del proveedor. Valida los endpoints relevantes desde el punto de observación actual antes de incorporarlos como estado presente.

Convertir datos en un mapa

Para cada nombre conserva:

Campo	Ejemplo de contenido
Nombre	`portal.DOMAIN`
Fuente	SAN actual, CT, DNS, HTML, RDAP o buscador externo.
Primera y última fecha	Fechas observadas en la fuente.
Resolución	A, AAAA, CNAME y resultado negativo cuando sea relevante.
Atribución	ASN, netblock, proveedor y relación estimada con el objetivo.
Validación	TLS, HTTP, escaneo de puertos u otra interacción actual.
Confianza	Confirmado, probable, histórico o pendiente.

La lista resultante alimenta la enumeración de infraestructura y, después de atribuir los objetivos, el flujo de Nmap. Cuando un nombre expone HTTP o HTTPS, continúa por el reconocimiento web.