Odpowiedź dotycząca brakującego rekordu może przetrwać brakujący rekord
Nowy Selektor DKIM może istnieć w autorytatywnym DNS , podczas gdy rekurencyjny program rozpoznawania nazw nadal odpowiada, jakby klucza nie było. Jednym z możliwych wyjaśnień jest buforowanie ujemne: mechanizm rozpoznawania nazw dowiedział się wcześniej, że nazwa lub żądany typ rekordu jest niedostępny i zachował tę odpowiedź. Wielokrotne zapisywanie tego samego Rekord TXT nie powiadomi każdej skrytki o zmianie sytuacji.
Zacznij od udowodnienia, że zamierzony zapis znajduje się teraz we właściwym organie. Sprawdź pełną nazwę właściciela, żądany typ i dowolny alias docelowy. Negatywne buforowanie to hipoteza, którą należy przetestować po potwierdzeniu publikacji, a nie wygodne wyjaśnienie rekord który został utworzony w niewłaściwej strefie lub nie został obsłużony przez wszystkie odpowiednie władze.
Wskaż, czemu zaprzeczała wcześniejsza odpowiedź
NXDOMAIN wskazuje, że nazwa nie istnieje. NODATA opisuje odpowiedź bez odpowiednich rekordów żądanego typu, zamiast dedykowanego kodu odpowiedzi DNS . Jego typowy kod nagłówka to NOERROR. Sprawdź sekcję uprawnień i przetwarzanie aliasów, aby odróżnić ten wynik od polecenia lub niedokończonego wyszukiwania. Sama pusta sekcja odpowiedzi nie wystarczy. RFC 2308 , sekcje 2.1–2.2.
Zakres ma znaczenie. W modelu pamięci podręcznej RFC 2308 wpis dotyczący błędu nazwy jest powiązany z nazwą i klasą; wpis bez danych obejmuje również żądany typ. Jeśli alias poprzedza odpowiedź negatywną, ustal, którego końcowego imienia brakuje. Alias selektora po stronie klienta może istnieć nawet wtedy, gdy jego cel po stronie dostawcy nie istnieje. Wymaga to zbadania sprawy przez innego właściciela niż w przypadku zaginionego rekordu klienta.
Zachowaj wcześniejszy wynik, jeśli jest dostępny. Obecna odpowiedź pozytywna nie może zrekonstruować części TTL i autorytetu uzyskanej wczoraj odpowiedzi negatywnej. Jeżeli nie istnieje wcześniejsze przechwytywanie, powiedz, że negatywne buforowanie jest zgodne z obserwacjami, ale niepotwierdzone.
Oblicz czas życia na podstawie odpowiednich pól SOA
Aby uzyskać wiarygodną odpowiedź negatywną, RFC 2308 ustawia Rekord SOATTL w tej odpowiedzi na mniejszy z wartości TTL rekordu SOA i jego pola MINIMUM. Następnie odliczany jest ujemny czas życia w pamięci podręcznej. Odczyt samego SOA.MINIMUM jako uniwersalnego licznika czasu ujemnej pamięci podręcznej jest niekompletny. RFC 2308 , sekcje 3–5.
W fikcyjnym przykładzie SOA TTL strefy wynosi 900 sekund, a MINIMUM wynosi 3600. Negatywna odpowiedź wygenerowana przy użyciu tych wartości ma początkowy negatywny czas życia wynoszący 900 sekund, a nie 3600. Jeśli mechanizm rozpoznawania nazw uzyskał go o godzinie 12:00, a nowy selektor został opublikowany o godzinie 12:03, wcześniejszy negatywny wpis mógł nadal mieć wpływ na ten mechanizm rozpoznawania nazw podczas pozostałego okna zwykłej pamięci podręcznej. Te wymyślone czasy ilustrują obliczenia, a nie zaobserwowany przypadek.
O 12:05 próbkowana odpowiedź rekurencyjna może wykazywać zmniejszony czas TTL SOA. Zachowaj to, co faktycznie raportuje, zamiast zastępować tę wartość polami skonfigurowanymi w nowym zapytaniu SOA. Inne pamięci podręczne mogły uzyskać różne odpowiedzi w różnym czasie, a zasady mechanizmu rozpoznawania nazw mogą ograniczać buforowanie. Pojedyncze obliczenie nie ustala powszechnego ożywienia na godzinę 12:15.
Nie myl buforowania nieobecności z buforowaniem błędów
SERVFAIL i przekroczenie limitu czasu nie potwierdzają braku zapisu. Opisują brak uzyskania użytecznego wyniku. RFC 9520 aktualizuje starsze reguły negatywnego buforowania, wymagając buforowania na wypadek niepowodzenia rozdzielczości, w tym DNSSEC błędy walidacji; czas trwania pamięci podręcznej błędów wynosi co najmniej jedną sekundę i nie więcej niż pięć minut. Jest to niezależne od obliczeń NXDOMAIN / NODATA pochodzących z SOA. RFC 9520 , sekcje 3.2–3.4.
Powtarzające się nieudane odświeżenia mogą prowadzić do dalszych wpisów w pamięci podręcznej awarii, więc górna granica nie gwarantuje odzyskania po awarii. Jeśli po naprawie wyszukiwanie zwróci SERVFAIL , zachowaj odpowiedź i sprawdź diagnostykę modułu rozpoznawania nazw oraz dostępność źródła nadrzędnego. Nie zastępuj zasad uwierzytelniania tylko dlatego, że niepowodzenie rozwiązania zostało nieformalnie opisane jako brakujący rekord.
W przypadku niepowodzeń związanych z odświeżaniem uprawnień nieaktualne zachowanie może również komplikować harmonogram, włączając nieaktualne, negatywne dane. Zapisz, czy program rozpoznawania nazw, którego dotyczy problem, jest skonfigurowany do udostępniania nieaktualnych odpowiedzi, gdy te informacje są dostępne. Nie wnioskuj o konfiguracji na podstawie pojedynczej linii wyjściowej. RFC 8767 , sekcje 4 i 10.
Publikuj nowe nazwy, zanim staną się zależnościami
W przypadku planowanej rotacji selektora przygotuj nowy rekord publiczny przed przełączeniem usługi podpisywania w celu korzystania z niego. Zweryfikuj dokładnego właściciela i dowolny cel u odpowiedzialnych operatorów. Unikaj wielokrotnego sprawdzania niestworzonej nazwy produkcji, jakby oczekiwano sukcesu; takie zapytania mogą spowodować utworzenie ujemnych wpisów w pamięci podręcznej przed publikacją.
Jeśli konieczne jest zapytanie wstępne, zachowaj jego czas i odpowiedź. Uwzględnij w planie uruchomienia kwestie związane z ujemną pamięcią podręczną, zamiast ukrywać niewygodną awarię przed inspekcją. Niższy TTL przyszłego rekordu TXT nie skraca z mocą wsteczną odpowiedzi na nieobecność zapisanej już w pamięci podręcznej w innym miejscu. Podobnie opróżnienie laptopa administratora nie powoduje wyczyszczenia modułu rozpoznawania nazw dostawcy poczty.
Utwórz ograniczony rekord odzyskiwania
Proponowany arkusz zawiera jeden wiersz dla każdego punktu końcowego i obserwacji: czas UTC, dokładne pytanie, kod odpowiedzi, odpowiednia odpowiedź lub alias, właściciel SOA i zwrócony TTL oraz uprawnienia lub rola rekurencji. Porównaj bieżące wiarygodne wyniki ze ścieżką rekursywną, której dotyczy problem, i oddzielnie zidentyfikowanym narzędziem do rozwiązywania porównań. Zachowaj pełne odpowiedzi i powtarzaj je w rozsądnych, udokumentowanych odstępach czasu.
Jeśli organ nie dysponuje dokumentacją, napraw publikację. Jeśli uprawnienia są prawidłowe, a przechwycony wpis negatywny wyjaśnia wynik rekurencyjny, śledź tę konkretną ścieżkę pamięci podręcznej. Jeśli pojawi się SERVFAIL , skierowania lub niespójne władze, zamiast tego sprawdź te oddziały. Na koniec zweryfikuj kontrolowaną wiadomość za pomocą nowego selektora. Ten artykuł zawiera wyłącznie fikcyjną arytmetykę i proponowany przepływ pracy. Porównania oryginalnych rozwiązań rozpoznawania nazw i wyniki odebranych wiadomości pozostają nierozstrzygnięte, więc bramka dowodów operacyjnych katalogu jest nadal otwarta.