Vytvoříte nový DNS záznam, uložíte, a nic. Web nejede, monitoring hlásí výpadek, ping říká, že jméno neexistuje. Za půl hodiny najednou všechno funguje, aniž byste cokoliv změnili. Kde se ta půlhodina vzala, když má záznam TTL 5 minut? Odpověď je jedna z nejčastěji přehlížených vlastností DNS a stojí za drtivou většinou dotazů typu „proč se mi změna nepropsala“. Pojďme si ji rozebrat od začátku.
Co je to TTL a proč vůbec existuje
DNS je distribuovaná databáze a její výkon stojí na cachování. Kdyby se každý dotaz na každé doménové jméno musel pokaždé ptát autoritativních serverů, internet by se utopil v DNS provozu a načítání stránek by bylo znatelně pomalejší. Proto si mezilehlé servery, takzvané rekurzivní resolvery, odpovědi pamatují.
TTL (Time To Live) je údaj u každého DNS záznamu, který říká: „tuhle odpověď si smíš pamatovat maximálně takhle dlouho“. Udává se v sekundách. Záznam s TTL 300 smí resolver držet v cache 5 minut, pak se musí zeptat znovu. My máme výchozí TTL nastavené právě na 300 sekund, což je rozumný kompromis mezi rychlostí změn a zátěží: změny se propíšou do 5 minut a resolvery se přitom neptají zbytečně často.
Důležité je pochopit, kdo TTL vlastně „spotřebovává“. Není to váš DNS server. Je to resolver na druhé straně: Google DNS (8.8.8.8), Cloudflare (1.1.1.1), resolver vašeho operátora nebo firemní DNS server. Ti všichni si drží vlastní, nezávislé cache. A přesně tady začíná ta část, kterou žádný poskytovatel DNS nemá pod kontrolou.
Jak reálně probíhá „propsání“ změny
Slovo propagace svádí k představě, že se změna aktivně rozesílá do světa a postupně dotéká na vzdálenější servery. Ve skutečnosti se nikam nic nerozesílá. Průběh je opačný a pasivní.
Když změnu uložíte, poskytovatel ji publikuje na svých autoritativních serverech. To je jediná část, kterou má plně v rukou, a bývá otázkou jednotek minut, často sekund. Od té chvíle autoritativní servery odpovídají novou hodnotou každému, kdo se zeptá.
Jenže resolvery se neptají. Dokud jim v cache leží stará odpověď s nevypršeným TTL, vracejí ji svým klientům a na autoritativní servery vůbec nesáhnou. Teprve když TTL doběhne, položí při dalším dotazu nový dotaz a dostanou aktuální hodnotu. „Propagace“ tedy není nic jiného než čekání, až jednotlivým resolverům po světě nezávisle vyprší cache. Proto změna funguje kamarádovi na mobilních datech, ale vám doma ještě ne: každý používáte jiný resolver s jinak starou cache.
U změny existujícího záznamu je matematika jednoduchá: publikace na autoritativních serverech plus maximálně TTL. Při TTL 300 je to do zhruba 5 minut. Tady žádné překvapení nečíhá.
Nový záznam: past jménem negativní cache
Překvapení číhá u záznamů nově vytvářených. A tady se dostáváme k té půlhodině ze začátku článku.
Resolvery si totiž nepamatují jen odpovědi „jméno existuje a má tuhle hodnotu“. Pamatují si i odpovědi „tohle jméno neexistuje“ (v DNS terminologii NXDOMAIN). Dává to smysl: dotazy na neexistující jména tvoří překvapivě velkou část DNS provozu (překlepy, staré odkazy, sondy botů) a bez cachování by je autoritativní servery musely zodpovídat pořád dokola.
Háček je v tom, čím se doba pamatování negativní odpovědi řídí. Není to TTL vašeho nového záznamu, ten v okamžiku dotazu ještě neexistoval, takže žádné TTL nemohl resolveru předat. Řídí se hodnotou ze SOA záznamu zóny, konkrétně jejím posledním polem (v RFC 2308 definovaným jako negativní TTL). Ta bývá u poskytovatelů nastavena typicky na 3600 sekund, tedy hodinu.
A teď ten scénář, který zná každý, kdo někdy netrpělivě čekal na nový záznam. Chystáte nasazení, tak si nejdřív zkusíte, jestli jméno resolvuje: ping nova-sluzba.mojedomena.cz. Neexistuje, jasně, vždyť jste ho ještě nevytvořili. Jenže tímhle jediným dotazem jste resolveru řekli, ať si odpověď „neexistuje“ zapamatuje. Pak záznam vytvoříte, na autoritativních serverech je během pár minut, ale váš resolver se už neptá. Drží NXDOMAIN a bude ho držet až hodinu od toho vašeho zvědavého pingu. Totéž udělá monitoring, který spustíte dřív, než záznam existuje: první kontrola si „vyrobí“ negativní cache a další kontroly do ní narážejí.
Výsledek: nový záznam se může projevit za pár minut, ale taky za hodinu. Rozhoduje jediná věc: jestli se na jméno někdo dotázal dřív, než záznam vznikl, a kdy. Odpočet přitom běží od okamžiku toho prvního dotazu, ne od vytvoření záznamu.
Co poskytovatel DNS ovlivnit může a co ne
Poskytovatel má pod kontrolou publikaci změn na vlastních autoritativních serverech, výchozí TTL záznamů a hodnotu negativního TTL v SOA zóny. To je celé.
Co ovlivnit nemůže: cache tisíců resolverů po celém světě. Neexistuje způsob, jak jim vzdáleně říct „zahoď starou odpověď“. Některé velké resolvery nabízejí webový formulář na ruční vyčištění konkrétního jména (Google i Cloudflare takový mají), ale to je nouzovka pro jednotlivé případy, ne mechanismus, na který jde spoléhat. Navíc resolvery mohou s TTL nakládat po svém: některé si nízké hodnoty uměle zvedají na vlastní minimum, jiné dlouhé hodnoty ořezávají stropem. Chování se liší resolver od resolveru a poskytovatel DNS do něj nevidí a nezasáhne.
Proto je fér říct to natvrdo: jakmile změna opustí autoritativní servery, je její osud v rukou cizích cache. Sliby typu „změny se propíší okamžitě po celém světě“ nemá jak splnit nikdo, kdo nelže.
Best practices, které vás čekání ušetří
Nejcennější pravidlo plyne přímo z mechaniky negativní cache: nejdřív záznam vytvořte, teprve potom ho testujte a zapínejte monitoring. Pořadí „zkusím, jestli existuje, pak vytvořím“ je přesně to, co spouští hodinové čekání. Pořadí „vytvořím, počkám pár minut, pak zkouším“ mu předchází úplně. Pokud monitoring nasazujete na jméno, které teprve vzniká, přidejte ho až po ověření, že jméno resolvuje.
Před plánovanou změnou existujícího záznamu se vyplatí s předstihem snížit TTL. Den předem stáhněte TTL třeba na 300, počkejte, až staré (delší) TTL všude doběhne, proveďte změnu, a po ověření TTL zase vraťte na provozní hodnotu. Změna se pak propíše během minut místo hodin.
Při migraci na novou IP adresu nechte starý server běžet souběžně s novým po dobu alespoň jednoho původního TTL, ideálně déle. Část světa bude ještě nějakou dobu chodit na starou adresu a je lepší, když tam něco funkčního najde.
Při ladění se ptejte přímo autoritativních serverů, obejdete tím veškeré cache: dig zaznam.mojedomena.cz @ns.poskytovatele.cz. Pokud autoritativní server vrací správnou hodnotu, změna je publikovaná a zbytek je jen čekání na cache. Pokud nevrací, problém je u poskytovatele nebo v zóně. Tenhle jediný příkaz spolehlivě rozsoudí, na čí straně zádrhel je. Podrobnější postup hledání příčiny najdete v návodu DNS – Řešení problémů. Stav propsání u velkých resolverů zkontrolujete dotazem přímo na ně (dig zaznam.mojedomena.cz @8.8.8.8) nebo některým z veřejných nástrojů na kontrolu propagace.
A poslední, méně známý tip: pozor na cache ve vlastním zařízení. Operační systém i prohlížeč si drží vlastní malé DNS cache nad rámec resolveru. Když všechno ostatní sedí a jen váš počítač tvrdohlavě vidí starou hodnotu, pomůže vyčištění lokální cache nebo prostě chvíle trpělivosti.
Shrnutí
TTL určuje, jak dlouho smí resolvery pamatovat odpověď, a tedy jak rychle se změny propisují. Úprava existujícího záznamu se projeví zhruba do TTL, u výchozích 300 sekund tedy do několika minut. Nový záznam je zrádnější: pokud se na jméno kdokoliv dotázal před jeho vytvořením, resolver drží odpověď „neexistuje“ podle negativního TTL zóny, typicky až hodinu od prvního dotazu. Poskytovatel DNS ovlivní jen publikaci na svých serverech a nastavení TTL hodnot, cizí cache po světě neovlivní nikdo. Nejlepší obrana je znát pořadí: nejdřív vytvořit, pak testovat.