Probleme bei der Namensauflösung sind häufig und lästig. Diese Seite bietet einen Überblick über das DNS-System bei linuxmuster.net sowie eine Schritt-für-Schritt-Anleitung zur Fehlersuche. Sie gilt für alle Versionen der PaedML/OpenML und linuxmuster.net mit IPCop oder IPFire.
Als zentraler DNS-Server läuft ein Bind auf dem Server. Er kennt alle Rechner im Schulnetz, dafür sorgt import_workstations. Anfragen nach externen Rechnern leitet er an den IPFire/IPCop weiter, auf dem ebenfalls ein DNS-Server läuft (kein Bind sondern Dnsmasq). Der wiederum leitet die Anfragen an einen externen Nameserver weiter.
Die Clients erhalten per DHCP den Server als Nameserver zugewiesen.
Als allererstes testet man, ob vom IPFire aus ein externer Nameserver erreichbar ist. Das kann ein vorgelagerter Router sein, auf dem ein Nameserver läuft, man kann aber auch einen anderen Nameserver im Internet verwenden. Beliebt ist der Nameserver von Google mit der IP-Adresse 8.8.8.8 - hierauf beziehen sich die Beispiele.
Beim IPFire testet man als root auf der Kommandozeile:
dig @8.8.8.8 www.heise.de
Die Ausgabe von dig
ist ein wenig unübersichtlich. Wichtig ist folgender Abschnitt:
;; ANSWER SECTION: www.heise.de. 3361 IN A 193.99.144.85 ;; Query time: 38 msec ;; SERVER: 8.8.8.8#53(8.8.8.8)
Eine Answer Section mit einer IP-Adresse zeigt, dass die Anfrage erfolgreich war. Weiter unten wird der Server angegeben, der geantwortet hat.
Hier muss man zwei Fälle unterscheiden. Lautet die Fehlermeldung connection timed out; no servers could be reached
, so ist der externe Nameserver nicht erreichbar (Achtung, das (1 server found)
in der Ausgabe bedeutret etwas anderes). Es liegt ein Problem mit der Anbindung nach draußen vor, eventuell filtert auch ein vorgelagerter Router DNS-Anfragen heraus.
Erhält man jedoch eine Antwort (was man an der oben wiedergegebenen Zeile mit ;;SERVER: 8.8.8.8 …
erkennt), aber keine Answer Section mit IP-Adresse, so konnte der externe Nameserver den Namen nicht auflösen. Beim Google-Server ist ein Tippfehler die wahrscheinlichste Ursache, verwendet man den Nameserver eines vorgelagerten Routers, so sollte man dessen Konfiguration überprüfen - oder gleich einen anderen Nameserver verwenden.
Nun wird getestet, ob der Nameserver auf dem IPFire läuft und auch externe Adressen auflösen kann.
Wieder als root auf der Kommandozeile versucht man:
dig @10.16.1.254 www.heise.de
Wenn in der Ausgabe eine Answer Section mit der IP-Adresse vorhanden ist, geht es weiter bei Schritt 3.
Wenn es nicht klappt, dann ruft man setup
auf und trägt den externen DNS-Server ein - vielleicht zur Sicherheit auch einen zweiten. Wenn der Fehler weiterhin besteht, dann ist die IPFire-Installation grundlegend fehlerhaft. Anstatt einer weiteren Fehlersuche empfiehlt sich eine Neuinstallation.
Der Nameserver auf dem IPFire funktioniert, nun gilt es zu testen, ob er auch korrekt genutzt wird.
Auch hier kann man wieder dig
verwenden, diesmal ohne einen Nameserver anzugeben:
dig www.heise.de
In der Ausgabe ist zweierlei wichtig: Zum einen sollte als antwortender Server die 127.0.0.1 oder 10.16.1.254 genannt werden. Zum anderen sollte wieder eine Answer Section mit IP-Adresse enthalten sein.
Auch in der Ausgabe von
ping www.heise.de
sollte die IP-Adresse zu finden sein.
Mögliche Fehlerquelle ist eine beschädigte Datei /etc/resolv.conf
. Auf dem IPFire sollte sie ausschließlich folgende Zeile enthalten:
nameserver 127.0.0.1
Außerdem sollte die Datei /etc/host.conf
so aussehen:
order hosts,bind
An dieser Stelle funktioniert auf dem IPFire alles, wie es soll. Nun geht es an den Server,die folgenden Tests führt man also als root auf dem Server aus.
Zunächst stellt man sicher, dass der IPFire erreichbar ist:
dig @10.16.1.254 www.heise.de
Die Kommunikation zwischen Server und IPFire klappt nicht, wahrscheinlich liegt ein Netzwerkproblem vor.
Nun befragt man den Nameserver auf dem Server:
dig @10.16.1.1 www.heise.de
Bei Problemen muss man genau die Ausgabe untersuchen:
- Es gibt keine Zeile, die mit ;; SERVER: 10.16.1.1
beginnt. Dann läuft der Nameserver nicht. Wenn ein service bind9 restart
(bzw. /etc/init.d/bind9 restart
für PaedML/OpenML 5.X) das Problem nicht beseitigt und auch ein import_workstations
nicht, dann muss man die Konfiguration des Bind näher untersuchen. Wenn ein Backup vorhanden ist, kann man auch das Verzeichnis /etc/bind
komplett wiederherstellen.
- Der Nameserver läuft, kann aber den Namen nicht auflösen. Dann fehlt vermutlich der Eintrag
forwarders { 10.16.1.254; };
in der Datei /etc/bind/named.conf.options
Wie beim IPFire gilt: Der Server soll nun auch bei Bedarf den Nameserver befragen.
Der Test läuft wieder mit dig
, aber ohne einen Nameserver anzugeben:
dig www.heise.de
Auch hier gilt: Zum einen sollte als antwortender Server die 10.16.1.1 genannt werden. Zum anderen sollte eine Answer Section mit IP-Adresse enthalten sein.
Auch in der Ausgabe von
ping www.heise.de
sollte die IP-Adresse zu finden sein.
Mögliche Fehlerquelle ist wie beim IPFire eine beschädigte Datei /etc/resolv.conf
. Auf dem Server sollte sie beispielsweise so aussehen:
nameserver 10.16.1.1 search linuxmuster.lokal
Und noch der Inhalt der Datei /etc/host.conf
:
order hosts,bind multi on
Die Clients erhalten den Nameserver per DHCP zugewiesen, Fehlerquelle ist also eine verbogene DHCP-Konfiguration.
Testen kann man auch hier mit:
dig www.heise.de
Windowsrechner kennen den Befehl nicht, hier (und auch bei den meisten Linux-Varianten) kann man stattdessen nslookup
verwenden:
nslookup www.heise.de
Oder auch:
ping www.heise.de
Wenn es wider Erwarten Probleme gibt, sollte man die DHCP-Konfiguration überprüfen, bei Windowsrechnern etwa mit:
ipconfig /all
Eventuell hilft es auch, eine statische IP-Adresse zu konfigurieren und anschließend wieder auf DHCP umzustellen.
Auf dem Server kann man mit import_workstations
die DHCP-Konfiguration neu erzeugen.