Wyszukiwanie uwierzytelnienia może zakończyć się niepowodzeniem, nawet jeśli panel sterowania DNS wyświetli oczekiwany wynik Rekord TXT. Osoba przeprowadzająca walidację musi także ustalić, czy odpowiedź jest godna zaufania. Złamany DNSSEC łańcuch może zatem zakłócać dostęp do SPF, DKIM lub dane dotyczące bezpieczeństwa transportu bez zmiany ich widocznego tekstu.
Oddziel objaw od przyczyny
Referencje: RFC 4035 §3.2.2, RFC 4035 §5.5.
Przechwyć dokładną nazwę właściciela, typ zapytania, funkcję rozpoznawania nazw, czas i odpowiedź. SERVFAIL sam w sobie nie jest diagnozą DNSSEC . Przekroczenia limitu czasu, nieosiągalne uprawnienia i inne awarie mechanizmu rozpoznawania nazw mogą spowodować powstanie tego samego kodu odpowiedzi. Porównaj normalne zapytanie sprawdzające z diagnostyką sprawdzającą z tego samego zaufanego mechanizmu rozpoznawania nazw i sprawdź łańcuch delegowania.
Zapytanie za pomocą wykop + dnssec żąda rekordów DNSSEC ; nie czyni to Dip kompletnym lokalnym walidatorem. Zapytanie z wyłączonym sprawdzaniem może pomóc w ujawnieniu danych, które zostały odrzucone podczas sprawdzania poprawności, ale odpowiedź uzyskana po pominięciu sprawdzania poprawności nie jest dowodem na to, że zależność produkcyjna jest w dobrym stanie. Trzymaj wynik diagnostyczny oddzielnie od wyniku zwykłej aplikacji.
Śledź rodzica i dziecko razem
Referencje: RFC 4035 §5, RFC 7208 §4.6.2, RFC 6376 §6.1.2, RFC 7672 §2.1.
Sprawdź nadrzędny DS, podrzędny klucz DNSKEY, podpisy obejmujące żądane rekordy i ich okresy ważności. Sprawdź zegar modułu sprawdzającego i konfigurację zaufania. Przestarzały nadrzędny DS po wymianie klucza, wygasłe podpisy lub niedostępne dane DNSKEY to różne usterki wymagające różnych napraw. Celowo niepodpisana delegacja z potwierdzonym dowodem braku DS jest niepewna i nie jest automatycznie fałszywa.
W przypadku wiadomości e-mail zapisz, co zrobiła implementacja, której dotyczy problem. Błąd DNS SPF może prowadzić do temperror; niepowodzenie wyszukiwania DKIM nie oznacza, że wiadomość została sfałszowana. SMTP DANE ma bardziej rygorystyczne konsekwencje transportowe, jeśli wymagane jest uwierzytelnienie TLSA danych nie można zweryfikować. Nie sprowadzaj tych wyników do uniwersalnego twierdzenia, że DNSSEC odrzuca całą pocztę.
Użyj kontrolowanego osprzętu do usuwania i naprawy
Referencje: RFC 4035 §5.2, RFC 6698 §2.1.
W hierarchii jednorazowej podpisz mailtest.example za pomocą klucza A i zainstaluj pasujący nadrzędny DS. Zapytaj o jego MX i _25._tcp.mx.mailtest.example TLSA za pośrednictwem walidatora zakotwiczonego w rodzicu testowym. Zapisz bezpieczną linię bazową, zestaw DNSKEY, DS i czasy podpisu. Zamień klucz podrzędny na B, celowo pozostawiając tylko DS A u rodzica. Oczekiwanym rezultatem jest nieudana weryfikacja, a nie nieszkodliwe przejście bez znaku.
Przywróć zgodny podpisany łańcuch i powtórz te same zapytania po uwzględnieniu delegacji w pamięci podręcznej i materiału klucza. Porównaj DER SubjectPublicKeyInfo SHA-256 certyfikatu z 3 1 1 Powiązanie TLSA osobno: pasujące bajty nie naprawiają uszkodzonego łańcucha DNS . Określa zachowanie modułu rozpoznawania nazw i SMTP ; poniższe zachowane kontrole kryptograficzne offline nie wykonują tych ścieżek sieciowych.
Zamknąć incydent ograniczonymi dowodami
Referencje: RFC 6781 §4.3.5.
Napraw faktyczny błąd łańcucha lub podpisu za pośrednictwem autoryzowanego operatora DNS . Nie usuwaj danych DS w ramach improwizowanego, uniwersalnego rozwiązania; zmienia to ochronę i ma konsekwencje zależne od pamięci podręcznej. Zachowaj odpowiedzi przed i po z autorytatywnych serwerów oraz odpowiednie ścieżki sprawdzania, a następnie przetestuj przepływ poczty, którego to dotyczy. Zamknięcie powinno informować, które nazwy zostały zweryfikowane i które testy poczty zakończyły się pomyślnie, wraz ze znacznikami czasu i pozostałymi limitami zasięgu.
Zachowane izolowane dowody walidacyjne
Referencje: RFC 4035 §5.
Laboratorium syntetyczne zachowane 7 listopada 2026 r., sprawdzone, ale nie uruchomione ponownie na potrzeby tej recenzji, przeprowadziło kontrole kryptograficzne dnspython 2.9.2 względem przypiętego nadrzędnego testowego klucza DNSKEY. Zweryfikował nadrzędne podpisy DNSKEY i DS, dopasował podrzędny DNSKEY do uwierzytelnionego DS i zweryfikował podrzędne podpisy DNSKEY i TLSA. Zatwierdzono zgodną linię bazową i przywrócony łańcuch. Tylko nowy klucz podrzędny w starym nadrzędnym DS nie został jawnie dopasowany do DS. Ślad zachowuje DS, DNSKEY, RRSIG, epokę walidacji i każdą kontrolę. Jest to weryfikacja podpisanego łańcucha w trybie offline, a nie śledzenie SERVFAIL rekursywnego mechanizmu rozpoznawania nazw lub awaria poczty na żywo. Lokalne porównania kluczy certyfikatów są zachowywane oddzielnie; produkcja i wyniki SMTP pozostają niesprawdzone.