L'équipe d'ingénierie avec laquelle je travaille a été en train de déplacer des équipements d'un centre de données à un autre. Il y a dix jours, nous avons déplacé l'un de nos serveurs de noms faisant autorité pour les domaines de nos clients (ns1.faithhiway.com) et mis à jour son adresse IP avec son fournisseur DNS respectif (register.com) pour pointer vers le nouveau centre de données. Tous les tests effectués montrent que ce serveur de noms fonctionne correctement à son nouvel emplacement et lorsqu'il est interrogé, renvoyant la réponse correcte pour tous les domaines dont il est responsable.
Le problème est que bien après 72 heures, nous voyions toujours plus d'activité DNS sur son ancienne adresse IP que sur la nouvelle. La bonne nouvelle est que nous avons gardé un serveur de noms répondant pour le moment sur l'ancienne adresse IP afin que nous ne voyions aucun problème avec les domaines dont notre serveur de noms est responsable, mais l'objectif est de le retirer dès que possible. Comme vous pouvez le voir sur WhatsMyDNS.net , une quantité décente de propagation s'est produite au cours des 10 derniers jours depuis que nous avons effectué ce changement, mais il y a encore des endroits qui signalent notre IP d'origine.
Étant donné que le TTL n'est que de 3600 avec les serveurs de noms responsables de ce domaine, cela n'a aucun sens pour moi ou pour les autres ingénieurs travaillant avec moi que nous rencontrons ce problème.
Maintenant, si j'exécute une vérification DNS en utilisant l'un des serveurs DNS de Register.com (serveurs de noms directs pour foihiway.com), j'obtiens le résultat (correct) suivant:
# dig @dns01.gpn.register.com ns1.faithhiway.com A
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @dns01.gpn.register.com. ns1.faithhiway.com A
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43232
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5
;; QUESTION SECTION:
;ns1.faithhiway.com. IN A
;; ANSWER SECTION:
ns1.faithhiway.com. 3601 IN A 206.127.2.71
;; AUTHORITY SECTION:
faithhiway.com. 3600 IN NS dns01.gpn.register.com.
faithhiway.com. 3600 IN NS dns02.gpn.register.com.
faithhiway.com. 3600 IN NS dns03.gpn.register.com.
faithhiway.com. 3600 IN NS dns04.gpn.register.com.
faithhiway.com. 3600 IN NS dns05.gpn.register.com.
;; ADDITIONAL SECTION:
dns01.gpn.register.com. 3600 IN A 98.124.192.1
dns02.gpn.register.com. 3600 IN A 98.124.197.1
dns03.gpn.register.com. 3600 IN A 98.124.193.1
dns04.gpn.register.com. 3600 IN A 69.64.145.225
dns05.gpn.register.com. 3600 IN A 98.124.196.1
;; Query time: 50 msec
;; SERVER: 98.124.192.1#53(98.124.192.1)
;; WHEN: Thu Jan 27 15:16:57 2011
;; MSG SIZE rcvd: 269
À titre de référence, voici les résultats lorsque la même requête est comparée à une variété de serveurs DNS publics:
Google:
# dig @8.8.8.8 ns1.faithhiway.com A
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @8.8.8.8. ns1.faithhiway.com A
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12773
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.faithhiway.com. IN A
;; ANSWER SECTION:
ns1.faithhiway.com. 997 IN A 206.127.2.71
;; Query time: 29 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Jan 27 15:17:31 2011
;; MSG SIZE rcvd: 52
Niveau 3:
# dig @4.2.2.1 ns1.faithhiway.com A
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @4.2.2.1. ns1.faithhiway.com A
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46505
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.faithhiway.com. IN A
;; ANSWER SECTION:
ns1.faithhiway.com. 2623 IN A 206.127.2.71
;; Query time: 7 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Thu Jan 27 15:18:35 2011
;; MSG SIZE rcvd: 52
Verizon:
# dig @151.197.0.38 ns1.faithhiway.com A
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @151.197.0.38. ns1.faithhiway.com A
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32658
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.faithhiway.com. IN A
;; ANSWER SECTION:
ns1.faithhiway.com. 3601 IN A 206.127.2.71
;; Query time: 81 msec
;; SERVER: 151.197.0.38#53(151.197.0.38)
;; WHEN: Thu Jan 27 15:19:15 2011
;; MSG SIZE rcvd: 52
Cisco:
# dig @64.102.255.44 ns1.faithhiway.com A
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @64.102.255.44. ns1.faithhiway.com A
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39689
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.faithhiway.com. IN A
;; ANSWER SECTION:
ns1.faithhiway.com. 3601 IN A 206.127.2.71
;; AUTHORITY SECTION:
faithhiway.com. 3600 IN NS dns01.gpn.register.com.
faithhiway.com. 3600 IN NS dns04.gpn.register.com.
faithhiway.com. 3600 IN NS dns05.gpn.register.com.
faithhiway.com. 3600 IN NS dns02.gpn.register.com.
faithhiway.com. 3600 IN NS dns03.gpn.register.com.
;; Query time: 105 msec
;; SERVER: 64.102.255.44#53(64.102.255.44)
;; WHEN: Thu Jan 27 15:20:05 2011
;; MSG SIZE rcvd: 165
OpenDNS:
# dig @208.67.222.222 ns1.faithhiway.com A
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @208.67.222.222. ns1.faithhiway.com A
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12328
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.faithhiway.com. IN A
;; ANSWER SECTION:
ns1.faithhiway.com. 169507 IN A 207.200.19.162
;; Query time: 6 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Thu Jan 27 15:19:29 2011
;; MSG SIZE rcvd: 52
SpeakEasy:
# dig @66.93.87.2 ns1.faithhiway.com A
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @66.93.87.2. ns1.faithhiway.com A
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9342
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.faithhiway.com. IN A
;; ANSWER SECTION:
ns1.faithhiway.com. 169323 IN A 207.200.19.162
;; Query time: 69 msec
;; SERVER: 66.93.87.2#53(66.93.87.2)
;; WHEN: Thu Jan 27 15:19:51 2011
;; MSG SIZE rcvd: 52
Comme vous pouvez le voir ci-dessus, la majorité des requêtes renvoient le résultat correct. Mais quelques-uns (OpenDNS et SpeakEasy dans les exemples ci-dessus) affichent toujours l'ancienne adresse IP. Compte tenu du temps qui s'est écoulé, il me semble évident soit que nous avons fait une erreur et que nous n'avons pas traité de manière approfondie les modifications DNS de notre part (probablement) ou qu'il y a un problème avec le fournisseur DNS pour ce domaine (S'inscrire ) ou avec certains des serveurs DNS à l'état sauvage (plutôt improbable).
Un conseil sur la façon de procéder?
MISE À JOUR (31 janvier 2011):
Tout d'abord, je m'excuse pour la longueur de la question d'origine et de cette mise à jour. J'ai envisagé de supprimer une partie de l'excédent du message d'origine, mais au cas où ce problème et sa solution seraient utiles à quelqu'un d'autre à l'avenir, je vais tout laisser tel quel.
Quoi qu'il en soit, j'ai fait plus de recherches sur ce problème et j'ai découvert l'occurrence intéressante suivante. Lors de l'exécution d'une vérification sur les enregistrements de colle pour foihiway.com, résolvez toujours correctement, si je vérifie un domaine client (où ns1.faithhiway.com fait autorité), j'obtiens une réponse étrange. Il semble que les serveurs racine renvoient nsX.faithhiway.com sous leur ancienne adresse IP (sous la section supplémentaire). Étant donné que nous avons toujours un serveur répondant aux requêtes DNS, la trace se termine et renvoie les adresses IP correctes comme étape finale (encore une fois, dans la section supplémentaire). L'exemple ci-dessous utilise l'un des domaines que nous utilisons qui utilise ns1.faithhiway.com comme serveur DNS faisant autorité.
# dig +trace +nosearch +all +norecurse ignitemail.com
; <<>> DiG 9.2.4 <<>> +trace +nosearch +all +norecurse ignitemail.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46856
;; flags: qr ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 7986 IN NS a.root-servers.net.
. 7986 IN NS b.root-servers.net.
. 7986 IN NS c.root-servers.net.
. 7986 IN NS d.root-servers.net.
. 7986 IN NS e.root-servers.net.
. 7986 IN NS f.root-servers.net.
. 7986 IN NS g.root-servers.net.
. 7986 IN NS h.root-servers.net.
. 7986 IN NS i.root-servers.net.
. 7986 IN NS j.root-servers.net.
. 7986 IN NS k.root-servers.net.
. 7986 IN NS l.root-servers.net.
. 7986 IN NS m.root-servers.net.
;; Query time: 39 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jan 31 09:22:17 2011
;; MSG SIZE rcvd: 228
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16325
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14
;; QUESTION SECTION:
;ignitemail.com. IN A
;; AUTHORITY SECTION:
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 172800 IN A 192.33.14.30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 172800 IN A 192.26.92.30
d.gtld-servers.net. 172800 IN A 192.31.80.30
e.gtld-servers.net. 172800 IN A 192.12.94.30
f.gtld-servers.net. 172800 IN A 192.35.51.30
g.gtld-servers.net. 172800 IN A 192.42.93.30
h.gtld-servers.net. 172800 IN A 192.54.112.30
i.gtld-servers.net. 172800 IN A 192.43.172.30
j.gtld-servers.net. 172800 IN A 192.48.79.30
k.gtld-servers.net. 172800 IN A 192.52.178.30
l.gtld-servers.net. 172800 IN A 192.41.162.30
;; Query time: 64 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Mon Jan 31 09:22:17 2011
;; MSG SIZE rcvd: 504
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12860
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;ignitemail.com. IN A
;; AUTHORITY SECTION:
ignitemail.com. 172800 IN NS ns1.faithhiway.com.
ignitemail.com. 172800 IN NS ns2.faithhiway.com.
;; ADDITIONAL SECTION:
ns1.faithhiway.com. 172800 IN A 207.200.19.162
ns2.faithhiway.com. 172800 IN A 207.200.50.142
;; Query time: 152 msec
;; SERVER: 192.54.112.30#53(h.gtld-servers.net)
;; WHEN: Mon Jan 31 09:22:17 2011
;; MSG SIZE rcvd: 111
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43016
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;ignitemail.com. IN A
;; ANSWER SECTION:
ignitemail.com. 3600 IN A 206.127.2.64
;; AUTHORITY SECTION:
ignitemail.com. 3600 IN NS ns1.faithhiway.com.
ignitemail.com. 3600 IN NS ns2.faithhiway.com.
;; ADDITIONAL SECTION:
ns1.faithhiway.com. 3600 IN A 206.127.2.71
ns2.faithhiway.com. 3600 IN A 206.127.2.72
;; Query time: 25 msec
;; SERVER: 206.127.2.71#53(ns1.faithhiway.com)
;; WHEN: Mon Jan 31 09:22:18 2011
;; MSG SIZE rcvd: 127
Je pense vraiment que c'est un problème que nous avons quelque part dans notre configuration, mais que ce soit l'ignorance de quelque chose avec DNS de mon côté ou de celle de mon collègue ou simplement une erreur stupide que nous avons commise, je ne l'ai pas encore trouvé.
la source
Réponses:
Problème résolu. Finalement. Apparemment Register.com n'a pas mis à jour les enregistrements de colle pour ns1 et ns2.faithhiway.com malgré notre demande initiale de le faire (et leur confirmation que cela avait été fait).
Les tests que j'ai publiés ci-dessus dans ma mise à jour ont montré que malgré leur confirmation de la mise à jour, les enregistrements de colle ne se propageaient pas correctement. Je suis allé de l'avant et j'ai poussé une autre mise à jour de nos enregistrements de colle et il semble que cette fois, nous voyons la propagation:
la source
Vous avez 2 problèmes:
Les requêtes pour ns1.faithhiway.com renvoient des résultats incorrects.
Les serveurs de noms répertoriés pour votre domaine sont incorrects.
Vous testez en fait un peu en arrière. Vous testez pour quelle adresse IP est retournée lors de la requête pour ns1.faithhiway.com, mais ce que vous devez tester en premier, c'est quels serveurs de noms sont réellement retournés pour foihiway.com. Une recherche Whois et une recherche nslookup renvoient les serveurs suivants comme étant les serveurs de noms de foihiway.com:
dns01.gpn.register.com
dns02.gpn.register.com
dns03.gpn.register.com
dns04.gpn.register.com
dns05.gpn.register.com
Vous devez donc d'abord régler ce problème.
la source
De nombreux serveurs ignorent votre TTL et mettent en cache les informations beaucoup plus longtemps qu'ils ne le devraient. Le moyen le plus simple de résoudre ce problème consiste généralement à contacter les opérateurs du réseau concerné et à les en informer. Ils sont généralement très bons pour le réparer assez rapidement.
la source