Adres IP serwera został zmieniony, panel dostawcy DNS pokazuje nową wartość, a mimo to część użytkowników nadal trafia na starą stronę. Jedni widzą już nowy serwis, inni poprzedni, a administrator słyszy, że musi czekać na „propagację DNS”. To użyteczny skrót, ale sugeruje proces, którego w rzeczywistości nie ma: jedna informacja nie rozchodzi się stopniowo po całym internecie jak fala.
Najczęściej zmiana jest dostępna na serwerach autorytatywnych od razu lub po krótkim czasie potrzebnym dostawcy na aktualizację własnej infrastruktury. Stare odpowiedzi pozostają jednak w wielu niezależnych pamięciach podręcznych. Każda z nich ma własny moment wygaśnięcia. Aby zrozumieć pozorny chaos, trzeba rozdzielić trzy pojęcia: serwer autorytatywny, resolver rekursywny i TTL.
DNS nie jest jedną globalną książką adresową
Gdy przeglądarka potrzebuje adresu IP dla nazwy www.example.com, zwykle nie pyta bezpośrednio serwera zarządzającego tą domeną. System operacyjny przekazuje pytanie do resolvera rekursywnego. Może nim być usługa operatora internetowego, serwer firmowy albo publiczny resolver, na przykład Google Public DNS czy Cloudflare.
Resolver najpierw zagląda do swojej pamięci. Jeśli ma ważną odpowiedź, zwraca ją bez dalszych pytań. Dopiero gdy wpisu brakuje albo wygasł, przechodzi przez hierarchię DNS: korzysta z informacji o strefie głównej, domenie najwyższego poziomu i właściwych serwerach autorytatywnych. Te ostatnie są źródłem danych opublikowanych przez właściciela domeny.
Takie działanie jest istotą skalowalności DNS. RFC 1034, jeden z podstawowych dokumentów systemu nazw domenowych, wskazuje, że głównym celem resolvera jest ograniczenie opóźnień i obciążenia serwerów dzięki odpowiedziom z pamięci podręcznej. Bez cache każde otwarcie strony wywoływałoby kolejną serię zapytań przez sieć.
TTL określa, jak długo odpowiedź może pozostać w cache
Każdy rekord DNS ma wartość TTL, czyli Time To Live, podawaną w sekundach. Zgodnie z RFC 1035 określa ona czas, przez jaki rekord może być przechowywany, zanim ponownie trzeba będzie skonsultować źródło informacji. TTL równy 300 oznacza pięć minut, 3600 godzinę, a 86400 dobę.
Wyobraźmy sobie, że resolver pobrał rekord A z adresem starego serwera i TTL wynoszącym 86400 sekund. Godzinę później administrator zmienia rekord na nowy adres IP. Serwer autorytatywny odpowiada już poprawnie, ale resolver nadal ma prawo korzystać ze starej kopii przez niemal 23 godziny. Nie otrzymuje powiadomienia o zmianie i nie śledzi panelu hostingowego. Po prostu odlicza czas zapisany przy poprzedniej odpowiedzi.
To tłumaczy, dlaczego dwóch użytkowników może widzieć coś innego. Resolver pierwszego odpytał domenę minutę przed zmianą i zachował dawny adres. Resolver drugiego nie miał wpisu w cache, więc po zmianie pobrał już nową wartość. Nie ma centralnego zegara odliczającego „propagację”. Są tysiące pamięci podręcznych, zapełnionych w różnych chwilach.
Obniżenie TTL po zmianie nie cofnie czasu
Jednym z najczęstszych błędów jest obniżenie TTL dopiero podczas migracji. Jeśli resolver wcześniej zapisał rekord z czasem jednej doby, późniejsza zmiana TTL na pięć minut nie dotrze do niego przed wygaśnięciem starej kopii. Krótsza wartość zacznie obowiązywać dopiero przy następnym pobraniu rekordu.
Dlatego TTL należy obniżyć z wyprzedzeniem co najmniej równym dotychczasowej wartości. Jeśli rekord miał TTL 86400, najlepiej zmniejszyć go dzień przed migracją, a jeszcze bezpieczniej wcześniej. Po upływie starego TTL większość resolverów przechowuje już rekord z krótszym czasem życia. Wtedy właściwa zmiana adresu może zostać zauważona znacznie szybciej.
Niski TTL nie jest jednak darmowym przyspieszeniem. Powoduje częstsze pytania do infrastruktury autorytatywnej i ogranicza korzyść z cache. Dokumentacja Cloudflare dotycząca TTL opisuje ten kompromis wprost: dłuższy czas zwiększa szansę szybkiej odpowiedzi z pamięci, ale opóźnia zauważenie aktualizacji. Po udanej migracji warto więc przywrócić wartość odpowiednią do stabilności usługi.
Internet potrafi zapamiętać także to, że nazwa nie istnieje
Cache DNS przechowuje nie tylko poprawne adresy. Resolver może zapamiętać również odpowiedź NXDOMAIN, informującą, że dana nazwa nie istnieje, albo odpowiedź NODATA, gdy nazwa istnieje, ale nie ma rekordu żądanego typu. Mechanizm ten nazywa się negatywnym cache.
RFC 2308 opisuje, że czas przechowywania negatywnej odpowiedzi jest wyznaczany na podstawie rekordu SOA strefy. Ma to praktyczne konsekwencje. Jeśli ktoś spróbuje otworzyć app.example.com przed utworzeniem tej nazwy, jego resolver może zapamiętać brak rekordu. Po dodaniu subdomeny inny użytkownik zobaczy ją od razu, a pierwszy przez pewien czas nadal otrzyma błąd.
Podobnie zachowują się łańcuchy CNAME i informacje o delegacji do serwerów NS. Zmiana jednego elementu nie usuwa automatycznie kopii pozostałych. Dlatego migracja domeny do nowego operatora DNS bywa bardziej złożona niż sama zmiana rekordu A lub AAAA.
Czy po wygaśnięciu TTL stara odpowiedź zawsze znika?
W normalnej sytuacji resolver po wygaśnięciu TTL powinien ponownie zapytać o dane. Istnieje jednak kontrolowany wyjątek. RFC 8767 definiuje mechanizm „serve stale”, który pozwala resolverowi podać przeterminowaną odpowiedź, gdy nie może skontaktować się z serwerami autorytatywnymi. Celem jest utrzymanie dostępności podczas awarii albo ataku, a nie ignorowanie zmian administracyjnych w zwykłych warunkach.
Różne warstwy urządzenia również mogą mieć własny cache: przeglądarka, system operacyjny, router domowy czy oprogramowanie zabezpieczające. Wyczyszczenie lokalnej pamięci pomaga tylko wtedy, gdy stary wpis znajduje się właśnie tam. Nie usuwa kopii z resolvera operatora ani z publicznej usługi DNS.
Jak bezpiecznie przeprowadzić zmianę DNS?
Dobrze zaplanowana migracja nie polega na biernym czekaniu. Warto wykonać kilka konkretnych kroków:
- Sprawdzić bieżący TTL i obniżyć go odpowiednio wcześniej, zanim zmieni się właściwy rekord.
- Upewnić się, że wszystkie autorytatywne serwery domeny zwracają tę samą nową odpowiedź oraz zgodny numer seryjny strefy SOA.
- Pozostawić stary serwer aktywny przynajmniej przez długość poprzedniego TTL z rozsądnym zapasem.
- Po zmianie porównać odpowiedź serwera autorytatywnego z odpowiedziami kilku resolverów rekursywnych.
- Po ustabilizowaniu usługi zwiększyć TTL, aby ograniczyć liczbę zapytań i poprawić odporność.
Do diagnostyki wystarczy narzędzie dig lub nslookup. Najpierw warto zapytać bezpośrednio serwer autorytatywny, a następnie resolver używany przez komputer. Jeśli pierwszy pokazuje nowy adres, a drugi stary z malejącym TTL, przyczyną jest zwykły cache. Gdy serwery autorytatywne zwracają różne dane, problem leży w konfiguracji strefy, a nie w oczekiwaniu.
Niektóre publiczne usługi pozwalają poprosić o usunięcie wpisu. Google Public DNS udostępnia narzędzie Flush Cache, ale wyczyszczenie jednej usługi nie wpływa na resolver operatora, firmową sieć ani cache innych dostawców. To pomoc diagnostyczna i operacyjna, nie przycisk przyspieszający cały internet.
Nie każdy stary widok jest winą DNS
Jeżeli nazwa rozwiązuje się już na nowy adres, a przeglądarka nadal pokazuje dawną treść, źródła problemu trzeba szukać gdzie indziej. Starą kopię może podawać CDN, odwrotne proxy, cache aplikacji, wtyczka WordPressa albo sama przeglądarka. Zdarza się też, że nowy serwer obsługuje kilka witryn, lecz nie ma prawidłowej konfiguracji dla danej nazwy hosta.
Właśnie dlatego skuteczna diagnoza zaczyna się od oddzielenia warstw. DNS odpowiada na pytanie, dokąd prowadzi nazwa. HTTP i TLS decydują, co stanie się po połączeniu z tym adresem. Samo odświeżanie strony nie naprawi złego rekordu, a czyszczenie DNS nie opróżni cache treści.
„Propagacja” to w praktyce wygasanie wielu niezależnych kopii
Zmiana DNS nie podróżuje kolejno przez wszystkie serwery świata. Nowa wartość czeka na serwerze autorytatywnym, a resolvery pobierają ją wtedy, gdy nie mają już ważnej starej odpowiedzi. To różnica ważna nie tylko językowo. Pozwala przewidzieć czas migracji, zrozumieć rozbieżne wyniki i uniknąć niepotrzebnego wyłączania poprzedniej infrastruktury.
Najlepszym narzędziem nie jest więc cierpliwe odliczanie umownych 48 godzin, lecz znajomość poprzedniego TTL, sprawdzenie serwerów autorytatywnych i porównanie odpowiedzi konkretnych resolverów. Gdy wiadomo, gdzie znajduje się stara kopia i kiedy wygaśnie, tajemnicza „propagacja DNS” staje się zwykłym, mierzalnym działaniem pamięci podręcznej.