7
DNS-Problem(?) mit www.google.de
Hallo Admin-Gemeinde,
wir haben in unserem Unternehmen seit gestern folgendes Problem:
Zuerst wurde auf einem lokalen PC festgestellt, dass die Adresse www.google.de nicht mehr zu erreichen war. Ping und tracert sind ins leere gelaufen.
Ping und tracert auf google.de haben eine Antwort geliefert.
Die Eingabe der IP in den Browser hat dazu geführt, dass man google verwenden konnte, die Eingabe von google.de / www.google.de hat eine Zeitüberschreitung hervorgerufen.
Dieses Problem ist nach einiger Zeit verschwunden, allerdings ließ es sich danach auf dem Terminalserver feststellen. Auch hier ist es nach einiger Zeit wieder verschwunden.
Auffällig ist, dass sämtliche Tracert im 3. Schritt eine Zeitüberschreitung liefern.
Statische IP-Adressen sind vergeben, das Problem tritt zwischen 10 und 12 Uhr auf.
Aus den Fehlerlogs sind keine Fehler o.ä. ersichtlich.
Bei allen anderen Websites ist dieses Problem nicht aufgetreten.
Außerdem wurde festgestellt, dass auf den DC´s festgelegte IPv6-Adressen vergeben sind(::1). Hierbei bezweifele ich allerdings, dass das die Fehlerquelle ist.
Falls ich was vergessen haben sollte, bitte ich um Nachsicht, da ich Admin in Ausbildung bin ^^
Grüße,
TlBERlUS
P.S. Verwendete Systeme sind Server 2008r2 und Windows 7
tracert google.de
(Zensur wurde aufgrund von Anordnung an Benutzername und IP in Schritt 2 vorgenommen)
Schritt 1 ist der Router und 2 die Firewall
tracert www.google.de
wir haben in unserem Unternehmen seit gestern folgendes Problem:
Zuerst wurde auf einem lokalen PC festgestellt, dass die Adresse www.google.de nicht mehr zu erreichen war. Ping und tracert sind ins leere gelaufen.
Ping und tracert auf google.de haben eine Antwort geliefert.
Die Eingabe der IP in den Browser hat dazu geführt, dass man google verwenden konnte, die Eingabe von google.de / www.google.de hat eine Zeitüberschreitung hervorgerufen.
Dieses Problem ist nach einiger Zeit verschwunden, allerdings ließ es sich danach auf dem Terminalserver feststellen. Auch hier ist es nach einiger Zeit wieder verschwunden.
Auffällig ist, dass sämtliche Tracert im 3. Schritt eine Zeitüberschreitung liefern.
Statische IP-Adressen sind vergeben, das Problem tritt zwischen 10 und 12 Uhr auf.
Aus den Fehlerlogs sind keine Fehler o.ä. ersichtlich.
Bei allen anderen Websites ist dieses Problem nicht aufgetreten.
Außerdem wurde festgestellt, dass auf den DC´s festgelegte IPv6-Adressen vergeben sind(::1). Hierbei bezweifele ich allerdings, dass das die Fehlerquelle ist.
Falls ich was vergessen haben sollte, bitte ich um Nachsicht, da ich Admin in Ausbildung bin ^^
Grüße,
TlBERlUS
P.S. Verwendete Systeme sind Server 2008r2 und Windows 7
tracert google.de
Schritt 1 ist der Router und 2 die Firewall
tracert www.google.de
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 231711
Url: https://administrator.de/contentid/231711
Printed on: April 23, 2024 at 09:04 o'clock
7 Comments
Latest comment
Hallo,
Wurde denn dort noch eine korrekte IP für dein Gugsduhier dort aufgelöst?
Und die IPs deines LAN werden vermutlich hinter einem NAT laufen - damit kennen wir deine Öffentliche(n) IP nicht und wollen es auch nicht...
zu deinem DNS Problem was töglich nur zwischen 10 und 12 stattfindet.
DNS Server?
DNS Cache?
DNS Konfiguration?
Was wird täglich zwischen 10 und 12 abgeschaltet?
.
.
.
Aufbau deines Netzes?
Konfiguration der Server und Dienste? Hier insbesondere eure DNS...
Gruß,
Peter
Wurde denn dort noch eine korrekte IP für dein Gugsduhier dort aufgelöst?
Ping und tracert auf google.de haben eine Antwort geliefert.
War es hier die gleiche IP? Oder haben die www und die ohne www unterschiedleich IPs?Auffällig ist, dass sämtliche Tracert im 3. Schritt eine Zeitüberschreitung liefern.
Was oder wer ist denn im 3.ten Schritt genannt? das ist doch von deiner Konstruktion deines Netzes abhängig an welcher Stelle was und wer nicht mehr antwortet. Nenn doch einfach ein paar Fakten statt so ein Blödsinn wie "Im 3ten Schritt".... Und die IPs deines LAN werden vermutlich hinter einem NAT laufen - damit kennen wir deine Öffentliche(n) IP nicht und wollen es auch nicht...Statische IP-Adressen sind vergeben,
Wo? Bei Google oder bei dir? Und was soll uns das sagen? kein DHCP weil ur 2 Rechner (aber mit einen TS.....)?das Problem tritt zwischen 10 und 12 Uhr auf.
Wirklich nur dann und das Täglich Mo - Frei oder auch am Samstag und / oder Sonntag?Aus den Fehlerlogs sind keine Fehler o.ä. ersichtlich.
Welche Fehlerlogs meinst du denn überhaupt?Bei allen anderen Websites ist dieses Problem nicht aufgetreten.
Weil die eben nicht google sind?Außerdem wurde festgestellt, dass auf den DC´s festgelegte IPv6-Adressen vergeben sind(::1).
Das ist deine 127.0.0.1 entsprechende IPv6.Hierbei bezweifele ich allerdings, dass das die Fehlerquelle ist.
Korrekt gezweifelt.bitte ich um Nachsicht, da ich Admin in Ausbildung bin ^^
Kein Problem. Allerdings frage ich mich was dein Ausbilder dazu sagen kann zu deinem DNS Problem was töglich nur zwischen 10 und 12 stattfindet. DNS Server?
DNS Cache?
DNS Konfiguration?
Was wird täglich zwischen 10 und 12 abgeschaltet?
.
.
.
P.S. Verwendete Systeme sind Server 2008r2 und Windows 7
Verwendete Autos sind Golf Vi und EOS Aufbau deines Netzes?
Konfiguration der Server und Dienste? Hier insbesondere eure DNS...
Gruß,
Peter
Hi,
mach doch mal nen nslookup gegen deinen DNS und mal gegen 8.8.8.8
Was kommt dabei raus?
Evtl. mal den DNS-Server (Dienst) neu starten?
Evtl. falscher DNS-Server bei dem Client eingetragen?
Wie sehen die DNS Forwarders aus?
Gruß
mach doch mal nen nslookup gegen deinen DNS und mal gegen 8.8.8.8
Was kommt dabei raus?
Evtl. mal den DNS-Server (Dienst) neu starten?
Evtl. falscher DNS-Server bei dem Client eingetragen?
Wie sehen die DNS Forwarders aus?
Gruß
Spannend
Was liefern nslookup auf google.de zu diesem zeitpunkt und bringt ein ipconfig /flushdns etwas? Zur probe mal nen Google-DNS (8.8.8.8) als einzigen DNS auf nem Client mit Problemen eingetragen und getestet?
Was liefern nslookup auf google.de zu diesem zeitpunkt und bringt ein ipconfig /flushdns etwas? Zur probe mal nen Google-DNS (8.8.8.8) als einzigen DNS auf nem Client mit Problemen eingetragen und getestet?
-Mit "ins leere laufen" war gemeint, dass eine Zeitüberschreitung der Anforderung stattfindet-> also keine IP-Adresse aufgelöst wurde.
Ping auf IP und google.de haben dieselbe IP zurückgegeben. Ping auf www.google.de(erst möglich gewesen, nachdem google wieder erreichbar war) hat eine andere Ip herausgegeben.
-Der genannte "3.Schritt" ist unidentifizierbar(für mich), da er nicht mehr in unserem Netzwerk liegt, und da er nicht antwortet(Zeitüberschreitung). Dieser Fehler tritt allerdings auch zu jedem anderen Zeitpunkt, auf jede Adresse zu.
Screenshots habe ich in der Frage eingefügt.
- Statische IP-Adressen sind auf Clients und Server eingestellt - DHCP ist vorhanden
> Wo? Bei Google oder bei dir? Und was soll uns das sagen? kein DHCP weil ur 2 Rechner (aber mit einen TS.....)?
-> nein es sind mehr Clients, aber da ich mir das Problem nicht erklären konnte, dachte ich mir, dass diese Information nicht schaden könnte.
> Wirklich nur dann und das Täglich Mo - Frei oder auch am Samstag und / oder Sonntag?
->Da das Problem erst seit gestern auftritt, kann ich hierzu nicht viel sagen.
- Mit Fehlerlogs meinte ich DNS und Firewall
- Der Punkt mit ::1 (schon klar, dass das Äquivalent zu 127.0.0.1 ist) war darauf bezogen, dass in meinen bisherigen Erfahrungen eine feste IPv6-Adresse zu DNS-Fehlern geführt hat.
- In der genannten Uhrzeit wird normalerweise nichts abgeschaltet(bzw. von User-Seite wurde hierbei nichts gemeldet)
- Der DNS-Bereich ist 192.168.1.xxx, Reverse-Lookup-Zone ist eingerichtet-> eine Weiterleitung ist an die interne Adresse der Firewall
- Ping und tracert an 8.8.8.8 funktionieren ohne Probleme
- ipconfig /flushdns(sry, hab ich vergessen zu erwähnen) haben keine Änderung hervorgerufen
- Die IP-Adresse des DNS ist korrekt eingetragen
- 8.8.8.8 als neuen DNS kann ich vermutlich erst morgen ausprobieren-.-
Falls die Beschreibung der DNS-Konfig unzureichend ist(vermutlich) bitte ich um Stichpunkte was ich beschreiben soll.
Grüße,
TlBERlUS
Ping auf IP und google.de haben dieselbe IP zurückgegeben. Ping auf www.google.de(erst möglich gewesen, nachdem google wieder erreichbar war) hat eine andere Ip herausgegeben.
-Der genannte "3.Schritt" ist unidentifizierbar(für mich), da er nicht mehr in unserem Netzwerk liegt, und da er nicht antwortet(Zeitüberschreitung). Dieser Fehler tritt allerdings auch zu jedem anderen Zeitpunkt, auf jede Adresse zu.
Screenshots habe ich in der Frage eingefügt.
- Statische IP-Adressen sind auf Clients und Server eingestellt - DHCP ist vorhanden
> Wo? Bei Google oder bei dir? Und was soll uns das sagen? kein DHCP weil ur 2 Rechner (aber mit einen TS.....)?
-> nein es sind mehr Clients, aber da ich mir das Problem nicht erklären konnte, dachte ich mir, dass diese Information nicht schaden könnte.
> Wirklich nur dann und das Täglich Mo - Frei oder auch am Samstag und / oder Sonntag?
->Da das Problem erst seit gestern auftritt, kann ich hierzu nicht viel sagen.
- Mit Fehlerlogs meinte ich DNS und Firewall
- Der Punkt mit ::1 (schon klar, dass das Äquivalent zu 127.0.0.1 ist) war darauf bezogen, dass in meinen bisherigen Erfahrungen eine feste IPv6-Adresse zu DNS-Fehlern geführt hat.
- In der genannten Uhrzeit wird normalerweise nichts abgeschaltet(bzw. von User-Seite wurde hierbei nichts gemeldet)
- Der DNS-Bereich ist 192.168.1.xxx, Reverse-Lookup-Zone ist eingerichtet-> eine Weiterleitung ist an die interne Adresse der Firewall
- Ping und tracert an 8.8.8.8 funktionieren ohne Probleme
- ipconfig /flushdns(sry, hab ich vergessen zu erwähnen) haben keine Änderung hervorgerufen
- Die IP-Adresse des DNS ist korrekt eingetragen
- 8.8.8.8 als neuen DNS kann ich vermutlich erst morgen ausprobieren-.-
Falls die Beschreibung der DNS-Konfig unzureichend ist(vermutlich) bitte ich um Stichpunkte was ich beschreiben soll.
Grüße,
TlBERlUS
Edit: Auf der Firewall sind 8.8.8.8 und 8.8.4.4 als DNS eingetragen.
Hallo,
Und ein DNS Server muss nicht zwingend im gleichen IP bereich zu finden sein. Dafür gibt es Router oder deren per Software genutzten Funktionen. Und klar, im AD ist ein DNS im gleichen IP bereich schon eine erhebliche erleichterung, aber kein zwingender Muss. Der DC muss halt nur den DNS jederueit erreichen können...
Bei euch hat der von euch verwendete DNS Server halt gehustet, mehr nicht. Ob da ein AD dranhängt oder nur ein Workgroup und eine Produktion mit xyz Maschinen.... wir wissen es nicht.
Ich hab meine Firewall Gün angestrichen, geholfen hats aber am Ro(u)ten auch nichts....
Gruß,
Peter
Zitat von @TlBERlUS:
-Mit "ins leere laufen" war gemeint, dass eine Zeitüberschreitung der Anforderung stattfindet
Dann schreib es auch so.-Mit "ins leere laufen" war gemeint, dass eine Zeitüberschreitung der Anforderung stattfindet
also keine IP-Adresse aufgelöst wurde.
Joa. Das kann schoa sein. Und dafür kann es gewollte und ungewollte gründe geben.Ping auf IP und google.de haben dieselbe IP zurückgegeben.
Sag nicht das dies dich wundert wenn beide gleich sinderst möglich gewesen, nachdem google wieder erreichbar war
Du meinst das ein Gerät mit der zugehörigen IP von www.google de welcher dir zu diesem zeitpunkt zurückgegeben wurde hat auf ein ICMP geantwortet. Google wie auch viele andere haben nicht nur eine IP zu ihren namen wie z.B. www.google.dehat eine andere Ip herausgegeben.
Wie deine jetzt gezeigte Bilder aucg klar zeigen. Tracert und Ping auf unterschiedle IPs losgelassen kann natürckich jeweils andere ergebnisse liefern. Auch diese Seite antwortet nicht auf ein Pingnicht antwortet(Zeitüberschreitung). Dieser Fehler
Wer sagt das dies ein Fehler darstellt? Kann es nicht sein das es eine bewusste Konfiguration dort ist? aber da ich mir das Problem nicht erklären konnte, dachte ich mir,
Du solltest damit gar nicht erst anfangen. Ich dachte daher weil und doch nicht. In der IT ist es Strom oder kein Strom daziwschen gibt es nichts. Nennt sich Dickestal. Und solange du weder Strom oder kein Strom hast, hast du höchstens Vermutung, also nichts. Und mit ohne Strom = nichts geht man dann logisch vor, von einem Punkt zum nächsten um die Vermutung in Wissen zu wandeln. Dann zum nächsten Punkt mit den nun vorhanden Wissen usw...Information nicht schaden könnte.
Sei froh das dir nicht Irgendein Arzt mit deiner Methode dir irgendwas für irgendetwas spritzt um irgendeine Reaktion sehen ohne zu Wissen was er erwartet Kann ja nicht Schaden). Wir in der IT Operieren zwar auch am offenen Herzen, nur das wir einen Reset Button habenDa das Problem erst seit gestern auftritt, kann ich hierzu nicht viel sagen.
Also den Lauten gemacht für einmaliges Ausfallen von entweder eurem DNS oder der von eurem ISP oder der welchen ihr als DNS nutzt. - Mit Fehlerlogs meinte ich DNS und Firewall
DNS liefert eine IP zu einer Adresse oder nicht. Selbst eine nicht gelieferte IP ist hier kein Fehler. Ist sogar so gewollt. Also könnte dir nur der DNS sagen das er eben nicht läuft oder Fehlkonfiguriert ist....wobei da die ergebnisse der Namensauflösung schon erkennen lassen ob fehlkonfigurationen vorliegen...Erfahrungen eine feste IPv6-Adresse zu DNS-Fehlern geführt hat.
Wie kommst du auf dieses? keine Ahnung von IPv6 oder absolut fehelerhafte Konfiguration in euren Netz?- Der DNS-Bereich ist 192.168.1.xxx
?!? Du meinst der IP bereich eures Netzes, oder?Und ein DNS Server muss nicht zwingend im gleichen IP bereich zu finden sein. Dafür gibt es Router oder deren per Software genutzten Funktionen. Und klar, im AD ist ein DNS im gleichen IP bereich schon eine erhebliche erleichterung, aber kein zwingender Muss. Der DC muss halt nur den DNS jederueit erreichen können...
Reverse-Lookup-Zone ist eingerichtet-> eine Weiterleitung ist an die interne Adresse der Firewall
Wovon redest du hier? Du bist sicher das du keine Ausbildung zum Schweißer machst? Die IP-Adresse des DNS ist korrekt eingetragen
Sicher? weil dein8.8.8.8 als neuen DNS kann ich vermutlich erst morgen ausprobieren-.-
lässt und böses Ahnen (Das nennt sich vorhersehen was passiert wenn an entscheidender Stellen etwas geändert wird). Entweder habt ihr kein AD (dann ist alles gut) oder du schiesst es damit ab (dann ist alles schlecht)Falls die Beschreibung der DNS-Konfig unzureichend ist(vermutlich) bitte ich um Stichpunkte was ich beschreiben soll.
DNS lVersion von Hersteller X läuft auf OSy in Version z auf Blech von g oder in einer VM von . AD hat x Standorte, rr weiter DNS Server usw. usw. usw.Bei euch hat der von euch verwendete DNS Server halt gehustet, mehr nicht. Ob da ein AD dranhängt oder nur ein Workgroup und eine Produktion mit xyz Maschinen.... wir wissen es nicht.
Edit: Auf der Firewall sind 8.8.8.8 und 8.8.4.4 als DNS eingetragen.
Und? Was willst du damit bezwecken? Sollen die gesperrt werden oder bervorzugt behandelt oder was? Und warum nicht die DNs eures ISP? Was ist euer DNS Konzept und warum muss da so sein?Ich hab meine Firewall Gün angestrichen, geholfen hats aber am Ro(u)ten auch nichts....
Gruß,
Peter
Um es zusammenzufassen:
Da in beiden Fällen google.de zu einer IP aufgelöst wurde, ist es mit hoher Wahrscheinlichkeit kein DNS-Problem.
Da der Traceroute sofort nach deinem ersten lokalen Router endet liegt das Problem irgendwo zwischen Hop 1 und Hop 2.
Ich lehne mich jetzt mal ganz weit aus dem Fenster und behaupte, dass auf einem dieser beiden Router eine Firewallregel oder Blackhole-Route für die 173.194.69.0/24 angelegt wurde. Kann man leicht testen, indem man versucht, benachbarte IPs per Traceroute zu erreichen
NACHTRAG:
Da der dritte Hop auch nicht antwortet sieht das ein wenig nach "Filter gone wild" aus...
Da in beiden Fällen google.de zu einer IP aufgelöst wurde, ist es mit hoher Wahrscheinlichkeit kein DNS-Problem.
Da der Traceroute sofort nach deinem ersten lokalen Router endet liegt das Problem irgendwo zwischen Hop 1 und Hop 2.
Ich lehne mich jetzt mal ganz weit aus dem Fenster und behaupte, dass auf einem dieser beiden Router eine Firewallregel oder Blackhole-Route für die 173.194.69.0/24 angelegt wurde. Kann man leicht testen, indem man versucht, benachbarte IPs per Traceroute zu erreichen
NACHTRAG:
Da der dritte Hop auch nicht antwortet sieht das ein wenig nach "Filter gone wild" aus...
