ich habe gestern einen Freifunk-Router in Essen aufgestellt und dabei bemerkt, dass für IPv4 der Google Public DNS-Server unter 8.8.8.8 benutzt wird. Auf Grund Googles Datenspeicherung (Your Privacy | Public DNS | Google Developers) finde ich das eher unschön*. Spräche etwas dagegen, den Nameserver, der per 2a03:2260:50:1::15 erreichbar ist, auch per IPv4 erreichbar zu machen und per DHCP diesen zu verteilen?
Viele Grüße,
Benedikt
Inwiefern man Nutzerdaten unter juristischen Gesichtspunkten ohne Datenschutzerklärung an einen Dienst mit solchen Bedingungen weiterleiten darf, ist nochmal eine andere Frage (die ich nicht beantworten kann).
Bei uns laufen eigene DNS Server auf den Gateways und dieser wird verteilt per DHCP. Upstream Server sind die des jeweiligen Hosters wo das Gateway gehostet ist + einen unzensierten OpenNIC Server.
Die 8.8.8.8 ist nur zusätzlich drin, weil am internen DNS Server gearbeitet werden sollte.
Gerne kannst Du uns unterstützen und mittels dnsbench zu unterschiedlichen Uhrzeiten an unterschiedlichen Tagen einen möglichst ebenso peformanten public DNS Cluster mit 100% Uptime raussuchen, dann verwenden wir zukünftig diesen.
Nur was weiß man dann wiederum über den Anbieter?
Sobald die Arbeiten an den DNS Servern abgeschlossen sind werden aber auch wieder nur unsere eigenen DNS Server genutzt, dann ist die 8.8.8.8 ohnehin nicht mehr in Nutzung.
Externen DNS halte ich aus Gründen der Datensparsamkeit generell für die zweite Wahl. Bei Google insbesondere, weil die Daten über nicht auffällige Transaktionen überhaupt geloggt werden.
Und „We don’t correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services.“ kann man auch so interpretieren, dass Daten, die ich an Google gebe, nur anonymisiert korreliert werden, Daten die andere an Google über mich übermitteln, aber auch personalisiert korreliert werden.
Speziell für mich bedeutet die Kombination „Request domain name“, „Client AS“ und „Absolute arrival time in seconds“ (permanente Speicherung) → Google speichert, wann ich meinem E-Mail/owncloud-Server kommuniziere (ja, ich kann natürlich auch überall /etc/hosts verteilen, aber das ist ja nicht Sinn von DNS)
Ich sehe da kein Personenbezogenes Datum welches da dauerhaft gespeichert wird.
Dass temporär geloggt wird ist dank DNS Amplification Attacks wohl leider notwendig.
Ansonsten kann ich mich Chris nur anschließen: Einen Resolver in der Geschwindigkeit und Zuverlässigkeit zu betreiben macht man nicht einfach so nach. Letztenendes bedeutet der Betrieb eigener Resolver bedeutet auch selber mit Amplification Attacken umgehen zu müssen, Ressourcen (Server) dafür zu haben und sich darum kümmern zu müssen.
Google DNS ist da halt eine sehr einladende Alternative.
Ehrlich gesagt sehe ich auch keine Notwendigkeit.
Freifunk erhebt keinen Anspruch darauf, ein besonders gesichertes Netz zu sein.
Wer Sicherheit braucht, muss diese im jeweiligen Endgerät herstellen: https, zusätzliche VPNs on top, dns-sec etc.
Gibt es alles, kann man machen.
Geschwindigkeitsmäßig vermute ich, dass ein interner Server bei häufig benutzten, bereits gecachten, Einträgen schneller ist, sonst eher langsamer als Google Public DNS.
Amplification-Attacks sind für einen öffentlichen DNS-Server problematisch, aber wenn dieser Server im Freifunk-Ruhr-Netz stünde und nur Antworten an Rechner im Freifunk-Ruhr-Netz beantworten würde, sehe ich kein Problem. Wenn jemand das Netz vollmüllen will, funktioniert das bei unserem Layer2-Netz auch ohne irgendwelche DNS-Server (ohne übersehe ich etwas?).
Administration könnte ich übernehmen, einen Rechner mit ausreichend stabiler Netzanbindung habe ich leider nicht.
Von freifunk.net „Wir verstehen frei als öffentlich zugänglich, nicht kommerziell, im Besitz der Gemeinschaft und unzensiert.“ Der Google-DNS-Server gehört sicherlich nicht der Gemeinschaft, auf Root-Name-Server kann man nicht einfach so verzichten, auf Google wäre es schon möglich.
Zu deinen Sicherheitsvorschlägen: DNS ist v.A. wegen Metadaten kritisch, dagegen hilft https nicht. DNSSEC signiert. VPNs sind möglich, aber da ist das manuelle Einstellen von einem eigenen Nameserver wohl meistens einfacher.
Falls es sonst niemanden im Ruhrufer stört, möchte ich dazu aber auch nicht mehr allzuviel diskutieren. Der Router steht sowieso am südlichen Ende des Ruhrgebiets (~1km vor der Stadtgrenze Essen-Velbert), da ist die Domäne Rheinufer (mit internem Namserver) nicht weit.
Kurz was zur Geschwindigkeit:
Der Google public DNS dienst ist von unseren Backbone Routern nur wenige Millisekunden entfernt:
FRA: 1,23ms
BER: 0,82ms
DUS: 4,50ms
Viel näher können wir auch einen eigenen Nameserver nicht an die Nutzer ran bringen.
Der Cache dürfte aufgrund der größeren Benutzerzahl bei Google auch besser gefüllt sein.
Zu den Metadaten:
Ein Nutzer der nicht weiter zu bestimmen ist (weil bei IPv4 die ganze Domäne das NAT teilt und man bei IPv6 hoffentlich privacy extensions verwendet wenn man Wert auf Anonymität legt) löst eine Domain XY auf. Und nun?
Zum DoS:
Wenn nutzer aus dem Freifunk Netz den DoS (DNS reflection attack) mit einem internen DNS Server starten dann schieben wir nicht mehr nur die 5Mbit/s raus die der Benutzer zu unserem Nameserver schickt sondern gleich ein vielfaches. Hier müssten wir dann administrativ eingreifen. Und das auch noch möglichst schnell. Die Arbeit erspare ich mir gerne und möchte ich auch keinem anderen mal eben zumuten. Bei Google kümmern sich Menschen und eine Menge Automatisierung um diesen Fall…
Wie bereits im ersten Posting erwähnt ist lediglich die 8.8.8.8 übergangsweise mit drin, weil an den INTERNEN DNS Servern Dinge umgestellt werden. Diese sind 3 Stück und werden zukünftig von Ruhrgebiet, Rheinufer, Möhne und Albufer genutzt, sowie für alle FFRL Dinge.
Auf vielen Devices auf denen z.B. ein Netflix Player läuft, ist der DNS fest eingestellt (Chromecast, PlayStation, Apple TV, XBox, …). Oft geht es dabei um die Geolocation.
Man könnte, wenn man wollte, alle Anfragen zu *:53 UDP/TCP auf einen eigenen DNS Resolver umleiten.[quote=„jbacksch, post:15, topic:2202“]
Auf vielen Devices auf denen z.B. ein Netflix Player läuft, ist der DNS fest eingestellt (Chromecast, PlayStation, Apple TV, XBox, …). Oft geht es dabei um die Geolocation.
[/quote]
Das würde allerdings dem Pico Peering Agreement widersprechen: „Der Eigentümer bestätigt, die Daten, die seine freie Netzwerkinfrastruktur passieren, weder störend zu beeinträchtigen noch zu verändern“.
Aber ich glaube jetzt werden wir langsam „offtopic“
Goggle als DNS Nameserver könnte ein verborgenes Problem verursachen:
Ich habe einige Domainnamen, die dann zeitweilig nicht aufgelöst werden, obwohl sie richtig aufgestellt sind. Das ändert sich dann mehrmals täglich, hat dann teilweise gravierende Auswirkungen.
Beispiel: https://www.ssllabs.com/ssltest/analyze.html?d=44-4.in hat seit Wochen „Unable to resolve domain name“ oder DNS Checker - DNS Propagation Check & DNS Lookup
Immer ist es Google, der failed, und damit alle System, die auf 8.8.8.8 zugreifen
Bin also nicht besonders glücklich darüber, dass Google benutzt wird, weil ich nicht abschätzen kann, wann und wobei dieses Problem mit Google sonst noch auftritt.
In Berlin gab es auch eine längere Diskussion (1) bzgl. „welche DNS-Resolver sollen hardcoded in die Firmware“.
FYI, die Berliner-Community betreibt selbst keine zentralen DNS-Server oder Gateways und Knoten-Betreiber haben auch die Möglichkeit selbstbestimmt einen anderen Resolver für Clients zu definieren. Dennoch sollen die voreingestellten Resolver folgende Eigenschaften haben:
