1 votes

Comment savoir si une mise à jour DNS prend trop de temps ?

Je viens de transférer un domaine d'un hôte et d'un registraire à un autre. 48 heures plus tard, le site est toujours en panne. Comment puis-je savoir si je dois continuer à attendre ou s'il y a un problème ?

MISE À JOUR : nslookup dit que c'est un NXDOMAIN (inexistant ?) - qu'est-ce que cela signifie ?

MISE À JOUR 2 - RÉSOLU :

Lors du transfert, godaddy avait configuré le mauvais serveur de noms - un appel téléphonique rapide a permis de rectifier cela.

Merci pour toutes vos réponses - j'ai beaucoup appris !

0 votes

Savez-vous ce qu'est le 'Time To Live' (TTL) d'une entrée DNS ?

0 votes

Cela devrait être "changement de serveur de noms" ou "changement de registraire" - et non "mise à jour DNS".

9voto

MovEaxEsp Points 161

Il existe quelques outils que vous pouvez utiliser pour vous aider à voir si les choses sont configurées correctement. Il existe des interfaces web pour ces outils, mais je suis plus familier avec les variantes en ligne de commande, c'est pourquoi je vais les décrire ci-dessous.

Vérifiez avec whois où le domaine est actuellement hébergé

Pour obtenir les informations sur ce site, vous devez utiliser la commande "whois serverfault.com".

On obtient ainsi la réponse (élaguée par souci de concision) :

   Domain Name: SERVERFAULT.COM
   Registrar: GODADDY.COM, INC.
   Whois Server: whois.godaddy.com
   Referral URL: http://registrar.godaddy.com
   Name Server: NS21.DOMAINCONTROL.COM
   Name Server: NS22.DOMAINCONTROL.COM

Cette information montre les informations que les constructeurs du fichier de zone .com (internic) détiennent. Elle indique également que d'autres informations sont disponibles sur le serveur whois de Godaddy.

Si cette sortie n'indique pas votre nouveau registraire et vos serveurs de noms, le transfert n'est pas encore terminé et vous devez contacter votre ancien registraire.

Si votre nouveau bureau d'enregistrement apparaît mais pas les informations dns correctes, le transfert a été mal effectué et vous devez contacter votre nouveau bureau d'enregistrement.

Si les détails sont corrects mais que le site ne fonctionne pas, soit la zone de premier niveau .com n'a pas encore été mise à jour et vous devez attendre, soit les nouveaux serveurs de noms ne sont pas configurés correctement. Pour savoir lequel, utilisez la commande "dig".

Vérifiez d'abord les serveurs GTLD (qui font autorité pour les .com) :

"dig ns @a.gtld-servers.net serverfault.com"

Les résultats donnent :

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

;; ANSWER SECTION:
serverfault.com.    172800  IN  NS  ns21.domaincontrol.com.
serverfault.com.    172800  IN  NS  ns22.domaincontrol.com.

;; ADDITIONAL SECTION:
ns21.domaincontrol.com. 172800  IN  A   216.69.185.11
ns22.domaincontrol.com. 172800  IN  A   208.109.255.11

Si ces informations sont correctes, vous pouvez continuer à effectuer la même requête auprès du DNS de votre nouveau fournisseur :

"dig ns @ns21.domaincontrol.com serverfault.com"

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

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

;; Query time: 76 msec
;; SERVER: 216.69.185.11#53(216.69.185.11)
;; WHEN: Mon Jun  1 16:47:51 2009
;; MSG SIZE  rcvd: 85

Si les informations affichées sont correctes, il est probable que vous ayez un problème de mise en cache et que vous deviez attendre que les anciennes entrées détenues par les serveurs de noms en cache expirent.

0 votes

Dig ne renvoie pas de section de réponse pour le domaine !

0 votes

Laquelle des digs n'a pas de section de réponse ? a.gtld-servers.net, le serveur autoritaire de votre nouveau registraire, ou votre serveur de nom de résolution local ? Si 1, et que le whois liste votre nouveau registraire, demandez à ce dernier de vérifier. De même, si 2, contactez également votre nouveau registraire. Si la réponse est 3, il se peut que le résultat du cache soit négatif et que vous deviez attendre qu'il expire ou vider le cache du serveur ("rndc flush" sur bind).

