DKIM weryfikacja polega na pobraniu publicznych materiałów weryfikacyjnych poprzez DNS . Podpis może być dobrze skonstruowany pod względem kryptograficznym, ale pozostać niemożliwy do zweryfikowania, gdy odpowiednie wyszukiwanie jest niedostępne. Przed wymianą kluczy lub zmianą treści wiadomości sprawdź ścieżkę DNS i czas próby odbiorcy.
Pomyślne wyszukiwanie po incydencie jest użytecznym dowodem na odzyskanie danych, ale nie pozwala ustalić, co wydarzyło się podczas nieudanej próby. Zachowaj oryginalny wynik uwierzytelnienia, komunikat, znacznik czasu i wszelkie dostępne dzienniki rozpoznawania nazw. Celem jest wyjaśnienie zaobserwowanej awarii bez żądania wglądu w infrastrukturę odbiornika, której nie posiadasz.
Ustal dokładne wyszukiwanie i wynik
Przeczytaj d i s od dotkniętych DKIM-Signature i skonstruować selektor wyszukaj pod _domainkey of d. Pod RFC 6376 §3.6.2.1 I RFC 1034 §3.6.2, jeśli obsługiwana konfiguracja wykorzystuje plik a CNAME, przechwyć łańcuch i ostateczną odpowiedź weryfikacyjną. Dołącz kod odpowiedzi, czas, narzędzie do rozpoznawania nazw i serwer autorytatywny, jeśli jest dostępny.
RFC 6376 §6.1.2 odróżnia zapytanie, które nie odpowiada, od rekordu klucza, który nie istnieje. Pierwsza może dać TEMPFAIL i późniejszą próbę; ten ostatni wymaga dla tego podpisu PERMFAIL bez klucza. RFC 8601 §2.7.1 temperror podobnie opisuje prawdopodobny przejściowy błąd weryfikacji. Nie zamieniaj wszystkich awarii związanych z DNS w jedną diagnozę braku rekordu.
Porównuj poglądy, nie wyolbrzymiając ich
Sprawdź strefę autorytatywną i reprezentatywne rekurencyjne mechanizmy rozpoznawania nazw. Różnica może wskazywać na nieaktualne dane w pamięci podręcznej, niespójności delegowania lub problem z dotarciem do części ścieżki DNS . Jeśli dotyczy to celu zarządzanego przez dostawcę, sprawdź ten cel, a także alias kontrolowany przez klienta.
Zapisz dowody potencjalnych przyczyn, zamiast wybierać jedną z samej etykiety błędu. Na przykład SERVFAIL mechanizmu rozpoznawania nazw wymaga dalszej diagnostyki; nie stanowi dowodu na to, że klucz został usunięty. DNSSEC walidacja (patrz RFC 4035 §5.5), problemy z delegowaniem i transportem mogą wymagać logów i wiedzy operatora DNS . Nie wyłączaj sprawdzania poprawności jako domyślnej poprawki tylko po to, aby jedno wyszukiwanie zakończyło się sukcesem.
Postępuj zgodnie z przykładem opartym na czasie
Przykładowa sekwencja: odbiorca próbuje pobrać active1._domainkey.sender.example o godzinie 10:00 i zgłasza tymczasowy błąd odzyskania klucza. O 10:05 administrator pobiera ważny klucz z innego mechanizmu rozpoznawania nazw. Obie obserwacje mogą być prawdziwe. Drugi określa dostępność dla tego zapytania o godzinie 10:05, a nie dostępność dla pierwszego odbiorcy pięć minut wcześniej.
Z drugiej strony, jeśli autorytatywna odpowiedź w momencie zdarzenia ustali, że aktywny selektor jest nieobecny, oczekiwanie na usunięcie przejściowej awarii może nie rozwiązać problemu z konfiguracją. Jeśli rekord zostanie przywrócony, ujemne buforowanie poniżej RFC 2308 §5 może również mieć wpływ, gdy inne metody rozpoznawania go zaobserwują. Przykładem jest harmonogram diagnostyki, a nie zmierzony przestój lub obiecany okres odzyskiwania.
Sprawdź resztę weryfikacji po odzyskaniu
Następny RFC 6376 §6.1.2 I RFC 6376 §6.1.3, po odzyskaniu klucza potwierdź, że zwrócony rekord jest użyteczny i odpowiada podpisującemu. Odzyskany klucz może nadal zostać unieważniony, zniekształcony lub niezgodny. Dopasowany klucz nie może kompensować treści zmodyfikowanej po podpisaniu. Zachowaj wyszukiwanie, sprawdzanie poprawności klucza, weryfikację skrótu treści i weryfikację podpisu jako osobne etapy w zapisie zdarzenia.
Jeśli istnieje kilka podpisów, jedno nieudane wyszukiwanie niekoniecznie powoduje usunięcie każdej dopasowanej ścieżki uwierzytelniania. Pod RFC 9989 §5.3.5, sprawdź pozostałe podpisy i SPF zanim to stwierdziłem DMARC przegrany. Pod RFC 6376 §6.3 I RFC 9989 §5.4, zasady dostarczania odbiorcy to kolejna odrębna decyzja; przejściowy problem DKIM nie gwarantuje ani odroczenia, ani akceptacji.
Zamknij awarię za pomocą kontrolowanych testów
Po autoryzowanej naprawie przez operatora DNS przetestuj wyszukiwanie, którego dotyczy problem, w odpowiednich widokach i wysyłaj nowe wiadomości oryginalną trasą. Zapisz oczekiwane i zaobserwowane wyniki. Poproś o dowody incydentu związanego DNS i dostawcą, jeśli przyczyna leży poza zakresem administracyjnym.
Prowadź spis delegowanych celów selektora i ich właścicieli, aby następny alert dotarł do odpowiedniego zespołu. Monitoruj zależność, która faktycznie zawiodła, ale uczciwie opisz zakres monitorowania: okresowe zapytanie publiczne nie odtwarza zachowania pamięci podręcznej, sieci lub sprawdzania poprawności każdego odbiorcy. Zamknięcie powinno określić, co odzyskano, jakie dowody potwierdzają diagnozę, a co pozostaje niezaobserwowane.
Zachowaj ograniczony wniosek
Zachowaj niepowodzenie o godzinie 10:00 i sukces o godzinie 10:05 jako dwa rekordy, każdy z funkcją rozpoznawania nazw, nazwą zapytania, wynikiem i limitami widoczności. Pięciominutowa przerwa ma charakter poglądowy, a nie cel odbudowy. DNS TTL to interwał świeżości, a nie globalny termin unieważnienia: RFC 8767 §4 pozwala na kwalifikujące się nieaktualne użycie. Nie zmierzono żadnych awarii resolwera, odzyskiwania ani testów poczty.