
Ich habe mich nicht verändertirgendetwasim Zusammenhang mit dem DNS-Eintrag für serverfault.com, aber einige Benutzer berichteten heute, dassDer DNS von serverfault.com kann für sie nicht aufgelöst werden.
Ich habe einJustping-Abfrageund ich kann das irgendwie bestätigen - die DNS-Auflösung von serverfault.com scheint in einigen Ländern fehlzuschlagen, ohne dass mir ein besonderer Grund dafür einfällt. (ebenfalls bestätigt überWas ist mein DNSdas auf ähnliche Weise einige weltweite Pings durchführt, sodass das Problem von zwei verschiedenen Quellen bestätigt wurde.)
Warum sollte dies passieren, wenn ich den DNS für serverfault.com nicht berührt habe?
unser Registrar ist (würg) GoDaddy, und ich verwende die DNS-Standardeinstellungen größtenteils ohne Zwischenfälle. Mache ich etwas falsch? Haben mich die DNS-Götter verlassen?
Kann ich das irgendwie beheben? Gibt es eine Möglichkeit, das DNS anzukurbeln oder zu zwingen, sich weltweit korrekt zu verbreiten?
Update: Seit Montag, 3:30 Uhr PST, sieht alles richtig aus. Die JustPing-Berichtsseite ist von allen Standorten aus erreichbar. Vielen Dank für die vielen sehr informativen Antworten, ich habe viel gelernt und werde beim nächsten Mal, wenn so etwas passiert, auf diese Frage zurückgreifen.
Antwort1
Dies ist nicht direkt ein DNS-Problem, sondern ein Netzwerkrouting-Problem zwischen einigen Teilen des Internets und den DNS-Servern für serverfault.com. Da die Nameserver nicht erreicht werden können, wird die Domain nicht mehr aufgelöst.
Soweit ich das beurteilen kann, liegt das Routing-Problem am (Global Crossing?) Router mit der IP-Adresse 204.245.39.50
.
Alsgezeigtvon@Radius, Pakete an ns52 (wie verwendet vonstackoverflow.com) Die Weiterleitung von hier nach 208.109.115.121
und von dort funktioniert einwandfrei. Pakete an ns22 gehen jedoch stattdessen an 208.109.115.201
.
Da sich diese beiden Adressen beide in derselben Adresse befinden /24
und die entsprechende BGP-Ankündigung auch für /24
diese Adresse gilt,sollte nicht passieren.
Ich habe Traceroutes über mein Netzwerk ausgeführt, das letztlich MFN Above.net statt Global Crossing verwendet, um zu GoDaddy zu gelangen, und unterhalb dieser /24
Ebene gibt es keinerlei Anzeichen für Routing-Tricks – beide Nameserver haben von hier aus identische Traceroutes.
Die einzigen Male, die ich so etwas gesehen habe, war es kaputtCisco Express-Weiterleitung(CEF). Dies ist ein Cache auf Hardwareebene, der zur Beschleunigung des Paketroutings verwendet wird. Leider kommt es gelegentlich vor, dass er nicht mehr mit der echten Routingtabelle synchronisiert ist und versucht, Pakete über die falsche Schnittstelle weiterzuleiten. CEF-Einträge können bis auf die /32
Ebene heruntergehen, selbst wenn der zugrunde liegende Routingtabelleneintrag für ein ist /24
. Es ist schwierig, diese Art von Problemen zu finden, aber wenn sie einmal identifiziert sind, sind sie normalerweise leicht zu beheben.
Ich habe GC eine E-Mail geschickt und auch versucht, mit ihnen zu sprechen, aber sie erstellen kein Ticket für Nicht-Kunden. Wenn einer von euchSindein Kunde von GC, versuchen Sie bitte, dies zu melden ...
UPDATE um 10:38 UTC Wie Jeff bemerkt hat, ist das Problem nun behoben. Traceroutes zu beiden oben genannten Servern gehen jetzt über den 208.109.115.121
nächsten Hop.
Antwort2
Ihre DNS-Server für serverfault.com [ ns21.domaincontrol.com, ns22.domaincontrol.com. ] sind seit ca. 20 Stunden nicht erreichbar, zumindest von einigen großen ISPs in Schweden aus [Telia,tele2,bredband2].
Gleichzeitig sind die „benachbarten“ DNS-Server für stackoverflow.com und superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com] erreichbar.
Beispiel-Traceroute zu ns52.domaincontrol.com:
1. xxxxxxxxxxx
2. 83.233.28.193
3. 83.233.79.81
4. 213.200.72.5
5. 64.208.110.129
6. 204.245.39.50
7. 208.109.115.121
8. 208.109.115.162
9. 208.109.113.62
10. 208.109.255.26
und zu ns21.domaincontrol.com
1. xxxxxxxxxxxx
2. 83.233.28.193
3. 83.233.79.81
4. 213.200.72.5
5. 64.208.110.129
6. 204.245.39.50
7. 208.109.115.201
8. ???
möglicherweise hat es beim Filtern gepatzt / jemand hat einen unerwünschten DDoS-Schutz ausgelöst und einige Teile des Internets auf die schwarze Liste gesetzt. Sie sollten sich wahrscheinlich an Ihren DNS-Dienstanbieter wenden – go Daddy.
Sie können überprüfen, ob das Problem [teilweise] gelöst ist, indem Sie:
- Überprüfen Sie, ob GoDaddy reagiert und die Nameserver geändert hat. Suchen Sie beispielsweise nach serverfault.com unterhttp://www.squish.net/dnscheck/verwendeter Datensatztyp: ANY
- Überprüfen Sie, ob die angegebenen Nameserver auf Ping antworten [nicht sehr wissenschaftlich, da Nameserver problemlos funktionieren und trotzdem ICMP blockieren können, aber in diesem Fall scheint ICMP für andere Server zulässig zu sein] von Telia überSpiegel.
bearbeiten: Traceroutes von Arbeitsplätzen
Polen
1. xxxxxxxxxxxxxxx
2. 153.19.40.254
3. ???
4. 153.19.254.236
5. 212.191.224.205
6. 213.248.83.129
7. 80.91.254.171
8. 80.91.249.105
80.91.251.230
80.91.254.93
80.91.251.52
9. 213.248.89.182
10. 204.245.39.50
11. 208.109.115.121
12. 208.109.115.162
13. 208.109.113.62
14. 208.109.255.26
Deutschland
1. xxxxxxxxxxxx
2. 89.149.218.181
3. 89.149.218.2
4. 134.222.105.249
5. 134.222.231.205
6. 134.222.227.146
7. 80.81.194.26
8. 64.125.24.6
9. 64.125.31.249
10. 64.125.27.165
11. 64.125.26.178
12. 64.125.26.242
13. 209.249.175.170
14. 208.109.113.58
15. 208.109.255.26
bearbeiten: jetzt funktioniert tatsächlich alles einwandfrei.
Antwort3
Meine Vorschläge: Wie von Alnitak erklärt, liegt das Problem nicht am DNS, sondern am Routing (wahrscheinlich BGP). Dass am DNS-Setup nichts geändert wurde, ist normal, da das Problem nicht am DNS lag.
Die DNS-Konfiguration von serverfault.com ist derzeit sehr schlecht, was für eine so wichtige Site sicherlich nicht ausreicht:
- nur zwei Nameserver
- alle Eier in den gleichen Korb gelegt (beide befinden sich im gleichen AS)
Wir haben gerade das Ergebnis gesehen: Ein Routing-Fehler (etwas, das im Internet recht häufig vorkommt) reicht aus, um serverfault.com für einige Benutzer verschwinden zu lassen (abhängig von ihren Betreibern, nicht von ihren Ländern).
Ich schlage vor, weitere Nameserver hinzuzufügen, die sich in anderen AS befinden. Dies würde Ausfallsicherheit bieten. Sie können sie entweder an private Unternehmen vermieten oder Serverfault-Benutzer bitten, sekundäres DNS-Hosting anzubieten (möglicherweise nur, wenn der Benutzer > 1000 Rep hat :-)
Antwort4
Es wäre praktisch, eine detaillierte Auflösungsverfolgung der fehlerhaften Standorte anzuzeigen ... um zu sehen, auf welcher Ebene des Auflösungspfads der Fehler auftritt. Ich kenne den von Ihnen verwendeten Dienst nicht, aber vielleicht ist es irgendwo eine Option.
Andernfalls liegen die Probleme höchstwahrscheinlich „weiter unten“ im Baum, da Fehler an der Wurzel oder bei TLDs (hoffentlich) mehr Domänen betreffen würden. Um die Ausfallsicherheit zu erhöhen, können Sie die Aufgabe an einen zweiten DNS-Dienst delegieren, um eine bessere Redundanz bei der Auflösung sicherzustellen, wenn es Probleme mit den Netzwerken der Domänensteuerung gibt.