Przydatna historia DNS wyjaśnia zarówno intencje, jak i obserwacje. Bilet zmiany mówi, co operator miał na myśli opublikować. Wiarygodna odpowiedź pokazuje, co w danym momencie zwrócił zapytany serwer. Odpowiedź rekurencyjna pokazuje, co zwrócił ten program rozpoznawania nazw, prawdopodobnie z pamięci podręcznej. Zachowaj wszystkie trzy podczas rekonstrukcji zdarzenia uwierzytelniającego; nikt sam nie opowiada całej historii.
Zapisz dokładny obiekt i źródło
Dla każdej obserwacji zachowaj czas UTC, nazwę właściciela zapytania, typ, adres serwera, transport, kod odpowiedzi, odpowiednie flagi, TTL i pełną odpowiedź. Zachowaj surowe dane wyjściowe lub dane przewodów, a także widok znormalizowany. Zapisz, czy obserwacja pochodzi z autorytatywnego serwera, rekursywnego modułu rozpoznawania nazw czy eksportu z panelu sterowania. RFC 1034 wyjaśnia rozróżnienie między uprawnieniami i buforowaniem.
W przypadku zmiany zasad zachowaj poprzednie i zamierzone wartości, osobę zatwierdzającą, powód biznesowy, nadawców, których to dotyczy, i warunki wycofywania. Późniejszy zrzut ekranu nie może potwierdzić wcześniejszego stanu DNS . Jeśli historia nie została uchwycona, powiedz to. Pasywne obserwacje lub metadane raportu mogą dostarczyć wskazówek, ale nie powinny być przedstawiane jako pełny i miarodajny dziennik zmian.
Zachowaj semantykę podczas porównywania rekordów
Normalizuj ostrożnie. W nazwach DNS nie jest rozróżniana wielkość liter, ale masowa transformacja całej zawartości TXT może uszkodzić dowody. TXT RDATA może zawierać wiele ciągów znaków; Cytowanie prezentacji to nie to samo, co wiele niezależnych rekordów zasobów. Zachowaj oryginalną strukturę i porównaj osobno wartość mającą znaczenie dla aplikacji. Dla SPF, wiele rekordów zasad to kwestia semantyczna, a nie nieszkodliwe formatowanie.
Oddziel zmianę wartości polityki od zmiany TTL, zmiany delegowania i przejścia pamięci podręcznej programu rozpoznawania nazw. Negatywne odpowiedzi mogą się utrzymywać zgodnie z regułami negatywnego buforowania w RFC 2308. Nowa miarodajna wartość nie oznacza, że każdy odbiorca natychmiast z niej skorzystał. Unikaj wyznaczania uniwersalnego czasu zakończenia propagacji na podstawie jednego udanego wyszukiwania.
Przeczytaj dwie obserwacje bez wymyślania czasu edycji
Załóżmy, że autoryzowane autorytatywne zapytanie o godzinie 10:00 pokazuje starą politykę. O 10:05 ten sam organ zwraca nową politykę, podczas gdy rekurencyjny program tłumaczący nadal zwraca starą wartość z pozostałym czasem życia pamięci podręcznej. Obie obserwacje mogą być dokładne dla swoich odpowiednich źródeł. Żadne z nich nie ustala, że wszystkie inne serwery lub odbiorniki mają nową wartość.
Jest to hipotetyczna oś czasu, niezatrzymane pakiety lub wykonane laboratorium DNS . Jeśli zdarzenie kontroli dostawcy jest niedostępne, dokładna chwila mutacji nie jest znana. Przy przyjętym założeniu pojedynczego przejścia u pytanego organu obserwacje wiążą się w przypadku zmiany widocznej odpowiedzi tego organu; nie potwierdzają dokładnego czasu publikacji ani globalnej konwergencji. Zarejestruj brakujące zdarzenie audytu zamiast wypełniać je odgadniętym znacznikiem czasu.
Połącz historię z dowodami wiadomości
Przeglądając awarię, dopasuj znaczniki czasu wiadomości, obserwacje DNS , selektory podpisu, opóźnienia w kolejkach i interwały obserwacji raportów. RFC 9990 zapewnia zbiorczy kontekst raportowania, ale raport nie jest dziennikiem transakcji dla edycji DNS . Wynik uwierzytelnienia opisuje ocenę; może nie ujawnić dokładnej zawartości pamięci podręcznej modułu rozpoznawania nazw, która to spowodowała.
Zachowaj dowody zgodnie z zatwierdzoną polityką dostępu i przechowywania. Hashe pomagają wykryć zmienione bajty, ale niepodpisany manifest lokalny nie jest pochodzeniem odpornym na manipulacje. Zachowaj kontekst źródła i kolekcji za pomocą podsumowania. Wyraźnie zaznacz luki, w tym brakujące punkty obserwacyjne lub niezarejestrowane okresy. Celem jest możliwa do obrony rekonstrukcja i bezpieczniejsza następna zmiana, a nie fałszywa pewność co do opinii każdego odbiorcy.