Heute soll es mal wieder um Pi-hole gehen: Dabei handelt es sich um einen Werbe-Blocker für das gesamte Netzwerk, der nicht nur störende Werbung auf Websites herausfiltert, sondern auch einen Schutz vor Tracking und Schadsoftware ermöglicht.
Die Installation und Einrichtung von Pi-hole hatte ich ja bereits im Artikel Nie mehr Werbung – Pi-hole auf Ubuntu Server 18.04 beschrieben. Mittlerweile würde man dafür vermutlich Ubuntu 20.04 LTS nutzen, trotzdem ist genannte Artikel weiterhin aktuell. Ebenso kann Pi-hole (wie der Name ja schon vermuten lässt) auf einem Raspberry Pi installiert werden – besonders viel Leistung wird hier also nicht benötigt.
In Sachen Datenschutz und Privatsphäre ist Pi-hole schon einmal ein riesiger Schritt nach vorne. Trotzdem gibt es hier noch ein Problem: Ein verwendeter DNS-Server (Upstream-DNS) kennt immer die Quell-IP, von der die DNS-Anfrage abgesetzt wird. Daran ändert auch eine verschlüsselte DNS-Abfrage (z.B. mit DNS over TLS) nichts. Damit lassen sich trotz aller Maßnahmen Profile erstellen, die z.B. Rückschlüsse auf die Surf-Gewohnheiten ermöglichen.
Zu diesem Problem gibt es allerdings schon Lösungsansätze: Die Protokolle DNSCrypt und Oblivious DNS-over-HTTPS (eine Protokollerweiterung von DNS over HTTPS – kurz: ODoH) bieten hier Mechanismen an, um die Quell-IP bei DNS-Anfragen effektiv zu schützen. Beide Protokolle werden vom DNS-Client dnscrypt-proxy implementiert.
Der folgende Artikel zeigt, wie man dnscrypt-proxy einrichten und in Kombination mit Pi-hole verwenden kann.
Inhalt
Zielsetzung/Funktionsweise dnscrypt-proxy
Um die Funktionsweise von dnscrypt-proxy besser zu verstehen, schauen wir uns erst einmal (vereinfacht) eine DNS-Abfrage eines Clients über Pi-hole und die damit verbundenen Probleme an:
Als Upstream-DNS-Server sind hier die DNS-Server des Internet-Providers, von Quad9, Google, etc. gemeint. Diese kennen nun immer die Quell-IP der DNS-Abfrage (d.h. in den meisten Fällen die öffentliche IP-Adresse des Internet-Anschlusses) und könnten dementsprechend Profile für Clients anlegen, die dann weiter ausgewertet werden könnten (u.a. auch für Werbezwecke).
Um dies zu verhindern, benötigt man nun eine Art „Mittelsmann“ – ein sog. DNS-Relay. Dies ist ein Server, der eine verschlüsselte DNS-Anfrage entgegen nimmt und an einen DNS-Resolver weiterleitet. Die Quell-IP wird dabei vom DNS-Relay nicht übermittelt. Der DNS-Resolver entschlüsselt die Anfrage und leitet diese dann an einen der Upstream-DNS-Server weiter. Das Ergebnis der DNS-Abfrage wird dann in umgekehrter Reihenfolge wieder an den Client PC übermittelt. Das folgende Bild zeigt wiederum vereinfacht den Ablauf:
Bis zum DNS-Relay ist die Quell-IP des Clients bekannt (blauer Bereich). Bei der Übergabe an den DNS-Resolver wird diese allerdings nicht weiter gegeben, so dass alle dahinter liegenden Systeme keine Kenntnis über die Quell-IP mehr haben (roter Bereich). Durch diese Vorgehensweise und die Verschlüsselung der DNS-Abfrage bis zum DNS-Resolver ist nun keine Partei in Kenntnis aller Informationen:
- Der Relay-Server kennt die Quell-IP der DNS-Anfrage, aber nicht deren Inhalt (da verschlüsselt).
- Der DNS-Resolver kennt den Inhalt der DNS-Abfrage (da dieser wieder entschlüsselt), nicht aber die Quell-IP.
Grundlage für diese Mechanismen bilden die Protokolle DNSCrypt und Oblivious DNS-over-HTTPS (ODoH). Im Rahmen von dnscrypt-proxy spricht man hierbei von anonymisiertem DNS (anonymized DNS).
Das Ziel des Artikels ist nun:
- Installation von dnscrypt-proxy.
- Konfiguration von dnscrypt-proxy, so dass DNSCrypt und ODoH genutzt werden.
- Einbinden von dnscrypt-proxy in eine bestehende Pi-hole Instanz.
Installation dnscrypt-proxy
dnscrypt-proxy ist bereits in den Paketquellen aller gängigen Distributionen enthalten. Allerdings ist dies meist nur eine recht alte Version. Da die Entwicklung von dnscrypt-proxy recht schnell voran schreitet und viele sinnvolle Features erst mit neueren Versionen dazu gekommen sind, empfehle ich eine manuelle Installation des Programms.
Auf der GitHub-Release-Seite des Projekts kann die jeweils aktuelle Version ermittelt werden.
Dazu laden wir uns zunächst einmal die aktuellste Version herunter (als dieser Artikel entstanden ist, war dies die Version 2.1.1). dnscrypt-proxy gibt es für so gut wie jedes Betriebssystem/CPU-Architektur. Hier gilt es, die passende Version für den Download zu wählen (in diesem Fall „Linux x86_64“):
wget https://github.com/DNSCrypt/dnscrypt-proxy/releases/download/2.1.1/dnscrypt-proxy-linux_x86_64-2.1.1.tar.gz
Als nächstes wird dieses Archiv entpackt und in den Ordner verschoben, in dem das Programm installiert werden soll:
tar -xf dnscrypt-proxy-linux_x86_64-2.1.1.tar.gz mv linux-x86_64/ /opt/dnscrypt-proxy
Damit ist die grundsätzliche Installation bereits abgeschlossen.
Konfiguration dnscrypt-proxy
Für die Konfiguration wechseln wir in das soeben angelegte Verzeichnis und kopieren uns die Beispiel-Konfiguration:
cd /opt/dnscrypt-proxy cp example-dnscrypt-proxy.toml dnscrypt-proxy.toml
Diese muss nun angepasst werden:
nano dnscrypt-proxy.toml
Die Einstellungen sind sehr umfangreich, daher ist die Konfiguration entsprechend lang. Aus diesem Grund habe ich die komplette Konfiguration in einem git-Repository auf Codeberg zur Verfügung gestellt:
DecaTec / dnscrypt-proxy-config @ Codeberg
Alle Einstellungen, die hier von den Standard-Vorgaben abweichen, habe ich dabei mit Kommentaren versehen (#DecaTec: …).
Folgende Optionen sind hier wichtig:
- server_names = […]
Hier werden die zu nutzenden Resolver-DNS-Server hinterlegt. Die Namen der Server sind hier nicht zufällig, sonder werden im Abschnitt [sources] definiert (s.u.). - listen_addresses = [‚127.0.0.1:65054‘, ‚[::1]:65054‘]
Gibt an, dass dnscypt-proxy nur über die lokale IP-Adresse unter Port 65054 erreichbar ist. Besonders der Port ist hier wichtig, da dies normalerweise Port 53 ist, dieser aber schon durch Pi-hole belegt ist. Hier kann natürlich auch ein anderer freier Port genutzt werden. - ipv6_servers = true
DNS-Server sollen auch über IPv6 angesprochen werden. Diese Option sollte nur aktiviert werden, wenn auch tatsächlich IPv6 genutzt wird, d.h. der Pi-hole eine IPv6 Adresse hat. - odoh_servers = true
Es sollen Server genutzt werden, die das Oblivious DoH Protokoll unterstützen. - require_dnssec = true
Zu nutzende DNS-Server müssen DNSSEC unterstützen. - lb_strategy = ‚p2‘
Es sollen nur die schnellsten zwei DNS-Server genutzt werden. - Sektion [sources]:
Hier werden die DNS-Resolver und DNS-Relays definiert. Hier gibt es bereits vorgefertigte Listen, die hier direkt per Link eingebunden werden können. Wichtig ist nur, dass es jeweils eigene Resolver/Relays für DNSCrypt und ODoH gibt, daher sind die zwei getrennte Blöcke. - skip_incompatible = true
Nicht kompatible DNS-Server sollen nicht genutzt werden. - Sektion [anonymized_dns]:
Hier entsteht nun die „Magie“ von dnscrypt-proxy. Angegeben wird hier, welche DNS-Resolver über welche DNS-Relays angesprochen werden sollen.
Wichtig: Dieser Bereich ist standardmäßig auskommentiert und daher sind anonymisierte DNS-Anfragen nicht aktiv. Daher ist es an dieser Stelle wichtig, Routen zu konfigurieren und anzugeben.
Der server_name stellt dabei immer den DNS-Resolver dar, unter via werden ein oder mehrere DNS-Relays angegeben.
Die auf Codeberg bereit gestellte Konfiguration ist dabei optimiert für die Nutzung von DNS-Resolvern/-Relays aus Deutschland. Diese sollten hierzulande die geringsten Antwortzeiten haben. Wer andere Server nutzen möchte, kann einen Blick auf die umfangreiche Liste des DNSCrypt-Projekts werfen (wichtig, hier sollten nur Server gewählt werden, die DNSCrypt oder ODoH unterstützen).
Bei der Definition der Routen (also der Verbindung zwischen DNS-Resolvern und -Relays) sollte man nach Möglichkeit Server wählen, die nicht vom gleichen Anbieter betrieben werden (denn dieser kennt ja „beide Seiten“ und könnte in der Theorie die Anonymisierung wieder umgehen). Aus diesem Grund nutze ich hier keine Wildcards bei der Definition der Routen (was dnscrypt-proxy durchaus unterstützt).
Wer maximalen Wert auf Anonymität legt, sollte am besten Resolver und Relays aus unterschiedlichen Ländern wählen. Der Nachteil ist dann allerdings, dass die DNS-Abfragen länger dauern werden, da weit entfernte Server in der Regel größere Antwortzeiten haben.
Test der Funktion
Nach der Konfiguration kann man nun dnscypt-proxy manuell starten:
cd /opt/dnscrypt-proxy ./dnscrypt-proxy
Wie man nun an der Ausgabe erkennt, probiert das Programm sämtliche Kombinationen von DNS-Resolvern und -Relays durch, um die kürzesten Antwortzeiten zu ermitteln. Dies dauert einen Moment, aber am Ende sollten dann folgende Meldungen sichtbar sein:
[2021-11-20 13:33:00] [NOTICE] Sorted latencies: [2021-11-20 13:33:00] [NOTICE] - 21ms dnswarden-eu-uncensor-dcv4 [2021-11-20 13:33:00] [NOTICE] - 22ms moulticast-de-ipv4 [2021-11-20 13:33:00] [NOTICE] - 23ms cs-dus3 [2021-11-20 13:33:00] [NOTICE] - 24ms odoh-cloudflare [2021-11-20 13:33:00] [NOTICE] - 24ms sicher-surfen-de [2021-11-20 13:33:00] [NOTICE] - 25ms dns.watch [2021-11-20 13:33:00] [NOTICE] - 26ms cs-berlin [2021-11-20 13:33:00] [NOTICE] - 29ms cs-de [2021-11-20 13:33:00] [NOTICE] - 32ms dnscrypt-de-blahdns-ipv4 [2021-11-20 13:33:00] [NOTICE] - 35ms cs-dus4 [2021-11-20 13:33:00] [NOTICE] - 36ms cs-dus1 [2021-11-20 13:33:00] [NOTICE] - 40ms cs-dus2 [2021-11-20 13:33:00] [NOTICE] - 45ms odoh-koki-ams [2021-11-20 13:33:00] [NOTICE] Server with the lowest initial latency: dnswarden-eu-uncensor-dcv4 (rtt: 21ms) [2021-11-20 13:33:00] [NOTICE] dnscrypt-proxy is ready - live servers: 13
Nun kann man (auf der gleichen Maschine) einen ersten Test durchführen, ob die DNS-Auflösung korrekt funktioniert:
dig @127.0.0.1 -p 65054 decatec.de
Hier sollte nun die IP 202.61.232.157 ermittelt werden können.
Nach diesem ersten Test kann das Programm nun mittels STRG+C wieder beendet werden.
Einrichtung von dnscrypt-proxy als systemd-Unit
dnscrypt-proxy soll natürlich bei jedem Systemstart automatisch ausgeführt werden. Dazu liefert das Programm gleich einen „Installer“ mit, den wir nun einfach ausführen können:
./dnscrypt-proxy -service install
Die systemd-Unit kann daraufhin auch gleich gestartet werden:
service dnscrypt-proxy start
Der Start dauert wieder eine kurze Zeit. Anschließend sollte aber folgender Befehl eine ähnliche Erfolgsmeldung wie schon beim manuellen Start anzeigen (s.o.):
service dnscrypt-proxy status
dnscrypt-proxy ist nun fertig konfiguriert und wird automatisch mit dem System gestartet.
Es fehlt nur noch die Einbindung in Pi-hole.
Pi-hole: Hinzufügen von dnscrypt-proxy
dnscrypt-proxy bringt erst einmal keine Funktionen zum Blocken von Werbung o.ä. mit. Zwar kann man DNS-Resolver nutzen, die ein gewisses Filtering anbieten, dennoch hat man hier keine Kontrolle darüber, welche Domains geblockt werden. Daher soll an dieser Stelle dnscrypt-proxy als Upstream-DNS-Server für unseren Pi-hole eingerichtet werden.
Dies geschieht unter Settings > DNS > Upstream DNS Servers. Hier kann man nun dnscrypt-proxy mit 127.0.0.1#65054 (IPv4) bzw. ::1#65054 (IPv6) angeben:
Links sieht man hier nun unsere dnscrypt-proxy Instanz als Upstream DNS-Server von Pi-hole (Port 65054). Auf der rechten Seite ist übrigens stubby als alternativer DNS-Upstream konfiguriert (Port 65053).
Mit einem Klick auf Save werden die Einstellungen übernommen. Nun profitiert das ganze Netzwerk sowohl vom anonymisierten DNS durch dnscrypt-proxy, als auch durch das Herausfiltern von Werbung und Tracking durch Pi-hole selbst.
dnscrypt-proxy vs. stubby
Im ursprünglichen Artikel über Pi-hole wurde stubby als Upstream-DNS für Pi-hole verwendet (siehe hier). Daher soll an dieser Stelle noch kurz auf die Unterschiede zwischen stubby und dnscrypt-proxy eingegangen werden.
stubby ist ein sog. Stub-Resolver für DNS over TLS (DoT). D.h. die DNS-Anfragen werden stets über TLS verschlüsselt. Dennoch wird hier die Quell-IP nicht gegenüber dem eigentlichen DNS-Server geheim gehalten (wie es beim anonymisierten DNS bei dnscrypt-proxy der Fall ist). Daher sollte man bei der Verwendung von stubby ein genaues Augenmerk auf die Upstream-DNS-Server werfen: Hier ist ein gewisses Vertrauen in die Betreiber der DNS-Server notwendig, dass diese nicht auf Grund von DNS-Anfragen gewisser Quell-IPs Profile erstellen, etc.
Dies ist der große Unterschied zu dnscrypt-proxy: Sobald hier anonymisiertes DNS mit Routen aus DNS-Resolvern und -Relays genutzt werden, ist das Vertrauen in den DNS-Resolver überhaupt nicht notwendig/relevant, da die eigene IP jederzeit durch die DNS-Relays „geschützt“ ist. So ist es bei dnscrypt-proxy nicht bedenklich, wenn man DNS-Dienste von Google, Cloudflare oder anderen großen Konzernen (als DNS-Resolver!) nutzt, wenn diese Kommunikation durch DNS-Relays geschützt werden. Bei stubby wäre dies aus Gründen des Datenschutzes/der Privatsphäre nicht empfehlenswert.
Es spricht übrigens nichts dagegen, dnscrypt-proxy und stubby parallel in Pi-hole als Upstream-DNS-Server zu verwenden (siehe Screenshot oben). Die Praxis zeigt allerdings, dass dnscrypt-proxy etwas effizienter arbeitet: Pi-hole nutzt bei der Verwendung mehrerer Upstream-DNS-Server bevorzugt den Server, der die geringste Antwortzeit aufweist. In dem meisten Fällen ist dies dnscrypt-proxy, auch wenn bei anonymisiertem DNS immer noch ein zusätzlicher „Hop“ bei den Anfragen notwendig ist. Dies kann man recht einfach in der Übersicht von Pi-hole unter Upstream servers erkennen: Deutlich mehr Anfragen werden über dnscrypt-proxy behandelt, als über stubby.
Fazit
Die Kombination von Pi-hole mit dnscrypt-proxy arbeitet nach der Optimierung der Einstellungen von dnscrypt-proxy sehr effizient und hält Werbung und Tracker aus dem Netzwerk fern. Darüber hinaus wird die Privatsphäre bei DNS-Abfragen dank anonymisierter DNS-Kommunikation über DNSCrypt bzw. ODoH optimal geschützt.
Meine beiden Pi-hole Instanzen laufen nun schon seit einiger Zeit mit dnscrypt-proxy und ich konnte bisher noch keine Probleme feststellen.
Wie schaut es bei euch aus? Nutzt ihr auch schon dnscrypt-proxy in Verbindung mit eurem Pi-hole? Wie sind eure Erfahrungen mit dieser Kombination? Hinterlasst mir dazu doch gern einen Kommentar!
Weiterführende Artikel
- Nie mehr Werbung – Pi-hole auf Ubuntu Server 18.04
- Pi-hole als lokaler DNS-Server: Optimierung für VPN und mehr Performance im Netzwerk
Links
- Pi-hole Homepage (englisch)
- dnscrypt-proxy (GitHub)
- DNSCrypt Homepage (englisch)
- DNS over TLS (Wikipedia)
- DNS over HTTPS (Wikipedia)
- DNSCrypt (Wikipedia, englisch)
- DecaTec / dnscrypt-proxy-config @ Codeberg (Beispiel-Konfiguration dnscrypt-proxy)
- Domain Name System Security Extensions (Wikipedia)
- DNSCrypt – List of public DoH and DNSCrypt servers
- DNSCrypt/dnscrypt-resolvers @ GitHub (Liste von DNSCrypt-Resolvern)
- DNSCrypt/dnscrypt-resolvers @ GitHub (Liste von DNSCrypt-Relays)
- DNSCrypt/dnscrypt-resolvers @ GitHub (Liste von ODoH-Resolvern)
- DNSCrypt/dnscrypt-resolvers @ GitHub (Liste von ODoH-Relays)
Ähnliche Artikel:
Nie mehr Werbung – Pi-hole auf Ubuntu Server 18.04
DynDNS: Home-Server mit einer FritzBox mit IPv4 und IPv6 (Dual-Stack) betreiben
Pi-hole als lokaler DNS-Server: Optimierung für VPN und mehr Performance im Netzwerk
Nextcloud auf Ubuntu Server 22.04 LTS mit nginx, PostgreSQL/MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
Hallo Jan,
danke für den Artikel und die darin genannten Empfehlungen.
Eine Frage hierzu, Wenn ich das richtig lese ist deine Empfehlung klar zu dnscrypt-proxy. Stubby kann bei einer Neuinstallation des pi-hole dann weggelassen werden?
Danke
Gruß Hans
Hi Hans,
dnscrypt-proxy läuft bei mir äußerst gut. stubby lasse ich noch „nebenbei“ laufen, eben als weiterer DNS-Upstream von Pi-hole. Das würde ich für „Umsteiger“ auch erst einmal empfehlen. Wenn dnscrypt-proxy dann zufriedenstellend läuft, kann stubby ja bei Bedarf wieder schnell entfernt werden.
Gruß,
Jan
Hallo Jan!
Danke für die Doku, war sehr einfach umzusetzen.
Wenn ich den dnscrypt-proxy bei mir zuhause stehen habe, weiß doch der Resolver trotzdem, wo die Anfrage herkommt? Und er kennt den Inhalt der Abfrage. Wer weniger weiß als vorher ist der DNS UPstream Server. EIn vertrauenswürdiger DNS-Cryptserver der im Netz verfügbar ist, und von mehreren genutzt wird, wäre wahrscheinlich ne Nummer sicherer.
Hi Christian,
dnscrypt-proxy läuft bei dir zu Hause (sorgt dafür, dass du DNSCrypt und ODoH nutzen kannst), Relay- und Resolver-Server sind aber externe Server.
Der Relay-Server kennt deine IP-Adresse, gibt diese aber nicht an den Resolver weiter. Aus Sicht des Resolvers ist die Quell-IP die des Relay-Server.
Relay- und Resolver-Server werden ja von unzähligen Leuten genutzt, daher kann man hier wohl auch keine Rückschlüsse auf Einzelne ziehen.
Gruß,
Jan
Hallo Jan,
dann ist aber das Bild in deinem Artikel „missverständlich“, denn dann gehört der Relay Server raus aus der lokalen Zone und nach rechts in den orangen „Interneteil“, oder?
So kenne ich es von der Apple „Privat Relay“ Methode … die würde dem ja entsprechen!?
Gruß
Thorsten
Hi Thorsten,
stimmt, hier sind eher die Beschriftungen („lokal“ und „Internet“) etwas blöd gesetzt. Der blaue Bereich ist eben nicht lokal und der rote nicht „Internet“, sondern diese Kästen dienen eher der Abgrenzung, wem welche IPs bekannt sind.
Mit der Erklärung wird es vielleicht verständlicher, oder?
Gruß,
Jan
PS: Oder die Bezeichnungen sind falsch:
DNS-Relay –> DNSCRYPT-Proxy
DNS-Resolver –> DNS-Relay
DNS-Upstream –> DNS Resolver
Oder?
Ansonsten würde der DNS-Resolver ja immer die (verschlüsselten) Anfragen aus meinem Netzwerk mit der öffentlichen IP Adresse meines Routers sehen und damit wäre ich via Time Stamp und ISP Log wieder „erkennbar“.
Hallo Jan,
schön dass du diese Anleitung geschrieben hast. Neben deiner Nextcloud und Matrix Anleitung eine willkommene Ergänzung und eine wirkliche Bereicherung.
Das Thema pihole (mittlerweile adguard home) + dnscrypt-proxy habe ich jetzt seit einigen Jahren verfolgt und selbst auf vielen kleinen raspberrypi’s umgesetzt.
Ich würde deine Anleitung gerne mit den zusätzlichen Funktionen des Proxys erweitern, wie Anonymized DNS und Cloaking oder das Automatische Aktualisieren. Dabei kann ich auf die Besonderheiten der verschiedenen OS Versionen(x86x64 /armv7/8 / freebsd (opnsense) Bezug nehmen.
Bei mir läuft mittlerweile adguard home, da ich GUI moderner empfinde und gefühlt alles etwas schneller geht; besonders das herunterladen der filterlisten. Interessant ist vielleicht auch die Konfiguration als DHCP Server, aber dafür nutze ich hier immer noch die FritzBox.
Ich freue mich auf deine Rückmeldung.
David
Hi David,
ok, dann funktioniert das ganze also auch mit AdGuard.
Mit AdGuard habe ich mich noch gar nicht beschäftigt. Hier wäre mal interessant, was die Unterscheide bzw. Vor-/Nachteile gegenüber Pi-hole sind.
Gruß,
Jan
Also neben der erwähnten grafischen Oberfläche als auch die subjektiv schnellere Reaktionszeit gibt es für einen Vergleich auf github:
AdGuard Home Github.
Hier gibt es auch noch einmal Informationen zum Thema PiHole vs AdGuard Home von der DietPi Community:
https://dietpi.com/blog/?p=665
Danke für den Artikel.
DNSCrypt hat gleich mal mein altes System ersetzt.
Ich finde die Umsetzung auf Dockerbasis recht praktisch da ich damit alle Server gescriptet in der Versionsverwaltung habe. Somit ist auch das Thema Sicherung des Raspi erledigt.
Ich frage mich ob das auch noch praktikabel ist, wenn die EU auf ihrem Internetkurs fortfährt und das DNS System wie RU zentralisiert?
AdGuard hatte ich gar nicht auf dem Schirm wirkt recht sympathisch.
Kann mehr, zeigt weniger Schnickschnack an und wirkt sauberer umgesetzt.
Ich bleib erstmal dabei.
Hi,
Hast du dazu vielleicht eine Quelle? Stelle mir das ganze nur schwer umsetzbar vor. Man könnte in diesem Fall ja auf Nicht-EU DNS-Server (Schweiz, UK) umsteigen.
Gruß,
Jan
Hallo,
warum nutzt du zusätzlich zur Cache Funktion von PiHole die Cache Funktion in dnscrypt. Ist das nicht kontraproduktiv?
Gruß
Dual-O
Hi,
ich habe da nun keine konkreten Messungen vorgenommen, aber ich kann mir nicht vorstellen, dass dies einen Unterschied ausmacht. Aus welchem Cache er das dann liest (dnscryprt oder Pi-hole) ist denke ich nebensächlich. Die Caches dürften sich auf alle Fälle nicht in die Quere kommen.
Gruß,
Jan
Sehr gute Anleitung!
Hat das schon mal wer auf ein Pi-zero (ohne W) versucht? Reicht die Rechenleistung aus?
Hi,
hat der Pi Zero (ohne W) überhaupt LAN oder WLAN? Wenn ich mich recht entsinne, hat er das nicht und dann wird es schwierig mit dem Netzwerk-Traffic.
Gruß,
Jan
Klar geht das. Ich habe über USB ein Netzwerk Adapter dran. Die ganze Konstruktion hängt bei mir **ohne** zusätzlicher Stromversorgung an der Fritzbox :) Also Nur der Strom über USB von der Fritzbox.
Die Frage ist ob die Leistungsaufnahme reicht von Zero.
In Moment ist der Leistungsverbrauch bei.
Active
Load: 0.04 0.07 0.07
Memory usage: 14.1 %
Temp: 29.3 °C
Ach bitte unten den Beitrag löschen…
Hi,
ja, von der Leistung sollte das schon reichen, die Auslastung ist ja sehr gering.
Hängt aber vermutlich auch von der Anzahl der Clients ab. Ich würde es einfach mal ausprobieren.
Gruß,
Jan
Bevor ich anfange werde ich die max_clients = 250 auf 25 verkleinern. Da in ein Normalen Haushalt nie mehr als 25 clients gleichzeitig sind. ;)
Und man sollte nicht vergessen das der Raspberry pi ZERO kein arm64 kann. Also die normale arm version. (dnscrypt-proxy-linux_arm- usw.)
Da deine Anleitung leider keine Autoupdatefunktion beinhaltet hab ich mir aus den Netz die entsprechende Scriptdatei gesucht und leicht umgebaut. :)
Gestern hab ich dann über SSH mir über Netzwerk mit DD eine .image datei von der Speicherkarte gezogen (backup) auf meine Windows Platte. Man darf dabei nicht übersehen das die .image datei die größe der gesamten Festplatte bzw. SDHC (speicherkarte) einnimmt. Wenn ich z.b 64GB SDHC benutze ist die .image datei auch 64GB groß! Das dauert zum Downloaden… In meinen fall da es über den externen USB Netzwerkadapter geht (100mb/s) um die 8MB/s zirka eine Stunde.
Ich melde mich wieder wenn alles rennt. Was ich hoffe ;)
Ok die Kiste Rennt.
Die last liegt bei:
Status
Active
Load: 0.16 0.12 0.1
Memory usage: 14.9 %
Temp: 29.3 °C
Stromverorgung über Fritzbox USB
Pi ZERO (ohne Wlan) und ohne Externe Stromverorgung
Werte von TOP
top – 16:16:37 up 15:10, 1 user, load average: 0.17, 0.21, 0.15
Tasks: 84 total, 1 running, 83 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.6 us, 3.3 sy, 0.0 ni, 92.8 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
MiB Mem : 477.6 total, 69.1 free, 61.1 used, 347.4 buff/cache
MiB Swap: 100.0 total, 98.2 free, 1.8 used. 339.3 avail Mem
Reicht Vollkommen aus.
Es muß nicht immer ein Raspberry 4 oder 3 sein. Man spart sich dadurch jede menge Geld und man hat quasi eine DNS Waschmaschine in Hosentaschenformart die mit einer Powerbank betrieben werden kann. :)
Hi,
danke für die Erfahrungswerte. Die Last ist ja trotz dem relativ schwachen Pi Zero recht gering. Ist v.a. interessant, da die Preise für einen Raspi 3 oder 4 ja massiv in die Höhe geschnellt sind.
Gruß,
Jan
Hi Super Anleitung …. Danke dafür,
natürlich habe ich auch noch eine frage dazu, wie bekomme ich es denn eingerichtet das meine localen adressen auch wieder aufgelöst werden ? z.B fritz.box oder server_xyz.fritz.box usw
Ich nutze Adguard Home und den dnscrypt-proxy an einer FritzBox 7590. Ich denke da muss ich wohl noch irgendetwas in meiner config anpassen nur weiß ich da nicht was da noch mit reinmuss damit der proxy die localen adressen mit auflöst.
Gruß Ralf
Hi Ralf,
zu Adguard kann ich leider nichts sagen, aber im Pi hole ist dies eine spezielle Option (Settings > DNS > Conditional Forwarding): Hier „verknüpfst“ du dein Netzwerk-Segment mit einem Local Domain Name.
Evtl. gibt es etwas vergleichbares auch bei Adguard.
Gruß,
Jan
Hi ich nochmal,
also wenn ich in der Konsole den dig befehl absetze dann kommt da eine NXDOMAIN raus, wie soll der dnscrypt-proxy das auch auflösen denn es ist ja nicht dafür hinterlegt, bei Adguard gibt es diese Funktion auch und funktioniert auch… allerdings holt sich Adguard wie auch PiHole nur die DNS Namen allerdings kann ich nicht im Browser x-y-z.fritz.box aufrufen denn da spielt der dnscrypt-proxy nicht mit.
eventuell hat du da ja noch eine Idee damit das wieder läuft … Danke für deine Geduld
pi@raspberrypi:~ $ dig x-y-z.fritz.box @127.0.0.1 -p 65054
; <> DiG 9.11.5-P4-5.1+deb10u6-Debian <> x-y-z.fritz.box @127.0.0.1 -p 65054
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10926
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;x-qnas.fritz.box. IN A
;; AUTHORITY SECTION:
box. 600 IN SOA ns0.centralnic.net. hostmaster.centralnic.net. 1642235321 900 1800 6048000 3600
;; Query time: 37 msec
;; SERVER: 127.0.0.1#65054(127.0.0.1)
;; WHEN: Sat Jan 15 10:12:09 CET 2022
;; MSG SIZE rcvd: 110
Hi Ralf,
also ein
ping rechner.fritz.boxwird bei mir lokal korrekt aufgelöst. Wenn ich dich recht verstanden habe, ist das bei dir nicht der Fall.Ich denke, das ist eine Einstellung in Pi hole. Wenn er Anfragen zu der lokalen Domain „fritz-box“ bekommt, darf er das gar nicht an dnscrypt-proxy weiterleiten (dieser kann das in keinem Fall auflösen), sondern muss „direkt“ die richtige IP ausspucken.
Gruß,
Jan
Hi,
kurze Rückmeldung meinerseits, du hast mich auf den richtigen Weg gebracht. Ich habe den Raspi nochmal komplett neu gemacht und nutze nun Adguard mit dnscrypt-proxy ohne Probleme, nun läuft auch alles wie es soll
Danke
Hi Ralf,
ok, danke für die Rückmeldung. Welche Einstellung war es denn? Oder war es einfach „die Magie der Neuinstallation“? ;-)
Gruß,
Jan
Ich glaube das es daran gelegen hat das ich das System ( vorher mit Pihole und Unbound ) in irgendeiner Form von mir verbastelt war. Also ja es scheint die Magie der Neuinstallation zu sein. Nun läuft Adguard-Home mit Dnscrypt-Proxy …. Die Namen werden auch gut Aufgelöst nur leider nicht mit Ipv6 das scheint etwas komplexer zu sein. In Adguard-Home musste ich noch zwei Einträge in den ‚ Private inverse DNS-Server ‚ einstellen :
[/168.192.in-addr.arpa/]192.168.0.1
[/fritz.box/]192.168.0.1
danach hat zumindest mit Ip4 alles funktioniert, damit es mit Ipv6 funktioniert sollte es eigentlich so aussehen:
[/0.0.d.f.ip6.arpa/]fd00::dg39:6fdf:fe286:4f27
[/fritz.box/]fd00::dg39:6fdf:fe286:4f27
das hat allerdings nicht funktioniert, beides sind die lokalen Adressen von der FritzBox. Alles in allen ist es aber OK so wie es jetzt ist, bin halt nur etwas gebrandmarkt weil ich einen Glasfaseranschluss habe und ohnehin mit Ipv6 auf Kriegsfuß stehe.
Gruß Ralf
# DecaTec: Configure nonymized DNS (DNSCrypt and ODoH) – nehme an, dass „anonymized“ im verlinken Config-File gemeint ist. (siehe Link im Artikel zum File dnscrypt-proxy.toml). Der DNSCrypt-Proxy läuft auf meinem RasPI mit PI-Hole zuverlässig. Nutze FritzBox „nur“ als Gateway zum Provider und zusätzlich diverse DNS-Profile auf z.B. Smartphones um auch dort Tracking und Werbung einzudämpfen. Danke für den ausführlichen Artikel – das LOG auf dem PI-Hole spricht Bände!
Frage: Nutzt jemand den DNSCryp-Proxy mit ufw/iptables? -> Zulassen des Ports für DNs-Proxy wäre dann ->
sudo ufw allow from 192.168.178.0/24 to any port 65054
Gruß, Markus
Hi Markus,
danke für den Hinweis, habe es gleich mal im Repo geändert.
Und ja, die ufw-Freigabe funktioniert so, habe ich auch schon gemacht, wenn man mehrere dnscrypt-proxy Instanzen auf mehreren Maschinen betreibt. Hier müssen dann aber noch die
listen_adressesangepasst werden, so dass der dnscrypt-proxy nicht ausschließlich auf localhost hört.Gruß,
Jan
Guten Tag,
wie gliedert sich denn unbound in die ganze Thematik und ist dnsCrypt bei unbound überhaupt notwendig?
Viele Grüße
Hi John,
unbound nutzt ja keinen Upstream-DNS-Server, sondern „hangelt“ sich von einem Top Level Domain Server zur eigentlichen Domain und cacht dann das Ergebnis, da diese DNS-Anfragen länger dauern.
dnscrypt-proxy kann auch mit unbound verknüpft werden. Pihole fragt dann bei dnscrypt-proxy nach, dieser nutzt wiederum unbound. Wie das ganze aussehen kann, ist z.B. hier beschrieben.
Gruß,
Jan
danke für die Anleitung :)
Danke für die tolle(n) Anleitung(en).
Macht wirklich Spaß es zu lesen und „nachzubauen“.
Meine Frage an der Stelle.
Macht es mehr Sinn es auf die genannte Weise umzusetzen, oder doch eher auf Unbound zu setzen? Unbound wird ja in Zusammenhang mit Pi Hole oft als die „perfekte“ Variante angesehen (vgl. Kuketz-Blog-Forum usw.).
Ich selbst habe dafür zu wenig Wissen um mir darüber eine Meinung bilden zu können – daher hier die Nachfrage.
Hi,
in der hier gezeigten Variante nutzt du DNS-Server, die durch andere Leute/Firmen bereit gestellt werden. Auch wenn dnscrypt-proxy hier für Privatsphäre sorgt, musst du den DNS-Server-Betreibern vertrauen. Wenn dir diese falsche Daten liefern, dann kannst du dagegen nichts tun.
Bei Unbound nutzt du dagegen Root-Nameserver. Diese unterliegen stärkeren Kontrollen – das muss auch so sein, da hier ja „die komplette Wahrheit“ des Internets liegt. Jedoch kann eine solche DNS-Anfrage dann nicht einfach in einem Schritt beantwortet werden, sondern es sind mehrere Schritte notwendig. Das ist erst einmal langsamer, aber Unbound cacht hier ja fleißig. Damit betreibst du dann quasi deinen eigenen lokalen DNS-Server.
Welche Variante nun besser/schneller ist, kann man denke ich pauschal nicht sagen. Hier muss man einfach mal beide Varianten verproben.
Gruß,
Jan
Hallo,
ich möchte mich erstmal für die gelungene Anleitung und ausführliche erklärung bedanken.
Ich habe ein Intel NUC auf dem ich ein esxi 6.7 laufen habe.
Hier habe ich ein Debian 11 genommen um den dnscrypt-proxy zu installieren.
Nun bekomme ich bei sudo ./dnscrypt-proxy folgenden Fehler
./dnscrypt-proxy: 1:ELF: not found
./dnscrypt-proxy: 2: A▒: not found
./dnscrypt-proxy: 3: AA▒▒▒▒: not found
./dnscrypt-proxy: 4: Syntax error: „(“ unexpected
Hat jemand eine Idee oder sollte ich das Betriebssystem auf Ubuntu lts wechseln? Oder nutze ich hier das falsche Paket?
Hi,
der Fehler scheint hier beschrieben zu sein. Wie es aussieht, nutzt du wirklich das falsche Paket für OS und CPU. Einfach mal das passende wählen und nochmal probieren.
Gruß,
Jan
Aber welches ist das richtige Paket?🤔
Ich hab schon ein anderes ausprobiert und bekomme dort auch Fehler.
Werde es heute nochmal prüfen 👍🏼
Hi,
also ich hätte nun auch gesagt, dass es das „linux_x86_64“ Paket sein sollte. Oder nutzt du ein 32 Bit Debian?
Gruß,
Jan
Hey Jan,
ich habe mich mal dran gemacht und habe bis zum Punkt „Test der Funktion“ in ein Script gepackt.
Vorteil ist hierbei, dass man in Zeile 2-4 einfach Paket, Version und CPU Architektur anpassen kann.
Nun werde ich erstmal was essen und später mal weiter „spielen“ :-)
#################################################################
#Per ssh eine .sh erstellen
#sudo nano dnscrypt_install.sh (Text ab #!/bin/bash einfügen)
#sudo chmod +x dnscrypt_install.sh
###############################################################
#!/bin/bash
dnscrypt=“dnscrypt-proxy-linux_i386-2.1.1.tar.gz“ # dnscrypt Paket
version=“2.1.1″ # Version des dnscrypt Paket
cpu=“linux-i386″ # CPU Architektur des dnscrypt Paket
sudo wget https://github.com/DNSCrypt/dnscrypt-proxy/releases/download/$version/$dnscrypt
sudo tar -xf $dnscrypt
sudo rm $dnscrypt
sudo mv $cpu/ /opt/dnscrypt-proxy
cd /opt/dnscrypt-proxy
#config von DecaTec
sudo wget https://codeberg.org/DecaTec/dnscrypt-proxy-config/archive/master.tar.gz
sudo tar -xf master.tar.gz
sudo mv /opt/dnscrypt-proxy/dnscrypt-proxy-config/dnscrypt-proxy.toml /opt/dnscrypt-proxy/dnscrypt-proxy.toml
sudo rm -r dnscrypt-proxy-config && sudo rm master.tar.gz
sudo ./dnscrypt-proxy
Hi,
OK, cool. Sag mal Bescheid, ob es mit einer anderen Version/Architektur klappt, würde mich interessieren.
Gruß,
Jan
hallo, ist es normal, dass diese Testseite keine sichere DNS Verbindung nach Einrichtung von dnscrypt mehr auflösen kann? Wie sieht es bei euch aus?
https://rootcanary.org/test.html
Hi,
ich teste das immer über diese Seite: https://dnssec.vs.uni-due.de/
Hier (und auch auf der Seite, die du verlinkt hast), bekomme ich ein positives Ergebnis.
Ich vermute mal, dass hier etwas an deiner Konfiguration noch nicht zu 100% passt. Steht in deiner dnscrypt-proxy.toml die Option“require_dnssec“ auf true? Ist DNSSEC in den Optionen des Pi-hole aktiviert (obwohl dies hier eigentlich nicht mehr notwendig ist).
Gruß,
Jan
ich bekomme bei: dig @127.0.0.1 -p 65054 decatec.de
als Antwort:
;; ANSWER SECTION:
decatec.de. 76822 IN A 202.61.232.157
wo ist mein Fehler?
Hi Thomas,
das ist kein Fehler, sondern die Website ist letzte Woche umgezogen, daher die andere IP-Adresse.
Ich habe es im Artikel mal angepasst. Danke für den Hinweis!
Gruß,
Jan
Ok, danke gleichfalls ;)
Danke für die super Anleitung! Ich habe heute allerdings eine interessante Entdeckung gemacht:
Ich verwende dnscrypt mit der hier empfohlenen config als nameserver aus meinem Pi-Hole, der wiederum als nameserver auf meiner FritzBox eingetragen ist die an der Telekom als ISP hängt.
Standardmäßig war auf unseren Androids WLAN-Anrufe aktiviert, das funktioniert auch outgoing, nur bei der Anruf-Annahme wird der Anruf einfach nicht angenommen. Bei der Recherche fand ich Hinweise auf Probleme an der Stelle mit Vodafone, aber bisher nichts für die Telekom. Hat jemand ähnliche Beobachtungen, bzw. gibt’s einen Workaround? Die Hinweise bei Vodafone zeigen Richtung Cloudflare, odoh-cloudflare steht in meinen server_names, aber dnscrypt nimmt ja den schnellsten aus der Liste wenn ich das richtig sehe…?
Hi Armin,
ich würde da erst einmal am Pi-Hole selbst prüfen, ob hier etwas geblockt wird, wenn ein Anruf angenommen werden soll. Evtl. auch mal einen „einfachen“ DNS-Upstream im Pihole eintragen (zur Not 1.1.1.1 oder 8.8.8.8) und dann mal damit testen. Dann sollte man auf jeden Fall schon mal ein System als dasjenige erkennen, was für dieses Verhalten zuständig ist.
Auf jeden Fall interessante Sache, halte uns doch mal auf dem Laufenden.
Gruß,
Jan
‚dnswarden-eu-uncensor-dcv4′, ’sicher-surfen-de‘ scheinen nicht mehr zu existieren.
Gibt es vielleicht eine aktualisierte config?
Danke!
Hi,
danke für den Hinweis. Ich habe das gleich mal aktualisiert.
Statt „dnswarden-eu-uncensor-dcv4“ nutze ich nun „dnswarden-uncensor-dc“.
„sicher-surfen-de“ habe ich durch „dotya.ml-ipv6“ ersetzt.
Gruß,
Jan
Ah super, ich habe statt dotya.ml-ipv6 die ipv4-Variante genommen.
Was mir noch aufgefallen ist, sind diese Logeinträge:
„`
Wed Nov 2 01:35:56 2022 daemon.err dnscrypt-proxy[21913]: [2022-11-02 00:35:56] [WARNING] Failed to receive successful response from [odoh-koki-ams]
Wed Nov 2 01:36:01 2022 daemon.err dnscrypt-proxy[21913]: [2022-11-02 00:36:01] [WARNING] Failed to receive successful response from [odoh-koki-ams]
Wed Nov 2 01:36:05 2022 daemon.err dnscrypt-proxy[21913]: [2022-11-02 00:36:05] [WARNING] Failed to receive successful response from [odoh-koki-ams]
„`
Konntest Du das auch beobachten?
Hi,
ja, das kommt auch in meinen Logs. Da es aber nicht eine so große Auswahl an ODOH-Servern gibt, bin ich erst einmal dabei geblieben.
Gruß,
Jan
Schau mal hier; ich habe deswegen odoh erst einmal deaktiviert: https://github.com/DNSCrypt/dnscrypt-resolvers/issues/751
Hi,
ist auch fraglich, ob odohrelay-crypto-sx und odohrelay-surf noch existieren, denn diese werden nicht mehr in der Liste von DNScrypt-proxy ggeführt.
Gruß,
Jan
Zunächst vielen Dank für die Anleitung.
Ich habe ein Problem wenn ich sudo ./dnscrypt-proxy ausführe, bekomme ich immer abwechselnd:
[ERROR] Non-existent relay set for server [odoh-cloudflare] oder auch mal [cs-de].
[NOTICE] dnscrypt-proxy is waiting for at least one server to be reachable.
die Relays sind aber konfiguriert wie in deinem Bsp.
Hat jemand eine Idee?
Sooo anscheinend hat es mit dem server_name zu tun. kann mir jemand sagen was der unterschied zwischen
{ server_name=’odoh-cloudflare‘, via=[‚odohrelay-crypto-sx‘, ‚odohrelay-surf‘] }
und
{ server_name=’odoh-cloudflare‘, via=[’sdns://BQcAAAAAAAAAF29kb2guY2xvdWRmbGFyZS1kbnMuY29tCi9kbnMtcXVlcnk‘] }
ist?
Wenn ich ersteres verwende scheint es zu funktionieren. Wo bekomme ich denn die Server her in https://dnscrypt.info/public-servers/ stehen leider nur die sdns.
Letzte Frage wie kann ich -dnscrypt-proxy testen?
Wenn ich https://www.dnsleaktest.com aufrufe sehe ich meine IP bzw. keine Veränderung.
nochmals vielen Dank und einen Guten Rutsch ins Neue Jahr!
Hi Sven,
hast du die Config aus dem Codeberg-Repo genommen? Diese sollte auf jeden Fall aktuell sein.
In der Liste der Public Server sehe ich gar keine odoh-Relays. Diese zeiht er sich eigentlich auch von hier. Wichtig ist in der Cofig daher die Sektion
[sources.'odoh-relays'], hier findet diese Verknüpfung statt.Testen kann man das meines Wissens nach nur wie im Artikel beschrieben – also ob die DNS-Auflösung funktioniert. Beim DNS-Leak-Test werden die genutzten DNS-Server angezeigt. Sind diese bei dir plausibel, oder sind das z.B. die IP-Adressen deines ISP?
Gruß,
Jan
Hi Jan,
Danke dir vielmals hab den Fehler gefunden.
Ja meine IP wird angezeigt. Nach meinem Verständnis sollte doch die IP vom DNS Server angezeigt werden.
Und nochmal vielen Dank für die Config.
Liebe Grüße
Sven
Hi Jan
gibt es eine Möglichkeit. Adlists zu vergleichen, sodass redundante Adlists rausfliegen. Z.B. habe ich deutlich mehr Domains als Unique Domains.
Viele Grüße
Tom
Hi Tom,
das ist bei Pi-hole gar nicht notwendig, da die herunter geladenen Adlists automatisch gemerged werden. Hier ist also kein manuelles Eingreifen notwendig.
Gruß,
Jan
Hallo,
ich bin am verzweifeln…ich bin Anfänger und bekomme es einfach nicht hin…..ich habe alles genau nach ihrer Anleitung etc kopiert
(…bei mir läuft pihole im Docker auf meiner Synology und MacvLan mit fester IP….)
Wenn ich „dig @127.0.0.1 -p 65054 decatec.de“ auf meiner Synology ausführe funktioniert es nicht weil er das dig-Kommando nicht mag….:
Stefan@DiskStation:/opt/dnscrypt-proxy$ dig @127.0.0.1 -p 65054 decatec.de
-sh: dig: command not found
Wenn ich auf meinem Mac „dig @127.0.0.1 -p 65054 decatec.de“ ausführe komme ich :
<> DiG 9.10.6 <> @127.0.0.1 -p 65054 decatec.de
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
Wenn ich „sudo /opt/dnscrypt-proxy/dnscrypt-proxy -resolve google.de“ auf meiner DiskStation ausführe bekomme ich aber:
„Stefan@DiskStation:/opt/dnscrypt-proxy$ sudo /opt/dnscrypt-proxy/dnscrypt-proxy -resolve google.de
Resolving [google.de] using 127.0.0.1 port 65054
Resolver : 84.200.70.40
Canonical name: google.de.
IPv4 addresses: 142.251.111.94
IPv6 addresses: 2607:f8b0:4004:c09::5e
Name servers : ns1.google.com., ns3.google.com., ns2.google.com., ns4.google.com.
DNSSEC signed : no
Mail servers : 1 mail servers found
HTTPS alias : –
HTTPS info : –
Host info : –
TXT records : v=spf1 -all
“
Was mache ich falsch…?
….ich bin blutiger Anfänger und weiss nicht weiter…und bitte um Hilfe für Dummies…….
Hi,
„dig“ scheint es auf der Synology selbst nicht zu geben, evtl. kann dies aber mit einem Paket eines Drittanbieters nachinstalliert werden.
Auf dem Mac geht das auf diese Art und Weise auch nicht, da der DNScrypt-proxy ja nicht lokal (127.0.0.1) läuft. Hier müsste man die IP des Servers angeben, auf dem DNScrypt-Proxy läuft (und hier darf der Port nicht blockiert werden).
Der Test an sich ist auch gar nicht so wichtig, wenn du DNScrypt-Proxy als einzigen Upstream-DNS-Server im Pi-hole eingerichtet hast und er eine DNS-Auflösung hinbekommt, dann funktioniert das auch – ist dann quasi eher ein indirekter Test.
Gruß,
Jan
…habe es soeben im Pihole getestet (ohne Unbound)….löst aber nicht auf……kann keine Webseite öffnen….
Was kann ich machen..?
Hi,
ein „nslookup“ dürfte aber auf der Synology vorhanden sein, dann würde ich das mal damit probieren.
Das wird dann aber vermutlich auch nicht funktionieren. Hier am besten mal DNScrypt-proxy manuell starten wie im Artikel beschrieben („./dnscrypt-proxy“) und hier auf den Output schauen, ob z.B. eine Fehlermeldung ausgeworfen wird.
Gruß,
Jan
…wenn ich aus der Synology :
„Stefan@DiskStation:/opt/dnscrypt-proxy$ sudo /opt/dnscrypt-proxy/dnscrypt-proxy -resolve google.de“
eingebe, dann:
Resolving [google.de] using 127.0.0.1 port 65054
Resolver : 84.200.70.40
Canonical name: google.de.
IPv4 addresses: 172.253.63.94
IPv6 addresses: 2a00:1450:4001:82b::2003
Name servers : ns4.google.com., ns3.google.com., ns1.google.com., ns2.google.com.
DNSSEC signed : no
Mail servers : 1 mail servers found
HTTPS alias : –
HTTPS info : –
Host info : –
TXT records : v=spf1 -all
…???
Ich verstehe es nicht…….
…hat niemena eine Idee woran es liegen kann?
– dnscrypt-proxy auch neu gestartete ..
– im log auch alles okay…denke ich…?
(2023-01-16 18:36:53] [NOTICE] dnscrypt-proxy 2.1.2
[2023-01-16 18:36:53] [NOTICE] Network connectivity detected
[2023-01-16 18:36:53] [NOTICE] Now listening to 127.0.0.1:65054 [UDP]
[2023-01-16 18:36:53] [NOTICE] Now listening to 127.0.0.1:65054 [TCP]
[2023-01-16 18:36:53] [NOTICE] Now listening to [::1]:65054 [UDP]
[2023-01-16 18:36:53] [NOTICE] Now listening to [::1]:65054 [TCP]
[2023-01-16 18:36:53] [NOTICE] Source [public-resolvers] loaded
[2023-01-16 18:36:53] [NOTICE] Source [relays] loaded
[2023-01-16 18:36:53] [NOTICE] Source [odoh-servers] loaded
[2023-01-16 18:36:53] [NOTICE] Source [odoh-relays] loaded
[2023-01-16 18:36:54] [NOTICE] Anonymized DNS: routing [dns.watch] via [anon-pwoss.org anon-cs->
[2023-01-16 18:36:54] [NOTICE] Anonymized DNS: routing [dns.watch-ipv6] via [anon-pwoss.org ano>
[2023-01-16 18:36:54] [NOTICE] Anonymized DNS: routing [cs-dus2] via [anon-pwoss.org anon-pf]
[2023-01-16 18:36:54] [NOTICE] Anonymized DNS: routing [odoh-koki-ams] via [odohrelay-crypto-sx>
[2023-01-16 18:36:54] [NOTICE] Anonymized DNS: routing [odoh-cloudflare] via [odohrelay-crypto->
[2023-01-16 18:36:54] [NOTICE] Anonymized DNS: routing [cs-berlin] via [anon-pwoss.org anon-pf]
[2023-01-16 18:36:54] [NOTICE] Anonymized DNS: routing [dnscrypt-de-blahdns-ipv6] via [anon-pwo>
[2023-01-16 18:36:54] [NOTICE] Anonymized DNS: routing [cs-dus4] via [anon-pwoss.org anon-pf]
[2023-01-16 18:36:54] [NOTICE] Anonymized DNS: routing [cs-dus1] via [anon-pwoss.org anon-pf]
[2023-01-16 18:36:54] [NOTICE] Anonymized DNS: routing [cs-de] via [anon-pwoss.org anon-pf]
[2023-01-16 18:36:54] [NOTICE] Anonymized DNS: routing [dnscrypt-de-blahdns-ipv4] via [anon-pwo>
[2023-01-16 18:36:54] [NOTICE] Anonymized DNS: routing [dnswarden-uncensor-dc] via [anon-pwoss.>
[2023-01-16 18:36:54] [NOTICE] Firefox workaround initialized
[2023-01-16 18:36:54] [NOTICE] Anonymizing queries for [dnscrypt-de-blahdns-ipv4] via [anon-cs->
[2023-01-16 18:36:54] [NOTICE] [dnscrypt-de-blahdns-ipv4] OK (DNSCrypt) – rtt: 36ms
[2023-01-16 18:36:54] [NOTICE] Anonymizing queries for [dns.watch-ipv6] via [anon-cs-dus1]
[2023-01-16 18:37:05] [NOTICE] [dns.watch-ipv6] TIMEOUT
[2023-01-16 18:37:05] [NOTICE] Anonymizing queries for [odoh-cloudflare] via [odohrelay-crypto->
[2023-01-16 18:37:10] [NOTICE] [odoh-cloudflare] OK (ODoH) – rtt: 41ms
[2023-01-16 18:37:10] [NOTICE] Anonymizing queries for [dnscrypt-de-blahdns-ipv6] via [anon-cs->)
….Mein Unbound (IP: 0.0.0.#53) funktioniert tadellos…
…der dnycrypt (127.0.0.1#65054) löst nur intern auf…woran kann das noch liegen…
…bin für jede Idee dankbar…
Gruß
Stefan
Hi Stefan,
du hast DNScrypt-Proxy direkt auf der Synology installiert? Hier wäre ich etwas vorsichtig, nicht, dass dies nach einem Synology Update dann wieder weg ist. Auf der Synology würde ich nur Pakete über die Paketverwaltung (UI) installieren.
Auf jeden Fall funktioniert die Auflösung auf der Syno selbst, von anderen Maschinen aber nicht? In diesem Fall mal den Wert für „listen_addresses“ in der DNScrypt-Proxy-Konfig prüfen. Wenn er hier nur auf die lokalen IPs lauscht (127.0.0.1, [::1]), dann werden Anfragen von anderen Geräten im LAN nicht beantwortet. Hier muss der dann auf die „echten“ IPs lauschen. Dann sollte das eigentlich gehen.
Zu Unbound kann ich leider nichts sagen, damit habe ich leider keine Erfahrungen.
Gruß,
Jan
Doofe Frage: wenn ich Internet.nl aufrufe und meine Verbindung testen lasse, dann sagt mir die Meldung, dass DNSSEC nicht geprüft wird. Aber wird ja, oder? Steht ja in der Confog, dass der Resolver das prüfen muss. Nur der Relay und damit der angesprochene DNS Server macht es nicht? Oder verstehe ich was falsch?
Hi Thorsten,
also bei mir wird angezeigt, dass DNSSEC verwendet wird. Bei diesem Test bekomme ich dann die 100%.
Hast du DNSSEC beim Pihole vielleicht deaktiviert? Versuche es dann hier mal zu aktivieren.
Gruß,
Jan
Da die Server immer wechsel ist es Zufall, wenn es angezeigt wird. Aktuell erreiche ich auch wieder 100% bei CLOUDFLARENET. Wenn DNSSEC versagt, dann zweigt er M237 o.ä. als DNS Provider an.
Hi Thorsten,
da wird es dann nur helfen, andere Upstream-DNS-Server zu nutzen.
Gruß,
Jan