Le DNS ne parvient pas à se propager dans le monde entier

Question

Le DNS ne parvient pas à se propager dans le monde entier

Demandé el 19 de Juillet, 2009: Quand la question a-t-elle été
11718 affichage: Nombre de visites la question a
5 Réponses: Nombre de réponses aux questions
Résolu: Situation réelle de la question

Je n'ai pas changé. tout ce qui est lié à l'entrée DNS de serverfault.com mais certains utilisateurs ont signalé aujourd'hui que le DNS de serverfault.com ne résout pas les problèmes pour eux. .

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

Pourquoi cela se produit-il, si je n'ai pas modifié le DNS de 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é ?
Y a-t-il quelque chose que je puisse faire pour régler ce problème ? Un moyen de faire suivre le DNS, ou de forcer le DNS à se propager correctement dans le monde entier ?

Mise à jour : à partir de lundi à 3h30 PST, tout semble correct JustPing rapporte que le site est accessible de tous les endroits. Merci pour les nombreuses réponses très instructives, j'ai beaucoup appris et je me référerai à cette Q la prochaine fois que cela se produira .

Demandé el 19 de Juillet, 2009 par Jeff Atwood

Answer 1

5 Réponses

Answer 2

92voto

Joey deVilla Points 4487

Il ne s'agit pas directement d'un problème de DNS, mais d'un problème de routage réseau entre certaines parties de l'Internet et les serveurs DNS de serverfault.com. Comme les serveurs de noms ne peuvent pas être atteints, le domaine ne se résout plus.

D'après ce que je sais, le problème de routage se situe sur le routeur (Global Crossing ?) avec l'adresse IP 204.245.39.50 .

Comme présenté sur por @radius les paquets vers ns52 (comme utilisé par stackoverflow.com ) passent d'ici à 208.109.115.121 et à partir de là, ils fonctionnent correctement. Cependant les paquets vers ns22 vont plutôt vers 208.109.115.201 .

Puisque ces deux adresses sont toutes deux dans le même /24 et l'annonce BGP correspondante est également pour une /24 ce 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 accéder à GoDaddy et il n'y a aucun signe d'un quelconque trucage de routage en dessous de l'adresse IP. /24 les deux serveurs de noms ont des traceroutes identiques à partir d'ici.

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

J'ai envoyé un e-mail à GC et j'ai également essayé de leur parler, mais ils ne veulent pas créer de ticket pour les non-clients. Si l'un d'entre vous son un client de GC, essayez de signaler ce problème...

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 serveur 208.109.115.121 saut suivant.

Répondu el 19 de Juillet, 2009 par Joey deVilla (4487 Points )

Answer 3

18voto

pQd Points 29251

Vos serveurs dns pour serverfault.com [ ns21.domaincontrol.com, ns22.domaincontrol.com. ] sont inaccessibles. depuis ~20h, au moins depuis deux isps majeurs en suède [ telia , Télé2 , 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 vers 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. ???

peut-être un filtrage défectueux / quelqu'un a déclenché une protection ddos non désirée et a mis en liste noire certaines parties d'internet. vous devriez probablement contacter votre fournisseur de service dns - allez papa.

vous pouvez vérifier si le problème est [partiellement] résolu :

vérifier si godaddy a réagi et changé les serveurs de noms - par exemple, chercher serverfault.com à l'adresse http://www.squish.net/dnscheck/ en utilisant le type de recort : N'IMPORTE QUI
vérifier si les serveurs de noms fournis répondent au ping [pas très scientifique puisque les serveurs de noms peuvent fonctionner correctement et bloquer icmp, mais dans ce cas il semble que icmp soit autorisé pour les autres serveurs] de telia via verre de regard .

modifier : traceroutes depuis les lieux de travail

polande

 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

modifier Le résultat : tout fonctionne bien maintenant.

Répondu el 19 de Juillet, 2009 par pQd (29251 Points )

Answer 4

16voto

John Hunter Points 2204

Mes suggestions : comme expliqué par Alnitak, le problème n'est pas le DNS mais le routage (probablement BGP). Le fait que rien n'ait été changé dans la configuration du DNS est normal, puisque le problème ne vient pas du DNS.

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

seulement deux serveurs de noms
tous les œufs dans le même panier (les deux sont dans la même SA)

Nous venons de voir le résultat : un problème de routage (quelque chose d'assez courant sur Internet) suffit à faire disparaître serverfault.com pour certains utilisateurs (selon leur opérateur, pas selon leur pays).

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

Répondu el 20 de Juillet, 2009 par John Hunter (2204 Points )

Answer 5

3voto

radius Points 9485

Je confirme que NS21.DOMAINCONTROL.COM et NS22.DOMAINCONTROL.COM sont également inaccessibles depuis le FAI Free.fr en France.
Comme pQd traceroute, le mien se termine aussi 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 voir, cette fois-ci, après 204.245.39.50, nous allons vers 208.109.115.121 au lieu de 208.109.115.201. Et pQd a le même traceroute. Depuis un lieu de travail, je n'ai pas croisé ce routeur 204.245.39.50 (Global Crossing).

Plus de traceroute à partir d'un endroit qui fonctionne et d'un autre qui ne fonctionne pas aiderait, mais il est très probable que Global Crossing a une fausse entrée de routage pour 208.109.255.11/32 et 216.69.185.11/32 car 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 que 208.109.115.201 (Go Daddy) annonce une route non fonctionnelle pour 208.109.255.11/32 et 216.69.185.11/32.

EDIT : Vous pouvez telnet route-server.eu.gblx.net pour vous connecter au serveur de route de Global Crossing et faire un traceroute depuis le réseau de Global Crossing.

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

Répondu el 19 de Juillet, 2009 par radius (9485 Points )

Answer 6

2voto

Ryan Sampson Points 2898

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

Dans le cas contraire, il est plus probable que les problèmes se situent "en bas" de l'arbre, car les défaillances au niveau de la racine ou des TLD affectent davantage de domaines (on peut l'espérer). Pour augmenter la résilience, vous pouvez déléguer à un second service DNS pour assurer une meilleure redondance dans la résolution en cas de problèmes avec le(s) réseau(x) de domaincontrol.

Répondu el 19 de Juillet, 2009 par Ryan Sampson (2898 Points )

Le DNS ne parvient pas à se propager dans le monde entier

Réponses

Questions en vedette

Top Tags

SistemesEz.com

Powered by:

Le DNS ne parvient pas à se propager dans le monde entier

Réponses

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

Powered by: