Bloque 5 — TTL y comportamiento dinámico de DNS

Objetivo del Bloque 5

Ir al laboratorio práctico del Bloque 5 ↓

Analizar cómo cambian las respuestas DNS a lo largo del tiempo y aprender a distinguir entre variación esperada y comportamiento que merece investigación.

Durante este bloque observaremos:

TTL
ROTACIÓN DE RESPUESTAS
MÚLTIPLES IPs
CDN / GeoDNS
TRAFFIC DISTRIBUTION SYSTEMS
FAST FLUX
DIFFERENT ≠ WRONG
DYNAMIC ≠ MALICIOUS

El objetivo será entender qué cambia, con qué frecuencia cambia y por qué podría estar cambiando.

5.1 DNS no siempre responde igual

Es común asumir que una consulta DNS debería producir siempre la misma respuesta. 

example.com
      ↓
93.184.216.34

Pero en muchos entornos modernos esto no ocurre. El mismo nombre puede producir direcciones diferentes en distintos momentos: 

Query 1 → 203.0.113.10
Query 2 → 203.0.113.11
Query 3 → 203.0.113.12

o desde resolvers diferentes:

Resolver A → 203.0.113.10
Resolver B → 198.51.100.20
Resolver C → 192.0.2.30

Esto puede ser completamente legítimo.

¿Por qué puede cambiar una respuesta?

LOAD BALANCING
CDN
GeoDNS
FAILOVER
ANYCAST INFRASTRUCTURE
POLICY-BASED RESPONSES
DIFFERENT ANSWER ≠ DNS FAILURE
DIFFERENT ANSWER ≠ ATTACK

Qué debemos observar

Ejemplo

www.example.com

10:00 → 203.0.113.10
10:01 → 203.0.113.11
10:02 → 203.0.113.10
10:03 → 203.0.113.12

Esto ya muestra comportamiento dinámico. Todavía no sabemos si se trata de una CDN, balanceo, failover, Fast Flux u otro mecanismo. Para distinguirlo necesitamos más evidencia.

La pregunta no es si DNS cambió, sino si el cambio tiene una explicación coherente.

5.2 TTL como evidencia de comportamiento

En el Bloque 1 vimos qué significa TTL. Aquí no volveremos a explicarlo. Ahora lo utilizaremos como una señal para entender cómo cambia DNS. 

example.com
A 203.0.113.10
TTL 300

y después:

example.com
A 203.0.113.11
TTL 300

El cambio de IP puede formar parte de un mecanismo normal de distribución. Pero también podemos encontrar TTL muy bajos o cambios frecuentes que merecen una observación más cuidadosa. 

TTL 60
TTL 45
TTL 30
TTL 20

TTL bajo no significa comportamiento malicioso

Algunos servicios utilizan TTL bajos legítimamente para balanceo, failover rápido, infraestructura cloud, CDN o cambios operativos frecuentes.

LOW TTL ≠ FAST FLUX

Lo importante es la relación

TTL
+
NUMBER OF IPs
+
CHANGE FREQUENCY
+
RESOLVER VARIATION

Por ejemplo:

TTL = 300
2 o 3 IPs conocidas
cambios moderados

puede ser perfectamente normal.

Mientras que:

TTL = 30
decenas de IPs
cambios constantes
gran dispersión

merece una investigación más profunda.

Qué debemos comparar

El TTL no nos dice si un comportamiento es bueno o malo. Nos ayuda a entender la velocidad con la que DNS espera que cambie.

5.3 Múltiples respuestas y rotación

Un mismo nombre DNS puede devolver más de una dirección IP en una sola respuesta. 

www.example.com
A 203.0.113.10
A 203.0.113.11
A 203.0.113.12

Esto puede formar parte de mecanismos normales de distribución de tráfico. También es posible que el orden cambie entre consultas: 

Query 1
203.0.113.10
203.0.113.11
203.0.113.12

Query 2
203.0.113.12
203.0.113.10
203.0.113.11

El conjunto de direcciones puede ser el mismo aunque el orden cambie.

