Propagacja DNS to czas między zmianą rekordu DNS a chwilą, w której wszyscy widzą nową wartość. Tak naprawdę nic nie jest nigdzie rozsyłane: resolwery w całym internecie serwują kopię z pamięci podręcznej, dopóki nie upłynie jej TTL (time to live), a potem pytają ponownie. Większość zmian rekordów jest widoczna wszędzie w ciągu TTL starego rekordu, często od kilku minut do godziny. Zmiana serwerów nazw u rejestratora może potrwać do dwóch dni. Aby sprawdzić, na jakim etapie jest zmiana, zapytaj najpierw serwery nazw domeny, co publikują, a potem kilka publicznych resolwerów, co wciąż mają w pamięci podręcznej.
Co się dzieje, gdy zmieniasz rekord
Przeglądarka odwiedzającego nie pyta bezpośrednio Twojego dostawcy DNS. Zapytanie przechodzi przez kilka warstw pamięci podręcznej, a każda z nich może odpowiedzieć z pamięci:
Przeglądarka przez krótki czas przechowuje ostatnie odpowiedzi.
System operacyjny ma własną pamięć podręczną resolwera.
Resolwer rekurencyjny u dostawcy internetu, w sieci firmowej lub w usłudze publicznej, takiej jak 1.1.1.1 czy 8.8.8.8, przechowuje każdą odpowiedź tak długo, jak pozwala jej TTL.
Autorytatywne serwery nazw Twojej domeny przechowują prawdziwe rekordy. Na początku tylko one wiedzą o Twojej zmianie.
Gdy zapiszesz zmianę u dostawcy DNS, autorytatywne serwery nazw zwykle serwują ją w ciągu kilku sekund lub minut. Każda pamięć podręczna niżej w łańcuchu trzyma starą odpowiedź, dopóki jej kopia nie wygaśnie. Dwóch odwiedzających z różnych sieci może więc przez jakiś czas trafiać na różne serwery – to normalne, a nie błąd. TTL ustawiasz sam dla każdego rekordu, w sekundach; skróconą wersję znajdziesz w haśle słownika o propagacji DNS.
Ile trwa propagacja DNS
Zwykłe rekordy: stary TTL
W przypadku rekordu A, AAAA, CNAME, MX lub TXT najdłużej czekasz tyle, ile wynosił TTL starego rekordu w chwili, gdy resolwery go zapisały. Rekord z TTL 3600 może być serwowany z pamięci podręcznej jeszcze do godziny po zmianie. Obniżenie TTL w tym samym momencie co zmiana nic nie da, bo resolwery, które mają już starą kopię, trzymają ją zgodnie ze starym TTL.
Zmiana serwerów nazw: strefa nadrzędna
Przeniesienie domeny do innego dostawcy DNS oznacza zmianę jej rekordów NS u rejestratora. Są one publikowane w strefie nadrzędnej, np. .com, i to ona ustala ich TTL, a nie Ty. Możesz to sprawdzić sam, pytając bezpośrednio serwer .com:
dig +norecurse @a.gtld-servers.net example.com NS
Odpowiedź podaje serwery nazw z TTL 172800 sekund, czyli 48 godzin. Stąd bierze się rada „do 48 godzin”. W tym czasie część resolwerów pyta starego dostawcę, a część nowego, więc obaj muszą serwować te same rekordy, dopóki zmiana się nie ustabilizuje.
Nowe nazwy: negatywne cache’owanie
Jeśli ktoś sprawdził nazwę, zanim zaczęła istnieć – na przykład nową subdomenę, którą przetestowałeś za wcześnie – resolwery mogą zapamiętać także odpowiedź „taka nazwa nie istnieje”. Na jak długo, określa RFC 2308: na niższą z dwóch wartości – pola minimum rekordu SOA i TTL samego rekordu SOA. Dlatego zupełnie nowa subdomena może przez jakiś czas pokazywać DNS_PROBE_FINISHED_NXDOMAIN w jednej sieci i działać w innej.
Aplikacje, które trzymają się adresów
Długo działający program, taki jak serwer aplikacji lub proxy, może rozwiązać nazwę hosta raz przy starcie i trzymać adres aż do restartu, niezależnie od TTL. Jeśli jedna usługa wciąż łączy się ze starym serwerem, choć wszystko inne już się przeniosło, zrestartuj ją, zanim zaczniesz podejrzewać DNS.
Jak sprawdzić propagację DNS
Idź od źródła na zewnątrz. Najpierw potwierdź, że zmiana jest opublikowana, a potem sprawdź, które pamięci podręczne wciąż mają starą odpowiedź.
1. Znajdź autorytatywne serwery nazw
dig NS example.com +short
Jeśli to nie są serwery nazw dostawcy, u którego wprowadziłeś zmianę, edytowałeś niewłaściwą strefę. To częsty powód, dla którego zmiana „nigdy się nie propaguje”.
2. Zapytaj bezpośrednio każdy serwer nazw
dig @ns1.example-dns.com example.com A +short
dig @ns1.example-dns.com example.com SOA +short
Powtórz to dla każdego serwera nazw z listy. Wszystkie powinny zwracać nową wartość i ten sam numer seryjny SOA, czyli trzecie pole odpowiedzi SOA. Serwer ze starszym numerem seryjnym jeszcze nie dostał aktualizacji; to propagacja wewnątrz infrastruktury dostawcy i zwykle kończy się w ciągu kilku minut.
3. Zapytaj publiczne resolwery
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
Bez +short dig pokazuje TTL przy każdej odpowiedzi. W odpowiedzi z resolwera ta liczba oznacza czas, jaki pozostał jego kopii w pamięci podręcznej: stara wartość, której zostało 1200 sekund, zostanie zastąpiona w ciągu 20 minut. W systemie Windows nslookup -type=A example.com 1.1.1.1 pyta wskazany resolwer, ale bez TTL. Nasze darmowe narzędzie DNS lookup pokazuje odpowiedzi i TTL dla dowolnego typu rekordu z resolwera naszego serwera w Sztokholmie – bez instalowania czegokolwiek.
4. Prześledź delegację po zmianie serwerów nazw
dig +trace example.com
+trace zaczyna od serwerów głównych i podąża za odesłaniami aż do Twoich serwerów nazw, po drodze pomijając pamięci podręczne. Jeśli ścieżka kończy się u nowego dostawcy, zmiana u rejestratora już działa, a reszta to kwestia wygasania pamięci podręcznych.
Zaplanuj zmianę tak, by propagacja nie bolała
Po zmianie nie przyspieszysz już propagacji, ale przed jej rozpoczęciem możesz sprawić, że będzie krótka. Przy przeprowadzce na nowy serwer:
KiedyKrokCo najmniej jeden stary TTL wcześniejObniż TTL rekordu, na przykład z 3600 do 300 sekund.Przed zmianąPrzygotuj nowy serwer i przetestuj go, na przykład wpisem w pliku hosts lub poleceniem curl –resolve.ZmianaSkieruj rekord na nowy serwer i sprawdź odpowiedź autorytatywną.W trakcie propagacjiNie wyłączaj starego serwera i serwuj na nim tę samą treść. Część odwiedzających wciąż na niego trafia.Mniej więcej dzień późniejPonownie podnieś TTL i wyłącz stary serwer.
Przy zmianie serwerów nazw najpierw skopiuj wszystkie rekordy do nowego dostawcy i porównaj obie strefy rekord po rekordzie, łącznie z MX i TXT. Zapomniany rekord TXT psuje uwierzytelnianie poczty; narzędzie do sprawdzania SPF, DKIM i DMARC pokaże, czy wciąż przechodzi. Jeśli domena korzysta z DNSSEC, postępuj zgodnie z instrukcją nowego dostawcy dotyczącą rekordu DS u rejestratora, bo rekord DS niepasujący do nowych serwerów nazw sprawia, że resolwery weryfikujące odpowiadają SERVFAIL.
Czyszczenie pamięci podręcznych, które kontrolujesz
Możesz wyczyścić własne pamięci podręczne, żeby szybciej zobaczyć nową wartość – to pomaga przy testach. Dla Twoich odwiedzających nic to nie zmienia.
macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Windows: ipconfig /flushdns
Chrome: otwórz chrome://net-internals/#dns i wyczyść pamięć podręczną hostów.
Publiczne resolwery: Cloudflare i Google pozwalają usunąć pojedynczą nazwę ze swoich pamięci podręcznych – na stronie czyszczenia cache 1.1.1.1 i na stronie czyszczenia cache Google Public DNS.
Resolwera Twojego dostawcy internetu ani resolwerów Twoich odwiedzających nie da się wyczyścić z zewnątrz. Wygasają według własnego harmonogramu.
Kiedy to nie propagacja
Jeśli autorytatywne serwery nazw wciąż zwracają starą wartość, czekanie nic nie da. Poszukaj raczej jednej z tych przyczyn:
Niewłaściwa strefa lub dostawca. Rekord zmieniono u dostawcy, z którego domena już nie korzysta.
Niewłaściwa nazwa. Domena główna (example.com) i www.example.com to osobne rekordy.
Proxy przed serwerem. Gdy dla rekordu włączony jest CDN lub proxy, publiczny DNS celowo zwraca adresy proxy, a nie Twojego serwera.
Rekord, który się nie zapisał, albo literówka w wartości. Porównaj to, co widzisz w panelu dostawcy, z odpowiedzią dig.
Hasło Typy rekordów DNS wyjaśnia, do czego służy każdy rekord, a lista kontrolna na wypadek awarii strony opisuje kolejne kroki po DNS.
Dowiaduj się o zmianie rekordu dzięki Uptimecheck
Propagacja to planowany rodzaj zmiany DNS. Ten nieplanowany – literówka podczas migracji czy przejęte konto u rejestratora – to ten, przy którym warto dostać alert. Monitorowanie DNS w Uptimecheck obserwuje rekordy A, AAAA, CNAME, MX, NS, SOA, TXT i CAA:
Pyta bezpośrednio autorytatywne serwery nazw domeny, więc zmianę widać przy następnym sprawdzeniu, bez żadnej pamięci podręcznej resolwera pomiędzy. Gdy serwery nazw dają różne odpowiedzi, strona monitora to pokazuje.
Nowy zestaw rekordów wywołuje alert, gdy zobaczą go dwa kolejne sprawdzenia – ze starymi i nowymi wartościami – i trafia do historii rekordu.
Podaj oczekiwane wartości, a sprawdzenie zakończy się błędem za każdym razem, gdy opublikowane rekordy nie będą się z nimi zgadzać. To przy okazji potwierdza, że zaplanowana zmiana weszła w życie.
Sprawdzenia mogą się odbywać nawet co minutę. Plan Start obejmuje 10 monitorów DNS, Professional 25, a Business 150.
Połącz je ze sprawdzaniem dostępności samej strony i monitorowaniem wygasania domeny. Jak skonfigurować monitor, opisuje artykuł jak skonfigurować monitorowanie DNS, a o sygnałach ostrzegawczych przeczytasz w poradniku jak wykryć przejęte rekordy DNS.
Dowiedz się od razu, gdy zmienią się Twoje rekordy. Wypróbuj Uptimecheck za darmo przez 14 dni, bez karty kredytowej.