Czym jest pamięć podręczna DNS i jak długo trzyma rekordy?

Gdzie właściwie zapisywana jest odpowiedź DNS?

Pojedyncze zapytanie przechodzi przez kilka pamięci podręcznych, zanim cokolwiek zauważysz, a każda z nich trzyma własną kopię przez własny czas:

• Przeglądarka. Chrome, Edge i Firefox trzymają każda własną, niewielką pamięć podręczną DNS, odrębną od systemu operacyjnego. Ta w Chrome jest widoczna pod chrome://net-internals/#dns, a jej wyczyszczenie dotyczy tylko tej przeglądarki, nie reszty maszyny.
• Resolver zaślepkowy systemu operacyjnego. Windows uruchamia usługę DNS Client i cache'uje odpowiedzi, które możesz wypisać poleceniem ipconfig /displaydns; macOS cache'uje przez mDNSResponder; większość pulpitów linuksowych uruchamia systemd-resolved, lokalny cache'ujący resolver zaślepkowy, który odpytujesz przez resolvectl. To prawdziwa pamięć podręczna z własnym odliczaniem TTL, nie tylko kopia tego, co ma przeglądarka.
• Router. Większość domowych routerów prowadzi mały forwarder DNS, który odpowiada z własnej pamięci podręcznej, zanim przekaże zapytanie dalej, dlatego restart routera czasem naprawia problem z DNS, który tak naprawdę siedział gdzie indziej.
• Resolver rekurencyjny. Resolver Twojego dostawcy internetu, albo publiczny, obsługuje większość zapytań w internecie i trzyma największą, najbardziej współdzieloną pamięć podręczną. Gdy raz ma odpowiedź, każde urządzenie, które go zapyta, dostaje zapisaną kopię, dopóki nie wygaśnie.

Każda warstwa jest niezależna. Wyczyszczenie pamięci podręcznej na Twoim laptopie nie robi nic z pamięcią podręczną, którą wciąż trzyma Twój router albo Twój dostawca internetu, i nie robi nic dla niczyjej innej maszyny.

Czym jest TTL i kto naprawdę go honoruje?

Każdy rekord DNS niesie wartość time to live: liczbę w sekundach, ustaloną przez tego, kto zarządza strefą, mówiącą resolverowi, jak długo może ponownie użyć odpowiedzi, zanim zapyta ponownie. RFC 1035 definiuje ją jako okres, przez jaki rekord "może być cache'owany, zanim źródło informacji powinno zostać ponownie skonsultowane", a TTL równe zero oznacza, że odpowiedź nigdy nie może być cache'owana.

Każda pamięć podręczna w łańcuchu, przeglądarka, resolver zaślepkowy, router, resolver rekurencyjny, ma honorować tę liczbę, licząc od momentu, gdy po raz pierwszy pobrała rekord. W praktyce niektóre resolvery dostawców internetu narzucają własne minimum ponad to, zwykle godzinę lub więcej, niezależnie od tego, co mówi strefa o TTL. Dlatego obniżenie TTL, żeby przyspieszyć przyszłą zmianę, pomaga większości resolverów, ale nie jest gwarancją dla każdego z nich.

Czym jest cache'owanie negatywne i dlaczego zupełnie nowy rekord może wciąż nie być widoczny?

Resolver cache'uje nie tylko rekordy, które istnieją. Jeśli zapytanie wraca z odpowiedzią "no such name" (NXDOMAIN) albo bez rekordu żądanego typu, ta porażka też jest cache'owana, co nazywa się cache'owaniem negatywnym. RFC 2308 ustala czas życia pamięci podręcznej negatywnej na podstawie pola minimum w rekordzie SOA, a RFC 9520 czyni teraz cache'owanie tej porażki obowiązkowym, nie opcjonalnym, dla zgodnego resolvera.

To jest mechanizm stojący za znanym problemem: tworzysz nową subdomenę, pytasz o nią sekundę za wcześnie, dostajesz NXDOMAIN, a resolver zapamiętuje "nie istnieje" przez cały negatywny TTL strefy, mimo że rekord już istnieje. Windows pokazuje oba rodzaje wpisów osobno: ipconfig /displaydns wylicza zarówno odpowiedzi pozytywne, jak i negatywne, a ipconfig /flushdns jawnie odrzuca wpisy pamięci podręcznej negatywnej jako część czyszczenia.

Dlaczego strona rozwiązuje się dla Ciebie, a nie dla kogoś innego?

Bo nie ma jednej wspólnej pamięci podręcznej. Dwie osoby pytające dwa różne resolvery, albo pytające ten sam resolver w dwóch różnych momentach, mogą dostać dwie różne odpowiedzi dla tej samej nazwy. Kopia jednego resolvera może być wciąż świeża po zapytaniu sprzed godziny; drugi mógł nigdy wcześniej nie widzieć tej nazwy i pójdzie po aktualną wartość. Żaden z nich się nie myli, po prostu działają na innych zegarach. Jeśli dzieje się to zaraz po zmianie rekordu, jak sprawdzić propagację DNS pokazuje, jak porównać kilka resolverów obok siebie i odczytać, ile czasu zostało każdemu z nich.

Jak odczytać TTL rekordu, który jest wciąż w pamięci podręcznej?

Zapytaj o nazwę bezpośrednio i zachowaj pełny wynik zamiast skróconej formy:

dig example.com

;; ANSWER SECTION:
example.com.        847    IN    A    203.0.113.10

Liczba przed typem rekordu, w tym przykładzie 847, to sekundy pozostałe do wygaśnięcia kopii tego konkretnego resolvera; to nie jest oryginalny TTL rekordu, który z pewnością zna tylko serwer autorytatywny. Uruchom to samo zapytanie ponownie kilka sekund później, a liczba spadnie mniej więcej o tyle samo sekund, co potwierdza, że czytasz żywe odliczanie, nie stałe ustawienie. Jeśli nazwa w ogóle się nie rozwiązuje, zamiast rozwiązywać się z niską liczbą, to inna awaria: jak wyczyścić DNS opisuje najpierw czyszczenie własnej pamięci podręcznej, a czym właściwie zajmuje się resolver DNS opisuje, co dzieje się dalej w łańcuchu, gdy własna pamięć podręczna nie jest problemem.

Pamięć podręczna wyjaśnia, dlaczego jeden odwiedzający widzi zmianę od razu, a drugi nie; nie wyjaśnia rekordu, który nigdzie się nie aktualizuje. Uruchom żywe zapytanie narzędziem do zapytań DNS, żeby zobaczyć bieżącą odpowiedź spoza własnej sieci, a jeśli strona musi być osiągalna według harmonogramu, a nie sprawdzona jednorazowo, właśnie do tego służy monitoring rozproszony z wielu punktów kontrolnych. HostTracker monitoruje strony internetowe od 2004 roku, obserwuje dziś ponad 500 000 stron z ponad 300 punktów kontrolnych w 158 miastach i powiadamia e-mailem, SMS-em, telefonicznie, przez Slack, Telegram i inne kanały, gdy sprawdzenie zawiedzie, w tym sprawdzenie, które oczekuje konkretnego adresu IP i oznacza awarię w chwili, gdy odpowiedź się zmienia.

Najczęściej zadawane pytania

Czy pełna pamięć podręczna DNS spowalnia komputer?

Nie. Pamięć podręczna DNS to niewielka tabela nazw i adresów, zwykle co najwyżej kilkaset wpisów, a jej odpytanie nie kosztuje nic mierzalnego. Jeśli zapytania wydają się wolne, sama pamięć podręczna nie jest tego przyczyną; zwykłą przyczyną jest odległy albo przeciążony resolver.

Czy wyczyszczenie mojej pamięci podręcznej naprawia to dla innych osób?

Nie. ipconfig /flushdns, dscacheutil -flushcache i resolvectl flush-caches czyszczą pamięć podręczną tylko na maszynie, na której je uruchamiasz. Wszyscy inni wciąż czytają z własnej przeglądarki, własnego routera i własnego resolvera, każdy na swoim własnym liczniku.

Czy pamięć podręczna DNS to to samo co pamięć podręczna CDN?

Nie, choć te dwie się mylą. Pamięć podręczna DNS przechowuje odpowiedź na pytanie "jaki jest adres IP dla tej nazwy". Pamięć podręczna CDN przechowuje samą treść strony albo pliku na serwerze blisko odwiedzającego. Wyczyszczenie jednej nie ma wpływu na drugą.

Czy mogę ustawić własny TTL, jeśli nie zarządzam domeną?

Nie. TTL jest właściwością rekordu, ustaloną w autorytatywnej strefie przez tego, kto zarządza DNS domeny. Jako odwiedzający jedyną dźwignią, jaką masz, jest wybór resolvera, który respektuje krótki TTL, zamiast takiego, który narzuca własne minimum.

Dlaczego TTL, który widzę, zmienia się przy każdym zapytaniu?

Bo pytasz inny resolver, albo pytasz ten sam w innym momencie jego odliczania. Zapytaj bezpośrednio autorytatywny serwer nazw poleceniem dig example.com @ns1.yourdns.example, żeby zobaczyć TTL taki, jaki został pierwotnie ustawiony, bez niczego już odliczonego.