Pod RFC 9989 §9.2, tymczasowy DMARC błąd oznacza, że podczas oceny napotkano problem, który może zostać rozwiązany przy późniejszej próbie. Nie oznacza to, że w domenie nie obowiązują żadne zasady ani że legalna poczta ostatecznie nie przeszła uwierzytelnienia.
Potraktuj wynik jako początek dochodzenia w sprawie rozwiązania problemu. Ustal, które wymagane wyszukiwanie nie powiodło się, czy dane istnieją u jego władz i co uniemożliwiło systemowi odbierającemu uzyskanie użytecznej odpowiedzi.
Uchwyć nieudaną ocenę
Zapisz pełny zaufany wynik lub zwróconą odpowiedź SMTP , czas, z domeny i trasę wysłania. Zwróć uwagę, do której metody uwierzytelniania należy błąd. Tymczasowy SPF Lub DKIM problem nie jest automatycznie taki sam jak dmarc=temperror.
Zachowaj dokładną nazwę wyszukiwania i typ rekordu, gdy dzienniki je ujawnią. Zapytanie TXT dotyczące polityki, zależność SPF i a Selektor DKIM wyszukiwanie może dotyczyć różnych nazw i organów. Testowanie tylko katalogu głównego domeny może spowodować pominięcie nieudanej zależności.
Przed wprowadzeniem zmian zachowaj mały pakiet dowodów. Powtarzające się zapytania mogą zakończyć się powodzeniem po incydencie, więc późniejsza prawidłowa odpowiedź nie może zastąpić pierwotnego rekordu niepowodzenia.
Podążaj ścieżką decyzji opartą na odpowiedzi
To jest diagnostyczna tabela decyzyjna, a nie uniwersalne mapowanie statusu DNS na jedną dyspozycję e-mail:
- Obserwacja zapytania: odpowiednia pełna odpowiedź z NOERROR; Co ustala: to zapytanie zwróciło w tamtym czasie użyteczne dane; Następne dochodzenie: Porównaj je z wcześniejszą obserwacją odbiorcy
- Obserwacja zapytania: Kompletna odpowiedź bez danych; Co ustala: Żądany zestaw rekordów nie został znaleziony w tym kontekście odpowiedzi; Następne dochodzenie: sprawdź dokładne imię i nazwisko, uprawnienia, aliasy i odkrycie
- Obserwacja zapytania: NXDOMAIN bez komplikacji związanej z aliasem; Co stwierdza: Zapytana nazwa właściciela nie istnieje; Następne badanie: Potwierdź zakres zapytania i obowiązującą rezerwę
- Obserwacja zapytania: SERVFAIL ; Co stwierdza: Rozwiązanie nie zostało pomyślnie zakończone; Następne dochodzenie: sprawdź dzienniki uprawnień, delegacji, walidacji i rozpoznawania nazw
- Zapytanie obserwacji: ODMOWA; Co stwierdza: Serwer odrzucił zapytanie; Następne dochodzenie: Sprawdź zasady zapytań i zamierzoną rolę serwera
- Obserwacja zapytania: przekroczenie limitu czasu; Co ustala: W granicach próby nie otrzymano żadnej użytecznej odpowiedzi; Następne dochodzenie: Sprawdź dostępność, transport, utratę i stan serwera
Kody odpowiedzi DNS są definiowane przez RFC 1035 §4.1.1; negatywne odpowiedzi wg RFC 2308 §2.1 I RFC 2308 §2.2. Zapytanie o _dmarc.example.com dotyczy nazwy tego właściciela. Jej odpowiedź negatywna sama w sobie nie oznacza, że witryna example.com nie istnieje. Przed przypisaniem nieobecności do oryginalnej nazwy, której dotyczy zapytanie, postępuj zgodnie z łańcuchami aliasów.
Porównaj ścieżki autorytatywne i rekurencyjne
Najpierw zidentyfikuj właściwe serwery autorytatywne, w tym wszelkie delegowane subdomeny. Przetestuj odpowiednią nazwę w każdym urzędzie i porównaj odpowiedzi. Jeśli władze nie zgadzają się z tym, sprawdź stan obsługi strefy i ostatnie zmiany.
Następnie sprawdź ścieżkę rekurencyjną używaną przez system odbierający, którego dotyczy problem, jeśli dostępne są dowody. Porównaj czas zapytania, status, odpowiedź i TTL. Lokalny program rozpoznawania nazw operatora i zdalny odbiornik mogą mieć inny stan buforowania lub sprawdzania poprawności.
Poniższy fikcyjny skrócony zapis ilustruje porównanie:
14:02 UTC | rekurencyjny mechanizm rozpoznawania nazw R | _dmarc.example.com TXT | SERVFAIL 14:04 UTC | autorytatywny serwer A | ta sama nazwa/typ | BŁĄD, zasady zwrócone o 14:04 UTC | autorytatywny serwer B | ta sama nazwa/typ | BŁĄD, zasady zwrócone o 14:09 UTC | rezolwer R po zbadanej naprawie | ta sama nazwa/typ | NIEBŁĄDObserwacje te zawężają badanie do ścieżki rekursywnej lub interweniującej. Nie udowadniają przyczyny bez logów i nie ustalają tego, czego doświadczył każdy odbiorca.
Uwzględnij w dochodzeniu weryfikację DNSSEC
Pod RFC 4035 §5.5, sprawdzający mechanizm rozpoznawania nazw może odrzucić dane, które się nie powiodą DNSSEC sprawdzanie poprawności nawet wtedy, gdy bezpośrednie zapytanie do autorytatywnego serwera zwraca tekst. Sprawdź dowody delegowania i walidacji, w tym zmiany klucza lub podpisu, korzystając z narzędzi i dzienników obsługiwanych przez odpowiedzialny zespół DNS .
Bezpośrednia odpowiedź organu sama w sobie nie odzwierciedla decyzji odbiorcy o zatwierdzeniu. Podobnie jeden SERVFAIL nie oznacza problemu DNSSEC ; może to mieć kilka przyczyn.
Napraw stwierdzoną wadę walidacji, jeśli taka istnieje. Wyłączenie sprawdzania poprawności w celu ukrycia symptomu nie jest dowodem na przywrócenie zamierzonej ścieżki bezpiecznego rozwiązania.
W stosownych przypadkach przetestuj zarówno UDP, jak i TCP
Transport DNS może być częścią niepowodzenia. Pomyślne wykonanie małego zapytania UDP nie oznacza, że większa odpowiedź, ponowienie odpowiedzi ze skróconą odpowiedzią lub protokół TCP działają na tej samej ścieżce.
RFC 7766 RFC 7766 §5 wymaga implementacji DNS ogólnego przeznaczenia obsługujących zarówno UDP, jak i TCP. Porównaj odpowiednią nazwę i typ każdego transportu podczas diagnozowania błędów związanych z osiągalnością lub rozmiarem. Zamiast zakładać, że każdy przekroczenie limitu czasu ma tę samą przyczynę, sprawdź flagę obcięcia i dowody sieci.
Badanie transportowe jest obserwacją diagnostyczną. Nie należy go przekształcać w obejście produkcyjne, które omija zamierzony moduł rozpoznawania nazw lub ścieżkę walidacji bez sprawdzonego projektu.
Trzymaj oddzielnie nieobecność i nieudane rozwiązanie
Pod RFC 2308 §5, negatywne odpowiedzi mogą być buforowane, podobnie jak pozytywne dane. Nowo dodany rekord może pozostać nieobecny w widoku rekurencyjnym do czasu wygaśnięcia wcześniejszego negatywnego stanu pamięci podręcznej. Różni się to od sytuacji, w której serwer autorytatywny jest nieosiągalny.
Wada konfiguracji może się również utrzymywać, podczas gdy zaobserwowany błąd pozostaje sklasyfikowany jako tymczasowy. „Tymczasowe” opisuje kategorię oceny, a nie obietnicę, że czekanie naprawi zepsutą delegację lub podpis.
Używać przewodnik po zaginionych rekordach za potwierdzoną nieobecność i przebieg publikacji aby zweryfikować rzeczywistą nazwę i uprawnienia.
Przed ponownym rozważeniem zasad zweryfikuj odzyskanie
Aktualny RFC 9989 §4.10.1 pozostawia obsługę błędów DNS związanych z wyszukiwaniem zasad odbiornikowi. Wytyczne dotyczące oceny w RFC 9989 §5.3.6 twierdzi, że wymagane zapytania DNS , które nie zostały ukończone z powodu błędów DNS nie potwierdzają pozytywnego lub negatywnego wyniku DMARC , a zasady oceny właściciela domeny nie mogą być stosowane w przypadku tego niekompletnego wyniku. Obsługa odbiornika może się nadal różnić.
Zmiana p nie naprawia nieosiągalnego wymaganego wyszukiwania. Najpierw przywróć użyteczną rozdzielczość, a następnie przetestuj ponownie tę samą trasę i sprawdź nowe wyniki specyficzne dla metody. Zachowaj wszelkie decyzje dotyczące odzyskiwania działalności jako odrębną zmianę o określonym zakresie.
Ostateczny zapis powinien określać uszkodzoną zależność, ustaloną przyczynę, naprawę i dowód odbiorcy po odzyskaniu. Dzięki temu łatwiej jest zdiagnozować kolejną sporadyczną awarię bez odruchowego osłabiania działającej polityki.
Trzymaj decyzję i dowody oddzielnie
W przypadku fikcyjnej transkrypcji 14:02–14:09 sukces autorytetu zawęża się, ale nie identyfikuje uszkodzonego elementu. Wymagaj faktycznego ustalenia mechanizmu rozpoznawania nazw lub sieci przed podaniem nazwy DNSSEC , transportu lub konkretnego serwera jako przyczyny. RFC 8767 §4 pozwala na kwalifikujące się użycie nieaktualnych odpowiedzi; sama świeżość nie jest uniwersalnym zegarem przestoju lub odzyskiwania. Obserwacje te są wymyślonymi elementami nauczania, a nie przeprowadzanymi testami.