staging.inyokaproject.org

Was machen wir im Hinblick auf diese Liste mit dem Artikel DNS-Probleme?

Im Grunde genommen handelt es sich nicht um einen wiki-konformen Artikel über ein bestimmtes Programm, sondern um eine Sammlung von Workarounds, um um die Fehler einiger Consumer-Router herum zu arbeiten. Der Artikel ist aber wichtig. Wollen wir hier auch einfach Getestet-general eintragen?

Ansonsten brauchen wir jemanden, der so einen fehlerhaften Router besitzt. Wenn ich mich richtig erinnere, hatte DrScott mal so einen.

der Artikel muss sofort entfernt werden, damit machen wir uns laut Ziercke strafbar! Schließlich enthält der Artikel Anleitungen um Zensurmaßnahmen zu umgehen.

Davon abgesehen: +1 für general

Hallo,

Davon abgesehen: +1 für general

Done.

Gruß, noisefloor

otzenpunk schrieb:

Wenn ich mich richtig erinnere, hatte DrScott mal so einen.

Den habe ich noch immer (und das Problem wohl auch noch...). Das Problem liegt darin, dass die vom Router verwendete DNS-Cache-Software (dproxy) nicht mit IPv6-Anfragen umgehen kann.

Hier die damalige Diskussion: http://forum.ubuntuusers.de/post/955547/

DrScott schrieb:

Das Problem liegt darin, dass die vom Router verwendete DNS-Cache-Software (dproxy) nicht mit IPv6-Anfragen umgehen kann.

Hier die damalige Diskussion: http://forum.ubuntuusers.de/post/955547/

Yo. Die Frage ist nur: Funktionieren die Workarounds auch unter Hardy/Intrepid/Jaunty?

otzenpunk schrieb:

Yo. Die Frage ist nur: Funktionieren die Workarounds auch unter Hardy/Intrepid/Jaunty?

Also ich arbeite hier immer noch mit Hardy und habe mir mal den Abschnitt "Einen bestimmten DNS-Server verwenden" vorgenommen.

Das Gesagte zu "resolvconf" kann ich nicht nachvollziehen: Der Eintrag in der /etc/network/interfaces wirkt sich nicht auf die /etc/resolv.conf aus.
Dagegen wirkt sich eine - allerdings anders geartete - Anpassung in der /etc/dhcp3/dhclient.conf auch bei installiertem resolvconf auf die /etc/resolv.conf aus.

Ich kenne mich mit resolvconf aber nicht sonderlich gut aus...

Die genannten Schritte bezüglich der /etc/dhcp3/dhclient.conf klappen nur teilweise. Die Anweisung

prepend domain-name-servers 62.72.64.237;

stellt der Liste in der resolv.conf tatsächlich den angegebenen Server voran.

Die Änderung an der "request"-Zeile führt bei mir allerdings zu keiner weiteren Änderung. Die vom Router bereitgestellten DNS-Einträge (also die meines ISPs) werden weiterhin aufgeführt. Das mag daran liegen, dass mein (kranker 😉 ) Router womöglich den genauen "request" missachtet und die DNS-Einträge trotzdem sendet. Vielleicht verhalten sich Router hier unterschiedlich.

Erfolgreich war ich dagegen mit dieser Lösung: Kein prepend, keine Änderung an der Request-Zeile, sondern einfach zusätzlich

supersede domain-name-servers 212.18.1.5,212.18.2.5;

Wie gesagt: Diese Lösung funktionierte auch bei installiertem resolvconf.

Die Lösung im Abschnitt "Überschreiben der resolv.conf" funktioniert sowohl mit als auch ohne resolvconf.

DrScott schrieb:

Das Gesagte zu "resolvconf" kann ich nicht nachvollziehen: Der Eintrag in der /etc/network/interfaces wirkt sich nicht auf die /etc/resolv.conf aus.

Das wundert mich jetzt etwas. Das resolvconf-Paket besteht aus Bash-Skripten, die u.a. in /etc/network/if-up.d/ und ähnlichen Hook-Verzeichnissen untergebracht sind. Ich kann mir höchstens vorstellen, dass der NetworkManager da irgendwie nicht zu 100% kompatibel zum ifupdown-System ist, und bspw. nicht alle Umgebungsvariablen setzt.

Die genannten Schritte bezüglich der /etc/dhcp3/dhclient.conf klappen nur teilweise. Die Anweisung

prepend domain-name-servers 62.72.64.237;

stellt der Liste in der resolv.conf tatsächlich den angegebenen Server voran.

Die Änderung an der "request"-Zeile führt bei mir allerdings zu keiner weiteren Änderung. Die vom Router bereitgestellten DNS-Einträge (also die meines ISPs) werden weiterhin aufgeführt. Das mag daran liegen, dass mein (kranker 😉 ) Router womöglich den genauen "request" missachtet und die DNS-Einträge trotzdem sendet. Vielleicht verhalten sich Router hier unterschiedlich.

Eigentlich nicht. Wenn der Client keine DNS-Server requestet, sollte er auch keine annehmen.

Erfolgreich war ich dagegen mit dieser Lösung: Kein prepend, keine Änderung an der Request-Zeile, sondern einfach zusätzlich

supersede domain-name-servers 212.18.1.5,212.18.2.5;

Wie gesagt: Diese Lösung funktionierte auch bei installiertem resolvconf.

Die Lösung im Abschnitt "Überschreiben der resolv.conf" funktioniert sowohl mit als auch ohne resolvconf.

Im Grunde genommen funktioniert resolvconf ja genauso. 😕

Ergänzung: Hat vielleicht was mit 293139 zu tun.

