Anleitung für dns-crypt

[debiator]

Hallölchen!

Ich habe hier nichts dazu gefunden und da ich vor kurzem dnscrypt bei mir eingerichtet habe, dachte ich mir, vielleicht ist es für den einen oder anderen brauchbar.
Ohne das verschlüsselte DNS halte ich das Surfen heutzutage für unsinnig. Vor allem, weil die Einrichtung so einfach funktioniert.

build-essential installieren (falls noch nicht vorhanden)
Dann

Code: Alles auswählen

wget http://download.libsodium.org/libsodium/releases/libsodium-0.7.0.tar.gz -O - | tar -xz

Mit dem Befehl cd libsodium-0.7.0/ bewegt man sich in den heruntergeladenen Ordner.
Mit dem Befehl ./configure && make bereitet man die Installation vor.
Mit sudo make install installiert man das nötige Verschlüsselungs-Paket libsodium.
ldconfig liest die Verknüpfungen im System neu ein.
Mit cd .. bewegt man sich aus dem Ordner einen Schritt raus/zurück
und mit rm -rf libsodium* löscht man das installierte und nicht mehr benötigte Archiv.

Das Gleiche macht man mit

Code: Alles auswählen

wget http://download.dnscrypt.org/dnscrypt-proxy/dnscrypt-proxy-1.6.0.tar.gz -O - | tar -xz

Bei libsodium gibt es höhere Versionen, sie funktionieren allerdings nicht mit dem dnscrypt-proxy.

Jetzt braucht man nur noch einen öffentlichen DNS-resolver, der dns-crypt unterstützt.
Ich bin bei dem öffentlichen von ovpn gelandet.
Unter /usr/local/share/dnscrypt-proxy/dnscrypt-resolvers.csv findet ihr aber eine Liste mit den Resolvern,
non-logged sind natürlich sinnvoller.

Wer die Liste von hier haben will, der ersetzt sie einfach:
https://github.com/jedisct1/dnscrypt-pr ... olvers.csv

Folgende Befehlszeile mit sudo/su bzw. root ausführen um zu starten (den Resolver nach Belieben aus der Liste anpassen):

Code: Alles auswählen

dnscrypt-proxy -a 127.0.0.1:53 -R dnscrypt.eu-dk

Dann noch die gleiche Zeile in den Autostart stellen, indem man die /etc/rc.local bearbeitet und vor exit 0 die obere Zeile kopiert.

Am Ende stellt man in den Netzwerkeinstellungen den DNS-Server auf 127.0.0.1 also localhost und passt gegebenenfalls die Firewall an.
Port 53 (wäre eh für DNS offen) und 5353 von der internen IP-Adresse "192.whatever" nur(!) zu der IP-Adresse des Resolvers.

Fertig ist der verschlüsselte DNS-Transfer!
Hier kann man es testen:
https://dnsleaktest.com/

Falls etwas fehlt oder in Eile fehlerhaft ist, bitte ergänzen und korrigieren.

\EDIT:

Das Addon DNSSEC/TLSA Validator für Firefox veranstaltet einen ordentlichen DNS-Leak, da DNSSEC am lokal gebundenen DNS-Server vorbei geht und sich direkt mit den Seiten verbindet.
Wer also sein DNS in unverschlüsselter Art NICHT durch die Gegend schicken will, sollte auch auf seine Addons achten und es mit Wireshark (oder tcpdump) gegenchecken!
Im Wireshark als Filter dns eingeben und schauen, ob über den DNS-Port-53 etwas übertragen wird. Das dürfte nicht sein, denn alles läuft lokal über 53 und wird weiter mit dnscrypt über 443 oder sonst was verschlüsselt weiter geschickt.

[dufty2]

Gibt es als Debian-Paket bereits, zuminderst für testing & unstable

[debiator]

ich finde, das müsste heutzutage in die grafische Desktopumgebung integriert sein. Damit es "Massentauglichkeit" hat. Bis jetzt ist dns-crypt etwas exotisches, obwohl es so selbstverständlich ist und durchaus vor einigen Lauschereien und Angriffen schützt.

[debiator]

Was ich nicht ganz verstehe.

