Przykład 1
- 3600 s
3600
Ile sekund przy TTL 3600? 3600. Konwersja wpisu, nie zapytanie DNS.
DNS TTL
Wpisz TTL w sekundach. 3600 zostaje 3600. 60 zostaje 60. 86400 zostaje 86400. To zamiana liczby, nie live DNS.
To przeliczenie sekund, które wpiszesz. Karta nie pyta nameservera. Zakres puli jest na zakresie DHCP.
Wynik
Wprowadź dane i kliknij Oblicz.
Jak to działa?
DNS TTL na tej karcie pokazuje wpisane sekundy. 3600 zostaje 3600. 60 zostaje 60. 86400 zostaje 86400. Obok widać minuty, godziny i dni z tej samej liczby. Karta nie robi zapytania DNS.
Pole dns-ttl-a jest liczbą sekund. 3600 / 60 = 60 minut, / 3600 = 1 godzina. 60 to jedna minuta. 86400 to jeden dzień. Wynik karty extras zostaje integer sekund.
3600 nie schodzi z dig. 60 nie jest SOA z Cloudflare. 86400 nie jest cache resolvera. Wpisujesz TTL sam. Nie ma live lookup.
Zakres DHCP obok liczy start puli. Podsieć IP liczy hosty. Tu 3600 zostaje 3600, sama konwersja sekund.
Wpisz 3600, potem Oblicz. Wynik to 3600. Zamień na 60 albo 86400. Zero sekund zostaje 0. Puste pole nie liczy.
3600 zostaje 3600. 60 zostaje 60. 86400 zostaje 86400. Inna liczba w polu zmienia wynik.
Wzór
sekundy = wpis; minuty = s/60; godziny = s/3600; dni = s/86400. Bez zapytania DNS.
Jak korzystać
- Wpisz 3600 w polu TTL.
- Kliknij Oblicz. Wynik sekund to 3600.
- 60 zostaje 60. 86400 zostaje 86400.
- To konwersja sekund, nie live DNS.
- Sąsiednia karta liczy start puli DHCP.
3600 zostaje 3600
Sekundy z pola. 3600 zostaje 3600. To nie zapytanie DNS.
- DNS
- Brak lookup. 60 zostaje 60. Nie dig i nie SOA.
- TTL
- Wpisane sekundy. 86400 zostaje 86400. Nie cache resolvera.
- sekund
- Wynik karty. 3600 zostaje 3600. Sama konwersja.
Przykłady
Przykład 2
- 60 s
60
Ile przy 60? 60.
Przykład 3
- 86400 s
86400
Ile przy 86400? 86400. Jeden dzień w sekundach.
Powiązane kalkulatory
Najczęstsze pytania
Ile sekund przy TTL 3600?
3600. Wpis zostaje sekundami. Nie dig.
Ile przy 60?
60. Jedna minuta w sekundach.
Ile przy 86400?
86400. Jeden dzień w sekundach.
Czy karta pyta nameserver?
Nie. Nie ma live DNS. Samo przeliczenie liczby.
Czy 3600 to czas propagacji?
Nie. To TTL, który wpiszesz. Cache resolverów jest poza kartą.
Czy przecinek w 3600,5 działa?
Tak jako liczba. Przykłady trzymają 3600, 60 i 86400.
Czy zero liczy?
Tak jako 0 sekund. Puste pole się zatrzymuje.
Czym to różni się od zakresu DHCP?
Tam 192.168.1.0 /24 daje 192.168.1.1. Tu 3600 zostaje 3600.
Czy 300 jest w extras?
Nie. Trzy karty biorą 3600, 60 i 86400.
Co kontroluje TTL
TTL (Time To Live) mówi resolverom, jak długo mogą cache’ować odpowiedź (w sekundach). To nie „ważność domeny” ani deadline propagacji u rejestratora — tylko wskazówka cache’owania. Kalkulator przelicza sekundy na minuty, godziny i dni (np. 300 = 5 min, 86400 = 24 h).
Cache rekursywnych resolverów
- Resolver (ISP / 1.1.1.1 / 8.8.8.8) trzyma odpowiedź do wyczerpania TTL — różne sieci mogą widzieć nowy i stary IP jednocześnie.
- Przeglądarka i OS też cache’ują (stąd „u mnie działa, u kolegi nie”).
- NXDOMAIN ma osobne TTL z SOA — też wygląda jak „DNS się nie odświeża”.
Tabela szybkiego odniesienia TTL
Najczęstsze wartości — odczytaj w sekundach i od razu zobacz praktyczne użycie. Presety w formularzu: 60, 300, 3600, 86400.
| Sekundy | Minuty | Godziny / dni | Typowe użycie |
|---|---|---|---|
| 60 | 1 | — | Testy, awaryjny cutover (dużo zapytań DNS) |
| 300 | 5 | — | Przed migracją / failover |
| 600 | 10 | — | Krótki kompromis przy częstszych zmianach |
| 3600 | 60 | 1 h | Stabilne usługi — częsty domyślny wybór |
| 14400 | 240 | 4 h | Spokojniejszy ruch DNS, wolniejsza zmiana |
| 86400 | 1440 | 24 h / 1 dzień | Rzadko zmieniane rekordy; ryzykowne tuż przed cutoverem |
Migracja i opóźnienia
- Przed cutoverem: obniż TTL (np. 86400 → 300) i odczekaj ≥ stary TTL, potem zmień rekord; po stabilizacji podnieś TTL (np. 3600).
- Samo ustawienie 300 dziś nie czyści wczorajszego cache z TTL 86400.
- Gdy „nadal stary IP”: inny resolver, cache OS/przeglądarki, CDN, albo zły rekord/strefa — sprawdź
dig @1.1.1.1.
Scenariusze A / AAAA / CNAME / MX
- A / AAAA — TTL bezpośrednio na IP. Migracja serwera WWW: krótki TTL → zmiana IP → obserwacja → dłuższy TTL.
- CNAME — klient idzie za celem; liczy się TTL CNAME oraz TTL rekordu docelowego. Krótki CNAME przy długim A u celu nadal może „trzymać” stare IP po stronie A.
- MX — zmiana poczty: obniż TTL MX (i powiązanych A/AAAA hostów MX) z wyprzedzeniem; kolejność i priorytety MX zostaw spójne podczas cutoveru.
- Wielu NS / anycast — spójna publikacja na wszystkich NS; TTL nie naprawi rozjechanej strefy.
Checklista przed zmianą DNS
- Zapisz obecny TTL i przelicz go w kalkulatorze.
- Obniż do 300 (lub 60 w awarii), odczekaj ≥ poprzedni TTL, zmień rekord, sprawdź na 2–3 resolverach.
- Po stabilizacji podnieś TTL (np. 3600) i zanotuj realne czasy w runbooku.
Przykład: poniedziałek 10:00 — 86400 → 300; wtorek 10:00 — zmiana A; środa — podnieś do 3600.
FAQ — TTL, migracje i „propagacja”
Praktyczne pytania o wartości TTL i planowanie cutoveru.
- Ile to 300, 3600 i 86400 w praktyce?
300= 5 minut,3600= 1 godzina,86400= 24 godziny. Kalkulator pokazuje też ułamki dni/godzin.- Czy TTL = czas propagacji DNS?
- Nie dosłownie. TTL to max czas cache. „Propagacja” to wypadkowa TTL, cache resolverów i tego, kiedy rekord faktycznie zmieniono na NS.
- Jak przygotować migrację z TTL 86400?
- Ustaw np. 300, poczekaj co najmniej 24 h (stary TTL), potem zmień rekord. Po sukcesie wróć do 3600+.
- Dlaczego dig pokazuje nowy IP, a telefon stary?
- Inny resolver / cache aplikacji. Sprawdź ten sam resolver co telefon lub wyczyść cache DNS na urządzeniu.
- Czy krótszy TTL zawsze lepszy?
- Nie — krótszy = więcej zapytań i obciążenia NS. Na spokojne usługi lepiej 3600–14400; krótki TTL rezerwuj na okna zmian.
- TTL na CNAME a TTL na A
- Oba mają znaczenie. Nawet z krótkim CNAME długi TTL na docelowym A spowalnia zmianę IP celu.
- Co z MX przy zmianie hostingu poczty?
- Obniż TTL MX i A/AAAA hostów MX wcześniej, utrzymaj okres równoległego odbioru jeśli provider na to pozwala, potem przełącz priorytety/cele.
- Czy 60 sekund jest bezpieczne na stałe?
- Technicznie działa, ale generuje ruch DNS. Używaj raczej w trakcie incidentu lub testów, potem podnieś.