2voto

hdanniel Points 4263

Tout d'abord, vous devez vérifier les serveurs DNS de votre domaine :

  • whois nom de domaine.com

Si les serveurs DNS sont toujours vos anciens serveurs DNS, le transfert a échoué. Si tout est ok, l'étape suivante est de vérifier les enregistrements dns dans vos nouveaux serveurs dns :

  • dig @dns.domainservers.com nom de domaine.com
  • dig @dns.domainservers.com www.domainname.com

Vous devez obtenir un résultat comme :

  • www.domainname.com. 86400 DANS UN A.B.C.D

Où A.B.C.D sera l'adresse IP du serveur où vous hébergez votre site. Si cette adresse est incorrecte, vous devez vérifier les enregistrements de votre domaine.

Enfin, vous pouvez essayer avec d'autres serveurs DNS comme opendns pour vérifier si votre domaine est mis à jour dans le monde :

  • dig @resolver1.opendns.com nom de domaine.com

Je pense que le problème se situe à l'étape 2, peut-être avez-vous oublié d'ajouter les enregistrements dans vos nouveaux serveurs DNS.

0 votes

+1 pour le guide de dépannage vérifier si l'enregistrement du domaine a été déplacé, puis vérifier le DNS où l'enregistrement pointe.

1voto

Matt Hanson Points 1929

Je vérifierais avec différents serveurs DNS. Vous pouvez utiliser un outil comme nslookup ou dig pour pointer directement sur un serveur DNS spécifique. Commencez par le serveur de la société d'hébergement, puis essayez ceux de votre travail, de votre FAI, du travail de votre ami, etc.

0voto

samy Points 4742

Je suivrais d'abord ces étapes :

  1. Interroger whois pour vérifier quels serveurs DNS doivent être utilisés pour votre domaine.

    whois nom de domaine.com

  2. Vérifiez ensuite que ces serveurs renvoient des résultats :

    dig A myhost.domainname.com @my.dnsserver.net

Faites cela pour tous les serveurs dns listés dans le whois en changeant le @dnsserver.

0voto

ZaphodB Points 643

Ce qui se passe lorsque vous transférez des domaines entre bureaux d'enregistrement dépend des règlements du TLD ou du registre. Il se peut que votre nouveau bureau d'enregistrement ne soit plus en possession des anciens enregistrements DNS et que vous souhaitiez dans ce cas les remplacer par de nouveaux. 48 heures, c'est déjà beaucoup pour être "hors internet", donc je n'hésiterais pas à contacter votre nouvel hébergeur/registrar.

suite à la réponse de Russell :

"dig soa serverfault.com @ns21.domaincontrol.com"

;; ANSWER SECTION:
serverfault.com.        86400   IN      SOA     ns21.domaincontrol.com. dns.jomax.net. 2009031400 28800 7200 604800 86400

"dig soa serverfault.com @ns22.domaincontrol.com"

;; ANSWER SECTION:
serverfault.com.        86400   IN      SOA     ns21.domaincontrol.com. dns.jomax.net. 2009031400 28800 7200 604800 86400

Le premier numéro après dns.jomax.net est le numéro de série de la zone. Il s'agit généralement d'une date à laquelle est ajouté un numéro de série correspondant au nombre de changements effectués ce jour-là, ce qui est généralement un mauvais signe si ces numéros ne sont pas synchronisés.

Vous pouvez aussi vérifier directement votre nouvel enregistrement, disons que nous avons changé récemment de www.serverfault.com :

"creuser un www.serverfault.com @ns22.domaincontrol.com +norec"

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

l'option +norec désactive le bit "récursion souhaitée" dans la question, qui est activé par défaut. Les serveurs de noms faisant autorité qui mettent également en cache peuvent vous donner des réponses provenant de leur cache si vous oubliez de spécifier +norec, ce qui peut parfois être trompeur.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X