Klasyfikuj wynik DNS przed zmianą uwierzytelniania
“DKIM brak rekordu” może opisywać kilka różnych sytuacji: selektor nazwa nie istnieje, nazwa nie nadaje się do użytku Rekord TXT, brakuje docelowego aliasu lub mechanizm rozpoznawania nazw nie mógł uzyskać odpowiedzi. Warunki te wymagają różnych badań. Traktowanie każdego nieudanego wyszukiwania jako nieobecności może wysłać zgłoszenie do niewłaściwego operatora i niepotrzebnie zachęcić SPF Lub DMARC zmiany.
Zacznij od sprawdzenia dokładnej tożsamości. Dla Podpis DKIMskonstruuj zapytanie na podstawie jego rzeczywistej domeny selektora i podpisu. Wyszukiwanie selektora z zeszłego miesiąca niewiele mówi o wiadomości podpisanej z selektorem z tego miesiąca. Zapisz całą odpowiedź, a nie tylko puste pole wyjściowe. RFC 6376 , sekcje 3.6.2 i 6.1.2.
Następująca sekwencja decyzyjna jest proponowaną metodą diagnostyczną. W jego przykładach wykorzystano fikcyjne nazwy i wyniki; nie jest jeszcze wspierany przez oryginalne transkrypcje zapytań na żywo.
Oddział pierwszy: czy nadeszła użyteczna odpowiedź DNS ?
Limit czasu oznacza, że klient nie otrzymał odpowiedzi w okresie oczekiwania. Nie jest to kod odpowiedzi DNS i nie dowodzi NXDOMAIN . Zapisz adres docelowy, transport, czas i odpowiedź innych zatwierdzonych punktów końcowych. Odmowa różni się także od nieobecności: REFUSED oznacza, że serwer odrzucił operację. RFC 1035 , sekcja 4.1.1.
Sprawdź obcięcie i transport tam, gdzie wskazują na to dowody. Odpowiedź UDP z ustawioną flagą TC może wymagać ponownej próby protokołu TCP, a implementacje DNS muszą obsługiwać protokół TCP. Opublikowany klucz może pozostać niedostępny poprzez ścieżkę zakłócającą tę wymianę. Skorzystaj z proponowanego porównania, np wykop @SERWER_IP amber._domainkey.example.com . TXT +tcp, zachowując tego samego właściciela i punkt końcowy co wcześniejsze zapytanie. Żadne polecenie opisane w tym artykule nie zostało uruchomione. RFC 7766 , sekcje 5–6.
Eskaluj problem z transportem przechwyconych dowodów do operatora sieci lub DNS . Zmiana zawartości rekordu nie naprawi nieosiągalnej usługi. Nie wyłączaj kontroli bezpieczeństwa jako niewyjaśnionego skrótu do rozwiązywania problemów.
Oddział drugi: czy NXDOMAIN identyfikuje oczekiwaną nazwę?
NXDOMAIN jest odpowiedzią na błąd nazwy. Bez aliasu, dotyczy to zapytania o nazwę. Kiedy A CNAME występuje, błąd może dotyczyć ostatecznego celu, a nie pierwotnego właściciela. Przeczytaj łańcuch, zanim ogłosisz, że selektor klienta nigdy nie został opublikowany. RFC 2308 , sekcja 2.1.
W fikcyjnym przypadku amber._domainkey.example.com istnieje jako CNAME do amber.keys.example.net, ale cel nie istnieje. Publikacja po stronie klienta i cel po stronie dostawcy mają różne obowiązki. Proponowane kolejne działanie polega na potwierdzeniu wydanego celu u jego operatora i skierowaniu zapytania do odpowiednich organów. Usunięcie aliasu klienta wyłącznie dlatego, że odpowiedź rekurencyjna mówi, że NXDOMAIN odrzuci użyteczną konfigurację bez rozpoznawania rzeczywistej brakującej nazwy.
Porównaj także stan pamięci podręcznej. Autorytatywna odpowiedź pozytywna wraz ze starszą rekursywną domeną NXDOMAIN może wskazywać nieobecność w pamięci podręcznej. Zachowaj kontekst SOA i sygnaturę czasową negatywnej odpowiedzi oraz zbadaj niezgodę między władzami, zanim przypiszesz wszystko buforowaniu.
Oddział trzeci: czy NOERROR naprawdę oznacza NODATA ?
NOERROR nie zgłasza żadnego błędu DNS , ale nie gwarantuje obecności żądanych danych TXT . NODATA jest określana na podstawie treści odpowiedzi: brak istotnej odpowiedzi, z kontekstem władzy odróżniającym ją od skierowania. SOA w sekcji dotyczącej uprawnień lub brak skierowań do rejestru NS pomaga w dokonaniu tego rozróżnienia; aliasy mogą wymagać dalszych zapytań. RFC 2308 , sekcja 2.2.
Fikcyjna amber._domainkey.example.com może mieć Rekord ale bez klucza TXT . To inna naprawa niż zupełnie nieobecna nazwa. Inna odpowiedź może zawierać rekordy NS odsyłające klienta do delegowanej strefy podrzędnej; zatrzymanie się na tym odesłaniu błędnie oznaczyłoby niekompletne wyszukiwanie jako brakujące dane. Zachowaj dokładny żądany typ widoczny przez całą decyzję.
Jeśli istnieją odpowiednie dane TXT , sprawdź osobno składnię protokołu i granice rekordów. Sukces DNS nie gwarantuje prawidłowego klucza DKIM ani zasad SPF . Na etapie wyszukiwania rekordu SPF RFC 7208 rozróżnia zasady braku dopasowania od błędów DNS , takich jak przekroczenie limitu czasu lub awaria serwera. Nie spłaszczaj tych wyników w pojedynczej etykiecie niepowodzenia uwierzytelnienia. RFC 7208 , sekcje 4.4–4.5.
Oddział czwarty: zbadaj SERVFAIL bez zakładania nieobecności
SERVFAIL wskazuje, że serwer nie mógł pomyślnie przetworzyć zapytania. Możliwe przyczyny to: niedostępne uprawnienia, pętle delegacji lub aliasów oraz DNSSEC błędy walidacji. Jego znaczenie nie polega na „publikowaniu nowego rekordu TXT ”. Zachowaj wszelkie rozszerzone informacje o błędach, ale nie wnioskuj o unikalnej przyczynie na podstawie samego SERVFAIL . RFC 9520 , sekcja 2.
Porównaj odpowiednie autorytatywne serwery i rekurencyjny program rozpoznawania nazw, którego dotyczy problem. Pozytywna reakcja bezpośredniego organu może zawęzić problem, pozostawiając nierozwiązane różnice w walidacji i osiągalności. RFC 9520 wymaga również buforowania błędów, więc natychmiastowa powtarzająca się awaria nie musi oznaczać, że moduł rozpoznawania nazw powtarza każde zapytanie poprzedzające. RFC 9520 , sekcja 3.2.
Zamknij oddział z dowodami
Rekord zdarzenia powinien identyfikować selektor komunikatu lub inną tożsamość protokołu, właściciela/typ/klasę zapytania, czas UTC, punkt końcowy serwera, flagi, kod odpowiedzi, pełne sekcje i transport. Dołącz oryginalne dane wyjściowe do proponowanej decyzji dotyczącej oddziału. Podaj kolejnego odpowiedzialnego operatora i obserwację, która obaliłaby obecne wyjaśnienie.
Po korekcie powtórz odpowiednie porównanie DNS i przetestuj kontrolowaną wiadomość na dotkniętej trasie. Zgłaszaj dostępność DNS , weryfikację uwierzytelniania i dostawę jako osobne obserwacje. Oryginalne transkrypcje zapytań, niezależny przegląd techniczny i zatwierdzenie wydania pozostają otwarte dla tego kandydata na dokument; fikcyjne przykłady decyzji nie mogą ich zastąpić.