Sigue la consulta DNS salto a salto para encontrar la fuente real
Una dirección de resolutor impuesta no decide qué fuente ve el resolutor. Sigue al cliente, al reenviador y al servidor que recibe, y anota el camino.
Dar a un cliente una dirección de resolutor fija dónde se envían las consultas, no qué fuente verá el resolutor. El enrutamiento, el reenvío y la traducción tienen cada uno su turno entre los dos extremos. Un manual de procedimiento para cuestiones de fuente sigue la consulta salto a salto y anota qué vio realmente cada observador. El orden importa, porque una afirmación hecha antes de la observación no es más que una suposición con mejor formato.
Anota la disposición antes de recoger pruebas
Cuatro lugares pueden decirte algo sobre una fuente DNS, y no todos dicen lo mismo. El núcleo del cliente sabe qué fuente usaría, un reenviador sabe qué envió aguas arriba, un dispositivo que traduce sabe qué reescribió y el resolutor que recibe sabe qué llegó. Anota cuáles de esos puedes alcanzar realmente antes de recoger nada.
| Observation point | What it can prove | What it cannot prove | How to read it |
|---|---|---|---|
| client kernel | which source address it would use for that resolver | anything a device in between rewrote | ip route get against the resolver address |
| forwarder | that it sent an upstream query, and from which source | what the client originally asked for | its own log and its cache state |
| translating device | that a source was rewritten, and to what | whether the query was legitimate | NAT policy and its counters |
| receiving resolver | the address that actually arrived | which client behind that address asked | a scoped capture on port 53 |
Anota también tu expectativa, incluido el resolutor que crees que está en uso. Una ruta dividida puede enviar una consulta a un lugar completamente distinto, y una caché puede responder sin ningún intercambio aguas arriba, así que una suposición que solo se guarda en la memoria no sobrevivirá a la primera sorpresa. Mantén el diseño declarado y el camino observado en columnas separadas de la misma nota; cuando los dos discrepen, has encontrado la pregunta que merece la pena perseguir.
Comprueba qué proceso envió realmente la consulta
Empieza por el cliente: anota la dirección del resolutor, el nombre consultado y la hora, y después confirma qué proceso la envió. La primera línea de abajo nombra el proceso que tiene el socket UDP, y esa es la comprobación que promete este encabezado. Si ese proceso es un asistente del navegador o un entorno de ejecución de contenedores en lugar del resolutor del sistema, el resto del rastro describe un camino que nadie pidió.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53En un equipo con varias interfaces, averigua qué dirección de origen elige el núcleo para ese destino antes de mirar en otro sitio. Es el último punto donde el camino está completamente bajo tu control, y es el valor que compararás con lo que informa el resolutor. Una discrepancia es la señal de que algo entremedias reescribió el paquete, o de que se enviaron dos consultas distintas.
Mantén los nombres de prueba internos, porque un nombre interno enviado a un resolutor público no demuestra nada sobre el camino interno y publica un nombre que no necesitabas publicar. Un navegador con DNS seguro activado no aparecerá en absoluto en esa lista de sockets, y esa ausencia es ella misma la respuesta.
El reenviador hace una segunda consulta, separada
Un reenviador convierte un intercambio en dos. La petición descendente llega, y entonces el reenviador envía su propia consulta aguas arriba desde una dirección que elige. Su configuración, no el cliente, decide qué ve el resolutor aguas arriba.
El manual de dnsmasq merece leerse por ese motivo: documenta cómo un reenviador elige servidores aguas arriba y liga su lado de escucha, y nada en esa disposición lleva la fuente del cliente aguas arriba. Un registro de resolutor que muestra una dirección de pasarela es, por tanto, normal y no una prueba de fallo. La ausencia es igual de fácil de malinterpretar, porque un acierto de caché no produce ninguna consulta aguas arriba y parece idéntico a una consulta que nunca llegó. Lee la configuración del reenviador y el estado de su caché antes de sacar cualquiera de las dos conclusiones. Dos preguntas, dos lugares donde mirar.
Lee la fuente en el resolutor que recibe
La única observación que resuelve esto se toma en el lado del servidor. Todo lo que se infiere de la lista de interfaces del cliente sigue siendo una hipótesis hasta que el resolutor informa de qué llegó realmente.
tcpdump -ni any port 53 and host 10.20.30.53Captura en el equipo del resolutor, mantén la captura corta y limitada, y guárdala donde la política lo permita. Si la fuente observada es una dirección traducida, la siguiente pregunta es qué dispositivo hizo la traducción y si su política es la prevista. Una captura responde qué llegó; no explica por qué la política lo permitió. Nombra al observador y el salto en la nota, porque una afirmación de privacidad sobre una pasarela es una afirmación sobre ese salto y no sobre todo el camino.
Escribe el hallazgo como un camino, no como una dirección
Anota el cliente, el resolutor, cualquier reenviador, la fuente observada en cada salto y la política que lo rige. Ese registro responde a la mayoría de las preguntas futuras sin otra captura. Dibújalo como una cadena, porque una lista de direcciones oculta qué salto produjo cuál.
Adjunta la fecha, la versión del cliente y la revisión de la configuración al dibujo, para que un lector posterior pueda decir si sigue vigente. Separa la fuente de transporte de todo lo demás que procesa el servicio, porque ver una dirección de pasarela no dice nada sobre qué más se conserva. La ubicación de un resolutor tampoco dice nada sobre qué cliente preguntó. Mantener esas afirmaciones separadas es lo que hace la conclusión defendible en una revisión.