DNS responde, la aplicacion no: seguir una peticion sin adivinar

El ticket suele llegar con una frase corta: “es DNS”. El navegador no abre la pagina, un microservicio agota su timeout o un pod no consigue hablar con una API. Alguien prueba un nombre, ve un error y la red completa queda sentenciada. El problema es que DNS solo responde una pregunta muy concreta: que direccion corresponde a un nombre. No promete que exista una ruta, que el puerto este escuchando ni que TLS acepte la conversacion.

Para depurar bien conviene resistir el impulso de cambiar cosas. Primero seguimos una peticion en el mismo orden en que la maquina la intenta construir.

El nombre y la direccion

Empiezo desde el cliente que sufre el fallo, no desde mi laptop. En un servidor Linux o dentro del contenedor afectado, pregunto por la resolucion real:

getent ahosts api.interna.example
resolvectl query api.interna.example
dig api.interna.example A +short

getent importa porque pasa por la resolucion que usa la aplicacion y respeta la configuracion local. dig ayuda a mirar DNS de forma directa, pero una respuesta bonita desde tu equipo no demuestra que el pod utilice el mismo resolver o la misma vista interna.

Si el nombre entrega una IP inesperada, ya tenemos una pista. Si entrega la IP correcta, DNS no queda “absuelto” para siempre, pero toca avanzar: la peticion ya tiene destino.

El camino y la escucha

Ahora pregunto si el cliente puede llegar a esa direccion por el puerto que realmente usa la aplicacion:

ip route get 10.20.30.40
nc -vz -w 3 10.20.30.40 443
curl -vk --connect-timeout 3 https://api.interna.example/health

ip route get muestra por que interfaz y con que origen saldra el paquete. nc separa el problema TCP de la conversacion HTTP. curl -v hace visible una capa que muchas veces se confunde con red: el certificado, el SNI, una redireccion o una respuesta del proxy.

Un timeout y un rechazo no significan lo mismo. Un rechazo suele indicar que llegaste a una maquina que no escucha o que rechazo activamente. Un timeout pide mirar rutas, ACL, NetworkPolicy, firewall o un paquete que nunca vuelve.

Cuando hace falta ver el cable

Si la aplicacion y las pruebas simples no bastan, dejo de interpretar mensajes y miro paquetes:

sudo tcpdump -ni any host 10.20.30.40 and port 443
sudo ss -lntp | grep ':443'

Si ves salir SYN y nunca vuelve SYN-ACK, la conversacion se perdio en el trayecto o en el destino. Si el handshake TCP ocurre y despues falla TLS, no arreglaras nada cambiando el registro DNS. La calma aqui no es una filosofia decorativa: es separar capas hasta que una evidencia te diga donde seguir.

Una buena depuracion termina con una explicacion reproducible: el nombre resolvia, el paquete llegaba, pero el proxy presentaba otro certificado; o el pod consultaba otro DNS; o la ruta de retorno estaba cerrada. Esa historia vale mas que haber reiniciado tres servicios hasta que el error desaparecio.

Para estudiar: ip-route(8), ss(8) y la documentacion de DNS de tu resolver son mejores compañeros que una suposicion rapida.