Propagacja DNS: co to jest i jak ograniczyć jej skutki

Propagacja DNS to okres, w którym niektóre resolvery nadal zwracają starą wartość rekordu po jego zmianie na autorytatywnym serwerze nazw. Nie jest to rozsyłanie zmiany: każdy resolver trzyma odpowiedź w pamięci podręcznej do końca TTL. Opóźnienie wynosi od kilku minut do 24 lub 48 godzin przy zmianie serwerów nazw, zależnie od TTL rekordu sprzed zmiany, a w przypadku serwerów nazw od TTL delegacji ustawionego w rejestrze. Poniżej wyjaśniamy, jak to działa i jak ograniczyć skutki.

Najważniejsze informacje

• Zmiana jest widoczna od razu na serwerze autorytatywnym. Opóźnienie wynika wyłącznie z pamięci podręcznych resolverów, które trzymają starą wartość do wygaśnięcia jej TTL.
• Czas życia starej wartości wyznacza TTL obowiązujący przed zmianą, a nie ten, który właśnie wpisano. Obniż go z wyprzedzeniem.
• Zmiana serwerów nazw jest najwolniejsza, bo zależy od TTL delegacji w rejestrze, nad którym nie masz kontroli.
• Błędy „ta nazwa nie istnieje” też trafiają do pamięci podręcznej: wejście na nazwę przed utworzeniem jej rekordu może przedłużyć błąd.

Czym propagacja DNS nie jest: rozsyłaniem zmiany

Nazwa wprowadza w błąd. Żaden serwer nie wysyła Twojej zmiany do innych. Gdy zapisujesz zmianę u dostawcy DNS, autorytatywny serwer nazw strefy od razu podaje nową wartość. Opóźnienie powstaje gdzie indziej, w pamięciach podręcznych.

Gdy urządzenie szuka adresu nazwy domeny, zapytanie przechodzi przez kilka warstw i każda może zapamiętać odpowiedź:

• przeglądarka, której pamięć podręczna trwa zwykle około minuty i nie zawsze respektuje TTL;
• system operacyjny, który przechowuje ostatnie odpowiedzi;
• rekursywny resolver dostawcy internetu lub usługi publicznej (na przykład 8.8.8.8 u Google, 1.1.1.1 u Cloudflare), który przechodzi hierarchię DNS i zapamiętuje wynik.

Każdy resolver stosuje TTL, który serwer autorytatywny podał mu w chwili zapisu odpowiedzi. Ponieważ nie pytały wszystkie jednocześnie, ich kopie wygasają w różnych momentach. Rekord z TTL równym 3600 sekund, zapisany 5 minut temu, odświeży się za 55 minut. Stąd sprzeczne relacje: jedna osoba widzi nową stronę, druga starą, trzecia błąd.

Jak długo trwa propagacja DNS

Czas zależy od rodzaju zmiany. TTL równy dobie (86 400 sekund) jest częsty, a dla rekordów rzadko zmienianych, takich jak serwery nazw, wartości bywają wyższe.

Trzy czynniki decydujące o opóźnieniu

TTL sprzed zmiany

Załóżmy, że rekord ma TTL 86 400 sekund, a dziś ustawiasz 300. Resolver, który zapisał go wczoraj, trzyma starą wartość nawet do 24 godzin, niezależnie od nowej: TTL 300 sekund zadziała dopiero po odświeżeniu jego kopii. W przypadku CNAME każda nazwa w łańcuchu ma własny TTL, a najdłuższy wyznacza całkowite opóźnienie.

Delegacja w rejestrze

Gdy zmieniasz serwery nazw, zmianę wprowadzasz u rejestratora, który przekazuje ją do rejestru domeny najwyższego poziomu. Resolvery, które znają jeszcze starą listę serwerów nazw, nadal je odpytują do wygaśnięcia delegacji. Ten TTL należy do rejestru: nie możesz go skrócić.

Resolvery, które nie trzymają się TTL co do joty

Niektóre resolvery ograniczają lub podnoszą TTL, a przeglądarki mają własną, krótkotrwałą pamięć podręczną. Nie da się więc zagwarantować jednakowego czasu wszędzie. TTL to teoretyczna granica, a nie obietnica wszystkich pamięci podręcznych.

Pułapka cache negatywnego

