Zdarzenie uwierzytelniające często obejmuje kilka zegarów: interwał objęty raportem, nadejście raportu, zmianę DNS , wdrożenie aplikacji i kontrolowany test. Umieszczenie ich na jednej osi czasu jest pomocne tylko wtedy, gdy każde wydarzenie zachowuje swoje pierwotne znaczenie. Codziennie raport zbiorczy zazwyczaj nie jest w stanie podać dokładnej minuty, w której każda dołączona wiadomość zakończyła się niepowodzeniem.
Ustal wspólną podstawę czasową
Referencje: RFC 9990 §3.1.1.4, RFC 9990 §3.5.4.
Normalizuj wyświetlane znaczniki czasu do zadeklarowanej strefy czasowej, zachowując oryginalne wartości i precyzję. Zapisz źródła zegara i znaną niepewność. Rozróżnij interwał raportu od sygnatur czasowych przybycia i spożycia. Opóźnione dostarczenie raportu nie powinno być traktowane jako nowa seria wysłania w momencie nadejścia załącznika.
Jeśli to możliwe, ogranicz zakres dochodzenia do domeny autora i zweryfikowanej usługi. Trzymaj niesklasyfikowane źródła oddzielnie. Zachowaj tożsamość osoby zgłaszającej i raportującej, liczbę wiadomości, grupy źródłowe i ocenione tożsamości, a także decyzje dotyczące powielania i nakładania się. Szczegóły te określają, które obserwacje można zgodnie z prawem porównywać.
Dodaj dowody DNS bez przepisywania historii
Referencje: RFC 1034 §3.6, RFC 8767 §4, RFC 9990 §3.3.
Zapisz zatwierdzoną zmianę, planowany czas publikacji, autorytatywne obserwacje i wszelkie próbki modułu rozpoznawania nazw, w tym czas wyszukiwania i zwrócony TTL. Bieżąca odpowiedź DNS ustala, co teraz zaobserwowało to wyszukiwanie; nie jest to pełna historia tego, co każdy odbiorca widział wcześniej.
Buforowanie DNS ma znaczenie w ramach RFC 1034 §3.6; kwalifikujące się nieaktualne zachowanie w ramach RFC 8767 §4 może wydłużyć wykorzystanie pamięci podręcznej poza normalną świeżość. Nie należy twierdzić, że wszystkie odbiorniki zostały przełączone w momencie publikacji lub że dokładnie jeden wyświetlił TTL później. Zachowaj wcześniejszą konfigurację, dziennik zmian i limity dowodów. Jeżeli okres raportowania obejmuje zmianę zasad, oznacz ją jako mieszaną lub potencjalnie mieszaną, zamiast przypisywać każdą obserwację do ostatecznej polityki.
Dodaj dowód aplikacji i odbiorcy
Referencje: RFC 5321 §4.2.5.
Umieść wdrożenia aplikacji, zmiany bram i zmiany podpisywania obok zdarzeń DNS . Zachowaj kontrolowane testy jako indywidualne obserwacje z ich rzeczywistą trasą, odbiorcą i wynikiem. Dziennik aplikacji może wykazywać przesłanie lub akceptację w momencie przeskoku; niekoniecznie oznacza to ostateczną dostawę.
Użyj tych typów dowodów, aby przetestować konkurencyjne wyjaśnienia. Wzrost liczby niepowodzeń po edycji DNS może również zbiegać się z nowym szablonem, który zmienia podpisaną treść. Korelacja zawęża badanie, ale nie identyfikuje przyczyny bez dalszych dowodów.
Pracuj według ograniczonej osi czasu
Przykładowy przypadek: raport obejmuje czas od 00:00 do 24:00 czasu UTC. Zmiana polityki jest rejestrowana o godzinie 12:00, a test kontrolowany o godzinie 12:20 jest zgodny DKIM. Raport zawiera 80 obserwacji pozytywnych i 20 nieudanych, które dotarły następnego ranka o 05:00.
O godzinie 12:20 możesz podać sumę interwałów i pomyślny wynik testu. Nie możesz przypisać wszystkich 20 niepowodzeń do południa tylko dlatego, że test zdał później. Następną czynnością jest uzyskanie dowodów węższego odbiorcy lub aplikacji lub przeprowadzenie dodatkowych reprezentatywnych testów. Przyjazd o godzinie 05:00 jest wydarzeniem zbiorczym, a nie czasem 20 awarii.
Zakończ stwierdzeniem przyczynowym odpowiedniej siły
Oznacz wnioski jako zaobserwowane, potwierdzone lub nadal hipotetyczne. Wymień dowody potwierdzające podejrzaną przyczynę i wszelkie konkurencyjne wyjaśnienia, które nie są wykluczone. Jeśli dokładne powiązanie nie jest możliwe, zachowaj niepewność, zamiast rysować dokładną granicę awarii na wykresie.
Zapisz oś czasu z odniesieniami do źródeł, wersją zapytania, uwzględnionymi odstępami czasu i klasyfikacjami własności. Zapisz kolejny czynnik wywołujący weryfikację, np. pierwszy pełny porównywalny okres raportowania po naprawie. Oś czasu nadająca się do wielokrotnego wykorzystania powinna umożliwić innemu analitykowi zrekonstruowanie zarówno faktów, jak i granic wniosków.
Kontynuuj śledztwo
Skorzystaj z przewodnik dotyczący raportu zbiorczego dla pól bazowych i poradnik diagnostyki zbieżności gdy sukces surowego uwierzytelnienia nie jest zadowalający DMARC.
Zachowaj ilustrację jako dowód
W przypadku fikcyjnego interwału 80 przejść/20 niepowodzeń należy zachować nieznane czasy wszystkich 20 awarii. Test o 12:20 to kolejna obserwacja, a przyjazd o 05:00 to wydarzenie związane z odbiorem. Nie wykonano żadnego prawdziwego wyszukiwania DNS ani testu uwierzytelniania, a na osi czasu nie znaleziono potwierdzonego przyczynowego przejścia.