Was ist das richtige Verhalten, wenn sich Nameserver ändern?

Ich hatte einige Probleme mit einem bestimmten Netzwerkanbieter wegen unveränderter Nameserver, die meine Website für ihre Kunden unsichtbar machten. Es würde mich nicht stören, außer dass sie einer der größten ISPs in Irland sind.

Sie behaupten, dass die Datensätze auf den alten Nameservern für meine Site noch aktiv sind, daher sollten sie sich nicht ändern, bis sie eine Antwort erhalten, die ihnen mitteilt, dass es keine DNS-Datensätze für die Site gibt.

Meine Frage ist, was ist das richtige Verhalten? Jeder andere Netzwerkanbieter, ISP, DNS-Server im Web, wurde auf meine neuen Nameserver aktualisiert.

Folgen sie einem technisch korrekten, aber ignorierten RFC, der besagt, dass sie keine neuen Nameserver überprüfen müssen, bis die alten einen Fehler zurückgeben?

Aktualisieren:

Vodafone hat mich schließlich kontaktiert und erklärt, dass das Problem behoben wurde, und, was noch wichtiger ist, eskaliert es jetzt an das richtige technische Personal, sodass dieses Problem niemanden betrifft. Hoffe, das löst das Problem.

Sie sehen anscheinend ein Problem, das als klebrige Kinder-Resolver bekannt ist .

Für jeden Domänennamen gibt es zwei mögliche Sätze von NSDatensätzen - die in der übergeordneten Zone und die in der Zone selbst.

Einige rekursive Resolver speichern den vom Kind gelernten Satz zwischen und kehren dann für alle nachfolgenden Aktualisierungen wiederholt zu diesen Servern zurück. Dies ist das klebrige Verhalten des Kindes . Wenn die Datensätze der übergeordneten Zone geändert werden, die (ursprünglichen) Datensätze der untergeordneten Zone jedoch unverändert bleiben, bemerken diese untergeordneten Sticky Resolver die Änderung in der übergeordneten Zone nicht.

Viele (wenn nicht die meisten) Implementierungen werden auf die übergeordneten NSDatensätze zurückgesetzt, um sicherzustellen, dass sie nicht geändert werden, wenn der aktuelle NSDatensatz aus dem Cache abläuft. Dies wird als "normales Verhalten" betrachtet, ist jedoch in den RFCs nicht eindeutig angegeben.

Um dieses klebrige Verhalten Ihres Kindes zu umgehen , sollten Sie die NSDatensätze auf Ihren alten Servern durch die richtigen Datensätze ersetzen , in denen die Namen der neuen Server angezeigt werden.

Weitere Einzelheiten finden Sie auf den Folien 8 bis 15 dieser Präsentation von Ólafur Guðmundsson, Vorsitzender der IETF DNSEXT-Arbeitsgruppe .

Folgen sie einem technisch korrekten, aber ignorierten RFC, der besagt, dass sie keine neuen Nameserver überprüfen müssen, bis die alten einen Fehler zurückgeben?

Wie würden wir wissen?

AFAIK gibt es so etwas nicht - und sie sollten die Datensätze jedes Mal aktualisieren, wenn sie eine Anfrage für einen zwischengespeicherten Datensatz mit einer abgelaufenen TTL erhalten.

Nun, ich habe bei ns.webfusion.co.uk Datensätze für Ihre Domain-Daten darin gesehen. Leider haben Sie keine Zonen auf alten NS getötet, aber dies entschuldigt nicht das Verhalten von Vodafone. Ich werde das jetzt erklären. Nehmen wir an, Vodafone-Resolver haben vor einiger Zeit beide Datensätze zwischengespeichert: A für www und NS für Domain. Aber ich sehe

Quering 212.67.202.1 for {cookingisfun.ie.,NS}
; Answer ID: 18467  QR: true  OPCODE: QUERY  AA: true  TC: false  RD: true
; RA: false  RCODE: NOERROR  qc 1  an 2  au 0  ad 2

; Question section:
;cookingisfun.ie. IN NS

; Answer section:
cookingisfun.ie. 1d IN NS ns2.hosteurope.com. 
cookingisfun.ie. 1d IN NS ns.hosteurope.com. 

; Authority section:
;(none)

; Additional section:
ns2.hosteurope.com. 2h IN A 92.51.159.40 
ns.hosteurope.com. 2h IN A 212.67.202.2

dh NS-Datensätze müssen nach einem Tag nach dem Empfang abgelaufen und aus dem Cache entfernt werden

Quering 212.67.202.1 for {www.cookingisfun.ie.,A}
; Answer ID: 18467  QR: true  OPCODE: QUERY  AA: true  TC: false  RD: true
; RA: false  RCODE: NOERROR  qc 1  an 1  au 0  ad 0

; Question section:
;www.cookingisfun.ie. IN A

; Answer section:
www.cookingisfun.ie. 1d IN A 212.67.220.186 

; Authority section:
;(none)

; Additional section:
;(none)

; Query took: 94 msec
; Server queried: 212.67.202.1[udp]

Das gleiche 1-Tages-Intervall gilt für A für www.cookingisfun.ie

Dh nach einem Tag Verspätung muss Vodafone erneut nach A fragen, und ein Rekorder auf dem Pfad gibt neue NS und neue NSes zurück - neue A.

Da wir wissen, dass dies nicht geschieht, sehe ich dies als eine starke Folge von RFC-Ignoranz (Speichern veralteter Daten im Cache - siehe meine Antwort auf Ihre vorherige Frage). Toby, ich denke, Sie können Vodafone meine obigen Anfragen zeigen und fragen: "WTF ??? Warum verwenden Sie veraltete Daten? Sie dürfen 212.67.202.2 nicht nach nichts fragen, was mit cookisfisf.ie vor langer Zeit zu tun hat. Fixit ASAP"