Trusted Recursive Resolver (TRR) funktioniert nicht / wird nie verwendet

Ich habe in zwei Versionen den Trusted Recursive Resolver (TRR) aktiviert, also DNS over HTTPS.

Im aktuellen ESR 68.11.0 funktioniert TRR problemlos wie erwartet.

In der aktuellen Release Version 79.0 (als portable) und den selben Einstellungen funktioniert TRR dagegen nicht bzw. nur im Abgesicherten Modus.

Meine Einstellungen:

network.trr.mode=3, testweise aber auch 2

network.trr.custom_uri korrekt angegeben, aber testweise auch mit Cloudflare/default

network.trr.bootstrapAddress korrekt angegeben

sonst keine Abweichungen vom default

Meine Ergebnisse:

Unter about:networking#dns wird angezeigt, dass TRR nicht benutzt wird (trotz obigen Einstellungen). Das deckt sich auch mit dem unterschiedlichen Auflösen von bestimmten Adressen, es wird tatsächlich nur das DNS des Betriebssystems verwendet.

Im Abgesicherten Modus und gleichen Einstellungen wird TRR dagegen benutzt und arbeitet korrekt. Eine Deaktivierung aller AddOns im normalen Modus bringt dagegen keinen Erfolg.

Gibt es Einstellungen, die TRR trotz mode=3 deaktivieren oder verhindern? In welchem Bereich der config könnten die liegen?

Hat die portable-Version Einfluss auf TRR?

Danke vorab für eure Gedanken oder Erfahrungen dazu!

Zitat von Boersenfeger

Willkommen im Forum!

Vielleicht möchtest du zunächst dein Betriebssystem auf einen aktuellen Stand bringen....

Vielen Dank für deine herzliche Begrüßung!

Deiner Vermutung/Frage/Wunsch/Aufforderung bin ich prompt dahingehend nachgekommen, dass eine portable Version ja tatsächlich portabel ist und ich meine Beschreibung auch unter Windows 10/2004 getestet habe, mit gleichem Ergebnis.

Falls das sachdienlich relevant sei sollte, kann gern ein Moderator meinen Post bezüglich des BS entsprechend anpassen, damit keine (weiteren) Missverständnisse entstehen.

Wenn ich die Idee von "TRR" richtig verstanden habe, soll die Absicherung des DNS bewusst nicht vom Betriebssystem abhängig sein. Insofern ist das identische Ergebnis (für mich) nicht verwunderlich.

Vielleicht gibt es ja noch andere Gedanken zu dem beschriebenen unerwarteten Verhalten, die Firefox selbst betreffen?

Mich würde schon interessieren, was FF dazu veranlassen kann, ein eindeutig aktiviertes Sicherheitsfeature kommentarlos nicht anzuwenden.

Zitat von ^L^

Hi, ich verwende auch FX 79, jedoch mit Profilen. Da funktionieren folgende Einstellungen recht gut - mit about:networking

und Nirsofts CurrPorts geprüft.

network.trr.mode;2

network.trr.bootstrapAddress;176.9.93.198

network.trr.uri;https://doh.appliedprivacy.net/query

Danke! Ja, mit FF 68 ESR funktioniert DoH bei mir scheinbar ja auch.

Der Mode 2 ermöglicht allerdings ein Fallback auf das System-DNS, wahrscheinlich kommentarlos, sodass die Anwendung von DoH jedenfalls in der Theorie nicht zuverlässiger als im Mode 3 sein kann, sondern ein stilles Ignorieren von DoH zulässt. Im Mode 2 wäre es nach meinem Verständnis jedenfalls möglich, dass man wegen Verbindungsfehlern gar kein DoH bekommt.

Zitat von ^L^

Inside Firefox’s DOH engine https://daniel.haxx.se/blog/2018/06/0…oxs-doh-engine/

Using network.trr.mode = 3 https://support.mozilla.org/de/questions/1265514

Beide Artikel sind mir bekannt, leider sehe ich da keinen direkten Bezug zu dem von mir beobachteten Verhalten.

Insbesondere bei der Diskussion um den Mode 3 wird mir nicht ganz klar, wer da was getestet hat, welche Ergebnisse hatte und ob es eine Lösung gab. Es sieht dort eher so aus, dass die Namensauflösung teilweise gar nicht funktionierte, was zwar ärgerlich ist, aber immerhin ein zuverlässiges Verhalten, wenn im Mode 3 die Kommunikation mit dem Server nicht klappt (so hätte ich das auch in meinem Fall erwartet). Daher werden dort auch verschiedene DNS-Server diskutiert, die mit meiner Nicht-Verwendung des exklusiven Modes 3 ja wenig zu tun haben sollten.

Offensichtlich geht es aber auch in dieser Diskussion darum, dass DoH unvorhersehbar nicht funktionierte - und das ist tatsächlich eine Gemeinsamkeit.

Zitat von Thomas S.

Ich hätte da noch anzubieten:

Privacy Handbuch: TRR

Danke! Durch den Artikel war ich ursprünglich darauf gekommen, "TRR" zu testen. Das Thema ist dort nach meinem Eindruck gut dokumentiert. Dass "TRR" manchmal stillschweigend ignoriert wird, wird dort allerdings auch nicht erwähnt.

edit:

