Monitor DNS , który sprawdza tylko, czy domena została rozwiązana, może nie zostać usunięta Selektor DKIM lub uszkodzony SPF zależność. Zacznij od rekordów, z których korzystają prawdziwe ścieżki pocztowe. Monitorowanie dostępności powinno raportować, o co zapytano, skąd i która oczekiwana właściwość nie powiodła się, a nie tylko o tym, że DNS jest w złej kondycji.
Zbuduj wyraźny docelowy asortyment
Referencje: RFC 6376 §3.1, RFC 7208 §4.4.
Lista domen autorów, domen kopert, aktywnych selektorów i nazw zasad używanych przez każdą usługę wysyłającą. Uwzględnij zależności osiągane poprzez aliasy i mechanizmy SPF . Dodaj nazwy zasad transportu podczas monitorowania bezpieczeństwa odbierania. Zwykłe zapytania DNS nie są w stanie wykryć każdego selektora, dlatego należy uzyskać aktywny zestaw z konfiguracji usługi i reprezentatywnych podpisanych wiadomości.
Dla każdego celu należy podać właściciela rekordu, typ, oczekiwany kształt lub zatwierdzoną wartość, właściciela odpowiedzialnego i okno zmiany. Unikaj zakładania, że każda wartość musi na zawsze pozostać taka sama w bajtach: planowana rotacja klucza powoduje legalną zmianę danych. Wprowadź oczekiwane wartości i odróżnij niezatwierdzoną zmianę od zatwierdzonego przejścia.
Sprawdzaj autorytet i rekurencję oddzielnie
Referencje: RFC 1035 §4.1.1, RFC 2308 §2.2, RFC 4035 §5.5.
Bezpośrednie wiarygodne zapytanie pomaga ustalić, co obsługuje dana strefa. Zapytanie rekurencyjne reprezentuje efektywny widok jednego mechanizmu rozpoznawania nazw, w tym pamięci podręczne i zachowanie podczas sprawdzania poprawności. Zachowaj czas zapytania, adres serwera, kod odpowiedzi, flagi, rekordy odpowiedzi i kontekst TTL dla obu. Korzystaj z wielu odpowiednich punktów obserwacyjnych tam, gdzie wymaga tego usługa, bez twierdzenia, że kilka sond obejmuje każdy odbiornik.
Rozróżnij NXDOMAIN , istniejącą nazwę bez żądanego typu, SERVFAIL , przekroczenie limitu czasu i pomyślną, ale niepoprawną odpowiedź. A DNSSEC problem może skutkować awarią sprawdzającego mechanizmu rozpoznawania nazw, nawet jeśli autorytatywny serwer zwróci rekord. Flaga autorytatywnej odpowiedzi nie jest dowodem na to, że odpowiedź została zweryfikowana kryptograficznie.
Powiadom o decyzji, która nastąpi
Brakujący aktywny selektor wymaga innej reakcji niż krótki limit czasu na jednym monitorze. Grupuj powiązane awarie zależności, aby jeden niedostępny organ nie tworzył setek niepowiązanych zgłoszeń. Korzystaj z kolejnych obserwacji i niezależnych ścieżek, aby zredukować szumy, zachowując jednocześnie czas pierwszej awarii i surowe wyniki. Progi to lokalne wybory operacyjne, a nie wymagania uniwersalnego protokołu DNS .
Nie zastępuj automatycznie rekordów ani nie wyłączaj egzekwowania tylko dlatego, że sonda się nie powiedzie. Najpierw sprawdź, czy monitor zapytał o poprawną nazwę i aktualne uprawnienia. Przekaż ustalenia właścicielowi rekordu powiązanego z usługą, której dotyczy problem, załącz ostatnią dobrą obserwację i dowód dokładnej zmiany lub warunku reakcji.
Odtwórz trzy różne obserwacje
Lokalne urządzenie klasyfikuje oczekiwany znacznik selektora zwrócony z wartością NOERROR jako obecny, odpowiedź NXDOMAIN jako brak nazwy, a odpowiedź SERVFAIL jako błąd rozdzielczości. Następnie pokazuje, że NOERROR z innym znacznikiem oznacza niezgodność treści, a nie awarię. Markery są syntetyczne i takie nie są DKIM klawiatura.
Uruchom dołączony skrypt, aby odtworzyć klasyfikację. Zużywa obiekty urządzeń zamiast wysyłać pakiety. Aby zweryfikować wdrożony monitor, prześlij zapytanie do izolowanej autoryzowanej strefy z tymi samymi przypadkami i zachowaj rzeczywiste odpowiedzi na przewody, pomiary przekroczeń limitu czasu i dowód dostarczenia alertu. Tutaj nie przeprowadzono tych testów na żywo.
Zamknąć pętlę monitorowania
Referencje: RFC 2308 §5, RFC 6376 §6.
Po naprawie porównaj każdy przetestowany wiarygodny punkt końcowy, a następnie obserwuj odzyskiwanie rekurencyjne i reprezentatywny komunikat po autoryzacji. Odpowiedzi negatywne mogą pozostać w pamięci podręcznej po zwróceniu rekordu. Nie usuwaj zdarzenia tylko dlatego, że późniejsze wyszukiwanie zakończyło się sukcesem.
Przejrzyj zasoby po wprowadzeniu nadawcy, rotacji selektora, migracji domeny i wycofaniu się. Obserwacje DNS ustalają wymaganą dostępność w danym momencie. Nie mogą sami wykazać ważności Podpis DKIM, DMARC wyrównanie, akceptacja skrzynki pocztowej lub umieszczenie skrzynki odbiorczej.
Zachowane historyczne dowody drutowe
Poniżej opisano przechwycenie pętli zwrotnej zachowane w dniu 7 listopada 2026 r., sprawdzone, ale nie uruchomione ponownie w ramach eksperymentu sieciowego na potrzeby tego przeglądu. Nowe kontrole modelu offline są rejestrowane osobno.
Zachowane przechwytywanie połączeń rejestruje rzeczywiste pytania UDP kierowane do minimalnego organu odpowiedzialnego za pętlę zwrotną. Zachowuje właściciela, typ, punkt końcowy, czas obserwacji UTC, bajty zapytań i odpowiedzi, flagi, kontekst TTL i SOA. Powstałe gałęzie to: NOERROR z obecnymi oczekiwanymi średnimi TXT ; NOERROR bez AAAA na istniejącym wierzchołku oznacza brak żądanych danych; NXDOMAIN dla absent.example .test oznacza brak nazwy; SERVFAIL oznacza błąd rozdzielczości; celowo pytanie bez odpowiedzi powoduje przekroczenie limitu czasu klienta. Serwer skryptuje te odpowiedzi, ale pakiety i przekroczenie limitu czasu są faktycznie przestrzegane. Testuje to drzewo decyzyjne, a nie zachowanie monitora komercyjnego lub dostarczanie alertów.