Ein Wartungsfenster ist ein Koordinationszeitraum und kein Versprechen, dass jeder Empfänger im selben Moment den neuen DNS Status sieht. Planen Sie die Änderung im Hinblick auf kritische Geschäftsabläufe, DNS Caching und die Zeit, die zum Beobachten der Ergebnisse erforderlich ist. Teilen Sie den Stakeholdern mit, was an jedem Kontrollpunkt bekannt ist, anstatt den Erfolg sofort zu verkünden ein Rekord wird gespeichert.
Wählen Sie ein Fenster rund um die Servicekonsequenzen
Listen Sie betroffene Bewerbungen, Sendespitzenzeiten, geplante Aufträge und die Personen auf, die diese prüfen können. Vermeiden Sie eine Gehaltsabrechnung oder eine Migration zur Passwortwiederherstellung, es sei denn, das Unternehmen hat diesen Zeitpunkt akzeptiert. Schließen Sie DNS und Messaging-Betreiber, einen Vorfallkontakt und eine Person ein, die befugt ist, den genehmigten Wiederherstellungsplan anzuwenden.
Definieren Sie die genaue Änderung und ihre Basislinie, bevor Sie das Fenster auswählen. Die Authentifizierungsrichtlinie kann mit Absendern außerhalb der primären Postfachplattform interagieren. Bestandsanwendungs-Relays und Signaturen Dritter sowie Mitarbeiter-Mails. DMARC Ausrichtung und Empfängerhandhabung unterscheiden sich vom Abnahmetest des Serviceeigentümers. RFC 9989.
Konto für vorhandene Caches
DNS TTL steuert, wie lange ein Ressourceneintrag zwischengespeichert werden darf, abhängig vom Resolver-Verhalten. Durch das Verringern einer TTL werden Datensätze, die bereits unter dem vorherigen Wert zwischengespeichert wurden, nicht gelöscht. RFC 1035 , Ressourcendatensatzformat und Resolver-Implementierung. Planen Sie bei der Planung einer Änderung Zeit für vorherige positive Cache-Einträge ein. Berücksichtigen Sie gegebenenfalls auch negative Antworten, Abhängigkeiten und Anbieterverhalten.
Ein hypothetisches Planungsbeispiel beginnt mit TTL 3600. Ein niedrigerer TTL 300 wird um 01:00 UTC veröffentlicht und die geplante Änderung ist 02:10 UTC. Ein altes TTL-Intervall nach 01:00 Uhr ist 02:00 Uhr; der geplante Wechsel um 02:10 Uhr erfolgt zehn Minuten später. Hierbei handelt es sich um eine manuelle Berechnung über angenommene Zeiten, nicht um eine durchgeführte Terminüberprüfung. Es beweist keine maßgebliche Konvergenz, globale Ausbreitung oder den Ablauf negativer Caches. Bestätigen Sie tatsächliche Beobachtungen, bevor Sie sich auf den Zeitplan verlassen.
Kommunizieren Sie in drei Schritten
Senden Sie der autorisierten Zielgruppe vor dem Fenster den Umfang, die erwartete Wirkung, den Zeitpunkt, die Verifizierungseigentümer und den Fallback-Kontakt. Beschreiben Sie die Änderung nicht als risikofrei. Notieren Sie während der Implementierung den tatsächlich beobachteten Zustand und den nächsten Kontrollpunkt. Wenn Tests fehlschlagen oder die Basislinie abweicht, melden Sie den spezifischen Blocker und die erforderliche Entscheidung und nicht eine unerklärliche Verzögerung.
Unterscheiden Sie nach der Umsetzung abgeschlossene Sofortkontrollen von noch ausstehenden verspäteten Beobachtungen. DMARC -Berichte beschreiben Empfängerbeobachtungen und können später als der Wartungszeitraum eintreffen. RFC 9990. Sagen Sie, welche Diensttests bestanden wurden, welche noch ungetestet sind und wer die nachfolgenden Beweise prüfen wird. Eine autorisierte interne Statusnachricht sollte keine Nachrichteninhalte, Anmeldeinformationen oder unnötigen Empfängerdetails preisgeben.
Halten Sie Personal für die Genesung und Nachsorge bereit
Behalten Sie den alten RRset und die genehmigten Wiederherstellungskriterien bei. Es kann einige Zeit dauern, bis das Zurücksetzen der Konfiguration beobachtet wird, und frühere Entscheidungen des Empfängers können nicht rückgängig gemacht werden. Behalten Sie die Überwachung und Verantwortung für Vorfälle über das geplante Zeitfenster hinaus bei, wenn das Risiko dies erfordert. Wenn der Geschäftstest erst bei der nächsten geplanten Kampagne ausgeführt werden kann, notieren Sie diese Einschränkung, anstatt den Dienst als verifiziert zu betrachten.
Beispielsweise kann eine sofortige Konfigurationsprüfung während des Zeitfensters abgeschlossen werden, während eine vierteljährliche Kampagne erst nach ihrem genehmigten Zeitplan durchgeführt werden kann. Nennen Sie den Kampagnenprüfer, den nächsten Kontrollpunkt und den Eskalationskontakt in der Übergabe. Geben Sie an, dass die Implementierung abgeschlossen ist, die Überprüfung der Kampagne jedoch noch aussteht. Bei dieser hypothetischen Statusunterscheidung handelt es sich nicht um eine gesendete Nachricht oder ein tatsächliches Wartungsereignis. Schließen Sie sofortige Arbeiten ab, ohne stillschweigend die spätere Sicherungspflicht zu schließen.
Der oben beschriebene Änderungsworkflow ist eine betriebliche Empfehlung und keine Protokollanforderung. NIST SP 800-53 Rev. 5-Kontrollen CM-3 und CM-5 bieten eine allgemeine Grundlage für die Überprüfung, Genehmigung und Einschränkung von Änderungen. Der Wartungszeitpunkt, die Kommunikationskontrollpunkte und die Folgeverantwortung sind hier die vorgeschlagene Implementierung. NIST Kontrollkatalog.