Wenn ich in meiner Firewall 53UDP zwischen WAN und LAN blocke, dann verbindet er zwar nach einer Weile, aber der Browser hängt sich für längere Zeit immer wieder auf.
Wie und warum kommt das Zustande?? Er dürfte wenn, dann gar keine Verbindung aufbauen, aber warum dann so seltsam verzögert?

Die andere Sache ist, wenn ich bei 127.0.0.1:53 statt 53 443 angebe und davor -T (nur TCP nutzen) tippe, verbindet er gar nicht. Kann man denn DNS nicht über TCP schicken und wenn ja wie?
Ich meine irgendwo gelesen zu haben, dass DNS über TCP sicherer ist als UDP.

[Cae]

Kann man denn DNS nicht über TCP schicken und wenn ja wie?
Ich meine irgendwo gelesen zu haben, dass DNS über TCP sicherer ist als UDP.

Doch, DNS verwendet TCP, sobald die Antwort zu gross fuer ein einzelnes UDP-Paket wird (z.B. bei Zonen-Transfers oder vielen CNAMEs). Man kann auch grundsaetzlich TCP verwenden, aber das ist zwei bis drei roundtrips langsamer, weil die Verbindung (t wie transmission in TCP) erst aufgebaut werden muss. Dafuer hat man aber Fehlerkorrektur und retransmission, wenn noetig, In dieser Bezeiehung ist DNS via TCP "sicherer" (gegenueber wackeligen Leitungen; faelschen geht natuerlich immer noch problemlos).

Gruss Cae

[debiator]

ok, danke für die genaue Erklärung!
2-3 Roundtips ist gut... da hängt sich der ganze Browser auf, wenn ich die meisten Seiten lade.
Wahrscheinlich liegt es am Pipelining, welches ich eingeschalten habe und network.http.pipelining.maxrequests auf 8 gesetzt habe.

hmm.. ist Fälschen bei verschlüsseltem DNS-Transfer immer noch möglich?

[mat6937]

hmm.. ist Fälschen bei verschlüsseltem DNS-Transfer immer noch möglich?

Hier könnte man evtl. dnssec (wenn möglich) verwenden. Z. B.:

Code: Alles auswählen

dig -4 +tcp +dnssec bund.de @8.8.8.8

[debiator]

Code: Alles auswählen

Connection to 8.8.8.8#53(8.8.8.8) for bund.de failed: connection refused.

[mat6937]

Code: Alles auswählen

Connection to 8.8.8.8#53(8.8.8.8) for bund.de failed: connection refused.

Dann ohne 8.8.8.8, d. h. nur zu deinem dns-Proxy:
ohne tcp:

Code: Alles auswählen

dig -4 +dnssec bund.de

mit tcp:

Code: Alles auswählen

dig -4 +tcp +dnssec bund.de

evtl. auch:

Code: Alles auswählen

dig -4 +tcp +dnssec bund.de @127.0.0.1

wenn 127.0.0.1 auch auf dem tcp-Port 53 lauscht.

EDIT:

... wenn dein dns-proxy auch "DNSSEC-capable upstream nameserver" nutzt und der dns-proxy auch für "DNSSEC requires" geeignet ist.

[debiator]

hmmm also das

Code: Alles auswählen

dig -4 +dnssec bund.de

gibt das aus:

Code: Alles auswählen

; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> -4 +dnssec bund.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8025
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;bund.de.			IN	A

;; ANSWER SECTION:
bund.de.		21600	IN	A	77.87.229.48
bund.de.		21600	IN	RRSIG	A 7 2 21600 20151017083001 20151007083001 47369 bund.de. uPgeeBuoIHZD1h+b8QpgYGxoWWTBxx9qTMz2D8dQjFqzQP4tEj63kn5A +iItU/uBsYBv8MeBrxCjKHC2tpEvcIWBkKuJd8OnQRzTA7PJAEXJPLHn u7goqeoKYrv8KG6vIMBZa0VP98+Fi6gIQf+UXaHqpCw+raWWC8oaJZZv +DQ=