Mit einer frisch "installierten" portablen Version funktioniert DoH mit obigen Einstellungen klaglos. Die portable Version selbst ist also nicht ursächlich.

Offensichtlich gibt es aber Änderungen, sei es durch (bereits deinstallierte) AddOns oder Config-Einträge, die zur Folge haben, dass DoH stillschweigend deaktiviert wird.

Zitat von Thomas S.

Was mir aufgefallen ist:

Einige Seiten werden mit aktivem TRR nicht mehr komplett aufgebaut, es gibt scheinbar Abhängigkeiten zu anderen Filtern.

Z.B. ebay. Hier müssen mindestens in uBlock neue Freigaben gesetzt werden, was mich schon verwundert hat.

Insofern sind da auch Einflüsse durch AddOns auf die Aktivierung von TRR denkbar.

Und das AddOn-abhängige Einstellungen beibehalten werden, wenn AddOns deinstalliert sind, ist auch mir aufgefallen.

Mir war das ersteinmal zu viel Gefummel, "Privacy" ist gut und notwendig, aber eben auch mit Seiteneffekten verbunden.

Alles anzeigen

Zusätzliche Effekte auf die Funktion von Seiten wie ebay ist mir (mit uMatrix) noch nicht aufgefallen. Das wäre zusätzlich (für mich) unverständlich und die Zuverlässigkeit verringernd.

Die Bedeutung meines getesteten Unterschieds im Abgesicherten Modus ist mir auch immer unklarer, denn ich hatte fälschlicherweise angenommen, darin würden auch Einstellungen der Config zurückgesetzt, was aber gar nicht der Fall ist. Und da das manuelle Deaktivieren der AddOns bei mir keinen Unterschied macht und Symbolleisten- und Fenstereinstellungen (die der Abgesicherte Modus mitbringt) in diesem Fall wohl eher uninteressant sind, tappe ich zunehmend im Dunkeln.

Vielleicht habe ich TRR auch noch überschätzt, immerhin will Mozilla es erst langsam in USA testen/ausrollen und hält es insofern auch selbst wohl für noch nicht ganz berechenbar. Wobei ich da bisher eher an die Performance gedacht hatte, nicht an stille Nicht-Funktion.

Auf Betriebssystemebene ist gesichertes DNS für mich deutlich interessanter, diesbezüglich wird Windows 10 - sofern DoH denn bereits jetzt oder bald richtig funktioniert - eventuell noch Mozilla den Rang ablaufen.

Mangels weiterer Ideen werde ich mich deshalb - jedenfalls unter Windows 10 - erstmal nicht weiter mit TRR beschäftigen.

Mein Fazit: Falls TRR überhaupt funktioniert, scheint es rund zu laufen. Zu sehr vertrauen würde ich der Funktion jedoch nicht, da sie unter bestimmten Bedingungen trotz eindeutig gegenteiliger Einstellungen einfach auf das System-DNS zugreift.

Zitat von Fox2Fox

Du kannst den betreffenden Beitrag selbst editieren.

Die Frage ist, ob du weiterhin unter Windows 7 und/oder Windows 10 testest.

Stimmt, das hatte ich übersehen und hab es erledigt.

Alle meine bisherigen Feststellungen gelten für 7 und 10.

Zitat von .DeJaVu

Nö, ist fertig, deswegen gibt es ja die Option in den Einstellungen dazu, die ist nur nicht aktiviert für andere Länder als USA.

Ja, eine Option, die manchmal ignoriert wird.

Aber ich kann damit leben - auch wenn TRR so "fertig" bleibt, wie es sich praktisch in meinem "Einzelfall" äußert.

Update:

Nachdem ich alle Einstellungen zu TRR und AddOns nun ein paar Monate so belassen, das Funktionieren von TR aber nicht mehr kontrolliert habe, ergibt sich momentan - wenn man dem eingebauten Monitor about:networking#dns trauen kann - ein gegenteiliges, erneut teilweise fehlerhaftes Bild.

Beide Anwendungen sind nun durch die regelmäßigen Updates ein paar Versionen älter, der ESR auf 78.3.1esr (32-Bit) und die portable Version auf 81.0.1 (32-Bit).

Meine Einstellungen: trr.mode=3 (also offiziell kein Fallback auf das System-DNS), Serveradresse benutzerdefiniert bzw. im Fehlerfall testweise immer auch alternativ Cloudflare.

In meiner portablen Version 81 wird nun durchgängig TRR benutzt, jedenfalls zu den Zeitpunkten, zu denen ich den Monitor betrachte. Zur Erinnerung: Als diese Anwendung noch auf Version 79 war, funktionierte TRR unter keinen Umständen.

Im meinem ESR 78 wird TRR nun dagegen gar nicht benutzt, trotz obiger und zu meiner Version 81 identischen Einstellungen. Vor 1-2 Wochen funktionierte TRR hier noch, ich habe aber wegen des (vorübergehend) beruhigend positiven Ergebnisses die Details nicht notiert. Zur Erinnerung: Als diese Anwendung noch auf Version 68 war, funktionierte TRR wie offiziell beabsichtigt.

Mittlerweile bin ich auch auf diesen Faden gestoßen, in dem zwar die Einstellungen etwas andere Probleme bereiten, das Fazit über die Zuverlässigkeit von TRR aber ähnlich ausfiel.

Echt schade für so eine Funktion mit ernstem Hintergrund!