DNS: resolución, registros y defensa

Casi todo lo que hace una aplicación empieza con una pregunta de DNS: “¿qué IP tiene api.citas.app?”. Es la agenda de contactos de Internet, y como casi nunca se bloquea, es también una de las vías favoritas para sacar datos de una red sin que salte una alarma. Entender cómo se resuelve un nombre te sirve para dos cosas: diagnosticar fallos (“no es la app, es el DNS”) y detectar abusos.

Cómo se resuelve un nombre#

El DNS es una base de datos jerárquica y distribuida. Ningún servidor conoce todo; cada uno sabe a quién preguntar en el siguiente nivel. Cuando pides un nombre, tu resolver hace el trabajo por ti de forma recursiva, consultando iterativamente a cada nivel de la jerarquía.

Resolución DNS y exfiltración bloqueada

Redes · DNS

Paso 1 de 6La pregunta

El cliente no conoce la IP de www.citas.app. Se la pregunta a su resolver, que se encargará de averiguarla por él (resolución recursiva).

El cliente pregunta a su resolver (en AWS, el Route 53 Resolver de la VPC, en la .2 de tu rango). Si no lo tiene en caché, empieza a buscar.
El resolver pregunta a un servidor raíz (.). La raíz no sabe la IP, pero sí quién gestiona el TLD: “pregunta a los servidores de .app”.
El resolver pregunta al servidor del TLD (.app). Tampoco da la IP, pero conoce los servidores autoritativos del dominio: “pregunta a los de citas.app”.
El resolver pregunta al servidor autoritativo, la fuente de la verdad del dominio, que devuelve el registro con la IP.
El resolver cachea la respuesta durante su TTL y se la entrega al cliente.

La diferencia entre recursivo e iterativo es quién persigue la respuesta: el resolver es recursivo hacia el cliente (le devuelve la respuesta final), pero itera hacia la jerarquía (cada servidor le da una referencia, no la respuesta).

Tipos de registro que importan#

Un dominio tiene varios registros, cada uno con un propósito:

Registro	Para qué	Ejemplo
`A`	Nombre → IPv4	`api.citas.app → 198.51.100.24`
`AAAA`	Nombre → IPv6	`api.citas.app → 2001:db8::24`
`CNAME`	Alias de un nombre a otro nombre	`www.citas.app → citas.app`
`MX`	Servidor de correo del dominio	`citas.app → 10 mail.citas.app`
`TXT`	Texto libre: SPF, DKIM, verificaciones	`v=spf1 include:amazonses.com -all`
`NS`	Servidores autoritativos del dominio	`citas.app → ns-1.awsdns.com`

Los registros TXT son especialmente relevantes para seguridad: ahí viven SPF, DKIM y DMARC, que autentican tu correo y evitan la suplantación de tu dominio. Y en AWS, un CNAME que apunta a un recurso que ya borraste (un bucket, una distribución) es la puerta a un subdomain takeover: alguien reclama ese recurso y sirve contenido desde tu subdominio.

Caché y TTL#

Recorrer toda la jerarquía por cada consulta sería lentísimo, así que cada respuesta trae un TTL (time to live): los segundos que puede guardarse en caché. Mientras no expire, el resolver responde sin volver a preguntar.

El TTL es una decisión de ingeniería: uno alto (horas) reduce consultas y latencia pero ralentiza los cambios (una migración o un failover tardan en propagarse); uno bajo (segundos) agiliza los cambios pero multiplica las consultas. Antes de migrar un registro, se baja el TTL con antelación para que el cambio se propague rápido.

El DNS como vector de ataque#

Aquí llega la parte incómoda. Como el puerto 53 casi siempre está permitido de salida, el DNS se convierte en un canal encubierto.

Las señales de este abuso son reconocibles: un volumen anómalo de consultas a un mismo dominio, nombres muy largos y de alta entropía (parecen aleatorios), y muchas respuestas NXDOMAIN. Esas señales solo las ves si registras las consultas.

