Interesse an dnscrypt-proxy (Version 1.95 aus 2019!)

[pfichtner]

Besteht Interesse an dnscrypt-proxy? Mit dnscrypt-proxy können verschlüsselte DNS-Anfragen an entsprechende DNSCrypt-Server gestellt werden, siehe z.B. https://www.heise.de/ratgeber/FAQ-Verschluesselte-DNS-Anfragen-6207567.html https://de.wikipedia.org/wiki/DNS_over_TLS

Ich habe das ganze mal bei mir gebaut, dazu nutze bzw. baue ich:

• https://github.com/dyne/dnscrypt-proxy das ist eine Version aus 2019! Das ist die letzte Version 1.95 die noch auf C beruht, die nachfolgenden Versionen beruhen auf go (https://github.com/DNSCrypt/dnscrypt-proxy/releases) und das binary für mips ist über 8 MB groß
• dnscrypt-proxy benötigt libsodium, welches problemlos kompliert.

Laufen tut das genannte bei mir nun seit mehr als einer Woche problemlos, dazu leitet mein dnsmasq auf der FritzBox externe Auflösungen statt an den Provider-DNS an den ebenfalls auf der FritzBox laufenden dnscrypt-proxy.

Jegliches Feedback von "gute Idee" über "prinzipiell gut aber bitte nicht mit den genannten Projekten" bis hin zu "braucht kein Mensch" willkommen. Gerne voten gerne kommentieren.

Warum frage ich das? Wenn es brauchbar ist/Bedarf besteht mache ich die UI (cgi) noch rund und baue noch eine autmatische Updatemöglichkeit für die resolver liste ein, dies benötigt dann noch zustätzlich minisign (welches ebenfalls wieder libsodium benötigt) um beim Update die Signatur der Liste überprüfen zu können.

[fda77]

Ein altes Programm zu nutzen das keine Updates mehr bekommt ist nicht so optimal. Können das die vorhandenen Packages bind und unbound nicht? Wenn du es aber erstellst sollte es schon aufgenommen werden, ich find es nicht gut wenn es ansonsten irgendwo getrennt gepflegt wird.

Dieses DoT find ich aber .. überflüssig :D Es wird nur die DNS-Kommunikation verschlüsselt. Meist nimmt man dann 1.1.1.1 oder 8.8.8.8, dh diese Anbieter in den USA erhalten dann ALLE Anfragen, womöglich komplett alles aus deinem Netzwerk. Und wenn man zb eine HTTPS Seite aufruft wird wird der Hostname dadurch in Klartest übertragen, da SNI diesen kennen muss um das richtige Zertifikat zuzuordnen...

Ich mach das so: dnsmasq fürs LAN der unbound nutzt. Dieser validiert Anfragen (http://dnssec.vs.uni-due.de) und löst rekursiv auf, dh man ist nicht von irgend einem dreisten deutschen Proivder und einer aufgezwungenen "Navigationshilfe" abhängig der DNS manipuliert, wie Telekom's : https://www.golem.de/news/t-online-navigationshilfe-telekom-beendet-dns-hijacking-nach-strafanzeige-1905-141370.html oder KDG(Vodafon): https://www.zdnet.de/41534451/kabel-deutschland-beendet-dns-faelschungen/ ehemals
Ausserdem cachet und prefetcht unbound auch noch:

$ unbound-control stats_noreset | grep ^total.num
total.num.queries=1321618
total.num.queries_ip_ratelimited=0
total.num.cachehits=1022909
total.num.cachemiss=298709
total.num.prefetch=782884
total.num.expired=429744
total.num.recursivereplies=298709

PS: Schade dass sich hier so wenige an Umfragen etc beteiligen, evtl bekommtst du im IPPF mehr Feedback

[fda77]

Mit Unbound hast du jedenfalls etwas was noch weiterentwickelt wird und Sicherheitsupdates bekommt. Ich würde DoT dennoch nochmal überdenken

[pfichtner]

Mir ging es erstmal darum, dass das Paket dnscrypt-proxy wenig Sinn macht, denn falls jemand DoT nutzen will, kann er dies jetzt bereits via unbound tun.
Es klingt aber so, als ob Du generell davon abraten willst, mir ist nicht klar wieso. Mit SNI ist zwar immer noch einsehbar, mit welchem Hostnamen Du sprechen möchtest, erscheint für mich aber immer noch besser gegenüber allem einsehbar.

[fda77]

Ich bin der Meinung dass man durch DoT weniger "Privatsphäre" hat da man alle Anfragen an 1 (oder 5) Anbeiter gebündelt übermittelt. Wenn du rekursiv (zb unbound) auflöst sind es die entsprechenden Server unter NS (verschedene je Domain, Land etc).
Da das meiste vermutlich https Traffic ist sieht man durch beobachten der Leitung durch SNI eh die Hostnamen: https://de.wikipedia.org/wiki/Server_Name_Indication#Sicherheit

[pfichtner]

Ok, Du ziehst Deine Schlüsse aus dem Vergleich von DoT im Vergleich zu unbound (selbst auflösen), da ist DoT tatsächlich fraglich bezüglich Sinnhaftigkeit. DoT im Vergleich zu "Namensauflösung via Provider-DNS" (an einen Anbieter gebündelt vs an einen Anbieter gebündelt) ist schon eine Verbesserung.
Von daher würde ich sagen: DoT macht schon Sinn, wenn man allerdings unbound nutzt/dafür nutzen will ist (bzw. kann es u.U.) eine Verschlechterung sein. Kann, weil, die Resolver in der genannten CSV loggen nicht, wird zumindest behauptet, das kann man nun glauben oder nicht. Und in solchen Konstellationen ziehe ich auch immer Dinge vor, bei denen Dinge einfach nicht möglich sind statt dass ich mich auf Zusagen anderer Verlassen müsste.

[fda77]

Unbound nutzt im "Normalfall" auch upstream Server vom zb Provider. Resolven über die rootserver muss man konfigurieren. Wenn du vor deinem Provider was verstecken willst, nimm lieber vpn (am besten irgend wo ein eigener vps) oder gleich tor.

Ob im resolve modus die Server mitloggen ist egal, jeder kennt nur seine zone.

zb .com (die "13" root server sind in unbound integriert)

dig com NS

;; ANSWER SECTION:
com.                    76609   IN      NS      l.gtld-servers.net.

github.com

dig github.com NS @l.gtld-servers.net

;; AUTHORITY SECTION:
github.com.             172800  IN      NS      dns2.p08.nsone.net.

;; ADDITIONAL SECTION:
ns-421.awsdns-52.com.   172800  IN      A       205.251.193.165

www.github.com

dig www.github.com AAAA @dns2.p08.nsone.net

;; QUESTION SECTION:
;www.github.com.                        IN      AAAA

;; ANSWER SECTION:
www.github.com.         3600    IN      CNAME   github.com.

;; AUTHORITY SECTION:
github.com.             3600    IN      SOA     dns1.p08.nsone.net. hostmaster.nsone.net. 1650042304 43200 7200 1209600 3600

lokal aus dem cache des resolvers:

dig www.github.com AAAA

;; QUESTION SECTION:
;www.github.com.                        IN      AAAA

;; ANSWER SECTION:
www.github.com.         3598    IN      CNAME   github.com.

;; Query time: 0 msec              <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<