Das Engineering-Team, mit dem ich zusammenarbeite, war dabei, Geräte von einem Rechenzentrum in ein anderes zu verschieben. Vor zehn Tagen haben wir einen unserer Nameserver, der für die Domains unserer Kunden autorisiert ist (ns1.faithhiway.com), verschoben und die IP-Adresse mit dem entsprechenden DNS-Anbieter (register.com) aktualisiert, um auf das neue Rechenzentrum zu verweisen. Alle durchgeführten Tests haben ergeben, dass dieser Nameserver an seinem neuen Standort ordnungsgemäß ausgeführt wird und bei einer Abfrage die richtige Antwort für alle Domänen zurückgibt, für die er verantwortlich ist.
Das Problem ist, dass wir nach 72 Stunden immer noch mehr DNS-Aktivität an der alten IP-Adresse als an der neuen sehen. Die gute Nachricht ist, dass wir vorerst einen Nameserver haben, der auf die alte IP-Adresse reagiert, damit wir keine Probleme mit den Domains sehen, für die unser Nameserver verantwortlich ist, aber das Ziel ist, diese so schnell wie möglich zu löschen. Wie Sie auf WhatsMyDNS.net sehen können , ist in den letzten 10 Tagen seit dieser Änderung eine anständige Verbreitung eingetreten, aber es gibt immer noch einige Standorte, die unsere ursprüngliche IP- Adresse melden.
In Anbetracht der Tatsache, dass die TTL nur 3600 mit den für diese Domäne verantwortlichen Nameservern ist, ergibt es für mich und die anderen mit mir zusammenarbeitenden Ingenieure keinen Sinn, dass dieses Problem vorliegt.
Wenn ich jetzt eine DNS-Überprüfung mit einem der DNS-Server von Register.com (direkte Nameserver für faithhiway.com) durchführe, erhalte ich das folgende (korrekte) Ergebnis:
# 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
Nur als Referenz, hier sind die Ergebnisse, wenn dieselbe Abfrage mit einer Vielzahl von öffentlichen DNS-Servern verglichen wird:
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
Stufe 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
Wie Sie oben sehen können, liefern die meisten Abfragen das richtige Ergebnis. Einige (OpenDNS und SpeakEasy in den obigen Beispielen) zeigen jedoch immer noch die alte IP-Adresse an. In Anbetracht der Zeit, die vergangen ist, scheint es mir offensichtlich, dass wir entweder einen Fehler gemacht haben und die DNS-Änderungen auf unserer Seite nicht gründlich behandelt haben (wahrscheinlich) oder dass ein Problem mit dem DNS-Anbieter für diese Domain (Registrieren) vorliegt ) oder mit einigen der DNS-Server in freier Wildbahn (eher unwahrscheinlich).
Irgendwelche Ratschläge, wie ich damit umgehen kann?
UPDATE (31. Januar 2011):
Zunächst entschuldige ich mich für die Länge der ursprünglichen Frage und dieses Updates. Ich überlegte, einen Teil des Überschusses aus dem ursprünglichen Beitrag zu entfernen, aber für den Fall, dass dieses Problem und seine Lösung in Zukunft für andere hilfreich sind, werde ich einfach alles so lassen, wie es ist.
Wie auch immer, ich habe dieses Problem genauer untersucht und das folgende interessante Ereignis entdeckt. Wenn ich eine Überprüfung der Leimdatensätze für faithhiway.com durchführe und dabei eine Client-Domain überprüfe (wobei ns1.faithhiway.com maßgeblich ist), erhalte ich eine seltsame Antwort. Es sieht so aus, als würden die Root-Server nsX.faithhiway.com als ihre alten IP-Adressen zurückgeben (unter "Zusätzlicher Abschnitt"). Da immer noch ein Server auf DNS-Abfragen antwortet, wird der Trace beendet und gibt als letzten Schritt die richtigen IP-Adressen zurück (erneut unter Zusätzlicher Abschnitt). Im folgenden Beispiel wird eine der von uns verwendeten Domänen verwendet, die ns1.faithhiway.com als autorisierenden DNS-Server verwendet.
# 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
Ich denke wirklich, dass dies ein Problem ist, das wir irgendwo in unserem Setup haben, aber ob es Unkenntnis von etwas mit DNS auf der Seite meines oder meines Kollegen oder nur ein blöder Fehler ist, den wir gemacht haben, muss ich noch finden.
quelle
Antworten:
Problem gelöst. Endlich. Anscheinend hat Register.com die Leimdatensätze für ns1 und ns2.faithhiway.com trotz unserer anfänglichen Aufforderung (und der Bestätigung, dass dies geschehen ist) nicht aktualisiert.
Die Tests, die ich oben in meinem Update gepostet habe, haben gezeigt, dass die Leimdatensätze trotz Bestätigung des Updates nicht korrekt übertragen wurden. Ich habe ein weiteres Update für unsere Leimaufzeichnungen veröffentlicht und es sieht so aus, als ob diesmal eine Ausbreitung zu beobachten ist:
quelle
Sie haben 2 Probleme:
Die Abfragen für ns1.faithhiway.com liefern falsche Ergebnisse.
Die für Ihre Domain aufgelisteten Nameserver sind falsch.
Sie testen tatsächlich ein wenig rückwärts. Sie testen, welche IP-Adresse zurückgegeben wird, wenn Sie nach ns1.faithhiway.com fragen. Zunächst sollten Sie jedoch überprüfen, welche Nameserver tatsächlich für faithhiway.com zurückgegeben werden. Ein Whois-Lookup und ein nslookup geben die folgenden Server als Nameserver für faithhiway.com zurück:
dns01.gpn.register.com
dns02.gpn.register.com
dns03.gpn.register.com
dns04.gpn.register.com
dns05.gpn.register.com
Also müssen Sie das zuerst reparieren.
quelle
Viele Server ignorieren Ihre TTL und speichern die Informationen viel länger im Cache, als sie sollten. Der einfachste Weg, dies zu lösen, ist in der Regel, die betroffenen Netzbetreiber zu kontaktieren und sie zu informieren. Sie sind normalerweise sehr gut darin, das Problem schnell zu beheben.
quelle