Ustaw zatwierdzony obiekt jako obiekt możliwy do wdrożenia
Przed publikacją potok zmian DNS powinien odpowiedzieć na konkretne pytanie: czy jest to dokładnie ta zmiana rekordu, którą sprawdzili odpowiedzialni właściciele? Pomyślne sprawdzenie składni nie może odpowiedzieć na to pytanie. Ważne Rekord SPF może autoryzować niewłaściwą usługę; dobrze uformowany DKIM klucz może zastąpić taki, który nadal weryfikuje pocztę oczekującą w kolejce. Dlatego rurociąg wymaga zarówno walidacji technicznej, jak i zapisu decyzji powiązanego z niezmienną proponowaną treścią.
Traktuj poniższy przepływ pracy jako proponowaną kontrolę operacyjną, a nie twierdzenie, że każda platforma DNS zapewnia te funkcje. Zacznij od wersjonowanej wersji bazowej, utwórz dokładną różnicę, zbierz zgodę na tę różnicę i ponownie sprawdź linię bazową bezpośrednio przed wykonaniem. Jeżeli obowiązujący zapis zmienił się od czasu przeglądu, zatrzymaj się w celu uzgodnienia. Nie łącz po cichu edycji awaryjnej ze starszym, zatwierdzonym planem.
Zbuduj pakiet zmian na poziomie rekordu
Opisz każde zamierzone dodanie, zastąpienie i usunięcie, podając w pełni kwalifikowaną nazwę właściciela, klasę, typ, TTL i pełną wartość zestawu rekordów. Uwzględnij strefę autorytatywną, jej bieżące delegowanie, konto dostawcy DNS i usługę korzystającą z rekordu. Własność rejestracji i autorytatywny hosting to oddzielne zależności. Model strefy i delegacji w RFC 1034 sekcja 4.2 wyjaśnia, dlaczego zmiana wygodnego panelu sterowania niekoniecznie powoduje zmianę opublikowanych uprawnień.
Zachowaj granice rekordów. Wiele ciągów znaków w cudzysłowie w jednym Rekord TXT nie są wieloma niezależnie wybranymi politykami. RFC 1035 sekcja 3.3.14 definiuje dane TXT jako jeden lub więcej ciągów znaków. Do przeglądu pokaż zarówno reprezentację dostawcy, jak i wynikającą z niej wartość logiczną. Zapisz cały zestaw, którego dotyczy problem, aby operacja wymiany nie mogła przypadkowo usunąć niepowiązanych danych TXT o tej samej nazwie.
Dołącz inwentarz nadawcy, mapę zależności, proponowane kontrole i przywróć materiał. Zapisz, kto może zatwierdzić wpływ biznesowy, kto może zatwierdzić zmianę techniczną i kto może ją wdrożyć. Tam, gdzie platforma obsługuje dostęp do zapisu o ograniczonym zakresie, preferuj najmniejszy praktyczny zakres; dokumentuj wszelkie szersze pozwolenia jako wyraźne ujawnienie. NIST Przewodnik wdrażania DNS omawia ochronę zawartości strefy i akceptowanie aktualizacji dynamicznych tylko od autoryzowanych nadawców. Projekt zatwierdzenia rozszerza tę kwestię na podlegający przeglądowi proces operacyjny.
Zanim poprosisz o zatwierdzenie, sprawdź semantykę
Proponowany walidator powinien oddzielić zniekształcone dane od niepożądanych zasad. Sprawdź rozwinięcie nazwy właściciela, typ rekordu, zduplikowane rekordy zasad, konflikty aliasów i nieoczekiwane usunięcie. Następnie sprawdź zasady konsumenckie. SPF wybiera rekordy rozpoczynające się od ciągu wersji i zwraca trwały błąd, jeśli pozostaje więcej niż jedna pasująca polityka. Jego ocena zależna od DNS ma również określone limity, więc zliczanie samych widocznych instrukcji włączania jest niewystarczające. Są to odrębne kontrole w ramach RFC 7208 sekcje 4.5 i 4.6.4.
W przypadku zmiany DKIM zidentyfikuj rzeczywistą domenę podpisującą i selektor, ustal, czy stary klucz musi pozostać dostępny i poproś właściciela usługi o potwierdzenie zamierzonej konfiguracji podpisywania. Nazwa wyszukiwania pochodzi z wartości podpisu, a nie z odgadniętego domyślnego dostawcy, under RFC 6376 sekcja 3.6.2.1. Walidator obsługujący wyłącznie DNS nie może udowodnić, że odpowiedni klucz prywatny jest używany.
Oddziel ostrzeżenia wymagające zarejestrowanej decyzji od błędów, które muszą blokować wdrożenie. Na przykład niezależna zewnętrzna zależność SPF może wymagać przeglądu ryzyka, nawet jeśli składnia jest poprawna. Brak wymaganej wartości bazowej powinien blokować wykonanie, ponieważ nie można wiarygodnie ocenić wpływu ani odbudowy.
Powiąż akceptację z planem i jego założeniami
Dołącz stabilny skrót lub identyfikator wersji sprawdzanej różnicy, odpowiednią linię bazową i pakiet dowodów. Zatwierdzenie powinno określać środowisko, zapisy, zamierzony wynik i warunki wygaśnięcia. Nowa wartość, dodatkowe usunięcie, zmiana uprawnień lub istotnie inna zależność powinny wymagać ponownego sprawdzenia. Zapobiega to ponownemu wykorzystaniu zatwierdzenia dołączonego do tytułu biletu do innej operacji.
Wykonawca powinien zgłosić częściową awarię, zamiast traktować żądanie wsadowe jako niepodzielne bez dowodów dostawcy. Przed ponowną próbą sprawdź, które rekordy uległy zmianie. Porównaj stan obecny zarówno z wynikiem wyjściowym, jak i zamierzonym, a następnie przygotuj najmniejszy plan naprawczy. Niepewny wynik jest powodem do obserwacji, a nie do powtarzania każdego zapisu.
Fikcyjny działający przykład zablokowanego wydania
Rozważmy fikcyjną domenę example.com . Jego usługa powiadomień żąda nowego selektora DKIM podczas gdy oddzielny bilet wycofuje stary weryfikacyjny rekord TXT . Proponowany pakiet zawiera dwa usunięcia, ponieważ narzędzie eksportu potraktowało cały zestaw TXT jako jedną edytowalną komórkę. Recenzent widzi, że niepowiązana wartość weryfikacyjna zniknie i odrzuca dokładnie ten pakiet.
Zmieniony plan zmienia tylko rekord selektora i zachowuje inne wartości TXT . Właściciel poczty dostarcza proponowaną sekwencję zmiany podpisu, podczas gdy właściciel DNS zachowuje wcześniejszy zestaw rekordów do przywrócenia. Zatwierdzenie pozostaje uzależnione od świeżego porównania z wartościami bazowymi. Są to wymyślone zdarzenia przeglądowe ilustrujące kontrolę; nie zapytano, nie zatwierdzono ani nie wdrożono żadnych zapisów dla tego rękopisu.
Zamknij pętlę wykonania za pomocą dowodów
Po autoryzowanym wdrożeniu operator powinien zachować wiarygodne odpowiedzi ze znacznikiem czasu i wybrane obserwacje rekurencyjne, a następnie połączyć je z kontrolowanymi wynikami komunikatów. Porównaj rzeczywiste nazwiska i typy właścicieli z zatwierdzonym pakietem. Odpowiedź dostawcy dotycząca powodzenia jest użytecznym dowodem wykonania, ale nie jest niezależnym dowodem publicznej dostępności lub pomyślnego uwierzytelnienia.
Zdefiniuj wyzwalacze wycofywania przed wdrożeniem, w tym niezamierzone rekordy, niedostępne klucze i nieoczekiwane awarie prawidłowej poczty. Przywrócenie stanu bazowego zmienia stan autorytatywny; nie usuwa wcześniejszych odpowiedzi zapisanych w pamięci podręcznej. Brama oryginalnych dowodów pozostaje otwarta do czasu zatwierdzenia dokładnego zapisu różnic, mapy zależności, materiału do przywrócenia i dowodów wyszukiwania po zmianie. Ten manuskrypt nie zawiera żadnych artefaktów wykonawczych specyficznych dla dzierżawcy.