Seit letzter Woche befinde ich mich im Austausch mit den RethinkDNS-Entwicklern. Anbei ein paar Ausschnitte aus der Konversation [übersetzt mit DeepL]:

Frage Kuketz:

Wenn eine Anwendung isoliert ist, kann der Benutzer festlegen, zu welchen IP-Adressen/Domänen eine Verbindung erlaubt ist. Dies funktioniert zuverlässig, überschneidet sich aber etwas mit den Regeln der universellen Firewall. Dort kann man festlegen, dass Anwendungen blockiert werden, wenn das Gerät gesperrt ist, oder dass Anwendungen blockiert werden, wenn sie nicht verwendet werden/im Vordergrund sind. Dies gilt jedoch nicht, wenn eine App isoliert ist. Isolierte Apps können immer noch auf die vom Benutzer gespeicherten Adressen/Domänen zugreifen. Meine Frage ist nun, ob es eine Möglichkeit gibt, die universellen Firewall-Regeln bzw. die zwei zuvor genannten auch auf isolierte Anwendungen anzuwenden?

Antwort RethinkDNS:

Im Moment gelten nur app-spezifische Regeln für eine isolierte App. In einer kommenden Version wollen wir es den Benutzern ermöglichen, universelle (globale) Firewall-Regeln zu einzelnen Apps hinzuzufügen (sie sozusagen zu lokalen / Pro-App-Regeln zu machen): https://github.com/celzero/rethink-app/issues/720. Dies wird zusammen mit einer „Regel-Engine“ implementiert, die mehrere Firewall-Regeln konsequent durchsetzt, wenn sie sich überschneiden: https://github.com/celzero/rethink-app/issues/781

Frage Kuketz:

Wie wirkt sich eine große lokale Filterliste auf die Performance und den Batterieverbrauch aus?

Antwort RethinkDNS:

Performance: Große Liste / kleine Liste spielen keine Rolle in Bezug auf die Performance. Sie sind alle in

einem einzigen Compact Radix Trie (14M Blocklisteneinträge auf 100MB komprimiert – die Suche nach Domains ist ungefähr weniger als 1ms im 95. Perzentil)

und optimiert für String-Kompression (auch Open Source: https://github.com/serverless-dns/trie, https://github.com/celzero/gotrie). Hier ist ein schöner Bericht über prägnante Tries (aber unsere Implementierung ist noch leistungsfähiger): http://stevehanov.ca/blog/?id=120

Leistung: Es entsteht definitiv ein gewisser Overhead wegen der Suchvorgänge. Da sich die gesamte Blockliste im RAM befindet und von einem LFU-Cache gepuffert wird, denke ich nicht, dass sie so viel zum Stromverbrauch beitragen sollte, aber ich habe keine formale Analyse durchgeführt, um dies festzustellen.

Frage Kuketz:

Werden Duplikate entfernt, wenn mehrere Listen abonniert/zusammengeführt werden?

Antwort RethinkDNS:

Ja.

Frage Kuketz:

Wenn in der aktuellen Version (055a) ein WireGuard-VPN aktiviert ist, laufen DNS-Anfragen weiterhin über den in RethinkDNS eingestellten DNS. Wird es eine Option geben, DNS-Anfragen auch über den WireGuard-Tunnel zu leiten?

Antwort RethinkDNS:

Das Routing von DNS-Anfragen über WireGuard (oder einen anderen aktiven Proxy) wird ab der nächsten Version, v055b (die in einer Woche erscheinen soll – aber das sage ich ja schon seit Wochen), die Standardeinstellung sein.

Frage Kuketz:

Wird es eine automatische Möglichkeit geben, für verschiedene Schnittstellen (WiFi/Mobile) unterschiedliche DNS-Einstellungen zu hinterlegen? So kann z.B. im WiFi der lokale Pi-hole hinterlegt werden, während unterwegs (mobil) ein anderer DNS-Server verwendet wird.

Antwort RethinkDNS:

Eine Nischenfunktion, von der wir hoffen, dass sie durch die Integration von Tasker gelöst wird. Es gibt ein Issue https://github.com/celzero/rethink-app/issues/63, aber das hat keine hohe Priorität.

Frage Kuketz:

Wird es eine Möglichkeit geben, eine WireGuard-Verbindung bzw. ein WireGuard-Profil nur dann zu aktivieren, wenn das mobile Interface (also getrennt vom WiFi) aktiv ist?

Antwort RethinkDNS:

Zur Kenntnis genommen: https://github.com/celzero/rethink-app/issues/1143 (aber auch hier würden wir uns auf Tasker verlassen; aber auch hier hat sich niemand aus der Community bereit erklärt, die Tasker-Integration zu implementieren, und wir selbst sehen das nicht als Priorität an).

Frage Kuketz:

Was ist performanter? DNS-Regeln, universelle Firewall-Regeln oder App-spezfische Regeln?

Antwort RethinkDNS:

DNS-Regeln sind am leistungsfähigsten, gefolgt von universellen und dann app-spezifischen.

Was den geringeren Stromverbrauch angeht, so lautet mein Verdacht: DNS-Regeln sind besser, gefolgt von anwendungsspezifischen Regeln, gefolgt von universellen Regeln. Das liegt daran, dass universelle Regeln dazu neigen, sehr viel zu blockieren, und daher mehr Strom verbrauchen, weil Anwendungen einfach weiter versuchen, die Firewall zu umgehen, und dadurch Strom verbrauchen.

Frage Kuketz:

Wenn RethinkDNS bzw. der Dienst unter System -> Bedienungshilfen abstürzt, wird der Schieberegler unter Firewall -> Universelle Firewall-Regeln -> Blockiere jede App, die nicht in Benutzung ist entfernt. Wird es dafür einen Fix/Workaround geben? Aktuell muss der Schieberegler wieder manuell aktiviert werden.

Antwort RethinkDNS:

Wir wissen nicht, warum diese „Abstürze“ auftreten, denn die Gründe scheinen von Version zu Version und von Gerät zu Gerät zu variieren, was wiederum die Fehlersuche und -behebung erschwert.

Was die automatische Aktivierung der Barrierefreiheit angeht: Die App kann das nicht. Dies ist eine von Android auferlegte Maßnahme. Der Benutzer muss die Berechtigung für die Barrierefreiheit manuell erneut erteilen.

Der Kontakt besteht aktuell weiterhin. Eventuell kann ich so dazu zur Verbesserung von RethinkDNS beitragen.

Unterstütze den Blog mit einem Dauerauftrag! Mitmachen ➡