Jakiś domena organizacyjna jest granicą używaną w DMARC przetwarzanie. Pomaga odbiorcy znaleźć politykę, gdy widoczna domena From nie ma własnego rekordu, i pomaga porównywać uwierzytelnione tożsamości w swobodnej atmosferze wyrównanie. Są to powiązane operacje, ale nie dotyczą tego samego pytania.
Skrót „weź dwie ostatnie etykiety” jest zawodny. Nazwa pod wieloczęściowym sufiksem publicznym, takim jak co.uk , już pokazuje, dlaczego po policzeniu dwóch etykiet można wybrać sufiks zamiast organizacji. Obecna specyfikacja dodaje kolejny powód, aby unikać skrótów: RFC 9989 definiuje przechodzenie po drzewie DNS zamiast polegania na a publiczna lista sufiksów sam.
Zapisz trzy pytania osobno
Zacznij od rzeczywistej domeny w adresie Od wiadomości, zwanej domeną autora. Następnie zapytaj:
- Który zapis zasad DMARC ma zastosowanie do tej domeny autora?
- Jaką domenę organizacyjną ustala odpowiedni proces odkrywania dla każdej porównywanej tożsamości?
- Czy przemija SPF Lub DKIM tożsamość spełnia wybrany tryb wyrównania?
Prawidłowy rekord bezpośrednio w domenie autora wygrywa wybór zasad. Nie oznacza to automatycznie, że domena autora jest domeną organizacyjną używaną do swobodnego dostosowania. Potraktuj moduł sprawdzający DNS , który wyświetla tylko jedno pole „domena” jako widok początkowy i zbierz rzeczywiste nazwy i odpowiedzi potrzebne do wyjaśnienia jego wniosków.
The przewodnik po łańcuchu tożsamości pomaga zidentyfikować domeny Od, kopertę i DKIM przed rozpoczęciem wykrywania.
Postępuj zgodnie z oznaczonym przykładem
Poniżej znajduje się syntetyczna migawka DNS . Ilustruje fikcyjny rejestr w zarezerwowanej przestrzeni nazw .example; nie jest to wynik zapytania na żywo ani stwierdzenie dotyczące jakiegokolwiek prawdziwego publicznego sufiksu.
Załóżmy, że istniejąca domena autora to invoice.harbour.registry.example . Jej przesłanie ma swoją przeszłość Podpis DKIM z d=sign.harbour.registry.example. SPF przekazuje oddzielną domenę usługi, która nie jest wyrównana.
| Cel zapytania | Przykładowa odpowiedź | Konsekwencja |
|---|---|---|
| _dmarc.invoice.harbour.registry.example | Brak zapisów zasad DMARC | Kontynuuj odkrywanie |
| _dmarc.harbour.registry.example | v=DMARC1; p=none; sp=quarantine; psd=n | Ustal tę wyraźną granicę organizacyjną i przerwij marsz |
| _dmarc.registry.example | Nie pytano po przystanku | Ten spacer nie wymaga dalszej reakcji |
Wybrana polityka jest rekordem w harbour.registry.example . Ponieważ invoice.harbour.registry.example istnieje i jest subdomeną, jej obowiązującą polityką oceny jest kwarantanna przez sp. Domena organizacyjna to harbour.registry.example , ponieważ rekord wyraźnie sygnalizuje psd=n.
W przypadku tożsamości DKIM ilustracyjne wyszukiwanie w _dmarc.sign.harbour.registry.example nie zwraca żadnego rekordu, po którym następuje ten sam rekord granicy psd=n . Dlatego uwierzytelniona tożsamość podpisująca i domena autora współdzielą domenę organizacyjną. Dzięki luźnemu wyrównaniu DKIM ten przekazujący podpis DKIM zapewnia wyrównaną ścieżkę. Ścisłe wyrównanie wymagałoby dokładnej równości tożsamości, której nie mają te dwie różne nazwy.
W przykładzie celowo widać, że wybór zasad, odkrycie granic, uwierzytelnianie i dopasowanie są widoczne jako osobne wyniki. Zmiana wartości zasad nie spowoduje przekształcenia nierównych ciągów domeny w dokładne dopasowanie.
Zrozum, co zatrzymuje spacer
RFC 9989 sekcja 4.10, określa zapytania, filtrowanie rekordów i limity. Prawidłowy rekord z psd=n identyfikuje granicę organizacyjną. Prawidłowy rekord z psd=y identyfikuje granicę publicznego sufiksu, przy czym zasady wyboru domeny organizacyjnej uwzględniają, w stosownych przypadkach, etykietę domeny pierwszą poniżej.
Jeśli żaden sygnał nie rozwiązuje granicy, specyfikacja zapewnia zasady wyboru i zasady awaryjne. Ogranicza także wykrywanie długich nazw, aby uniknąć wymuszania przez osobę atakującą nieograniczonej liczby wyszukiwań. Implementacja produkcyjna wymaga pełnego algorytmu, w tym nieprawidłowych lub wielu rekordów i błędów DNS ; usuwanie etykiet do czasu pojawienia się znajomej nazwy nie jest substytutem.
Nie kopiuj psd=y do rejestru zwykłej organizacji. Opisuje rolę przyrostka. psd=n może obsługiwać zamierzone granice organizacyjne, w tym delegowane poddrzewa, ale powinno być zgodne z udokumentowaną decyzją dotyczącą przestrzeni nazw, a nie uniwersalną listą kontrolną.
Zbadaj różnice między narzędziami i odbiornikami
Starsza implementacja może wykorzystywać podejście z sufiksem publicznym powiązane z RFC 7489. Nowsza implementacja może być zgodna z chodzeniem po drzewach RFC 9989 . Odpowiedzi DNS , pamięci podręczne i wsparcie wdrożeniowe mogą zatem mieć znaczenie, gdy wyniki nie są zgodne.
Aby uzyskać przydatne porównanie, zachowaj pełne nazwy tożsamości, odpowiedzi na zapytania ze znacznikami czasu, wykryty rekord zasad, ustawienia dopasowania i wynik odbiorcy. Zapytaj dostawcę narzędzia, jaki model wykrywania wdraża. Nie wnioskuj o powszechnym przyjęciu na podstawie daty publikacji ani nie zmieniaj DNS wyłącznie po to, aby dwie etykiety pulpitu nawigacyjnego były zgodne.
Oddziel prawdziwą różnicę granic od prostego problemu z uwierzytelnianiem. Brakujący podpis DKIM , błędny podpis lub niezatwierdzona trasa wysyłki nie będą ważne, ponieważ obliczenie domeny organizacyjnej zostanie poprawione.
Uczyń granicę rekordem operacyjnym
W przypadku domen z kilkoma jednostkami biznesowymi lub delegowanymi zespołami DNS zapisz, kto może publikować w ramach każdej granicy i jakie usługi mogą tam uwierzytelniać pocztę. Sprawdź ponownie ten rekord, gdy aplikacja uzyska subdomenę, jednostka biznesowa zmieni zarządzanie DNS lub dostawca wycofa się.
Używać weryfikacja polityki subdomen aby sprawdzić, która polityka ma zastosowanie, oraz porównanie wyrównania przy podejmowaniu decyzji, jakie relacje domenowe są akceptowalne.
Przydatnym wynikiem jest powtarzalny łańcuch: były to tożsamości wiadomości, odpowiedzi DNS ustaliły odpowiednie granice, zastosowano tę zasadę i ta przekazana tożsamość była zgodna lub nie. Odgadnięta etykieta domeny nie może dostarczyć takiego dowodu.
Użyj karty decyzji granicznej
Użyj tej karty do wyboru domeny organizacyjnej, a nie zamiast odkrywania zasad. Najpierw sprawdź domenę autora pod kątem jej własnych zasad. Zasady bezpośrednie można zastosować nawet wtedy, gdy wyrównanie wymaga innego obliczenia granic.
| Obserwacja podczas wskazanego spaceru | Decyzja graniczna |
|---|---|
| Prawidłowy rekord zawiera psd=n | Zatrzymywać się; domena tego rekordu jest domeną organizacyjną. |
| Prawidłowy rekord zawiera psd=y poza domeną początkową | Zatrzymywać się; wybierz etykietę domeny pierwszą poniżej tego publicznego sufiksu. |
| psd=y is at the starting domain | Chód zatrzymuje się, ale zasada „jedna etykieta poniżej” nie ma zastosowania do tego rekordu startowego. Zastosuj reguły wyboru, zamiast wymyślać domenę podrzędną. |
| Istnieją ważne zapisy bez decydującego sygnału granicznego | Wybierz prawidłowy rekord przy nazwie z najmniejszą liczbą etykiet. Nie wybieraj automatycznie pierwszego rekordu nadrzędnego. |
| Nie określono domeny organizacyjnej | Użyj początkowej domeny docelowej jako domeny organizacyjnej. Ta rezerwa nie tworzy rekordu zasad. |
| Nazwa podmiotu ma wiele etykiet | Zastosuj ograniczenie ośmiu zapytań: zachowaj początkowe zapytanie, a następnie skróć zgodnie z opisem. Nie odpytuj każdego przodka o dowolnie długim imieniu. |
Te wiersze podsumowują RFC 9989 sekcje 4.10–4.10.2; nadal obowiązuje filtrowanie rekordów i obsługa błędów DNS. Podczas wykrywania zasad nie znaleziono żadnych zasad, co oznacza, że DMARC nie ma zastosowania, mimo że algorytm wyrównywania ma rezerwę graniczną.
Jako drugi fikcyjny ślad załóżmy, że spacer po a.mail.example.com znajdzie prawidłowe rekordy w mail.example.com i example.com , ani z psd=n ani psd=y, ani nigdzie indziej. Wybrana domena organizacyjna to example.com . Jeśli zamiast tego mail.example.com zasygnalizuje psd=n, spacer zatrzymuje się w tym miejscu i wygrywa ta bardziej konkretna granica. Zachowaj migawkę DNS z wynikiem, aby inny operator mógł odtworzyć porównanie.