Dominios, DNS y certificados

Un dominio crea identidad operativa y una cadena pública de artefactos. El registro, la delegación, las resoluciones y la emisión de certificados pueden observarse antes de que exista tráfico procedente del objetivo.

cuenta del registrador
   -> registro / RDAP
   -> delegación de servidores de nombres
   -> registros de zona y TTL
   -> observaciones de DNS pasivo
   -> emisión del certificado y CT
   -> tráfico de la aplicación
   -> rotación o retirada

No todos los datos son evitables. La decisión OPSEC consiste en conocer qué se publica, cuándo y cómo se correlaciona.

Registra por dominio:

• cuenta y MFA
• registrador y operador del registro
• fecha de creación y renovación
• servidores de nombres
• privacidad disponible
• contactos de abuso
• bloqueo de transferencia
• método de pago y recuperación
• política del proveedor

RDAP y WHOIS pueden exponer fechas, el registrador, estados, servidores de nombres y entidades anonimizadas. La privacidad no oculta la existencia del dominio ni su patrón temporal.

Utiliza un TTL bajo durante la preproducción solo si aceptas más consultas y una propagación más dinámica. Auméntalo cuando la estabilidad sea prioritaria. Una rotación no es inmediata: los resolvers y las aplicaciones conservan caché según el TTL y su propio comportamiento.

edge.example.test. 300 IN A 192.0.2.40
health.example.test. 300 IN A 192.0.2.41

No publiques el team server si el redirector debe ser el único frontal. Limita la resolución interna del upstream a la red o configuración que lo necesite.

Valida desde varios resolvers y desde una posición de red comparable a la del objetivo:

dig +trace edge.example.test A
dig @RESOLVER edge.example.test A
dig @RESOLVER edge.example.test AAAA

Comprueba también respuesta negativa, DNSSEC si se usa y fugas AAAA que envíen clientes por una ruta no filtrada.

Los proveedores de DNS pasivo pueden conservar:

• dominio ↔ IP
• first seen y last seen
• servidores de nombres
• registros históricos
• dominios que compartieron IP

Reutilizar una IP, un servidor de nombres, el SOA, un patrón de subdominio o una ventana de creación conecta campañas. Rotar solo el nombre de host no elimina el historial.

Decide:

• CA pública, privada o certificado del proveedor
• SAN exactos
• wildcard o nombres individuales
• algoritmo y tamaño de clave
• almacenamiento y acceso a la clave
• renovación
• distribución a redirectors
• revocación y retirada

ACME automatiza emisión, pero el challenge deja interacciones DNS o HTTP. Una CA pública registra certificados en Certificate Transparency. Un wildcard oculta subdominios concretos en CT, pero publica el wildcard y la organización puede quedar correlacionada por otros campos.

Consulta CT antes y después de emitir. Valida el certificado servido, no solo el archivo:

openssl s_client -connect edge.example.test:443 \
  -servername edge.example.test -showcerts </dev/null

El frontal puede seguir sirviendo un certificado anterior debido a una caché, un balanceador o un nodo olvidado.

El proveedor observa la cuenta, la API, la región, la imagen, la IP, el volumen, las instantáneas, la consola y el tráfico agregado. Puede aplicar políticas de abuso, reputación o suspensión. Mantén una consola de recuperación y no dependas de un único proveedor para retirar los datos.

Una IP recién creada puede tener un historial previo. Comprueba el DNS inverso, las listas de bloqueo relevantes, los servicios expuestos y los dominios históricos. No interpretes la reputación como una propiedad exclusiva de la operación actual.

Para cada FQDN:

1. resolver A y AAAA desde la estación
2. resolver desde el nodo y una posición similar al objetivo
3. comprobar SNI y certificado
4. probar una ruta admitida y otra rechazada
5. revisar que el upstream no sea público
6. verificar los registros y la marca de tiempo
7. simular retirada de DNS o certificado
8. medir recuperación y propagación

• ICANN RDAP
• RFC 9082: RDAP Query Format
• RFC 8555: ACME
• Certificate Transparency