DNSSEC dodaje uwierzytelnianie pochodzenia i integralność do danych DNS , gdy walidator może ustanowić łańcuch zaufania. Nie szyfruje odpowiedzi DNS , nie zatwierdza usługi wysyłania ani nie uwierzytelnia treści wiadomości. Jego wartość dla poczty e-mail wynika z ochrony zależności DNS , co ma konsekwencje dla dostępności w przypadku przerwania łańcucha sprawdzania poprawności.
Zweryfikuj łańcuch, a nie obecność podpisu
Referencje: RFC 4033 §3, RFC 4035 §5.
Podpisana odpowiedź zawiera materiał kryptograficzny, ale sama obecność RRSIG nie oznacza pomyślnej weryfikacji. Walidator potrzebuje zaufanego punktu początkowego, odpowiedniego klucza DNS i informacji o delegowaniu, użytecznych podpisów i prawidłowego czasu. Dane nadrzędne DS i klucze podrzędne muszą pozostać skoordynowane podczas zmian.
Użyj sprawdzającego mechanizmu rozpoznawania nazw lub diagnostyki umożliwiającej weryfikację ze znaną konfiguracją zaufania. Jeśli aplikacja opiera się na wskazaniu danych uwierzytelnionych przez mechanizm rozpoznawania nazw, ścieżka i relacja zaufania do tego mechanizmu rozpoznawania nazw mają znaczenie. Samo żądanie rekordów DNSSEC za pomocą narzędzia nie powoduje ich sprawdzenia przez narzędzie, a flaga autorytatywnej odpowiedzi nie jest wynikiem sprawdzania poprawności DNSSEC .
Zachowaj oddzielne stany walidacji
Referencje: RFC 4035 §4.3, RFC 7672 §2.1.
Bezpieczny wynik ma zweryfikowany łańcuch zaufania dla zwracanych danych. Niepewnym wynikiem może być legalna, niepodpisana gałąź i nie jest to równoznaczne z wykrytym fałszerstwem. Fałszywy wynik oznacza, że oczekiwana weryfikacja nie powiodła się. Należy również rozróżnić wynik nieokreślony: RFC 4035 używa go, gdy mechanizm rozpoznawania nazw nie może określić, czy dane powinny zostać podpisane, ponieważ nie można uzyskać niezbędnych rekordów DNSSEC . RFC 7672 wykorzystuje znaczenie RFC 4035 dla SMTP DANE i traktuje taki stan jako porażkę, zamiast milczeć jako niepodpisany. Zachowaj kontekst diagnostyczny, ponieważ RFC 4033 opisuje nieokreślone inaczej.
Sprawdzający poprawność algorytm rozpoznawania nazw może zwrócić SERVFAIL w przypadku fałszywych danych, ale sam SERVFAIL nie diagnozuje DNSSEC : mogą to spowodować inne awarie DNS . Sprawdź diagnostykę walidacyjną, nadrzędny DS, podrzędny klucz DNSKEY, podpisy i czas. Nie wyłączaj sprawdzania poprawności jako domyślnej naprawy, ponieważ powoduje to zmianę testowanej właściwości zaufania.
Odtwórz trzy różne zależności poczty
Referencje: RFC 4035 §5.2, RFC 4035 §5.4.
Syntetyczny przypadek A ma podpisaną strefę, pasujący nadrzędny DS i podrzędny klucz DNSKEY oraz aktualnie ważne podpisy dla kwestionowanego rekordu poczty. Oczekiwany wynik skonfigurowanego modułu sprawdzania poprawności jest bezpieczny. Przypadek B ma celowo niepodpisane dziecko z poświadczonym dowodem braku DS w swojej delegacji. Oczekiwany wynik jest niepewny, a nie fałszywy.
Przypadek C pozostawia stary DS u rodzica po wymianie klucza podrzędnego bez kompatybilnego przeniesienia. Oczekiwanym rezultatem jest przerwany łańcuch walidacji i, dla zdefiniowanego urządzenia sprawdzającego-rozwiązującego, SERVFAIL do zwykłego zapytania. Nieweryfikujące wyszukiwanie bezpośrednie może nadal wyświetlać TXT lub Rekord MX. Ta różnica nie dowodzi, że sprawdzający algorytm rozwiązywania problemów jest błędny.
Odtwórz te przypadki tylko w jednorazowej podpisanej hierarchii testów z własną kotwicą zaufania. Zachowaj nadrzędny DS, podrzędny klucz DNSKEY, rekord, którego dotyczy zapytanie, RRSIG, konfigurację programu rozpoznawania nazw, zegar i szczegółowy ślad sprawdzania poprawności. W każdym przypadku zapytaj tego samego właściciela i typ, a następnie porównaj stan tajny. Te scenariusze rekursywnego rozwiązywania problemów są specyfikacjami testowymi, a nie deklarowanym wdrożeniem strefy ze znakiem na żywo lub wykonaniem modułu sprawdzania poprawności rekurencyjnej. Późniejsza sekcja Przechwycone przypadki sprawdzania poprawności offline dokumentuje oddzielne, ograniczone urządzenie kryptograficzne przechwycone 7 listopada 2026 r.; nie zaobserwował SERVFAIL ani nie przetestował zintegrowanego SMTP DANE .
Zapoznaj się z dodatkowymi wymaganiami DANE
Referencje: RFC 7672 §2.2, RFC 7672 §3.
SMTP DANE wykorzystuje uwierzytelnianie DNSSEC TLSA stowarzyszenia i wsparcie nadawcy w celu uwierzytelnienia transportu. Samo podpisanie domeny nie powoduje utworzenia wymaganych rekordów TLSA ani nie zmusza każdego nadawcy do egzekwowania DANE . Ścieżka wykrywania MX i TLSA oraz powiązanie certyfikatu wymagają własnej weryfikacji zgodnie z RFC 7672 .
Przeniesienie certyfikatu lub klucza może przerwać dopasowanie TLSA, nawet jeśli DNSSEC pozostaje w dobrej kondycji. I odwrotnie, uszkodzony łańcuch DNSSEC może uniemożliwić nadawcy obsługującemu bezpieczne użycie prawidłowych danych TLSA. Zaplanuj obie warstwy razem i zachowaj kontrolowany test SMTP . Ani DANE , ani DNSSEC nie zastępują SPF, DKIM Lub DMARC.
Obsługuj podpisywanie jako utrzymywaną zależność
Referencje: RFC 6781 §4.1.
Rejestruj własność podpisywania, aktualizacji DS przez rejestratora, przekazywania kluczy i monitorowania. Przed zmianą dostawców DNS określ, czy klucze i łańcuch zostaną zachowane, czy przeniesione. Monitoruj ważność i weryfikację podpisów z odpowiednich ścieżek i żądaj dowodów odzyskiwania przed zamknięciem błędu. Zamiast twierdzić, że podpisany DNS zapewnia bezpieczeństwo wszystkich wiadomości e-mail, zgłaszaj dokładne zaobserwowane zachowania związane z zaufaniem DNS i pocztą.
Przechwycone przypadki sprawdzania poprawności offline
Referencje: RFC 4035 §5.
Zachowane przechwytywanie, sprawdzone, ale nie uruchomione ponownie na potrzeby tej recenzji, rejestruje, że izolowane urządzenie kryptograficzne zostało wykonane 7 listopada 2026 r. o 20:34:42 czasu UTC przy użyciu języka Python 3.12.14 i dnspython 2.9.2. Przypiął wygenerowany nadrzędny klucz DNSKEY, na przykład jako kotwicę zaufania laboratorium, wygenerował klucz podrzędny dla signed.example , podpisał DS dziecka kluczem nadrzędnym i podpisał test Rekord TXT z kluczem dziecięcym. Rzeczywiste sprawdzenie podpisu dla DS i TXT powiodło się, a obliczony DS SHA-256 był zgodny z kluczem DNSKEY dziecka. Przechwycony wynik był zweryfikowanym łańcuchem offline.
W przypadku zerwanego łańcucha urządzenie wygenerowało zastępczy klucz potomny, zachowując jednocześnie stary DS. Obliczony DS nie był już zgodny i urządzenie odrzuciło łańcuch. Nie uruchomił walidatora rekurencyjnego i nie zaobserwował SERVFAIL . W przypadku przypadku bez znaku zweryfikował NSEC podpisany przez rodzica w unsigned.example , którego mapa bitowa z dokładną nazwą zawierała NS i pominęła DS, a następnie sklasyfikowała to delegowanie jako niepewne. Ten wąski dowód nie implementuje ogólnego rozwiązania problemu zaprzeczenia istnieniu.
Aby odtworzyć, utwórz klucze nadrzędne i podrzędne ECDSA P-256, zbuduj rekordy DNSKEY i DS, podpisz DS i TXT z ograniczonymi czasami rozpoczęcia/wygaśnięcia i wywołaj operację sprawdzania poprawności DNSSEC dnspython względem przypiętych kluczy nadrzędnych i dopasowanych kluczy podrzędnych. Wymień klucz podrzędny w przypadku niezgodności. W przypadku przypadku bez znaku sprawdź poprawność podpisu NSEC dokładnego delegowania i sprawdź jego mapę bitową. Przechowuj publiczne rejestry kluczy, podpisy, czas sprawdzania poprawności, wersje zależności i wyniki; przechowuj testowe klucze prywatne w jednorazowym użytku. Dowody wskazują na rzeczywiste lokalne operacje kryptograficzne, a nie na weryfikację publicznego DNS , produkcyjne SMTP DANE lub wdrożony rekurencyjny program rozpoznawania nazw.