Summary

To sprawdzanie propagacji DNS szacuje, jak długo zmiana rekordu może być niewidoczna dla części resolverów. Propagacja to wygasanie cache: resolver trzyma starą odpowiedź do końca TTL, więc najgorszy przypadek równa się staremu TTL. Nowe rekordy mogą być zapisane jako nieistniejące na czas negatywnego TTL, a zmiana serwerów nazw zależy od TTL rekordów NS u rejestratora. Podaj rodzaj zmiany, TTL i czas od edycji, aby zobaczyć pozostały czas. Działa w przeglądarce i nie odpytuje działających serwerów DNS.

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.

Sprawdź czas oczekiwania

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.

TTL, jaki rekord miał przed edycją, a nie nowy.

Jak to działa

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.

Przed zmianą rekordu DNS e-mail

Cztery kroki, które skracają oczekiwanie

Taką kolejność stosujemy przy edycji SPF, DKIM, DMARC i MX na domenie wysyłkowej.

  1. 1

    Odczytaj obecny TTL

    Uruchom dig na rekordzie i odczytaj liczbę w sekcji answer. To TTL, który Twoja zmiana musi przetrwać.

  2. 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. 3

    Wprowadź zmianę i zapisz godzinę

    Zapisz edycję, zanotuj godzinę i wpisz czas, który upłynął, do kalkulatora powyżej.

  4. 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ą.

Zobacz, jak działa Notification Harbor
notificationharbor
Zacznij za darmo