Bloque 1 — Entender DNS antes de capturarlo

1.1 ¿Qué es DNS?

DNS, Domain Name System, es un sistema distribuido y jerárquico que permite asociar nombres con información.

Su función más conocida es relacionar nombres fáciles de recordar con direcciones IP:

Sin embargo, DNS hace mucho más. También puede indicar qué servidores reciben correo para un dominio, cuáles son sus servidores autoritativos, si un nombre es alias de otro, almacenar información mediante registros TXT y realizar resolución inversa.

En este curso no intentaremos memorizar toda la arquitectura de DNS. Necesitamos entender lo suficiente para reconocer qué está ocurriendo dentro de una transacción DNS y después relacionarlo con la evidencia que observemos.

1.2 ¿Quién participa en una consulta DNS?

Para entender una resolución DNS utilizaremos primero un modelo simplificado:

Application

Una aplicación necesita resolver un nombre. Normalmente no recorre por sí misma la jerarquía DNS; solicita la resolución al sistema operativo.

Stub Resolver

El stub resolver actúa como cliente DNS del host. Construye y envía consultas, espera respuestas y las entrega a la aplicación. Normalmente no recorre por sí mismo toda la jerarquía DNS.

Recursive Resolver

El recursive resolver recibe la consulta y realiza el trabajo necesario para obtener una respuesta completa. Puede responder desde caché o consultar otros servidores DNS.

Desde la perspectiva del cliente, la conversación puede verse así:

Authoritative DNS

Un servidor autoritativo mantiene información de una zona DNS y puede responder con autoridad sobre los nombres que pertenecen a ella.

Recursión e iteración

Para este bloque basta con conservar esta diferencia:

Más adelante podremos observar otra perspectiva de este proceso utilizando dig +trace.

1.3 Jerarquía y nombres DNS

DNS organiza los nombres de forma jerárquica. Por ejemplo:

www.lab.example.com.

puede representarse conceptualmente así:

.
└── com
    └── example
        └── lab
            └── www

El punto superior representa la raíz. Debajo aparecen los dominios de nivel superior o TLD, como com; después dominios y subdominios, hasta llegar al nombre que queremos consultar.

Cada parte separada por puntos se denomina label. El punto final representa explícitamente la raíz y permite escribir el nombre completo como un FQDN — Fully Qualified Domain Name.

www.lab.example.com.

Muchas herramientas omiten visualmente el punto final, aunque conceptualmente la raíz sigue formando parte del nombre.

1.4 Tipos de registros DNS

DNS puede asociar un nombre con diferentes tipos de información. Esa información se representa mediante Resource Records.

Por ejemplo, podemos preguntar por una dirección IPv4:

example.com.    IN    A

o por una dirección IPv6:

example.com.    IN    AAAA

También podemos encontrar un alias:

www.example.com.    IN    CNAME    web.example.net.

1.5 Anatomía de una consulta DNS

Una consulta DNS contiene tres elementos que nos interesa reconocer desde el principio:

QNAME identifica el nombre consultado, QTYPE el tipo de registro solicitado y QCLASS la clase, normalmente IN para Internet.

Por ejemplo:

www.example.com  A
www.example.com  AAAA

No son consultas equivalentes. El nombre es el mismo, pero el tipo de información solicitada cambia.

Podemos representar una consulta de forma compacta como:

www.example.com / A / IN

1.6 Límites y propiedades medibles de un nombre DNS

Hasta ahora hemos tratado un nombre DNS principalmente como texto:

www.example.com

Sin embargo, cuando un nombre viaja dentro de un mensaje DNS no se transmite simplemente como una cadena de texto con puntos. DNS representa el nombre como una secuencia de labels.

www | example | com | root

Cada label tiene una longitud y DNS incluye esa información dentro del mensaje. Conceptualmente:

3 www
7 example
3 com
0

El 3 indica que el siguiente label contiene tres octetos; el 7 corresponde a example; el siguiente 3 a com; y el valor 0 representa el final del nombre, es decir, el root label.

Por eso los puntos que utilizamos al escribir www.example.com. son una representación legible de la separación entre labels; los puntos no se transmiten literalmente como parte de cada label en el wire format DNS.

El límite de un label

Un label DNS puede contener como máximo:

En la representación tradicional de un nombre DNS, el campo que indica la longitud de un label utiliza un octeto, pero los dos bits más significativos están reservados para mecanismos como name compression. Esto deja seis bits para representar la longitud:

00111111 = 63

De ahí proviene el límite máximo de 63 octetos por label.

El límite del nombre completo

La representación de un nombre DNS completo no puede superar:

incluyendo la información utilizada para representar las longitudes de los labels y el root label.