CHANGING ORDER ≠ CHANGING INFRASTRUCTURE

Qué queremos observar

¿Cambió el orden o cambió realmente el conjunto de direcciones?

Rotación frente a cambio

ROTATION
mismas IPs
orden diferente

frente a:

CHANGE
IPs diferentes
conjunto diferente
Múltiples respuestas y rotación son comportamientos normales en DNS moderno. Lo importante es distinguir entre variación del orden y cambio real del conjunto de respuestas.

5.4 CDN, GeoDNS y Traffic Distribution Systems

Una misma consulta DNS puede producir respuestas diferentes dependiendo de desde dónde se realiza o del contexto en el que ocurre.

DNS / TRAFFIC DECISION ↓ WHO? ↓ WHERE? ↓ WHEN? ↓ CONTEXT?

CDN y GeoDNS

Una CDN puede utilizar DNS para dirigir al cliente hacia un recurso cercano o adecuado para su ubicación y condiciones de red. GeoDNS puede utilizar información relacionada con la ubicación del cliente o del resolver para devolver respuestas distintas. 

México → Edge A
Europa → Edge B
Asia   → Edge C

La intención puede ser:

El resolver importa

En muchos casos la respuesta DNS no depende directamente del cliente final, sino del resolver que realiza la consulta hacia la infraestructura autoritativa. 

CLIENT
RESOLVER
LOCATION
TIME
ANSWER
DIFFERENT BY RESOLVER ≠ SUSPICIOUS

Traffic Distribution Systems

Un Traffic Distribution System, o TDS, también decide a dónde dirigir el tráfico. Puede utilizar muchas señales para tomar esa decisión. 

IP / geografía
User-Agent
sistema operativo
idioma
hora
referer
cookie
tipo de dispositivo
reputación de la IP

Conceptualmente:

VISITOR
   ↓
TDS
   ├── Usuario A → Site A
   ├── Usuario B → Site B
   ├── Bot / Scanner → Benign page
   └── Target victim → Payload / malicious site

Un TDS no es necesariamente malicioso. La misma idea tecnológica puede utilizarse para marketing, advertising, campañas o distribución de contenido. Sin embargo, también puede emplearse para seleccionar víctimas u ocultar infraestructura maliciosa.

TRAFFIC DISTRIBUTION ≠ MALICIOUS ACTIVITY

Qué podemos observar desde DNS

No necesariamente veremos el TDS directamente. Lo que podemos encontrar son efectos del sistema: 

MISMO DOMINIO
+
RESPUESTAS DIFERENTES
+
CAMBIOS POR RESOLVER / REGIÓN / TIEMPO
+
DESTINOS DIFERENTES
¿Existe alguna lógica que determine quién recibe cada respuesta?

De distribución a Fast Flux

CDN / GeoDNS
Distribución legítima y relativamente predecible

        ↓

TDS
Distribución condicionada por múltiples variables

        ↓

FAST FLUX
Rotación rápida y distribuida
Para investigar comportamiento dinámico conviene preguntar: ¿qué cambia, para quién cambia y qué parece determinar el cambio?

5.5 Fast Flux

Fast Flux utiliza cambios frecuentes en las direcciones IP asociadas a un dominio para hacer que la infraestructura sea más difícil de identificar, bloquear o retirar. 

example.com
   ↓
10:00 → 203.0.113.10
10:01 → 198.51.100.20
10:02 → 192.0.2.30
10:03 → 203.0.113.77

La característica importante no es que la respuesta cambie una vez, sino la combinación de varias señales. 

MANY IPs
+
FREQUENT CHANGES
+
LOW TTL
+
DISTRIBUTED INFRASTRUCTURE

¿Por qué se utiliza?

En infraestructura maliciosa, Fast Flux puede ayudar a mantener disponible un servicio aunque algunas direcciones IP sean bloqueadas o retiradas. 

DOMAIN
  ├── IP A
  ├── IP B
  ├── IP C
  ├── IP D
  └── IP E

Si una dirección deja de funcionar, otras pueden seguir disponibles. Esto aumenta la resiliencia de la infraestructura.

