Bloque 3 — Troubleshooting real: RCODE ≠ Root Cause

3.1 Cuando una transacción DNS no se comporta como esperamos

Hasta ahora hemos trabajado con una transacción sencilla:

QUERY → RESPONSE

Pero una captura real puede mostrar situaciones diferentes:

QUERY → NXDOMAIN
QUERY → SERVFAIL
QUERY → NOERROR / 0 Answers
QUERY → ?
QUERY ─────────────→ RESPONSE
       demasiado tiempo

Todas representan comportamientos distintos. Nuestro trabajo no será únicamente reconocerlos, sino investigar qué evidencia tenemos y qué podría explicarlos.

3.2 NXDOMAIN

NXDOMAIN indica que la respuesta DNS contiene RCODE = 3. En Wireshark podemos localizar estas respuestas con:

dns.flags.rcode == 3

Encontrar un NXDOMAIN responde qué respondió DNS, pero no explica todavía por qué ocurrió.

Posibles explicaciones

• el nombre realmente no existe;
• el usuario escribió mal el nombre;
• una aplicación generó un nombre incorrecto;
• existe un problema relacionado con un sufijo de búsqueda;
• algún proceso está generando nombres automáticamente.

Por eso debemos observar la transacción completa antes de formular una hipótesis.

WHO     172.16.20.145
WHAT    host123.example.com / A
WHERE   172.16.20.11
RESULT  NXDOMAIN

Preguntas de troubleshooting

• ¿El nombre consultado es correcto?
• ¿El cliente preguntó al resolver esperado?
• ¿El mismo nombre produce el mismo resultado desde otro resolver?
• ¿La respuesta realmente contiene RCODE 3?
• ¿Existe alguna diferencia entre el nombre esperado y el observado?

NXDOMAIN describe el resultado. El troubleshooting comienza cuando investigamos por qué ese nombre produjo ese resultado.

3.3 SERVFAIL

SERVFAIL corresponde a RCODE = 2. En Wireshark podemos localizar estas respuestas con:

dns.flags.rcode == 2

SERVFAIL no identifica por sí solo la causa. Puede aparecer, por ejemplo, cuando:

• el resolver no logra completar la resolución;
• existe un problema con un servidor autoritativo;
• ocurre un timeout durante la recursión;
• hay un problema de delegación;
• falla una validación DNSSEC.

¿En qué parte del proceso de resolución falló la consulta?

Qué observar

WHO     ¿Quién hizo la consulta?
WHAT    ¿Qué nombre y tipo fueron consultados?
WHERE   ¿Qué resolver respondió?
RESULT  SERVFAIL
TIME    ¿La respuesta llegó inmediatamente o después de una espera?

Un SERVFAIL inmediato y uno que aparece después de varios segundos pueden orientar investigaciones diferentes.

OBSERVATION
Resolver responde SERVFAIL

        ↓

HYPOTHESIS
El resolver recibió la consulta,
pero no pudo completar la resolución

        ↓

VALIDATE
Comparar con otro resolver
Revisar autoritativos
Revisar delegación
Revisar DNSSEC

SERVFAIL nos dice que la resolución falló. El troubleshooting debe descubrir dónde y por qué.

3.4 NODATA

NODATA puede parecer similar a NXDOMAIN, pero representa una situación diferente.

Podemos localizar respuestas de este tipo con:

dns.flags.rcode == 0 && dns.count.answers == 0

Ejemplo

Supongamos que existe:

host.example.com AAAA 2001:db8::10

pero preguntamos:

host.example.com A

El servidor puede responder:

RCODE: NOERROR
Answers: 0

Eso no significa necesariamente que haya un problema. El nombre existe, pero no tiene un registro del tipo solicitado.

Qué debemos preguntar

• ¿El nombre existe?
• ¿Qué QTYPE solicitó el cliente?
• ¿Existe otro tipo de registro para ese nombre?
• ¿La aplicación esperaba A, AAAA u otro tipo?

NODATA no significa que el nombre no exista; significa que no existe información del tipo solicitado.

3.5 Consultas sin respuesta

Una consulta sin respuesta visible en la captura puede localizarse con:

dns.flags.response == 0 && !dns.response_in

