DNS ne parvient pas à se propager dans le monde entier

Je n'ai rien changé en ce qui concerne l'entrée DNS pour serverfault.com , mais certains utilisateurs signalaient aujourd'hui que le DNS de serverfault.com ne pouvait pas être résolu .

J'ai couru une requête justping et je peux en quelque sorte confirmer ceci - le DNS de serverfault.com semble ne pas pouvoir résoudre dans une poignée de pays, sans aucune raison particulière que je puisse discerner. (également confirmé via What's My DNS, qui effectue des pings dans le monde entier de manière similaire; le problème est donc confirmé par deux sources différentes.)

• Pourquoi cela se produirait-il si je n'ai pas touché le DNS pour serverfault.com?

• notre registraire est (gag) GoDaddy, et j'utilise les paramètres DNS par défaut pour la plupart sans incident. Est-ce que je fais quelque chose de mal? Les dieux du DNS m'ont-ils abandonné?

• est-ce que je peux faire quelque chose pour résoudre ce problème? Y a-t-il un moyen de contourner le DNS ou de le forcer à se propager correctement dans le monde entier?

Mise à jour: dès lundi à 3 h 30, heure avancée du Pacifique, tout semble correct. Le site de rapports JustPing est accessible de tous les endroits. Merci pour les nombreuses réponses très informatives, j'ai beaucoup appris et je me référerai à ce Q la prochaine fois que cela se produit ..

Ce n'est pas directement un problème de DNS, mais un problème de routage réseau entre certaines parties d'Internet et les serveurs DNS de serverfault.com. Étant donné que les serveurs de noms ne peuvent pas être atteints, la résolution du domaine est arrêtée.

Autant que je sache, le problème de routage se situe sur le routeur (Global Crossing?) Avec adresse IP 204.245.39.50.

Comme indiqué par @radius , les paquets vers ns52 (utilisés par stackoverflow.com ) passent d’ici vers 208.109.115.121et de là fonctionnent correctement. Cependant, les paquets vers ns22 vont à la place 208.109.115.201.

Étant donné que ces deux adresses sont identiques /24et que l'annonce BGP correspondante est également valable, /24cela ne devrait pas se produire .

J'ai effectué des traceroutes via mon réseau, qui utilise finalement MFN Above.net au lieu de Global Crossing pour atteindre GoDaddy. Aucune astuce de routage inférieure au /24niveau - les deux serveurs de noms ont des traceroutes identiques à partir d'ici.

Les seules fois où j'ai jamais vu quelque chose comme ça, c'était Cisco Express Forwarding (CEF) cassé . Il s'agit d'un cache de niveau matériel utilisé pour accélérer le routage des paquets. Malheureusement, il arrive que de temps en temps il ne soit plus synchronisé avec la vraie table de routage et tente de transférer des paquets via une mauvaise interface. Les entrées CEF peuvent descendre jusqu'au /32niveau même si l'entrée de la table de routage sous-jacente est pour a /24. Il est difficile de trouver ce genre de problèmes, mais une fois identifiés, ils sont normalement faciles à résoudre.

J'ai envoyé un e-mail à GC et j'ai également essayé de leur parler, mais ils ne créeront pas de ticket pour les non-clients. Si certains d'entre vous sont des clients de GC, veuillez essayer de signaler ceci ...

MISE À JOUR À 10:38 UTC Comme Jeff l’a noté, le problème est maintenant résolu. Les traceroutes vers les deux serveurs mentionnés ci-dessus passent maintenant par le 208.109.115.121saut suivant.

vos serveurs DNS pour serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com. ] sont inaccessibles. depuis environ 20h, au moins parmi quelques isps majeurs en suède [ telia , tele2 , bredband2 ].

en même temps, les serveurs DNS 'voisins' pour stackoverflow.com et superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com] sont accessibles.

exemple de traceroute vers 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          

et à 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. ???

filtrage peut-être foutu / quelqu'un a déclenché une protection contre les DDOS non désirés et a mis sur liste noire certaines parties d'Internet. probablement vous devriez contacter votre fournisseur de service de DNS - allez papa.

vous pouvez vérifier si le problème est résolu en partie par:

