Ein nützlicher DNS Verlauf erklärt sowohl die Absicht als auch die Beobachtung. Auf dem Änderungsticket steht, was ein Betreiber veröffentlichen wollte. Eine verbindliche Antwort zeigt, was ein abgefragter Server zu einem bestimmten Zeitpunkt zurückgegeben hat. Eine rekursive Antwort zeigt, was dieser Resolver zurückgegeben hat, möglicherweise aus dem Cache. Behalten Sie alle drei bei, wenn Sie einen Authentifizierungsvorfall rekonstruieren. Keiner allein erzählt die ganze Geschichte.
Notieren Sie das genaue Objekt und die Quelle
Behalten Sie für jede Beobachtung die UTC-Zeit, den Namen des abgefragten Eigentümers, den Typ, die Serveradresse, den Transport, den Antwortcode, die relevanten Flags, die TTL und die vollständige Antwort bei. Behalten Sie Rohausgabe- oder Verbindungsdaten sowie eine normalisierte Ansicht bei. Notieren Sie, ob die Beobachtung von einem autorisierenden Server, einem rekursiven Resolver oder einem Control-Panel-Export stammt. RFC 1034 erklärt den Unterschied zwischen Autorität und Caching.
Behalten Sie bei einer Richtlinienänderung die vorherigen und beabsichtigten Werte, den Genehmiger, den Geschäftsgrund, die betroffenen Absender und die Rollback-Bedingungen bei. Ein späterer Screenshot kann den früheren DNS Status nicht beweisen. Wenn der Verlauf nicht erfasst wurde, sagen Sie es. Passive Beobachtungen oder Berichtsmetadaten können Hinweise liefern, sollten jedoch nicht als vollständiges, maßgebliches Änderungsprotokoll dargestellt werden.
Behalten Sie die Semantik beim Vergleich von Datensätzen bei
Vorsichtig normalisieren. DNS Namen wird die Groß-/Kleinschreibung nicht beachtet, aber eine wahllose Umwandlung aller TXT Inhalte kann Beweise beschädigen. TXT RDATA kann mehrere Zeichenfolgen enthalten; Das Zitieren von Präsentationen ist nicht dasselbe wie mehrere unabhängige Ressourceneinträge. Erhalten Sie die ursprüngliche Struktur und vergleichen Sie den anwendungsrelevanten Wert separat. Für SPF, mehrere Richtliniendatensätze sind ein semantisches Problem und keine harmlose Formatierung.
Trennen Sie eine Richtlinienwertänderung von einer TTL-Änderung, einer Delegationsänderung und einem Resolver-Cache-Übergang. Negative Antworten können gemäß den Negativ-Caching-Regeln in bestehen bleiben RFC 2308. Ein neuer maßgeblicher Wert stellt nicht sicher, dass jeder Empfänger ihn sofort verwendet hat. Vermeiden Sie es, aus einer erfolgreichen Suche einen universellen Zeitpunkt für den Abschluss der Weitergabe abzuleiten.
Lesen Sie zwei Beobachtungen, ohne eine Bearbeitungszeit zu erfinden
Angenommen, eine autorisierte autorisierende Abfrage um 10:00 Uhr zeigt eine alte Richtlinie. Um 10:05 Uhr gibt dieselbe Autorität die neue Richtlinie zurück, während ein rekursiver Resolver immer noch den alten Wert mit einer verbleibenden Cache-Lebensdauer zurückgibt. Beide Beobachtungen können für ihre jeweiligen Quellen zutreffend sein. Weder stellt sicher, dass alle anderen Server oder Empfänger den neuen Wert haben.
Hierbei handelt es sich um eine hypothetische Zeitleiste, nicht um zurückgehaltene Pakete oder ein ausgeführtes DNS Labor. Wenn das Provider-Audit-Ereignis nicht verfügbar ist, ist der genaue Zeitpunkt der Mutation unbekannt. Unter der erklärten Annahme eines einzelnen Übergangs bei der befragten Behörde werden die Beobachtungen gebunden, wenn sich die sichtbare Antwort dieser Behörde ändert; Sie beweisen nicht den genauen Veröffentlichungszeitpunkt oder die globale Konvergenz. Erfassen Sie das fehlende Audit-Ereignis, anstatt es mit einem geschätzten Zeitstempel zu füllen.
Verknüpfen Sie den Verlauf mit Nachrichtenbeweisen
Passen Sie bei der Überprüfung eines Fehlers Nachrichtenzeitstempel, DNS Beobachtungen, Signaturselektoren, Warteschlangenverzögerungen und Berichtsbeobachtungsintervalle an. RFC 9990 Bietet aggregierten Berichtskontext, ein Bericht ist jedoch kein Transaktionsprotokoll für DNS Änderungen. Ein Authentifizierungsergebnis beschreibt eine Bewertung; Möglicherweise wird der genaue Inhalt des Resolver-Cache, der das Problem verursacht hat, nicht angezeigt.
Bewahren Sie die Beweise im Rahmen einer genehmigten Zugriffs- und Aufbewahrungsrichtlinie auf. Hashes helfen dabei, geänderte Bytes zu erkennen, aber ein unsigniertes lokales Manifest ist keine manipulationssichere Herkunft. Behalten Sie den Quell- und Sammlungskontext mit dem Digest bei. Machen Sie Lücken deutlich, einschließlich fehlender Aussichtspunkte oder nicht erfasster Zeiträume. Das Ziel ist eine vertretbare Rekonstruktion und eine sicherere nächste Änderung, nicht eine falsche Gewissheit über die Meinung jedes Empfängers.