DNS kann sich nicht weltweit verbreiten

Ich habe nichts im Zusammenhang mit dem DNS-Eintrag für serverfault.com geändert , aber einige Benutzer haben heute gemeldet, dass der DNS-Eintrag für serverfault.com für sie nicht aufgelöst werden kann .

Ich habe eine Justping-Abfrage durchgeführt und kann dies irgendwie bestätigen - serverfault.com dns scheint in einer Handvoll Ländern keine Lösung zu finden, und zwar ohne einen bestimmten Grund, den ich erkennen kann. (Wird auch über What's My DNS bestätigt, das einige weltweite Pings auf ähnliche Weise ausführt, sodass es von zwei verschiedenen Quellen als Problem bestätigt wird.)

• Warum würde das passieren, wenn ich den DNS für serverfault.com nicht berührt hätte?

• Unser Registrar ist (gag) GoDaddy, und ich verwende die Standard-DNS-Einstellungen größtenteils ohne Zwischenfälle. Mache ich etwas falsch? Haben mich die Götter des DNS verlassen?

• Kann ich irgendetwas tun, um das zu beheben? Gibt es eine Möglichkeit, das DNS mitzuschleusen oder die weltweite Verbreitung des DNS zu erzwingen?

Update: Ab Montag um 3.30 Uhr PST sieht alles korrekt 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 das nächste Mal auf dieses Q verweisen, wenn dies passiert.

Dies ist kein direktes DNS-Problem, sondern ein Netzwerk-Routing-Problem zwischen einigen Teilen des Internets und den DNS-Servern für serverfault.com. Da die Nameserver nicht erreichbar sind, wird die Domain nicht mehr aufgelöst.

Soweit ich das erkennen kann liegt das Routing-Problem am (Global Crossing?) Router mit der IP-Adresse 204.245.39.50.

Wie gezeigt durch @radius , Pakete zu ns52 (wie verwendet stackoverflow.com ) gelangen von hier 208.109.115.121und von dort richtig. Pakete an ns22 gehen jedoch stattdessen an 208.109.115.201.

Da diese beiden Adressen sind beide in der gleichen /24und die entsprechende BGP - Mitteilung ist auch für eine /24dies sollte nicht passieren .

Ich habe Traceroutes über mein Netzwerk durchgeführt, das letztendlich MFN Above.net anstelle von Global Crossing verwendet, um zu GoDaddy zu gelangen, und es gibt keine Anzeichen für Routing-Tricks unterhalb der /24Ebene - beide Nameserver haben identische Traceroutes von hier.

Das einzige Mal, dass ich so etwas gesehen habe, war Cisco Express Forwarding (CEF) defekt . Dies ist ein Cache auf Hardwareebene, der zur Beschleunigung des Paketroutings verwendet wird. Leider kommt es nur gelegentlich vor, dass es nicht mehr mit der realen Routing-Tabelle synchronisiert ist und versucht, Pakete über die falsche Schnittstelle weiterzuleiten. CEF-Einträge können auf die /32Ebene herabgesetzt werden, selbst wenn der zugrunde liegende Routing-Tabelleneintrag für a ist /24. Es ist schwierig, diese Art von Problemen zu finden, aber sobald sie identifiziert sind, lassen sie sich normalerweise leicht beheben.

Ich habe GC eine E-Mail gesendet und versucht, mit ihnen zu sprechen, aber sie erstellen kein Ticket für Nicht-Kunden. Wenn einer von euch sind ein Kunde von GC, bitte versuchen Sie es und diese zu berichten ...

UPDATE um 10:38 UTC Wie Jeff bemerkt hat, ist das Problem nun behoben. Traceroutes zu beiden oben genannten Servern gehen nun über den 208.109.115.121nächsten Hop.

Ihre DNS-Server für serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com. ] sind nicht erreichbar. für letzte ~ 20h, zumindest von den Paaren der wichtigsten ISPs in Schweden [ telia , Tele2 , bredband2 ].

Gleichzeitig sind die DNS-Server der Nachbarn für stackoverflow.com und superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com] erreichbar.

Beispiel für eine 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. ???

Vielleicht ist das Filtern durcheinander / jemand hat einen unerwünschten DDoS-Schutz ausgelöst und einige Teile des Internets auf die schwarze Liste gesetzt. wahrscheinlich solltest du deinen dns-dienstanbieter kontaktieren - go daddy.

