{"id":2342,"date":"2026-10-20T06:03:09","date_gmt":"2026-10-20T06:03:09","guid":{"rendered":"https:\/\/junglelabs.uk\/"},"modified":"2026-10-20T06:03:09","modified_gmt":"2026-10-20T06:03:09","slug":"what-is-dns-propagation-why-dns-changes-take-time","status":"publish","type":"post","link":"https:\/\/junglelabs.uk\/pl\/what-is-dns-propagation-why-dns-changes-take-time\/","title":{"rendered":"Czym jest propagacja DNS? Dlaczego zmiany w DNS zajmuj\u0105 czas"},"content":{"rendered":"

Aktualizujesz rekordy DNS domeny, zapisujesz zmiany i oczekujesz, \u017ce nowa witryna internetowa lub us\u0142uga poczty elektronicznej b\u0119d\u0105 dzia\u0142a\u0107 natychmiast. Jednak kolega nadal widzi star\u0105 witryn\u0119, narz\u0119dzie online pokazuje inny adres, a dostarczanie wiadomo\u015bci e-mail zachowuje si\u0119 niejednolicie. To op\u00f3\u017anienie jest powszechnie nazywane Propagacja DNS<\/strong>.<\/p>\n\n\n\n

Fraz\u0119 t\u0119 mo\u017cna zinterpretowa\u0107 tak, jakby pojedyncza aktualizacja przemieszcza\u0142a si\u0119 przez centralny system Internetu. DNS jest jednak rozproszony. Informacje o domenach s\u0105 przechowywane i buforowane na serwerach nazw autorytatywnych, rekurencyjnych resolverach, routerach, systemach operacyjnych oraz aplikacjach. Ka\u017cdy z tych system\u00f3w mo\u017ce od\u015bwie\u017ca\u0107 swoje informacje w innym czasie.<\/p>\n\n\n\n

Wi\u0119kszo\u015b\u0107 zmian w DNS staje si\u0119 widoczna po wyga\u015bni\u0119ciu bufor\u00f3w, gdy resolverzy pobieraj\u0105 \u015bwie\u017ce rekordy. Czas ten zale\u017cy od poprzedniego czasu \u017cycia (TTL) rekordu, zachowania resolver\u00f3w oraz poprawno\u015bci konfiguracji autorytatywnego DNS. Nie istnieje uniwersalny czas, kt\u00f3ry gwarantowa\u0142by, \u017ce ka\u017cdy u\u017cytkownik zobaczy now\u0105 odpowied\u017a.<\/p>\n\n\n\n

Ten przewodnik wyja\u015bnia, co ludzie maj\u0105 na my\u015bli m\u00f3wi\u0105c o propagacji DNS, dlaczego zmiany w DNS pojawiaj\u0105 si\u0119 w r\u00f3\u017cnych odst\u0119pach czasu, jak sprawdzi\u0107 bie\u017c\u0105ce odpowiedzi domeny oraz co zrobi\u0107, gdy aktualizacja nadal wydaje si\u0119 niekompletna.<\/p>\n\n\n\n

Co oznacza propagacja DNS?<\/h2>\n\n\n\n

Propagacja DNS to powszechny termin okre\u015blaj\u0105cy okres, w kt\u00f3rym r\u00f3\u017cni u\u017cytkownicy lub serwery rozwi\u0105zywania nazw DNS mog\u0105 otrzymywa\u0107 r\u00f3\u017cne odpowiedzi po zmianie rekord\u00f3w DNS. U\u017cytkownik w jednej sieci mo\u017ce ju\u017c widzie\u0107 nowy adres IP, podczas gdy resolver innego u\u017cytkownika nadal zwraca starszy, buforowany adres.<\/p>\n\n\n\n

Podstawowa zmiana DNS jest dokonywana na autorytatywnych serwerach nazw dla domeny. Rekurencyjne resolvery pobieraj\u0105 nast\u0119pnie i buforuj\u0105 rekordy dla swoich u\u017cytkownik\u00f3w. Resolvere te nie pytaj\u0105 koniecznie ponownie serwer\u00f3w autorytatywnych za ka\u017cdym razem, gdy kto\u015b odwiedza domen\u0119. Mog\u0105 ponownie wykorzysta\u0107 zbuforowan\u0105 odpowied\u017a, dop\u00f3ki pozostaje ona wa\u017cna.<\/p>\n\n\n\n

Dlatego \u201epropagacj\u0119\u201d lepiej zrozumie\u0107 jako wyga\u015bni\u0119cie pami\u0119ci podr\u0119cznej i od\u015bwie\u017canie<\/strong>. Nie ma centralnej kopii, kt\u00f3ra musia\u0142aby by\u0107 aktualizowana jednocze\u015bnie na ka\u017cdym urz\u0105dzeniu pod\u0142\u0105czonym do Internetu. Autorytatywny rekord mo\u017ce ju\u017c by\u0107 poprawny, podczas gdy niekt\u00f3re resolver'y nadal dostarczaj\u0105 starsze dane z pami\u0119ci podr\u0119cznej.<\/p>\n\n\n\n

Jak dzia\u0142a buforowanie DNS<\/h2>\n\n\n\n

Gdy przegl\u0105darka musi znale\u017a\u0107 adres IP domeny, zwraca si\u0119 do systemu operacyjnego w celu rozwi\u0105zania nazwy. System operacyjny mo\u017ce mie\u0107 ju\u017c zapisan\u0105 w pami\u0119ci podr\u0119cznej odpowied\u017a. Je\u015bli jej nie ma, zwraca si\u0119 do skonfigurowanego rekurencyjnego resolvera, np. takiego jak ten obs\u0142ugiwany przez dostawc\u0119 internetu, firm\u0119 lub publiczn\u0105 us\u0142ug\u0119 DNS.<\/p>\n\n\n\n

Resolver rekurencyjny mo\u017ce r\u00f3wnie\u017c posiada\u0107 odpowied\u017a zapisan\u0105 w pami\u0119ci podr\u0119cznej. Je\u015bli ta odpowied\u017a nadal znajduje si\u0119 w okresie wa\u017cno\u015bci swojej pami\u0119ci podr\u0119cznej, mo\u017ce zwr\u00f3ci\u0107 j\u0105 bez kontaktowania si\u0119 z autorytatywnymi serwerami nazw. Gdy rekord w pami\u0119ci podr\u0119cznej wyga\u015bnie, resolver mo\u017ce zapyta\u0107 autorytatywny system DNS i zapisa\u0107 zaktualizowan\u0105 odpowied\u017a.<\/p>\n\n\n\n

Buforowanie skraca czas wyszukiwania i zmniejsza obci\u0105\u017cenie infrastruktury DNS. Oznacza to r\u00f3wnie\u017c, \u017ce zmiany w rekordach nie s\u0105 zawsze widoczne dla wszystkich resolver\u00f3w w tym samym momencie. Poprzednia odpowied\u017a pozostaje u\u017cyteczna dla resolvera do momentu wyga\u015bni\u0119cia jego bufora lub innego od\u015bwie\u017cenia go.<\/p>\n\n\n\n

R\u00f3\u017cni u\u017cytkownicy mog\u0105 korzysta\u0107 z r\u00f3\u017cnych resolver\u00f3w rekurencyjnych. Nawet osoby mieszkaj\u0105ce w tym samym gospodarstwie domowym mog\u0105 widzie\u0107 r\u00f3\u017cne wyniki, je\u015bli ich urz\u0105dzenia korzystaj\u0105 z r\u00f3\u017cnych us\u0142ug DNS, sieci VPN, sieci kom\u00f3rkowych lub lokalnych pami\u0119ci podr\u0119cznych.<\/p>\n\n\n\n

Czym jest TTL w DNS?<\/h2>\n\n\n\n

TTL oznacza Czas \u017cycia<\/strong>. Jest to warto\u015b\u0107, zwykle mierzona w sekundach, kt\u00f3ra informuje rekurencyjne serwery DNS, jak d\u0142ugo mog\u0105 one buforowa\u0107 rekord DNS przed sprawdzeniem zaktualizowanej odpowiedzi.<\/p>\n\n\n\n

Na przyk\u0142ad, TTL 3600<\/code> oznacza jedn\u0105 godzin\u0119. Je\u015bli resolver pobierze rekord z takim TTL, mo\u017ce zazwyczaj u\u017cywa\u0107 odpowiedzi przez do godziny, zanim b\u0119dzie musia\u0142 j\u0105 od\u015bwie\u017cy\u0107. TTL 300<\/code> oznacza pi\u0119\u0107 minut.<\/p>\n\n\n\n

TTL, kt\u00f3ry ma znaczenie po zmianie, to zwykle TTL starego rekordu, kt\u00f3ry ju\u017c zosta\u0142 zbuforowany przez resolvery. Obni\u017cenie TTL bezpo\u015brednio przed zmian\u0105 rekordu mo\u017ce nie skr\u00f3ci\u0107 czasu oczekiwania dla resolver\u00f3w, kt\u00f3re zbuforowa\u0142y poprzedni, wy\u017cszy TTL. Te resolvery mog\u0105 nadal u\u017cywa\u0107 starej odpowiedzi do momentu wyga\u015bni\u0119cia oryginalnego okresu buforowania.<\/p>\n\n\n\n

W przypadku zaplanowanych migracji administratorzy cz\u0119sto z wyprzedzeniem zmniejszaj\u0105 warto\u015b\u0107 TTL, odczekuj\u0105 wystarczaj\u0105co d\u0142ugo, aby poprzednia warto\u015b\u0107 TTL wygas\u0142a, a nast\u0119pnie wprowadzaj\u0105 zmian\u0119 w DNS. Po ustabilizowaniu si\u0119 zmiany mog\u0105 ponownie zwi\u0119kszy\u0107 warto\u015b\u0107 TTL, aby zmniejszy\u0107 liczb\u0119 powtarzaj\u0105cych si\u0119 zapyta\u0144. Odpowiednie warto\u015bci zale\u017c\u0105 od us\u0142ugi oraz procesu zmian operatora.<\/p>\n\n\n\n

Dlaczego zmiany w DNS zajmuj\u0105 r\u00f3\u017cn\u0105 ilo\u015b\u0107 czasu?<\/h2>\n\n\n\n

Najcz\u0119stszym powodem jest to, \u017ce resolvery maj\u0105 r\u00f3\u017cne skopiowane dane w pami\u0119ci podr\u0119cznej. Niekt\u00f3re mog\u0142y ju\u017c od\u015bwie\u017cy\u0107 rekord, podczas gdy inne nadal korzystaj\u0105 z nieprzeterminowanej odpowiedzi. Resolver mo\u017ce r\u00f3wnie\u017c stosowa\u0107 w\u0142asne zachowanie dotycz\u0105ce od\u015bwie\u017cania lub buforowa\u0107 odpowiedzi negatywne, czyli odpowiedzi wskazuj\u0105ce, \u017ce dany rekord nie istnieje.<\/p>\n\n\n\n

Lokalna pami\u0119\u0107 podr\u0119czna mo\u017ce doda\u0107 kolejn\u0105 warstw\u0119. Komputer, router, przegl\u0105darka lub aplikacja zabezpiecze\u0144 mog\u0105 tymczasowo przechowywa\u0107 informacje DNS. Uruchomienie ponownie przegl\u0105darki lub wyczyszczenie pami\u0119ci podr\u0119cznej DNS systemu operacyjnego mo\u017ce pom\u00f3c w niekt\u00f3rych przypadkach, ale nie zmieni to tego, co nadal jest zbuforowane przez resolver rekurencyjny.<\/p>\n\n\n\n

Zmiany dostawcy us\u0142ug DNS mog\u0105 wprowadza\u0107 dodatkowe czynniki czasowe. Je\u015bli zmienisz autorytatywne serwery nazw domeny u rejestratora, resolvery mog\u0105 potrzebowa\u0107 od\u015bwie\u017cenia informacji o delegacji, a tak\u017ce rekord\u00f3w obs\u0142ugiwanych przez te serwery nazw. Jest to zmiana inna ni\u017c edycja rekordu A lub AAAA w ramach tej samej us\u0142ugi hostingu DNS.<\/p>\n\n\n\n

Ostatecznie aktualizacja mo\u017ce by\u0107 niepoprawna w \u017ar\u00f3dle autorytatywnym. Je\u015bli edytowano niew\u0142a\u015bciwy rekord, zmiany nie zosta\u0142y zapisane, domena korzysta z innych serwer\u00f3w nazw autorytatywnych lub rekord zawiera b\u0142\u0105d sk\u0142adniowy, oczekiwanie nie naprawi podstawowej konfiguracji.<\/p>\n\n\n\n

Propagacja DNS vs Aktualizacje autorytatywnego DNS<\/h2>\n\n\n\n

Autorytatywny serwer DNS dostarcza oficjalne rekordy dla domeny lub strefy. Gdy edytujesz rekord w panelu kontrolnym dostawcy us\u0142ug DNS, dostawca powinien zaktualizowa\u0107 autorytatywne dane, kt\u00f3re udost\u0119pnia.<\/p>\n\n\n\n

Rekurencyjny resolver dostarcza odpowiedzi DNS urz\u0105dzeniom klienckim. Mo\u017ce posiada\u0107 dane z pami\u0119ci podr\u0119cznej zebrane przed zmian\u0105. W zwi\u0105zku z tym serwer autorytatywny mo\u017ce zwr\u00f3ci\u0107 nowy adres, podczas gdy rekurencyjny resolver nadal zwraca starszy.<\/p>\n\n\n\n

To rozr\u00f3\u017cnienie jest przydatne podczas rozwi\u0105zywania problem\u00f3w. Najpierw sprawd\u017a, co zwracaj\u0105 autorytatywne serwery nazw. Je\u015bli ju\u017c zawieraj\u0105 oczekiwany rekord, zmiana zosta\u0142a opublikowana w \u017ar\u00f3dle, a pozosta\u0142e r\u00f3\u017cnice s\u0105 prawdopodobnie spowodowane buforowaniem lub zachowaniem resolvera. Je\u015bli autorytatywne serwery nadal zwracaj\u0105 star\u0105 warto\u015b\u0107 lub brak warto\u015bci, przeanalizuj konfiguracj\u0119 dostawcy DNS oraz same rekordy.<\/p>\n\n\n\n

Zmiana serwer\u00f3w nazw dodaje kolejn\u0105 warstw\u0119. Strefa DNS nadrz\u0119dna musi wskazywa\u0107 na przewidziane autorytatywne serwery nazw, a te serwery musz\u0105 obs\u0142ugiwa\u0107 prawid\u0142ow\u0105 stref\u0119. Poprawny rekord u dostawcy DNS nie jest przydatny, je\u015bli domena jest delegowana do serwer\u00f3w nazw innego dostawcy.<\/p>\n\n\n\n

Zmiany w DNS a ich skutki<\/h2>\n\n\n\n

Zmiana A record<\/strong> changes the IPv4 address returned for a hostname. Changing an rekord AAAA<\/strong> zmienia sw\u00f3j adres IPv6. Je\u015bli oba s\u0105 obecne, klienci mog\u0105 korzysta\u0107 z dowolnej rodziny adres\u00f3w w zale\u017cno\u015bci od ich sieci i zachowania po\u0142\u0105czenia.<\/p>\n\n\n\n

Zmiana rekord CNAME<\/strong> zmienia nazw\u0119 hosta, do kt\u00f3rej wskazuje alias. Rozwi\u0105zywanie nazw mo\u017ce wtedy wymaga\u0107 wyszukania docelowej nazwy oraz jej adresu. Zmiana w rekordach dotycz\u0105cych elementu docelowego mo\u017ce wp\u0142yn\u0105\u0107 na ostateczny wynik, nawet je\u015bli sam rekord CNAME pozostaje bez zmian.<\/p>\n\n\n\n

Zmiana Domena MX<\/strong> wp\u0142ywa na to, kt\u00f3re serwery pocztowe odbieraj\u0105 e-maile dla domeny. Systemy pocztowe mog\u0105 buforowa\u0107 te rekordy, a routowanie poczty mo\u017ce wymaga\u0107 czasu, aby odzwierciedli\u0107 aktualizacje. Przy zmianie dostawcy us\u0142ug pocztowych administratorzy powinni osobno zweryfikowa\u0107 rekordy MX oraz wszelkie powi\u0105zane rekordy uwierzytelniania poczty, takie jak SPF, DKIM lub DMARC.<\/p>\n\n\n\n

Zmienia si\u0119 namesery<\/strong> zmiany, kt\u00f3re sprawiaj\u0105, \u017ce dostawca DNS jest autorytatywny dla domeny. Wymaga to prawid\u0142owej delegacji u rejestratora oraz poprawnej konfiguracji strefy u nowego dostawcy. Migracja serwer\u00f3w nazw powinna by\u0107 starannie zaplanowana, poniewa\u017c brakuj\u0105ce rekordy u nowego dostawcy mog\u0105 spowodowa\u0107 niedost\u0119pno\u015b\u0107 stron internetowych, poczty e-mail lub innych us\u0142ug.<\/p>\n\n\n\n

Jak sprawdzi\u0107, czy zmiana DNS zosta\u0142a wprowadzona<\/h2>\n\n\n\n

Zacznij od zapytania o domen\u0119 z komputera, kt\u00f3rego u\u017cywasz. W systemach Windows, macOS i Linux nslookup<\/code> jest powszechnie dost\u0119pny:<\/p>\n\n\n\n

nslookup example.com<\/code><\/pre>\n\n\n\n
Aby sprawdzi\u0107 rekord adresu IPv4, u\u017cyj:<\/p>\n\n\n\n
nslookup -type=A example.com<\/code><\/pre>\n\n\n\n
Dla IPv6:<\/p>\n\n\n\n
nslookup -type=AAAA example.com<\/code><\/pre>\n\n\n\n
Dla rekord\u00f3w serwera pocztowego:<\/p>\n\n\n\n
nslookup -type=MX example.com<\/code><\/pre>\n\n\n\n
Na macOS i Linux, kop<\/code> dostarcza bardziej szczeg\u00f3\u0142owe dane wyj\u015bciowe:<\/p>\n\n\n\n
dig example.com A<\/code><\/pre>\n\n\n\n
Aby wy\u015bwietli\u0107 tylko sekcj\u0119 z odpowiedzi\u0105:<\/p>\n\n\n\n
dig example.com A +noall +answer<\/code><\/pre>\n\n\n\n
Mo\u017cesz zapyta\u0107 o konkretny rekurencyjny resolver, aby por\u00f3wna\u0107 odpowiedzi. Na przyk\u0142ad:<\/p>\n\n\n\n
dig @1.1.1.1 example.com A<\/code><\/pre>\n\n\n\n
W systemie Windows mo\u017cesz okre\u015bli\u0107 serwer DNS za pomoc\u0105:<\/p>\n\n\n\n
nslookup example.com 1.1.1.1<\/code><\/pre>\n\n\n\n
Zamie\u0144 example.com<\/code> z Twoj\u0105 domen\u0105. Adres resolvera w tych przyk\u0142adach to tylko jeden z mo\u017cliwych publicznych resolver\u00f3w; mo\u017cesz r\u00f3wnie\u017c skonsultowa\u0107 si\u0119 z us\u0142ug\u0105 DNS u\u017cywan\u0105 przez Twoj\u0105 organizacj\u0119 lub dostawc\u0119.<\/p>\n\n\n\n
Zapisz resolvera, kt\u00f3rego zapytano, odpowied\u017a oraz czas. Por\u00f3wnanie wynik\u00f3w z wielu resolver\u00f3w pomaga ustali\u0107, czy r\u00f3\u017cnica jest lokalna dla jednego resolvera, czy wyst\u0119puje szerzej.<\/p>\n\n\n\n
Jak zapyta\u0107 autorytatywny serwer nazw<\/h2>\n\n\n\n
Aby znale\u017a\u0107 autorytatywne serwery nazw dla domeny, u\u017cyj:<\/p>\n\n\n\n
dig example.com NS<\/code><\/pre>\n\n\n\n
Nast\u0119pnie zapytaj bezpo\u015brednio o rekord, kt\u00f3ry zmieni\u0142e\u015b, jeden z tych serwer\u00f3w nazw:<\/p>\n\n\n\n
dig @ns1.example-dns.com example.com A<\/code><\/pre>\n\n\n\n
Zamie\u0144 ns1.example-dns.com<\/code> z autorytatywnym serwerem wymienionym dla Twojej domeny. Je\u015bli bezpo\u015brednie zapytanie zwraca oczekiwany adres, ale resolver rekurencyjny zwraca starszy, dane autorytatywne zosta\u0142y zaktualizowane, a resolver mo\u017ce nadal u\u017cywa\u0107 skompresowanej odpowiedzi.<\/p>\n\n\n\n
Mo\u017cesz r\u00f3wnie\u017c zapyta\u0107 kop<\/code> \u015bledzi\u0107 proces delegowania:<\/p>\n\n\n\n
dig +trace example.com<\/code><\/pre>\n\n\n\n
Ma to miejsce w hierarchii DNS od korzenia w kierunku autorytatywnych serwer\u00f3w domeny. Mo\u017ce pom\u00f3c w identyfikacji problem\u00f3w z delegacj\u0105, cho\u0107 jego wynik jest bardziej szczeg\u00f3\u0142owy ni\u017c wi\u0119kszo\u015b\u0107 podstawowych kontroli wymaga.<\/p>\n\n\n\n
Je\u015bli korzystasz z panelu kontrolnego dostawcy DNS, upewnij si\u0119, \u017ce domena jest faktycznie delegowana do serwer\u00f3w nazw wy\u015bwietlanych w tym panelu. Rekord mo\u017ce by\u0107 poprawny w interfejsie jednego dostawcy, podczas gdy publiczna domena wskazuje na innego dostawc\u0119.<\/p>\n\n\n\n
Co je\u015bli niekt\u00f3rzy u\u017cytkownicy zobacz\u0105 star\u0105 stron\u0119 internetow\u0105?<\/h2>\n\n\n\n
Najpierw upewnij si\u0119, \u017ce autorytatywny rekord A lub AAAA ma oczekiwan\u0105 warto\u015b\u0107. Nast\u0119pnie zapytaj kilka rekurencyjnych resolver\u00f3w i sprawd\u017a, czy zwracaj\u0105 t\u0119 sam\u0105 odpowied\u017a. Je\u015bli dane autorytatywne s\u0105 poprawne, ale niekt\u00f3re resolversy zwracaj\u0105 starszy adres, prawdopodobn\u0105 przyczyn\u0105 jest buforowanie (cache).<\/p>\n\n\n\n
Nast\u0119pnie sprawd\u017a lokaln\u0105 konfiguracj\u0119 u\u017cytkownika. Sie\u0107 VPN, firmowy resolver DNS, produkt zabezpieczaj\u0105cy, pami\u0119\u0107 podr\u0119czna przegl\u0105darki lub lokalny plik hosts mog\u0105 wp\u0142ywa\u0107 na to, jaki adres zostanie zwr\u00f3cony. Por\u00f3wnaj wynik uzyskany z innej sieci, np. po\u0142\u0105czenia mobilnego, aby sprawdzi\u0107, czy zachowanie si\u0119 zmienia.<\/p>\n\n\n\n
Rozwa\u017c r\u00f3wnie\u017c, czy stare i nowe serwery odpowiadaj\u0105 na zapytania. Migracja mo\u017ce wydawa\u0107 si\u0119 niesp\u00f3jna, je\u015bli stary host nadal dostarcza zbuforowan\u0105 kopi\u0119 lub przekierowania dzia\u0142aj\u0105 inaczej. Rekord DNS mo\u017ce by\u0107 poprawny, podczas gdy stary serwer pozostaje dost\u0119pny dla u\u017cytkownik\u00f3w, kt\u00f3rych resolver nie od\u015bwie\u017cy\u0142 jeszcze danych.<\/p>\n\n\n\n
Je\u015bli problem dotyczy tylko IPv4 lub tylko IPv6, por\u00f3wnaj rekordy A i AAAA osobno. Urz\u0105dzenie mo\u017ce \u0142\u0105czy\u0107 si\u0119 przez IPv6, podczas gdy inne u\u017cywa IPv4. Jedna rodzina adres\u00f3w mo\u017ce wskazywa\u0107 na nowy serwer, podczas gdy druga nadal wskazuje na stary.<\/p>\n\n\n\n
Co zrobi\u0107, je\u015bli witryna jest niedost\u0119pna po zmianie DNS?<\/h2>\n\n\n\n
Sprawd\u017a, czy autorytatywne serwery nazw domeny s\u0105 poprawne i dost\u0119pne. Nast\u0119pnie zweryfikuj, czy odpowiednie rekordy istniej\u0105 na tych serwerach. Je\u015bli ostatnio zmieni\u0142e\u015b serwery nazw, upewnij si\u0119, \u017ce nowy dostawca DNS ma wszystkie wymagane rekordy, w tym rekordy dla strony internetowej, poczty e-mail, weryfikacji oraz us\u0142ug.<\/p>\n\n\n\n
Upewnij si\u0119, \u017ce serwer docelowy jest gotowy do przyjmowania po\u0142\u0105cze\u0144 dla domeny. Aktualizacja DNS zmienia tylko kierunek, w kt\u00f3rym s\u0105 przekierowani klienci. Nie konfiguruje ona serwera WWW, nie instaluje certyfikatu, nie otwiera portu zapory sieciowej ani nie kopiuje plik\u00f3w witryny.<\/p>\n\n\n\n
Je\u015bli DNS zwraca oczekiwany adres IP, ale strona internetowa nadal nie dzia\u0142a, przetestuj serwer i aplikacj\u0119 osobno. Problem mo\u017ce le\u017ce\u0107 po stronie serwera WWW, zapory sieciowej, certyfikatu TLS, konfiguracji hostingu lub aplikacji. Wyszukiwanie DNS potwierdza poprawn\u0105 resolucj\u0119 nazw; nie potwierdza jednak, \u017ce us\u0142uga jest zdrowa.<\/p>\n\n\n\n
Aby sprawdzi\u0107 og\u00f3ln\u0105 \u015bcie\u017ck\u0119 mi\u0119dzy Twoim urz\u0105dzeniem a miejscem docelowym, zapoznaj si\u0119 z naszym przewodnikiem po u\u017cywanie traceroute do diagnozowania problem\u00f3w z po\u0142\u0105czeniem sieciowym<\/a>Traceroute i wyszukiwania DNS testuj\u0105 r\u00f3\u017cne cz\u0119\u015bci po\u0142\u0105czenia, dlatego s\u0105 przydatne w po\u0142\u0105czeniu podczas zaw\u0119\u017cania zakresu problemu.<\/p>\n\n\n\n
Negatywne buforowanie i wyniki \u201eNie znaleziono rekordu\u201d<\/h2>\n\n\n\n
Resolwery mog\u0105 buforowa\u0107 informacj\u0119 o tym, \u017ce rekord nie istnieje. Nazywa si\u0119 to negatywnym buforowaniem. Je\u015bli resolver zapyta\u0142 o nazw\u0119 przed utworzeniem rekordu, mo\u017ce tymczasowo nadal zwraca\u0107 odpowied\u017a \u201enie znaleziono\u201d, nawet po dodaniu rekordu.<\/p>\n\n\n\n
Negatywne buforowanie r\u00f3wnie\u017c ma ustawiony czas \u017cycia (TTL), oparty na informacjach zawartych w rekordzie SOA strefy oraz zasadach resolvera. Dok\u0142adne zachowanie mo\u017ce si\u0119 r\u00f3\u017cni\u0107. Je\u015bli nowo utworzona subdomena nie rozwi\u0105zuje si\u0119 natychmiast, najpierw sprawd\u017a autorytatywny serwer nazw. Je\u015bli zwr\u00f3ci on nowy rekord, poczekaj na wyga\u015bni\u0119cie negatywnych cache'\u00f3w i por\u00f3wnaj wyniki innych resolver\u00f3w.<\/p>\n\n\n\n
Odpowied\u017a \u201erecord not found\u201d mo\u017ce r\u00f3wnie\u017c oznacza\u0107, \u017ce rekord zosta\u0142 dodany do niew\u0142a\u015bciwej strefy, nazwa hosta zosta\u0142a wpisana niepoprawnie lub domena korzysta z innych autorytatywnych serwer\u00f3w nazw. Przed za\u0142o\u017ceniem, \u017ce problem wynika wy\u0142\u0105cznie z op\u00f3\u017anie\u0144 w propagacji, upewnij si\u0119 co do pe\u0142nej nazwy hosta, typu rekordu oraz dostawcy DNS.<\/p>\n\n\n\n
Jak zaplanowa\u0107 migracj\u0119 DNS<\/h2>\n\n\n\n
Przed wprowadzeniem zmian w rekordach dla us\u0142ugi produkcyjnej, wypisz wszystkie nazwy host\u00f3w i rekordy, od kt\u00f3rych us\u0142uga ta zale\u017cy. Strona internetowa mo\u017ce korzysta\u0107 z rekord\u00f3w A i AAAA, podczas gdy poczta elektroniczna zale\u017cy od rekord\u00f3w MX, SPF, DKIM oraz DMARC. Aplikacje mog\u0105 r\u00f3wnie\u017c polega\u0107 na rekordach weryfikacyjnych lub s\u0142u\u017c\u0105cych do odkrywania us\u0142ug.<\/p>\n\n\n\n
Je\u015bli zmiana jest zaplanowana, z wyprzedzeniem skr\u00f3\u0107 odpowiedni czas TTL i odczekaj co najmniej poprzedni okres TTL przed prze\u0142\u0105czeniem celu. Przygotuj nowy serwer lub dostawc\u0119 przed aktualizacj\u0105 DNS. Przetestuj bezpo\u015brednio tam, gdzie to mo\u017cliwe, i upewnij si\u0119, \u017ce certyfikaty, regu\u0142y zapory sieciowej, ustawienia aplikacji oraz us\u0142ugi pocztowe s\u0105 gotowe.<\/p>\n\n\n\n
Po zmianie sprawd\u017a autorytatywne odpowiedzi oraz kilka rekurencyjnych resolver\u00f3w. Monitoruj dost\u0119pno\u015b\u0107 witryny internetowej, dostarczanie wiadomo\u015bci e-mail oraz b\u0142\u0119dy aplikacji. Przez czas przej\u015bcia utrzymuj star\u0105 us\u0142ug\u0119 w stanie dost\u0119pnym, o ile jest to mo\u017cliwe, poniewa\u017c niekt\u00f3rzy u\u017cytkownicy mog\u0105 nadal z niej korzysta\u0107, zanim wygasn\u0105 wygas\u0142e odpowiedzi z pami\u0119ci podr\u0119cznej.<\/p>\n\n\n\n
Po ustabilizowaniu si\u0119 nowej konfiguracji przywr\u00f3\u0107 odpowiedni\u0105 warto\u015b\u0107 TTL. Utrzymywanie bardzo niskiego TTL przez d\u0142ugi czas mo\u017ce zwi\u0119kszy\u0107 liczb\u0119 zapyta\u0144 DNS bez znacz\u0105cej korzy\u015bci dla us\u0142ugi, kt\u00f3ra rzadko ulega zmianom.<\/p>\n\n\n\n
Powszechne nieporozumienia dotycz\u0105ce propagacji DNS<\/h2>\n\n\n\n
Jednym z powszechnych nieporozumie\u0144 jest przekonanie, \u017ce ka\u017cda zmiana w DNS trwa dok\u0142adnie 24 lub 48 godzin. Nie istnieje sta\u0142y, uniwersalny czas oczekiwania. Rzeczywiste op\u00f3\u017anienie zale\u017cy od poprzednich warto\u015bci TTL, buforowania przez resolvery, zmian delegacji oraz poprawno\u015bci konfiguracji serwer\u00f3w autorytatywnych.<\/p>\n\n\n\n
Kolejne nieporozumienie polega na przekonaniu, \u017ce czyszczenie pami\u0119ci podr\u0119cznej przegl\u0105darki aktualizuje DNS we wszystkich miejscach. Mo\u017ce ono wyczy\u015bci\u0107 informacje przechowywane na tym urz\u0105dzeniu, ale nie mo\u017ce wyczy\u015bci\u0107 pami\u0119ci podr\u0119cznej zdalnego resolvera rekurencyjnego. Podobnie restart routera mo\u017ce wyczy\u015bci\u0107 jego lokaln\u0105 pami\u0119\u0107 podr\u0119czn\u0105, ale nie zmienia rekord\u00f3w autorytatywnych.<\/p>\n\n\n\n
Kolejne nieporozumienie polega na przekonaniu, \u017ce DNS checker pokazuj\u0105cy r\u00f3\u017cne odpowiedzi dowodzi, i\u017c domena jest uszkodzona. R\u00f3\u017cne odpowiedzi mog\u0105 wyst\u0105pi\u0107 podczas zaplanowanej migracji, szczeg\u00f3lnie gdy resolvery maj\u0105 w pami\u0119ci podr\u0119cznej dane pobrane w r\u00f3\u017cnych momentach. Wa\u017cne pytanie brzmi: czy rekordy autorytatywne s\u0105 poprawne i czy pozosta\u0142e r\u00f3\u017cnice s\u0105 zgodne z poprzednim czasem \u017cycia (TTL).<\/p>\n\n\n\n
Ostatecznie propagacja DNS nie konfiguruje us\u0142ugi docelowej. Poprawny adres IP mo\u017ce nadal prowadzi\u0107 do niedost\u0119pnej strony internetowej, je\u015bli serwer, zapora sieciowa, certyfikat TLS lub aplikacja nie s\u0105 gotowe.<\/p>\n\n\n\n
Cz\u0119sto zadawane pytania dotycz\u0105ce propagacji DNS<\/h2>\n\n\n\n
Jak d\u0142ugo trwa propagacja DNS?<\/h3>\n\n\n\n
Nie ma jednego, gwarantowanego czasu. Niekt\u00f3re zmiany pojawiaj\u0105 si\u0119 szybko, podczas gdy inne pozostaj\u0105 niekonsekwentne do momentu wyga\u015bni\u0119cia rekord\u00f3w w pami\u0119ci podr\u0119cznej. Poprzedni czas TTL, zachowanie resolvera oraz to, czy serwery nazw uleg\u0142y zmianie, wp\u0142ywaj\u0105 na czas propagacji.<\/p>\n\n\n\n
Czy obni\u017cenie warto\u015bci TTL powoduje natychmiastow\u0105 zmian\u0119?<\/h3>\n\n\n\n
Nie. Obni\u017cenie warto\u015bci TTL wp\u0142ywa na przysz\u0142e buforowanie po tym, jak resolverzy pobior\u0105 nowy TTL. Resolvery, kt\u00f3re ju\u017c zbuforowa\u0142y stary rekord, mog\u0105 nadal go u\u017cywa\u0107 do momentu wyga\u015bni\u0119cia jego poprzedniego TTL.<\/p>\n\n\n\n
Dlaczego sprawdzacze DNS pokazuj\u0105 r\u00f3\u017cne wyniki?<\/h3>\n\n\n\n
Mog\u0105 one odpytywa\u0107 r\u00f3\u017cne rekurencyjne serwery DNS z r\u00f3\u017cnych lokalizacji. Te serwery mog\u0105 mie\u0107 r\u00f3\u017cne odpowiedzi w pami\u0119ci podr\u0119cznej, od\u015bwie\u017ca\u0107 je w r\u00f3\u017cnych odst\u0119pach czasu lub otrzymywa\u0107 r\u00f3\u017cne odpowiedzi ze wzgl\u0119du na geograficzne polityki DNS.<\/p>\n\n\n\n
Czy powinienem wyczy\u015bci\u0107 pami\u0119\u0107 podr\u0119czn\u0105 DNS mojego komputera?<\/h3>\n\n\n\n
Mo\u017ce pom\u00f3c, gdy Twoje urz\u0105dzenie ma w pami\u0119ci podr\u0119cznej star\u0105 odpowied\u017a. Nie czy\u015bci cache'u utrzymywanego przez dostawc\u0119 internetu, resolver firmowy lub publiczn\u0105 us\u0142ug\u0119 DNS.<\/p>\n\n\n\n
Dlaczego moja strona internetowa si\u0119 rozwi\u0105zuje, ale nadal nie \u0142aduje si\u0119?<\/h3>\n\n\n\n
DNS mo\u017ce zwraca\u0107 prawid\u0142owy adres, podczas gdy serwer docelowy lub aplikacja ma problem. Sprawd\u017a osobno serwer WWW, zapora sieciow\u0105, certyfikat TLS oraz konfiguracj\u0119 hostingu.<\/p>\n\n\n\n
Czy zmiany serwer\u00f3w nazw mog\u0105 trwa\u0107 d\u0142u\u017cej ni\u017c zmiany rekord\u00f3w?<\/h3>\n\n\n\n
Mog\u0105 one obejmowa\u0107 dodatkowe informacje o delegacji na poziomie rejestratora i nadrz\u0119dnego strefy DNS. Nowy dostawca musi r\u00f3wnie\u017c udost\u0119pnia\u0107 kompletn\u0105 i poprawn\u0105 stref\u0119. Zweryfikuj zar\u00f3wno delegacj\u0119, jak i rekordy na nowych serwerach autorytatywnych.<\/p>\n\n\n\n
Zmiany w DNS mog\u0105 pojawia\u0107 si\u0119 w r\u00f3\u017cnych momentach, poniewa\u017c serwery nazw autorytatywne i rekurencyjne resolvery pe\u0142ni\u0105 r\u00f3\u017cne role, a resolvery buforuj\u0105 odpowiedzi zgodnie z warto\u015bciami TTL. U\u017cytkownik mo\u017ce widzie\u0107 stary adres, podczas gdy inny ju\u017c otrzymuje nowy.<\/p>\n\n\n\n
Aby przeprowadzi\u0107 badanie, najpierw sprawd\u017a autorytatywne serwery nazw, a nast\u0119pnie por\u00f3wnaj odpowiedzi z kilku rekurencyjnych resolver\u00f3w. Potwierd\u017a typ rekordu, nazw\u0119 hosta, TTL oraz delegacj\u0119 serwer\u00f3w nazw. Je\u015bli DNS zwraca oczekiwany adres, ale us\u0142uga pozostaje niedost\u0119pna, sprawd\u017a serwer docelowy i aplikacj\u0119 jako oddzielne elementy problemu.<\/p>\n\n\n\n
Zrozumienie dzia\u0142ania buforowania u\u0142atwia planowanie i rozwi\u0105zywanie problem\u00f3w ze zmianami w DNS. Aby pozna\u0107 wi\u0119cej podstaw sieciowych, kontynuuj lektur\u0119 naszych przewodnik\u00f3w po Adresy IP<\/a>, domy\u015blne bramki przej\u015bcia<\/a>, i traceroute<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"
You update a domain\u2019s DNS records, save the change, and expect the new website or mail service to work immediately. But a colleague still sees the old website, an online checker shows a different address, or email delivery behaves inconsistently. This delay is commonly called DNS propagation. The phrase can make it sound as though […]<\/p>\n","protected":false},"author":1,"featured_media":2344,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"What Is DNS Propagation? Why DNS Changes Take Time","_seopress_titles_desc":"Learn why DNS changes take time to appear, how caching and TTL affect updates, and how to check whether a domain is returning the expected records.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-2342","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article"],"_links":{"self":[{"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/posts\/2342","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/comments?post=2342"}],"version-history":[{"count":1,"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/posts\/2342\/revisions"}],"predecessor-version":[{"id":2343,"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/posts\/2342\/revisions\/2343"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/media\/2344"}],"wp:attachment":[{"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/media?parent=2342"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/categories?post=2342"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/junglelabs.uk\/pl\/wp-json\/wp\/v2\/tags?post=2342"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}