Ersetzen Sie die Verbreitungsfrist durch einen Änderungsplan
Mithilfe einer DNS -TTL lässt sich ermitteln, wann zwischengespeicherte Informationen erneut berücksichtigt werden. Es ist kein weltweiter Zeitpunkt vorgesehen, an dem jeder Empfänger einen Ersatz verwendet SPF Politik bzw DKIM Schlüssel. Verschiedene Resolver haben die alte Antwort zu unterschiedlichen Zeiten erhalten, autorisierende Server stellen möglicherweise nicht alle die neuen Daten bereit und Anwendungen können ihr eigenes Such- und Wiederholungsverhalten haben.
Ein nützlicher Änderungsplan trennt die maßgebliche Veröffentlichung von der nachgelagerten Beobachtung. „Der DNS Host hat die Änderung akzeptiert“ ist ein früherer Meilenstein als „die relevanten autorisierenden Server geben die beabsichtigte Antwort zurück“. Keine der Aussagen stellt fest, was ein bestimmter E-Mail-Empfänger für eine vor einer Minute gesendete Nachricht verwendet hat. Beginnen Sie den Zeitplan mit Belegen für jeden Meilenstein und nicht mit dem allgemeinen Versprechen, dass DNS eine feste Anzahl von Stunden in Anspruch nimmt.
Verstehen Sie, welche TTL beobachtet wird
Einem maßgeblichen Ressourceneintrag ist eine TTL mit den veröffentlichten Daten verknüpft. Eine zwischengespeicherte Antwort meldet normalerweise die verbleibende Lebensdauer der zwischengespeicherten Daten, sodass zwei rekursive Resolver identischen Text mit unterschiedlichen verbleibenden TTLs zurückgeben können. Diese Werte beschreiben unterschiedliche Cache-Zustände; es handelt sich nicht um zwei konkurrierende Deklarationen der beabsichtigten Konfiguration des Datensatzes. RFC 1035 , Abschnitt 4.1.3; RFC 1034 , Abschnitt 6.2.1.
Wenn ein vorhandener Datensatz eine lange TTL hat, wirkt sich die Reduzierung dieses Werts nicht auf Caches aus, in denen bereits die ältere Antwort gespeichert ist. Planen Sie die Reduzierung vor der wesentlichen Änderung und berücksichtigen Sie das vorherige Caching-Fenster. Stellen Sie sicher, dass die niedrigere TTL tatsächlich bereitgestellt wird, bevor Sie sie als Teil des Wartungsplans behandeln. Dies ist eine Planungshilfe und kein Beweis dafür, dass jeder Cache beobachtet wurde.
Eine Aliaskette fügt unterschiedliche Abhängigkeiten hinzu. Der Aliasdatensatz und der Datensatzsatz des Ziels können unterschiedliche TTLs und unterschiedliche Operatoren haben. Eine kurze TTL auf Kundenseite CNAME erzwingt nicht, dass ein bereits zwischengespeicherter Zielschlüssel gleichzeitig aktualisiert wird. Schreiben Sie beide Namen auf, bevor Sie versuchen, den Zeitpunkt zu erklären.
Modellieren Sie die alten und neuen Antworten getrennt
Betrachten Sie ein fiktives SPF Update unter mail.example.com. Resolver A erhält die alte Richtlinie um 09:50 Uhr mit einer TTL von 3.600 Sekunden. Um 10:00 Uhr ändert der maßgebliche Betreiber die veröffentlichte TTL auf 300. Um 10:10 Uhr ersetzt der Betreiber die Richtlinie. Der frühere Eintrag von Resolver A kann unter seiner ursprünglichen Cache-Lebensdauer bis 10:50 Uhr weiterhin verwendet werden, sofern kein anderes Verhalten auftritt. Ein zweiter Resolver, der sich zunächst um 10:10 kümmert, kann bereits Ersatz liefern.
Bei diesem Beispiel handelt es sich um eine erfundene Arithmetik, nicht um eine Messung oder einen garantierten Ablaufplan. Die Lehre daraus ist, dass eine Senkung der TTL um 10:00 Uhr den 09:50 Uhr-Eintrag von Resolver A nicht neu schreibt. Ein Betriebsarbeitsblatt sollte die vorherigen Daten, die vorherige TTL, den Zeitpunkt, zu dem die TTL-Änderung bei der Behörde beobachtet wurde, den Zeitpunkt, zu dem sich der Inhalt änderte, und nachfolgende abgetastete Resolver-Antworten enthalten.
Behalten Sie für eine DKIM Rotation separate Meilensteine für die Veröffentlichung des neuen bei Wähler, Überprüfen seiner Verfügbarkeit, Starten von Signaturen, die ihn verwenden, und Entfernen des alten Selektors. DNS -Cache-Arithmetik allein kann nicht entscheiden, wann die Überprüfung zuvor gesendeter E-Mails abgeschlossen ist. Die Warteschlangen-, Wiederholungs- und Aufbewahrungsanforderungen des Absenders gehören ebenfalls in die Rotationsentscheidung. RFC 6376 , Abschnitte 3.1 und 3.6.
Beziehen Sie negative Antworten und Ausfallverhalten mit ein
Ein neu erstellter Name weist möglicherweise keine alte positive Aufzeichnung auf. Ein Resolver könnte stattdessen ein früheres NXDOMAIN oder NODATA Ergebnis speichern. Die SOA-basierte Lebensdauer der negativen Antwort unterscheidet sich vom TTL der neu veröffentlichten Antwort TXT Eintrag. Durch das Ändern der neuen TXT -TTL wird eine zuvor zwischengespeicherte Abwesenheit daher nicht gelöscht. RFC 2308 , Abschnitte 3 und 5.
Es gibt auch eine explizite Standardausnahme für eine einfache Ablaufstory. RFC 8767 erlaubt die Bereitstellung veralteter Daten, wenn ein abgelaufener Eintrag nicht autorisierend aktualisiert werden kann. Ob dies der Fall ist, hängt vom Resolver und den Fehlerbedingungen ab. Gehen Sie nicht davon aus, dass eine zurückgegebene Antwort aktuell ist, nur weil sie eine kleine TTL ungleich Null hat. RFC 8767 , Abschnitte 4–5.
Diese Fälle sollten die Ermittlungen verändern und nicht zu einer willkürlichen Verlängerung der Wartezeit führen. Wenn die Behörden anderer Meinung sind, korrigieren Sie die Konsistenz der Veröffentlichung. Wenn eine negative Antwort weiterhin besteht, überprüfen Sie die ursprüngliche Frage und den SOA-Kontext. Wenn die Autorität nicht erreichbar ist, stellen Sie die Verfügbarkeit wieder her oder untersuchen Sie sie, anstatt einen bereits korrekten TXT Eintrag wiederholt zu bearbeiten.
Wählen Sie Beobachtungen aus, die die Freigabefrage beantworten
Erfassen Sie vor der Änderung den genauen Datensatz und seine TTL von den zuständigen Behörden und ausgewählten rekursiven Pfaden. Wiederholen Sie anschließend denselben Eigentümer, Typ und dieselbe Klasse für dieselben Endpunkte. Fügen Sie einen für die betroffene Umgebung relevanten Pfad hinzu, sofern verfügbar; Bei mehreren öffentlichen Resolvern handelt es sich weiterhin um Stichproben, nicht um eine Zählung aller Postempfänger.
Eine vorgeschlagene Abfrage ist dig @RESOLVER_IP mail.example.com . TXT, gepaart mit dig @AUTH_IP mail.example.com . TXT +norecurse. Speichern Sie die vollständigen Antworten mit UTC-Zeitstempeln und beschriften Sie alle Platzhalter vor der Verwendung. Ein lokaler Cache-Flush ändert nur diesen lokalen Caching-Pfad. Der rekursive Cache eines Remote-Empfängers kann nicht gelöscht werden, es handelt sich also nicht um eine globale Abschlusskontrolle.
Geben Sie das Ergebnis genau an: Welche Behörden sind sich einig, welche abgetasteten Resolver geben den neuen Wert zurück und welche Beobachtungen fehlen noch. Senden Sie dann eine kontrollierte Nachricht über den vorgesehenen Dienst und überprüfen Sie die tatsächlichen Authentifizierungsidentitäten und das Empfängerergebnis. Für diesen Entwurf wurden keine DNS Abfragen oder Nachrichtentests durchgeführt. Der erforderliche Resolver-Vergleich, einschließlich TTL, Antworttyp, Autorität und Beobachtungszeit, bleibt offen.