„Propagace“: proč to jeden vidí hned a druhý ne

Modul 6: Čas, cache a převod domény · Doba čtení: 8 min

Cíl lekce: Po této lekci dokážete vysvětlit, proč změna DNS není vidět všude najednou, odhadnout, jak dlouho to potrvá, a vyřešit situaci, kdy starý stav vidíte už jen Vy.

Klíčové pojmy: „propagace“, cache, negativní cache (NXDOMAIN), SOA minimum, TTL delegace, změna jmenných serverů, vyprázdnění cache

Nedorozumění v jediném slově

Změnili jste záznam. Váš kolega už vidí nový web, Vy stále ten starý. Na internetu si pak přečtete: „jen počkejte, DNS se musí ještě propagovat.“ Slovo propagace (šíření) vyvolává dojem, že se Vaše změna šíří internetem jako vlna, ze serveru na server.

Tak to ale nefunguje. Vaše změna je okamžitě k dispozici na autoritativních jmenných serverech Vaší domény (nebo během pár minut, pokud Váš poskytovatel DNS synchronizuje více jmenných serverů). Nic se nikam neposílá. To, co vidíte, je vypršení platnosti cache: každý resolver vrací starou odpověď, dokud nevyprší TTL v jeho cache (lekce 6.1). Protože každý resolver začal počítat v jiný okamžik, uvidí jeden změnu dříve než druhý.

„Propagace“ je tedy ve skutečnosti: čekání, až se vyprázdní všechny cache. Toto pochopení Vám pomůže, protože teď přesně víte, na co čekáte a jak dlouho to maximálně potrvá.

Jak dlouho to trvá?

To záleží na tom, co měníte.

Existující záznamy

Zde je to jednoduché: stará TTL je maximum. Měl-li záznam TTL 3600, uvidí každý novou odpověď nejpozději hodinu po Vaší změně. Pokud po více než hodině někdo stále vidí starou hodnotu, problém je jinde (viz dále).

Nové záznamy a negativní cache

Nový záznam obvykle funguje okamžitě, s výjimkou případu, kdy někdo daný název dotazoval už ve chvíli, kdy ještě neexistoval. Resolver tehdy dostal odpověď NXDOMAIN („tento název neexistuje“) nebo „tento název existuje, ale nemá záznam tohoto typu“. I toto „ne“ se zapamatuje. Tomu se říká negativní cache.

Jak dlouho se „ne“ uchovává, nestojí v záznamu, který neexistuje. Vyplývá to ze SOA záznamu zóny: podle RFC 2308 jde o menší ze dvou hodnot, TTL samotného SOA záznamu a poslední pole SOA záznamu (tzv. „minimum“). Příklad:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
                             2026110701 ; sériové číslo
                             14400      ; refresh
                             3600       ; retry
                             1209600    ; expire
                             300 )      ; minimum

Zde se „ne“ pamatuje maximálně 300 sekund (menší z hodnot 3600 a 300). U některých zón je to hodina nebo více.

Proto platí zlaté pravidlo: neotevírejte novou subdoménu v prohlížeči dřív, než ji vytvoříte. Váš počítač a Váš resolver si pak zapamatují, že neexistuje, a čekat budete pouze Vy.

Změna jmenných serverů

Při změně jmenných serverů čekáte na něco jiného: NS záznamy u registru Vaší koncovky. Tyto záznamy říkají resolverům, kde se nacházejí jmenné servery Vaší domény (lekce 2.1), a i ty se pamatují. Každý registr si pro ně volí vlastní TTL. Naměřeno v listopadu 2026:

K tomu se přidává fakt, že registr Vaši změnu někdy nezveřejní okamžitě a že jmenné servery Vašeho původního poskytovatele v mezidobí často ještě odpovídají starou zónou. Při změně jmenných serverů proto počítejte s několika hodinami, a u .com s maximálně dvěma dny. Zajistěte si tedy, aby měli oba poskytovatelé během přechodu stejné, správné záznamy (lekce 6.3).

Vidíte starý stav jen Vy?

Ukazuje online kontrolní nástroj novou odpověď už u téměř všech resolverů, ale u Vás ne? Pak se stará odpověď nachází ve Vašem okolí. Projděte si tyto kroky, od nejrychlejšího k nejdůkladnějšímu:

1. Anonymní okno nebo jiný prohlížeč. Váš prohlížeč si ukládá DNS odpovědi i stránky.
2. Telefon přes 4G nebo 5G, s vypnutou wifi. Pak použijete resolver svého mobilního operátora místo resolveru Vaší domácí sítě.

