Nieświeże, spłaszczone Rekord SPF jest kopią autoryzacyjną, która nie stanowi już zamierzonego źródła. Może pominąć nowo użyty zakres wysyłania, zachować taki, który powinien zostać usunięty lub połączyć oba błędy. Widocznym objawem może być brak przesyłki pocztowej, jednak brak reklamacji nie oznacza, że egzemplarz jest aktualny.
Określ, która kopia jest utrzymywana
Zapisz domenę koperty, aktualną SPF wartość i system, który ją wygenerował. Znajdź zależności oryginalnych dostawców oraz sygnatury czasowe ostatniego pomyślnego generowania i publikacji. Jeśli nikt nie jest w stanie zidentyfikować danych wejściowych, potraktuj brakujące pochodzenie jako wadę konserwacyjną, zamiast zgadywać na podstawie bieżących adresów.
Zachowaj rozróżnienie trzech stanów: aktualnej udokumentowanej autoryzacji dostawcy, ostatniej mocy wyjściowej generatora i możliwości rozpoznania odbiorników zapisu. Pomyślna generacja z nieudaną aktualizacją DNS generuje inne zadanie naprawy niż generator, który nigdy nie zauważył zmiany dostawcy.
Niezależnie porównuj dodatki i usunięcia
Utwórz kontrolowane porównanie, korzystając z obsługiwanej semantyki oryginalnych zasad. RFC 7208 definiuje obejmuje jako oceny, więc skrobanie adresu nie jest wystarczającą podstawą dla zasad z warunkami lub makrami. Zapisz każdą nieobsługiwaną konstrukcję i zatrzymaj automatyczną wymianę do czasu poznania jej efektu.
Brakujący dodatek w opublikowanej kopii może stanowić potencjalny problem z dostawą dla legalnego nadawcy korzystającego z tego zakresu. Usunięty zakres, który nadal występuje, stanowi problem nadmiernej autoryzacji. Każdej różnicy nadaj właściciela i powód. Nie nazywaj rekordu naprawionym tylko dlatego, że najbardziej widoczny nadawca, który uległ awarii, już nie działa.
Przykładowy incydent polega na tym, że dostawca zaczyna używać 192.0.2.40 podczas gdy stara, spłaszczona kopia zawiera tylko 192.0.2.10 . Te adresy dokumentacji są wartościami syntetycznymi, a nie wdrożeniowymi. Dodanie zaobserwowanego adresu może ukryć natychmiastową awarię, jednocześnie tracąc resztę obsługiwanej puli dostawcy. Przed przygotowaniem pełnej korekty potwierdź zamierzony zakres dostawcy.
Znajdź nieudany etap
Sprawdź harmonogram odświeżania, status zadania, wyniki zapytania nadrzędnego, ostrzeżenia parsera, wygenerowaną różnicę, kolejkę zatwierdzenia i potwierdzenie publikacji. Następnie wykonaj zapytanie do opublikowanego rekordu i porównaj go z zamierzonymi wynikami. Zachowaj czasy zapytań i tożsamości modułu rozpoznawania nazw, aby odpowiedź w pamięci podręcznej nie została pomylona z nieudanym zapisem.
Buforowanie DNS to oddzielna warstwa od świeżości generatora. Zmniejszenie TTL nie powoduje, że stara skopiowana lista adresów jest poprawna. Nie zmusza również każdego modułu rozpoznawania nazw do odrzucenia danych, które już buforował. Skorzystaj z zaobserwowanych odpowiedzi, wcześniejszej konfiguracji i możliwego nieaktualnego zachowania w sekcji RFC 8767 §4 przy ocenie zbieżności, zamiast obiecywać uniwersalny czas propagacji.
Naprawa bez poszerzania zaufania
Zapisz bieżący rekord i proponowaną zamianę. Rozwiąż każdy nieoczekiwany dodany zakres przed publikacją. Nie autoryzuj całego dostawcy usług w chmurze, ponieważ pojawił się u niego pojedynczy nowy nadawca. Pochodzenie sieci nie jest dowodem na to, że sieć powinna wysyłać przy użyciu tożsamości koperty.
Sprawdź składnię kandydata, ocenione ścieżki wyszukiwania, rodziny adresów i wynik końcowy. Upewnij się, że przy nazwie właściciela będzie istniał tylko jeden odpowiedni rekord SPF . Po zatwierdzeniu opublikuj w ramach ustalonego procesu zmian i przetestuj aplikację, której dotyczy problem, zwykłą drogą.
Dodaj sygnał świeżości, który może w widoczny sposób zawieść
Zalecane monitorowanie powinno uwzględniać „ostatnie wykonanie zadania”, „powodzenie ostatniego odczytu źródła”, „ostatnią zmianę wyniku” i „ostatnią zweryfikowaną publikację”. Źródło, które nie zmieniło się od miesiąca, może nadal być zdrowe; zadanie zgłaszające powodzenie przy wielokrotnym ponownym użyciu nieudanych danych wejściowych nie jest. Wybierz progi alertów dotyczące ryzyka biznesowego i modelu operacyjnego dostawcy, a nie wymyślony interwał odświeżania protokołu.
Zakończ incydent porównaniem przed i po, dowodami z otrzymanej wiadomości i wyjaśnieniem nieudanego etapu. Zachowaj kolejnego właściciela w przypadku wycofanych zakresów i powtarzających się niepowodzeń. Jeśli kopii nie można zachować w sposób niezawodny, należy ponownie rozważyć użycie modelu spłaszczanie kompromisów zamiast wielokrotnego stosowania poprawek adresów alarmowych.
Tło DNS : RFC 1035 sekcja 3.2.1 definiuje TTL rekordu zasobu; RFC 2308 §5 obejmuje buforowanie negatywne; RFC 8767 §4 aktualizuje semantykę TTL i pozwala na nieaktualne użycie w przypadku niepowodzenia autorytatywnego odświeżania. Opisują one zachowanie DNS , a nie uniwersalny czas zakończenia zmiany.
Zapisz następną decyzję
Użyj jednego wiersza na różnicę zakresu: dodana lub wycofana; dowód dostawcy; wersja/czas generatora; zatwierdzony wynik; autorytatywna odpowiedź/czas; rekurencyjna odpowiedź/czas; i dotknięta trasa. Obecne pokolenie oraz stare wiarygodne dane wskazują na publikację; aktualne wiarygodne dane plus stara odpowiedź rekurencyjna wymagają zbadania stanu mechanizmu rozpoznawania nazw. Są to gałęzie diagnostyczne, a nie mierzone incydenty, a przestarzałe użycie może komplikować synchronizację.