Qué podemos observar en DNS

LOW TTL ≠ FAST FLUX
MANY IPs ≠ FAST FLUX
RAPID ROTATION ≠ FAST FLUX

CDN vs. Fast Flux

Característica CDN / infraestructura legítima Fast Flux
Múltiples IPs Común Común
TTL bajo Posible Frecuente
Rotación Controlada Muy frecuente
Infraestructura Proveedor reconocible Muy distribuida
Patrón Relativamente consistente Altamente dinámico
Propósito Rendimiento / disponibilidad Evasión / resiliencia

La pregunta correcta

LOW TTL
+
MANY UNIQUE IPs
+
RAPID ROTATION
+
MULTIPLE NETWORKS
+
NO CLEAR CDN PATTERN
Fast Flux no se reconoce por una dirección IP o por un TTL bajo. Se reconoce por un patrón persistente de rotación rápida y distribuida.

5.6 Diferenciar dinámica legítima de comportamiento sospechoso

Muchas características que pueden parecer extrañas también aparecen en infraestructura legítima. 

LOW TTL
MULTIPLE IPs
ROTATION
GEOGRAPHIC VARIATION
DIFFERENT RESPONSES

Por eso, observar una de estas señales no es suficiente. La pregunta correcta es:

¿La dinámica que observamos tiene una explicación coherente con el servicio que estamos analizando?

Comparar contexto, no sólo valores

Dos dominios pueden mostrar TTL bajos y múltiples IPs, pero el contexto puede ser completamente distinto. 

Domain A
TTL 60
Multiple IPs
Frequent rotation

Domain B
TTL 60
Multiple IPs
Frequent rotation

El primero podría pertenecer a una CDN. El segundo podría formar parte de infraestructura Fast Flux. Necesitamos más evidencia para diferenciarlos.

Comparación rápida

Señal CDN / GeoDNS TDS Fast Flux
TTL bajo Posible Posible Frecuente
Múltiples IPs Común Común Común
Rotación Controlada Condicionada Rápida
Geografía Importante Puede influir Puede ser dispersa
Proveedor común Frecuente Variable Puede no existir
Patrón estable Generalmente sí Depende de reglas Menor estabilidad
Intención Rendimiento / disponibilidad Distribución Resiliencia / evasión

La tabla no debe utilizarse como una regla automática. Sirve para formular mejores preguntas.

Qué debemos investigar

¿CUÁNTAS IPs APARECEN? ↓ ¿CON QUÉ FRECUENCIA CAMBIAN? ↓ ¿CUÁNTO DURA EL TTL? ↓ ¿A QUÉ REDES PERTENECEN? ↓ ¿CAMBIA SEGÚN EL RESOLVER? ↓ ¿EXISTE UNA LÓGICA GEOGRÁFICA? ↓ ¿EL PATRÓN ES CONSISTENTE?

La idea más importante

CHANGE + CONTEXT + CONSISTENCY = MEANING
DYNAMIC + UNEXPLAINED = INVESTIGATE

5.7 Integrar el análisis

Durante este bloque vimos que DNS puede cambiar por muchas razones diferentes. El problema no es detectar que algo cambia. El problema es interpretar correctamente ese cambio.

OBSERVE ↓ COMPARE ↓ TRACK CHANGE ↓ CORRELATE ↓ INTERPRET

OBSERVE

Primero identificamos qué está cambiando:

IP addresses
TTL
number of answers
resolver behavior
geographic response

En esta etapa no intentamos explicar todavía el comportamiento.

COMPARE

Después comparamos:

una consulta vs. otra
un resolver vs. otro
un momento vs. otro
una región vs. otra
un cliente vs. otro

La diferencia es una observación. Todavía no es una conclusión.

TRACK CHANGE

Ahora observamos cómo evoluciona el comportamiento:

10:00 → 203.0.113.10
10:01 → 203.0.113.11
10:02 → 203.0.113.10
10:03 → 203.0.113.12

Podemos preguntar:

Aquí dejamos de observar respuestas aisladas y empezamos a entender la dinámica.

CORRELATE

Después combinamos las señales.

