Sprawdzanie propagacji DNS online

Jak sprawdzamy — i czego to sprawdzenie nie pokazuje

Zapytania wychodzą z naszego serwera do 15 publicznych resolverów różnych operatorów przez DNS-over-HTTPS oraz bezpośrednio do autorytatywnych serwerów NS domeny. Większość publicznych DNS działa w anycast: odpowiada punkt obecności najbliższy naszemu serwerowi, a nie serwery w różnych krajach. To porównanie „jak domenę widzą różne publiczne DNS”, a nie test „z 30 krajów świata”.

Nie widzimy resolvera Twojego dostawcy internetu, routera ani bufora Twojego komputera — mogą trzymać starą odpowiedź, nawet gdy wszystkie publiczne DNS są już zaktualizowane. Wynik jest buforowany na 60 sekund.

Dlaczego zmiana DNS rozchodzi się do 24–48 godzin

Nowa wartość pojawia się na autorytatywnych NS niemal od razu po zapisaniu w panelu. Ale każdy resolver, który już pytał o rekord, trzyma starą odpowiedź w buforze do końca jej TTL i dopiero potem pyta ponownie. Przy TTL 3600 to do godziny, przy 86400 — do doby.

Najdłużej trwa zmiana serwerów NS u rejestratora: delegacja w strefie domeny najwyższego poziomu (.com, .pl, .eu…) bywa buforowana przez 1–2 doby. Stąd znane „24–48 godzin”. Jak przyspieszyć przenosiny i wyczyścić lokalny bufor — w poradniku poniżej.

Narzędzie pokazuje, czy rekordy DNS domeny zaktualizowały się w różnych publicznych resolverach. Równolegle odpytujemy 15 usług przez DNS-over-HTTPS (Google Public DNS, Cloudflare, Quad9, OpenDNS, AdGuard, NextDNS, Control D, Mullvad, DNS.SB, AliDNS, DNS4EU, SWITCH, CZ.NIC, Yandex, IIJ) oraz bezpośrednio autorytatywne serwery NS strefy. Przy każdej odpowiedzi widać wartość, pozostały TTL i czas odpowiedzi; identyczne odpowiedzi są pogrupowane, a rozbieżności podświetlone. Możesz podać oczekiwaną wartość — np. nowy IP — i od razu zobaczyć, kto już ją zwraca. Sprawdzenie jest darmowe, wynik jest buforowany na 60 sekund.

15 publicznych resolverów DNS różnych operatorów, odpytywanych równolegle w 1–2 sekundy

Bezpośrednie zapytanie do autorytatywnych NS domeny jako punkt odniesienia

Rekordy A, AAAA, CNAME, MX, TXT, NS, SOA i CAA, także dla subdomen takich jak www i _dmarc

Pozostały TTL każdego resolvera i szacunek, jak długo może utrzymać się stara odpowiedź

Grupowanie identycznych odpowiedzi i podświetlanie rozbieżności

Pole „oczekiwana wartość”: znacznik przy każdym resolverze, czy zwraca już nowy IP lub rekord

Jak korzystać

Wpisz domenę lub subdomenę (możesz wkleić adres strony — weźmiemy z niego nazwę hosta)
Wybierz typ rekordu i, jeśli trzeba, wpisz oczekiwaną wartość — np. nowy IP serwera
Porównaj odpowiedzi z autorytatywnymi NS; jeśli część resolverów zostaje w tyle, kliknij „Sprawdź ponownie” później — orientacyjny czas podaje ich TTL

FAQ

Nie i nie przedstawiamy go w ten sposób. Wszystkie zapytania wychodzą z naszego serwera, a większość publicznych DNS działa w anycast i odpowiada z punktu najbliższego temu serwerowi. Narzędzie pokazuje, jak domenę widzą różni operatorzy DNS i same autorytatywne serwery domeny — to wystarcza, by ocenić, czy zmiana się rozeszła.

Nie dłużej niż poprzedni TTL tego rekordu: resolvery, które zbuforowały starą wartość, zapytają ponownie po jego wygaśnięciu. Zmiana NS u rejestratora trwa dłużej — do 24–48 godzin, bo delegacja w strefie domeny jest buforowana na dobę lub dwie.

