# Sprawdzanie propagacji DNS: ile czeka Twoja zmiana URL: https://notificationharbor.com/pl/tools/sprawdzanie-propagacji-dns Type: tool Locale: pl Published: 2026-10-07 Updated: 2026-10-08 --- > Oszacuj najdłuższe oczekiwanie po zmianie DNS na podstawie TTL i czasu od edycji. Działa w przeglądarce i obejmuje rekordy, nowe klucze DKIM oraz zmianę serwerów nazw. ## Sprawdzanie propagacji DNS: kiedy Twoja zmiana zacznie działać Podaj TTL i czas od edycji. To sprawdzanie propagacji DNS pokaże najdłuższe pozostałe oczekiwanie po zmianie rekordu, nowego klucza DKIM lub serwerów nazw. ## Sprawdzanie propagacji DNS Wybierz rodzaj zmiany, wpisz obowiązujący TTL i czas od zapisania. Wynik aktualizuje się podczas pisania, a nic nie opuszcza Twojej przeglądarki. *[Interactive widget — see the live page for the full experience]* ## Co naprawdę mierzy ten kalkulator ### Propagacja to wygasanie cache DNS niczego nigdzie nie wypycha. Każdy resolver przechowuje pobraną odpowiedź do końca TTL, a potem pyta ponownie. Najwolniejszy jest resolver, który pobrał starą odpowiedź tuż przed Twoją edycją, więc najgorszy przypadek równa się staremu TTL. ### Nowe rekordy mają własny zegar Rekord, którego wcześniej nie było, może zostać zapisany w cache jako nieistniejący. Ta negatywna odpowiedź trwa krócej z dwóch wartości: TTL rekordu SOA lub pola minimum SOA. Jeśli nikt nie odpytał nazwy wcześniej, nowy rekord widać od razu. ### Zmiana serwerów nazw zależy od rejestratora Zmiana serwerów nazw zmienia rekordy NS w strefie nadrzędnej, a TTL tych rekordów nie ustawiasz Ty. Kalkulator przyjmuje go jako dane wejściowe, z dwoma dniami jako typową wartością dla dużych TLD, np. .com. ## Cztery kroki, które skracają oczekiwanie 1. **Odczytaj obecny TTL** — Uruchom dig na rekordzie i odczytaj liczbę w sekcji answer. To TTL, który Twoja zmiana musi przetrwać. 2. **Obniż go wcześniej** — Ustaw TTL na 300 sekund, a potem poczekaj co najmniej tyle, ile wynosił stary TTL, zanim edytujesz rekord. Resolwery muszą najpierw wygasić długo żyjącą kopię. 3. **Wprowadź zmianę i zapisz godzinę** — Zapisz edycję, zanotuj godzinę i wpisz czas, który upłynął, do kalkulatora powyżej. 4. **Sprawdź u źródła, potem w resolverze** — Najpierw zapytaj swój autorytatywny serwer nazw, a potem publiczny resolver. Gdy oba zwracają nową wartość i okno minęło, przywróć wyższy TTL. ## Najczęstsze pytania ### Czy to sprawdzanie propagacji DNS jest darmowe? Tak. Bez rejestracji i bez limitu zapytań. Obliczenie to arytmetyka na trzech liczbach, które wpisujesz, więc działa w przeglądarce i nic nie jest wysyłane na nasze serwery. ### Czy narzędzie odpytuje działające serwery DNS? Nie. Nie sprawdza rekordu na resolverach na całym świecie. Oblicza najdłuższy czas, przez jaki odpowiedź z cache może przetrwać, na podstawie wpisanego TTL. Aby zobaczyć, co dany resolver zwraca teraz, uruchom dig względem tego resolvera i porównaj wynik z pokazanym oknem. ### Dlaczego szacunek używa starego TTL, a nie nowego? Resolwery zapisują odpowiedź pobraną przed Twoją edycją razem z jej TTL. Obniżenie TTL w tej samej edycji nic nie daje resolverom, które już mają starą odpowiedź. Nowy TTL dotyczy tylko odpowiedzi pobranych po zmianie. ### Czym jest negatywny TTL cache i kiedy działa? Gdy resolver pyta o nazwę bez rekordu, może zapisać odpowiedź „nie istnieje” (RFC 2308). Trwa ona krócej z dwóch wartości: TTL samego rekordu SOA lub jego pola minimum. Dotyczy tylko resolverów, które odpytały nazwę przed utworzeniem rekordu, na przykład selektor DKIM, który ktoś przetestował za wcześnie. ### Dlaczego zmiana serwerów nazw trwa tak długo? Rekordy NS wskazujące na Twoje serwery nazw znajdują się u rejestratora, z TTL, którego nie kontrolujesz. Dla dużych TLD, np. .com, ten TTL wynosi zwykle dwa dni. Do jego wygaśnięcia część resolverów wciąż pyta Twoje stare serwery nazw. ### Minął czas okna, a nadal widzę starą wartość. Co dalej? Nie obwiniaj cache. Zapytaj bezpośrednio swój autorytatywny serwer nazw i potwierdź, że zwraca nową wartość. Jeśli nie, edycja trafiła do złej strefy, złej nazwy hosta albo nie została zapisana. Jeśli tak, testuj z resolvera, którego jeszcze nie używałeś, i sprawdź lokalny cache na swoim komputerze lub w sieci. ### Czy dotyczy to rekordów SPF, DKIM i DMARC? Tak. To rekordy TXT, zapisywane w cache jak każde inne. Serwer odbiorcy, który zapisał stary rekord SPF, ocenia wysyłkę według niego aż do wygaśnięcia TTL, więc wysyłka tuż po edycji może zostać oceniona według starej polityki. ## Śledź infrastrukturę Twoich wysyłek To narzędzie szacuje czas oczekiwania. Notification Harbor obejmuje wysyłki, które kontrolujesz: rozgrzewanie domeny, obserwowalność na poziomie śladów oraz poprawnie skonfigurowane SPF, DKIM i DMARC przed pierwszą produkcyjną wysyłką. *Call to action: Zobacz, jak działa Notification Harbor* ## FAQ ### Czy to sprawdzanie propagacji DNS jest darmowe? Tak. Bez rejestracji i bez limitu zapytań. Obliczenie to arytmetyka na trzech liczbach, które wpisujesz, więc działa w przeglądarce i nic nie jest wysyłane na nasze serwery. ### Czy narzędzie odpytuje działające serwery DNS? Nie. Nie sprawdza rekordu na resolverach na całym świecie. Oblicza najdłuższy czas, przez jaki odpowiedź z cache może przetrwać, na podstawie wpisanego TTL. Aby zobaczyć, co dany resolver zwraca teraz, uruchom dig względem tego resolvera i porównaj wynik z pokazanym oknem. ### Dlaczego szacunek używa starego TTL, a nie nowego? Resolwery zapisują odpowiedź pobraną przed Twoją edycją razem z jej TTL. Obniżenie TTL w tej samej edycji nic nie daje resolverom, które już mają starą odpowiedź. Nowy TTL dotyczy tylko odpowiedzi pobranych po zmianie. ### Czym jest negatywny TTL cache i kiedy działa? Gdy resolver pyta o nazwę bez rekordu, może zapisać odpowiedź „nie istnieje” (RFC 2308). Trwa ona krócej z dwóch wartości: TTL samego rekordu SOA lub jego pola minimum. Dotyczy tylko resolverów, które odpytały nazwę przed utworzeniem rekordu, na przykład selektor DKIM, który ktoś przetestował za wcześnie. ### Dlaczego zmiana serwerów nazw trwa tak długo? Rekordy NS wskazujące na Twoje serwery nazw znajdują się u rejestratora, z TTL, którego nie kontrolujesz. Dla dużych TLD, np. .com, ten TTL wynosi zwykle dwa dni. Do jego wygaśnięcia część resolverów wciąż pyta Twoje stare serwery nazw. ### Minął czas okna, a nadal widzę starą wartość. Co dalej? Nie obwiniaj cache. Zapytaj bezpośrednio swój autorytatywny serwer nazw i potwierdź, że zwraca nową wartość. Jeśli nie, edycja trafiła do złej strefy, złej nazwy hosta albo nie została zapisana. Jeśli tak, testuj z resolvera, którego jeszcze nie używałeś, i sprawdź lokalny cache na swoim komputerze lub w sieci. ### Czy dotyczy to rekordów SPF, DKIM i DMARC? Tak. To rekordy TXT, zapisywane w cache jak każde inne. Serwer odbiorcy, który zapisał stary rekord SPF, ocenia wysyłkę według niego aż do wygaśnięcia TTL, więc wysyłka tuż po edycji może zostać oceniona według starej polityki.