1. vérifier si godaddy a réagi et changé de serveur de noms - par exemple, lookup serverfault.com à l' adresse http://www.squish.net/dnscheck/ en utilisant le type de recort: ANY
2. vérifie si les serveurs de noms fournis répondent au ping [pas très scientifique, car les serveurs de noms peuvent fonctionner correctement tout en bloquant icmp, mais dans ce cas, il semble que icmp soit autorisé sur d'autres serveurs] de telia via Looking Glass .

edit : traceroutes des lieux de travail

Pologne

 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              

Allemagne

 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 : tout fonctionne bien maintenant.

Mes suggestions: comme l'explique Alnitak, le problème n'est pas le DNS mais le routage (probablement BGP). Le fait que rien n'ait été modifié dans la configuration DNS est normal, car le problème n'était pas dans le DNS.

serverfault.com a aujourd'hui une configuration DNS très mauvaise, certainement insuffisante pour un site aussi important que celui-ci:

• seulement deux serveurs de noms
• tous les oeufs dans le même panier (les deux sont dans le même AS)

Nous venons de voir le résultat: un problème de routage (quelque chose qui est assez courant sur Internet) est suffisant pour faire que serverfault.com disparaisse pour certains utilisateurs (en fonction de leurs opérateurs, pas de leurs pays).

Je suggère d'ajouter plus de serveurs de noms, situés dans d'autres AS. Cela permettrait une résilience aux échecs. Vous pouvez soit les louer à des sociétés privées, soit demander aux utilisateurs de serverfault de proposer un hébergement DNS secondaire (éventuellement uniquement si l'utilisateur a> 1000 représentants :-)

Je confirme que NS21.DOMAINCONTROL.COM et NS22.DOMAINCONTROL.COM sont également inaccessibles depuis ISP Free.fr en France.
Comme pQd traceroute, le mien se termine également après 208.109.115.201 pour ns21 et 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  * * *

Mais ns52.domaincontrol.com (208.109.255.26) fonctionne et se trouve dans le même sous-réseau que 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  * * *

Comme vous pouvez le constater, cette fois après 204.245.39.50, nous passons à 208.109.115.121 au lieu de 208.109.115.201. Et pQd a le même traceroute. D'un lieu de travail, je n'ai pas traversé ce routeur 204.245.39.50 (Global Crossing).

Il serait fort probable que Global Crossing ait une entrée de routage fictive pour 208.109.255.11/32 et 216.69.185.11/32 comme 208.109.255.10, 208.109.255.12, 216.69.185.10, 216.69. 185.12 fonctionnent bien.

Il est difficile de savoir pourquoi il a une entrée de routage embourbée. Probablement 208.109.115.201 (Go Daddy) annonce un itinéraire inutilisable pour 208.109.255.11/32 et 216.69.185.11/32.

EDIT: vous pouvez utiliser telnet route-server.eu.gblx.net pour vous connecter au serveur de routage Global Crossing et traceroute à partir du réseau Global Crossing

EDIT: Il semble que le même problème se soit déjà produit chez d’autres NS il ya quelques jours, voir: http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=5277&start=0

Ce qui serait pratique serait de voir une trace de résolution détaillée à partir des emplacements qui échouent ... voir sur quelle couche du chemin de résolution il échoue. Je ne connais pas bien le service que vous utilisez, mais c'est peut-être une option quelque part.

À défaut, il est fort probable que les problèmes se situent «plus bas» dans l’arborescence, car des défaillances à la racine ou des TLD affecteraient plus de domaines (vous espérez bien). Pour augmenter la résilience, vous pouvez déléguer à un deuxième service DNS pour assurer une meilleure redondance de résolution en cas de problèmes avec le ou les réseaux de domaincontrol.

Je suis surpris que vous n'hébergez pas votre propre DNS. L'avantage de procéder de cette façon, c'est que si le DNS est accessible, il en va de même (espérons-le) de votre site.

Au moins chez UPC, je reçois cette réaction lorsque j'essaie de récupérer votre enregistrement A auprès de votre serveur principal (ns21.domaincontrol.com).

; <<>> 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

Quand j'essaie la même chose depuis une machine sur un réseau différent (OVH), je reçois une réponse.

; <<>> 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

J'obtiens un comportement similaire pour quelques autres domaines, donc je suppose que UPC (au moins) redirige en silence les requêtes DNS vers leur propre serveur de noms de mise en cache et imite les réponses. Si votre DNS s'était mal comporté brièvement, cela pourrait s'expliquer par le fait que les serveurs de noms d'UPC pourraient mettre en cache la réponse NXDOMAIN.