Segue a consulta DNS salto a salto para atopar a fonte real
Un enderezo de resolutor imposto non decide que fonte ve o resolutor. Segue o cliente, o reenviador e o servidor que recibe, e anota o camiño.
Dar un enderezo de resolutor a un cliente fixa onde se envían as consultas, non que fonte verá o resolutor. O encamiñamento, o reenvío e a tradución teñen cada un a súa quenda entre os dous extremos. Un manual de procedemento para cuestións de fonte segue a consulta salto a salto e anota que viu realmente cada observador. A orde importa, porque unha afirmación feita antes da observación só é unha suposición con mellor formato.
Anota a disposición antes de recoller probas
Catro lugares poden dicirche algo sobre unha fonte DNS, e non todos din o mesmo. O núcleo do cliente sabe que fonte usaría, un reenviador sabe que enviou cara arriba, un dispositivo que traduce sabe que reescribiu, e o resolutor que recibe sabe que chegou. Anota cales deses podes acadar realmente antes de recoller 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 tamén a túa expectativa, incluído o resolutor que cres que está en uso. Unha ruta dividida pode enviar unha consulta a un lugar completamente distinto, e unha caché pode responder sen ningún intercambio cara arriba, así que unha suposición que só se garda na memoria non sobrevivirá á primeira sorpresa. Mantén o deseño declarado e o camiño observado en columnas separadas da mesma nota; cando os dous discrepen, atopaches a pregunta que paga a pena perseguir.
Comproba que proceso enviou realmente a consulta
Comeza polo cliente: anota o enderezo do resolutor, o nome consultado e a hora, e despois confirma que proceso a enviou. A primeira liña de abaixo nomea o proceso que ten o socket UDP, e esa é a comprobación que promete este epígrafe. Se ese proceso é un asistente do navegador ou un contorno de execución de contedores en lugar do resolutor do sistema, o resto do rastro describe un camiño que ninguén pediu.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Nun equipo con varias interfaces, averigua que enderezo de orixe escolle o núcleo para ese destino antes de mirar noutro sitio. É o último punto onde o camiño está completamente baixo o teu control, e é o valor que compararás co que informa o resolutor. Unha discrepancia é o sinal de que algo entremedias reescribiu o paquete, ou de que se enviaron dúas consultas diferentes.
Mantén os nomes de proba internos, porque un nome interno enviado a un resolutor público non demostra nada sobre o camiño interno e publica un nome que non necesitabas publicar. Un navegador con DNS seguro activado non aparecerá nada nesa lista de sockets, e esa ausencia é ela mesma a resposta.
O reenviador fai unha segunda consulta, separada
Un reenviador converte un intercambio en dous. A petición descendente chega, e entón o reenviador envía a súa propia consulta cara arriba desde un enderezo que escolle. A súa configuración, non o cliente, decide que ve o resolutor cara arriba.
O manual de dnsmasq paga a pena lelo por ese motivo: documenta como un reenviador escolle servidores cara arriba e liga o seu lado de escoita, e nada nesa disposición leva a fonte do cliente cara arriba. Un rexistro de resolutor que mostra un enderezo de pasarela é, xa que logo, normal e non unha proba de erro. A ausencia é igual de doada de malinterpretar, porque un acerto de caché non produce ningunha consulta cara arriba e parece idéntico a unha consulta que nunca chegou. Le a configuración do reenviador e o estado da súa caché antes de sacar calquera das dúas conclusións. Dúas preguntas, dous lugares onde mirar.
Le a fonte no resolutor que recibe
A única observación que resolve isto tómase no lado do servidor. Todo o que se infire da lista de interfaces do cliente segue sendo unha hipótese ata que o resolutor informe do que chegou realmente.
tcpdump -ni any port 53 and host 10.20.30.53Captura no equipo do resolutor, mantén a captura curta e limitada, e garda a onde a política o permita. Se a fonte observada é un enderezo traducido, a pregunta seguinte é que dispositivo fixo a tradución e se a súa política é a prevista. Unha captura responde que chegou; non explica por que a política o permitiu. Nomea o observador e o salto na nota, porque unha afirmación de privacidade sobre unha pasarela é unha afirmación sobre ese salto e non sobre todo o camiño.
Escribe o achado como un camiño, non como un enderezo
Anota o cliente, o resolutor, calquera reenviador, a fonte observada en cada salto e a política que o rexe. Ese rexistro responde a maioría das preguntas futuras sen outra captura. Dibúxao como unha cadea, porque unha lista de enderezos agocha que salto produciu cal.
Engade a data, a versión do cliente e a revisión da configuración ao debuxo, para que un lector posterior poida dicir se aínda se aplica. Separa a fonte de transporte de todo o demais que procesa o servizo, porque ver un enderezo de pasarela non di nada sobre que máis se conserva. A ubicación dun resolutor tampouco di nada sobre que cliente preguntou. Manter esas afirmacións separadas é o que fai a conclusión defendible nunha revisión.