Problembehandlung zu DNS
Werbung
Problembehandlung zu DNS (Engl. Originaltitel: Troubleshooting DNS) Kapitel 13 aus dem englischsprachigen Buch DNS on Windows 2000 (Second Edition), herausgegeben von O'Reilly & Associates, Inc. Im letzten Kapitel wurde erläutert, wie mithilfe von nslookup Anfragen erstellt werden können. In diesem Kapitel erfahren Sie, wie nslookup – gemeinsam mit herkömmlichen TCP/IP-Netzwerktools wie dem bereits bewährten ping – zur Behandlung konkreter Probleme mit DNS verwendet werden kann. Es liegt in der Natur der Sache, dass die Problembehandlung kein einfaches Thema ist. Ausgehend von einem der zahlreichen Symptome wird versucht, die Ursache zu finden. Natürlich kann hier nicht auf alle Probleme eingegangen werden, die im Umgang mit dem Internet auftreten können; aber wir werden unser Möglichstes tun, um Ihnen zu zeigen, wie besonders häufig auftretende Probleme erkannt werden können. Dabei sollen Ihnen auch Methoden zur Problembehandlung vermittelt werden, die Ihnen das Nachverfolgen von weniger bekannten Problemen erleichtern, auf die hier nicht eingegangen wird. Liegt das Problem tatsächlich bei DNS? Bevor auf die Problembehandlung im Zusammenhang mit DNS (Domain Name System) eingegangen wird, sollten wir zunächst sicherstellen, dass Sie erkennen können, ob ein Problem von DNS oder einem anderen Namensdienst verursacht wurde. Bei Hosts unter Windows kann nur schwer festgestellt werden, ob der Fehler tatsächlich bei DNS liegt. Windows unterstützt eine Reihe von Namensdiensten: DNS, WINS, HOSTS, LMHOSTS und viele andere. Das grundlegende Tool nslookup von Windows 2000 wird allerdings unabhängig von diesen Namensdiensten ausgeführt. Dementsprechend kann es vorkommen, dass Sie nslookup auf einem Computer unter Windows 2000 ausführen und den Namenserver abfragen können, während der Dienst, bei dem das Problem auftritt, einen anderen Namensdienst verwendet. Wie können Sie erkennen, wo das Problem liegt? Zunächst müssen Sie herausfinden, bei welchem Programm das Problem auftritt. Wenn es sich um einen TCP/IP-Client handelt, wie beispielsweise telnet oder ftp, kann der Fehler bei DNS oder bei der HOSTS-Datei liegen. Wenn die NetBIOS-Benennung von einem Dienstprogramm unterstützt wird, beispielsweise net (wie in net use), könnte der Fehler auch durch WINS oder die LMHOSTSDatei verursacht werden. Andere Clients, wie beispielsweise ping, die entweder einen DNS- oder einen NetBIOS-Namen als Argument verwenden, können jeden dieser Namensdienste verwenden. Berücksichtigen Sie dann die Reihenfolge, in der Windows die Namensdienste verwendet. Sie sollten die verschiedenen Dienste bei der Problembehandlung in dieser Reihenfolge untersuchen. Diese Tipps sollten Ihnen die Identifizierung der fehlerhaften Komponente oder zumindest die Eingrenzung der möglichen Fehlerquellen erleichtern. Wenn Sie die möglichen Fehlerquellen bereits eingegrenzt haben und DNS dazu zählt, sollten Sie dieses Kapitel unbedingt lesen. Überprüfen des Caches Wie bereits erwähnt, können Sie die Inhalte des Namenservercaches mithilfe der DNS-Konsole überprüfen. Dies kann sehr praktisch sein, wenn Sie vermuten, dass der Namenserver fehlerhafte oder veraltete Daten von einem anderen Server zwischengespeichert hat. Klicken Sie auf das Pluszeichen (+) neben dem Namen des Servers im linken Fensterbereich der DNS-Konsole, um den Cache eines Servers zu überprüfen. Der Ordner Zwischengespeicherte Lookupvorgänge (Cached Lookups) wird angezeigt. Klicken Sie entweder auf das Pluszeichen links daneben, oder doppelklicken Sie auf das Ordnersymbol oder die Bezeichnung, um die nächste Ebene zu erweitern. Auf diese Weise werden die obersten Domänen angezeigt, für die der Namenserver Daten zwischengespeichert hat. Erweitern Sie die Ebenen bis zu dem Domänennamen, mit dem die gesuchten zwischengespeicherten Daten verbunden sind. In Abbildung 13-1 wurden die Ebenen bis zur Ebene acmebw.com erweitert, um nach zwischengespeicherten Daten zu suchen. Abbildung 13-1: NS- und A-Einträge für "acmebw.com" im Zwischenspeicher Wie Sie im rechten Fensterbereich erkennen können, hat der Namenserver drei NS-Einträge und einen A-Eintrag für acmebw.com zwischengespeichert. Durch Doppelklicken auf net und dann auf acmebw können die zwischengespeicherten Adressen der Namenserver ermittelt werden. Doppelklicken Sie auf einen Eintrag im rechten Fensterbereich, um die Gültigkeitsdauer (Time-to-Live oder TTL) der zwischengespeicherten Daten anzuzeigen. Im Ergebnisfenster wird die Gültigkeitsdauer des Eintrags angezeigt, vorausgesetzt, die erweiterte Ansicht wurde für die DNS-Konsole aktiviert (wählen Sie dazu Ansicht und dann Erweitert aus). Abbildung 13-2 zeigt das Ergebnisfenster nach dem Doppelklicken auf den A-Eintrag acmebw.com. Abbildung 13-2: Die Gültigkeitsdauer eines zwischengespeicherten Eintrags Vor dem Überprüfen der Gültigkeitsdauer sollten Sie die DNS-Konsole unbedingt aktualisieren, indem Sie die F5-Taste drücken oder im Menü Vorgang auf Aktualisieren klicken. Andernfalls wird möglicherweise eine längere als die aktuelle Gültigkeitsdauer angezeigt. Wenn Sie mit der rechten Maustaste auf den Eintrag geklickt haben, haben Sie möglicherweise die Option Eintrag löschen bemerkt. Diese Option ist für BIND nicht verfügbar. Mithilfe der DNS-Konsole können Sie einzelne Einträge zwischengespeicherter Daten nacheinander löschen. Wenn Sie wissen, dass einige Einträge im Zwischenspeicher des Namenservers nicht mehr aktuell sind, können Sie sie löschen und dafür sorgen, dass der Namenserver aktuelle Einträge von einem autorisierenden Server übernimmt. Liste möglicher Probleme Nun sollen einige häufig auftretende Probleme erläutert werden. Viele dieser Probleme sind leicht zu erkennen und problemlos zu korrigieren. Sie sollen hier behandelt werden, da ihr Auftreten fast schon eine Selbstverständlichkeit ist, denn sie werden durch besonders "beliebte" Fehler verursacht. Die Probleme werden im Folgenden aufgeführt, wobei die Reihenfolge willkürlich gewählt wurde. 1. Seriennummer wurde nicht erhöht Dieses Problem wird nur auftreten, wenn Sie Änderungen an der Zonendatendatei manuell vornehmen und nicht mithilfe der DNS-Konsole. Die DNS-Konsole erhöht die Seriennummer im SOA-Eintrag bei der Änderung von Zonendaten automatisch, so dass Sie sich keine Gedanken darüber machen müssen. Das bedeutet allerdings auch, dass Sie möglicherweise nicht daran gewöhnt sind, die Seriennummer zu aktualisieren, so dass Sie es beim manuellen Ändern vergessen könnten. Das wichtigste Anzeichen für dieses Problem ist die Tatsache, dass die untergeordneten Namenserver keine der von Ihnen an der Zone auf dem primären Server vorgenommenen Änderungen übernehmen. Die untergeordneten Server erkennen die Änderung der Zonendaten nicht, weil die Seriennummer nicht geändert wurde. Wie können Sie überprüfen, ob Sie die Seriennummer erhöht haben? Leider ist das nicht so einfach. Wenn Sie sich nicht an die alte Seriennummer erinnern können und die Seriennummer keine Hinweise auf das Aktualisierungsdatum enthält, gibt es keine direkte Möglichkeit, um festzustellen, ob sie geändert wurde. 1 Beim Starten des primären Servers werden die aktualisierten Zonendatendateien geladen, auch wenn die Seriennummer nicht geändert wurde. Die beste Lösung besteht darin, die vom primären und von einem untergeordneten Server zurückgegebenen Daten mithilfe von nslookup zu vergleichen. Wenn sie unterschiedliche Daten zurückgeben, haben Sie möglicherweise vergessen, die Seriennummer zu erhöhen. Wenn Sie sich an eine vor kurzem vorgenommene Änderung erinnern können, können Sie nach diesen Daten suchen. Wenn Sie sich nicht daran erinnern können, können Sie auch die Zone von einem primären und von einem untergeordneten Server übertragen, wobei Sie die Ergebnisse sortieren und die Dateien mithilfe eines geeigneten Tools vergleichen sollten. Es kann zwar nicht auf einfache Weise festgestellt werden, ob die Zone übertragen wurde, aber Sie können problemlos sicherstellen, dass die Zone übertragen wird. Sie müssen lediglich die Seriennummer der Zonenkopie auf dem primären Server erhöhen, indem Sie auf den SOA-Eintrag in der DNS-Konsole doppelklicken und das Feld für die Seriennummer manuell bearbeiten. Die untergeordneten Server werden die neuen Daten innerhalb des Aktualisierungsintervalls bzw. vorher übernehmen, wenn Sie BENACHRICHTIGEN verwenden. 2. Primärer Masterserver wurde nicht neu gestartet Wie das vorherige Problem wird auch dieses Problem nur entstehen, wenn Sie die Zonendatendateien manuell ändern. Die DNS-Konsole fügt Daten direkt hinzu bzw. löscht sie, so dass der primäre Masternamenserver nicht neu gestartet werden muss. Wenn Sie die DNS-Konsole allerdings nicht verwenden, vergessen Sie möglicherweise, den primären Masternamenserver nach dem Bearbeiten einer Zonendatendatei neu zu starten. Der Namenserver wird nicht erkennen, dass neue Daten geladen werden müssen, denn er überprüft nicht automatisch, ob die Datei geändert wurde. Dementsprechend werden die von Ihnen vorgenommenen Änderungen nicht in den Daten des Namenserver enthalten sein. Neue Zonen werden also nicht geladen und neue Einträge nicht an die untergeordneten Server weitergegeben. Sie können den Zeitpunkt des letzten Neustarts des Namenservers überprüfen, indem Sie in der Ereignisanzeige nach dem letzten Eintrag suchen, der Folgendes beinhaltet: Der DNS-Server wurde gestartet. Anhand des Datums und der Uhrzeit der Ereignisse können Sie erkennen, wann Sie den Namenserver das letzte Mal neu gestartet haben. Wenn der Zeitpunkt des Neustarts nicht mit dem der letzten Änderung übereinstimmt, sollten Sie den Namenserver mithilfe der DNS-Konsole beenden, neu starten und die Daten erneut laden. Überprüfen Sie, ob Sie die Seriennummern der geänderten Zonendatendateien erhöht haben. 3. DNS-Server verliert manuelle Änderungen Es folgt noch ein letzter wichtiger Hinweis zu manuellen Änderungen: Denken Sie daran, dass der Microsoft DNS-Server die Zonendatendateien regelmäßig aktualisiert. Jedes Mal, wenn Sie Änderungen an den Daten einer Zone mithilfe der DNS-Konsole vornehmen, steht ein Schreibvorgang aus: Bevor der DNS-Server beendet wird, muss er die Datendatei der Zone überschreiben, um die Änderungen nicht zu verlieren. Diesen Vorgang können Sie sich als eine Art "Schmierzettel" im Arbeitsspeicher vorstellen: Das Betriebssystem muss die Daten vor dem Beenden auf die Festplatte schreiben. 1 1 Wenn Sie, wie viele Benutzer, das Datum in die Seriennummer kodieren (beispielsweise ist 1998010500 der erste Verweis auf Daten am 5. Januar 1998), können Sie sofort feststellen, ob Sie die Seriennummer nach dem Ändern aktualisiert haben. Mit der DNS-Konsole ist das jedoch nicht möglich, denn sie erhöht die Seriennummer bei jeder Änderung immer nur um eins. Wenn Sie eine Zonendatendatei manuell ändern, während ein Schreibvorgang aussteht, werden Sie die Änderungen beim Beenden des Namenservers verlieren. Sie möchten beispielsweise eine Delegierung zur neuen untergeordneten Domäne der Zone movie.edu hinzufügen, während der Server ausgeführt wird und ein Schreibvorgang aussteht. Nachdem die Änderung vorgenommen wurde, müssen Sie den Server beenden und erneut starten, damit die Zonendaten erneut gelesen werden. Beim Beenden des Servers wird jedoch die Zonendatendatei der Zone movie.edu überschrieben, so dass die Delegierung nicht mehr vorhanden ist. Wenn Sie die Ereignisanzeige sorgfältig überwachen (wie es sich empfiehlt), werden Sie vor dem Beenden des Servers folgende Meldung sehen: Der DNS-Server hat Version 37 der Zone movie.edu in die Datei Movie.edu.dns geschrieben. Sobald Sie den Server zum Überschreiben der Zonendatendateien gezwungen haben (klicken Sie dazu auf Vorgang und anschließend auf Serverdatendateien aktualisieren), ist der Server mit den Zonendatendateien synchronisiert und muss diese beim Beenden nicht überschreiben. Deshalb sollten Sie beim manuellen Ändern der Zonendatendateien entweder zuvor den Server beenden (der Server kann natürlich keine Abfragen beantworten, während Sie die Änderung vornehmen) oder den Server mithilfe der DNS-Konsole mit den Zonendatendateien synchronisieren und die Änderung anschließend vornehmen. 4. Untergeordneter Server kann Zonendaten nicht laden Wenn ein untergeordneter Namenserver die aktuelle Seriennummer für eine Zone nicht vom Masterserver abrufen kann, werden Sie zunächst nicht gewarnt. Wenn das Problem jedoch weiterhin besteht und der untergeordnete Server innerhalb des Beendigungsintervalls nicht ermitteln kann, ob die Daten aktuell sind, wird er die Zone nicht länger beibehalten. Auf einem Microsoft DNS-Server wird diese oder eine ähnliche Meldung in der Ereignisanzeige angezeigt: Die Zone movie.edu wurde entfernt, bevor die Zonenübertragung durchgeführt werden konnte bzw. bevor die Zone vom Zonenmaster (als Quelle der Zone) aktualisiert werden konnte. Die Zone ist nicht mehr verfügbar. Nachdem die Zone entfernt wurde, werden Sie SERVFAIL-Fehlermeldungen erhalten, wenn Sie Daten in der Zone vom Namenserver abfragen: C:\> nslookup robocop wormhole.movie.edu. Server: wormhole.movie.edu Addresses: 192.249.249.1, 192.253.253.1 *** robocop.movie.edu wurde von wormhole.movie.edu nicht gefunden: Serverfehler Dieses Problem kann eine der folgenden drei Ursachen haben: eine Unterbrechung der Verbindung zum Masterserver aufgrund eines Netzwerkfehlers, eine falsche IP-Adresse, die für den Masterserver konfiguriert wurde, oder ein Syntaxfehler in der Zonendatendatei auf dem Masterserver. Überprüfen Sie zunächst mithilfe der DNS-Konsole die Adresse auf den Masterservern, von denen der untergeordnete Namenserver Daten zu laden versucht. Klicken Sie mit der rechten Maustaste auf den Domänennamen der Zone im linken Fensterbereich, wählen Sie Eigenschaften aus, und sehen Sie sich die Registerkarte Allgemein (General) in Abbildung 13-3 an. Abbildung 13-3: Das Fenster mit den Zoneneigenschaften, in dem die Masterserver angezeigt werden Stellen Sie sicher, dass es sich bei der IP-Adresse tatsächlich um die Adresse des Masternamenservers handelt. Wenn dies der Fall ist, sollten Sie die Verbindung zu dieser IP-Adresse überprüfen: C:\> ping 192.249.249.3 Ping wird ausgeführt für 192.249.249.3 mit 32 Bytes Daten: Zeitüberschreitung Zeitüberschreitung Zeitüberschreitung Zeitüberschreitung der der der der Anforderung. Anforderung. Anforderung. Anforderung. Wenn der Masterserver nicht verfügbar ist, sollten Sie sicherstellen, dass der Host des Servers wirklich ausgeführt wird (überprüfen Sie beispielsweise, ob er eingeschaltet ist) und dass kein Netzwerkproblem besteht. Sie sollten auch überprüfen, ob der Masterserver autorisierende Antworten zurückgibt, wenn Daten in der Zone abgefragt werden. Wenn der Masterserver als nicht für die Zone autorisierender Masterserver antwortet, wird der untergeordnete Namenserver die Zone nicht von dort übertragen. Mit nslookup können Sie folgendermaßen überprüfen, ob eine autorisierende Antwort für den SOA-Eintrag der Zone vom Masterserver gesendet wurde: C:\> nslookup -norec -type=SOA movie.edu. 192.249.249.3 Mit diesem Befehl wird eine nicht rekursive Abfrage für den SOA-Eintrag der Zone movie.edu zum Namenserver mit der Adresse 192.249.249.3 gesendet. Es muss eine nicht rekursive Abfrage gesendet werden, damit der Namenserver mit der Adresse 192.249.249.3 nicht versucht, die Abfrage zu einem anderen Server zu senden. Wenn der Masterserver richtig konfiguriert ist, sollte die Antwort auf diese Anfrage autorisierend sein. (Denken Sie daran, dass die Antwort autorisierend ist, sofern nslookup nicht die Meldung "Nicht-autorisierende Antwort" zurückgibt). Eine nicht autorisierende Antwort kann darauf hinweisen, dass der Masterserver beim Laden der Zone ein Problem hatte, das auf einen Syntaxfehler in der Zonendatendatei zurückzuführen ist. Wenden Sie sich an den Administrator des Masterservers und bitten Sie ihn, die Einträge in der Ereignisanzeige oder das SyslogProtokoll nach Hinweisen auf einen Syntaxfehler zu überprüfen. Es geschieht sicher sehr selten, dass ein Namenserver unter Windows 2000 aufgrund eines Syntaxfehlers in einer Zonendatendatei in einen nicht autorisierenden Namenserver geändert wird, aber bei älteren BIND-Namenservern ist dies möglich. Wenn Ihr Namenserver einer Zone untergeordnet ist, deren primärer Masterserver ein BIND-Namenserver ist, der keine Autorität für die Zone fordert, könnte das Problem auf einen Syntaxfehler zurückzuführen sein. Wenn die Antwort zu der Abfrage autorisierend ist, aber der untergeordnete Server die Zone immer noch nicht übertragen kann, können Sie versuchen, die Zone mithilfe des Befehls ls in nslookup manuell zu übertragen (wie in Kapitel 12 beschrieben, kann mithilfe von ls eine Zonenübertragung durchgeführt werden). Wenn dieser oder ein ähnlicher Fehler auftritt, wird die Zonenübertragung wahrscheinlich vom Masterserver eingeschränkt. C:\> nslookup - 192.249.249.3 Standardserver: terminator.movie.edu Address: 192.249.249.3 > ls movie.edu [terminator.movie.edu] *** Domäne movie.edu kann nicht aufgeführt werden: Query refused > Wenden Sie sich an den Administrator des Namenservers und fragen Sie ihn, ob er die Zonenübertragung eingeschränkt hat. Bitten Sie den Administrator (sofern er den Microsoft DNS-Server ausführt), die Optionen auf der Registerkarte Zonenübertragungen (Zone Transfers) im Fenster Eigenschaften (Properties) für die Zone zu überprüfen, die übertragen werden soll. Wenn der Remoteserver BIND ausführt, sollten Sie den Administrator fragen, ob er Zonenübertragungen mithilfe der Features xfrnets oder allow-transfer beschränkt hat. Wenn das Problem behoben ist und der Server die Zone überträgt, wird die folgende oder eine ähnliche Meldung in der Ereignisanzeige angezeigt: Es wurde eine neuere Version, Version 212, der Zone movie.edu auf dem DNS-Server 192.249.249.3 gefunden. Die Zonenübertragung wird zurzeit durchgeführt. Der DNS-Server hat Version 212 der Zone movie.edu in die Datei movie.edu.dns geschrieben. 5. Adresse wurde zur Zone hinzugefügt, aber entsprechender PTR-Eintrag wurde nicht hinzugefügt Da die Zuordnungen von Hostnamen zu IP-Adressen nicht mit den Zuordnungen von IP-Adressen zu Hostnamen in DNS zusammenhängen, kann das Hinzufügen eines PTR-Eintrags für den neuen Host schnell vergessen werden. Während das Hinzufügen des A-Eintrags intuitiv geschieht, vermuten viele Benutzer, die an Hosttabellen gewöhnt sind, dass durch das Hinzufügen eines Adresseintrags automatisch auch die umgekehrte Zuordnung erfolgt. Dies ist allerdings nicht der Fall. Sie müssen für den Host einen PTR-Eintrag zu der entsprechenden Zone in-addr.arpa hinzufügen. Die DNS-Konsole enthält das Kontrollkästchen Verknüpften PTR-Eintrag erstellen, das diese Aufgabe vereinfacht. Aktivieren Sie dieses Kontrollkästchen, wenn Sie Neuer Host auswählen. Wenn für den Host kein PTR-Eintrag hinzugefügt wird, führt dies i. d. R. zum Fehlschlagen von Authentifizierungen. Benutzer des Hosts können beispielsweise die Dienstprogramme rsh oder rcp nicht in Verbindungen mit anderen Hosts verwenden. Die Server, zu denen diese Programme eine Verbindung herstellen, müssen die IP-Adresse der Verbindung zu einem Domänennamen zuordnen können, um die Autorisierungsdateien zu überprüfen. Darüber hinaus verweigern viele große FTP-Archive, einschließlich ftp.uu.net, den anonymen FTP-Zugriff für Hosts, deren IP-Adressen keinem Domänennamen zugeordnet werden können. Der FTP-Server von ftp.uu.net gibt eine Meldung aus, die u. a. folgende Hinweise enthält: 530530530530530531- Sorry, we're unable to map your IP address 140.186.66.1 to a hostname in the DNS. This is probably because your nameserver does not have a PTR record for your address in its tables, or because your reverse nameservers are not registered. We refuse service to hosts whose names we cannot resolve. Hier wird deutlich, warum Sie ftp nicht anonym verwenden können. Bei anderen FTP-Sites werden keine Informationsmeldungen ausgegeben, sondern der Dienst wird direkt verweigert. Mithilfe von nslookup können Sie schnell überprüfen, ob Sie den PTR-Eintrag vergessen haben: C:\> nslookup Standardserver: terminator.movie.edu Address: 192.249.249.3 > beetlejuice --Auf eine Zuordnung zwischen Hostnamen und Adresse prüfen Server: terminator.movie.edu Address: 192.249.249.3 Name: beetlejuice.movie.edu Address: 192.249.249.23 > 192.249.249.23 --Now check for a corresponding address-to-hostname mapping Server: terminator.movie.edu Address: 192.249.249.3 *** 192.249.249.23 wurde von terminator.movie.edu nicht gefunden: Domäne nicht vorhanden Durch eine schnelle Überprüfung der DNS-Konsole oder der Datei 249.249.192.in-addr.arpa.dns auf dem primären Masterserver für 249.249.192.in-addr.arpa erfahren Sie, ob der PTR-Eintrag bereits zur Zone hinzugefügt wurde. 6. Falscher Domänenname im RDATA-Abschnitt des Eintrags Wenn Sie mithilfe der DNS-Konsole CNAME-, MX- und NS-Einträge hinzufügen, müssen Sie den vollqualifizierten Domänennamen des Hosts für die Daten eingeben, die für Ressourceneinträge spezifisch sind. Die DNS-Konsole geht davon aus, dass der im RDATA-Feld eingegebene Name vollqualifiziert ist. Wenn Sie versuchen, einen CNAME-Eintrag zu erstellen (wie in Abbildung 13-4 dargestellt), wird der CNAME-Eintrag in der Zonendatendatei folgendermaßen angezeigt: bigt IN NS terminator. Das haben Sie vermutlich nicht beabsichtigt, da die übergeordnete Domäne terminator nicht existiert. Sie sind wahrscheinlich davon ausgegangen, dass die DNS-Konsole den Namen der Zone an den Namen anfügt, wenn Sie den Punkt weglassen. Falsch gedacht. Abbildung 13-4: Erstellen eines CNAME-Eintrags (Beispiel zur falschen Vorgehensweise) Diese Fehler entdecken Sie schnell, indem Sie die Zonendatendateien überprüfen (nachdem Sie auf Vorgang und auf Serverdatendateien aktualisieren geklickt haben) oder indem Sie nslookup verwenden. C:\> nslookup -type=ns movie.edu. Server: terminator.movie.edu Address: 192.249.249.3 movie.edu nameserver = wormhole.movie.edu movie.edu nameserver = terminator wormhole.movie.edu internet address = 192.253.253.1 wormhole.movie.edu internet address = 192.249.249.1 7. Unterbrechung der Netzwerkverbindung Obwohl das Internet heutzutage zuverlässiger ist als noch zu Zeiten von ARPANET, kommen Unterbrechungen der Netzwerkverbindung noch immer relativ häufig vor. Diese Fehler wirken i. d. R. wie eine Beeinträchtigung der Leistung: C:\> nslookup nisc.sri.com. Server: terminator.movie.edu Address: 192.249.249.3 DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 4 seconds. DNS request timed out. timeout was 8 seconds. *** Zeitüberschreitung bei Anforderung an terminator.movie.edu. Mithilfe von nslookup können Sie die Namen und Adressen der Namenserver nachschlagen, zu denen Ihr Namenserver zum Auflösen des Namens eine Verbindung herstellen muss: C:\> nslookup Default Server: terminator.movie.edu Address: 192.249.249.3 > set type=ns > sri.com. Server: terminator.movie.edu Address: 192.249.249.3 Non-authoritative answer: sri.com nameserver = NS.sri.com sri.com nameserver = NS.CSL.sri.com sri.com nameserver = TURTLE.MCC.COM sri.com nameserver = NS1.sri.com NS.sri.com internet address = 128.18.30.66 NS.CSL.sri.com internet address = 130.107.4.94 NS.CSL.sri.com internet address = 192.12.33.94 TURTLE.MCC.COM internet address = 128.62.1.215 NS1.sri.com internet address = 128.18.30.65 > com. Server: terminator.movie.edu Address: 192.249.249.3 Non-authoritative answer: com nameserver = C.ROOT-SERVERS.NET com nameserver = D.ROOT-SERVERS.NET com nameserver = E.ROOT-SERVERS.NET com nameserver = I.ROOT-SERVERS.NET com nameserver = F.ROOT-SERVERS.NET com nameserver = G.ROOT-SERVERS.NET com nameserver = J.GTLD-SERVERS.INTERNIC.NET com nameserver = A.ROOT-SERVERS.NET com nameserver = H.ROOT-SERVERS.NET com nameserver = B.ROOT-SERVERS.NET C.ROOT-SERVERS.NET internet D.ROOT-SERVERS.NET internet E.ROOT-SERVERS.NET internet I.ROOT-SERVERS.NET internet F.ROOT-SERVERS.NET internet G.ROOT-SERVERS.NET internet J.GTLD-SERVERS.INTERNIC.NET A.ROOT-SERVERS.NET internet H.ROOT-SERVERS.NET internet B.ROOT-SERVERS.NET internet address = 192.33.4.12 address = 128.8.10.90 address = 192.203.230.10 address = 192.36.148.17 address = 192.5.5.241 address = 192.112.36.4 internet address = 198.41.0.21 address = 198.41.0.4 address = 128.63.2.53 address = 128.9.0.107 Anschließend können Sie die Verbindung zwischen dem Host und diesen Servern überprüfen. Auch die Verwendung von ping wird vermutlich zu keinem anderen Ergebnis führen als die Verwendung des Namenservers. Sollte dies doch der Fall sein, sollten Sie überprüfen, ob die Remotenamenserver tatsächlich ausgeführt werden. C:\> ping 128.18.30.66 --ping first sri.com name server Pinging 128.18.30.66 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. C:\> ping 130.107.4.94 --ping second sri.com name server Pinging 130.107.4.94 with 32 bytes of data: Request Request Request Request timed timed timed timed out. out. out. out. Nun müssen Sie nur noch herausfinden, wo das Netzwerk unterbrochen wurde. Mithilfe von Dienstprogrammen wie tracert können Sie ermitteln, ob das Problem in Ihrem Netzwerk, im Zielnetzwerk oder zwischen den beiden Netzwerken besteht. Beim Nachverfolgen derartiger Probleme helfen oft einfach logische Überlegungen. Wenn sich beispielsweise beim Testen mit ping gezeigt hat, dass Sie keinen der Stammnamenserver für das Internet erreichen konnten, ist es unwahrscheinlich, dass das lokale Netzwerk jedes Stammes ausgefallen ist oder dass die wichtigsten kommerziellen Backbonenetzwerke innerhalb des Internets vollständig zusammengebrochen sind. Das Prinzip hinter dem Occam-Auswahlverfahren ("Occam's Razor") besagt, dass die einfachste Bedingung, durch die dieses Verhalten verursacht werden kann (hier eine Unterbrechung der Verbindung zwischen Ihrem Netzwerk und dem Internet), die wahrscheinlichste Ursache ist. 8. Fehlende Delegierung für die untergeordnete Domäne Auch wenn Ihre Anfragen von dem durch ICANN akkreditierten Registrator so schnell wie möglich verarbeitet werden, kann es ein bis zwei Wochen dauern, bis die Delegierung der untergeordneten Domäne auf den Stammnamenservern angezeigt wird. Die Dauer kann variieren, abhängig von der übergeordneten Instanz (entweder ein durch ICANN akkreditierter Registrator oder ein anderer Zonenadministrator). Einige dieser übergeordneten Instanzen arbeiten schnell und zuverlässig, andere dagegen langsam und unzuverlässig. Aber genau wie im richtigen Leben haben Sie leider keine Wahl. Der Namenserver kann im Namespace der Internetdomäne Daten nachschlagen, bis die Delegierungsdaten auf den Namenservern der übergeordneten Zone angezeigt werden, aber kein anderer Internetbenutzer (außerhalb Ihrer Domäne) kann Daten in Ihrem Namespace suchen. Das bedeutet, dass Sie E-Mail-Nachrichten außerhalb Ihrer Domäne versenden, die Empfänger aber nicht antworten können. Darüber hinaus kann keine Person mithilfe der Dienstprogramme telnet, ftp oder ping in Verbindung mit Ihren Hosts treten (nach Namen). Dies gilt auch für alle möglicherweise von Ihnen ausgeführten untergeordneten Domänen in in-addr.arpa. Namenserver im Internet können Adressen in Ihrem Netzwerk nicht zurückverfolgen und zuordnen, bis die übergeordnete Domäne diese untergeordneten Domänen an Ihre Server delegiert. Sie müssen den NS-Eintrag für Ihre Zone bei einem übergeordneten Namenserver abfragen, um zu ermitteln, ob die Delegierung der Zone die Namenserver der übergeordneten Zone erreicht hat. Wenn der übergeordnete Namenserver über die Daten verfügt, kann jeder Namenserver im Internet die Daten finden: C:\> nslookup Default Server: terminator.movie.edu Address: 192.249.249.3 > server a.root-servers.net. --Query a root name server Default Server: a.root-servers.net Address: 198.41.0.4 > set norecurse --Instruct the server to answer out of > set type=ns --its own data and to look for NS records > 249.249.192.in-addr.arpa. --for 249.249.192.in-addr.arpa Server: a.root-servers.net Address: 198.41.0.4 *** 249.249.192.in-addr.arpa wurde von a.root-servers.net nicht gefunden. : Non-existent domain Hier wurde die Delegierung offensichtlich noch nicht hinzugefügt. Sie können entweder warten oder sich an den Administrator der übergeordneten Zone wenden, wenn die Anforderung der Delegierung schon länger zurückliegt. 9. Falsche Delegierung der untergeordneten Domäne Auch die falsche Delegierung der untergeordneten Domäne ist ein bekanntes Problem im Zusammenhang mit dem Internet. Die Aktualisierung der Delegierung erfolgt nicht ohne menschliches Zutun. Sie müssen den Administrator der übergeordneten Zone über Änderungen in Kenntnis setzen, die an den autorisierenden Namenservern vorgenommen werden. Dementsprechend können Delegierungsinformationen ungenau sein, weil Administratoren Änderungen vornehmen, ohne die übergeordneten Instanzen darüber zu informieren. Sehr viele Administratoren glauben, das Einrichten einer Delegierung sei eine einmalige Angelegenheit. Sie teilen der übergeordneten Instanz beim Einrichten der Zone mit, welche Namenserver autorisierend sind, und haben danach anscheinend nichts mehr damit zu tun. Ein Administrator kann einen neuen Namenserver hinzufügen, einen anderen außer Betrieb setzen und die IPAdresse eines dritten ändern, ohne den Administrator der übergeordneten Zone darüber in Kenntnis zu setzen. Die Anzahl der Namenserver, die von der übergeordneten Zone korrekt delegiert wurden, sinkt mit der Zeit. Dies führt im günstigsten Fall zu langen Auflösungszeiten, da abfragende Namenserver Schwierigkeiten haben, einen autorisierenden Namenserver für die Zone zu finden. Wenn die Delegierungsinformationen gar völlig veraltet sind und der letzte autorisierende Namenserverhost zwecks Wartung außer Betrieb genommen wird, kann auf die Informationen in der Zone nicht mehr zugegriffen werden. Mithilfe von nslookup können Sie überprüfen, ob die Delegierung von der übergeordneten Instanz zu Ihrer Zone, von Ihrer Zone zu einer untergeordneten Instanz oder von einer Remotezone zu einer untergeordneten Instanz fehlerhaft ist: C:\> nslookup Default Server: terminator.movie.edu Address: 192.249.249.3 > server a.gtld-servers.net. --Set server to the parent name --server you suspect has bad delegation Default Server: a.gtld-servers.net Address: 198.41.0.4 > set type=ns --Look for NS records > hp.com. --for the zone in question Server: a.gtld-servers.net Address: 198.41.0.4 Non-authoritative hp.com nameserver hp.com nameserver hp.com nameserver hp.com nameserver answer: = RELAY.HP.COM = HPLABS.HPL.HP.COM = NNSC.NSF.NET = HPSDLO.SDD.HP.COM Authoritative answers can be found from: hp.com nameserver = RELAY.HP.COM hp.com nameserver = HPLABS.HPL.HP.COM hp.com nameserver = NNSC.NSF.NET hp.com nameserver = HPSDLO.SDD.HP.COM RELAY.HP.COM internet address = 15.255.152.2 HPLABS.HPL.HP.COM internet address = 15.255.176.47 NNSC.NSF.NET internet address = 128.89.1.178 HPSDLO.SDD.HP.COM internet address = 15.255.160.64 HPSDLO.SDD.HP.COM internet address = 15.26.112.11 Angenommen, Sie halten die Delegierung zu hpsdlo.sdd.hp.com nicht für korrekt. Fragen Sie hpsdlo nach Daten für die Zone hp.com ab, und überprüfen Sie die Antwort: > server hpsdlo.sdd.hp.com. Default Server: hpsdlo.sdd.hp.com Addresses: 15.255.160.64, 15.26.112.11 > set norecurse > set type=soa > hp.com. Server: hpsdlo.sdd.hp.com Addresses: 15.255.160.64, 15.26.112.11 Non-authoritative answer: hp.com origin = relay.hp.com mail addr = hostmaster.hp.com serial = 1001462 refresh = 21600 (6 hours) retry = 3600 (1 hour) expire = 604800 (7 days) minimum ttl = 86400 (1 day) Authoritative answers can be found from: hp.com nameserver = RELAY.HP.COM hp.com nameserver = HPLABS.HPL.HP.COM hp.com nameserver = NNSC.NSF.NET RELAY.HP.COM internet address = 15.255.152.2 HPLABS.HPL.HP.COM internet address = 15.255.176.47 NNSC.NSF.NET internet address = 128.89.1.178 Wenn der Server hpsdlo tatsächlich autorisierend wäre, hätte er eine autorisierende Antwort gesendet. Der Administrator der Zone hp.com kann Ihnen mitteilen, ob hpsdlo ein autorisierender Namenserver für hp.com ist. Daher sollten Sie sich an ihn wenden. Probleme mit der Interoperabilität Bei Microsoft DNS-Servern tritt folgender Interoperabilitätsfehler im Zusammenhang mit BIND-Namenservern auf: Zonenübertragungen schlagen manchmal aufgrund des proprietären WINS-Eintrags fehl. Wenn ein Microsoft DNS-Server so konfiguriert wird, dass er bei einem WINS-Server Namen anfragt, die in einer bestimmten Zone nicht gefunden werden können, fügt er einen besonderen Eintrag in die Zonendatendatei ein. Dieser Eintrag sieht ähnlich wie der folgende aus: @ IN WINS <IP address of WINS server> Leider ist WINS kein Standardeintragstyp in der In-Klasse. Dementsprechend können untergeordnete BINDServer, die diese Zone übertragen, den WINS-Eintrag nicht verarbeiten. Sie werden das Laden der Zone daher ablehnen. Der Administrator des BIND-Servers erhält folgende Meldung im Syslog-Protokoll: May 23 15:58:43 terminator named-xfer[386]: "fx.movie.edu IN 65281" - unknown type (65281) Zur Umgehung dieses Problems sollte der Microsoft DNS-Server so konfiguriert werden, dass der proprietäre Eintrag vor dem Übertragen der Zone herausgefiltert wird. Dazu müssen Sie mit der rechten Maustaste auf die Zone im linken Fensterbereich der DNS-Konsole klicken und anschließend Eigenschaften auswählen. Klicken Sie auf der Registerkarte WINS in das sich ergebende Eigenschaftenfenster, das in Abbildung 13-5 dargestellt ist. Abbildung 13-5: Das Kontrollkästchen "Diesen Eintrag nicht replizieren" ("Do not replicate this record") Durch Aktivieren des Kontrollkästchens Diesen Eintrag nicht replizieren (Do not replicate this record) wird der WINS-Eintrag für die Zone herausgefiltert. Den untergeordneten Microsoft DNS-Servern wird der Eintrag nicht angezeigt, obwohl sie ihn verwenden können. Anzeichen für Probleme Einige Probleme sind leider nicht so leicht zu identifizieren wie die oben aufgeführten. Es ist möglich, dass Fehler auftreten, deren Ursache Sie nicht zuordnen können, denn bei vielen Problemen sind die Anzeichen gleich. Für solche Fälle werden wir einige häufige Fehlerursachen sowie Möglichkeiten zum Isolieren der Fehler aufzeigen. Nachschlagen des lokalen Namens nicht möglich Wenn Programme wie telnet oder ftp einen lokalen Namen nicht nachschlagen können, sollten Sie zunächst versuchen, denselben Namen mithilfe von nslookup nachzuschlagen. Es muss hier tatsächlich derselbe Name verwendet werden. Fügen Sie keinen Domänennamen oder nachfolgenden Punkt ein, wenn nicht auch der Benutzer diese angegeben hat. Fragen Sie keinen anderen Namenserver ab als der Benutzer. Häufig hat der Benutzer den Namen falsch eingegeben oder die Funktionsweise der Suchliste missverstanden und benötigt nur eine Anleitung. Gelegentlich treten echte Konfigurationsfehler bei den Hosts auf, wie ein Fehler in der Auflösungskonfiguration (z. B. die falsche IP-Adresse für einen Namenserver). Das Auftreten derartiger Fehler können Sie mithilfe des Befehls set all in nslookup überprüfen. Wenn nslookup eher auf ein Problem mit dem Namenserver als auf ein Problem mit der Hostkonfiguration verweist, sollten Sie die Probleme überprüfen, die im Zusammenhang mit dieser Art von Namenserver auftreten können. Wenn der Namenserver der primäre Masterserver der Zone ist, aber auf Anfrage nicht die erwarteten Daten sendet, sollten Sie folgendermaßen vorgehen: Überprüfen Sie, ob die Zonendatendatei die gewünschten Daten enthält. Stellen Sie sicher, dass die Domänennamen in den Einträgen korrekt sind (Problem 6). Wenn es sich bei dem Namenserver um einen untergeordneten Server handelt, sollten Sie zunächst überprüfen, ob der Masterserver über die korrekten Daten verfügt. Wenn dies für den Masterserver, aber nicht für den untergeordneten Server zutrifft, sollten Sie folgendermaßen vorgehen: Stellen Sie sicher, dass Sie die Seriennummer auf dem primären Server erhöht haben (Problem 1). Überprüfen Sie, ob der untergeordnete Server beim Aktualisieren der Zone ein Problem hat (Problem 4). Wenn der primäre Server nicht über die richtigen Daten verfügt, sollten Sie selbstverständlich auf dem primären Server nach der Ursache des Problems suchen. Wenn der Server mit dem Problem nicht für die die Daten enthaltene Zone autorisierend ist, sollten Sie überprüfen, ob eine Delegierung von der übergeordneten Zone zu Ihrer Zone besteht und ob diese korrekt ist (Probleme 8 und 9). Für diesen Namenserver sieht die Zone wie jede andere Remotezone aus. Auch wenn sich der Host, auf dem sie ausgeführt wird, möglicherweise innerhalb der Zone befindet, muss der Namenserver einen autorisierenden Server für Ihre Zone von den Servern der übergeordneten Zone aus finden können. Nachschlagen der Remotenamen nicht möglich Wenn Sie den lokalen Namen nachschlagen können, aber Namen außerhalb der lokalen Zone nicht, gibt es eine Reihe anderer möglicher Probleme: Können Sie den Befehl ping für den Namenserver der Remotezone erfolgreich ausführen? Vielleicht können Sie die Server der Remotezone nicht erreichen, weil die Verbindung unterbrochen wurde (Problem 7). Ist die Remotezone neu? Möglicherweise wurde die Delegierung noch nicht angezeigt (Problem 8). Vielleicht sind auch die Delegierungsinformationen für die Remotezone falsch oder veraltet, weil sie nicht aktualisiert wurden (Problem 9). Ist der Domänenname tatsächlich auf den Servern der Remotezone vorhanden? Ist er auf allen Servern der Remotezone vorhanden (Problem 1, 2 und 4)? Falsche oder inkonsistente Antwort Wenn Sie beim Nachschlagen eines lokalen Namens eine falsche oder inkonsistente Antwort erhalten, sollten Sie zunächst die Synchronisierung zwischen Ihren Namenservern überprüfen. Und zwar abhängig davon, welchen Namenserver Sie wann abfragen: Wurde auf allen Namenservern die gleiche Seriennummer für die Zone gespeichert? Haben Sie eine manuelle Änderung vorgenommen und anschließend vergessen, die Seriennummer auf dem primären Server zu erhöhen (Problem 1)? In diesem Fall ist möglicherweise auf allen Namenservern die gleiche Seriennummer gespeichert, aber sie antworten aufgrund ihrer autorisierenden Daten unterschiedlich. Haben Sie eine manuelle Änderung vorgenommen und anschließend vergessen, den primären Server neu zu starten (Problem 2)? In diesem Fall wird der primäre Server eine andere Seriennummer zurückgeben als die Seriennummer in der Zonendatendatei (beispielsweise über nslookup). Haben die untergeordneten Server Probleme beim Aktualisieren der Daten vom primären Server (Problem 4)? Wechselt das Round Robin-Feature des Namenservers die Adressen des von Ihnen nachgeschlagenen Domänennamens? Wenn Sie beim Nachschlagen eines Namens in einer Remotezone diese Ergebnisse erhalten, sollten Sie überprüfen, ob die Synchronisierung der Namenserver in der Remotezone noch besteht. Mithilfe von Tools wie nslookup können Sie beispielsweise ermitteln, ob der Administrator der Remotezone vergessen hat, die Seriennummer zu erhöhen. Wenn die Namenserver aufgrund ihrer autorisierenden Daten anders antworten, aber die gleiche Seriennummer anzeigen, wurde die Seriennummer möglicherweise nicht erhöht. Wenn die Seriennummer des primären Servers viel niedriger ist als die der untergeordneten Server, wurde die Seriennummer eventuell versehentlich zurückgesetzt. Normalerweise kann davon ausgegangen werden, dass der primäre Namenserver einer Zone auf dem im SOA-Eintrag als Quelle aufgeführten Host ausgeführt wird. Sie können aber vermutlich nicht daraus folgern, dass der primäre Server nicht neu gestartet wurde. Außerdem ist es schwierig, Probleme bei der Aktualisierung zwischen Remotenamenservern festzustellen. Wenn Sie feststellen, dass die Remotenamenserver falsche Daten ausgeben, sollten Sie sich an den Administrator der Zone wenden und ihm das Problem beschreiben. Dadurch wird dem Administrator das Nachverfolgen des Problems auf der Remoteseite erleichtert. Nachschlagevorgänge dauern sehr lange Wenn Namensauflösungen viel Zeit beanspruchen, ist dies i. d. R. auf eines der beiden folgenden Probleme zurückzuführen: Eine Unterbrechung der Netzwerkverbindung (Problem 7), die Sie mithilfe von Tools wie ping oder tracert ermitteln können. Falsche Delegierungsinformationen (Problem 9), die auf die falschen Namenserver oder die falschen IP-Adressen verweisen. Für gewöhnlich erhalten Sie Hinweise auf die Ursachen, wenn Sie einige Ping-Befehle senden. Entweder können Sie alle Namenserver erreichen oder Sie können die Hosts erreichen, aber die Namenserver antworten nicht. Manchmal helfen Ihnen die Ergebnisse allerdings nicht weiter. Es ist beispielsweise möglich, dass die übergeordneten Namenserver zu einer Reihe von Namenservern delegieren, die nicht auf Ping-Befehle oder Abfragen antworten, obwohl die Verbindung zum Remotenetzwerk zu funktionieren scheint (durch das Tools tracert erhalten Sie z. B. Zugriff zur "Türschwelle" des Remotenetzwerkes – dem letzten Router zwischen Ihnen und dem Host). Sind die Delegierungsinformationen so veraltet, dass die Namenserver bereits längst zu anderen Adressen verschoben wurden? Sind die Hosts einfach außer Betrieb? Oder besteht tatsächlich ein Problem mit dem Remotenetzwerk? Normalerweise sollten Sie sich deswegen an den Administrator der Remotezone wenden. (Die entsprechenden Telefonnummern können Sie mithilfe von whois herausfinden.) Dies waren die wichtigsten Informationen zum Thema "Problembehandlung zu DNS". Diese Liste ist sicherlich nicht vollständig, aber wir hoffen, dass sie Ihnen das Lösen häufig auftretender Probleme im Zusammenhang mit DNS erleichtert und auch beim Lösen anderer Probleme eine Hilfestellung bietet. Auch wir wären sehr froh gewesen, wenn wir auf ein Handbuch zur Problembehandlung hätten zurückgreifen können! Dieses Kapitel wurde mit freundlicher Genehmigung von O'Reilly & Associates (englischsprachig) bereitgestellt. Das Team der Microsoft Corporation hofft, dass die Informationen in diesem Dokument für Sie von Nutzen sind. Die Verwendung der in diesem Dokument enthaltenen Informationen erfolgt jedoch auf eigene Gefahr. Alle Informationen werden wie besehen bereitgestellt, ohne jede Gewährleistung, sei sie ausdrücklich oder konkludent, für die Richtigkeit, die Vollständigkeit, die Eignung für einen bestimmten Zweck, den Eigentumsvorbehalt oder die Nichtverletzung von Rechten Dritter, und keine der in diesem Dokument genannten Fremdherstellerprodukte oder Informationen von Dritten wurden/werden von der Microsoft Corporation verfasst, empfohlen oder unterstützt, und Microsoft Corporation übernimmt keine Garantie dafür. Die Microsoft Corporation kann nicht für Schäden haftbar gemacht werden, die aus der Verwendung dieser Informationen entstehen, ungeachtet dessen, ob es sich um direkte oder indirekte, spezielle, zufällig entstandene oder Folgeschäden handelt, selbst dann nicht, wenn Microsoft Corporation auf die mögliche Entstehung solcher Schäden hingewiesen wurde. Alle in diesem Dokument genannten Preise für Produkte können ohne vorherige Ankündigung geändert werden.