Encontrar una Query sin respuesta correlacionada no significa automáticamente que el servidor DNS esté caído.

Posibles explicaciones

• el servidor realmente no respondió;
• hubo pérdida de paquetes;
• un firewall bloqueó la consulta o la respuesta;
• existe un problema de routing;
• la captura dejó fuera parte de la transacción;
• la respuesta tomó una ruta que no estamos capturando.

¿Tenemos evidencia suficiente para afirmar que el servidor no respondió?

Qué observar

WHO       ¿Quién hizo la consulta?
WHAT      ¿Qué nombre y tipo fueron consultados?
WHERE     ¿A qué servidor se envió?
RESPONSE  No existe respuesta correlacionada en la captura
TIME      ¿Cuánto tiempo abarca la captura después de la Query?

OBSERVATION
Query enviada a 172.16.20.11
No existe Response In

        ↓

HYPOTHESIS
La respuesta no llegó al cliente
o no fue observada en este punto de captura

        ↓

VALIDATE
Revisar conectividad
Revisar firewall
Comparar con otra captura
Probar otro resolver

Una consulta sin respuesta es evidencia de una transacción incompleta, no una prueba automática de que el servidor DNS esté caído.

3.6 Slow Responding Name Servers

Una transacción puede producir una respuesta correcta y aun así provocar un problema si tarda demasiado.

QUERY ───────────────────────── RESPONSE
              latency

Para nuestro análisis nos interesa medir cuánto tiempo pasó entre una Query y su Response correspondiente.

Podemos comparar varias transacciones y buscar aquellas que se alejan del comportamiento habitual.

Transaction A   18 ms
Transaction B   24 ms
Transaction C   21 ms
Transaction D   1.8 s

La transacción D merece atención, pero el tiempo por sí solo no identifica la causa.

Posibles explicaciones

• latencia de red;
• resolución recursiva que necesita consultar varios servidores;
• un servidor autoritativo lento;
• retransmisiones;
• pérdida de paquetes;
• problemas de conectividad aguas arriba;
• carga en el resolver.

OBSERVATION
Response correcta
RCODE = NOERROR
TIME = mucho mayor que otras transacciones

        ↓

HYPOTHESIS
Existe un problema de latencia durante la resolución

        ↓

VALIDATE
Comparar otros nombres
Comparar otros resolvers
Revisar dónde aparece la demora
Buscar retransmisiones o pérdida

3.7 Diagnosticar una transacción completa

El último paso es reunir toda la evidencia y construir una hipótesis de troubleshooting.

La investigación comienza organizando la evidencia con el modelo que ya conocemos:

Eso describe qué observamos, pero todavía no explica por qué ocurrió.

OBSERVE

Registrar lo que realmente aparece en la captura, sin interpretar todavía.

Query enviada
No existe Response In

CLASSIFY

Identificar el tipo de comportamiento observado.

NXDOMAIN
SERVFAIL
NODATA
SIN RESPUESTA
RESPUESTA LENTA

HYPOTHESIZE

Proponer una explicación posible. Una hipótesis todavía no es una conclusión.

VALIDATE

Buscar evidencia adicional que confirme o descarte la hipótesis.

• repetir la consulta;
• probar otro resolver;
• comparar con otra captura;
• revisar conectividad o firewall;
• revisar servidores autoritativos;
• comparar tiempos de respuesta.

Ejemplo completo

OBSERVATION
Query: app.example.com / A
Resolver: 172.16.20.11
Response: SERVFAIL
Time: 2.4 s

        ↓

CLASSIFICATION
SERVFAIL + response time high

        ↓

HYPOTHESIS
El resolver recibió la consulta,
pero tuvo dificultades para completar
la resolución aguas arriba

        ↓

VALIDATION
Consultar otro resolver
Revisar servidores autoritativos
Revisar delegación
Revisar conectividad aguas arriba

El objetivo del troubleshooting no es encontrar rápidamente una etiqueta para el problema. Es construir una explicación respaldada por evidencia.

En el Bloque 4 cambiaremos la unidad de análisis: dejaremos de observar únicamente transacciones individuales y comenzaremos a buscar patrones entre muchas transacciones DNS.