Vorübergehender Fehler bei der Namensauflösung

Ich erhalte immer wieder eine Fehlermeldung, wenn etwas getan wird, das eine DNS-Suche auf meinem CentOS-Server erfordert. Z.B:

[root @ 15557 etc] # wget http://www.whitehouse.gov/sites/default/files/rss_viewer/birth-certificate-long-form.pdf
--2011-05-03 20: 55: 35-- http://www.whitehouse.gov/sites/default/files/rss_viewer/birth-certificate-long-form.pdf
Auflösung von www.whitehouse.gov ... fehlgeschlagen: Temporärer Fehler bei der Namensauflösung.
wget: Hostadresse "www.whitehouse.gov" kann nicht aufgelöst werden

Wenn ich den Server neu starte, verschwindet dieses Problem für kurze Zeit, aber es kommt immer nach einer Stunde oder so zurück. Wenn ich die in aufgelisteten Nameserver-IPs ändere resolv.conf, ist das Problem nicht behoben, auch wenn ich sie durch einen herkömmlichen Nameserver wie den von Google ersetze 8.8.8.8. Wenn ich den Hosts-Cache nach dem Ändern resolve.confentleere, wird das Problem ebenfalls nicht behoben. Nach dem Neustart des Servers wird der resolv.confauf seine Standardwerte zurückgesetzt (ich vermute, durch einige DHCP).

— Whitelines222
quelle

Verlust von ausgehenden Paketen auf Ihrem Server? Ich würde einen Paket-Sniffer starten und sehen, wie der DNS-Verkehr in diesem Fall aussieht.

— EEAA

Kannst du einen Packet Sniffer empfehlen? Ich habe noch nie eine solche Software installiert. Vielen Dank.

— Whitelines222

tcpdumpist in den meisten Distributionen über das Paket-Repository verfügbar. Ich würde jedoch empfehlen, vor dem Start ein tcpdump-Tutorial zu lesen. Sie können die Pakete auch mit tcpdump erfassen und in eine Protokolldatei schreiben. Anschließend können Sie diese Protokolldatei in einem GUI-Tool namens Wireshark öffnen, das etwas benutzerfreundlicher ist als die Verwendung der CLI.

— EEAA

tcpdump -Ani <Ihre_Schnittstelle> -s0 Port-Domain (-w my.log &)

— 3.

Antworten:

Dies kann ein Problem sein, das vom DHCP-Server verursacht wird - tatsächlich von einem Schurken oder einem anderen falsch konfigurierten DHCP-Server in Ihrem Netzwerk.

Wahrscheinlich passiert folgendes: Wenn Ihr Server hochfährt, kann er die genauen Parameter ( IP-Adresse, Gateway, DNS-Server usw. ) vom legitimen DHCP-Server abrufen. Infolgedessen treten bis zum Leasing keine Probleme auf Erneuerung. Nach relativ kurzer Zeit ( abhängig von der DHCP-Client- und Server-Konfiguration)), versucht der DHCP-Client, die Lease zu erneuern, indem er sich mit dem legitimen DHCP-Server in Verbindung setzt (über Unicast-Übertragung). Wenn dies aus irgendeinem Grund fehlschlägt oder Ihr DHCP-Client aus irgendeinem Grund keine Antwort vom legitimen DHCP-Server erhält, wird er erneut gebunden und sendet eine Anfrage zur Verlängerung der Lease-Zeit. Wenn der Schurke / ein anderer falsch konfigurierter DHCP-Server zuerst antwortet, sendet er möglicherweise ungenaue Parameter an Ihren DHCP-Client, z. B. eine "falsche" DNS-Serveradresse. Infolgedessen können Sie Hostnamen nicht auflösen.

Wenn meine Spekulationen richtig sind, kann das Problem nicht immer durch einen Neustart des Servers behoben werden , da der nicht autorisierte DHCP-Server unter Umständen zuerst antwortet und das erwähnte Problem auftritt.

Versuchen Sie in jedem Fall, statische IP-Adressen zu konfigurieren, DHCP zu deaktivieren und DNS-Server manuell einzurichten. Außerdem sollten Sie wahrscheinlich überprüfen, ob in Ihrem Netzwerk neben dem von Ihnen verwendeten weitere DHCP-Server ausgeführt werden.

— dkaragasidis
quelle

Wie finde ich heraus, ob in meinem Netzwerk ein nicht autorisierter DHCP-Server vorhanden ist? serverfault.com/questions/8526/…

— Elijah Lynn

In meinem Fall würde ich die fw-Regeln für die falsche Schnittstelle einrichten. Also war Port 53 nicht offen und der Server konnte keine DNS-Anforderung stellen

— grahamrhay
quelle