Der DNS-Abfrage Hop für Hop folgen, um die echte Quelle zu finden
Eine zugeschobene Resolver-Adresse entscheidet nicht über die Quelle, die der Resolver sieht. Verfolge den Client, den Forwarder und den empfangenden Server und schreibe den Pfad auf.
Einem Client eine Resolver-Adresse zu übergeben legt fest, wohin Abfragen gehen, nicht welche Quelle der Resolver sehen wird. Routing, Weiterleitung und Übersetzung kommen zwischen den beiden Enden jeweils zum Zug. Ein Runbook für Quellenfragen folgt der Abfrage Hop für Hop und hält fest, was jeder Beobachter tatsächlich gesehen hat. Die Reihenfolge zählt, denn eine Behauptung vor der Beobachtung ist nur eine Vermutung mit besserer Formatierung.
Halte die Anordnung fest, bevor du Belege sammelst
Vier Stellen können dir etwas über eine DNS-Quelle sagen, und sie sagen nicht alle dasselbe. Der Client-Kernel weiß, welche Quelle er benutzen würde, ein Forwarder weiß, was er stromaufwärts gesendet hat, ein übersetzendes Gerät weiß, was es umgeschrieben hat, und der empfangende Resolver weiß, was angekommen ist. Schreibe auf, welche davon du tatsächlich erreichen kannst, bevor du irgendetwas sammelst.
| 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 |
Schreibe auch deine Erwartung auf, samt dem Resolver, von dem du glaubst, dass er im Einsatz ist. Eine Split-Route kann eine Abfrage ganz woandershin schicken, und ein Cache kann ohne jeden Upstream-Austausch antworten, deshalb übersteht eine Annahme, die nur im Kopf gehalten wird, die erste Überraschung nicht. Halte den erklärten Entwurf und den beobachteten Pfad in getrennten Spalten derselben Notiz; wenn die beiden nicht übereinstimmen, hast du die Frage gefunden, der es sich nachzugehen lohnt.
Prüfe, welcher Prozess die Abfrage tatsächlich gesendet hat
Beginne beim Client: Notiere die Resolver-Adresse, den Abfragenamen und die Uhrzeit und bestätige dann, welcher Prozess sie gesendet hat. Die erste Zeile unten nennt den Prozess, der den UDP-Socket hält, und das ist die Prüfung, die diese Überschrift verspricht. Ist dieser Prozess ein Browser-Helfer oder eine Container-Runtime statt des System-Resolvers, beschreibt der Rest der Spur einen Pfad, nach dem niemand gefragt hat.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Ermittle auf einem Host mit mehreren Schnittstellen zuerst, welche Quelladresse der Kernel für dieses Ziel wählt, bevor du woanders hinschaust. Das ist der letzte Punkt, an dem der Pfad vollständig unter deiner Kontrolle ist, und es ist der Wert, den du mit dem vergleichst, was der Resolver meldet. Eine Abweichung ist das Signal dafür, dass etwas dazwischen das Paket umgeschrieben hat oder dass zwei verschiedene Abfragen gesendet wurden.
Halte die Testnamen intern, denn ein interner Name, der an einen öffentlichen Resolver geht, beweist nichts über den internen Pfad und veröffentlicht einen Namen, den du nicht veröffentlichen musstest. Ein Browser mit aktiviertem sicheren DNS taucht in dieser Socket-Liste überhaupt nicht auf, und dieses Fehlen ist selbst die Antwort.
Der Forwarder stellt eine zweite, eigene Abfrage
Ein Forwarder macht aus einem Austausch zwei. Die Downstream-Anfrage kommt an, und der Forwarder sendet dann seine eigene Abfrage von einer Adresse stromaufwärts, die er wählt. Seine Konfiguration, nicht der Client, entscheidet, was der Upstream-Resolver sieht.
Das dnsmasq-Handbuch lohnt aus diesem Grund die Lektüre: Es dokumentiert, wie ein Forwarder Upstream-Server auswählt und seine Lauscheseite bindet, und nichts an dieser Anordnung trägt die Client-Quelle stromaufwärts. Ein Resolver-Log, das eine Gateway-Adresse zeigt, ist daher normal und kein Beleg für einen Fehler. Abwesenheit lässt sich genauso leicht falsch lesen, denn ein Cache-Treffer erzeugt keine Upstream-Abfrage und sieht genauso aus wie eine Abfrage, die nie ankam. Lies die Forwarder-Konfiguration und ihren Cache-Zustand, bevor du eine der beiden Schlussfolgerungen ziehst. Zwei Fragen, zwei Stellen zum Nachsehen.
Lies die Quelle am empfangenden Resolver
Die einzige Beobachtung, die das klärt, wird auf der Serverseite gemacht. Alles, was aus der Schnittstellenliste des Clients geschlossen wird, bleibt eine Hypothese, bis der Resolver meldet, was tatsächlich angekommen ist.
tcpdump -ni any port 53 and host 10.20.30.53Erfasse auf dem Resolver-Host, halte die Erfassung kurz und begrenzt und speichere sie dort, wo die Richtlinie es erlaubt. Ist die beobachtete Quelle eine übersetzte Adresse, lautet die nächste Frage, welches Gerät die Übersetzung vorgenommen hat und ob seine Richtlinie die beabsichtigte ist. Eine Erfassung beantwortet, was angekommen ist; sie erklärt nicht, warum die Richtlinie es zugelassen hat. Nenne den Beobachter und den Hop in der Notiz, denn eine Datenschutzaussage über ein Gateway ist eine Aussage über diesen Hop und nicht über den ganzen Pfad.
Schreibe den Befund als Pfad, nicht als Adresse
Notiere den Client, den Resolver, jeden Forwarder, die beobachtete Quelle an jedem Hop und die Richtlinie, die ihn regelt. Diese Aufzeichnung beantwortet die meisten künftigen Fragen ohne eine weitere Erfassung. Zeichne sie als Kette, denn eine Liste von Adressen verbirgt, welcher Hop welche hervorgebracht hat.
Hänge Datum, Client-Version und Konfigurationsstand an die Zeichnung, damit ein späterer Leser erkennen kann, ob sie noch gilt. Trenne die Transportquelle von allem anderen, was der Dienst verarbeitet, denn eine Gateway-Adresse zu sehen sagt nichts darüber, was sonst noch gespeichert wird. Auch ein Resolver-Standort sagt nichts darüber, welcher Client gefragt hat. Diese Aussagen auseinanderzuhalten ist das, was die Schlussfolgerung in einer Prüfung verteidigbar macht.