Po změně DNS vidí část lidí nový web a jiní starý. Může jít o běžící cache, ale také o chybnou zónu, zapomenutou IPv6 adresu nebo úplně jinou vrstvu problému. Čekání má smysl až po ověření, že autoritativní servery zveřejňují správná data. Opakované ukládání stejné hodnoty v panelu bez této kontroly diagnózu spíše zkomplikuje.
Sepište jednu konkrétní změnu
Nejdříve si ujasněte, zda jste změnili adresu A či AAAA, alias CNAME, nebo delegaci na jiné nameservery. Jde o rozdílné operace s odlišnými kontrolami. Převod k jinému registrátorovi sám o sobě nemusí přesouvat DNS ani web. Pokud se měnilo několik věcí současně, rozdělte je do časové osy.
Do záznamu patří přesné jméno, typ záznamu, stará a nová hodnota, čas změny a původní TTL. Uveďte i poskytovatele panelu. Častou ztrátou času je úprava zóny, kterou doména ve skutečnosti nepoužívá. Základní rozdělení rolí najdete v průvodci DNS a DNSSEC; zde už sledujeme konkrétní rozdíl mezi zveřejněním a přijetím změny.
| Otázka | Co zaznamenat | Proč to pomůže |
|---|---|---|
| Které jméno nefunguje? | Hlavní doména, www nebo konkrétní subdoména | Každé může mít jiný záznam |
| Co bylo změněno? | Typ, původní a nová hodnota | Oddělí přesun adresy od změny delegace |
| Kdy změna proběhla? | Čas s časovým pásmem | Umožní vztáhnout výsledky ke cache |
| Kdo vrací výsledek? | Autoritativní server nebo konkrétní resolver | Ukáže vrstvu rozdílu |
Začněte autoritativní odpovědí
Autoritativní servery zveřejňují data zóny. Resolver, který používá návštěvník, je může mít dočasně uložená. Správce proto nejprve ověří aktuální delegaci a odpovědi jednotlivých autoritativních serverů. Pokud už ty vracejí rozdílné nebo nesprávné hodnoty, není vhodné vysvětlovat celý problém jen čekáním na cache návštěvníků.
Při změně nameserverů je třeba ověřit také úplnost nové zóny. Webové záznamy mohou být správné, zatímco chybějí poštovní MX nebo ověřovací TXT. Diagnostiku konkrétního webového výpadku proto neuzavírejte tvrzením, že celý převod všech služeb proběhl dobře. Funkční homepage není kontrola firemní pošty.
Jestli výsledky neumíte získat, požádejte správce o výpis pro konkrétní jméno a typ. Stačí technické údaje o odpovědi; hesla, AuthInfo ani soukromé přístupové tokeny do takového podkladu nepatří. Přesný výpis je užitečnější než fotografie celého zákaznického účtu s nesouvisejícími daty.
Co skutečně říká TTL
TTL určuje dobu uložení DNS odpovědi v cache. Delší hodnota zvyšuje šanci použití uloženého výsledku, ale zároveň zpomaluje projevení změny u klientů s touto odpovědí. Cloudflare tuto souvislost popisuje ve své dokumentaci; konkrétní možnosti nastavení se liší podle typu záznamu a služby.
Snížení TTL po provedené změně nevymaže odpovědi, které si někdo dříve uložil s delší hodnotou. Příprava se proto dělá s předstihem podle původního stavu. Nové krátké TTL není tlačítko pro okamžité rozšíření změny. Při incidentu sledujte skutečně vracené hodnoty a čas, ne jen nový údaj v administraci.
Nedávejte návštěvníkům univerzální slib, že vše začne fungovat po přesném počtu minut. Vedle různých cache může být chyba v delegaci, podpisu nebo samotné aplikaci. Smysluplný odhad vzniká až z konkrétní změny a ověřeného stavu. Průběžné hlášení má říkat, co už je správně a kde rozdíl přetrvává.
A a AAAA kontrolujte zvlášť
Web může mít správnou IPv4 adresu a současně starou či nefunkční IPv6 adresu. Některá připojení pak projeví problém a jiná ne. Kontrola pouze A záznamu je v takové situaci neúplná. Stejně tak nezapomeňte na www: jeho CNAME či samostatné adresy mohou směřovat jinam než samotná hlavní doména.
- Porovnejte A i AAAA pro přesné problematické jméno.
- U aliasu zjistěte také cílové jméno a jeho adresy.
- Ověřte, že na nové adrese funguje správný web i HTTPS pro danou doménu.
- Zkontrolujte, zda se chyba liší podle sítě nebo jen podle uložené stránky.
Neodstraňujte IPv6 automaticky při každé závadě. Nejdříve potvrďte chybnou hodnotu a oprávnění k zásahu. Cílem je opravit konkrétní směrování, nikoli bez evidence zmenšit podporovaný provoz. U spravované služby si správné hodnoty nechte potvrdit jejím provozovatelem.
Rozlište DNS, cache stránky a chybu HTTPS
Jestli všechny kontrolované resolvery vracejí novou adresu, ale článek je starý, pokračujte ve vrstvě webu. Může jít o serverovou cache nebo CDN. Jestli se nový server ozve, ale prohlížeč hlásí jiné jméno certifikátu, řešte konfiguraci HTTPS. Další změna DNS záznamu bez důkazu nemusí ani jednomu problému pomoci.
| Pozorování | Pravděpodobný směr kontroly | Čemu se vyhnout |
|---|---|---|
| Autoritativní odpověď je špatná | Zóna, delegace nebo zveřejnění změny | Pouhému čekání na návštěvníky |
| Autorita je správná, resolver drží starou hodnotu | Cache a původní TTL | Opakovaným přepisům správné hodnoty |
| Adresa je správná, stránka stará | HTTP cache a aplikace | Zaměňování DNS za obsahovou cache |
| Nový server vrací chybný certifikát | HTTPS pro konkrétní jméno | Obcházení varování v prohlížeči |
| Validující resolver hlásí selhání | DNSSEC a návaznost podpisů | Slepému vypínání zabezpečení |
DNSSEC vyžaduje zvláštní pozornost při přesunu mezi poskytovateli. Pokud některé validující resolvery selhávají, předejte správci stav delegace a podpisů. Nevypínejte ověřování jako první univerzální opravu. Důležitý je koordinovaný postup odpovídající původnímu a novému poskytovateli.
Postup, který lze předat podpoře
- Uveďte přesnou adresu a čas prvního zjištěného problému.
- Popište jedinou změnu nebo časovou osu několika souvisejících změn.
- Přiložte aktuální autoritativní odpovědi a výsledky dvou odlišných resolverů.
- Oddělte A, AAAA, případný alias a chybu HTTPS či samotné stránky.
- Napište, co očekáváte jako správný cílový stav a kdo jej potvrdil.
V modelové situaci jeden kolega vidí nový magazín a druhý starý. Autoritativní servery už odpovídají správně, ale jeden resolver ještě vrací původní IP. To je jiný závěr než situace, kdy obě adresy sedí a CDN vydává starou homepage. Stejný příznak v prohlížeči tedy může vyžadovat zcela jiné řešení.
Uzavření změny opřete o více než vlastní notebook. Zaznamenejte použitá místa kontroly a ověřené služby. Starý server vypínejte podle předem domluveného plánu, nikoli podle jediného úspěšného načtení. U rozsáhlé změny přidejte zvlášť kontrolu pošty a dalších závislostí, aby se webová kontrola nevydávala za úplnou přejímku.
Časté otázky
Pomůže vymazání cache prohlížeče všem návštěvníkům?
Ne. Změní jen místní stav v daném prostředí a navíc nemusí vymazat všechny používané DNS cache. Nemění odpovědi autoritativních serverů ani cache jiných resolverů.
Proč stále vidím starý výsledek po snížení TTL?
Resolver mohl dřívější odpověď uložit s původní delší hodnotou. Nové TTL automaticky neodvolává už uložená data. Ověřte čas změny, původní hodnotu a skutečně použitý resolver.
Stačí vyzkoušet mobilní data?
Je to užitečný další pohled, ale ne náhrada autoritativní kontroly. Výsledek zaznamenejte s konkrétní adresou a časem. Dvě fungující sítě také nemusí pokrýt všechny služby pod doménou.
Proč web nefunguje jen některým lidem?
Vedle různých cache může jít o rozdílné použití IPv4 a IPv6 nebo o validaci DNSSEC. Proto porovnávejte typy odpovědí a chyby, místo abyste všechny potíže označili jako pomalou propagaci.
Mám změnu znovu uložit v panelu?
Nejdříve zjistěte, zda už autoritativní servery vracejí požadovanou hodnotu. Opakované ukládání správného nastavení nevymaže vzdálené cache. Pokud panel a skutečné odpovědi nesouhlasí, řešte zveřejnění s poskytovatelem.