LABEL ≤ 63 octetos
FULL DNS NAME ≤ 255 octetos

Un nombre puede contener varios labels perfectamente válidos individualmente y, aun así, acercarse al límite total del nombre.

¿Por qué nos importan estos límites?

Porque convierten un nombre DNS en algo que podemos medir. Más adelante podremos preguntarnos:

• ¿Cuánto mide el nombre?
• ¿Cuántos labels contiene?
• ¿Cuánto mide cada label?
• ¿Qué caracteres aparecen?
• ¿Cuánto cambian los labels entre consultas?
• ¿Con qué frecuencia aparecen nombres similares?

Comparemos:

api.example.com
a8f92bd71c04e98a.example.com
4f8a9c2d7e1b6a3f8c0d2e5f7a9b1c3d.example.com

Los tres podrían ser nombres DNS válidos, pero presentan propiedades diferentes.

Esto será importante más adelante cuando analicemos patrones relacionados con DGA, tunneling, exfiltración u otros comportamientos DNS.

Un label largo no demuestra exfiltración. Un nombre aparentemente aleatorio no demuestra un DGA. Muchos subdominios diferentes no demuestran tunneling. Son características observables que adquieren significado cuando las combinamos con otras evidencias.

1.7 Tamaño, transporte y EDNS

DNS fue diseñado originalmente para realizar muchas de sus transacciones utilizando UDP puerto 53.

Client                    DNS Server
   |                           |
   |------ DNS Query --------->|
   |                           |
   |<----- DNS Response -------|
   |                           |

Para muchas consultas, UDP resulta adecuado porque permite realizar este intercambio sin establecer previamente una conexión. Pero DNS no está limitado a UDP; también puede utilizar TCP/53.

El límite tradicional de 512 bytes

El DNS original establecía para los mensajes transportados mediante UDP un tamaño máximo de:

Con la evolución de DNS, ese límite podía resultar demasiado restrictivo. DNS incorporó un mecanismo para extender sus capacidades: EDNS — Extension Mechanisms for DNS.

¿Qué es EDNS?

EDNS permite extender DNS sin reemplazar el protocolo DNS original.

Una de las capacidades más importantes para nosotros es que el cliente puede comunicar al servidor el tamaño máximo de respuesta UDP que está preparado para recibir. Que anuncie un tamaño superior a 512 bytes no significa que la respuesta tendrá necesariamente ese tamaño.

El pseudo-record OPT

EDNS introduce un elemento especial denominado OPT.

Aunque OPT aparece junto con la estructura de Resource Records, no representa un registro DNS tradicional almacenado en una zona, como A, AAAA, MX o TXT. Funciona como un mecanismo para transportar información relacionada con EDNS.

Additional records
    ↓
OPT
    ↓
UDP payload size

No necesitamos aprender todavía todos los campos de OPT. Lo importante es reconocer qué función cumple.

¿Entonces EDNS elimina TCP?

No. EDNS permite realizar mediante UDP intercambios que pueden superar el límite tradicional de 512 bytes, pero eso no significa que TCP deje de utilizarse.

DNS Query
    ↓
UDP
    ↓
¿La respuesta puede entregarse adecuadamente?
        │
     ┌──┴──┐
     │     │
    Sí     No
     │     │
     ↓     ↓
Response   puede requerirse
via UDP    otro comportamiento,
           incluido TCP

DNS ≠ solamente UDP
EDNS ≠ TCP

El bit TC: Truncated

Una respuesta DNS contiene flags. Entre ellos se encuentra TC = Truncated.

Si una respuesta no puede entregarse completamente en las condiciones del intercambio UDP, el servidor puede indicar que la respuesta fue truncada. Esto puede conducir a que el cliente vuelva a realizar la consulta utilizando TCP.

Query via UDP
      ↓
DNS Server
      ↓
Response
TC = 1
      ↓
"La respuesta está truncada"

EDNS cambia lo que esperamos observar

En DNS moderno sería incorrecto concluir que una respuesta UDP superior a 512 bytes “no debería ocurrir”. Primero deberíamos preguntarnos:

• ¿Hay EDNS?
• ¿Qué UDP payload size fue anunciado?
• ¿Cuánto mide realmente la respuesta?
• ¿Existe truncation?
• ¿Aparece posteriormente TCP?

El tamaño también es evidencia

Comparemos:

Query:      74 bytes
Response:   98 bytes

con:

Query:      74 bytes
Response: 1250 bytes

Ambas transacciones podrían ser perfectamente legítimas, pero existe una diferencia observable:

En el segundo caso existe una mayor asimetría entre el tamaño de la consulta y el de la respuesta. Eso tampoco demuestra por sí mismo un ataque.