Tak działają CDN, load balancery i GeoDNS: serwer autorytatywny zwraca różne adresy zależnie od pytającego albo rotacyjnie. Jeśli w naszym raporcie autorytatywne NS też odpowiadają różnie, rozbieżność jest normalna, a nie problemem propagacji.

Starą odpowiedź trzyma DNS Twojego dostawcy, router, system operacyjny lub przeglądarka — tego nie możemy sprawdzić. Wyczyść bufor DNS w komputerze i przeglądarce albo tymczasowo przełącz się na publiczny DNS; jak to zrobić, opisuje poradnik na tej stronie.

Do 6 sprawdzeń na minutę z jednego IP oraz dzienny limit darmowych sprawdzeń, trzykrotnie wyższy po darmowej rejestracji. Powtórne zapytanie o tę samą domenę i typ w ciągu 60 sekund jest obsługiwane z bufora i nie zużywa limitu dziennego.

Czym jest propagacja DNS i dlaczego rekordy nie zmieniają się od razu

„Propagacja DNS” to nieścisły, ale przyjęty termin. Rekordy nigdzie nie są rozsyłane: po zapisaniu w panelu nowa wartość niemal od razu pojawia się na autorytatywnych serwerach NS Twojej strefy. Opóźnienia biorą się z buforów. Każdy resolver (DNS dostawcy internetu, Google, Cloudflare, router, system operacyjny, przeglądarka), który już pytał o Twoją domenę, trzyma starą odpowiedź do końca jej TTL i dopiero potem pyta ponownie. Dlatego sprawdzanie propagacji DNS to zawsze pytanie: „kto ma jeszcze w buforze starą wartość?”.

W raporcie powyżej widać to wprost: wiersze autorytatywnych NS pokazują aktualną wartość strefy, wiersze publicznych resolverów — co oddają użytkownikom w tej chwili. Jeśli NS zwracają już nową wartość, a część resolverów starą, nic nie zepsułeś: trzeba poczekać, aż wygaśnie u nich TTL.

TTL: jak go czytać i ile czekać

TTL (time to live) to liczba sekund, na jaką resolver może zbuforować rekord. Na serwerze autorytatywnym widzisz pełny TTL, w publicznym resolverze — resztę: ile sekund jeszcze będzie zwracał to, co już zna.

TTL	Jak długo żyje stara odpowiedź	Gdzie występuje
60–300	1–5 minut	Cloudflare z proxy (Auto = 300), rekordy przed przenosinami, równoważenie ruchu
3600	do godziny	wartość domyślna u wielu rejestratorów i hostingów
14400–86400	4–24 godziny	MX, TXT, NS; stare strefy, w których nikt nie zmieniał TTL
172800	do 2 dób	delegacja NS w strefie .com/.net i wielu innych domen najwyższego poziomu

Ważny szczegół: czeka się według starego TTL. Jeśli rekord miał TTL 86400, a Ty razem ze zmianą IP ustawiłeś 300, resolvery, które pobrały odpowiedź wczoraj, i tak będą ją trzymać do doby — nowy TTL poznają dopiero przy kolejnym zapytaniu.

Osobno buforowane są odpowiedzi negatywne. Jeśli otworzyłeś new.example.com, zanim utworzyłeś rekord, resolver zapamięta NXDOMAIN na czas wynikający z rekordu SOA strefy (mniejsza z wartości: TTL samego SOA i pole minimum). Te wartości zobaczysz, wybierając w narzędziu typ SOA.

Propagacja DNS — ile trwa zmiana rekordu A i jak ją przyspieszyć

Co najmniej jeden stary TTL wcześniej (bezpiecznie: dobę) obniż TTL rekordów A/AAAA do 300.
Poczekaj, aż publiczne resolvery w raporcie przestaną pokazywać TTL większy niż 300 — stary, długi TTL się wyczerpał.
Zmień IP. W polu „oczekiwana wartość” wpisz nowy adres i sprawdzaj: po 5–10 minutach prawie wszystkie resolvery powinny go zwracać.
Nie wyłączaj starego serwera jeszcze przez dobę: dostawcy i sieci firmowe ignorujące krótki TTL przez jakiś czas będą tam kierować część odwiedzających.
Gdy wszystko działa stabilnie, przywróć TTL 3600 lub wyższy.

Z pocztą jest tak samo: przy zmianie MX stary serwer pocztowy musi przyjmować wiadomości co najmniej przez stary TTL rekordu MX. Wynik potwierdzą sprawdzanie rekordów MX i sprawdzanie SPF — przy przenosinach poczty SPF najczęściej zostaje nieaktualny.

