Probleme mit der DNS-Weitergabe 10 Tage nach einer Änderung


25

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.

Bildbeschreibung hier eingeben

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.


3
Ich wünschte, mehr Fragen wären so gut gestellt worden, Sie hätten meine Zustimmung zur Qualität
Jeff Atwood

Antworten:


5

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:

# 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: 12706
;; flags: qr ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.              IN  NS

;; ANSWER SECTION:
.           79883   IN  NS  a.root-servers.net.
.           79883   IN  NS  b.root-servers.net.
.           79883   IN  NS  c.root-servers.net.
.           79883   IN  NS  d.root-servers.net.
.           79883   IN  NS  e.root-servers.net.
.           79883   IN  NS  f.root-servers.net.
.           79883   IN  NS  g.root-servers.net.
.           79883   IN  NS  h.root-servers.net.
.           79883   IN  NS  i.root-servers.net.
.           79883   IN  NS  j.root-servers.net.
.           79883   IN  NS  k.root-servers.net.
.           79883   IN  NS  l.root-servers.net.
.           79883   IN  NS  m.root-servers.net.

;; Query time: 293 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jan 31 13:24:02 2011
;; MSG SIZE  rcvd: 228

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43910
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14

;; QUESTION SECTION:
;ignitemail.com.            IN  A

;; AUTHORITY SECTION:
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  h.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: 336 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Mon Jan 31 13:24:03 2011
;; MSG SIZE  rcvd: 504

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44133
;; 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   206.127.2.71
ns2.faithhiway.com. 172800  IN  A   206.127.2.72

;; Query time: 2411 msec
;; SERVER: 192.43.172.30#53(i.gtld-servers.net)
;; WHEN: Mon Jan 31 13:24:06 2011
;; MSG SIZE  rcvd: 111

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50833
;; 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: 1495 msec
;; SERVER: 206.127.2.71#53(ns1.faithhiway.com)
;; WHEN: Mon Jan 31 13:24:09 2011
;; MSG SIZE  rcvd: 127

4

Sie haben 2 Probleme:

  1. Die Abfragen für ns1.faithhiway.com liefern falsche Ergebnisse.

  2. 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.


first - ns1 und ns2 sind Nameserver und nicht für sich selbst maßgebend. Registrieren Sie den DNS-Server unseres NS-Servers, während alle anderen Benutzer ihre DNS-Einträge auf uns verweisen, um eine verbindliche Antwort zu erhalten Ich habe die NS-Einträge für faithhiway.com auf allen oben genannten Servern nachgeschlagen und sie lösen auch die Registrierung als maßgebliche Nameserver der Domain auf.
Grufftech

Ich habe das Problem dann falsch verstanden. Die Nameserver für faithhiway.com sind nicht nsX.faithhiway.com. nsX.faithhiway.com sind die Nameserver für DNS-Zonen, die Sie für Ihre Kunden hosten. Ist das richtig? Wenn ja, entschuldige ich mich für das Missverständnis.
Joeqwerty

Das ist richtig - Register.com ist maßgeblich für faithhiway.com und nsX.faithhiway.com sind die verantwortlichen Nameserver für unsere Kunden.
Runlevelsix

(Für mein eigenes Verständnis) Wäre es nicht eine relativ schlechte Idee, wenn Ihr Domain Name Server für sich selbst autorisierend wäre, denn wenn Sie aus irgendeinem (gottverlassenen) Grund den Zugriff auf die IPs verlieren, auf die diese Domains verweisen, haben Sie keinen Zugriff mehr Alle maßgeblichen Nameserver, die Ihren Domains mitteilen, wohin sie gehen sollen oder wo sie Updates erhalten möchten, z. B. der neue Speicherort für sich selbst, ns # .yourdomain.com. Ebenso, wenn ich awesomedomain.com kaufe und auf ns1 & ns2.awesomedomain.com verweise, wurde jedoch noch keinem Rootserver mitgeteilt, auf welche dieser beiden Subdomains ich verweise. Sollte nichts passieren?
Grufftech

Ich weiß nicht, wie schlecht eine Idee ist, aber ich kenne viele Unternehmen, die ihre eigenen Nameserver für ihren öffentlichen Namespace hosten. Wenn ich verstehe, was Sie fragen, ist das, was Leimaufzeichnungen auf den übergeordneten Servern sind.
Joeqwerty

2

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.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.