Wer betreibt 1.1.1.1? Eine DNS-Adresse prüfen, bevor man ihr vertraut
Eine zusammen mit einem VPN genutzte DNS-Adresse wird nicht zwangsläufig von diesem VPN betrieben. Bestimmen Sie den Resolver und prüfen Sie dann Pfad und Richtlinie für private Namen getrennt.
Sie haben 1.1.1.1 in das DNS-Feld des VPN eingetragen, die Seite lud, und das Tutorial gilt nun als bestätigt. Diese Beobachtung ist enger, als sie sich anfühlt: Die Anwendung hat sich anders verhalten, und die Änderung sagt noch nichts darüber, wer die Anfrage beantwortet hat oder warum die alte Einrichtung versagt hat. Ein abgeschriebenes Tutorial nennt eine bekannte öffentliche Adresse gern „das DNS des VPN“; das ist eine Aussage über die Betreiberschaft und nicht über die Erreichbarkeit. Zu prüfen, wofür die Adresse steht, dauert fünf Minuten und verhindert eine dauerhafte Änderung aus dem falschen Grund.
Eine funktionierende Einstellung ist keine Identität
Die Adresse in einem Einstellungsfeld ist ein Endpunkt, und ein Endpunkt hat einen Betreiber. Diese beiden Tatsachen sind getrennt, und die zweite ist die, die man überspringt. Für das am häufigsten kopierte Paar ist die Antwort öffentlich: Cloudflare veröffentlicht 1.1.1.1 und 1.0.0.1 als seine Resolver-Adressen und führt sie in seiner offiziellen Adressreferenz auf. Deshalb gehört der Name des Betreibers neben die Adresse und nicht in ein separates Tutorial.
Wer dieses Paar einträgt, während ein Tunnel läuft, macht das VPN-Unternehmen nicht zu dessen Betreiber und den Verkehr nicht anonym. Die Anfrage verlässt Ihren Rechner in Richtung eines Unternehmens, das den Adressbereich veröffentlicht; dieses Unternehmen kann seriös sein und trotzdem nicht die Partei, die das Tutorial nahelegt. Die Bezeichnung in der Anleitung und der Betreiber in der Realität sind zwei verschiedene Aussagen. Keine von beiden sagt, wer den Netzwerkpfad dazwischen betreibt.
Nutzen Sie die eigene veröffentlichte Referenz des Resolvers, um ein Adresspaar oder einen verschlüsselten Endpunkt zu bestätigen. Eine Empfehlung eines anderen Anbieters kann legitim sein, und „empfohlen von“, „erreicht über“ und „betrieben von“ beschreiben weiterhin drei verschiedene Beziehungen.
Vergleichen Sie die drei Angaben, die ein Eintrag braucht
Ein prüffähiger Eintrag trennt drei Fragen: Wer soll die Anfrage erhalten, ob der Austausch unverschlüsselt oder verschlüsselt ist und welcher Pfad sie tragen soll. Ein Anbietername kann die zweite und die dritte Frage nicht beantworten, und ein Ländername keine davon. Schreiben Sie die drei Angaben vor der Änderung auf und vergleichen Sie sie danach. Diese Angaben sind nicht austauschbar, und sie als eine zu behandeln ist der Weg, auf dem aus einer Vermutung eine Dokumentation wird.
Der Vergleich ist es, der aus einer funktionierenden Einstellung eine dokumentierte Entscheidung macht. Ohne ihn erbt die nächste Person eine Adresse, an der kein Grund hängt. Lesen Sie zuerst die dritte Spalte der folgenden Tabelle, denn dort enden die meisten selbstsicheren Erklärungen tatsächlich.
| Entry | What it records | What it cannot tell you |
|---|---|---|
| Recipient | Which resolver should answer | Who operates the path to it |
| Transport | Plain DNS or an encrypted variant | Whether names stay private |
| Path | Which interface carries the query | Which upstream answers last |
Die Tabelle ist absichtlich kurz. Ihr Punkt ist, dass jede Angabe eine andere Frage beantwortet und kein einzelnes Feld alle drei ausfüllt.
Ein lokaler Weiterleiter verbirgt den echten Upstream
Ein Gerät, das seinen Router als DNS nutzt, zeigt auf einen Weiterleiter. Diese Adresse benennt den nächsten Empfänger der Anfrage, nicht den Resolver, der sie schließlich beantwortet. Ein lokaler Stub-Resolver fügt denselben zusätzlichen Schritt hinzu, und er ist leicht mit der eigentlichen Instanz zu verwechseln, weil er in jeder Statusausgabe auftaucht.
Der Stub leitet an Upstreams weiter, die dieselbe Ausgabe ebenfalls auflistet, meist weiter unten. Lesen Sie die ganze Kette, bevor Sie etwas über den Betreiber schließen, denn die erste Zeile ist nicht die ganze Antwort. Sonst benennen Sie den Empfang als das Unternehmen.
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'
Der zweite Befehl nutzt den Echo-Namen eines Resolvers, sofern der Betreiber einen veröffentlicht, um die Quelladresse zu melden, die er sieht. Der dritte nennt den Server, der geantwortet hat, und das ist oft nicht die Adresse, die Sie konfiguriert haben. Vergleichen Sie alle drei Ausgaben, bevor Sie einen Betreiber notieren.
Verschlüsseltes DNS ändert, was sichtbar ist, nicht wer es sieht
DNS over HTTPS und DNS over TLS schützen den Austausch zwischen Client und Resolver. Der Resolver liest weiterhin jeden Namen, nach dem er gefragt wird, denn das Antworten ist seine Aufgabe. Was sich ändert, ist, wer den Austausch beobachten kann: Das lokale Netz sieht eine Verbindung zu einem Endpunkt statt eines Stroms von Klartextanfragen.
Was sich nicht ändert, ist die Vertrauensbeziehung, die weiterhin auf die Organisation zeigt, die diesen Endpunkt betreibt. Ein Browser mit eigener Einstellung für sicheres DNS kann den Resolver des Betriebssystems vollständig umgehen. Behandeln Sie beides als zwei Konfigurationen, die sich widersprechen können, und nicht als eine zweimal angewandte Einstellung.
Private Namen brauchen wieder eine eigene Entscheidung. Ein Arbeitstunnel kann ausgewählte Domains an organisatorische Resolver leiten, und das durch einen öffentlichen Dienst zu ersetzen kann interne Auflösungen brechen oder interne Namen an die falsche Partei preisgeben. Prüfen Sie die Domain-Richtlinie, bevor Sie die Einstellungen eines ganzen Adapters ersetzen.
Halten Sie die Beobachtung eng
Wenn Sie vergleichen, bewahren Sie die alte Konfiguration auf und ändern Sie jeweils nur eine Einstellung. Notieren Sie die Anwendung, den Vorgang, die Resolver-Richtlinie und ob öffentliche und erlaubte private Namen nach einem erneuten Verbinden noch aufgelöst werden. Ein Vergleich mit zwei Änderungen darin beweist keine von beiden. Schreiben Sie das Ergebnis dorthin, wo die nächste Person es findet, direkt neben die Einstellung selbst.
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com
Wenn die Anwendung zu funktionieren beginnt, halten Sie die Aussage so klein, wie es die Belege zulassen. Diese Änderung hat einem Test geholfen, und sie sagt nichts darüber, ob der vorherige Resolver in böser Absicht handelte, ob der Tunnel defekt war oder ob ein anderes Gerät denselben Ersatz braucht. Das dauerhafte Ergebnis ist eine Konfiguration, deren Betreiber und Zweck Sie erklären können.