Ich habe bei mir auf meinem Serverlein einen unbound als DNS-Server eingerichtet. Malware und Reklame filtere ich per hosts-files.
Bei der Konfiguration habe ich generell 2 unterschiedliche Möglichkeiten:
a) Ich betreibe den als caching recursiven Resolver mit "qname minimisation" und löse alle Anfragen top-down von der root-Zone aus auf. Dank caching sind wohl viele Domains bereits im Cache und die Auflösung ist normal recht flott. Das klappt bestens und auch mit DNSSEC und TLSA.
b) Ich beteibe den nur als "forwarder" und befrage über DoT einen "non logging" und vertrauenswürdigen (nach privacy handbook) freien DNS-Server. Das klappt ebenfalls völlig problemlos, DNSSEC und TLSA geht ebenfalls.
Zu einem gewissen Grade könnte ich auch beide Wege gleichzeitig aktivieren und z.B. nur für einzelne Hosts oder Subnetze die "forward-zone" aktivieren.
Meine Frage ist nun:
Welches ist bezüglich Sicherheit und/oder Privacy der bessere Weg?
Kann man eventuell beide Wege gleizeitig aktivieren und davon einen als "primär" nutzen und den anderen nur als "fall back"?
Gruß, Ingo
Eigener unbound: Sicherheit und Privatsphäre
Re: Eigener unbound: Sicherheit und Privatsphäre
Sicherheit für dich:
Steht und fällt mit DNSSEC. Wenn das über beide Lösungen funktioniert: Kein unterschied.
Privatsphäre:
Ist eine Vertrauensfrage. Auf der einen Seite gehen die anfragen halt alle über den DoT Server wo es entsprechend attraktiv ist mitzuhören auf der anderen kann sie halt dein lokaler ISP lesen. Du kannst jetzt entscheiden, was dir lieber ist.
Sicherheit für andere:
DNS ist ein angenehmes Target um für DDos misbraucht zu werden. Wenn fremde deinen DNS nutzen können ist es eventuell sinnvoll Prävention auf den DoT-Server zu überlassen.
Performance:
Die erste Variante wird vermutlich deutlich performanter sein, wenn du ausreichend RAM benutzt und viele Anfragen handelst. (DNS-Server werden schneller je mehr anfragen sie bekommen, weil sie dann mehr cachen können.) Wenn du nur ein kleiner Plastikrouter für dich alleine bist, ist vermutlich der weg über DoT besser.
Steht und fällt mit DNSSEC. Wenn das über beide Lösungen funktioniert: Kein unterschied.
Privatsphäre:
Ist eine Vertrauensfrage. Auf der einen Seite gehen die anfragen halt alle über den DoT Server wo es entsprechend attraktiv ist mitzuhören auf der anderen kann sie halt dein lokaler ISP lesen. Du kannst jetzt entscheiden, was dir lieber ist.
Sicherheit für andere:
DNS ist ein angenehmes Target um für DDos misbraucht zu werden. Wenn fremde deinen DNS nutzen können ist es eventuell sinnvoll Prävention auf den DoT-Server zu überlassen.
Performance:
Die erste Variante wird vermutlich deutlich performanter sein, wenn du ausreichend RAM benutzt und viele Anfragen handelst. (DNS-Server werden schneller je mehr anfragen sie bekommen, weil sie dann mehr cachen können.) Wenn du nur ein kleiner Plastikrouter für dich alleine bist, ist vermutlich der weg über DoT besser.
Ich weiß nicht wie, kann mir aber nicht vorstellen, dass es nicht geht.Kann man eventuell beide Wege gleizeitig aktivieren und davon einen als "primär" nutzen und den anderen nur als "fall back"?
rot: Moderator wanne spricht, default: User wanne spricht.
- ingo2
- Beiträge: 1124
- Registriert: 06.12.2007 18:25:36
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Wo der gute Riesling wächst
Re: Eigener unbound: Sicherheit und Privatsphäre
Danke für die strukturierte Antwort, das bringt schon ein bisschen Licht in die Sache.
Der lokale ISP kann sowieso sehen, welche IP's ich ansteuere, erscheint bei Bedarf ja in den Logs zu meinem Anschluß - spielt also auch (fast) keine Rolle.
Ich muß mal sehen, ob ich beide Möglichkeiten parallel aktivieren kann und das irgendwie steuern kann. Die Dokumentation und Stellschrauben auf der original Website https://www.nlnetlabs.nl/documentation/ ... ound.conf/ sind äußerst umfangreich.
Das Problem wird sein, daß ich DoT nicht selektiv einschalten kann, weil es die normalen Resolver bei recursiven Anfragen bestimmt nicht unterstützen.
Gruß, Ingo
Ergänzend dazu:wanne hat geschrieben:28.09.2020 22:19:37Privatsphäre:
Ist eine Vertrauensfrage. Auf der einen Seite gehen die anfragen halt alle über den DoT Server wo es entsprechend attraktiv ist mitzuhören auf der anderen kann sie halt dein lokaler ISP lesen. Du kannst jetzt entscheiden, was dir lieber ist.
Der lokale ISP kann sowieso sehen, welche IP's ich ansteuere, erscheint bei Bedarf ja in den Logs zu meinem Anschluß - spielt also auch (fast) keine Rolle.
Keine Angst, nach außen zum Internet hin ist der dicht, da sorgt js schon der Router für. Wenn ich ihn von "remote" nutzen will, dann nur durch einen VPN-Tunnel zu meinem Serverlein. Das ist sowieso von außerhalb mein Weg, im Internet zu surfen. Habe hier 10Mbit Upstream, das reicht da völlig aus.wanne hat geschrieben:28.09.2020 22:19:37Sicherheit für andere:
DNS ist ein angenehmes Target um für DDos misbraucht zu werden. Wenn fremde deinen DNS nutzen können ist es eventuell sinnvoll Prävention auf den DoT-Server zu überlassen.
Ja, rein subjektiv ist der recursive Weg deutlich schneller. Habe ich seit ein paar Tagen mal so umgestellt. Dazu habe ich heute das Logging für Statistik aktiviert - werde das hier mal posten, wenn ich was aussagekräftiges im Log sehe.wanne hat geschrieben:28.09.2020 22:19:37Performance:
Die erste Variante wird vermutlich deutlich performanter sein, wenn du ausreichend RAM benutzt und viele Anfragen handelst. (DNS-Server werden schneller je mehr anfragen sie bekommen, weil sie dann mehr cachen können.) Wenn du nur ein kleiner Plastikrouter für dich alleine bist, ist vermutlich der weg über DoT besser.
Ich muß mal sehen, ob ich beide Möglichkeiten parallel aktivieren kann und das irgendwie steuern kann. Die Dokumentation und Stellschrauben auf der original Website https://www.nlnetlabs.nl/documentation/ ... ound.conf/ sind äußerst umfangreich.
Das Problem wird sein, daß ich DoT nicht selektiv einschalten kann, weil es die normalen Resolver bei recursiven Anfragen bestimmt nicht unterstützen.
Gruß, Ingo
avatar: [http://mascot.crystalxp.net/en.id.2938- ... nther.html MF-License]
Re: Eigener unbound: Sicherheit und Privatsphäre
IPs sind nicht mehr so vielsagend wie sie mal waren: Das Internet ist dominiert von Amazon, Google, Akamai, Cloudflare und ein paar anderen Giganten mit dicken Gateways die sich einen Pool von addresse für alle Seiten teilen.Der lokale ISP kann sowieso sehen, welche IP's ich ansteuere, erscheint bei Bedarf ja in den Logs zu meinem Anschluß - spielt also auch (fast) keine Rolle.
Was für die Privatsphäre eigentlich eine Katastrophe ist wird jetzt vielmals als Chance gesehen: Dass du Google oder Cloudflare anspirchst ist in etwa so nichtssagend, wie dass du überhautpt ins Internet gehst und wenn die eh schon wissen, was du machst ist es eigentlich logisch, dahin den DNS zu stellen. Macht man das per DoH oder DoT können dann nur die, die DNS anfragen lesen, die eh schon alles wissen. Dank der großflächigen Implementierung von SNI sieht der Priovider am ende aber doch wieder wo du Surfst.
rot: Moderator wanne spricht, default: User wanne spricht.
- ingo2
- Beiträge: 1124
- Registriert: 06.12.2007 18:25:36
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Wo der gute Riesling wächst
Re: Eigener unbound: Sicherheit und Privatsphäre
So, wie versprochen hier die Ergebnisse mit unbound in den beiden Konfigurationen:
In beiden Fällen ist "caching" und "validating" für DNSSEC/TLSA aktiv. Nur 1 Thread. Die Statistiken gehen jeweils über genau 1 Tag.
a) recursive DNS-Auflösung top-down vom root-server ausgehend
qname-minimisation yes, strikt
keine "forwarding-zone" definiert
Bei maximal 33 Eintägen (Anfragen in Arbeit) in der requestlist, die fasst 512 Slots bevor "gejostelt" wird, besteht kein Anlaß, auf mehr Treads umzustellen.
Test im Browser auf einem Client-PC mit https://browserleaks.com/dns
Das ist meine öffentliche IPv4 und die IPv6 vom unbound-Server.
b) Mit forwarding zu 3 "vertrauensdwürdigen" DNS-Servern
qname-minimisation no
"forwarding-zone" mit 3 forward-addr: Einträgen
Test im Browser auf einem Client-PC mit https://browserleaks.com/dns
Das scheint mir soweit alles vernünftig und die Antwortzeiten sind auch in beiden Fällen ziemlich gleich - das ist auch mein Einduck beim Surfen. Meine Ping-Zeiten (round trip) am VDSL-50 Anschluß liegen bei ca. 15ms. Daß bei "qname-minimisation" mehr Look-Ups erfolgen, ist ebenfalls logisch.
Was mir aber unerklärlich ist:
unbound listet auch bei Nutzung der forward-Server Statistik zu "recurion processing", obwohl bei Nutzung der forward-Server ohne qname-minimisation die vollständige URL an die Forward-Server geht/gehen sollte und die dann die Auflösung übernehmen.
Habe daraufhin mal recherchiert und hier https://github.com/NLnetLabs/unbound/issues/75 gefunden:
Ob mein Server da in einer "Mixed-Mode" arbeitet und den schnellsten Weg dann wählt, oder "round robin" mit forwarden und recursive?
Gruß, Ingo
In beiden Fällen ist "caching" und "validating" für DNSSEC/TLSA aktiv. Nur 1 Thread. Die Statistiken gehen jeweils über genau 1 Tag.
a) recursive DNS-Auflösung top-down vom root-server ausgehend
qname-minimisation yes, strikt
keine "forwarding-zone" definiert
Code: Alles auswählen
info: server stats for thread 0: 3804 queries, 1902 answers from cache, 1902 recursions, 45 prefetch, 0 rejected by ip ratelimiting
info: server stats for thread 0: requestlist max 33 avg 1.90652 exceeded 0 jostled 0
info: average recursion processing time 0.119481 sec
info: histogram of recursion processing times
info: [25%]=0.0170831 median[50%]=0.0360362 [75%]=0.104651
info: lower(secs) upper(secs) recursions
info: 0.000000 0.000001 131
info: 0.001024 0.002048 1
info: 0.004096 0.008192 57
info: 0.008192 0.016384 267
info: 0.016384 0.032768 457
info: 0.032768 0.065536 381
info: 0.065536 0.131072 222
info: 0.131072 0.262144 171
info: 0.262144 0.524288 130
info: 0.524288 1.000000 56
info: 1.000000 2.000000 17
info: 2.000000 4.000000 11
info: 4.000000 8.000000 1
Code: Alles auswählen
unbound-control forward
off (using root hints)
Code: Alles auswählen
unbound-control lookup heise.de
The following name servers are used for lookup of heise.de.
no delegation from cache; goes to configured roots
Code: Alles auswählen
Test Results Found 2 Servers, 1 ISP, 2 Locations
Your DNS Servers
IP Address : ISP : Location :
91.54.152.199 Deutsche Telekom AG Germany, Wiesbaden
2003:c7:ef46:a200:20d:b9ff:fe47:83e8 Deutsche Telekom AG Germany, Huenstetten
b) Mit forwarding zu 3 "vertrauensdwürdigen" DNS-Servern
qname-minimisation no
"forwarding-zone" mit 3 forward-addr: Einträgen
Code: Alles auswählen
info: server stats for thread 0: 2166 queries, 713 answers from cache, 1453 recursions, 25 prefetch, 0 rejected by ip ratelimiting
info: server stats for thread 0: requestlist max 15 avg 4.08796 exceeded 0 jostled 0
info: average recursion processing time 0.125064 sec
info: histogram of recursion processing times
info: [25%]=0.045195 median[50%]=0.0844871 [75%]=0.167499
info: lower(secs) upper(secs) recursions
info: 0.000000 0.000001 19
info: 0.002048 0.004096 2
info: 0.008192 0.016384 4
info: 0.016384 0.032768 193
info: 0.032768 0.065536 383
info: 0.065536 0.131072 434
info: 0.131072 0.262144 197
info: 0.262144 0.524288 200
info: 0.524288 1.000000 21
Code: Alles auswählen
unbound-control forward
46.182.19.48 91.239.100.100 89.233.43.71
Code: Alles auswählen
unbound-control list_forwards
. IN forward 46.182.19.48 91.239.100.100 89.233.43.71
Code: Alles auswählen
unbound-control lookup heise.de
The following name servers are used for lookup of heise.de.
forwarding request:
Delegation with 0 names, of which 0 can be examined to query further addresses.
It provides 3 IP addresses.
46.182.19.48 rto 60 msec, ttl 195, ping 28 var 8 rtt 60, tA 0, tAAAA 0, tother 0, EDNS 0 probed.
91.239.100.100 rto 87 msec, ttl 194, ping 31 var 14 rtt 87, tA 0, tAAAA 0, tother 0, EDNS 0 probed.
89.233.43.71 rto 58 msec, ttl 194, ping 26 var 8 rtt 58, tA 0, tAAAA 0, tother 0, EDNS 0 probed.
Code: Alles auswählen
Test Results Found 5 Servers, 3 ISP, 3 Locations
Your DNS Servers
IP Address : ISP : Location :
46.182.18.9 NbIServ Germany
89.233.43.71 Telia Company AB Denmark, Kobenhavn O
94.126.178.9 Sentia Denmark A/S Denmark
2a01:3a0:53:53:: Telia Company AB Denmark
2a03:a480:1000:3029::2 Sentia Denmark A/S Denmark
Das scheint mir soweit alles vernünftig und die Antwortzeiten sind auch in beiden Fällen ziemlich gleich - das ist auch mein Einduck beim Surfen. Meine Ping-Zeiten (round trip) am VDSL-50 Anschluß liegen bei ca. 15ms. Daß bei "qname-minimisation" mehr Look-Ups erfolgen, ist ebenfalls logisch.
Was mir aber unerklärlich ist:
unbound listet auch bei Nutzung der forward-Server Statistik zu "recurion processing", obwohl bei Nutzung der forward-Server ohne qname-minimisation die vollständige URL an die Forward-Server geht/gehen sollte und die dann die Auflösung übernehmen.
Habe daraufhin mal recherchiert und hier https://github.com/NLnetLabs/unbound/issues/75 gefunden:
Das bezieht sich aber auf eine recht alte unbound-Version, es steht dort nur, daß das Problem mit v1.9.3 gelöst ist - Buster nutzt v1.9.0.Sobald eine "forward-zone:" definiert ist, soll nicht mehr recursiv aufgelöst werden.
Ob mein Server da in einer "Mixed-Mode" arbeitet und den schnellsten Weg dann wählt, oder "round robin" mit forwarden und recursive?
Gruß, Ingo
avatar: [http://mascot.crystalxp.net/en.id.2938- ... nther.html MF-License]