Większość poradników opisuje TTL rekordów i pomija odpowiedzi negatywne. Gdy resolver dowie się, że nazwa nie istnieje (odpowiedź NXDOMAIN) albo nie ma rekordu żądanego typu, może zapamiętać ten brak. RFC 2308 ustala czas cache negatywnego jako mniejszą z dwóch wartości: TTL rekordu SOA strefy i jego pole MINIMUM. Uznaje czas od jednej do trzech godzin za rozsądny i ostrzega, że wartości powyżej doby sprawiają problemy.

Typowy scenariusz: testujesz nowa.example.com przed utworzeniem rekordu, dostajesz błąd, a potem tworzysz rekord. Dla Twojego resolvera nazwa „nie istnieje” do końca cache negatywnego, nawet jeśli rekord działa od minuty. Jak tego uniknąć:

• utwórz rekord przed testowaniem lub ogłoszeniem nazwy;
• jeśli dostawca DNS pozwala ustawiać SOA, trzymaj umiarkowane pole MINIMUM;
• wyczyść lokalną pamięć podręczną, zanim uznasz, że „nie działa”: Microsoft podaje, że ipconfig /flushdns usuwa także negatywne wpisy z pamięci podręcznej.

Metoda ograniczania skutków migracji

1. Zanotuj bieżący TTL każdego rekordu, którego dotyczy zmiana (polecenia poniżej). To on wyznacza opóźnienie.
2. Obniż TTL do 300 sekund, co najmniej z takim wyprzedzeniem, jak długo trwa stary TTL. Przy 86 400 sekundach zrób to 24 do 48 godzin przed przełączeniem. Sprawdź minimum akceptowane przez dostawcę.
3. Przygotuj nowe miejsce docelowe: stronę, serwer poczty lub CDN gotowe odpowiadać tą samą treścią co stare. Oba muszą działać w okresie przejściowym.
4. Przełącz rekord, jedna zmiana naraz, by wiedzieć, co sprawdzać.
5. Zweryfikuj najpierw serwer autorytatywny, potem publiczne resolvery.
6. Zostaw stary serwer włączony co najmniej do końca najdłuższego starego TTL, dopiero potem go wyłącz.
7. Podnieś TTL z powrotem (3600 sekund lub więcej), gdy wszystko jest stabilne.

Przy zmianie serwerów nazw najpierw odtwórz całą strefę u nowego dostawcy (A, CNAME, MX, TXT razem z SPF i DKIM oraz resztę), sprawdź, czy odpowiada poprawnie, i dopiero potem zmień serwery nazw u rejestratora. Zostaw strefę u poprzedniego dostawcy włączoną i identyczną przez 48 godzin: resolvery, które znają jeszcze starą delegację, nadal ją odpytują.

Sprawdzanie, co widzi każdy resolver

Polecenie dig (macOS, Linux) lub nslookup (Windows) pozwala porównać odpowiedzi serwera autorytatywnego i kilku publicznych resolverów.

# Wartość i pozostały TTL widziane przez publiczne resolvery
dig +noall +answer example.com A @8.8.8.8
dig +noall +answer example.com A @1.1.1.1

# Serwery nazw zadeklarowane dla domeny
dig +short NS example.com

# Wartość podawana przez serwer autorytatywny (wstaw swój serwer nazw)
dig +noall +answer example.com A @ns1.dostawca-dns.example

# Numer seryjny SOA, do porównania między serwerami nazw
dig +short SOA example.com @ns1.dostawca-dns.example
dig +short SOA example.com @ns2.dostawca-dns.example

# Odpowiednik w Windows
nslookup -type=A example.com 8.8.8.8
nslookup -type=NS example.com

W odpowiedzi resolvera wyświetlany TTL maleje z zapytania na zapytanie: to czas pozostały do wygaśnięcia jego kopii. Jeśli resolver zwraca starą wartość z TTL, który nadal odlicza, a serwer autorytatywny zwraca już nową, wystarczy poczekać.

Porównaj też numer seryjny SOA na swoich serwerach nazw. Jeśli się różnią, któryś serwer podaje nieaktualne dane: problem leży po stronie dostawcy DNS, a nie w propagacji. Strona dns.google pozwala odpytać konkretny typ rekordu, także SOA, a przewodnik rozwiązywania problemów Google Public DNS opisuje tę weryfikację.

Czyszczenie pamięci podręcznych, które kontrolujesz

Wyczyszczenie własnej pamięci podręcznej nic nie zmienia dla innych odwiedzających, ale pokazuje, co faktycznie widzisz.

# Windows (wiersz polecenia)
ipconfig /flushdns