;; AUTHORITY SECTION:
bund.de.		21600	IN	NS	argon.bund.de.
bund.de.		21600	IN	NS	bamberg.bund.de.
bund.de.		21600	IN	NS	xenon.bund.de.
bund.de.		21600	IN	NS	nuernberg.bund.de.
bund.de.		21600	IN	NS	dns-1.dfn.de.
bund.de.		21600	IN	RRSIG	NS 7 2 21600 20151017083001 20151007083001 47369 bund.de. n2cImUHdZ6S/OV9opt/+NRigon2rISa6PHsD8TUWtSQ5bJ7l1NX6zgYB qrrzKsdjS1iIq6bj3Hvqq/FOUcUg46ZVgksF9ltUbR6AfYfdDz8LJNPX BdnLSpn1/d4G4N09dYtVtWseqMUCVyM+hG6gD1NGd1VVJNmV9y7couPW v7s=

;; ADDITIONAL SECTION:
argon.bund.de.		21600	IN	A	77.87.224.18
xenon.bund.de.		21600	IN	A	77.87.224.71
bamberg.bund.de.	21600	IN	A	77.87.228.36
nuernberg.bund.de.	21600	IN	A	77.87.228.37
argon.bund.de.		21600	IN	RRSIG	A 7 3 21600 20151017083001 20151007083001 47369 bund.de. fkWdRMPPxZB1UO3K3cy2h3JtteuujbsT/SVT662O3PljuvZ8Cyu6WRxH 7PNBu7G3C3hUzIuxF457Bu+yPQi93lFPYH5OgRU78ykI55tig/LoN2xj KhmLdstaGsKk7LwJ4iC2ISC1fDWA9hfPdm5wmEP0szaSjZEudgohT50c RkE=
xenon.bund.de.		21600	IN	RRSIG	A 7 3 21600 20151017083001 20151007083001 47369 bund.de. VroFp/8S1Ctb/THvrO28UoZmdlCdOUCCGRdj15XBaBQfI3mmo3kYsfi2 uZW2SUiLYJ8uQJ+Hpk3R41Ba8lpF1l2A6DDBsjo3jOctYaUKOLJwSCtx bRHX96Opsrv7G00rO2uZR2Wm5p9m9kkWlOaeahFaRwSbR6rojZzF80vc Yng=
bamberg.bund.de.	21600	IN	RRSIG	A 7 3 21600 20151017083001 20151007083001 47369 bund.de. nPK4BGb71aJcR1uuXmWwgtGolr71x6UdU0GC7DxQNf4j16GgKd916ml4 L1jCVS9OM0ogPgMDUE/jKtW4bDof4RWXrkH0EghvrYJ4fwBEAim1Sx8w h6htKW/8HDb5LLpi/dDBLnip2jHOqqiVLn+NH8BoozRg1DWllFCyn1Rr XI8=
nuernberg.bund.de.	21600	IN	RRSIG	A 7 3 21600 20151017083001 20151007083001 47369 bund.de. OhAVAAJXYtjnM7gCGM6ARna4xXJcvYRzxaa2LZKruVxwFYv15Ip0G2vZ VHqhkXpD2iYpGQDxVW2yOATMoy733gf7Fwm54E5+rmI+0wXJVy4e+ks3 LARsMF5HiRZ0niAnlFrCb3iWJ2OC5Z6JNQVMlhM306jNxVs7erGxZOxI XDM=

;; Query time: 1041 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 12 09:03:38 CEST 2015
;; MSG SIZE  rcvd: 1228

verstehe nicht ganz... d.h. er kann mit dnssec am dnscrypt einfach vorbei??

mit TCP (mit und ohne Verweis auf localhost) bricht die Connection ab, also nichts.

[mat6937]

hmmm also das

Code: Alles auswählen

dig -4 +dnssec bund.de

verstehe nicht ganz... d.h. er kann mit dnssec am dnscrypt einfach vorbei??

Nein, nicht vorbei. dnssec und dnscrypt ist gleichzeitig möglich. dnssec ist ja keine Verschlüsselung.

mit TCP (mit und ohne Verweis auf localhost) bricht die Connection ab, also nichts.

Wie sind die Ausgaben von:

Code: Alles auswählen

sudo netstat -tulpen | grep -i :53

Code: Alles auswählen

nc -v -n -z -w 1 8.8.8.8 53

Code: Alles auswählen

nc -v -n -z -w 1 127.0.0.1 53

?

[debiator]

naja... wenn dnssec unverschlüsselten DNS erlaubt (was ja vom Konzept her so ist) dann ist es ja im Grunde wie "vorbei".

