[erledigt] Systemd hardkodierte Google DNS?

[clue]

Hi,

in diesem Thread wird berichtet, dass in Systemd die Google DNS server als fallback Lösung hardkodiert sind. Daraus ergeben sich auch Konsequenzen wie DNS leaking bei VPN.

Nun meine Frage:

Ist das in Debian genauso und falls ja, wie kann man dem beikommen? Ich möchte kein DNS leaking alle 15 min, wie im Thread beschrieben.

Kann mal jemand, der Ahnung hat, dem Link folgen?

https://www.heise.de/forum/iX/News-Komm ... 9899/show/

[smutbert]

Gabs dazu nicht schon einen Thread (finde aber nichts)?

Meines Wissens ist es so, dass die Google-Server tatsächlich der Fallback von systemd-resolved sind, was man auch in der Datei »/etc/systemd/resolved.conf« nachlesen kann (dort sind die Zeilen auf meinem stretch auskommentiert, aber die auskommentierten Zeilen entsprechen normalerweise den Defaults).

Allerdings kommt systemd-resolved ja normalerweise gar nicht zum Einsatz - man müsste es selbst aktivieren und wenn man das tut, kann man die Zeilen in der Konfigurationsdatei auch anpassen und so den Fallback ändern. So ungefähr lautete auch die Begründung des Paketmaintainers (?), der an dem default-Fallback wohl nichts ändern möchte.

[eggy]

https://bugs.debian.org/cgi-bin/bugrepo ... bug=761658

[clue]

Harte Diskussion, vielen Dank für den Link!

[/Aluhut-Mode-ON]

Wie wir ja alle wissen, bezahlen die Geheimverbrecherorganisationen ja jede Menge Menschen. Unter anderem auch in open source Projekten.

Da der Debian Paketverwalter für SystemD, das von Poettering, welcher afaik beim US-Distributor Redhat angestellt ist und somit den NSL's verpflichtet ist, vorgegebene Verhalten ohne jede Logik bis aufs Blut verteidigt, beschleicht mich hier ein Gefühl, welches ich damals beim Heartbleed-maintainer hatte.

Noch niemals zuvor wurde es in Debian für nötig erachtet, einen default als fallback Lösung für DNS resolve festzuschreiben.

Wie lange gibt es Debian eigentlich schon? Und nun kommt das von allen Seiten einstimmig viel gelobte systemD daher mit solch netten defaults ...

[/Aluhut-Mode-OFF]

Was mich jetzt ein bisschen verwundert ist, dass in meiner /etc/systemd/resolved.conf alles bereits auskommentiert war. Liegt das daran, dass ich keine Neuinstallation beim upgrade auf Stretch vorgenommen habe? Und bin ich jetzt "sicherer" vor Google, oder muss ich noch an einer Stelle rumschrauben?

[scientific]

Ese heißt "systemd", nicht "systemD".

[DeletedUserReAsG]

Noch niemals zuvor wurde es in Debian für nötig erachtet, einen default als fallback Lösung für DNS resolve festzuschreiben.

Dafür sind bei Debian einige Pakete mit einigen Default-Optionen konfiguriert. Nichts anderes ist’s mit systemd – das ist kein Default von Debian, sondern der vom Upstream, und der wurde, wie bei hunderten anderen Paketen, einfach übernommen.

[wolfn]

So, ich habe jetzt nochmal Poetterings Antwort vom 24.April durchgelesen und vorher einige unbound-docs nachgelesen sowie meine /etc/systemd/resolved.conf.

Ich bin jetzt der Überzeugung, daß das hier ein Mißverständnis ist, denn:

- die Fallback-Nameserver werden NUR aktiviert, wenn im ganzen System nichts dergleichen konfiguriert ist,
damit notfalls überhaupt was geht.
Sobald irgendwas konfiguriert ist, wird nur das genommen, auch wenn keine Antwort kommt!

- In meiner resolved.conf (ArchLinux) kann ich die Vorgaben überschreiben mit beliebigen Unsinn oder auch löschen.
Geht in meinem Ubuntu 16.04 übrigens auch. Habe gerade kein Debian an, denke aber es wird genauso sein.

Solange nicht jemand hier ein logfile mit einem klaren Gegenbeweis reinstellt, halte ich das Ding für erledigt.

Nachtrag: Die default-Einträge einfach löschen ist sicher keine so gute Idee, weil dann der default wieder greift.
Aber wer es ganz sicher haben will kann z.B. 127.0.0.1 oder sowas reinschreiben, hat sich damit aber auch den eigenen Ast abgesägt...
Sonst sehe ich eher als Option die Server aus Jana's 2. Link.

[clue]

- die Fallback-Nameserver werden NUR aktiviert, wenn im ganzen System nichts dergleichen konfiguriert ist,
damit notfalls überhaupt was geht.
Sobald irgendwas konfiguriert ist, wird nur das genommen, auch wenn keine Antwort kommt!

Wenn das so stimmt, wäre das ja schön. Leider hab ich keine Ahnung wie man das wirklich testen kann. Was mich aber auch interessiert, ob es auch wirklich nicht zu irgendwelchen DNS leaks kommen kann, wenn ich VPN verwende. Das wäre nämlich das Gegenteil von dem, was ich durch Nutzung von VPN erreichen möchte.

[BenutzerGa4gooPh]

Wenn das so stimmt, wäre das ja schön. Leider hab ich keine Ahnung wie man das wirklich testen kann.

Nachsehen, notfalls umkonfigurieren: https://wiki.archlinux.de/title/Systemd ... d-resolved
Eintrag so? https://www.kuketz-blog.de/dns-unzensie ... ollierung/

Was mich aber auch interessiert, ob es auch wirklich nicht zu irgendwelchen DNS leaks kommen kann, wenn ich VPN verwende.

VPN-Leaks können eher nach unbeabsichtigtem Abbruch der Verbindung, auch durch DoS-Angriffe auf andere Dienste/Router entstehen. Deshalb schränkt man per Firewall oder Paketfilter Quell- und Zieladressen besser ein. Bei VPN-Tunnel durch NAT-Router (NAT-Bypass) nur Nicht-VPN-Adressen = WAN-Adresse des Routers als Quelladresse auf WAN-Interface outbound zulassen. Und immer an beide Seiten, Server und Client denken!

[clue]

Danke für die Hilfe und links. Dann markier ich das Thema als erledigt.