LOW TTL
+
MANY IPs
+
RAPID ROTATION

todavía puede corresponder a infraestructura legítima.

Pero si añadimos:

MULTIPLE UNRELATED NETWORKS
+
NO CLEAR GEOGRAPHIC PATTERN
+
CONTINUOUS CHANGE

el comportamiento merece más atención. La correlación evita que una sola característica determine nuestra conclusión.

INTERPRET

Finalmente intentamos explicar el comportamiento.

Consistent with CDN behavior

Consistent with GeoDNS

Possible Traffic Distribution System

Behavior consistent with Fast Flux

Insufficient evidence

Esta última respuesta también es válida. No siempre tendremos suficiente información para determinar la causa.

Ejemplo completo

Supongamos que analizamos:

service.example

y obtenemos:

Resolver A
TTL 300
203.0.113.10
203.0.113.11

Resolver B
TTL 300
198.51.100.20
198.51.100.21

Las respuestas cambian dependiendo del resolver, pero cada conjunto es relativamente estable. 

OBSERVE
Different responses

COMPARE
Different resolvers

TRACK CHANGE
Stable within each resolver

CORRELATE
Geographic variation + stable TTL + related infrastructure

INTERPRET
Behavior consistent with CDN / GeoDNS

Ahora consideremos otro dominio:

unknown.example

TTL 30

10:00 → IP A
10:01 → IP B
10:02 → IP C
10:03 → IP D
10:04 → IP E

y las direcciones pertenecen a redes diferentes.

OBSERVE
Rapid IP changes

COMPARE
Different networks

TRACK CHANGE
Continuous rotation

CORRELATE
Low TTL + many IPs + distributed infrastructure

INTERPRET
Behavior consistent with Fast Flux

La diferencia no surge de una sola señal. Surge del conjunto de evidencia.

El modelo completo del Bloque 5

WHAT CHANGED? ↓ HOW OFTEN? ↓ WHERE? ↓ FOR WHOM? ↓ IS THE CHANGE CONSISTENT? ↓ WHAT EXPLAINS IT?
DIFFERENT ≠ WRONG
DYNAMIC ≠ MALICIOUS
DYNAMIC + UNEXPLAINED = INVESTIGATE
El valor no está en detectar que DNS cambia, sino en entender si ese cambio tiene una explicación coherente.

Laboratorio práctico — Bloque 5

Observa TTL, conjuntos de respuestas y diferencias entre resolvers sin anticipar conclusiones.

← Volver al curso

En esta práctica observarás cómo las respuestas DNS de servicios reales pueden variar. No buscamos un resultado predeterminado: buscamos aprender a describir correctamente lo que la evidencia permite afirmar.

Objetivo

Observar el comportamiento dinámico de DNS y distinguir entre una observación y la interpretación que hacemos de ella.

DYNAMIC DNS BEHAVIOR ≠ MALICIOUS

Durante la práctica utilizaremos dig, Wireshark y, opcionalmente, mediciones desde distintos puntos de Internet.

Parte 1 — Elegir un servicio real

Comienza realizando consultas a varios servicios públicos. 

dig google.com A
dig cloudflare.com A
dig amazon.com A

Observa las respuestas y selecciona uno de los dominios para continuar con la práctica.

No esperamos que un dominio concreto muestre siempre múltiples IP, determinado TTL o cambios entre consultas. Internet puede comportarse de forma diferente según el momento y el punto de observación.

Parte 2 — Mirar más allá de la dirección IP

Para el dominio elegido ejecuta:

dig <dominio> A

Localiza:

  • IP o IPs recibidas;
  • TTL;
  • cantidad de respuestas;
  • Query time;
  • resolver utilizado.
Pregunta: ¿TTL y Query time representan lo mismo?

No. El Query time describe el tiempo observado para completar la consulta. El TTL indica cuánto tiempo puede mantenerse en caché un registro.

Parte 3 — Consultar repetidamente

Sustituye <dominio> por el dominio que elegiste: 

for i in {1..10}; do
  dig <dominio> A +noall +answer
  sleep 5
done

Realizarás diez consultas separadas aproximadamente por cinco segundos.

Registra lo que observas:

Consulta TTL IP / IPs ¿Cambió?
1
2
3
4
5
6
7
8
9
10
¿No cambió ninguna IP?

Eso también es un resultado válido. Diez consultas durante unos segundos constituyen solamente una pequeña ventana de observación.

Parte 4 — Cambiar de resolver

Ahora consulta el mismo dominio utilizando dos resolvers públicos. 

dig @1.1.1.1 <dominio> A
dig @8.8.8.8 <dominio> A

Compara los resultados:

Resolver TTL IP / IPs
1.1.1.1
8.8.8.8
Importante: obtener respuestas diferentes no demuestra por sí mismo GeoDNS ni significa que las consultas se realizaron desde dos ubicaciones geográficas diferentes.
DIFFERENT RESOLVER ≠ DIFFERENT KNOWN LOCATION

Parte 5 — Verlo en Wireshark

Inicia una captura en Wireshark y realiza algunas de las consultas anteriores.

Primero muestra todo el tráfico DNS:

dns

Después muestra solamente las respuestas:

dns.flags.response == 1

Selecciona una respuesta y expande:

Domain Name System
    ↓
Answers
    ↓
Time to live

Compara el TTL que observaste con dig con la información contenida dentro del paquete DNS.

El objetivo es conectar lo que muestra una herramienta de consulta como dig con la estructura del protocolo que Wireshark permite inspeccionar.

Parte 6 — El experimento geográfico

Esta parte es avanzada y opcional.

Podemos utilizar una plataforma de medición distribuida como RIPE Atlas para observar una consulta DNS desde diferentes puntos de Internet.

MEXICO → DNS QUERY
UNITED STATES → DNS QUERY
EUROPE → DNS QUERY
ASIA → DNS QUERY

Después compara:

  • IP recibidas;
  • TTL;
  • cantidad de respuestas;
  • diferencias entre puntos de medición.
Pregunta correcta:

¿Qué diferencias observamos dependiendo del punto de medición?

No debemos asumir que necesariamente encontraremos respuestas diferentes.

Parte 7 — La trampa Fast Flux

Imagina que observas el siguiente comportamiento:

TTL: 60 seconds

T1 → IP A, IP B, IP C
T2 → IP D, IP E, IP F
T3 → IP G, IP H, IP I
¿Es Fast Flux?

Con esta información solamente no podemos afirmarlo.

Antes de formular una hipótesis necesitamos buscar más contexto:

IP DIVERSITY + ASN / NETWORK + GEOGRAPHIC DISTRIBUTION + DOMAIN CONTEXT + HISTORICAL BEHAVIOR + THREAT INTELLIGENCE

Preguntas

  1. ¿Con qué rapidez cambian las direcciones?
  2. ¿Cuántas IP diferentes aparecen?
  3. ¿A qué redes o ASN pertenecen?
  4. ¿La infraestructura parece coherente?
  5. ¿Qué sabemos del dominio?
  6. ¿El comportamiento es nuevo o histórico?
  7. ¿Existen otras señales relacionadas?

Parte 8 — Construye tu interpretación

Completa la siguiente tabla utilizando lo aprendido durante la práctica.

Observación Evidencia ¿Qué puedo afirmar? ¿Qué necesito investigar?
TTL bajo
Varias IP
Respuestas diferentes
Diferentes ASN
Cambio frecuente

El objetivo no es encontrar una respuesta predeterminada, sino distinguir entre lo que observaste y lo que la evidencia realmente permite concluir.

Cierre de la práctica

OBSERVE ↓ MEASURE ↓ COMPARE ↓ ADD CONTEXT ↓ FORM A HYPOTHESIS

No:

SHORT TTL + MANY IPs ↓ ATTACK

DNS legítimo puede ser altamente dinámico. Antes de interpretar un comportamiento como sospechoso necesitamos comprender cómo se comporta la infraestructura legítima.

Idea final:

Una observación nos dice qué ocurrió. El contexto nos ayuda a entender qué podría significar.