Da DNS auf 53 läuft:

Code: Alles auswählen

tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      0          9107        683/dnscrypt-proxy
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           105        14386       670/avahi-daemon: r
udp        0      0 127.0.0.1:53            0.0.0.0:*                           0          9105        683/dnscrypt-proxy
udp6       0      0 :::5353                 :::*                                105        14387       670/avahi-daemon: r

bei

Code: Alles auswählen

nc -v -n -z -w 1 127.0.0.1 53

connection refused

bei

Code: Alles auswählen

nc -v -n -z -w 1 127.0.0.1 53

(UNKNOWN) [127.0.0.1] 53 (domain) open

[mat6937]

naja... wenn dnssec unverschlüsselten DNS erlaubt (was ja vom Konzept her so ist) dann ist es ja im Grunde wie "vorbei".

Bei dnssec geht es um Authentizität bzw. Integrität und btw., man kann auch etwas "Falsches per Verschlüsselung" übertragen. Der Anlass war ja deine Frage: "ist Fälschen bei verschlüsseltem DNS-Transfer immer noch möglich?".

Da DNS auf 53 läuft:

Code: Alles auswählen

tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      0          9107        683/dnscrypt-proxy
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           105        14386       670/avahi-daemon: r
udp        0      0 127.0.0.1:53            0.0.0.0:*                           0          9105        683/dnscrypt-proxy
udp6       0      0 :::5353                 :::*                                105        14387       670/avahi-daemon: r

bei

Code: Alles auswählen

nc -v -n -z -w 1 127.0.0.1 53

connection refused

bei

Code: Alles auswählen

nc -v -n -z -w 1 127.0.0.1 53

(UNKNOWN) [127.0.0.1] 53 (domain) open

D. h., auf tcp-Port 53 wird gelauscht, kann aber nicht genutzt werden.
So sollten die Antworten evtl. sein:

Code: Alles auswählen

