Co je DNS cache a jak dlouho v ní záznamy zůstávají?

Kde se odpověď DNS skutečně ukládá do cache?

Jedno vyhledání projde přes několik cache dřív, než si čehokoli všimnete, a každá z nich si drží vlastní kopii na vlastní dobu:

• Prohlížeč. Chrome, Edge a Firefox mají každý vlastní malou DNS cache, oddělenou od té systémové. Cache Chromu je vidět na chrome://net-internals/#dns, a její vymazání ovlivní jen daný prohlížeč, ne zbytek počítače.
• Stub resolver OS. Windows provozuje službu DNS Client a cachuje odpovědi, které si vypíšete příkazem ipconfig /displaydns; macOS cachuje přes mDNSResponder; většina desktopů na Linuxu provozuje systemd-resolved, lokální cachující stub resolver, na který se ptáte přes resolvectl. Toto je skutečná cache s vlastním odpočtem TTL, ne jen kopie toho, co má prohlížeč.
• Router. Většina domácích routerů provozuje malý DNS forwarder, který odpovídá z vlastní cache, než dotaz pošle dál, což je důvod, proč restart routeru občas opraví problém s DNS, který byl ve skutečnosti jinde.
• Rekurzivní resolver. Resolver vašeho poskytovatele internetu, nebo veřejný, obsluhuje většinu vyhledání na internetu a drží největší a nejsdílenější cache. Jakmile má odpověď, dostane stejnou uloženou kopii každé zařízení, které se ho zeptá, dokud nevyprší.

Každá vrstva je nezávislá. Vyprázdnění cache na vašem notebooku nedělá nic s cache, kterou pořád drží váš router nebo váš poskytovatel internetu, a nedělá nic ani pro počítač kohokoli jiného.

Co je TTL a kdo ho skutečně dodržuje?

Každý DNS záznam nese time to live: číslo v sekundách, nastavené tím, kdo zónu spravuje, které resolveru řekne, jak dlouho smí odpověď znovu použít, než se zeptá znovu. RFC 1035 ho definuje jako interval, po který "smí být záznam cachován, než by se měl znovu konzultovat zdroj informace", a TTL rovné nule znamená, že se odpověď nesmí cachovat vůbec.

Každá cache v řetězci, prohlížeč, stub resolver, router, rekurzivní resolver, by měla toto číslo dodržovat, s odpočtem od okamžiku, kdy záznam poprvé stáhla. V praxi si některé resolvery poskytovatelů internetu nastavují vlastní minimum navrch, běžně hodinu nebo víc, bez ohledu na to, co udává zóna. Proto snížení TTL kvůli urychlení budoucí změny pomůže většině resolverů, ale u žádného z nich to není zaručené.

Co je negativní cachování a proč může úplně nový záznam zůstat chybějící?

Resolver necachuje jen záznamy, které existují. Pokud se dotaz vrátí s "takový název neexistuje" (NXDOMAIN), nebo bez záznamu daného typu, i toto selhání se uloží do cache, chování zvané negativní cachování. RFC 2308 nastavuje životnost negativní cache podle pole minimum ze záznamu SOA, a RFC 9520 teď dělá cachování tohoto selhání pro kompatibilní resolver povinným, ne volitelným.

To je mechanismus za známým problémem: vytvoříte novou subdoménu, dotážete se na ni o vteřinu dřív, dostanete NXDOMAIN, a resolver si "neexistuje" pamatuje po celou délku negativního TTL zóny, i když záznam už existuje. Windows tyto dva typy položek zobrazuje odděleně: ipconfig /displaydns vypíše jak pozitivní odpovědi, tak negativní, a ipconfig /flushdns negativní položky cache výslovně zahazuje jako součást vyprázdnění.

Proč se web přeloží vám, a někomu jinému ne?

