Segui la query DNS salto per salto per trovare la vera sorgente
Un indirizzo di resolver imposto non decide quale sorgente vede il resolver. Segui il client, il forwarder e il server che riceve, e annota il percorso.
Dare a un client un indirizzo di resolver stabilisce dove vengono inviate le query, non quale sorgente il resolver vedrà. Instradamento, inoltro e traduzione hanno ciascuno il proprio turno tra i due estremi. Un manuale operativo per le questioni di sorgente segue la query salto per salto e annota ciò che ogni osservatore ha realmente visto. L'ordine conta, perché un'affermazione fatta prima dell'osservazione è solo un'ipotesi con una formattazione migliore.
Annota la disposizione prima di raccogliere prove
Quattro punti possono dirti qualcosa su una sorgente DNS, e non dicono tutti la stessa cosa. Il kernel del client sa quale sorgente userebbe, un forwarder sa cosa ha inviato a monte, un dispositivo che traduce sa cosa ha riscritto, e il resolver che riceve sa cosa è arrivato. Annota quali di questi puoi realmente raggiungere prima di raccogliere qualsiasi cosa.
| 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 |
Annota anche la tua aspettativa, incluso il resolver che credi in uso. Una rotta divisa può inviare una query da tutt'altra parte, e una cache può rispondere senza alcuno scambio a monte, quindi un'ipotesi tenuta solo in memoria non sopravviverà alla prima sorpresa. Tieni il progetto dichiarato e il percorso osservato in colonne separate dello stesso appunto; quando i due non concordano, hai trovato la domanda che vale la pena inseguire.
Verifica quale processo ha realmente inviato la query
Parti dal client: annota l'indirizzo del resolver, il nome interrogato e l'ora, poi conferma quale processo l'ha inviata. La prima riga qui sotto nomina il processo che detiene il socket UDP, ed è il controllo che questa intestazione promette. Se quel processo è un helper del browser o un runtime di container invece del resolver di sistema, il resto della traccia descrive un percorso che nessuno ha chiesto.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Su un host con più interfacce, scopri quale indirizzo di origine il kernel sceglie per quella destinazione prima di guardare altrove. È l'ultimo punto in cui il percorso è interamente sotto il tuo controllo, ed è il valore che confronterai con quello che il resolver riporta. Una discrepanza è il segnale che qualcosa nel mezzo ha riscritto il pacchetto, o che sono state inviate due query diverse.
Tieni i nomi di test interni, perché un nome interno inviato a un resolver pubblico non prova nulla sul percorso interno e pubblica un nome che non avevi bisogno di pubblicare. Un browser con DNS sicuro attivo non comparirà affatto in quell'elenco di socket, e quell'assenza è essa stessa la risposta.
Il forwarder effettua una seconda query, separata
Un forwarder trasforma uno scambio in due. La richiesta a valle arriva, e il forwarder invia poi la propria query a monte da un indirizzo che sceglie. La sua configurazione, non il client, decide ciò che il resolver a monte vede.
Il manuale di dnsmasq vale la pena di essere letto per questo motivo: documenta come un forwarder seleziona i server a monte e collega il proprio lato in ascolto, e nulla in quella disposizione trasporta la sorgente del client a monte. Un log del resolver che mostra un indirizzo di gateway è quindi normale e non la prova di un guasto. L'assenza è altrettanto facile da fraintendere, perché un successo di cache non produce alcuna query a monte e appare identico a una query che non è mai arrivata. Leggi la configurazione del forwarder e lo stato della sua cache prima di trarre l'una o l'altra conclusione. Due domande, due punti da guardare.
Leggi la sorgente sul resolver che riceve
L'unica osservazione che risolve la questione viene presa lato server. Tutto ciò che si deduce dall'elenco delle interfacce del client resta un'ipotesi finché il resolver non riporta ciò che è realmente arrivato.
tcpdump -ni any port 53 and host 10.20.30.53Cattura sull'host del resolver, mantieni la cattura breve e circoscritta, e conservala dove la politica lo consente. Se la sorgente osservata è un indirizzo tradotto, la domanda successiva è quale dispositivo ha eseguito la traduzione e se la sua politica è quella prevista. Una cattura risponde a ciò che è arrivato; non spiega perché la politica lo abbia permesso. Nomina l'osservatore e il salto nell'appunto, perché un'affermazione sulla privacy relativa a un gateway riguarda quel salto e non l'intero percorso.
Scrivi il risultato come un percorso, non come un indirizzo
Annota il client, il resolver, ogni forwarder, la sorgente osservata a ogni salto e la politica che lo governa. Quel registro risponde alla maggior parte delle domande future senza un'altra cattura. Disegnalo come una catena, perché un elenco di indirizzi nasconde quale salto abbia prodotto quale.
Allega la data, la versione del client e la revisione della configurazione al disegno, così un lettore successivo possa dire se vale ancora. Separa la sorgente di trasporto da tutto il resto che il servizio elabora, perché vedere un indirizzo di gateway non dice nulla su cos'altro venga conservato. Anche la posizione di un resolver non dice nulla su quale client abbia interrogato. Tenere separate queste affermazioni è ciò che rende la conclusione difendibile in sede di revisione.