Potwierdź uprawnienia DNS przed otwarciem edytora
GoDaddy może być rejestratorem, hostem DNS , dostawcą poczty lub kilkoma z nich jednocześnie. Ten przewodnik dotyczy publikowania DNS dla domen korzystających GoDaddy serwery nazw. Jeśli aktywne autorytatywne serwery nazw należą do innego dostawcy, zamiast tego edytuj strefę tego dostawcy. Nie przenoś serwerów nazw tylko po to, aby udostępnić znany edytor DNS .
Uzyskaj rzeczywiste wymagane wartości uwierzytelnienia z usługi wysyłającej. Jakiś SPF włączać, Selektor DKIM lub niestandardowy cel domeny zwrotnej zależy od tej usługi i trasy. Rola hosta DNS firmy GoDaddy nie oznacza uniwersalnej wartości autoryzacji poczty. Przed zmianą czegokolwiek zapisz widoczną domenę From, zamierzoną domenę koperty, jeśli jest znana, selektor i bieżącą politykę domeny.
Zidentyfikuj wszystkie istniejące rekordy pod proponowanymi nazwiskami właścicieli i zapisz rekord przed zmianą. Domena może mieć niepowiązaną weryfikację Rekordy TXT, istniejąca polityka SPF , kilka DKIM selektory i a DMARC polityka. Celem jest precyzyjna zmiana odpowiednich zapisów, a nie czyszczenie wszystkiego, co wygląda nieznajomo.
Przetłumacz zamierzonego właściciela na pola GoDaddy
Udokumentowana trasa to Portfolio domen, wybierz domenę, DNS , a następnie Dodaj nowy rekord. W przypadku TXT pole Nazwa zawiera nazwę hosta lub prefiks bez domeny; @ oznacza korzeń. Wprowadź podany tekst w polu Wartość i wybierz TTL. Strona pomocy określa wartość ASCII TXT zawierającą maksymalnie 1024 znaki. Jeśli dostarczony klucz przekracza obsługiwane pole lub wydaje się obcięty, przed zapisaniem rozwiąż problem.
W przypadku syntetycznej strefy example.com właściciel DMARC _dmarc.example.com mapuje na nazwę _dmarc . Właściciel DKIM selector7._domainkey.example.com mapuje na selektor7. _domainkey , zakładając, że selektor7 jest faktyczną etykietą dostarczoną przez dostawcę. Zasada wierzchołka SPF jest mapowana na @. Są to przykłady tłumaczenia nazw, a nie klucze lub zasady dotyczące konta rzeczywistego.
W żądaniu zmiany wpisz zarówno pełnego zamierzonego właściciela, jak i etykietę edytora. Pełna nazwa będzie tym, o co będziesz pytać w celu weryfikacji. Unikaj kopiowania pełnej nazwy hosta do pola, które ponownie dołącza do domeny. Nie dodawaj ostatniej kropki do względnego pola Nazwa, jeśli zabraniają tego udokumentowane zasady redaktora.
Wybierz TXT lub CNAME w zależności od nadawcy
Zasady SPF i DMARC są rekordami TXT . DKIM może używać klucza publicznego TXT lub wymaganego przez dostawcę CNAME alias. Postępuj zgodnie z dokładnym typem rekordu usługi wysyłającej. Klucz publiczny wklejony do miejsca docelowego CNAME nie jest aliasem DNS , a nazwa hosta dostawcy wklejona jako dowolny TXT nie jest równoważnym delegowaniem.
Przepływ pracy CNAME w GoDaddy używa prefiksu w nazwie, nie akceptuje tam znaku @ i wymaga nazwy, która nie jest jeszcze używana w innym rekordzie. Opublikuj docelową nazwę domeny dostawcy, a nie adres https lub ścieżkę do jego witryny internetowej. Jeśli nazwa selektora jest zajęta, zidentyfikuj usługę zależną i poproś o obsługiwaną alternatywę. Nie usuwaj selektora innego nadawcy tylko po to, aby zapisać formularz.
Żądana domena zwrotna Rekord MX jest niezależny od MX domeny głównej używanego w przypadku zwykłej poczty przychodzącej. Nie zmieniaj istniejącego routingu przychodzącego, chyba że zatwierdzona konfiguracja usługi pocztowej wyraźnie wymaga tej zmiany. Zachowaj niepowiązane zależności z pocztą i witrynami internetowymi podczas wdrażania uwierzytelniania.
Zachowaj granice polityki
Dodając kolejnego legalnego nadawcę, zaktualizuj jedną prawidłową politykę SPF u odpowiedniego właściciela, zamiast tworzyć drugą kandydującą politykę. Przejrzyj zależności wyszukiwania DNS i zachowaj innych zatwierdzonych nadawców. Zwykłe, niepowiązane ze sobą rekordy TXT mogą współistnieć; błąd dotyczy wielu wybranych zasad SPF , a nie każdego wystąpienia wielu danych TXT .
DMARC wymaga również przemyślanej decyzji na poziomie domeny. Przed dodaniem kolejnej sprawdź, czy odpowiednia polityka już istnieje. Nie obniżaj poziomu wymuszonych zasad do p=none ponieważ próba nowego dostawcy wykorzystuje monitorowanie. Nowa trasa powinna wykazywać dopasowane uwierzytelnianie, zanim będzie można na niej polegać w ramach zasad organizacji.
Używaj wyłącznie zatwierdzonych miejsc docelowych raportów. Skrzynka pocztowa samouczka ani punkt końcowy raportowania nie są wartościami do skopiowania do środowiska produkcyjnego. Jeśli zmiana powodowałaby wysyłanie raportów dotyczących domeny do usługi zewnętrznej, w zatwierdzeniu uwzględnij miejsce docelowe i cel.
Zapisz, zapytaj i sprawdź wiadomość
GoDaddy może wymagać dodatkowej weryfikacji tożsamości w przypadku domen chronionych. Autoryzowany właściciel konta musi wykonać wszystkie wymagane kroki bezpieczeństwa. Po zapisaniu zapytaj o pełną nazwę właściciela i wpisz ją na każdym autorytatywnym serwerze. Potwierdź pełną wartość TXT lub cel CNAME , a nie tylko wiersz edytora. Zapisany wiersz potwierdza, że zmiana została zaakceptowana; nie stwierdza, że obsługuje go aktywne delegowanie.
GoDaddy opisuje aktualizacje jako często skuteczne w ciągu godziny, ale potencjalnie trwające do 48 godzin na całym świecie. Traktuj to jako szerokie oczekiwanie, a nie powód do czekania przed sprawdzeniem nieprawidłowej nazwy lub obciętej wartości. Najpierw porównaj wiarygodne odpowiedzi, a następnie oceń buforowanie rekurencyjne względem poprzednich TTL.
Następnie zatwierdź lub aktywuj usługę wysyłania i wyślij kontrolowaną wiadomość rzeczywistą trasą. Rekord z, tożsamość koperty, wszystkie domeny/selektory podpisujące DKIM i wyniki zaufanego odbiorcy. SPF uwierzytelnia kopertę; DKIM uwierzytelnia domenę podpisu; DMARC potrzebuje wyrównanej ścieżki przejścia dla widocznego źródła.
Przypadek syntetyczny: selector7._domainkey.example.com jest rozpoznawany poprawnie, ale nadawca podpisuje się za pomocą selektor8. Hosting DNS działa, ale zamierzony klucz nie sprawdza poprawności tego podpisu. Uzgodnij selektor wygenerowany przez usługę pocztową i publikację. Dodanie kolejnej głównej zasady SPF nie jest rozwiązaniem.
Odzyskuj wąsko i dokumentuj limity
Trzymać rekord starych i nowych wartości oraz wpływających na to procesów biznesowych. Jeśli zmiana się nie powiedzie, przywróć tylko odpowiedni zatwierdzony zestaw rekordów po sprawdzeniu, czy nie wystąpiły zmiany. Przetestuj ponownie zarówno zamierzoną trasę wychodzącą, jak i wszelkie zależności przychodzące związane ze zmianą. Nie usuwaj na ślepo nowego selektora, jeśli podpisywanie zostało już do niego przeniesione.
W tym przewodniku wykorzystano własną dokumentację GoDaddy i syntetyczne przykłady. Żadne konto GoDaddy , publikacja DNS , autorytatywne wyszukiwanie ani dostarczona poczta nie były dostępne jako żywy dowód. Właściciel zmiany musi osobno dostarczyć te uwagi i zatwierdzić zakończenie produkcji.
Nagraj to, co wciąż nie jest znane
Dla pisemnego przypadku selektor7/selector8 załóżmy, że From notices@example.com i DKIM d=example.com, s=selector8. Sam klucz selektor7 nie dostarcza żadnych dowodów na temat wymaganego wyszukiwania selektora8. Selector8 DNS , weryfikacja podpisu, tożsamość/wynik SPF i inne podpisy są nieznane; nie nazywaj całej wiadomości awarią DMARC . Poproś właściciela wysyłającego o aktualnie wygenerowany rekord i zachowaj rzeczywistą odpowiedź selektora8 przed wybraniem naprawy. Nie wykonano żadnej prawdziwej wiadomości ani zapytania.
Zachowaj granicę egzekwowania
RFC 9989 Sekcja 7.4 wymaga prawidłowego DKIM , a nie samego SPF , do publikowania domen p=rejecti ostrzega o współdziałaniu poczty pośredniej i list mailingowych. Pojedynczy pomyślny test wiadomości bezpośredniej nie jest dowodem na to, że każda legalna droga jest gotowa na silniejszą politykę. Zachowaj istniejącą zatwierdzoną ochronę podczas diagnozowania rzeczywistej luki; każda zmiana polityki wymaga własnej decyzji.