Más adelante será especialmente útil cuando estudiemos DNS Amplification:

Una respuesta DNS grande no significa automáticamente amplification. EDNS, DNSSEC, determinados tipos de consulta y otras características del DNS moderno pueden producir respuestas mayores.

1.8 dig: generar tráfico DNS controlado

Hasta ahora hemos estudiado DNS desde el punto de vista conceptual. Ahora necesitamos una forma de generar consultas DNS de manera controlada.

Para ello utilizaremos dig, abreviatura de Domain Information Groper.

dig example.com A

Conceptualmente estamos solicitando:

QNAME  = example.com
QTYPE  = A
QCLASS = IN

dig no es el Stub Resolver

Cuando una aplicación utiliza los mecanismos normales de resolución del sistema operativo puede interactuar con el Stub Resolver. dig, en cambio, puede generar directamente sus propias consultas DNS.

Application → Stub Resolver

dig → DNS Query

Esta característica lo convierte en una herramienta especialmente útil para troubleshooting: podemos controlar qué preguntamos y a quién se lo preguntamos.

Consultar el resolver configurado

dig example.com A

dig utilizará normalmente el servidor DNS configurado para la consulta.

Consultar un servidor específico

dig @1.1.1.1 example.com A

Ahora hemos controlado dos variables:

WHAT  → example.com / A
WHERE → 1.1.1.1

Esto permite comparar el comportamiento de distintos resolvers planteando esencialmente la misma pregunta.

Observar la resolución desde otra perspectiva

dig +trace example.com

+trace permite observar consultas sucesivas siguiendo la jerarquía DNS:

No necesitamos analizar todavía todos los detalles de +trace. Lo importante es reconocer que dig puede mostrarnos diferentes perspectivas de una resolución DNS.

dig como generador de tráfico

En este curso dig tendrá otra función importante: generar tráfico DNS conocido.

dig @1.1.1.1 example.com A

Sabemos de antemano quién generó la consulta, qué nombre consultamos, qué tipo solicitamos, a qué servidor la enviamos y cuándo ejecutamos la prueba.

1.9 Cómo leer una respuesta de dig

Ejecutemos:

dig @1.1.1.1 example.com A

Para troubleshooting podemos comenzar concentrándonos en cinco elementos:

QUESTION — ¿Qué preguntamos?

;; QUESTION SECTION:
;example.com.        IN      A

QNAME  → example.com
QCLASS → IN
QTYPE  → A

ANSWER — ¿Qué recibimos?

;; ANSWER SECTION:
example.com.    300    IN    A    192.0.2.10

NAME          TTL    CLASS   TYPE   DATA
example.com   300    IN      A      192.0.2.10

La existencia o ausencia de una ANSWER SECTION no debe ser nuestra única forma de decidir si una transacción DNS funcionó.

STATUS — ¿Cuál fue el resultado DNS?

status: NOERROR

DNS puede producir otros resultados, por ejemplo:

NOERROR
NXDOMAIN
SERVFAIL
REFUSED

Por ahora no necesitamos estudiarlos en profundidad. Lo importante es entender:

ANSWER ≠ STATUS
DNS RESPONSE ≠ SUCCESSFUL ANSWER

SERVER — ¿Quién respondió?

;; SERVER: 1.1.1.1#53

Durante troubleshooting no debemos asumir qué servidor respondió: lo verificamos.

QUERY TIME — ¿Cuánto tardó?

;; Query time: 24 msec

Por ahora no estableceremos un número universal para decidir cuándo DNS es “lento”. La latencia depende del contexto.

Más adelante aprenderemos a observar esa dimensión temporal directamente entre paquetes DNS.

Leer evidencia, no sólo resultados

1.10 TTL

TTL — Time To Live indica durante cuánto tiempo determinada información DNS puede permanecer almacenada en caché antes de que deba considerarse expirada.

example.com.    300    IN    A    192.0.2.10

El valor 300 representa un TTL de 300 segundos.

¿Por qué existe el TTL?

Los resolvers no necesitan consultar continuamente a los servidores autoritativos por información que acaban de obtener. Pueden almacenarla temporalmente, reduciendo consultas innecesarias, carga y latencia.

El TTL que observamos puede cambiar

Si un resolver almacena una respuesta con TTL = 300, consultas posteriores podrían mostrar valores como:

300 → 247 → 183 → ... → 0

Eso no significa necesariamente que el servidor autoritativo esté cambiando continuamente el TTL. Podemos estar observando el tiempo restante de una respuesta almacenada en caché.

Dos consultas correctas no tienen que verse idénticas