Defensa: filtrar y registrar el DNS#

En AWS tienes dos controles complementarios, ambos sobre el Route 53 Resolver de la VPC:

Route 53 Resolver DNS Firewall filtra y regula el tráfico DNS saliente de tu VPC. Creas grupos de reglas con listas de dominios y los asocias a la VPC; su uso principal, según la propia documentación de AWS, es prevenir la exfiltración de datos por DNS. Dos estrategias:

Allowlist: denegar todo salvo los dominios que confías explícitamente. Máxima seguridad, más mantenimiento.
Blocklist: permitir todo salvo dominios conocidos como maliciosos (puedes usar las listas gestionadas por AWS).

Cada regla aplica una acción: ALLOW, ALERT (deja pasar y registra) o BLOCK. Al bloquear puedes responder con NODATA, NXDOMAIN o un valor OVERRIDE.

Rule group: egress-citas  →  asociado a la VPC prod
  1  BLOCK  (AWSManagedDomainsMalwareDomainList)  → NXDOMAIN
  2  ALERT  (dominios de alta entropía / DGA)
  3  ALLOW  (resto)

Route 53 Resolver query logging registra cada consulta DNS que hacen los recursos de la VPC: el nombre consultado, el tipo de registro, la respuesta y quién preguntó. Es tu fuente para la detección y la caza de amenazas: sin él, la exfiltración por DNS es invisible.

# Buscar en los logs nombres sospechosamente largos (posible tunneling)
aws logs filter-log-events \
  --log-group-name /aws/route53/vpc-prod \
  --filter-pattern '{ $.query_name = "*" }' \
  --start-time 1760140800000 \
  | jq '.events[].message | fromjson | .query_name' \
  | awk '{ if (length($0) > 60) print }'

Combínalo con GuardDuty, que tiene detecciones específicas de DNS (Trojan:EC2/DNSDataExfiltration) usando estos datos.

Tu turno

Resuelve y audita un nombre de tu entorno

Elige un dominio que uses (el de tu empresa, el de un servicio interno) y explóralo con dig. El objetivo es ver la jerarquía y pensar como defensor.

dig +trace api.tudominio.com para ver el recorrido raíz → TLD → autoritativo.
dig TXT tudominio.com: ¿tienes SPF y DMARC configurados? ¿Qué pasaría si no?
Revisa tus CNAME: ¿alguno apunta a un recurso cloud que ya no existe (riesgo de takeover)?
Si gestionas una VPC, ¿registras las consultas DNS? Si la respuesta es no, ese es tu punto ciego.

Reto

¿Por qué una exfiltración por DNS puede funcionar aunque tengas un security group que solo permite salida al puerto 443?

▸Mostrar solución

Porque las instancias no suelen hablar DNS directamente con Internet: preguntan al Route 53 Resolver de la VPC (la .2), y es AWS quien resuelve hacia fuera. El tráfico DNS del atacante viaja dentro de ese canal legítimo del resolver, no como una conexión saliente directa que tu security group pueda ver. Por eso el control adecuado no es un security group, sino el DNS Firewall y el query logging sobre el propio resolver.

En resumen#

El DNS resuelve nombres recorriendo una jerarquía: resolver → raíz → TLD → autoritativo, y cachea la respuesta según su TTL.
Registros clave: A/AAAA (IP), CNAME (alias), MX (correo), TXT (SPF/DKIM/DMARC) y NS (autoritativos).
El DNS es un vector de exfiltración y tunneling: datos codificados en los nombres consultados escapan por el puerto 53, que casi nunca se filtra.
Defiéndete con Route 53 Resolver DNS Firewall (filtra la salida DNS de la VPC, su uso principal es frenar la exfiltración) y query logging (visibilidad para detectar).
Un CNAME colgando hacia un recurso borrado es un riesgo de subdomain takeover.