Zamień wyszukiwanie w precyzyjne pytanie
Użyj funkcji dig, aby zapytać nazwany serwer DNS o dokładnego właściciela i typ rekordu, a następnie zachowaj wystarczający kontekst, aby zinterpretować odpowiedź. W przypadku uwierzytelniania poczty e-mail rzadko pojawia się pytanie, czy domena je posiada Rekordy TXT. Chodzi o to, czy zależność używana przez nadawcę lub weryfikatora istnieje pod poprawną nazwą i może zostać rozwiązana poprzez odpowiednią ścieżkę.
Przykłady w tym przewodniku dotyczą udokumentowanej składni ISC BIND 9.20.13 dig. Jest to przypięty zakres dokumentacji, a nie twierdzenie, że każdy zainstalowany wykop ma tę wersję lub że jest to najnowsza wersja. Do wszystkich poleceń proponowane są zapytania DNS tylko do odczytu lub sprawdzenie wersji lokalnej. Żaden nie został tu stracony. Nazwy example.com i adresy 192.0.2.0/24 są obiektami zastępczymi dokumentacji, a nie działającą konfiguracją programu rozpoznawania nazw.
Zacznij od tożsamości, której faktycznie używa poczta e-mail
Dla SPF, zidentyfikuj domenę używaną w odpowiedniej tożsamości SMTP , zamiast automatycznie używać widocznej domeny Od. Dla DKIM, weź domenę podpisującą i selektor z podpisu wiadomości. Właściciel wyszukiwania klucza łączy selektor, _domainkey i podpisanie domeny. Nie zgaduj selektora na podstawie nazwy dostawcy. RFC 7208 RFC 6376
Wyszukiwanie _dmarc.example.com. może sprawdzić historię polisy tego właściciela. Nie jest to samo w sobie pełna implementacja odkrywania zasad lub wyrównanie ocena. Podczas przekazywania wyników specjalistom ds. poczty zachowaj tożsamość wiadomości i odpowiedni kontekst wykrywania zasad. Widoczność DNS i wynik uwierzytelnienia należą do powiązanych, ale odrębnych pól dowodów. RFC 9989
Napisz arkusz pytań, podając właściciela, typ, powód zapytania i oczekiwane uprawnienia. To niewielkie przygotowanie uniemożliwia zaakceptowanie atrakcyjnie wyglądającej odpowiedzi dla niewłaściwej domeny jako poprawki. Końcowa kropka powoduje, że nazwy przykładów są wyraźnymi bezwzględnymi nazwami DNS .
Spraw, aby początkowe zapytanie było odtwarzalne
Proponowane polecenie lokalne kopać -v rejestruje wersję narzędzia. Aby uzyskać kontrolowany kształt zapytania, użyj dig -r @ 192.0.2.53 _dmarc.example.com . TXT. The -r opcja pozwala uniknąć domyślnych ustawień wyszukiwania dla poszczególnych użytkowników, podczas gdy argument serwera identyfikuje serwer DNS . Zastąp oba symbole zastępcze tylko w przypadku oddzielnie autoryzowanego wyszukiwania. Zachowaj cały wynik przed wykonaniem zwartego ekstraktu. Podręcznik kopania ISC
Zapisz czas UTC, kontekst sieci źródłowej i serwer faktycznie zgłoszony w wyniku. Unikaj zaczynania od polecenia, które ukrywa wszystko oprócz odpowiedzi. Krótki widok zawierający tylko odpowiedź może być później wygodny, ale początkowy dowód powinien zawierać sekcje pytań, statusu, flag, odpowiedzi i uprawnień, a także komunikaty związane z transportem. Te szczegóły odróżniają nieobecność, skierowanie i porażkę.
Sugerowane pytania towarzyszące to dig -r @ 192.0.2.53 example.com . TXT I dig -r @ 192.0.2.53 selector1._domainkey.example.com . TXT. Są to przykłady składni, a nie twierdzenie, że którakolwiek nazwa ma zapis uwierzytelniający. Wybierz rzeczywiste nazwy z zatwierdzonego dochodzenia i nigdy nie traktuj ŻADNEGO zapytania jako gwarantowanego spisu wszystkiego w strefie.
Porównaj obserwacje rekurencyjne i autorytatywne
Najpierw ustal, o który serwer pytałeś. Rekurencyjny program rozpoznawania nazw może zwrócić dane z pamięci podręcznej; autorytatywny serwer odpowiada za strefy, które obsługuje. Dla porównania z oddzielnie zweryfikowanym organem, proponowana forma to dig -r @ 192.0.2.54 _dmarc.example.com . TXT +norekurs. Wyłączenie rekurencji nie powoduje, że dowolny serwer jest autorytatywny. Zamiast ufać samemu wybranemu adresowi IP, sprawdź odpowiedź i dowód delegowania. RFC 1034
Jeśli wyniki rekurencyjne i autorytatywne nie są zgodne, zachowaj oba. Porównaj nazwy, typy, wartości, status odpowiedzi i znaczniki czasu, zanim zrzucisz winę na propagację. Zmniejszający się buforowany TTL ma charakter informacyjny, ale nie jest uniwersalnym terminem wygaśnięcia dla każdego obserwatora. Ujemny wpis w pamięci podręcznej również podlega swoim własnym regułom. RFC 2308
Przeczytaj odpowiedź strukturalnie. Do jednego rekordu zasobu TXT może należeć kilka ciągów znaków w cudzysłowie; kilka rekordów zasobów TXT to inny stan. Nie spłaszczaj obu formularzy w jeden ciąg oddzielony spacjami. Zachowaj granice rekordów, zanim specjalista ds. poczty oceni składnię SPF lub DKIM . A CNAME wprowadza inną nazwę do zbadania, zamiast udowadniać, że dostępny jest ostateczny klucz lub tekst zasad. RFC 1035
Delegowanie śledzenia tylko wtedy, gdy o to chodzi
Proponowane zapytanie dig -r +trace example.com . NS podąża za poleceniami z katalogu głównego. Wysyła wiele zapytań sieciowych, więc odpowiednio zatwierdź zakres diagnostyczny. Dodanie argumentu serwera nie powoduje ograniczenia całego śledzenia do tego mechanizmu rozpoznawania nazw. Śledzenie sprawdza delegację z sieci operatora; nie odtwarza każdej decyzji podjętej przez zdalnego odbiorcę poczty elektronicznej. Podręcznik kopania ISC
Przeglądając ślad, zidentyfikuj ostatnie pomyślne skierowanie, serwery, z którymi się skontaktowano oraz miejsce, w którym zatrzymano rozpoznawanie. Przerwa w jednym etapie nie oznacza pozwolenia na edycję serwery nazw. Porównaj wynik z inwentarzem rejestratora i właściciela DNS , a następnie przypisz kolejne dochodzenie odpowiedniemu właścicielowi. Unikaj przekształcania jednego niekompletnego śladu w zalecenie migracji.
Ogranicz roszczenia dotyczące niepowodzeń i walidacji
NXDOMAIN , pomyślna odpowiedź bez żądanych danych i SERVFAIL wymagają innych kolejnych kroków. Nie tłumacz wszystkich trzech na brakujące rekordy uwierzytelniające. Jeżeli podejrzewa się transport, proponuje się +tcp porównanie może pomóc w rozdzieleniu ścieżek, ale sukces w jednym transporcie nie dowodzi, że każdy odbiorca może rozwiązać rekord. RFC 1035 RFC 7766
Kopanie +dnssec żądania opcji DNSSEC tworzywo; jego obecność nie jest samodzielnym wynikiem weryfikacji kryptograficznej. Powiąż wnioski z walidacji z odpowiednim zachowaniem mechanizmu rozpoznawania nazw i zaufanymi dowodami. Zakończ dochodzenie zwięzłym stwierdzeniem, który serwer odpowiedział na jakie pytanie, kiedy i co pozostaje niepewne. Nadal brakuje autorytatywnych i rekursywnych transkrypcji wymaganych w tym artykule ze znacznikiem czasu; te proponowane polecenia nie zastępują ich.