Lab 2 — Todo falla, pero no de la misma manera

Objetivo del laboratorio

Comparar distintos comportamientos DNS que desde la perspectiva de un usuario podrían parecer simplemente:

“DNS no funciona”.

Utilizaremos dig y Wireshark para demostrar que errores aparentemente similares pueden producir evidencia completamente distinta.

Durante el laboratorio aplicaremos dos modelos:

WHO → WHAT → WHERE → RESPONSE → RESULT → TIME

OBSERVATION ↓ INTERPRETATION ↓ HYPOTHESIS ↓ NEXT TEST

Antes de comenzar

Necesitarás:

dig instalado;
Wireshark;
conectividad de red;
una interfaz de captura identificada;
permiso para capturar tráfico en tu workstation.

Utilizaremos 192.0.2.1 en uno de los escenarios. Esta dirección pertenece al bloque TEST-NET-1 reservado para documentación y pruebas.

Preparar Wireshark

Inicia una captura en la interfaz desde la que tu equipo tiene conectividad.

Aplica primero este Display Filter:

dns

Mantén la captura activa mientras realizas las pruebas.

Escenario 1 — NXDOMAIN

Nuestro primer escenario será una consulta hacia un nombre que sabemos que no debe existir.

Ejecuta:

dig @1.1.1.1 nombre-inexistente-lab.invalid A

El TLD .invalid está reservado precisamente para nombres que deben considerarse inválidos.

Qué esperamos encontrar

Query ↓ Response ↓ NXDOMAIN

Si quieres aislar únicamente respuestas NXDOMAIN, utiliza:

dns.flags.rcode == 3

Investiga la transacción

Elemento	Tu evidencia
WHO	Source IP del cliente
WHAT	QNAME / QTYPE
WHERE	Resolver consultado
RESPONSE	¿Existe una Response?
RESULT	RCODE
TIME	Tiempo Query ↔ Response

Ahora interpreta la evidencia

Observation	La Query recibió una Response con RCODE NXDOMAIN.
Interpretation	El resolver sí respondió. No estamos observando ausencia de servicio DNS.
Hypothesis	El nombre consultado no existe en la resolución realizada.
Next Test	Validar el nombre o realizar una consulta diferente para comprobar que el resolver continúa funcionando.

NXDOMAIN no significa que DNS esté caído. De hecho, recibir NXDOMAIN demuestra que existió una respuesta DNS.

Escenario 2 — No Response

Ahora realizaremos una prueba completamente diferente.

Ejecuta:

dig @192.0.2.1 example.com A +time=2 +tries=1

¿Qué hacen +time y +tries?

+time=2 limita a 2 segundos el tiempo de espera por intento.
+tries=1 hace que dig realice un solo intento.

Las utilizamos para que una prueba diseñada para no recibir respuesta termine rápidamente.

En este caso estamos enviando la consulta hacia una dirección reservada para documentación y no esperamos obtener una respuesta DNS normal.

Qué buscamos en Wireshark

Localiza la Query correspondiente.

Después busca su Response.

Query ↓ ?

Dependiendo del entorno, podrías observar únicamente la Query DNS o también mensajes de red generados por otros componentes.

Lo importante es no inventar una Response DNS cuando no existe. La ausencia de respuesta también es evidencia.

Analiza

Observation	Se observa una Query DNS, pero no una Response DNS correspondiente.
Interpretation	No tenemos evidencia de que el resolver consultado haya respondido.
Hypothesis	Podría existir un problema de reachability, filtrado, pérdida, servicio o simplemente un destino que no presta DNS.
Next Test	Consultar un resolver conocido y comparar el resultado.

Comparación — NXDOMAIN vs No Response

Ahora compara los dos primeros escenarios.

Evidencia	NXDOMAIN	No Response
Query visible	Sí	Sí
Response visible	Sí	No necesariamente
RCODE	NXDOMAIN	No existe RCODE observable sin Response
El resolver respondió	Sí	No tenemos evidencia de respuesta
Conocemos la Root Cause	No necesariamente	No

Ambos escenarios pueden ser descritos por un usuario como “DNS no funciona”, pero la evidencia es completamente diferente.

Escenario 3 — Cambiar una sola variable

Una técnica básica de troubleshooting consiste en cambiar una sola variable y comparar.

Primero consulta Cloudflare:

dig @1.1.1.1 example.com A

Después consulta Google:

dig @8.8.8.8 example.com A

Hemos mantenido:

Cliente
QNAME
QTYPE

y cambiamos únicamente:

WHERE → Resolver

Compara

	1.1.1.1	8.8.8.8
Response	¿?	¿?
RCODE	¿?	¿?
Answers	¿?	¿?
TTL	¿?	¿?
Time	¿?	¿?

No esperamos necesariamente que uno falle. El objetivo es aprender a comparar evidencia después de modificar una sola variable.

Escenario 4 — UDP vs TCP

Este escenario es opcional si el tiempo del workshop es limitado.

Primero ejecuta una consulta normal:

dig @1.1.1.1 example.com A

Después ejecuta exactamente la misma consulta utilizando TCP:

dig +tcp @1.1.1.1 example.com A

Hemos conservado:

WHO
WHAT
WHERE

y cambiamos:

UDP ↔ TCP

En Wireshark identifica qué transporte utilizó cada transacción y compara:

Response;
Result;
Time.

La pregunta no es cuál transporte es “mejor”. La pregunta es si cambiar una variable modifica el comportamiento.

Desafío final — No adivines

Para una de las transacciones observadas, completa mentalmente o por escrito:

OBSERVATION ↓ INTERPRETATION ↓ HYPOTHESIS ↓ NEXT TEST

Antes de escribir una Root Cause, pregúntate:

¿La evidencia realmente demuestra esa causa o solamente la hace posible?

Resultado esperado

Al terminar este laboratorio deberás poder distinguir claramente entre:

RCODE ≠ Root Cause

y utilizar:

EVIDENCE ↓ HYPOTHESIS ↓ NEXT TEST

como parte de un proceso de troubleshooting reproducible.

Siguiente paso

En este laboratorio analizamos transacciones individuales para comprender por qué un resultado no equivale automáticamente a una causa.

En el Bloque 4 cambiaremos nuevamente la escala del análisis.

Un paquete puede parecer normal. El patrón puede contar otra historia.

EVENT ≠ PATTERN