Ile trwa propagacja DNS i jak ją przyspieszyć
Zmieniłeś rekord DNS — przeniosłeś stronę na nowy serwer, zmieniłeś dostawcę poczty, podpiąłeś domenę do Cloudflare — i teraz jedni widzą nową stronę, a inni starą. Firmy hostingowe zwykle odpowiadają: „propagacja DNS trwa 24–48 godzin”. W rzeczywistości wszystko zależy od tego, co dokładnie zmieniasz, i od jednej liczby, którą sam kontrolujesz — TTL. Przy odrobinie przygotowania zwykła zmiana rekordu zajmuje minuty, a nie dni.
Czym naprawdę jest „propagacja”
Nic nie jest rozsyłane po internecie. Gdy zapisujesz rekord, autorytatywne serwery nazw twojego dostawcy DNS niemal od razu zaczynają zwracać nową wartość. Opóźnienia biorą się z pamięci podręcznych (cache). Każdy resolwer, który wcześniej pytał o twoją domenę — DNS operatora, Google Public DNS, Cloudflare 1.1.1.1, router w biurze, system operacyjny, przeglądarka — trzyma starą odpowiedź, dopóki nie wygaśnie jej kopia, i dopiero wtedy pyta ponownie. „Czekanie na propagację” oznacza w praktyce czekanie, aż te cache się przeterminują.
TTL — liczba, która wyznacza czas czekania
Każdy rekord DNS ma TTL (time to live, czas życia) w sekundach. Mówi on resolwerom, jak długo mogą przechowywać odpowiedź. Rekord z TTL 3600 może być podawany z cache do godziny po pobraniu, z TTL 86400 — do doby.
| TTL | Jak długo może żyć stara odpowiedź | Gdzie się spotyka |
|---|---|---|
| 60–300 | 1–5 minut | Rekordy przygotowane do przeprowadzki, równoważenie obciążenia, proxowane rekordy Cloudflare |
| 3600 | Do godziny | Częsta wartość domyślna u rejestratorów i hostingów |
| 14400–86400 | 4–24 godziny | MX, TXT i stare strefy, których nikt dawno nie ruszał |
| 172800 | Do 2 dni | Delegacja NS w strefach .com, .net i wielu innych |
Haczyk polega na tym, że resolwery trzymają stary TTL, a nie nowy. Jeśli rekord miał TTL 86400, a ty obniżyłeś go do 300 w tej samej chwili, w której zmieniłeś IP, resolwer, który pobrał rekord wczoraj, nadal trzyma starą wartość — ze starym, dobowym terminem — aż ten upłynie. O nowym TTL dowie się dopiero przy następnym zapytaniu.
Dlaczego „24–48 godzin” to tylko reguła kciuka
Ta liczba opisuje najgorszy przypadek. Delegacja serwerów nazw w popularnych strefach, takich jak .com, jest publikowana z TTL równym dwóm dniom, a rekordy z długim TTL potrafią siedzieć w cache przez dobę. Dodaj resolwery, które narzucają własny minimalny czas przechowywania albo podają przeterminowaną odpowiedź, gdy nie mogą dosięgnąć twoich serwerów — i „do 48 godzin” stało się bezpieczną formułką dla działów wsparcia. Przy zwykłej zmianie rekordu A z TTL 300–3600 sekund większość internetu zwykle widzi nową wartość w ciągu od kilku minut do godziny. Dokładnego czasu dla każdej sieci nikt nie obieca, bo część resolwerów nie przestrzega TTL ściśle.
Zmiana rekordu a zmiana serwerów nazw
To dwie różne operacje i propagują się inaczej.
- Zmiana rekordu (A, AAAA, CNAME, MX, TXT) w strefie, której już używasz: czekasz tyle, ile wynosił stary TTL tego rekordu. W pełni go kontrolujesz.
- Zmiana serwerów nazw (przeniesienie DNS do innego dostawcy, dodanie domeny do Cloudflare): zmieniasz NS u rejestratora, rejestrator przekazuje je do rejestru domeny, a resolwery znające starą delegację trzymają ją do wygaśnięcia TTL rekordów NS w strefie nadrzędnej — dla .com to do dwóch dni. Na ten TTL nie masz wpływu.
Bezpieczna zmiana serwerów nazw polega na tym, by przed przełączeniem strefa była identyczna u obu dostawców: skopiuj wszystkie rekordy A, AAAA, CNAME, MX i TXT (w tym SPF, DKIM i ciągi weryfikacyjne), zmień NS u rejestratora i nie usuwaj starej strefy przez co najmniej dwa dni. Wtedy nie ma znaczenia, którego dostawcę zapyta resolwer — odpowiedź będzie poprawna. Jeśli masz włączony DNSSEC, zaplanuj zmianę rekordu DS według instrukcji obu dostawców: DS niezgodny z kluczami nowego dostawcy psuje domenę dla resolwerów z walidacją.
Cache negatywny: „nie znaleziono” też jest zapamiętywane
Jeśli ktoś zapytał o new.example.com, zanim utworzyłeś rekord, resolwery zapamiętały odpowiedź „nie istnieje” (NXDOMAIN). Jak długo ją trzymają, określa rekord SOA strefy — brana jest mniejsza z wartości: TTL samego SOA i jego pole minimum. Dlatego najpierw twórz rekordy, a dopiero potem je testuj: odpytywanie nazwy „czy już działa” przed jej utworzeniem może wydłużyć czekanie.
Jak przyspieszyć: obniż TTL z wyprzedzeniem
- Dobę lub wcześniej przed zmianą obniż TTL rekordów, które zamierzasz zmienić (np. A i AAAA), do 300 sekund.
- Przeczekaj stary TTL. Upewnij się, że publiczne resolwery nie pokazują już dla tych rekordów TTL powyżej 300.
- Wprowadź zmianę. Większość resolwerów pobierze nową wartość w ciągu mniej więcej pięciu minut.
- Nie wyłączaj starego serwera przez co najmniej dobę. Część operatorów i sieci firmowych ignoruje krótkie TTL i przez jakiś czas będzie tam kierować odwiedzających. W przypadku poczty stary serwer musi przyjmować wiadomości co najmniej przez stary TTL rekordu MX — nowe rekordy sprawdź w sprawdzarce MX.
- Przywróć TTL do 3600 lub więcej, gdy wszystko się ustabilizuje: mniej zapytań i większa odporność.
Lokalne cache: wyczyść je, zanim zaczniesz panikować
Często internet jest już zaktualizowany, a w tyle zostaje tylko twój komputer. Wyczyść cache między tobą a resolwerem:
| Gdzie | Polecenie lub działanie |
|---|---|
| Windows | ipconfig /flushdns w wierszu poleceń uruchomionym jako administrator |
| macOS | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder |
| Linux z systemd-resolved | resolvectl flush-caches |
| Chrome, Edge | chrome://net-internals/#dns → „Clear host cache”; potem #sockets → „Flush socket pools” |
| Firefox | about:networking#dns → „Clear DNS Cache” |
| Router | Uruchom ponownie: wiele domowych routerów ma własny cache DNS |
Sprawdź też plik hosts (C:\Windows\System32\drivers\etc\hosts lub /etc/hosts): zapomniany wpis nadpisuje każdy DNS. A jeśli przeglądarka korzysta z własnego „bezpiecznego DNS”, przeglądarka i wiersz poleceń mogą pokazywać co innego. Google Public DNS i Cloudflare 1.1.1.1 mają strony, na których można poprosić o odświeżenie cache dla konkretnej nazwy; cache operatora nie da się tak wyczyścić, ale możesz tymczasowo przełączyć urządzenie na publiczny resolwer.
Jak sprawdzić propagację DNS
Użyj sprawdzarki propagacji DNS. Równolegle odpytuje ona zestaw publicznych resolwerów DNS-over-HTTPS i autorytatywne serwery nazw twojej strefy. Wynik czytaj tak:
- Serwery autorytatywne zwracają nową wartość, część publicznych resolwerów — starą — wszystko jest skonfigurowane dobrze, te resolwery czekają na koniec TTL. Pozostały TTL w każdym wierszu mówi mniej więcej, jak długo.
- Serwery autorytatywne wciąż zwracają starą wartość — zmiana się nie zapisała, trafiła do złej strefy albo edytujesz DNS u dostawcy, z którego domena nie korzysta. Sprawdź rekordy NS i dane rejestratora w WHOIS.
- Serwery autorytatywne odpowiadają różnie — strefa jest między nimi niezsynchronizowana, to problem po stronie dostawcy.
Z wiersza poleceń dig example.com @8.8.8.8 pyta jeden publiczny resolwer, a dig example.com @ns1.your-dns-provider.com — bezpośrednio twój serwer autorytatywny. Wszystkie rekordy domeny naraz pokaże DNS Lookup, a na jaki IP wskazuje strona — sprawdzarka IP domeny. Typy rekordów omawia artykuł sprawdzanie rekordów DNS domeny, a praktyczne sposoby ustalenia adresu strony — artykuł jak sprawdzić IP strony.