Propagacja DNS. Ile naprawdę trwa i jak sprawdzić, czy zmiana jest już widoczna?

Rekord w strefie DNS został zmieniony, panel rejestratora pokazuje nową wartość, a strona nadal otwiera się ze starego serwera albo nie otwiera się wcale. W takiej chwili najczęściej pada słowo „propagacja” i zalecenie, żeby odczekać dobę lub dwie. To zalecenie bywa słuszne, ale równie często zmiana jest widoczna po kilku minutach, a długie czekanie tylko maskuje zwykłą literówkę w rekordzie.

Ta instrukcja jest przeznaczona dla właścicieli firm i osób opiekujących się stroną, które przenoszą witrynę na inny serwer, zmieniają serwery nazw, podłączają pocztę albo dodają rekord weryfikacyjny. Nie wymaga wiedzy o sieciach. Wystarczy dostęp do panelu, w którym edytuje się strefę DNS domeny, oraz komputer z systemem Windows, macOS lub Linux.

Po lekturze czytelnik będzie umiał oszacować, ile potrwa oczekiwanie w jego konkretnym przypadku, sprawdzić krok po kroku, dokąd zmiana już dotarła, odróżnić zwykłe opóźnienie od błędu w konfiguracji oraz tak przygotować kolejną zmianę, żeby przeszła w kilka minut, a nie w dwie doby.

Czym jest propagacja DNS i dlaczego zmiany nie widać od razu?

System DNS zamienia nazwę domeny na adres serwera. Dane o domenie przechowują jej serwery nazw, nazywane serwerami autorytatywnymi. To one znają aktualną treść strefy, czyli wszystkie rekordy: A, CNAME, MX, TXT i pozostałe.

Komputer użytkownika nie pyta jednak tych serwerów bezpośrednio. Pyta serwer pośredniczący, najczęściej należący do dostawcy internetu albo publiczny, taki jak Google Public DNS pod adresem 8.8.8.8 lub serwer Cloudflare pod adresem 1.1.1.1. Serwer pośredniczący pobiera odpowiedź z serwera autorytatywnego i zapamiętuje ją na określony czas, żeby nie pytać o to samo przy każdej wizycie.

Słowo „propagacja” sugeruje, że nowa wartość jest rozsyłana po świecie. W rzeczywistości nic nie jest rozsyłane. Zmiana obowiązuje na serwerach autorytatywnych praktycznie od razu po zapisaniu, a opóźnienie wynika wyłącznie z tego, że tysiące serwerów pośredniczących trzymają jeszcze w pamięci starą odpowiedź. Każdy z nich pobierze nową wartość dopiero wtedy, gdy jego zapamiętana kopia straci ważność.

Stąd bierze się typowy objaw: jedna osoba widzi już nową stronę, druga jeszcze starą, a telefon w sieci komórkowej pokazuje coś innego niż komputer w biurze. Każde z tych urządzeń korzysta z innego serwera pośredniczącego, a każdy serwer zapamiętał odpowiedź w innym momencie.

Ile naprawdę trwa propagacja i od czego zależy czas oczekiwania?

Nie istnieje jeden czas propagacji wspólny dla wszystkich domen. O długości oczekiwania decyduje kilka niezależnych czynników i każdy z nich da się sprawdzić samodzielnie.

Wartość TTL zmienianego rekordu

Każdy rekord DNS ma własną wartość TTL, podawaną w sekundach. Określa ona, jak długo serwer pośredniczący może przechowywać odpowiedź, zanim zapyta o nią ponownie. Jest to najważniejsza liczba w całym zagadnieniu, ponieważ wyznacza górną granicę oczekiwania przy zmianie zwykłego rekordu.

Dokumentacja Google Workspace podaje to wprost: zastosowanie zmian w rekordzie, którego wartość TTL wynosi 86 400 sekund, może potrwać do 24 godzin. Przy wartości 3600 będzie to najwyżej godzina, a przy wartości 300 około pięciu minut. W usłudze Cloudflare ustawienie „Auto” oznacza właśnie 300 sekund.

Istotny szczegół: liczy się wartość TTL, która obowiązywała przed zmianą, a nie ta wpisana razem z nową wartością rekordu. Serwery pośredniczące zapamiętały starą odpowiedź razem ze starym czasem ważności i będą się go trzymać do końca. Jak ujmuje to dokumentacja Google, skrócony czas TTL zostanie zastosowany dopiero po wygaśnięciu dotychczasowej wartości.

Zmiana serwerów nazw zamiast pojedynczego rekordu

Zmiana serwerów nazw, czyli przeniesienie obsługi całej strefy do innego dostawcy, trwa zwykle dłużej niż zmiana jednego rekordu. Informację o serwerach nazw domeny przechowuje rejestr danej końcówki, a wartość TTL tych danych ustala rejestr, nie właściciel domeny. Bywa ona liczona w dobach, a nie w minutach.

Dochodzi do tego czas, w którym rejestrator przekazuje zmianę do rejestru. Dokumentacja Cloudflare zaleca odczekanie do 24 godzin na aktualizację serwerów nazw przez rejestratora. W pomocy dużych rejestratorów pojawia się też górna granica 48 godzin dla skrajnych przypadków. Uważam, że właśnie stąd wzięło się powtarzane wszędzie „do dwóch dni”, chociaż dotyczy ono głównie serwerów nazw, a nie zwykłych rekordów.

Samą procedurę opisałem osobno we wpisie o tym, kiedy zmiana serwerów nazw domeny jest potrzebna i jak ją przeprowadzić. Tutaj ważne jest jedno: przy takiej zmianie należy z góry założyć dłuższe oczekiwanie i odpowiednio się do niego przygotować.

Pamięć serwerów pośredniczących, routera, systemu i przeglądarki

Odpowiedź DNS jest zapamiętywana na kilku poziomach jednocześnie: w serwerze dostawcy internetu, w routerze, w systemie operacyjnym i w przeglądarce. Większość z nich stosuje się do wartości TTL, lecz nie wszystkie robią to dokładnie. Część serwerów skraca bardzo długie czasy. Google Public DNS zwykle ogranicza przechowywanie odpowiedzi do 6 godzin, nawet gdy rzeczywista wartość TTL jest dłuższa.

Zdarza się też sytuacja odwrotna. Niektórzy dostawcy internetu odświeżają zapamiętane rekordy rzadziej, niż wynikałoby to z wartości TTL. Na to właściciel domeny nie ma wpływu, a dotyczy to zwykle niewielkiej części odwiedzających.

Zapamiętana odpowiedź „taki rekord nie istnieje”

Serwery pośredniczące zapamiętują także odpowiedzi negatywne. Jeżeli ktoś sprawdził nową poddomenę, zanim rekord został dodany do strefy, serwer zapamiętał informację o jej braku. Czas przechowywania takiej odpowiedzi wynika z rekordu SOA strefy i potrafi wynosić od kilku minut do kilku godzin.

Wniosek praktyczny jest prosty: najpierw dodaje się rekord, potem sprawdza się, czy działa. Otwieranie nowego adresu w przeglądarce „na próbę” przed zapisaniem rekordu wydłuża oczekiwanie na własnym komputerze.

Jak odczytać wartość TTL i oszacować czas oczekiwania?

Zanim zacznie się czekać, dobrze jest wiedzieć, jak długo to potrwa. Wartość TTL rekordu można odczytać w dwóch miejscach: w panelu strefy DNS oraz w odpowiedzi serwera nazw.

1. Należy zalogować się do panelu firmy, która obsługuje strefę DNS domeny. Nie zawsze jest to rejestrator. Jeżeli domena korzysta z serwerów nazw firmy hostingowej albo usługi takiej jak Cloudflare, strefę edytuje się właśnie tam.
2. W edytorze strefy trzeba odszukać zmieniany rekord i odczytać kolumnę lub pole z wartością TTL. Wartość jest podana w sekundach albo w postaci opisowej, na przykład jedna godzina.
3. Jeżeli panel nie pokazuje tej wartości, można ją odczytać z wiersza poleceń. W systemie macOS lub Linux w oknie Terminala wpisuje się dig przyklad.pl A, a w systemie Windows w oknie programu PowerShell Resolve-DnsName przyklad.pl -Type A. W miejsce nazwy przyklad.pl podaje się własną domenę.
4. W odpowiedzi polecenia dig wartość TTL to liczba stojąca tuż za nazwą domeny w sekcji odpowiedzi. W odpowiedzi programu PowerShell jest to kolumna „TTL”.
5. Odczytaną liczbę sekund dzieli się przez 3600, co daje liczbę godzin. Jest to najdłuższy czas, przez jaki prawidłowo działający serwer pośredniczący może jeszcze podawać starą wartość.

Jedna uwaga do kroku trzeciego. Polecenie skierowane do serwera pośredniczącego pokazuje czas, który pozostał do wygaśnięcia zapamiętanej odpowiedzi, dlatego przy kolejnych próbach liczba maleje. Pełną wartość TTL podaje dopiero serwer autorytatywny, o którym mowa w następnej części.

Jeśli zmiana już została wykonana, a poprzedniej wartości TTL nikt nie zanotował, pozostaje przyjąć ostrożnie dobę dla zwykłego rekordu i dwie doby dla serwerów nazw, a w tym czasie kontrolować postęp opisanymi niżej sposobami.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Sprawdzę strefę DNS domeny, ustalę, czy zmiana jest już widoczna na serwerach nazw i w sieci, a jeśli nie jest, wskażę przyczynę i doprowadzę ustawienia do porządku.

Jak sprawdzić, czy zmiana jest już widoczna?

Sprawdzanie w przeglądarce jest najmniej wiarygodne, bo przeglądarka i system mają własną pamięć. Pewny wynik daje dopiero pytanie zadane wprost kolejnym serwerom, w ustalonej kolejności: najpierw źródło, potem pośrednicy, na końcu własny komputer.

Pytanie do serwera autorytatywnego

Jeżeli serwer autorytatywny podaje starą wartość, dalsze czekanie nie ma sensu, ponieważ zmiana w ogóle nie została zapisana albo trafiła do niewłaściwej strefy. Dlatego od tego pytania należy zacząć.

1. W systemie Windows otwiera się „Wiersz polecenia”, a w systemie macOS lub Linux „Terminal”.
2. Wpisuje się nslookup -type=ns przyklad.pl i zatwierdza klawiszem Enter. Odpowiedź zawiera nazwy serwerów nazw domeny, na przykład ns1.dostawca.pl i ns2.dostawca.pl.
3. Następnie pyta się jeden z tych serwerów o zmieniony rekord: nslookup przyklad.pl ns1.dostawca.pl. Dla rekordu innego typu dodaje się jego nazwę, na przykład nslookup -type=mx przyklad.pl ns1.dostawca.pl albo nslookup -type=txt przyklad.pl ns1.dostawca.pl.
4. To samo pytanie trzeba powtórzyć dla drugiego serwera nazw z listy. Oba powinny zwrócić identyczną, nową wartość.
5. Jeżeli oba serwery podają nową wartość, zmiana jest zapisana poprawnie i pozostaje wyłącznie odczekać czas wynikający z wartości TTL.

Gdy serwery nazw odpowiadają różnie, problem leży po stronie operatora strefy. Dokumentacja Google Public DNS radzi w takiej sytuacji porównać numer seryjny w rekordzie SOA na każdym z serwerów. Jeśli numery się różnią, serwery nie zsynchronizowały strefy i sprawę trzeba zgłosić firmie, która je utrzymuje.

Pytanie do publicznych serwerów DNS

Drugi etap pokazuje, co widzą zwykli użytkownicy. Wystarczy to samo polecenie skierować do publicznego serwera pośredniczącego: nslookup przyklad.pl 8.8.8.8 dla serwera Google oraz nslookup przyklad.pl 1.1.1.1 dla serwera Cloudflare. Przy zmianie serwerów nazw używa się wariantu nslookup -type=ns przyklad.pl 8.8.8.8.

Kto nie chce korzystać z wiersza poleceń, może otworzyć w przeglądarce stronę dns.google, wpisać nazwę domeny i odczytać odpowiedź serwera Google. Wygodne jest też narzędzie Dig z zestawu Google Admin Toolbox, które pokazuje rekordy wybranego typu razem z wartością TTL.

Różne wyniki z dwóch publicznych serwerów są w trakcie propagacji czymś zupełnie normalnym. Oznaczają tylko tyle, że jeden z nich pobrał już nową odpowiedź, a drugi czeka na wygaśnięcie starej.

Narzędzia pokazujące odpowiedzi z wielu krajów

W sieci działają serwisy, które pytają o rekord kilkadziesiąt serwerów w różnych krajach i pokazują wyniki na mapie. Dokumentacja Cloudflare wymienia jako przykład whatsmydns.net i od razu zastrzega, że takie narzędzia korzystają z zapamiętanych wyników, więc mogą pokazywać nową wartość z opóźnieniem.

Radzę traktować taką mapę jako obraz poglądowy. Zielone znaczniki przy wszystkich lokalizacjach nie gwarantują, że każdy dostawca internetu ma już nową odpowiedź, a pojedynczy czerwony znacznik nie świadczy o błędzie. Rozstrzygające są dwa wcześniejsze pytania: do serwera autorytatywnego i do dużych serwerów publicznych.

Jak odróżnić zwykłe opóźnienie od błędu w konfiguracji?

Najwięcej czasu traci się wtedy, gdy błąd w strefie jest brany za propagację. Poniższe sytuacje wskazują na błąd, którego samo czekanie nie usunie.

• Serwer autorytatywny zwraca starą wartość. Zmiana nie została zapisana, została wprowadzona w panelu, który nie obsługuje już tej domeny, albo czeka na zatwierdzenie.
• Rekord został dodany u rejestratora, a domena korzysta z serwerów nazw innej firmy. Strefa u rejestratora jest wtedy nieaktywna i żaden wpis w niej nie ma skutku.
• Nazwa rekordu została zdublowana. Część paneli sama dopisuje nazwę domeny, więc wpisanie pełnej nazwy tworzy rekord w rodzaju www.przyklad.pl.przyklad.pl.
• W strefie istnieją jednocześnie stary i nowy rekord A dla tej samej nazwy. Serwer zwraca oba adresy, a odwiedzający trafiają losowo na stary albo nowy serwer.
• Zmieniono rekord A dla samej domeny, a adres z przedrostkiem www ma osobny rekord, który nadal wskazuje stary serwer.
• Minął czas wynikający z poprzedniej wartości TTL, a duże serwery publiczne nadal podają starą odpowiedź.

Każdą z tych sytuacji da się potwierdzić pytaniem do serwera autorytatywnego. Jeżeli potrzebne jest przypomnienie, jak poprawnie wpisać rekordy kierujące domenę na serwer, opisałem to we wpisie o rekordzie A i rekordzie CNAME.

O zwykłej propagacji można mówić wtedy, gdy spełnione są trzy warunki naraz: oba serwery autorytatywne podają nową wartość, od zmiany nie upłynął jeszcze czas równy poprzedniej wartości TTL, a część serwerów publicznych pokazuje już nową odpowiedź. W takim układzie jedyną rozsądną czynnością jest odczekanie.

Jak odświeżyć pamięć DNS na własnym komputerze?

Bywa, że cały świat widzi już nową stronę, a komputer właściciela nadal otwiera starą. Przyczyną jest lokalna pamięć systemu, przeglądarki lub routera. Jej wyczyszczenie jest bezpieczne i nie usuwa żadnych danych użytkownika.

1. W systemie Windows należy otworzyć „Wiersz polecenia” i wpisać ipconfig /flushdns. System potwierdza opróżnienie pamięci podręcznej programu rozpoznawania nazw DNS.
2. W systemie macOS otwiera się „Terminal” i wpisuje sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. System poprosi o hasło administratora komputera.
3. Przeglądarkę trzeba zamknąć i uruchomić ponownie. W przeglądarce Chrome można zamiast tego otworzyć adres chrome://net-internals/#dns i użyć przycisku „Clear host cache”.
4. Jeżeli to nie pomaga, warto wyłączyć router na kilkadziesiąt sekund i włączyć go ponownie, ponieważ wiele routerów przechowuje odpowiedzi DNS dla całej sieci biurowej.
5. Na koniec stronę otwiera się w oknie prywatnym przeglądarki, żeby wykluczyć wpływ zapisanych plików samej witryny.

Szybkim testem jest też otwarcie strony na telefonie z wyłączoną siecią Wi-Fi. Sieć komórkowa korzysta z innych serwerów pośredniczących niż łącze w biurze, więc różnica w wyniku od razu pokazuje, że źródłem kłopotu jest lokalna pamięć, a nie strefa DNS.

Trzeba przy tym pamiętać o jednym ograniczeniu. Wyczyszczenie pamięci komputera nie zmienia tego, co zapamiętał serwer dostawcy internetu. Jeśli on nadal trzyma starą odpowiedź, komputer natychmiast pobierze ją ponownie.

Jak przyspieszyć odświeżenie rekordu w publicznych serwerach DNS?

Pamięci cudzych serwerów nie da się wyczyścić na życzenie, z jednym ważnym wyjątkiem. Google udostępnia narzędzie Flush Cache, które odświeża zapamiętaną odpowiedź w serwerach Google Public DNS. Nie trzeba udowadniać, że jest się właścicielem domeny, wystarczy rozwiązać test reCAPTCHA. Podobne narzędzie dla serwera 1.1.1.1 prowadzi Cloudflare.

1. W przeglądarce należy otworzyć stronę dns.google/cache albo stronę „Opróżnij pamięć podręczną” w pomocy Google Public DNS.
2. W polu „Domain Name” wpisuje się nazwę domeny bez przedrostka https, na przykład przyklad.pl.
3. W polu „RR Type” wybiera się typ zmienionego rekordu: A, AAAA, CNAME, MX, NS lub TXT.
4. Należy kliknąć „Flush Cache” i rozwiązać test reCAPTCHA.
5. Czynność powtarza się osobno dla każdej zmienionej nazwy, na przykład dla adresu z przedrostkiem www, oraz dla każdego zmienionego typu rekordu.
6. Wynik sprawdza się poleceniem nslookup przyklad.pl 8.8.8.8. Serwer Google powinien zwrócić nową wartość.

Kolejność ma znaczenie. Dokumentacja Google wyraźnie zaznacza, że po niedawnej zmianie rejestratora lub dostawcy DNS najpierw czyści się główną nazwę domeny, a dopiero potem poddomeny. Gdy stara odpowiedź dotyczy łańcucha rekordów CNAME, czyszczenie zaczyna się od ostatniego ogniwa.

Narzędzie ma swoje granice. Działa wyłącznie na serwery Google, nie na serwery dostawców internetu. Nie da się nim również odświeżyć domen, które do kierowania ruchu według lokalizacji używają mechanizmu podsieci klienta EDNS. W takich przypadkach pozostaje odczekać, przy czym Google i tak zwykle nie przechowuje odpowiedzi dłużej niż 6 godzin.

Jak przygotować zmianę, żeby propagacja trwała kilka minut?

Długą propagację najłatwiej skrócić, zanim w ogóle się zacznie. Cała metoda polega na tym, żeby z wyprzedzeniem obniżyć wartość TTL, a właściwą zmianę wykonać dopiero wtedy, gdy stara, długa wartość wygaśnie we wszystkich serwerach pośredniczących.

1. Należy odczytać obecną wartość TTL rekordu, który ma zostać zmieniony, i ją zanotować.
2. W edytorze strefy obniża się wartość TTL tego rekordu do 300 sekund, nie zmieniając jeszcze jego treści. Jeżeli panel nie pozwala ustawić tak krótkiego czasu, wybiera się najkrótszy dostępny.
3. Trzeba odczekać co najmniej tyle, ile wynosiła poprzednia wartość TTL. Przy 86 400 sekundach jest to pełna doba. Dopiero po tym czasie wszystkie serwery pośredniczące znają już krótki czas ważności.
4. Po upływie tego czasu zmienia się właściwą wartość rekordu, na przykład adres serwera w rekordzie A.
5. Po kilku minutach sprawdza się wynik: najpierw na serwerze autorytatywnym, następnie na serwerach 8.8.8.8 i 1.1.1.1.
6. Gdy strona i poczta działają poprawnie przez dzień lub dwa, wartość TTL podnosi się z powrotem. Dokumentacja Google zaleca 3600 sekund jako wartość roboczą, a po ustabilizowaniu konfiguracji 86 400.

Krótki czas TTL ma dodatkową zaletę: jeśli nowy serwer sprawia kłopoty, powrót do poprzedniego adresu również zajmuje kilka minut. Z tego powodu nie radzę podnosić wartości TTL od razu po zmianie.

Przy zmianie serwerów nazw ta metoda pomaga tylko częściowo, bo czasu ważności danych w rejestrze nie da się skrócić. Bezpieczna droga wygląda wtedy inaczej. Najpierw u nowego dostawcy odtwarza się pełną kopię strefy ze wszystkimi rekordami, łącznie z pocztowymi i weryfikacyjnymi, potem zmienia się serwery nazw u rejestratora, a starą strefę pozostawia się bez zmian przez co najmniej dwie doby. Dzięki temu obie grupy serwerów odpowiadają tak samo i odwiedzający nie zauważają przejścia.

Przy większych pracach, takich jak przeniesienie całego serwisu, kolejność czynności jest szersza. Opisałem ją we wpisie o tym, jak przeprowadzić migrację strony bez utraty pozycji w Google.

Jak obejrzeć stronę na nowym serwerze, zanim zmiana dotrze do wszystkich?

Nowy serwer można sprawdzić jeszcze przed zmianą rekordu albo w trakcie propagacji. Służy do tego plik hosts, czyli lokalna lista w systemie operacyjnym, która ma pierwszeństwo przed odpowiedzią z DNS. Wpis w tym pliku działa tylko na jednym komputerze i nie wpływa na innych użytkowników.

1. W systemie Windows uruchamia się „Notatnik” jako administrator i otwiera plik C:\Windows\System32\drivers\etc\hosts. W systemie macOS lub Linux plik znajduje się pod ścieżką /etc/hosts i wymaga uprawnień administratora.
2. Na końcu pliku dopisuje się jeden wiersz złożony z adresu IP nowego serwera i nazw domeny, na przykład 203.0.113.10 przyklad.pl www.przyklad.pl. Adres należy zastąpić tym, który podała firma hostingowa.
3. Plik trzeba zachować, a następnie wyczyścić pamięć DNS systemu i ponownie uruchomić przeglądarkę.
4. Po otwarciu domeny w przeglądarce komputer łączy się z nowym serwerem. Można spokojnie sprawdzić stronę główną, podstrony, formularze i panel administracyjny.
5. Po zakończeniu testów dopisany wiersz usuwa się z pliku i ponownie czyści pamięć DNS.

Ostatni krok jest obowiązkowy. Zapomniany wpis w pliku hosts to częsta przyczyna sytuacji, w której właściciel przez wiele tygodni widzi na swoim komputerze coś innego niż klienci, a po kolejnej zmianie serwera strona przestaje mu się otwierać.

W czasie takiego testu przeglądarka może wyświetlić ostrzeżenie o certyfikacie. Wynika to z tego, że nowy serwer nie zawsze ma jeszcze wystawiony certyfikat dla domeny. Ostrzeżenie w teście nie jest błędem, ale przed przełączeniem ruchu certyfikat powinien być gotowy.

Co dzieje się ze stroną, pocztą i certyfikatem w czasie propagacji?

