Ustal, która usługa DNS kontroluje zmianę
Publikowanie rekordu uwierzytelniania oznacza zmianę konfiguracji zaufania domeny. Rozpocznij od zidentyfikowania delegowanej autorytatywnej usługi, odpowiedniego zespołu DigitalOcean i dokładnej strefy zawierającej nazwę zamierzonego właściciela. Witryna działająca na Droplecie nie ustala, gdzie hostowany jest DNS jej domeny. Konto pokazujące domenę również nie jest dowodem na to, że delegacja publiczna na nią wskazuje.
Limity DNS DigitalOcean odróżnia hosting DNS od rejestracji domeny. Dokumentują również minimalny rekord TTL wynoszący trzydzieści sekund i stwierdzają, że ich serwery nazw nie obsługują domen obsługujących DNSSEC. Traktuj istniejące podpisane delegowanie jako decyzję właściciela domeny o zgodności, a nie zaproszenie do wyłączenia ochrony podczas konfiguracji poczty e-mail. W tym przewodniku założono już zatwierdzoną, kompatybilną strefę hostowaną przez DigitalOcean; nie przenosi delegacji ani nie zmienia DNSSEC.
Zdefiniuj żądaną zmianę przed otwarciem edytora. Dla każdego proponowanego rekordu określ usługę wysyłającą, która go dostarczyła, obsługiwany przez nią przepływ biznesowy, oczekiwanego właściciela i typ rekordu oraz osobę zatwierdzającą. Zachowaj niepowiązane rekordy sieciowe, poczty przychodzącej i weryfikacji poza zmianą, chyba że określona zależność wymaga sprawdzenia.
Zachowaj użyteczny punkt początkowy
Dostawca dokumentuje opcję pobierania strefy w obszarze Sieć, Domeny i menu Więcej domeny. Jego instrukcje eksportu strefy opisz plik tekstowy zawierający zapisy strefy. Użyj autoryzowanego eksportu jako jednego z danych wejściowych do planu naprawy, wraz z proponowaną różnicą, zapisem własności i zatwierdzonymi kryteriami przywracania. Eksport nie stanowi dowodu na istnienie przycisku przywracania ani na to, że można przywrócić poprzedni stan bez wpływu na późniejsze zmiany.
W proponowanym arkuszu dowodów podaj imię i nazwisko zamierzonego właściciela w osobnej kolumnie. Typ i wartość rekordu znajdują się w oddzielnych kolumnach. Zapobiega to częstym niepowodzeniom przeglądu: poprawna polityka jest dołączona do niewłaściwej nazwy DNS , ponieważ pełny właściciel, etykieta względna i wartość tekstowa były traktowane jako ciągi wymienne.
Użyj udokumentowanego modelu edytora
Prąd przewodnik po zarządzaniu rekordami kieruje operatorów przez Sieć, Domeny i wybraną domenę, a następnie Utwórz rekord. W przypadku TXT pole Nazwa hosta akceptuje znacznik wierzchołka @ lub prefiks subdomeny, podczas gdy Wartość TXT przechowuje tekst. Opisuje SPF i bezpośredni DKIM publikacja kluczy poprzez TXT i obsługuje rekordy NS dla delegowania subdomen.
Celowo przetłumacz żądanego, w pełni wykwalifikowanego właściciela na model wejściowy tej strefy. W przypadku fikcyjnej strefy example.com krewny DMARC etykieta _dmarc reprezentuje _dmarc.example.com . Jest to wyjaśnienie konstrukcji nazwy, a nie proponowana wartość polisy lub twierdzenie, że jakikolwiek rekord został zapisany. Oczekiwanego właściciela publicznego należy sprawdzić niezależnie od tego, jak jest on prezentowany w formularzu.
Skorzystaj z aktualnych materiałów usługi wysyłania, dostosowanych do konkretnego konta, dla a Selektor DKIM, klucz publiczny lub delegowany cel. Host DNS nie wybiera tożsamości podpisującej nadawcy. Jeżeli usługa wymaga CNAME zamiast bezpośredniego klucza TXT , zachowaj to rozróżnienie i sprawdź dokładnego właściciela pod kątem istniejących zależności przed zatwierdzeniem wymiany. Nigdy nie wnioskuj o brakującym celu na podstawie zrzutu ekranu z konfiguracją innego klienta.
Zachowaj logiczną separację rekordów uwierzytelniania
RFC 7208 sekcje 3.2 i 3.3 wyróżnić wielu kandydatów Rekordy SPF z wielu ciągów w jednym rekordzie. Nie dodawaj drugiej konkurencyjnej polityki SPF dla nowej usługi. Cytowanie lub dzielenie ciągów na ekranie samo w sobie nie mówi, czy oceniany będzie jeden, czy kilka rekordów. Sprawdź zwrócone granice rekordów i wynikową połączoną wartość.
Dla DKIM , RFC 6376 sekcja 3.1 wiąże wyszukiwanie klucza z selektorem i domeną podpisującą. Sama publikacja nie może wykazać, że aplikacja wybrała ten klucz lub podpisała zamierzoną wiadomość. Konfiguracja nadawcy i publiczny materiał DNS muszą odnosić się do tej samej planowanej tożsamości.
DMARC należy do odpowiedniego właściciela _dmarc , a nie do miejsca, w którym znajduje się rekord SPF . RFC 9989 sekcje 4.1 i 4.4 opisz politykę i wyrównanie relacja. Wynik wyłącznie DNS nie jest dowodem pomyślnego dopasowania poczty, a mechanizm uwierzytelniania przechodzącego dla niepowiązanej domeny nie wystarczy.
Zweryfikuj publikację i faktyczne wykorzystanie jako różne wyniki
Autoryzowany plan weryfikacji powinien przechwytywać wiarygodne odpowiedzi przed i po zatwierdzonej edycji, w tym serwer, znacznik czasu, właściciel, typ, TTL i pełny zestaw rekordów. Zachowaj możliwość odróżnienia braku odpowiedzi od przekroczenia limitu czasu lub zapytania wysłanego do niewłaściwego serwera. Porównanie tylko zrzutu ekranu pulpitu nawigacyjnego z innym zrzutem ekranu pulpitu nawigacyjnego pomija etap publikacji publicznej.
Następnie uzyskaj kontrolowany komunikat poprzez rzeczywisty przepływ aplikacji i zachowaj wyniki zaufanego odbiorcy. Porównaj widoczną domenę From, tożsamość koperty, domenę podpisującą DKIM i selektor z zatwierdzoną konfiguracją. Rejestruj uwierzytelnianie i wyrównanie oddzielnie od dostarczania lub umieszczania w folderze. Pomyślne wyszukiwanie DNS nie powinno wypełniać pustej komórki testowej komunikatu.
Jeśli obserwowany właściciel lub wartość różni się od planu, wstrzymaj dalsze zmiany i określ najmniejsze zatwierdzone działanie naprawcze. Pamięć podręczna może zachować wcześniejszą odpowiedź, więc obserwacja odzyskiwania wymaga czasu i kontekstu, a nie obietnicy natychmiastowej globalnej spójności. Zachowaj zapis zdarzenia na tyle szczegółowy, aby odróżnić błąd wpisu od nieaktualnych danych lub nieaktywnej konfiguracji wysyłania.
Fikcyjna recenzja i wyjątkowe dowody
Fikcyjny recenzent otrzymuje wersję roboczą zawierającą prawidłowo wyglądającą wartość DMARC na szczycie witryny example.com . Recenzent wychwytuje niezgodność właściciela przed przesłaniem i zmienia proponowanego właściciela na _dmarc . Arkusz nadal nie zawiera wiarygodnych odpowiedzi przed/po ani otrzymanej wiadomości. Jest to recenzja papierowa, a nie udany przewodnik po DigitalOcean.
Dokładny pierwotny wymóg pozostaje otwarty: aktualny przewodnik po publikacji DigitalOcean z autorytatywnymi zapytaniami przed/po i niezależnie zweryfikowaną wiadomością. Bramka do uruchomienia to: Potwierdzenie aktualnej tożsamości produktu i dokumentacji będącej własnością dostawcy; przetestuj prawdziwą wiadomość lub opublikowane zapisy. Uczciwie określ nieobsługiwane funkcje domeny niestandardowej. Dokumentacja wspiera proponowany przepływ pracy, ale możliwość zastosowania przez najemcę, oryginalne testy, przegląd techniczny MŚP, wizualne sprawdzenie na żywo i zatwierdzenie publikacji przez właściciela pozostają nierozwiązane. Nie wykonano żadnej operacji DNS ani konta.