3. Vyprázdněte cache svého počítače.

   • Windows (Příkazový řádek): ipconfig /flushdns
   • macOS (Terminál): sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   • Linux se systemd-resolved: resolvectl flush-caches
4. Restartujte router. Mnoho routerů funguje jako malý resolver s vlastní cache.
5. Zkontrolujte soubor hosts. Testovali jste dříve nový server tím, že jste adresu zapsali do souboru hosts (C:\Windows\System32\drivers\etc\hosts nebo /etc/hosts)? Tento řádek má přednost před DNS. Odstraňte ho. Na to se často zapomíná.
6. Podívejte se přímo u zdroje. Dotažte se na záznam u autoritativního jmenného serveru (dig A example.com @ns1.hosting.example). Je-li tam stále stará odpověď, znamená to, že změna nebyla správně uložena nebo jste ji provedli na špatném místě.

Po uplynutí čekací doby stále nic?

Pokud už dávno uplynula TTL a i online nástroje zobrazují starou odpověď, čekání nemá smysl. Pak je v hra něco jiného. Tři nejčastější příčiny:

• Změna na špatném místě. Vaše doména používá jmenné servery jiného poskytovatele (například Cloudflare nebo tvůrce webu) a Vy jste změnili záznamy u svého hostingového poskytovatele. Zjistěte, jaké jmenné servery Vaše doména má (lekce 2.1), a změňte je tam.
• Překlep nebo chybějící tečka. mail.example.com bez tečky se v mnoha panelech změní na mail.example.com.example.com (lekce 2.2).
• Jmenné servery se mezi sebou neshodují. Doména má alespoň dva jmenné servery. Pokud se správně nesynchronizují, jeden vrací novou a druhý starou odpověď. Porovnejte sériové číslo SOA na každém jmenném serveru: musí se shodovat.

dig +short SOA example.com @ns1.hosting.example
dig +short SOA example.com @ns2.hosting.example

V praxi: jak to vypadá v panelu

Chcete-li zjistit, jak odpovídají resolvery na různých místech ve světě, použijte online DNS kontrolní nástroj, který se dotazuje resolveru podle jednotlivých zemí (například dnschecker.org). Ve vzorovém panelu Můj WebOké kontroluje karta Doména / E-mail zdraví jmenné servery a záznamy Vaší domény přímo u autoritativních jmenných serverů, a DNS diagnostika porovnává sériová čísla jmenných serverů. Jiní poskytovatelé mívají ve svém panelu podobnou kontrolu; pokud ne, poskytnou stejný obraz dig a online nástroje z lekce 8.3.

Shrnutí

• Nic se „nešíří“: čekáte, až vyprší platnost cache.
• Změněný záznam je viditelný všude nejpozději po uplynutí staré TTL; nový záznam je obvykle viditelný ihned, pokud ovšem někdo daný název už dříve nedotazoval (negativní cache, určená SOA záznamem).
• Výměna jmenných serverů závisí na TTL u registru: u .nl hodina, u .com dva dny.
• Vidíte starý stav už jen Vy? Anonymní okno, 4G, vyprázdnění cache, restart routeru a kontrola souboru hosts.
• Stále starý stav na autoritativním jmenném serveru? Pak nemá čekání smysl: hledejte chybu.

Kvíz

Úkol

Úkol Z6.2: TTL delegace a negativní cache. Dvě otázky, obě lze zodpovědět pomocí dig nebo online dig nástroje:

1. Kolik sekund si podle registru .com pamatují resolvery jmenné servery domény google.com? Dotažte se na server .com: dig NS google.com @a.gtld-servers.net a podívejte se na TTL v části AUTHORITY.
2. Kolik sekund si resolver pamatuje, že název pod sidn.nl neexistuje? Dotažte se na SOA záznam domény sidn.nl (sidn.nl je webová stránka SIDN, registru domén .nl v Nizozemsku) na serveru ns1.sidn.nl a použijte pravidlo z této lekce (menší z hodnot SOA TTL a SOA minimum).

Doporučené čtení

Kroky v těchto článcích se týkají panelů WebOké; v jiných panelech to funguje obdobně.

• Jak dlouho trvá změna nameserveru nebo DNS a co dělat, pokud ji nevidíte?
• Web nebo e-mail nefunguje po přesunu nebo změně DNS: zkontrolujte svou doménu
• Příručka k DirectAdmin 5.11: Kdy se změna projeví? Čekací doba a TTL
• Jak vytvořit subdoménu a co dělat, pokud nefunguje
• Jak mohu otestovat doménu před jejím převodem? (localhost)
• Příručka WebOké 5.17: Zdraví domény a e-mailu: kontrola a náprava