Dopóki trwa propagacja, część odwiedzających trafia na stary serwer, a część na nowy. Oba muszą więc w tym czasie działać i pokazywać tę samą treść. Wyłączenie starego serwera zaraz po zmianie rekordu oznacza, że część klientów zobaczy komunikat o błędzie.

Podobnie zachowuje się poczta. Po zmianie rekordu MX wiadomości przez pewien czas docierają na oba serwery pocztowe. Starą skrzynkę należy zatem utrzymać i sprawdzać aż do chwili, w której przestaną na nią trafiać nowe wiadomości. Sposób ustawienia rekordów pocztowych opisałem we wpisie o tym, jak skierować pocztę firmową na właściwy serwer.

Sklepy internetowe i serwisy z formularzami wymagają dodatkowej ostrożności. Zamówienie złożone na starym serwerze w trakcie propagacji zapisze się w starej bazie danych. Bezpiecznym rozwiązaniem jest wstrzymanie przyjmowania zamówień na starym serwerze na czas przejścia albo późniejsze ręczne przeniesienie tych kilku zapisów.

Certyfikat SSL na nowym serwerze często da się wystawić dopiero wtedy, gdy domena już na niego wskazuje, ponieważ wystawca sprawdza to przez DNS. Jeżeli firma hostingowa pozwala wgrać istniejący certyfikat albo potwierdzić domenę rekordem TXT, dobrze jest zrobić to przed zmianą rekordu A.

Najczęstsze błędy popełniane w czasie propagacji da się zebrać w krótką listę.

• Wielokrotne poprawianie rekordu w odstępach kilku minut. Każda poprawka uruchamia odliczanie od nowa, a różne serwery zapamiętują różne wersje.
• Usuwanie konta na starym serwerze w dniu zmiany, bez odczekania pełnego czasu propagacji.
• Ocenianie wyniku wyłącznie we własnej przeglądarce, bez pytania do serwera autorytatywnego.
• Zmiana serwerów nazw bez wcześniejszego przepisania rekordów poczty i rekordów weryfikacyjnych do nowej strefy.
• Podniesienie wartości TTL do doby jeszcze przed sprawdzeniem, czy nowy serwer działa bez zarzutu.

Po czym poznać, że propagacja się zakończyła?

Zakończenie propagacji nie jest ogłaszane żadnym komunikatem, dlatego trzeba je stwierdzić samodzielnie. Przyjmuję, że zmiana jest zakończona, gdy spełnione są cztery warunki: oba serwery autorytatywne podają nową wartość, serwery 8.8.8.8 i 1.1.1.1 zwracają tę samą odpowiedź, od zmiany upłynął czas równy poprzedniej wartości TTL, a strona otwiera się poprawnie w sieci biurowej i w sieci komórkowej.

Dodatkowym potwierdzeniem jest ruch na starym serwerze. Jeżeli w jego dziennikach przestały pojawiać się nowe odwiedziny, a na starą skrzynkę nie przychodzą wiadomości, można go bezpiecznie wyłączyć. Przy zmianie serwerów nazw radzę odczekać z tym pełne dwie doby, nawet gdy wszystko wygląda dobrze wcześniej.

Gdy czas minął, a część użytkowników nadal widzi starą wersję, kolejność działania jest następująca. Najpierw ponownie pyta się serwery autorytatywne i porównuje ich odpowiedzi. Potem sprawdza się, czy w strefie nie pozostał drugi rekord o tej samej nazwie. Następnie czyści się pamięć Google Public DNS narzędziem Flush Cache. Jeśli problem zgłasza pojedyncza osoba, zwykle wystarcza wyczyszczenie pamięci DNS na jej komputerze i ponowne uruchomienie routera. Dopiero gdy to wszystko nie pomaga, sprawę zgłasza się operatorowi strefy, podając nazwę rekordu, oczekiwaną wartość i odpowiedzi obu serwerów nazw.

Najczęstsze pytania

Czy propagacja DNS zawsze trwa 24 albo 48 godzin?

Nie. Czas zależy od wartości TTL, która obowiązywała przed zmianą. Rekord z wartością 300 sekund zmienia się w większości sieci w ciągu kilku minut, a rekord z wartością 86 400 sekund może być widoczny w starej postaci do 24 godzin. Dłuższe terminy, sięgające dwóch dób, dotyczą przede wszystkim zmiany serwerów nazw.