Zmiana serwerów NS: dlaczego 24–48 godzin i jak bezpiecznie się przenieść

Zmieniając dostawcę DNS, zmieniasz NS u rejestratora. Rejestrator przekazuje je do rejestru domeny zwykle w ciągu minut do godziny, ale resolvery, które znają już starą delegację, trzymają ją do końca TTL rekordów NS w strefie nadrzędnej — dla .com to 172800 sekund, czyli dwie doby. Dopóki bufor nie wygaśnie, część odwiedzających pyta stare NS, a część nowe.

Stąd główna zasada: strefa u starego i nowego dostawcy DNS musi być identyczna przez cały czas przenosin. Przenieś wszystkie rekordy (A, AAAA, CNAME, MX, TXT z SPF, DKIM i weryfikacjami) do nowego dostawcy przed zmianą NS, a starej strefy nie usuwaj przez co najmniej dwie doby. Wtedy nie ma znaczenia, do którego NS trafi resolver — odpowiedź będzie poprawna.

Jak sprawdzić: wybierz typ NS — publiczne resolvery pokażą, jaką delegację mają w buforze. Potem typ SOA: widać w nim serwer główny (mname) i numer seryjny strefy. Jeśli autorytatywne NS w raporcie odpowiadają różnie, strefa nie jest między nimi zsynchronizowana. Co jest ustawione u rejestratora, pokaże WHOIS domeny.

Cloudflare: pomarańczowa chmurka i „obce” adresy IP

Jeśli rekord w Cloudflare jest proxowany (pomarańczowa chmurka), resolvery zwracają adresy IP Cloudflare, a nie Twojego serwera, z TTL 300. Dlatego przy zmianie serwera za Cloudflare nie czeka się na propagację DNS: zmieniasz IP origin w panelu, publiczne adresy zostają te same, a Cloudflare niemal od razu zaczyna łączyć się z nowym serwerem. Prawdziwy IP pojawi się w raporcie tylko po przełączeniu rekordu w tryb „DNS only” (szara chmurka) — nie warto tego robić dla samego sprawdzenia, bo ujawnia to adres origin.

Sytuacja odwrotna: domena została właśnie podłączona do Cloudflare, a część resolverów w raporcie zwraca dawny IP hostingu. To nie błąd Cloudflare, tylko stare NS w buforze — zobacz sekcję o zmianie NS.

Dlaczego u dostawcy internetu wciąż jest stary IP

Bufor dostawcy. Niektórzy dostawcy podnoszą minimalny TTL albo oddają przeterminowaną odpowiedź, gdy nie mogą szybko pobrać nowej (serve-stale, RFC 8767). Tego resolvera nie widzimy, więc raport może być cały zielony, a Ty wciąż widzisz starą stronę.
Bufor urządzenia i przeglądarki. Windows, macOS i przeglądarki mają własne bufory DNS.
Plik hosts. Wpis w C:\Windows\System32\drivers\etc\hosts lub /etc/hosts pozostawiony po testach nadpisuje każdy DNS.
Bezpieczny DNS w przeglądarce. Gdy w Chrome włączony jest „Bezpieczny DNS”, przeglądarka pyta wybranego dostawcę zamiast systemowego DNS — wyniki w przeglądarce i w wierszu poleceń mogą się różnić.

Jak wyczyścić bufor DNS: Windows, macOS, Linux, Chrome

Windows (wiersz polecenia jako administrator):

ipconfig /flushdns

macOS (Terminal):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux z systemd-resolved:

resolvectl flush-caches

Chrome: otwórz chrome://net-internals/#dns i kliknij „Clear host cache”, a potem na chrome://net-internals/#sockets — „Flush socket pools”. Firefox: about:networking#dns, przycisk „Clear DNS Cache”.

Duże publiczne resolvery pozwalają poprosić o odświeżenie konkretnej nazwy: Google Public DNS ma stronę Flush Cache, a Cloudflare 1.1.1.1 — Purge Cache. Bufora dostawcy internetu w ten sposób nie wyczyścisz: zostaje poczekać na TTL albo tymczasowo ustawić publiczny DNS w ustawieniach sieci.

Wszystkie rekordy domeny jednym zapytaniem pokazuje DNS Lookup.