Protože neexistuje jedna sdílená cache. Dva lidé ptající se dvou různých resolverů, nebo ptající se stejného resolveru ve dvou různých okamžicích, mohou pro stejný název dostat dvě různé odpovědi. Kopie jednoho resolveru může být ještě čerstvá z vyhledání před hodinou; jiný ten název nemusel nikdy vidět a jde stáhnout aktuální hodnotu. Ani jeden není špatně, jen jedou podle jiných hodin. Pokud se to děje hned po tom, co jste změnili záznam, jak zkontrolovat šíření DNS ukazuje, jak porovnat několik resolverů vedle sebe a přečíst, kolik času každému zbývá.

Jak přečíst TTL záznamu, který je ještě v cache?

Dotažte se na název přímo a podržte celý výstup místo krátké formy:

dig example.com

;; ANSWER SECTION:
example.com.        847    IN    A    203.0.113.10

Číslo před typem záznamu, v tomto příkladu 847, je počet sekund zbývajících do vypršení kopie u tohoto konkrétního resolveru; není to původní TTL záznamu, který s jistotou umí říct jen autoritativní server. Spusťte stejný dotaz o pár vteřin později a číslo kleslo zhruba o tolik sekund, čímž potvrdí, že čtete živý odpočet, ne statické nastavení. Pokud se název vůbec nepřeloží, místo aby se přeložil s nízkým číslem, jde o jiné selhání: jak vyprázdnit DNS pokrývá vyčištění vlastní cache jako první krok a co vlastně dělá DNS resolver pokrývá, co se stane dál v řetězci, když vlastní cache není problém.

Cache vysvětlí, proč jeden návštěvník vidí změnu okamžitě a jiný ne; nevysvětlí záznam, který se nikde neaktualizuje. Spusťte živé vyhledání pomocí nástroje pro DNS dotaz, abyste viděli aktuální odpověď mimo vlastní síť, a pokud web musí zůstat dostupný podle plánu místo jednorázové kontroly, na to slouží distribuovaný monitoring z mnoha kontrolních bodů. HostTracker monitoruje weby od roku 2004, dnes sleduje přes 500 000 webů z více než 300 kontrolních bodů ve 158 městech a upozorní e-mailem, SMS, hlasovým hovorem, přes Slack, Telegram a další, když kontrola selže, včetně kontroly, která očekává konkrétní IP adresu a označí ji ve chvíli, kdy se odpověď změní.

Časté otázky

Zpomaluje plná DNS cache můj počítač?

Ne. DNS cache je malá tabulka názvů a adres, typicky nejvýš pár set položek, a vyhledání v ní nic měřitelně nestojí. Pokud vyhledávání připadá pomalé, cache samotná není příčinou; obvyklou příčinou bývá vzdálený nebo přetížený resolver.

Vyřeší vyčištění mé cache věci i pro ostatní?

Ne. ipconfig /flushdns, dscacheutil -flushcache a resolvectl flush-caches vyčistí cache jen na počítači, kde je spustíte. Všichni ostatní pořád čtou z vlastního prohlížeče, vlastního routeru a vlastního resolveru, každý podle svého časovače.

Je DNS cache totéž co cache CDN?

Ne, i když se to plete. DNS cache ukládá odpověď na "jaká je IP adresa pro tento název". Cache CDN ukládá skutečný obsah stránky nebo souboru na serveru blízko návštěvníka. Vymazání jedné nemá vliv na druhou.

Můžu si nastavit vlastní TTL, když doménu nespravuji?

Ne. TTL je vlastnost záznamu, nastavená v autoritativní zóně tím, kdo spravuje DNS domény. Jako návštěvník máte k dispozici jen možnost zvolit si resolver, který krátké TTL respektuje, místo takového, co si vynucuje vlastní minimum.

Proč se TTL, které vidím, mění při každém dotazu?

Protože se ptáte jiného resolveru, nebo se ptáte stejného v jiném okamžiku jeho odpočtu. Dotažte se přímo na autoritativní jmenný server příkazem dig example.com @ns1.yourdns.example, abyste viděli TTL v podobě, v jaké bylo původně nastaveno, s ničím ještě neodpočítaným.