Czy propagację da się przyspieszyć po wykonaniu zmiany?

Tylko w ograniczonym zakresie. Można wyczyścić pamięć własnego komputera i routera oraz odświeżyć odpowiedź w serwerach Google Public DNS narzędziem Flush Cache. Pamięci serwerów dostawców internetu nie da się wyczyścić z zewnątrz, dlatego prawdziwym sposobem na szybką zmianę jest obniżenie wartości TTL z wyprzedzeniem.

Dlaczego na telefonie strona już działa, a na komputerze jeszcze nie?

Telefon w sieci komórkowej i komputer w sieci biurowej korzystają z różnych serwerów pośredniczących, a każdy z nich zapamiętał odpowiedź w innym momencie. Dodatkowo komputer ma własną pamięć w systemie i w przeglądarce. Zwykle pomaga wyczyszczenie pamięci DNS systemu, ponowne uruchomienie przeglądarki i routera.

Czy podczas propagacji strona jest niedostępna?

Nie powinna być, o ile stary serwer nadal działa. Odwiedzający trafiają wtedy na jeden z dwóch serwerów i w obu przypadkach widzą stronę. Przerwa pojawia się dopiero wtedy, gdy stary serwer zostanie wyłączony za wcześnie albo gdy w nowej strefie brakuje któregoś rekordu.

Czy propagacja wpływa na pozycje strony w Google?

Sama zmiana adresu serwera, przeprowadzona bez przerwy w działaniu strony, nie jest powodem do obaw. Ryzyko pojawia się wtedy, gdy przez dłuższy czas roboty Google trafiają na niedziałający serwer lub na błędy. Dlatego w czasie przejścia oba serwery powinny odpowiadać poprawnie i pokazywać tę samą treść.

Jaką wartość TTL ustawić na co dzień?

Dokumentacja Google Workspace zaleca 3600 sekund jako wartość wygodną w czasie konfiguracji oraz 86 400 sekund dla rekordów, które są już ustawione prawidłowo i nie będą zmieniane. Przed planowaną zmianą obniża się ją do 300 sekund. Uważam, że dla małej firmy, która rzadko zmienia serwer, godzina jest rozsądnym ustawieniem stałym.

Czy zmiana rekordu TXT lub MX propaguje się inaczej niż zmiana rekordu A?

Zasada jest ta sama dla wszystkich typów rekordów: decyduje wartość TTL danego rekordu. Różnica polega na sposobie sprawdzania. W poleceniu nslookup podaje się wtedy odpowiedni typ, a w narzędziu Flush Cache wybiera się go w polu „RR Type”. Rekord weryfikacyjny TXT warto sprawdzić na serwerze 8.8.8.8, zanim uruchomi się weryfikację w zewnętrznej usłudze.

Co oznacza sytuacja, w której dwa serwery nazw domeny podają różne wartości?

Oznacza to, że serwery nie zsynchronizowały strefy albo że w rejestrze pozostały jednocześnie stare i nowe serwery nazw. Nie jest to propagacja i samo czekanie nie pomoże. Należy porównać numery seryjne w rekordzie SOA na obu serwerach i zgłosić rozbieżność firmie obsługującej strefę.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Zmiany w DNS potrafią niepokoić, zwłaszcza gdy od domeny zależy strona firmy i cała poczta. Chętnie zajmę się tym od początku do końca: sprawdzę obecną strefę, zaplanuję zmianę tak, żeby przeszła bez przerwy w działaniu strony i skrzynek, wprowadzę ją, a potem dopilnuję, czy nowa wartość jest widoczna na serwerach nazw i w sieci. Jeżeli zmiana została już wykonana i coś nie działa, ustalę, czy to jeszcze zwykłe opóźnienie, czy błąd w rekordach, i go poprawię.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać nazwę domeny oraz krótki opis tego, co ma zostać zmienione lub co przestało działać.