Schlage vor alle Beispieladressen auf den DNS des FoeBuD abzuändern, statt eines bestimmten ISPs um Werbung zu vermeiden. DNS-Server-Adressen von ISPs sollten nicht hier im Wiki stehen sondern auf externen Listen.

http://www.foebud.org/aboutus/gegen-internetsperren-in-einer-freien-gesellschaft-foebud-richtet-anti-zensur-dns-server-ein/view

Grüße Sbl

ja, mach mal - ist eine gute Idee

habs mal gemacht, waren ja nur 3 Textänderungen.

Da ja nun DNS-Server manuell ändern in Mode kommen wird (Google hat ja gerade für seinen geworben) sollte vielleicht zwei Themen daraus machen: Einen Artikel wegen (Router-) Problemen und eine Anleitung zum (manuellen, per NetworkManager) DNS-ändern (denn dafür müssen ja keine Routerprobleme vorhanden sein). Somit bleibt im letzteren Artikel auch Platz für Warnhinweise, welche Daten man mit seinen DNS-Anfragen preisgibt etc. um eine manuelle Anpassung für sich besser abwägen zu können.

Betr. DNS-Probleme, bitte Hand hoch wer den Block versteht 😉

Wenn DNS-Relay aktiviert ist, wird den DHCP-Clients die IP-Adresse des Routers als DNS-Server zugeteilt. Alle DNS-Anfragen an den Router werden an die DNS-Server Ihres Internetdiensteanbieters weitergeleitet. Wenn DNS-Relay deaktiviert ist, werden den DHCP-Clients vom Router die DNS-Server des Internetdiensteanbieters zugewiesen.

Ok, der Artikel mag für Fortgeschrittene sein, aber als Laie möchte man vll. auch verstehen. Was bedeutet (schändlich verkürzt) "on = dns-Anfrage an Router an dns-server des Isp" und "off = dns-Server des Isp werden von Router zugewiesen"? Wo ist der Unterschied? Könnte man das bitte so schreiben das ich es auch kapiere?

Rubrik "Einen bestimmten DHCP Server blockieren"

Befindet sich ... ein "falscher" DHCP Server im Netzwerk...

Was bitte ist ein "falscher" ..., könnte man das evtl. näher beschreiben, z.B. was ist dann ein "richtiger"? Danke.

1. Hallo

2. bitte nur eine Frage pro Thread

3. DNS:

   • Option on → Dein Router macht die DNS-Anfragen bei den DNS-Servern Deines Providers. Dein Router ist DNS-Server für Dein Netz und cached die DNS-Einträge.

   • Option off → Dein Router hat mit DNS nix zu tun, die Clients fragen selbst bei den DNS-Servern Deines Providers und cachen auch selber.

4. DHCP

DHCP-Server müssen "autorisiert" sein, damit sie gültige IP-Adressen vergeben können, in dem von Dir beschriebenen Netz läuft irgendwo ein unautorisierter DHCP-Serverdienst, der abgeschaltet werden sollte.

Grüßle

Fanatics

Danke an den Moderator für das Einordnen des Beitrags. Schlecht war nur das der vorher abgelegte Link zu 404 führte und ich raten konnte wo der Beitrag nun ist. Danke an Fanatics für die Erklärung zu 3., jetzt kann man den Unterschied erkennen.

bitte nur eine Frage pro Thread

Bitte? Es handelt sich doch um denselben Artikel.

in dem von Dir beschriebenen Netz

Bitte wo habe ich ein Netz beschrieben? Mit "falscher" ist also ein

unautorisierter DHCP-Serverdienst

gemeint. Davon abgesehen warum man dies mit "falscher" umschreibt, würde es wahrscheinlich zu weit führen im Artikel zu erklären wie man das feststellt.

ann schrieb:

Bitte? Es handelt sich doch um denselben Artikel.

Sorry, hab den Teil nur überflogen und mich auf die Fragen konzentriert. Wusste nicht, dass es um den Artikel geht. (War der Link vorhin auch schon in dem Post? 😳 )

Bitte wo habe ich ein Netz beschrieben?

s.o.

bzgl. "falscher" DHCP-Server:

Im Zusammenhang mit dem Artikel ist das schon ein falscher DHCP-Server, denn es könnte auch ein zweiter autorisierter DHCP-Server im Netz laufen. Und der Server, der zuerst ausliefert hat halt gewonnen (sozusagen).

Grüßle

Fanatics

ann schrieb:

Mit "falscher" ist also ein

unautorisierter DHCP-Serverdienst

gemeint. Davon abgesehen warum man dies mit "falscher" umschreibt, würde es wahrscheinlich zu weit führen im Artikel zu erklären wie man das feststellt.

Feststellen tut man das, indem man Probleme bemerkt. Entweder werden Adressen auf einmal doppelt vergeben, oder sie liegen in einem anderen Subnetz als erwartet, oder die Daten zu Gateway und/oder DNS-Server stimmen nicht. Das hängt stark davon ab, wieso dieser sog. Rogue-DHCP-Server existiert. Denkbar wären bspw. folgende Szenarios:

• Fehlgeschlagener Versuch des Admins, mit mehreren Servern Ausfallsicherheit herzustellen. Anstatt sich zu ergänzen, vergeben die Server parallel dieselben IP-Adressen an unterschiedliche Rechner.

• Es wird ein neuer Router oder Accesspoint im Netz installiert, aber es wird vergessen, den integrierten DHCP-Server abzuschalten.

• Ein böswilliger Mensch setzt absichtlich einen Rogue-DHCP-Server mit falschen DNS/Gateway-Daten auf, um den Traffic seiner Opfer über seinen eigenen Rechner leiten und abfangen zu können.