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 ..
la source
Réponses:
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 place208.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.la source
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:
et à ns21.domaincontrol.com
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:
edit : traceroutes des lieux de travail
Pologne
Allemagne
edit : tout fonctionne bien maintenant.
la source
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:
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 :-)
la source
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.
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).
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
la source
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.
la source
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.
la source
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).
Quand j'essaie la même chose depuis une machine sur un réseau différent (OVH), je reçois une réponse.
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.
la source