Wyobraźmy sobie zmianę adresu serwera domeny: w domu otwiera się nowa strona, ale telefon nadal łączy się ze starym serwerem. Nawet przy tej samej nazwie wyniki mogą się chwilowo różnić, jeśli urządzenia korzystają z innych pamięci podręcznych DNS. Pamięć HTTP przechowująca pobrane strony i pamięć DNS pomagająca znaleźć adres połączenia wymagają innych kontroli.
Artykuł śledzi fikcyjny host biblioteki www.library.example, aby wyjaśnić rozwiązywanie nazw i buforowanie. Nazwy i harmonogram są przykładami, a nie pomiarami odpowiedzi rzeczywistej usługi. Celem jest odróżnienie sposobu uzyskiwania adresu, opóźnionej widoczności zmian i awarii następujących po rozwiązaniu nazwy.
1. DNS udziela różnych rodzajów odpowiedzi dla każdej nazwy
DNS udostępnia informacje przypisane nazwom domen w rekordach różnych typów. A oznacza adres IPv4, AAAA adres IPv6; jedna nazwa może mieć wiele adresów. CNAME jest aliasem wskazującym inną nazwę, MX wskazuje serwer odbierający pocztę, a NS autorytatywny serwer nazw dla strefy. Zapytanie o tę samą nazwę może więc dawać inne odpowiedzi zależnie od żądanego typu rekordu.
Jak wyjaśnia dokumentacja rekordów DNS Cloudflare, wartość CNAME jest inną nazwą, nie adresem IP. Uzyskanie adresu może wymagać rozwiązania również tej nazwy. W https://www.library.example/books DNS obsługuje nazwę hosta www.library.example. Ścieżka /books ani treść strony nie są rejestrowane w DNS. Ustawienie CNAME nie tworzy automatycznie przekierowania HTTP zmieniającego pasek adresu przeglądarki.
2. Jak resolver rekurencyjny znajduje serwery autorytatywne
Funkcja rozwiązywania nazw urządzenia zwykle pyta skonfigurowany resolver rekurencyjny. Ten korzysta z dostępnych informacji w pamięci podręcznej albo odpytuje inne serwery DNS, zwracając ostateczną odpowiedź lub błąd. Standard terminologii DNS RFC 9499 odróżnia to wyszukiwanie w imieniu klienta od roli serwera autorytatywnego, posiadającego informacje o własnej strefie. Pochodzenie odpowiedzi należy odczytywać w kontekście roli serwera.
W uproszczonym przebiegu bez pamięci podręcznej i pośredników resolver otrzymuje od korzenia wskazanie serwerów domeny najwyższego poziomu, a od nich wskazanie serwerów autorytatywnych strefy docelowej. Ostateczny serwer autorytatywny podaje potrzebny rekord lub alias. Jeden serwer główny nie przechowuje adresów IP wszystkich stron. W praktyce można zacząć od zapamiętanej delegacji albo przekazać zapytanie innemu resolverowi; nie każda wizyta powtarza zatem całą sekwencję.
3. TTL to pozostały czas w pamięci, nie zegar całego świata
TTL rekordu przekazuje czas jego przechowywania w pamięci podręcznej w sekundach. W zwykłych odpowiedziach z pamięci czas pozostały maleje podczas przechowywania. Jeśli resolver zapisze o 10:00 adres z TTL 300 sekund, odpowiedź z tej samej kopii o 10:02 będzie miała około 180 sekund do wygaśnięcia. Tabela zakłada jeden resolver bez ponownego odpytywania, wcześniejszego odświeżania ani udostępniania przeterminowanych odpowiedzi.
| Fikcyjny czas | Adres na serwerze autorytatywnym | Działanie tego resolvera |
|---|---|---|
| 10:00 | Stary adres | Zapisuje stary adres z TTL 300 sekund |
| 10:01 | Zmieniony na nowy adres | Zapisana kopia ma jeszcze 240 sekund |
| 10:03 | Nowy adres | Może ponownie używać starego adresu przez pozostałe 120 sekund |
| Pierwsze zapytanie po 10:05 | Nowy adres | Założenie: ponowne zapytanie zamiast wygasłej kopii daje nowy adres |
Inne resolvery mogły zapisać rekord później albo nigdy go nie widzieć. Odświeżają go w różnym czasie, więc pojedynczy TTL nie wyznacza jednoczesnej zmiany u wszystkich użytkowników świata. Pamięć może usunąć dane przed wygaśnięciem, a odświeżenie strony nie kasuje kopii we współdzielonym resolverze. TTL pomaga rozumieć ponowne użycie odpowiedzi DNS, ale nie ogranicza czasu całego połączenia ze stroną ani odświeżenia ekranu.
4. Kiedy obniżać TTL i jak zapamiętuje się brak danych
Pamięć, która otrzymała stary adres z TTL 3 600 sekund, nie dowiaduje się natychmiast, że operator obniżył go teraz do 60 sekund. Przy planowanej zmianie dostosuj TTL wcześniej i uwzględnij odpowiedzi zapisane jeszcze z poprzednim, dłuższym czasem. Niższy TTL może powodować częstsze sprawdzanie zmian, ale zwiększa obciążenie zapytaniami i zależność od serwerów autorytatywnych. Rozpatruj plan zmiany i reagowanie na awarie razem, zamiast wszędzie ustawiać tę samą małą liczbę.
NXDOMAIN, oznaczający nieistniejącą nazwę, i NODATA, oznaczający nazwę istniejącą bez rekordów żądanego typu, także mogą być buforowane. Standard buforowania odpowiedzi negatywnych RFC 2308 wyznacza ten czas jako mniejszą z wartości TTL rekordu SOA serwera autorytatywnego i pola MINIMUM w SOA. Dlatego wcześniejsza odpowiedź o braku hosta może pozostać tuż po jego dodaniu. Założenie, że wygasa według TTL nowego rekordu A, może przesłonić przyczynę.
5. Sprawdzaj tę samą nazwę, typ i serwer
Zapisuj dokładną nazwę, typ, na przykład A lub AAAA, pytany serwer DNS i czas. Jeśli zainstalowano dig, nazwę i typ można podać poleceniem dig example.com A. Badając rzeczywisty problem, zastąp example.com sprawdzanym hostem. Polecenie ilustruje procedurę; nie uruchomiono go ani nie zmierzono nim czasów odpowiedzi na potrzeby tego artykułu.
Czytaj status odpowiedzi razem z nazwami, typami, wartościami i TTL w ANSWER. Powtarzając to samo zapytanie do tego samego resolvera, sprawdź, czy TTL maleje, ale wzrostu nie uznawaj od razu za błąd. Możliwe jest wcześniejsze odświeżenie lub odpowiedź innego węzła pamięci podręcznej. Osobne zapisy A i AAAA ułatwiają ustalenie, która rodzina adresów się różni.
Jako administrator możesz porównać odpowiedź resolvera rekurencyjnego z odpowiedzią serwera autorytatywnego swojej strefy dla tej samej nazwy i typu. Przy rozbieżnościach sprawdzaj kolejno pozostały czas buforowania, zgodność danych między serwerami autorytatywnymi i delegację. Nie uogólniaj odpowiedzi jednego publicznego resolvera na wszystkich użytkowników. Wewnętrzny DNS firmy albo osobne ustawienia DNS przeglądarki mogą zmieniać drogę zapytania, dlatego zapisuj również środowisko połączenia.
6. Odróżniaj błędy DNS, błędy połączenia i wyjątki
NXDOMAIN odpowiada, że nazwa nie istnieje, a NODATA, że brak żądanego typu rekordu. SERVFAIL oznacza natomiast niemożność przetworzenia zapytania przez serwer, a przekroczenie czasu oczekiwania brak odpowiedzi w wyznaczonym okresie. Nie wszystkie te przypadki oznaczają usunięcie domeny. Najpierw zachowaj informację, czy był kod odpowiedzi i który serwer pytano, aby wybrać następną kontrolę.
Stara odpowiedź po upływie TTL nie zawsze narusza zasady. Metoda serve-stale z RFC 8767 opisuje użycie przeterminowanych informacji dla zwiększenia dostępności, gdy wyjątkowo nie można ich odświeżyć u serwerów autorytatywnych. Nie oznacza to jednakowych ustawień wszystkich resolverów. Sprawdzaj działanie faktycznie używanego resolvera zamiast wyprowadzać z pojedynczego TTL gwarantowany termin uwidocznienia zmiany.
Poprawne uzyskanie adresu nie gwarantuje wreszcie dostępu do witryny. Droga sieciowa, certyfikat TLS, serwer WWW i aplikacja to osobne etapy. Jeśli DNS zwraca oczekiwany adres, ale strona się nie otwiera, badaj następny etap połączenia. Oddzielne zapisy odpowiedzi DNS i WWW pomagają znaleźć miejsce awarii przed bezmyślnym kasowaniem pamięci stron lub zmianą ustawień DNS.