Jak dlouho trvá změna DNS? TTL, cache a ověření změn
Shrnutí: Změna DNS může být někde vidět během minut, zatímco jinde se ještě používá stará adresa. Záleží hlavně na původním TTL a uložených odpovědích. Při stěhování webu proto snižte TTL předem a ponechte původní server dostupný. Pokud jste ale upravili záznam u neaktivního DNS poskytovatele, samotné čekání nepomůže.
Obsah článku
Proč pro změnu DNS neexistuje jedna přesná lhůta?
Změníte adresu webu a na telefonu už vidíte nový server. Kolega se stále dostává na starý. Oba výsledky mohou být správnou odpovědí jejich resolveru: jeden si vyžádal nové údaje, druhý ještě používá dříve uložené.
Tomuto postupnému projevení změny se říká propagace DNS. Aktualizace se ale nerozesílá naráz všem počítačům. Resolvery se pro nové údaje obracejí na autoritativní servery domény podle toho, co už mají v cache.
Než začnete čekat, ověřte, že jste změnu uložili u aktivního DNS poskytovatele. Jestliže autoritativní servery stále zveřejňují starou adresu, návštěvníci nemají odkud získat novou.
A pokud už DNS vrací správný cíl, ale služba nefunguje, podívejte se do administrace hostingu. Může ještě ověřovat doménu nebo vystavovat certifikát. To je samostatný krok, který TTL neurychlí.
Co znamená TTL a kde se uplatňuje?
TTL neboli Time to Live určuje v sekundách, jak dlouho lze DNS odpověď běžně uchovat v cache. Hodnota 300 znamená pět minut, 3600 hodinu a 86400 jeden den.
Čas se počítá od získání odpovědi, ne od vaší úpravy. Ukazuje to tento příklad:
| Co se stane | Čas |
|---|---|
| Resolver si uloží starou IP s TTL 3 600 | 10:00 |
| Změníte IP domény | 10:10 |
| Uložené odpovědi běžně vyprší platnost | 11:00 |
Resolver tedy může dalších 50 minut vracet původní adresu. Jiný se mohl ptát později, a jeho cache proto vyprší jindy.

Kratší TTL umožní dřívější načtení nových údajů, delší omezí počet opakovaných dotazů. Není to však přesná záruka pro všechny situace: při potížích s dostupností mohou resolvery za určitých podmínek použít i starší data po vypršení TTL.
Kdy snížit TTL před přesunem webu?
Snižte ho ještě před změnou adresy, s předstihem alespoň pro doběhnutí původního TTL. Pokud bylo nastavené na den, změna na pět minut těsně před migrací je pozdě. Resolvery, které si už uložily denní odpověď, o nové hodnotě zatím nevědí.
Postup je proto následující:
- Zveřejněte kratší TTL, pokud ho váš DNS poskytovatel dovoluje upravit.
- Nechte doběhnout původní hodnotu. Starší odpovědi s dlouhým TTL tak mají čas vypršet.
- Změňte adresu webu a ověřte nový server. Původní ponechte po přechodnou dobu funkční.
- Po ustálení provozu vraťte běžné TTL, pokud jste ho snížili jen kvůli přesunu.
Nový hosting i HTTPS připravte před přepnutím. Při přesunu webu zachovejte také poštovní záznamy, pokud e-mail zůstává u původní služby.
Je změna nameserverů totéž co změna A záznamu?
Změna A nebo AAAA upravuje adresu jednoho jména. Přepnutí nameserverů mění poskytovatele, od kterého se mají získávat DNS údaje domény. U něj proto musí být připravené všechny potřebné záznamy, včetně pošty a ověření dalších služeb.
Kvůli novému webhostingu nemusíte vždy měnit nameservery. Pokud stačí upravit adresu webu, můžete ponechat správu DNS tam, kde je. Tím se vyhnete přesunu celé zóny při připojování domény k hostingu.

Při skutečné změně nameserverů se řiďte postupem obou DNS poskytovatelů. Staré servery nechte potřebnou dobu funkční, aby dál odpovídaly návštěvníkům, kteří je ještě používají. Zkontrolujte i návaznost DNSSEC. TTL jednoho A záznamu totiž neřídí cache delegace v nadřazené zóně.
Jak poznat čekání na cache od chyby?
- Zkontrolujte přesné jméno a typ. Hlavní doména a
wwwse mohou lišit. U webu prověřte A i AAAA, případně CNAME. - Ověřte, kde jste změnu uložili. Nameservery domény musí vést k poskytovateli, v jehož editoru jste pracovali.
- Porovnejte starou a novou hodnotu. V DNS výpisu sledujte příslušný záznam a TTL. Pomocí nslookup můžete srovnat další resolver; pokročilejší kontrola se ptá přímo autoritativního serveru.
- Dohledejte původní TTL a čas změny. Současná hodnota pět minut nic neříká o odpovědi, která byla předtím uložená na den.
- Otevřete samotný web. Pokud DNS odpovídá správně, hledejte dál u hostingu, aplikace nebo certifikátu.
Online kontrola Websio používá jeden veřejný resolver a může výsledek uchovat až 60 sekund. Neukazuje tedy stav ve všech sítích. Ani vymazání cache počítače neodstraní odpovědi uložené u operátora.
Co když je nová subdoména stále nenalezená?
Do cache se ukládají i záporné odpovědi. Pokud se resolver ptal na blog.example.com dřív, než jste ho vytvořili, může ještě vracet informaci, že jméno neexistuje.
Nejprve ale zkontrolujte zápis v administraci. Některé editory automaticky přidávají název domény. Když do nich místo blog zadáte celé jméno, může vzniknout blog.example.com.example.com. V takovém případě je třeba opravit název; čekání správný záznam nevytvoří.
Často kladené otázky
Musí změna DNS vždy trvat 24 nebo 48 hodin?
Ne. Jsou to orientační lhůty z návodů, nikoli pevné pravidlo DNS. Jednoduchá změna může být vidět podstatně dříve. Záleží na původním TTL, cache a tom, co měníte.
Pomůže opakovaně uložit stejný záznam?
Cizí cache tím nevymažete. Nejdříve ověřte, co zveřejňuje autoritativní server. Opakované úpravy navíc ztěžují zjištění, kterou verzi právě dostáváte.
Dokazuje správný výsledek funkční HTTPS?
Ne. DNS najde cíl, ale HTTPS potřebuje správně nastavený server a platný certifikát. Ověřte ho otevřením webu, ne jen DNS dotazem.
Použité zdroje a metodika
Výklad rozlišuje autoritativní změnu, cache resolveru a nastavení koncové služby. Modelová časová osa ukazuje princip TTL bez slibu jednotné doby pro všechny sítě.
- Cloudflare. Time to Live (TTL). https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/. Přístup dne 22. 9. 2026.
- IETF. RFC 1034: Domain Names, Concepts and Facilities. https://www.rfc-editor.org/rfc/rfc1034. Přístup dne 22. 9. 2026.
- IETF. RFC 2308: Negative Caching of DNS Queries. https://www.rfc-editor.org/rfc/rfc2308.html. Přístup dne 22. 9. 2026.
- IETF. RFC 8767: Serving Stale Data to Improve DNS Resiliency. https://www.rfc-editor.org/rfc/rfc8767.html. Přístup dne 22. 9. 2026.
- Cloudflare. DNS FAQ. https://developers.cloudflare.com/dns/faq/. Přístup dne 22. 9. 2026.