# Nowszy macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux z systemd-resolved
resolvectl flush-caches

Microsoft opisuje /flushdns i /displaydns na stronie polecenia ipconfig. Potem całkowicie zamknij przeglądarkę, która ma własną krótkotrwałą pamięć.

Dwa publiczne resolvery oferują też czyszczenie, przydatne po zmianie serwerów nazw lub dla użytkowników tych usług: narzędzie Flush Cache w Google Public DNS (Google radzi wyczyścić zarówno zarejestrowaną domenę, jak i dokładną nazwę zwracającą nieaktualną odpowiedź) oraz czyszczenie pamięci podręcznej 1.1.1.1 od Cloudflare, gdzie wybiera się domenę i typ rekordu. Resolverów dostawców internetu nie da się wyczyścić: trzeba poczekać na wygaśnięcie ich kopii.

Częste błędy

• Obniżanie TTL w chwili przełączenia. Jest już za późno: resolvery trzymają kopię zrobioną ze starym TTL.
• Testowanie nazwy przed utworzeniem rekordu. Cache negatywny może przedłużyć błąd.
• Zmiana serwerów nazw przed odtworzeniem całej strefy. Zapomniane rekordy poczty lub subdomen przestają działać dla resolverów, które już pytają nowego dostawcę.
• Zbyt wczesne wyłączenie starego serwera. Odwiedzający, których pamięć podręczna nie wygasła, trafiają na serwer, który już nie odpowiada.
• Uznanie propagacji za zakończoną na podstawie własnego komputera. Lokalna pamięć podręczna nie reprezentuje innych resolverów.
• Trwałe pozostawienie bardzo niskiego TTL. Zwiększa liczbę zapytań do Twoich serwerów nazw. Podnieś go po zakończeniu migracji.

Najczęściej zadawane pytania

Jak długo trwa propagacja DNS?

Przy zmianie rekordu najwyżej tyle, ile stary TTL: godzinę przy TTL 3600 sekund, 24 godziny przy 86 400. Przy zmianie serwerów nazw od kilku godzin do 48 godzin. Większość resolverów aktualizuje się znacznie przed upływem maksymalnego terminu. Zostaje kilka spóźnionych pamięci podręcznych.

Czy można przyspieszyć propagację DNS?

Nie w całym internecie: cudzych pamięci podręcznych nie da się wymusić. Można obniżyć TTL przed zmianą, wyczyścić publiczne resolvery Google i Cloudflare oraz własne pamięci podręczne. Resolverów dostawców internetu nie da się wyczyścić.

Jaki TTL wybrać przed migracją?

Krótki, na przykład 300 sekund (5 minut), ustawiony co najmniej na czas trwania starego TTL przed przełączeniem. Gdy migracja się ustabilizuje, podnieś go do 3600 sekund lub więcej: trwale bardzo niski TTL zwielokrotnia zapytania. Sprawdź minimum akceptowane przez dostawcę DNS.

Dlaczego kolega widzi nową stronę, a ja nie?

Korzystacie z różnych resolverów, które zapisały odpowiedź w różnych momentach. Odpytajcie ten sam publiczny resolver z obu komputerów, aby porównać, a potem wyczyść lokalną pamięć podręczną na komputerze, który wciąż widzi starą wersję.

Co dzieje się z moją pocztą podczas propagacji?

Zmiana rekordu MX podlega tym samym regułom: w okresie opóźnienia niektórzy nadawcy nadal piszą na stary serwer poczty. Zostaw go włączonego do końca okresu przejściowego. Gdy serwer jest niedostępny, serwery nadawcze zwykle zatrzymują wiadomości i ponawiają próby przez kilka dni.

Czy trzeba czyścić pamięć podręczną komputera?

Tak, by sprawdzić, co widzisz, ale dla innych odwiedzających nic to nie zmienia. Użyj polecenia swojego systemu, a potem całkowicie zamknij przeglądarkę. Jeśli wartość nadal jest stara, kopię trzyma resolver Twojego dostawcy internetu.

Dlaczego internetowe narzędzia do sprawdzania propagacji pokazują różne wyniki?

Każde odpytuje resolvery w różnych krajach, które zapisały odpowiedź w różnych momentach. Mieszany wynik jest normalny, dopóki TTL nie wygasł wszędzie. Jeśli same autorytatywne serwery nazw odpowiadają różnie, porównaj ich numery seryjne SOA: problem leży wtedy w strefie, a nie w propagacji.