Zastąp termin propagacji planem zmian
Wartość TTL DNS pomaga określić, kiedy należy ponownie rozważyć informacje zapisane w pamięci podręcznej. Nie przewiduje jednego światowego momentu, w którym każdy odbiornik zaczyna korzystać z zamiennika SPF polityka lub DKIM klawisz. Różne programy rozpoznawania nazw uzyskały starą odpowiedź w różnym czasie, nie wszystkie autorytatywne serwery mogą obsługiwać nowe dane, a aplikacje mogą mieć własne zachowanie wyszukiwania i ponawiania prób.
Przydatny plan zmian oddziela autorytatywną publikację od dalszych obserwacji. „Host DNS zaakceptował zmianę” jest wcześniejszym kamieniem milowym niż „odpowiednie autorytatywne serwery zwracają zamierzoną odpowiedź”. Żadne ze stwierdzeń nie określa, czego konkretny odbiorca poczty użył w wiadomości wysłanej minutę temu. Rozpocznij harmonogram od dowodów dla każdego kamienia milowego, a nie od ogólnej obietnicy, że DNS zajmie ustaloną liczbę godzin.
Dowiedz się, który TTL jest obserwowany
Wiarygodny rekord zasobu ma TTL powiązany z opublikowanymi danymi. Odpowiedź w pamięci podręcznej zwykle podaje pozostały czas życia danych w pamięci podręcznej, więc dwa rekursywne programy rozpoznawania nazw mogą zwrócić identyczny tekst z różnymi pozostałymi wartościami TTL. Te wartości opisują różne stany pamięci podręcznej; nie są to dwie konkurujące ze sobą deklaracje zamierzonej konfiguracji rekordu. RFC 1035 , sekcja 4.1.3; RFC 1034 , sekcja 6.2.1.
Jeśli istniejący rekord ma długi czas TTL, zmniejszenie tej wartości nie powoduje sięgania wstecz do pamięci podręcznych, w których przechowywana była już starsza odpowiedź. Zaplanuj redukcję przed istotną zmianą i pozwól na uwzględnienie poprzedniego okna buforowania. Upewnij się, że niższy TTL jest rzeczywiście obsługiwany, zanim potraktujesz go jako część planu konserwacji. To wskazówki dotyczące planowania, a nie dowód, że zaobserwowano każdą skrytkę.
Łańcuch aliasów dodaje odrębne zależności. Rekord aliasu i zestaw rekordów celu mogą mieć różne wartości TTL i różnych operatorów. Krótki TTL po stronie klienta CNAME nie wymusza odświeżenia już zapisanego w pamięci podręcznej klucza docelowego w tym samym momencie. Zanim spróbujesz wyjaśnić moment, zapisz oba nazwiska.
Modeluj oddzielnie stare i nowe odpowiedzi
Rozważ fikcyjną aktualizację SPF pod adresem mail.example.com. Narzędzie do rozpoznawania odpowiedzi A uzyskuje starą politykę o godzinie 09:50 z czasem TTL wynoszącym 3600 sekund. O godzinie 10:00 autorytatywny operator zmienia opublikowaną wartość TTL na 300. O godzinie 10:10 operator wymienia polisę. Wcześniejszy wpis modułu przeliczającego A może być nadal użyteczny w ramach pierwotnego czasu życia pamięci podręcznej do 10:50, pod warunkiem, że nie wystąpią żadne inne zachowania. Drugi tłumacz, który jako pierwszy zajmie się 10:10, może już zwrócić zamiennik.
Ten sprawdzony przykład jest wymyśloną arytmetyką, a nie pomiarem lub gwarantowanym harmonogramem wygaśnięcia. Lekcja z tego jest taka, że obniżenie TTL o godzinie 10:00 nie powoduje przepisania wpisu Resolvera A o godzinie 09:50. Arkusz operacyjny powinien zawierać poprzednie dane, poprzedni TTL, czas zaobserwowania zmiany TTL u władzy, czas zmiany treści i kolejne próbkowane odpowiedzi tłumacza.
W przypadku rotacji DKIM zachowaj osobne kamienie milowe w celu opublikowania nowego selektor, sprawdzając jego dostępność, uruchamiając podpisy, które go używają i wycofując stary selektor. Sama arytmetyka pamięci podręcznej DNS nie może decydować o tym, kiedy wcześniej wysłana poczta zostanie zakończona weryfikacja. Wymagania nadawcy dotyczące kolejkowania, ponownych prób i przechowywania również są uwzględniane przy podejmowaniu decyzji o rotacji. RFC 6376 , sekcje 3.1 i 3.6.
Uwzględnij odpowiedzi negatywne i zachowanie związane z awarią
Nowo utworzona nazwa może nie mieć starych pozytywnych zapisów. Funkcja rozpoznawania nazw może zamiast tego przechowywać wcześniejszy wynik NXDOMAIN lub NODATA . Czas życia odpowiedzi negatywnej oparty na SOA jest inną wartością niż TTL w nowo opublikowanym Rekord TXT. Zmiana nowego TXT TTL nie powoduje zatem usunięcia poprzedniej nieobecności w pamięci podręcznej. RFC 2308 , sekcje 3 i 5.
Istnieje również wyraźny wyjątek od standardów w przypadku prostej historii wygaśnięcia. RFC 8767 pozwala na udostępnianie nieaktualnych danych, gdy nie można autorytatywnie odświeżyć wygasłego wpisu. To, czy tak się stanie, zależy od mechanizmu rozpoznawania nazw i warunków awarii. Nie zakładaj, że zwrócona odpowiedź jest świeża tylko dlatego, że ma mały, niezerowy TTL. RFC 8767 , sekcje 4–5.
Sprawy te powinny zmienić sposób dochodzenia, a nie powodować arbitralny dodatkowy okres oczekiwania. Jeśli władze nie zgadzają się z tym, popraw spójność publikacji. Jeśli odpowiedź negatywna będzie się powtarzać, sprawdź pierwotne pytanie i kontekst SOA. Jeśli uprawnienia są nieosiągalne, przywróć lub sprawdź dostępność, zamiast wielokrotnie edytować już poprawny rekord TXT .
Wybierz obserwacje, które odpowiadają na pytanie o wydanie
Przed zmianą przechwyć dokładny rekord i jego TTL z odpowiednich organów i wybranych ścieżek rekurencyjnych. Następnie powtórz tego samego właściciela, typ i klasę dla tych samych punktów końcowych. Jeśli jest dostępna, dołącz ścieżkę odpowiednią dla dotkniętego środowiska; kilka publicznych programów rozpoznawania nazw pozostaje próbkami, a nie spisem wszystkich odbiorców poczty.
Proponowane zapytanie to wykop @RESOLVER_IP mail.example.com . TXT, w połączeniu z wykop @AUTH_IP mail.example.com . TXT +norekurs. Zapisz pełne odpowiedzi ze znacznikami czasu UTC i oznacz wszystkie symbole zastępcze przed użyciem. Opróżnianie lokalnej pamięci podręcznej zmienia tylko tę ścieżkę lokalnego buforowania. Nie może wyczyścić rekursywnej pamięci podręcznej zdalnego odbiornika, więc nie jest to globalna kontrola zakończenia.
Podaj dokładnie wynik: które organy się zgadzają, które programy rozpoznawania próbek z próbą zwracają nową wartość i jakich obserwacji brakuje. Następnie wyślij kontrolowaną wiadomość za pośrednictwem zamierzonej usługi i sprawdź rzeczywiste tożsamości uwierzytelniające oraz wynik odbiorcy. Dla tej wersji roboczej nie wykonano żadnych zapytań DNS ani testów wiadomości. Wymagane porównanie rezolwerów, w tym TTL, typ odpowiedzi, uprawnienia i czas obserwacji, pozostaje otwarte.