:~$ nc -v -n -z -w 1 8.8.8.8 53
Connection to 8.8.8.8 53 port [tcp/*] succeeded!

Code: Alles auswählen

:~$ nc -v -n -z -w 1 127.0.0.1 53
Connection to 127.0.0.1 53 port [tcp/*] succeeded!

Code: Alles auswählen

:~$ dig +short +tcp +dnssec bund.de @127.0.0.1
77.87.229.48
A 7 2 ... ...

EDIT:

Mit z. B.:

Code: Alles auswählen

sudo tcpdump -vvveni any port 53

kannst Du den (möglichen/erlaubten/geblockten/...) Datenverkehr zum Port 53 und vom Port 53 (... lokal, im W/LAN bzw. ins/aus dem Internet), evtl. anzeigen lassen.

[debiator]

ja so weit kenn ich DNSsec, allerdings ist mir nicht klar, wie es mit dnscrypt arbeitet oder nicht arbeitet. Hast Du da noch ne Info? Danke!

was meinst Du mit "So sollten die Antworten evtl. sein"?
Falls man die 53er für etwas anderes als DNS nutzen könnte?

mit tcpdump auf 53 zeigt er mir jetzt die Auflösung der Seiten ohne Verschlüsselung.
Kann man das ebenfalls blocken? Wahrscheinlich nicht. Die Frage ist nur, warum kann ich den Verkehr nicht komplett durch dnscrypt durchleiten lassen.

[mat6937]

Falls man die 53er für etwas anderes als DNS nutzen könnte?

Warum sollte man das tun? Es gibt btw. auch Clients (die Namensauflösung anfordern/benötigen), die von sich aus den tcp-Port 53 und nicht den udp-Port 53 für die Namensauflösung nutzen wollen.

mit tcpdump auf 53 zeigt er mir jetzt die Auflösung der Seiten ohne Verschlüsselung.
Kann man das ebenfalls blocken? Wahrscheinlich nicht. Die Frage ist nur, warum kann ich den Verkehr nicht komplett durch dnscrypt durchleiten lassen.

Blocken und/oder evtl. besser auch umleiten der dns-Anfragen, kannst Du z. B. mit iptables, versuchen.

[Patsche]

Darf ich hier mal eine Zwischenfrage stellen?
Habe das mal getestet und bei mir funktioniert dnscrypt ganz gut nur die Handy's können das halt nicht. Wie kann ich dem Networkmanager grafisch mitteilen, dass er meinen manuellen DNS-Server nehmen soll? Er nimmt Standardmäßig immer den Server, den ich in meiner Fritzbox eingestellt habe, also nutzt Networkmanager den Server vom Gateway. Falls die Frage hier nicht erwünscht ist, dann bitte einfach verschieben. Danke für die Hilfe.

Edit:
Hat sich erledigt. Habe es jetzt doch selbst gefunden. Also für alle, die das grafisch umstellen wollen:
"Verbindungen bearbeiten" und dann unter den IPV-Einstellungen bei der Methode "Automatisch (DHCP), nur Adressen" auswählen. Danach kann man auch unten den DNS-Server eintragen. Das wars. Entschuldigt die Zwischenfrage :/

[debiator]

Warum sollte man das tun? Es gibt btw. auch Clients (die Namensauflösung anfordern/benötigen), die von sich aus den tcp-Port 53 und nicht den udp-Port 53 für die Namensauflösung nutzen wollen.

ich meine nur so, dass man 53er für etwas missbrauchen könnte, also andere Pakete als DNS-Anfragen darin tunneln.

Blocken und/oder evtl. besser auch umleiten der dns-Anfragen, kannst Du z. B. mit iptables, versuchen.

naja... ich kann das in meiner HW-Firewall blocken, hab ich ja auch probiert. Dann hängt sich der Browser immer wieder wegen hoher Anfragen über 53 auf, bis er dann irgendwann auf TCP umstellt. Also ist es leider ein no-go.

Die Frage ist, kann jemand bei mir dnscrypt mit Hilfe von dnssec umgehen? So ala dns-Leak.

Hat sich erledigt. Habe es jetzt doch selbst gefunden. Also für alle, die das grafisch umstellen wollen:
"Verbindungen bearbeiten" und dann unter den IPV-Einstellungen bei der Methode "Automatisch (DHCP), nur Adressen" auswählen. Danach kann man auch unten den DNS-Server eintragen. Das wars. Entschuldigt die Zwischenfrage :/

sehr schön, dass Du den Weg dazu gefunden hast. Diesen einfachen Standard sollten mehr Menschen nutzen!
DHCP ist an sich nicht gut. Konfiguriere das Netzwerk lieber manuell und schalte DHCP beim Router und auch in den Neztwerkeinstellungen des PCs/Smartphones ab.
Die IP-Vergabe hängt vom Gateway (Router/Modem) ab. Wenn er z.B. 192.168.178.1 hat, dann das als Gateyway eingeben und 192.168.178.2 als IP des PCs eingeben 192.168.178.3 als die des Smartphones und so weiter. Subnetz kann 255.255.255.0 sein.

[mat6937]

Die Frage ist, kann jemand bei mir dnscrypt mit Hilfe von dnssec umgehen?

Ja, das sollte auch ohne dnssec möglich sein. Z. B. kann man (auch im Internet) einen DNS-Server/Resolver, u. a. auch auf den TCP-Ports 80 oder 443 lauschen lassen.

[debiator]

Die Frage ist, kann jemand bei mir dnscrypt mit Hilfe von dnssec umgehen?

Ja, das sollte auch ohne dnssec möglich sein. Z. B. kann man (auch im Internet) einen DNS-Server/Resolver, u. a. auch auf den TCP-Ports 80 oder 443 lauschen lassen.

Dafür müsste man bei mir auf dem Rechner Einstellungen vornehmen, richtig?
Es ist von außen aber nicht möglich.

[mat6937]

Dafür müsste man bei mir auf dem Rechner Einstellungen vornehmen, richtig?

Oder code bzw. ein Script auf deinem Rechner ausführen.

Es ist von außen aber nicht möglich.

Das wird davon abhängig sein, wie dein Browser konfiguriert ist.

[debiator]

hmm.. ja gut.. klar. Der Browser müsste, so weit wie es für einen Browser geht, dicht sein.

Jetzt mal kurz zurück zum dns-crypt.
Ich habe da etwas durcheinander gebracht, als ich weiter an den Einstellungen gepfuscht hab.

Was ist mit den dnscrypt-proxy.socket und dnscrypt-proxy.service? Wo müssen diese Dateien sein?
Ich habe ja nur die rc.local angepasst, aber etwas scheint da nicht zu stimmen.

\Edit: vor allem, wie schaffe ich es, den nicht auf 53 laufen zu lassen sondern auf einem anderen Port??
wenn ich die Funktion

Code: Alles auswählen

--local-address=127.0.0.1:53

auf 82 oder was weiss ich was ändere, dann lädt er die Seiten gar nicht mehr, aber auf 53 läuft das DNS weiterhin.
Irgendwas check ich da nicht

Muss ich dafür die /etc/services bearbeiten und dort auf z.B. 82 setzen?
Das bringt aber nichts.

Ich frage mich auch, wenn ich per dnscrypt eine Verbindung zum Resolver z.B. per 443 aufbaue, warum brauche ich den 53 bei localhost??
die Ports bei mir sind doch dynamischer Natur und werden eh nicht festgesetzt wie ist also

Code: Alles auswählen

Proxying from 127.0.0.1:53 to xxx:443

gemeint?

[mat6937]

\Edit: vor allem, wie schaffe ich es, den nicht auf 53 laufen zu lassen sondern auf einem anderen Port??
wenn ich die Funktion

Code: Alles auswählen

--local-address=127.0.0.1:53

auf 82 oder was weiss ich was ändere, dann lädt er die Seiten gar nicht mehr, aber auf 53 läuft das DNS weiterhin.
Irgendwas check ich da nicht

Dann versuch mal mit:

Code: Alles auswählen

sudo tcpdump -vvveni any port 82

und

Code: Alles auswählen

dig +short -p 82 heise.de

EDIT:

Z. B.:

Code: Alles auswählen

:~$ sudo lsof -nPi | grep -i :82
dnsmasq 4366 dnsmasq    4u  IPv4  25732      0t0  UDP 127.0.0.1:82 
dnsmasq 4366 dnsmasq    5u  IPv4  25733      0t0  TCP 127.0.0.1:82 (LISTEN)

Code: Alles auswählen

:~$ dig +short -p 82 heise.de
193.99.144.80

[debiator]

das ist ja das Problem, ich habe es schn mit tcpdump probiert. Er zeigt mir nichts, also da läuft nichts (auch wenn ich den Port beim Start von dnscrypt ändere). Aber auf 53 läuft alles weiterhin. Zeigt nur logischerweise keine Seiten mehr an.

[mat6937]

das ist ja das Problem, ich habe es schn mit tcpdump probiert. Er zeigt mir nichts, also da läuft nichts (auch wenn ich den Port beim Start von dnscrypt ändere). Aber auf 53 läuft alles weiterhin. Zeigt nur logischerweise keine Seiten mehr an.

Wenn Du mit dem tool dig (oder gleichwertig), die dns-Anfrage zum Port 82 (auch wenn auf diesem Port nicht gelauscht wird) machst, dann wird tcpdump, dir das schon anzeigen.
Dass die Browser & Co. nur den Port 53 (für dns) nutzen wollen (und nichts anderes) ist auch klar. Oder kannst Du einen Browser so konfigurieren, dass dieser z. B. den Port 82 nutzt?

[debiator]

hmmm... dann hat die Umstellung wenig Sinn, wenn man den Browser nicht auf 82 oder sonst was umzwingen kann.
Warum kann man das beim Browser nicht umstellen, was hat es für einen Hintergrund?

Bei 80/443 kann ichs noch verstehen. Da ist jeder Webserver (im Normalfall) auf 80/443 und es geht nur, wenn ich von meinen dynamischen Ports zu den offenen 80/443 zusurfe.

Aber dnycrypt dürfte ja keine 53 mehr benutzen, wenn ich auf dem Resolver nen anderen Port habe.


Übrigens. Wie isn das genau mit dem Verkehr bei dnscrypt?
Browser schickt die Anfrage über die lokale DNS-Einstellung an den lokalen dnscrypt-proxy auf localhost, der schickt dann über 5353 ne Resolv-Anfrage an den jeweiligen crypt-Resolver mit 443 oder was auch immer. Aber wo bleibt da der 53?

Bei Wireshark sehe ich ein Mischmasch aus verschlüsselten Verbindungen und auch offenen DNS-Anfragen.