Zacznij od tożsamości, którą odbiorca sprawdzi
Zmiana uwierzytelnienia poczty elektronicznej zaczyna się od imienia i nazwiska, rekord typu i odpowiedzialnego operatora. „Dodaj uwierzytelnianie do naszej domeny” to zbyt szerokie pojęcie, aby zidentyfikować właściwy edytor DNS lub odpowiedź, jakiej potrzebuje odbiorca. Usługa marketingowa może podpisać umowę z jedną domeną, użyć innej jako koperty SMTP i wyświetlić trzecią w polu Od. Inwentarz powinien zachować te różnice, zanim ktokolwiek dokona edycji strefy.
Dla SPF, uzyskaj domenę używaną przez SMTP POCZTA OD tożsamość; the Tożsamość HELO ma własną kontrolę, w tym przypadek zerowej ścieżki zwrotnej. Zapytaj odpowiednią domenę o TXT . Nie wybieraj właściciela SPF jedynie poprzez odczytanie widocznego adresu Od. RFC 7208 , sekcje 2.3–2.4 i 3.1.
Dla DKIM, weź selektor z s= i domena podpisująca z d= w podpisie. Zatem kluczową nazwą wyszukiwania jest selektor _domainkey, a następnie domena podpisująca. Dla DMARC, wykrywanie zasad rozpoczyna się od zapytania TXT znajdującego się poniżej _dmarc w domenie autora i może nadal korzystać z określonej domeny Spacer po drzewie DNS. Brak początkowego zapisu nie oznacza sam w sobie, że żadna polisa nie ma zastosowania. RFC 6376 , sekcja 3.6.2; RFC 9989 , sekcje 4.5 i 4.10.
Oddziel nazwę właściciela od osób, które są właścicielami zmiany
W DNS właścicielem rekordu jest nazwa domeny. W przypadku biletu zmiany jego właścicielem jest często osoba lub zespół. Nagraj oba. Rejestrator domeny, autorytatywny host DNS , administrator platformy wysyłającej i zatwierdzający właściciel domeny mogą być różnymi stronami. Dostęp do rejestracji nie jest dowodem na to, że konkretna konsola DNS kontroluje dzisiejszą publiczną odpowiedź.
Zidentyfikuj delegowane serwery autorytatywne dla strefy zawierającej żądaną nazwę. Subdomena może mieć własną delegację, więc właściwy edytor może różnić się od edytora domeny nadrzędnej. Zachowaj strefę, pełną nazwę właściciela, żądany typ, proponowane dane i operatora odpowiedzialnego razem. Delegacja DNS określa miejsce zmiany uprawnień; nie przestrzega granic zespołu wsparcia organizacji. RFC 1034 , sekcje 4.2 i 4.2.1.
Poproś administratora nadawcy o podanie wartości przypisanych do konta i wyjaśnienie wszelkich aliasów. Dostawca CNAME instrukcja wskazuje imię na inne imię; nie jest to ta sama operacja, co delegowanie strefy podrzędnej z rekordami NS. Przechwytuj, kto utrzymuje docelowy alias, a także kto może zmieniać rekord po stronie klienta.
Przeczytaj opublikowany zestaw rekordów, a nie wygląd redaktora
Konsole DNS często akceptują względną etykietę hosta i dołączają nazwę strefy. Skopiowana w pełni kwalifikowana nazwa wprowadzona w złym trybie może zatem trafić do niezamierzonego właściciela. Sprawdź ostateczną nazwę bezwzględną, w tym każdą subdomenę i etykietę podkreślenia. Wartość zaoszczędzona przez redaktora to dowód przygotowawczy; autorytatywna odpowiedź DNS jest dowodem publikacji.
Prezentacja TXT również wymaga opieki. Pojedynczy rekord zasobu TXT może zawierać kilka ciągów znaków. W przypadku SPF ciągi te są łączone bez wstawiania spacji. To różni się od publikowania dwóch oddzielnych publikacji Rekordy SPF u tego samego właściciela, co jest zabronione. Podczas przeglądania eksportu lub zrzutu ekranu zachowaj granice rekordów, zamiast liczyć cudzysłowy. RFC 1035 , sekcja 3.3.14; RFC 7208 , sekcje 3.2–3.3.
Rekordy MX identyfikować osoby wymieniające pocztę w celu odbierania poczty. Nie potwierdzają samodzielnie, która usługa wychodząca jest autoryzowana ani jaki klucz podpisuje wiadomość. Polityka SPF może odwoływać się do MX poprzez mechanizm, ale ta relacja musi wynikać z faktycznej polityki, a nie z założenia, że wszystkie rekordy DNS związane z pocztą uwierzytelniają wysyłanie. RFC 1035 , sekcja 3.3.9; RFC 7208 , sekcja 5.4.
Przejrzyj inwentarz fikcyjnej własności
Załóżmy, że fikcyjna usługa wysyła pocztę za pomocą adresu From news@example.com, POCZTA OD bounce@mail.example.com, oraz Podpis DKIM zawierający d=example.com; s=nov26. Początkowy spis zawiera trzy osobne pytania TXT : mail.example.com, nov26._domainkey.example.com, I _dmarc.example.com. Są to przykładowe nazwy i tożsamości, a nie przestrzegane komunikaty lub zalecane wartości produkcyjne.
Administrator poczty elektronicznej potwierdza zamierzoną trasę i selektor. Administrator DNS sprawdza, która strefa zawiera każdą nazwę i czy alias wymagany przez dostawcę zmienia ścieżkę wyszukiwania. Właściciel domeny zatwierdza zakres. Jeśli selektor został wydany przez dostawcę, sprzedawca musi zachować odpowiedni klucz prywatny; tylko materiał klucza publicznego należy do DNS . Klucza prywatnego nie wolno nigdy kopiować do zgłoszenia ani publicznego rekordu TXT .
Wiersz inwentarza powinien rozróżniać „dostarczone przez usługę”, „obecne w autorytatywnym DNS ” i „zaobserwowane w otrzymanej poczcie”. Pozostawienie jednej z tych kolumn jako nieznanej jest bardziej przydatne niż przedwczesne zaznaczenie pojedynczego „uwierzytelnionego” pola.
Zbierz dowody przed zamknięciem zmiany
Proponowane kontrole są wykop @AUTH_IP nov26._domainkey.example.com . TXT +norekurs I wykop @RESOLVER_IP nov26._domainkey.example.com . TXT. Zastąp symbole zastępcze wielkimi literami zatwierdzonymi punktami końcowymi. Powtórz tę czynność dla każdego rzeczywistego właściciela i odpowiedniego autorytatywnego serwera. Zachowaj czas UTC, adres serwera, pytanie, kod odpowiedzi, flagi, sekcje odpowiedzi i uprawnień, TTL i dowolny łańcuch aliasów. Polecenia te nie zostały wykonane w tym artykule.
Jeśli uprawnienia i rekurencja nie zgadzają się, przed dodaniem zduplikowanych rekordów sprawdź spójność publikacji, buforowanie i ścieżkę modułu rozpoznawania nazw. Odpowiedź DNS w dalszym ciągu nie może potwierdzić weryfikacji podpisu, autoryzacji SPF rzeczywistego adresu IP wysyłania lub wyrównania DMARC . Zakończ te pytania kontrolowaną otrzymaną wiadomością i wynikami zaufanego odbiorcy. Autorytatywne i rekurencyjne transkrypcje ze znacznikiem czasu pozostają otwartą bramą do oryginalnych dowodów dla tej wersji dokumentu.