Dos consultas correctas pueden mostrar diferencias en TTL, Query Time, orden de algunas respuestas o servidor observado, dependiendo del resolver, caché, infraestructura y momento de la consulta.

TTL como evidencia

No vamos a interpretar todavía un TTL bajo, alto o cambiante como indicador de seguridad. Eso requerirá contexto adicional y lo estudiaremos más adelante.

1.11 Nuestro modelo de análisis DNS

Durante troubleshooting necesitamos una forma consistente de organizar la evidencia. Utilizaremos este modelo durante el resto del curso:

No es un estándar del protocolo DNS ni una metodología formal definida por un RFC. Es nuestro modelo de investigación.

Su propósito es evitar una de las fallas más comunes durante troubleshooting: llegar demasiado pronto a una conclusión.

En lugar de comenzar preguntando “¿Cuál es el problema?”, comenzamos preguntando: “¿Qué puedo demostrar con la evidencia que tengo?”

WHO — ¿Quién hizo la consulta?

Primero identificamos el origen: workstation, servidor, aplicación, endpoint o resolver. En una captura, WHO estará relacionado con la dirección IP que origina el paquete.

Una consulta observada desde un cliente y una observada desde un recursive resolver pueden pertenecer al mismo proceso de resolución y, sin embargo, representar conversaciones diferentes.

WHAT — ¿Qué está preguntando?

Reutilizamos la anatomía de DNS:

QNAME
QTYPE
QCLASS

Queremos poder afirmar algo preciso, por ejemplo: “Este cliente está solicitando un registro A para example.com”.

WHERE — ¿A quién se lo está preguntando?

Identificamos el destino de la consulta:

WHERE?
 ↓
1.1.1.1
UDP/53

Durante troubleshooting no debemos asumir que una aplicación está utilizando el servidor DNS que creemos que debería utilizar. Debemos observarlo.

EXPECTED DNS SERVER
        ↓
        ?
        ↓
OBSERVED DNS SERVER

RESPONSE — ¿Qué respondió?

Necesitamos determinar qué información regresó. En este punto todavía no decidimos si el comportamiento es correcto o incorrecto; primero documentamos qué respondió realmente DNS.

RESULT — ¿Cuál fue el resultado del protocolo?

RESPONSE ≠ RESULT

El hecho de recibir un paquete de respuesta no significa necesariamente que DNS haya producido el resultado esperado. Debemos observar el resultado indicado por el protocolo.

NOERROR
NXDOMAIN
SERVFAIL
REFUSED

“No recibí respuesta” y “recibí una respuesta DNS indicando un error” son condiciones diferentes y requieren investigaciones diferentes.

TIME — ¿Cuánto tardó?

Finalmente incorporamos el tiempo. Con dig obtenemos una primera referencia mediante QUERY TIME.

CORRECT RESPONSE ≠ ACCEPTABLE RESPONSE TIME

Una consulta puede terminar con NOERROR y devolver la información correcta, pero tardar lo suficiente para producir un problema perceptible.

Aplicando el modelo

Supongamos que ejecutamos:

dig @1.1.1.1 example.com A

Ahora ya no tenemos simplemente “DNS funciona”. Tenemos una descripción reproducible de qué ocurrió.

De observación a hipótesis

Nuestro modelo organiza la evidencia; después podemos formular una hipótesis que todavía debe validarse.

OBSERVATION
RESULT = NOERROR
TIME = unusually high
        ↓
HYPOTHESIS
DNS responde correctamente,
pero existe un problema de latencia.

Referencias

• Albitz, P., & Liu, C. (2006). DNS and BIND (5th ed.). O'Reilly Media.
  Utilizado como referencia para distinguir el papel del resolver, el stub resolver y los servidores DNS que participan en el proceso de resolución.
• Mockapetris, P. (1987). RFC 1034 — Domain Names: Concepts and Facilities.
  RFC 1034 — RFC Editor
• Mockapetris, P. (1987). RFC 1035 — Domain Names: Implementation and Specification.
  Referencia utilizada para la estructura del mensaje DNS, Question Section, QNAME, QTYPE, QCLASS y límites del protocolo.
  RFC 1035 — RFC Editor
• Damas, J., Graff, M., & Vixie, P. (2013). RFC 6891 — Extension Mechanisms for DNS (EDNS(0)).
  RFC 6891 — RFC Editor
• Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., & Wessels, D. (2016). RFC 7766 — DNS Transport over TCP — Implementation Requirements.
  RFC 7766 — RFC Editor
• Farnham, G. Detecting DNS Tunneling. SANS Institute / GIAC. Utilizado como referencia para la relación entre DNS, longitud de nombres, registros, caching y análisis posterior de comportamiento.