Vytvo\u0159\u00edte nov\u00fd DNS z\u00e1znam, ulo\u017e\u00edte, a nic. Web nejede, monitoring hl\u00e1s\u00ed v\u00fdpadek, ping \u0159\u00edk\u00e1, \u017ee jm\u00e9no neexistuje. Za p\u016fl hodiny najednou v\u0161echno funguje, ani\u017e byste cokoliv zm\u011bnili. Kde se ta p\u016flhodina vzala, kdy\u017e m\u00e1 z\u00e1znam TTL 5 minut? Odpov\u011b\u010f je jedna z nej\u010dast\u011bji p\u0159ehl\u00ed\u017een\u00fdch vlastnost\u00ed DNS a stoj\u00ed za drtivou v\u011bt\u0161inou dotaz\u016f typu „pro\u010d se mi zm\u011bna nepropsala“. Poj\u010fme si ji rozebrat od za\u010d\u00e1tku.<\/p>\n\n\n\n\n\n\n\n
DNS<\/a> je distribuovan\u00e1 datab\u00e1ze a jej\u00ed v\u00fdkon stoj\u00ed na cachov\u00e1n\u00ed. Kdyby se ka\u017ed\u00fd dotaz na ka\u017ed\u00e9 dom\u00e9nov\u00e9 jm\u00e9no musel poka\u017ed\u00e9 pt\u00e1t autoritativn\u00edch server\u016f, internet by se utopil v DNS provozu a na\u010d\u00edt\u00e1n\u00ed str\u00e1nek by bylo znateln\u011b pomalej\u0161\u00ed. Proto si mezilehl\u00e9 servery, takzvan\u00e9 rekurzivn\u00ed resolvery, odpov\u011bdi pamatuj\u00ed.<\/p>\n\n\n\n TTL (Time To Live) je \u00fadaj u ka\u017ed\u00e9ho DNS z\u00e1znamu<\/a>, kter\u00fd \u0159\u00edk\u00e1: „tuhle odpov\u011b\u010f si sm\u00ed\u0161 pamatovat maxim\u00e1ln\u011b takhle dlouho“. Ud\u00e1v\u00e1 se v sekund\u00e1ch. Z\u00e1znam s TTL 300 sm\u00ed resolver dr\u017eet v cache 5 minut, pak se mus\u00ed zeptat znovu. My m\u00e1me v\u00fdchoz\u00ed TTL nastaven\u00e9 pr\u00e1v\u011b na 300 sekund, co\u017e je rozumn\u00fd kompromis mezi rychlost\u00ed zm\u011bn a z\u00e1t\u011b\u017e\u00ed: zm\u011bny se prop\u00ed\u0161ou do 5 minut a resolvery se p\u0159itom neptaj\u00ed zbyte\u010dn\u011b \u010dasto.<\/p>\n\n\n\n D\u016fle\u017eit\u00e9 je pochopit, kdo TTL vlastn\u011b „spot\u0159ebov\u00e1v\u00e1“. Nen\u00ed to v\u00e1\u0161 DNS server. Je to resolver na druh\u00e9 stran\u011b: Google DNS (8.8.8.8), Cloudflare (1.1.1.1), resolver va\u0161eho oper\u00e1tora nebo firemn\u00ed DNS server. Ti v\u0161ichni si dr\u017e\u00ed vlastn\u00ed, nez\u00e1visl\u00e9 cache. A p\u0159esn\u011b tady za\u010d\u00edn\u00e1 ta \u010d\u00e1st, kterou \u017e\u00e1dn\u00fd poskytovatel DNS nem\u00e1 pod kontrolou.<\/p>\n\n\n\n Slovo propagace sv\u00e1d\u00ed k p\u0159edstav\u011b, \u017ee se zm\u011bna aktivn\u011b rozes\u00edl\u00e1 do sv\u011bta a postupn\u011b dot\u00e9k\u00e1 na vzd\u00e1len\u011bj\u0161\u00ed servery. Ve skute\u010dnosti se nikam nic nerozes\u00edl\u00e1. Pr\u016fb\u011bh je opa\u010dn\u00fd a pasivn\u00ed.<\/p>\n\n\n\n Kdy\u017e zm\u011bnu ulo\u017e\u00edte, poskytovatel ji publikuje na sv\u00fdch autoritativn\u00edch serverech. To je jedin\u00e1 \u010d\u00e1st, kterou m\u00e1 pln\u011b v rukou, a b\u00fdv\u00e1 ot\u00e1zkou jednotek minut, \u010dasto sekund. Od t\u00e9 chv\u00edle autoritativn\u00ed servery odpov\u00eddaj\u00ed novou hodnotou ka\u017ed\u00e9mu, kdo se zept\u00e1.<\/p>\n\n\n\n Jen\u017ee resolvery se neptaj\u00ed. Dokud jim v cache le\u017e\u00ed star\u00e1 odpov\u011b\u010f s nevypr\u0161en\u00fdm TTL, vracej\u00ed ji sv\u00fdm klient\u016fm a na autoritativn\u00ed servery v\u016fbec nes\u00e1hnou. Teprve kdy\u017e TTL dob\u011bhne, polo\u017e\u00ed p\u0159i dal\u0161\u00edm dotazu nov\u00fd dotaz a dostanou aktu\u00e1ln\u00ed hodnotu. „Propagace“ tedy nen\u00ed nic jin\u00e9ho ne\u017e \u010dek\u00e1n\u00ed, a\u017e jednotliv\u00fdm resolver\u016fm po sv\u011bt\u011b nez\u00e1visle vypr\u0161\u00ed cache. Proto zm\u011bna funguje kamar\u00e1dovi na mobiln\u00edch datech, ale v\u00e1m doma je\u0161t\u011b ne: ka\u017ed\u00fd pou\u017e\u00edv\u00e1te jin\u00fd resolver s jinak starou cache.<\/p>\n\n\n\n U zm\u011bny existuj\u00edc\u00edho z\u00e1znamu je matematika jednoduch\u00e1: publikace na autoritativn\u00edch serverech plus maxim\u00e1ln\u011b TTL. P\u0159i TTL 300 je to do zhruba 5 minut. Tady \u017e\u00e1dn\u00e9 p\u0159ekvapen\u00ed ne\u010d\u00edh\u00e1.<\/p>\n\n\n\n P\u0159ekvapen\u00ed \u010d\u00edh\u00e1 u z\u00e1znam\u016f nov\u011b vytv\u00e1\u0159en\u00fdch. A tady se dost\u00e1v\u00e1me k t\u00e9 p\u016flhodin\u011b ze za\u010d\u00e1tku \u010dl\u00e1nku.<\/p>\n\n\n\n Resolvery si toti\u017e nepamatuj\u00ed jen odpov\u011bdi „jm\u00e9no existuje a m\u00e1 tuhle hodnotu“. Pamatuj\u00ed si i odpov\u011bdi „tohle jm\u00e9no neexistuje“ (v DNS terminologii NXDOMAIN). D\u00e1v\u00e1 to smysl: dotazy na neexistuj\u00edc\u00ed jm\u00e9na tvo\u0159\u00ed p\u0159ekvapiv\u011b velkou \u010d\u00e1st DNS provozu (p\u0159eklepy, star\u00e9 odkazy, sondy bot\u016f) a bez cachov\u00e1n\u00ed by je autoritativn\u00ed servery musely zodpov\u00eddat po\u0159\u00e1d dokola.<\/p>\n\n\n\n H\u00e1\u010dek je v tom, \u010d\u00edm se doba pamatov\u00e1n\u00ed negativn\u00ed odpov\u011bdi \u0159\u00edd\u00ed. Nen\u00ed to TTL va\u0161eho nov\u00e9ho z\u00e1znamu, ten v okam\u017eiku dotazu je\u0161t\u011b neexistoval, tak\u017ee \u017e\u00e1dn\u00e9 TTL nemohl resolveru p\u0159edat. \u0158\u00edd\u00ed se hodnotou ze SOA z\u00e1znamu z\u00f3ny<\/a>, konkr\u00e9tn\u011b jej\u00edm posledn\u00edm polem (v RFC 2308 definovan\u00fdm jako negativn\u00ed TTL). Ta b\u00fdv\u00e1 u poskytovatel\u016f nastavena typicky na 3600 sekund, tedy hodinu.<\/p>\n\n\n\n A te\u010f ten sc\u00e9n\u00e1\u0159, kter\u00fd zn\u00e1 ka\u017ed\u00fd, kdo n\u011bkdy netrp\u011bliv\u011b \u010dekal na nov\u00fd z\u00e1znam. Chyst\u00e1te nasazen\u00ed, tak si nejd\u0159\u00edv zkus\u00edte, jestli jm\u00e9no resolvuje: V\u00fdsledek: nov\u00fd z\u00e1znam se m\u016f\u017ee projevit za p\u00e1r minut, ale taky za hodinu. Rozhoduje jedin\u00e1 v\u011bc: jestli se na jm\u00e9no n\u011bkdo dot\u00e1zal d\u0159\u00edv, ne\u017e z\u00e1znam vznikl, a kdy. Odpo\u010det p\u0159itom b\u011b\u017e\u00ed od okam\u017eiku toho prvn\u00edho dotazu, ne od vytvo\u0159en\u00ed z\u00e1znamu.<\/p>\n\n\n\n Poskytovatel m\u00e1 pod kontrolou publikaci zm\u011bn na vlastn\u00edch autoritativn\u00edch serverech, v\u00fdchoz\u00ed TTL z\u00e1znam\u016f a hodnotu negativn\u00edho TTL v SOA z\u00f3ny. To je cel\u00e9.<\/p>\n\n\n\n Co ovlivnit nem\u016f\u017ee: cache tis\u00edc\u016f resolver\u016f po cel\u00e9m sv\u011bt\u011b. Neexistuje zp\u016fsob, jak jim vzd\u00e1len\u011b \u0159\u00edct „zaho\u010f starou odpov\u011b\u010f“. N\u011bkter\u00e9 velk\u00e9 resolvery nab\u00edzej\u00ed webov\u00fd formul\u00e1\u0159 na ru\u010dn\u00ed vy\u010di\u0161t\u011bn\u00ed konkr\u00e9tn\u00edho jm\u00e9na (Google i Cloudflare takov\u00fd maj\u00ed), ale to je nouzovka pro jednotliv\u00e9 p\u0159\u00edpady, ne mechanismus, na kter\u00fd jde spol\u00e9hat. Nav\u00edc resolvery mohou s TTL nakl\u00e1dat po sv\u00e9m: n\u011bkter\u00e9 si n\u00edzk\u00e9 hodnoty um\u011ble zvedaj\u00ed na vlastn\u00ed minimum, jin\u00e9 dlouh\u00e9 hodnoty o\u0159ez\u00e1vaj\u00ed stropem. Chov\u00e1n\u00ed se li\u0161\u00ed resolver od resolveru a poskytovatel DNS do n\u011bj nevid\u00ed a nezas\u00e1hne.<\/p>\n\n\n\n Proto je f\u00e9r \u0159\u00edct to natvrdo: jakmile zm\u011bna opust\u00ed autoritativn\u00ed servery, je jej\u00ed osud v rukou ciz\u00edch cache. Sliby typu „zm\u011bny se prop\u00ed\u0161\u00ed okam\u017eit\u011b po cel\u00e9m sv\u011bt\u011b“ nem\u00e1 jak splnit nikdo, kdo nel\u017ee.<\/p>\n\n\n\n Nejcenn\u011bj\u0161\u00ed pravidlo plyne p\u0159\u00edmo z mechaniky negativn\u00ed cache: nejd\u0159\u00edv z\u00e1znam vytvo\u0159te, teprve potom ho testujte a zap\u00ednejte monitoring.<\/strong> Po\u0159ad\u00ed „zkus\u00edm, jestli existuje, pak vytvo\u0159\u00edm“ je p\u0159esn\u011b to, co spou\u0161t\u00ed hodinov\u00e9 \u010dek\u00e1n\u00ed. Po\u0159ad\u00ed „vytvo\u0159\u00edm, po\u010dk\u00e1m p\u00e1r minut, pak zkou\u0161\u00edm“ mu p\u0159edch\u00e1z\u00ed \u00fapln\u011b. Pokud monitoring nasazujete na jm\u00e9no, kter\u00e9 teprve vznik\u00e1, p\u0159idejte ho a\u017e po ov\u011b\u0159en\u00ed, \u017ee jm\u00e9no resolvuje.<\/p>\n\n\n\n P\u0159ed pl\u00e1novanou zm\u011bnou existuj\u00edc\u00edho z\u00e1znamu se vyplat\u00ed s p\u0159edstihem sn\u00ed\u017eit TTL<\/strong>. Den p\u0159edem st\u00e1hn\u011bte TTL t\u0159eba na 300, po\u010dkejte, a\u017e star\u00e9 (del\u0161\u00ed) TTL v\u0161ude dob\u011bhne, prove\u010fte zm\u011bnu, a po ov\u011b\u0159en\u00ed TTL zase vra\u0165te na provozn\u00ed hodnotu. Zm\u011bna se pak prop\u00ed\u0161e b\u011bhem minut m\u00edsto hodin.<\/p>\n\n\n\n P\u0159i migraci na novou IP adresu nechte star\u00fd server b\u011b\u017eet<\/strong> soub\u011b\u017en\u011b s nov\u00fdm po dobu alespo\u0148 jednoho p\u016fvodn\u00edho TTL, ide\u00e1ln\u011b d\u00e9le. \u010c\u00e1st sv\u011bta bude je\u0161t\u011b n\u011bjakou dobu chodit na starou adresu a je lep\u0161\u00ed, kdy\u017e tam n\u011bco funk\u010dn\u00edho najde.<\/p>\n\n\n\n P\u0159i lad\u011bn\u00ed se ptejte p\u0159\u00edmo autoritativn\u00edch server\u016f<\/strong>, obejdete t\u00edm ve\u0161ker\u00e9 cache: A posledn\u00ed, m\u00e9n\u011b zn\u00e1m\u00fd tip: pozor na cache ve vlastn\u00edm za\u0159\u00edzen\u00ed.<\/strong> Opera\u010dn\u00ed syst\u00e9m i prohl\u00ed\u017ee\u010d si dr\u017e\u00ed vlastn\u00ed mal\u00e9 DNS cache nad r\u00e1mec resolveru. Kdy\u017e v\u0161echno ostatn\u00ed sed\u00ed a jen v\u00e1\u0161 po\u010d\u00edta\u010d tvrdohlav\u011b vid\u00ed starou hodnotu, pom\u016f\u017ee vy\u010di\u0161t\u011bn\u00ed lok\u00e1ln\u00ed cache nebo prost\u011b chv\u00edle trp\u011blivosti.<\/p>\n\n\n\n TTL ur\u010duje, jak dlouho sm\u00ed resolvery pamatovat odpov\u011b\u010f, a tedy jak rychle se zm\u011bny propisuj\u00ed. \u00daprava existuj\u00edc\u00edho z\u00e1znamu se projev\u00ed zhruba do TTL, u v\u00fdchoz\u00edch 300 sekund tedy do n\u011bkolika minut. Nov\u00fd z\u00e1znam je zr\u00e1dn\u011bj\u0161\u00ed: pokud se na jm\u00e9no kdokoliv dot\u00e1zal p\u0159ed jeho vytvo\u0159en\u00edm, resolver dr\u017e\u00ed odpov\u011b\u010f „neexistuje“ podle negativn\u00edho TTL z\u00f3ny, typicky a\u017e hodinu od prvn\u00edho dotazu. Poskytovatel DNS ovlivn\u00ed jen publikaci na sv\u00fdch serverech a nastaven\u00ed TTL hodnot, ciz\u00ed cache po sv\u011bt\u011b neovlivn\u00ed nikdo. Nejlep\u0161\u00ed obrana je zn\u00e1t po\u0159ad\u00ed: nejd\u0159\u00edv vytvo\u0159it, pak testovat.<\/p>\n","protected":false},"excerpt":{"rendered":" Vytvo\u0159\u00edte nov\u00fd DNS z\u00e1znam, ulo\u017e\u00edte, a nic. Web nejede, monitoring hl\u00e1s\u00ed v\u00fdpadek, ping \u0159\u00edk\u00e1, \u017ee jm\u00e9no neexistuje. Za p\u016fl hodiny najednou v\u0161echno funguje, ani\u017e byste cokoliv zm\u011bnili. Kde se ta p\u016flhodina vzala, kdy\u017e m\u00e1 z\u00e1znam TTL 5 minut? Odpov\u011b\u010f je jedna z nej\u010dast\u011bji p\u0159ehl\u00ed\u017een\u00fdch vlastnost\u00ed DNS a stoj\u00ed za drtivou v\u011bt\u0161inou dotaz\u016f typu „pro\u010d se … <\/p>\nJak re\u00e1ln\u011b prob\u00edh\u00e1 „props\u00e1n\u00ed“ zm\u011bny<\/h2>\n\n\n\n
Nov\u00fd z\u00e1znam: past jm\u00e9nem negativn\u00ed cache<\/h2>\n\n\n\n
ping nova-sluzba.mojedomena.cz<\/code>. Neexistuje, jasn\u011b, v\u017edy\u0165 jste ho je\u0161t\u011b nevytvo\u0159ili. Jen\u017ee t\u00edmhle jedin\u00fdm dotazem jste resolveru \u0159ekli, a\u0165 si odpov\u011b\u010f „neexistuje“ zapamatuje. Pak z\u00e1znam vytvo\u0159\u00edte, na autoritativn\u00edch serverech je b\u011bhem p\u00e1r minut, ale v\u00e1\u0161 resolver se u\u017e nept\u00e1. Dr\u017e\u00ed NXDOMAIN a bude ho dr\u017eet a\u017e hodinu od toho va\u0161eho zv\u011bdav\u00e9ho pingu. Tot\u00e9\u017e ud\u011bl\u00e1 monitoring, kter\u00fd spust\u00edte d\u0159\u00edv, ne\u017e z\u00e1znam existuje: prvn\u00ed kontrola si „vyrob\u00ed“ negativn\u00ed cache a dal\u0161\u00ed kontroly do n\u00ed nar\u00e1\u017eej\u00ed.<\/p>\n\n\n\nCo poskytovatel DNS ovlivnit m\u016f\u017ee a co ne<\/h2>\n\n\n\n
Best practices, kter\u00e9 v\u00e1s \u010dek\u00e1n\u00ed u\u0161et\u0159\u00ed<\/h2>\n\n\n\n
dig zaznam.mojedomena.cz @ns.poskytovatele.cz<\/code>. Pokud autoritativn\u00ed server vrac\u00ed spr\u00e1vnou hodnotu, zm\u011bna je publikovan\u00e1 a zbytek je jen \u010dek\u00e1n\u00ed na cache. Pokud nevrac\u00ed, probl\u00e9m je u poskytovatele nebo v z\u00f3n\u011b. Tenhle jedin\u00fd p\u0159\u00edkaz spolehliv\u011b rozsoud\u00ed, na \u010d\u00ed stran\u011b z\u00e1drhel je. Podrobn\u011bj\u0161\u00ed postup hled\u00e1n\u00ed p\u0159\u00ed\u010diny najdete v n\u00e1vodu DNS \u2013 \u0158e\u0161en\u00ed probl\u00e9m\u016f<\/a>. Stav props\u00e1n\u00ed u velk\u00fdch resolver\u016f zkontrolujete dotazem p\u0159\u00edmo na n\u011b (dig zaznam.mojedomena.cz @8.8.8.8<\/code>) nebo n\u011bkter\u00fdm z ve\u0159ejn\u00fdch n\u00e1stroj\u016f na kontrolu propagace.<\/p>\n\n\n\nShrnut\u00ed<\/h2>\n\n\n\n