Jak zkontrolovat DNS propagaci

Odkud se čekání bere

Představte si řetězec, kterým dotaz prochází. Vaše zařízení se zeptá rekurzivního resolveru, provozovaného vaším poskytovatelem internetu nebo veřejnou službou. Pokud má tento resolver v mezipaměti nedávnou odpověď, vrátí ji bez dalšího dotazování. Teprve když mezipaměť vyprší, sestoupí ke kořenovým serverům, registru dané domény nejvyšší úrovně a nakonec k vašim autoritativním jmenným serverům, které drží záznam, jenž jste upravili.

Takže když změníte záznam A, nová hodnota existuje ve chvíli, kdy ji váš DNS poskytovatel uloží. Každý resolver, který stále drží starou odpověď, ji podává dál, dokud jeho kopie nevyprší. TTL, time to live, je číslo v sekundách připojené k záznamu, které resolverům říká, jak dlouho ho smí mít v mezipaměti. Záznam s TTL 3600 může být z mezipaměti podáván hodinu od okamžiku, kdy byl načten, takže hodina je nejhorší možný případ pro resolver, který ho načetl těsně před vaší úpravou.

To je důvod, proč dva lidé ve stejné kanceláři mohou vidět různé výsledky, a proč vymazání vlastní mezipaměti nikomu jinému nepomůže. Nečeká se na žádné globální šíření, jen doběhne velké množství nezávislých časovačů v různých okamžicích.

Jak to ověřit z více resolverů

Ruční způsob je zeptat se stejné otázky několika resolverů a porovnat odpovědi:

dig +short example.com @8.8.8.8      # Google Public DNS
dig +short example.com @1.1.1.1      # Cloudflare
dig +short example.com @9.9.9.9      # Quad9
dig +short example.com               # váš vlastní resolver
dig +short example.com @ns1.yourdns.example  # autoritativní: zdroj pravdy

Autoritativní dotaz je ten nejdůležitější. Pokud vrátí novou hodnotu, vaše změna je správná a kompletní a všechno ostatní je jen otázka mezipaměti. Pokud vrátí starou hodnotu, změna se neuložila, upravili jste špatnou zónu, nebo jmenné servery domény nejsou ty, o kterých si myslíte.

Chcete-li vidět zbývající dobu v mezipaměti, ne jen samotnou hodnotu, vynechte +short a přečtěte sloupec TTL:

dig example.com @8.8.8.8 | grep -A1 "ANSWER SECTION"

Číslo před typem záznamu se s tím, jak uložená kopie stárne, odpočítává, což vám přesně řekne, jak dlouho ještě daný resolver bude podávat starou odpověď. Na Windows totéž porovnání bez dalších nástrojů udělá nslookup example.com 8.8.8.8. Webový nástroj pro DNS dotaz, který se ptá z mnoha lokalit najednou, udělá stejnou práci rychleji a navíc pokryje i resolvery, ke kterým se z vlastního počítače nedostanete.

Proč to může trvat hodiny

• Platí stará TTL, ne nová. Pokud měl záznam TTL 86400 a vy ho při změně snížíte, resolvery, které si uložily starý záznam, k němu mají nárok ještě celý den. Snížení TTL pomůže až příští změně.
• Některé resolvery krátké TTL ignorují. Řada poskytovatelů internetu vynucuje vlastní minimum, běžně hodinu nebo víc, bez ohledu na to, co uvádí váš záznam.
• Změny jmenných serverů jsou pomalejší. Záznamy NS na úrovni registru mívají TTL v řádu dnů, takže přechod na jiného DNS poskytovatele může skutečně trvat jeden až dva dny, než se ustálí všude.
• Počítá se i záporné ukládání do mezipaměti. Pokud název v okamžiku dotazu neexistoval, odpověď "neexistuje" se rovněž uloží do mezipaměti, a to po dobu danou minimální hodnotou pole SOA dané zóny.
• Řetězené mezipaměti. DNS si ukládá prohlížeč, ukládá si ho operační systém a před veřejným resolverem může stát ještě firemní resolver. Každá vrstva přidává vlastní zpoždění.
• Dlouhotrvající spojení. Aplikace, které přeložily název hostitele jednou při startu, tu adresu používají dál bez ohledu na to, co teď říká DNS, dokud se samy nerestartují.

Jak udělat příští změnu rychle

1. Nejprve snižte TTL, pak počkejte. Snižte TTL záznamu na 300 sekund a nechte to tak alespoň po dobu délky staré TTL, než provedete skutečnou změnu. Do té doby už každá uložená kopie ponese krátkou hodnotu.
2. Proveďte změnu. Při TTL 300 sekund většina resolverů odpověď převezme do pěti minut.
3. Nechte starý server odpovídat i během přechodu. Nevypínejte ho hned ve chvíli, kdy se DNS aktualizuje. Nechte ho odpovídat, dokud k němu neustane provoz, a migrace proběhne, aniž by si toho kdokoli všiml.
4. Ověřte to vůči autoritativním jmenným serverům a několika veřejným resolverům, než prohlásíte, že je hotovo.
5. Zvyšte TTL zpět, jakmile se změna ustálí, aby běžný provoz opět těžil z ukládání do mezipaměti.

U změny jmenného serveru žádná zkratka neexistuje, protože TTL registru si nenastavujete sami. Počítejte s jedním až dvěma dny a po celou dobu nechte oba DNS poskytovatele podávat identické záznamy, aby nezáleželo na tom, kterého se resolver zeptá.

Jakmile se změna ustálí

Ruční kontrola pár resolverů vám řekne, jak daleko se změna rozšířila v okamžiku, kdy se díváte, což je užitečné během migrace a nepoužitelné kdykoli jindy. Stojí za to zachytit pozdější selhání: záznam, který se změní, aniž by si toho kdokoli všiml, jmenný server, který přestane odpovídat, zóna, která vyprší. Nepřetržitý monitoring DNS se dotazuje z mnoha lokalit podle plánu a upozorní, jakmile odpověď přestane odpovídat tomu, co má být, což zachytí i případ "odsud to funguje, odtamtud je to rozbité", který jedno vyhledání nemůže odhalit. Spusťte dotaz hned teď pomocí nástroje pro DNS dotaz. Pokud je web nedostupný pro vás, ale jinde funguje v pořádku, pokračujte návodem je nedostupný pro všechny, nebo jen pro mě.