Sie können überprüfen, ob das Problem [teilweise] gelöst ist durch:

1. Überprüfung, ob Godaddy reagiert und Nameserver geändert hat - z. B. Lookup Serverfault.com unter http://www.squish.net/dnscheck/ mit dem Recort-Typ ANY
2. überprüfen , ob bereitgestellt Nameserver auf Ping reagiert [nicht sehr wissenschaftlich , da Nameserver funktionieren kann und immer noch icmp blockieren, aber in diesem Fall scheint es , dass icmp auf andere Server erlaubt ist] von Telia über Glas suchen .

edit : 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       

edit : alles funktioniert jetzt tatsächlich einwandfrei.

Meine Vorschläge: Wie von Alnitak erklärt, ist das Problem nicht DNS, sondern Routing (wahrscheinlich BGP). Die Tatsache, dass im DNS-Setup nichts geändert wurde, ist normal, da das Problem nicht im DNS lag.

serverfault.com hat heute ein sehr schlechtes DNS-Setup, was für eine wichtige Site wie diese sicherlich nicht ausreicht:

• nur zwei Nameserver
• alle Eier im selben Korb (beide sind im selben AS)

Wir haben gerade das Ergebnis gesehen: Ein Routingfehler (etwas, das im Internet häufig vorkommt) reicht aus, damit serverfault.com für einige Benutzer verschwindet (abhängig von ihren Betreibern, nicht von ihren Ländern).

Ich empfehle, weitere Nameserver in anderen AS hinzuzufügen. Dies würde Ausfallsicherheit ermöglichen. Sie können sie entweder an private Unternehmen vermieten oder Benutzer mit Serverfehlern bitten, sekundäres DNS-Hosting anzubieten (möglicherweise nur, wenn der Benutzer mehr als 1000 Mitarbeiter hat :-)

Ich bestätige, dass NS21.DOMAINCONTROL.COM und NS22.DOMAINCONTROL.COM auch für ISP Free.fr in Frankreich nicht erreichbar sind.
Wie pQd traceroute endet auch meins nach 208.109.115.201 für ns21 und ns22.

traceroute to NS22.DOMAINCONTROL.COM (208.109.255.11), 64 hops max, 40 byte packets
 1  x.x.x.x (x.x.x.x)  2.526 ms  0.799 ms  0.798 ms
 2  78.224.126.254 (78.224.126.254)  6.313 ms  6.063 ms  6.589 ms
 3  213.228.5.254 (213.228.5.254)  6.099 ms  6.776 ms *
 4  212.27.50.170 (212.27.50.170)  6.943 ms  6.866 ms  6.842 ms
 5  212.27.50.190 (212.27.50.190)  8.308 ms  6.641 ms  6.866 ms
 6  212.27.38.226 (212.27.38.226)  68.660 ms  185.527 ms  14.123 ms
 7  204.245.39.50 (204.245.39.50)  48.544 ms  19.391 ms  19.753 ms
 8  208.109.115.201 (208.109.115.201)  19.315 ms  19.668 ms  34.110 ms
 9  * * *
10  * * *
11  * * *
12  * * *

Aber ns52.domaincontrol.com (208.109.255.26) funktioniert und befindet sich im selben Subnetz wie ns22.domaincontrol.com (208.109.255.11).

traceroute to ns52.domaincontrol.com (208.109.255.26), 64 hops max, 40 byte packets
 1  x.x.x.x (x.x.x.x)  1.229 ms  0.816 ms  0.808 ms
 2  78.224.126.254 (78.224.126.254)  12.127 ms  5.623 ms  6.068 ms
 3  * * *
 4  212.27.50.170 (212.27.50.170)  13.824 ms  6.683 ms  6.828 ms
 5  212.27.50.190 (212.27.50.190)  6.962 ms *  7.085 ms
 6  212.27.38.226 (212.27.38.226)  35.379 ms  7.105 ms  7.830 ms
 7  204.245.39.50 (204.245.39.50)  19.896 ms  19.426 ms  19.355 ms
 8  208.109.115.121 (208.109.115.121)  37.931 ms  19.665 ms  19.814 ms
 9  208.109.115.162 (208.109.115.162)  19.663 ms  19.395 ms  29.670 ms
10  208.109.113.62 (208.109.113.62)  19.398 ms  19.220 ms  19.158 ms
11  * * *
12  * * *
13  * * *

Wie Sie sehen, gehen wir dieses Mal nach 204.245.39.50 zu 208.109.115.121 anstelle von 208.109.115.201. Und pQd hat die gleiche Traceroute. Von einem Arbeitsplatz aus habe ich diesen 204.245.39.50 Router (Global Crossing) nicht gekreuzt.

Mehr Traceroute vom Arbeits- und Nichtarbeitsplatz würde helfen, aber es ist sehr wahrscheinlich, dass Global Crossing einen falschen Routing-Eintrag für 208.109.255.11/32 und 216.69.185.11/32 als 208.109.255.10, 208.109.255.12, 216.69.185.10, 216.69 hat. 185.12 funktionieren gut.

Warum es einen verzerrten Routing-Eintrag gibt, ist schwer zu wissen. Möglicherweise wirbt 208.109.115.201 (Go Daddy) für eine nicht funktionierende Route für 208.109.255.11/32 und 216.69.185.11/32.

BEARBEITEN: Sie können per Telnet route-server.eu.gblx.net eine Verbindung zum Global Crossing-Routenserver herstellen und Traceroute über das Global Crossing-Netzwerk ausführen

EDIT: Es scheint, dass das gleiche Problem bereits vor einigen Tagen bei anderen NS aufgetreten ist, siehe: http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=5277&start=0

Es wäre praktisch, eine detaillierte Auflösungsspur von den fehlgeschlagenen Stellen zu sehen. Überprüfen Sie, auf welcher Ebene des Auflösungspfads dies fehlschlägt. Ich bin mit dem von Ihnen verwendeten Dienst nicht vertraut, aber möglicherweise ist dies eine Option.

Gelingt dies nicht, sind die Probleme höchstwahrscheinlich "niedriger" in der Baumstruktur, da Fehler im Stamm oder in TLDs mehr Domänen betreffen würden (wie Sie hoffen würden). Um die Ausfallsicherheit zu erhöhen, können Sie einen zweiten DNS-Dienst delegieren, um eine bessere Redundanz bei der Auflösung sicherzustellen, wenn Probleme mit den Netzwerken von domaincontrol auftreten.

Ich bin überrascht, dass Sie nicht Ihr eigenes DNS hosten. Dies hat den Vorteil, dass der DNS und (hoffentlich) Ihre Site erreichbar sind.

Zumindest von UPC erhalte ich diese Reaktion, wenn ich versuche, Ihren A-Datensatz von Ihrem autorisierenden Server (ns21.domaincontrol.com) abzurufen.

; <<>> DiG 9.5.1-P2 <<>> @ns21.domaincontrol.com serverfault.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38663
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;serverfault.com.       IN  A

;; Query time: 23 msec
;; SERVER: 216.69.185.11#53(216.69.185.11)
;; WHEN: Sun Jul 19 12:09:40 2009
;; MSG SIZE  rcvd: 33

Wenn ich dasselbe von einem Computer in einem anderen Netzwerk (OVH) aus versuche, erhalte ich eine Antwort

; <<>> DiG 9.4.2-P2 <<>> @216.69.185.11 serverfault.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33998
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;serverfault.com.               IN      A

;; ANSWER SECTION:
serverfault.com.        3600    IN      A       69.59.196.212

;; AUTHORITY SECTION:
serverfault.com.        3600    IN      NS      ns21.domaincontrol.com.
serverfault.com.        3600    IN      NS      ns22.domaincontrol.com.

;; Query time: 83 msec
;; SERVER: 216.69.185.11#53(216.69.185.11)
;; WHEN: Sun Jul 19 12:11:05 2009
;; MSG SIZE  rcvd: 101

Bei einigen anderen Domänen tritt ein ähnliches Verhalten auf. Daher gehe ich davon aus, dass UPC (zumindest) stillschweigend DNS-Abfragen an den eigenen Cache-Nameserver umleitet und die Antworten fälscht. Wenn sich Ihr DNS kurzzeitig schlecht benommen hat, könnte dies erklären, dass die Nameserver von UPC möglicherweise die NXDOMAIN-Antwort zwischengespeichert haben.