← Všechny kurzyZpět do simulátoru →

DNS a jména v síti

Z „telefonního seznamu“ do hloubky: kdo se koho ptá (klient, resolver, autorita), cache a TTL, vlastní místní DNS ve firmě i veřejné resolvery a cesta od kořene, typy záznamů (A, CNAME, MX, TXT, NS, PTR) a k čemu slouží — a nakonec co se stane, když DNS vypadne nebo lže.

Tohle je textový náhled lekcí pro čtení. Plná verze – interaktivní simulátor s animacemi, úlohami a kvízy – běží v aplikaci.

▶ Spustit interaktivní verzi

Lekce 1: Od jména k adrese

Proč jména: adresy se mění, jména zůstanou

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKčlověk si pamatuje jméno, ne číslo

V Kurzu 1 sis ukázal, že DNS je „telefonní seznam internetu“: napíšeš example.com a DNS ti vrátí číslo, IP adresu. Tenhle kurz jde dál – ukáže, kdo tu odpověď vlastně dává, odkud ji bere a co se stane, když ji dá špatně. Začneme otázkou, která se skoro nikdy neptá nahlas: proč vůbec jména používáme? Odpověď „aby si to lidi zapamatovali“ je jen půlka pravdy. Ta druhá, důležitější, zní: adresy se mění, jména zůstanou. Server se přestěhuje k jinému poskytovateli, dostane novou IP adresu, firma vymění hardware, služba se rozdělí na deset strojů v pěti zemích – a ty pořád píšeš to samé jméno. Kdyby v prohlížeči, v odkazech, v konfiguracích a v e-mailech byla natvrdo čísla, každé takové stěhování by znamenalo obejít všechny ty stroje a čísla přepsat. Jméno tedy funguje jako vrstva odstupu mezi tím, co si pamatuješ ty, a tím, kde služba zrovna fyzicky je. Na scéně to vidíš celé: tvůj PC zná jméno, DNS zná dvojici jméno↔adresa a WEB má nějakou adresu, která se klidně zítra změní. Vyzkoušej si to i v simulátoru: každý host (PC, server…) má v detailu na záložce Typ a služby pole Jméno v DNS (FQDN) – a pod tímhle jménem ho pak půjde najít v testu průchodu (panel testů vedle plátna), kde se cíle podle jmen nabízejí ve skupině „Podle jména (DNS)“. Samotné vyplnění jména ale nestačí – jméno musí ještě někdo servírovat, totiž DNS server ve svých záznamech. Přesně to si postavíš v lekci 2.

Krok za krokem

  1. Do prohlížeče píšeš jméno – web.acme.local. Číslo bys si nezapamatoval a nepředal ho kolegovi po telefonu.
  2. Jenže server se jednou přestěhuje a dostane jinou IP adresu. To se v životě sítě stává běžně.
  3. Opravit stačí jediný záznam v DNS. Jméno zůstane stejné – nikdo z uživatelů nic přepisovat nemusí.
  4. Jméno je vrstva odstupu mezi tebou a tím, kde služba fyzicky je. V simulátoru ho zadáš v poli Jméno v DNS (FQDN).

Kdo se koho ptá: klient, resolver, autorita

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKklient: web.acme.local = ?

Kurz 1 kreslil DNS jako jednu krabičku, která odpověď prostě zná. Ve skutečnosti jsou v každém překladu jména tři role a rozdíl mezi nimi je jádro celého kurzu. 1) Klient – tvůj počítač. Ten toho ví nejmíň: umí položit jednu otázku („jaká IP patří k tomuhle jménu?“) a čeká na hotovou odpověď. Nic dalšího neřeší. 2) Resolver – server, kterého se klient ptá; česky „rozřešovač“. Bývá to DNS server ve tvé síti nebo u poskytovatele. Resolver odpověď zpravidla nezná – ale umí ji zjistit: obejde za tebe ostatní servery a vrátí ti výsledek. Je to takový poslíček. 3) Autoritativní server – ten, kdo odpověď opravdu vlastní. Drží záznamy o své doméně, protože je tam někdo zapsal. Když řekne „web.acme.local je 10.0.2.20“, je to definice, ne dohad. Tenhle rozdíl se vyplatí vzít vážně: autorita odpověď VÍ, resolver ji jen ZJISTÍ. Ptát se autority napřímo bys mohl, ale musel bys sám vědět, která autorita to je – a to je přesně práce, kterou za tebe dělá resolver. V simulátoru je ta role vidět v nastavení sítě jako „DNS server pro tuhle síť“: klienti z té sítě se ptají právě jeho. Roli resolveru přitom nemusí hrát jen server – zvládne ji i router, firewall nebo L3 switch. Jak přesně, uvidíš v příští lekci v modulu „Kdo překládá? Router jako resolver“.

Krok za krokem

  1. Klient umí jediné: položit otázku „jaká IP patří k tomuhle jménu?“ a počkat na hotovou odpověď.
  2. Ptá se resolveru. Ten odpověď zpravidla nezná – jeho práce je ji za tebe zjistit u ostatních serverů.
  3. Resolver dojde k autoritativnímu serveru – tomu, kdo záznam vlastní. Jeho odpověď je definice, ne dohad.
  4. Resolver vrátí klientovi hotový výsledek. V simulátoru tuhle roli nastavuješ v síti jako „DNS server pro tuhle síť“.

Cache a TTL: proč se neptáme pokaždé

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKprvní dotaz: resolver musí ven

Kdyby resolver obcházel svět při každém dotazu, byl by internet nesnesitelně pomalý – jen otevření jedné stránky se ptá na desítky jmen. Proto si každý článek řetězu odpovědi ukládá do cache (mezipaměti): klient ve svém systému i prohlížeči, a hlavně resolver pro všechny své uživatele naráz. Když se pak kdokoli zeptá na to samé jméno, odpověď přijde okamžitě z paměti, bez jediného dotazu ven. Tohle je ten důvod, proč je druhé otevření stránky znatelně rychlejší než první. Jenže odpověď v paměti stárne: co když se adresa mezitím změnila? Aby se cache nikdy neseklo na trvalé lži, nese každá DNS odpověď s sebou číslo TTL (time to live – „doba života“): kolik sekund se ta odpověď smí schovávat, než se musí zahodit a zjistit znovu. TTL nastavuje ten, kdo záznam vlastní – tedy autorita. A je to zajímavá volba mezi dvěma nepříjemnostmi. Dlouhé TTL (třeba den) = málo dotazů, rychlé odpovědi, ale změna se ve světě projeví až za den. Krátké TTL (třeba minuta) = změna je skoro okamžitá, ale servery dostanou mnohem víc dotazů. Praktický důsledek si zapamatuj: když měníš záznam, změna se neprojeví hned – část světa ji uvidí až po vypršení TTL. Proto se před plánovaným stěhováním serveru TTL nejdřív sníží, teprve pak se stěhuje. Až budeš mít po lekci 2 postavený vlastní DNS, vyzkoušej si to v simulátoru. Spusť v panelu testů tentýž test podle jména dvakrát po sobě ze stejného zařízení. Podruhé uvidíš „z lokální cache klienta“ – klient se resolveru ani nezeptal. Teď stejné jméno z jiného zařízení: to se zeptá, ale dostane „z cache resolveru“. To jsou přesně ty dvě úrovně cache. (Zbývající TTL u každého záznamu vidíš v pokročilém režimu – přepínač Jednoduchý / Pokročilý je nahoře v liště.) Co si zařízení pamatuje, vidíš v jeho detailu na záložce DNS cache – a jde to i ručně vyprázdnit (klasický helpdesk krok). V pokročilém režimu si všimneš, že si klient pamatuje i „neexistuje“ (negativní caching) a u každého záznamu zbývající čas. Pozor, zdejší cache je učební zjednodušení – jakmile v topologii cokoli změníš, vyprázdní se, takže tvoje úprava záznamu se projeví hned (skutečný svět by na TTL musel počkat).

Krok za krokem

  1. První dotaz na jméno stojí čas: resolver musí obejít svět a odpověď teprve zjistit.
  2. Odpověď si resolver uloží do cache a s ní i číslo TTL: kolik sekund se smí schovávat.
  3. Druhý dotaz na to samé jméno se vrátí okamžitě z cache – ven neputuje nic. Proto je druhé otevření rychlé.
  4. Daň za rychlost: když adresu změníš, část světa to uvidí až po vypršení TTL. Proto se TTL před stěhováním nejdřív sníží.

▶ Otevřít v simulátoru

Lekce 2: Místní DNS: jména ve vlastní síti

Proč mít DNS doma a ve firmě

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKvlastní záznam: web.acme.local → WEB

Zatím to znělo, jako by DNS byla věc internetu. Není – vlastní DNS server dává obrovský smysl i uvnitř firmy nebo domácnosti, a to ze tří důvodů. 1) Jména vlastních serverů. Tvoje tiskárna, souborový server ani interní aplikace v žádném veřejném DNS nejsou a nikdy nebudou – nikdo mimo firmu je nemá potkat. Přesto chceš psát web.acme.local místo 10.0.2.20. Vlastní DNS ti to umožní: záznamy si do něj prostě zapíšeš sám. 2) Nezávislost a rychlost. Interní jméno se přeloží doma, během milisekund, a bez toho, aby o něm kdokoli venku věděl. Když navíc resolver stojí ve tvé síti, uživatelé mají odpovědi na běžná jména už v jeho cache. 3) Přehled a kontrola. Resolver vidí, na co se tvoje síť ptá – to je zlatý zdroj pro řešení potíží i pro bezpečnost (v Kurzu 8 – Pokročilá bezpečnost – sis ukázal, že podivné DNS dotazy umí prozradit tunel či malware). Za tenhle luxus platíš jednu cenu, kterou probereme na konci téhle lekce: resolver se stane kritickým zařízením. V simulátoru si to postav: přidej z palety Server a v jeho detailu (Typ a služby) zapni službu DNS (port 53) – DNS je služba, ne zvláštní typ zařízení. Tím se u serveru odemkne nová záložka DNS a v ní editor záznamů (jméno → IP adresa); vyplň je ručně nebo klikni na „Doplnit ze jmen zařízení“. To nasaje i adresy webů: web server (má zapnutý port 80/443) si je nese na vlastní záložce Web, takže jeden web server tak může obsloužit víc adres. Nakonec v nastavení sítě klientů zvol tenhle server jako „DNS server pro tuhle síť“ – bez tohohle kroku se jména v síti nepřeloží vůbec, protože klienti nemají koho se ptát (a kontrola topologie ti síť bez resolveru vytkne). Od té chvíle jde v testu průchodu vybrat cíl ve skupině „Podle jména (DNS)“.

Krok za krokem

  1. Jména vlastních serverů: tvoje tiskárna ani interní web v žádném veřejném DNS nejsou. Do vlastního DNS si je zapíšeš sám.
  2. Nezávislost a rychlost: interní jméno se přeloží u tebe doma, během milisekund, a nikdo venku o něm nemusí vědět.
  3. Přehled a kontrola: resolver vidí, na co se tvoje síť ptá – zlatý zdroj pro řešení potíží i pro bezpečnost (Kurz 8 – Pokročilá bezpečnost).
  4. V simulátoru: přidej DNS server, vyplň záznamy (nebo „Doplnit ze jmen zařízení“) a síti nastav „DNS server pro tuhle síť“.

Záznam a forwarding: co znám, zbytek pošlu dál

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKco znám → odpovím sám

Tvůj firemní resolver má tedy zapsaná jména vlastních serverů. Ale co se stane, když se ho někdo zeptá na example.com – jméno, které mu do záznamů nikdo nezapsal? Odpověď je jednoduché pravidlo o dvou větách: co znám, na to odpovím – co neznám, pošlu dál. Tomu „poslání dál“ se říká forwarding. Resolver dotaz na cizí jméno předá jinému serveru (typicky resolveru poskytovatele nebo veřejnému resolveru), počká na odpověď, uloží si ji do cache a vrátí klientovi. Klient nic nepozná – ptal se jen jednou a dostal odpověď. Zajímavější je druhá možnost: forwarding vypnout. Pak resolver na neznámé jméno odpoví „takové jméno neexistuje“ – zkratkou NXDOMAIN (tak to hlásí simulátor; skutečný resolver by na dotaz, na který se odmítá doptat, spíš odpověděl „odmítám“ – REFUSED, viz slovníček). To zní jako porucha, ale je to legitimní volba: v přísně oddělené síti (třeba v OT prostředí z Kurzu 13 – OT/ICS: bezpečnost průmyslových sítí) nechceš, aby se cokoli uvnitř ptalo ven; resolver, který umí jen vlastní jména, je tam feature, ne bug. V simulátoru máš přesně tenhle přepínač (v pokročilém režimu): na záložce DNS serveru najdeš „Forwardovat neznámá jména ven (do internetu)“. V jednoduchém režimu je ten přepínač schovaný a platí hodnota z topologie – preset nebo úloha ho tedy může mít i vypnutý. Zapnuté = na jméno, které neznám, se doptám ven. Vypnuté = odpovím, že takové jméno neexistuje. Vyzkoušej si obojí – a všimni si, že když resolver forwardovat chce, ale ven se nedostane (třeba ho tam nepustí firewall), skončí to stejně: jméno se nepřeloží.

Krok za krokem

  1. Pravidlo věta první: na jméno, které mám ve svých záznamech, odpovím sám a hned.
  2. Jenže teď se někdo zeptá na example.com – to jméno mi do záznamů nikdo nezapsal.
  3. Věta druhá: forwarding. Dotaz předám dál, počkám na odpověď, uložím do cache a vrátím klientovi. Klient nic nepozná.
  4. Když forwarding vypneš, odpovím NXDOMAIN – „takové jméno neexistuje“. V přísně oddělené síti je to feature, ne bug.

Kdo překládá? Router jako resolver

PCRTRISP DNSWEBklient se ptá routeru: web = ?

Doteď jsme roli resolveru kreslili jako samostatný DNS server. Jenže vzpomeň si, jak to máš doma: žádný server tam nestojí – a jména se přesto překládají. Kdo to dělá? Router. Domácí router je typický forwarder: sám žádné záznamy nemá, dotazy klientů jen přeposílá dál na resolver poskytovatele (upstream), odpovědi si ukládá do cache a klientům je vrací. Pro klienty je resolverem on – tomu, kdo za něj překlad reálně odvede, se říká upstream. Firemní síť to mívá jinak: tam roli resolveru hraje plnohodnotný DNS server s vlastními záznamy (jak sis postavil v prvním modulu téhle lekce) – protože interní jména jako web.acme.local žádný upstream nezná a znát nemá. Kdy co zvolit? V malé síti klidně nech roli přímo na routeru; jakmile chceš resolver zálohovat nebo víc zatížit, vyplatí se samostatný server. Hranice mezi oběma rolemi je přesně tohle:forwarder nic neví a všechno posílá dál; server odpovědi vlastní. V simulátoru si obojí vyzkoušíš v pokročilém režimu: router, firewall nebo L3 switch má v detailu záložku DNS s volbou „Role DNS“ – forwarder (dotazy přeposílá dál) s výběrem „Upstream DNS server“ (bez výběru jdou dotazy ven na internet, přesně jako u domácího routeru), nebo DNS server (vlastní záznamy) se stejným editorem záznamů, jaký znáš ze serveru. Pak stačí router zvolit v nastavení sítě jako „DNS server pro tuhle síť“. A poslední dílek skládačky: resolver nemusí být pro všechny stejný. V pokročilém režimu může mít konkrétní zařízení vlastní DNS server (override v jeho síťovém nastavení) – ptá se pak jinam než zbytek sítě. Hodí se pro testování, ale pamatuj na to i jako diagnostik: „všem to jde, jen jemu ne“ může znamenat, že se ten jeden stroj ptá jiného resolveru než ostatní.

Krok za krokem

  1. Doma žádný DNS server nestojí – klient se ptá routeru. Pro klienty je resolverem on.
  2. Domácí router je forwarder: sám nic neví, dotaz přepošle na upstream (DNS poskytovatele), odpověď cachuje a vrátí.
  3. Druhá role: DNS server s vlastními záznamy – firemní router či firewall odpoví na interní jméno sám, žádný upstream ho znát nemusí. V pokročilém režimu: záložka DNS → „Role DNS“.
  4. A pozor: konkrétní zařízení může mít vlastní DNS server (override, pokročilý režim). „Všem to jde, jen jemu ne“ pak znamená: ptá se jiného resolveru.

Když DNS vypadne: server běží, ale nikdo ho nenajde

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKserver běží, na adresu to projde ✓

A teď ta cena za pohodlí. Když má celá firma jeden resolver a ten vypadne – nebo se k němu klienti prostě nedostanou – nastane situace, kterou zná každý helpdesk a která na první pohled nedává smysl: síť jede, ale nic nefunguje. Web server běží. Firewall pouští, co má. Ping na adresu prochází. A přesto se v prohlížeči nic neotevře, protože prohlížeč vůbec nezjistí, kam se má připojit. Server je zdravý, jen ho nikdo nenajde. Pozor na past, do které padne skoro každý začátečník: DNS server nemusí být rozbitý, aby tohle nastalo. Stačí, že se k němu dotaz nedostane – firewall blokne UDP port 53, spadne linka, síť dostane špatně nastaveného resolvera. Z pohledu klienta je výsledek identický. Naštěstí existuje diagnostický trik, který si zapamatuj na celý život: zkus stejný cíl podle jména a pak podle adresy. Když to na adresu jde a přes jméno ne, závada není v síti – je v DNS. A pozor: jediný resolver drží překlad jmen celé sítě – když ho necháš samotný, kontrola topologie ti ho sama vytkne jako jediný bod selhání (SPOF), tak ho radši zdvoj: přidej druhý DNS server a v nastavení sítě ho zvol jako Záložní DNS server – klient se ho zeptá, když primární nedosáhne (výpadek nebo blokovaný port 53) – a jakmile primární zase odpovídá, vrátí se k němu; záloha slouží jen po dobu výpadku. Vyzkoušej si to: primární pravým klikem vypni a jméno se přesto přeloží „přes záložní DNS server“. Výpadek DNS je vidět i v Simulaci reálného provozu: toky, které jdou na jméno, se bez překladu vůbec nerozjedou a v logu svítí „jméno se nepřeložilo (DNS)“. Právě tohle si teď vyzkoušej v úloze „Síť jede, ale nic nefunguje (DNS)“: v testu průchodu vyber cíl web.acme.local ze skupiny „Podle jména (DNS)“ (překlad selže) a pak stejný cíl jako zařízení Web na adresu (projde). Rozdíl uvidíš na vlastní oči. A ponaučení pro návrh? Resolver je kritické zařízení – zaslouží si stejnou péči jako brána: dva servery, aby jeden směl vypadnout (Kurz 14 – Odolnost a škálování sítě).

Krok za krokem

  1. Výchozí stav: server běží a na jeho adresu provoz normálně projde. Se sítí není nic v nepořádku.
  2. Jenže dotaz na resolver se nedostane – firewall blokuje UDP 53, spadla linka nebo je resolver mrtvý. Pro klienta je to jedno a totéž.
  3. Výsledek: síť jede, ale nic nefunguje. Server je zdravý, jen ho nikdo nenajde – prohlížeč nezjistí, kam se připojit.
  4. Trik na celý život: jde to na adresu a přes jméno ne? Vina je v DNS, ne v síti. Zkus úlohu „Síť jede, ale nic nefunguje (DNS)“.

▶ Otevřít v simulátoru

Lekce 3: Veřejné DNS: cesta od kořene

Hierarchie jmen: kořen, TLD, doména

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKjméno se čte zprava: kořen je vpravo

Zatím jsme se pohybovali doma, kde si jména vymýšlíš sám. Venku na internetu by ale nešlo, aby si každý zapsal, co chce – jména by se srazila. Proto je veřejný jmenný prostor hierarchický strom a platí u něj jedno nezvyklé pravidlo: jméno se čte zprava doleva. Vezmi www.example.com. Úplně vpravo je (neviditelně) kořen – vrchol celého stromu a společný začátek všech jmen na světě; „neviditelně“ proto, že v běžném zápisu jména se vůbec nepíše (formálně je to prázdný konec za poslední tečkou). Pod ním je com, tzv. TLD (top-level domain – doména nejvyšší úrovně; třeba com, cz, org). Pod ním example – to je doména, kterou si někdo zaregistroval a od té chvíle je jejím vlastníkem. A teprve úplně vlevo je www – konkrétní jméno uvnitř té domény, o kterém rozhoduje výhradně její majitel. Ta hierarchie není samoúčelná: řeší dvě věci najednou. Jedinečnost – example.com může být na světě jen jeden, protože jméno se přiděluje shora dolů. A rozdělení práce (odborně delegace) – kořen se nestará o miliardy jmen, jen řekne „na com se zeptej tamhle“; com se nestará o obsah domén, jen řekne „example.com spravuje tamhleten server“. Každé patro zná jen jeden krok a zbytek předá níž. Jak se po tom stromu chodí, ukáže další modul.

Krok za krokem

  1. Nezvyklé pravidlo: jméno se čte zprava doleva. Úplně vpravo je (neviditelně) kořen – vrchol stromu všech jmen.
  2. Pod kořenem je TLD – doména nejvyšší úrovně, třeba com, cz nebo org.
  3. Pod TLD je doména (example) – tu si někdo zaregistroval a od té chvíle o jejím obsahu rozhoduje jen on.
  4. Vlevo je konkrétní jméno uvnitř domény (www). Strom zajistí jedinečnost i delegaci: každé patro zná jen krok dolů.

Rekurze v praxi: kořen → TLD → autorita

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKklient se ptá JEDNOU a čeká

Teď to spojíme: tři role z lekce 1 a strom z minulého modulu. Klient položí resolveru jednu otázku a čeká. Resolver nemá odpověď v cache a nikoho, komu by ji forwardoval – takže se vydá na cestu sám a obejde strom shora dolů. Tomu se říká rekurze (rekurzivní dotaz): klient se ptá jednou, resolver se ptá kolikrát je potřeba. Vypadá to takhle. 1) Resolver se zeptá kořene: „kde je www.example.com?“ Kořen odpověď nezná a ani neřeší – vrátí odkaz: „na com se zeptej těchhle serverů.“ 2) Resolver se zeptá serveru TLD com. Ten taky odpověď nezná, ale ví o krok víc: „doménu example.com spravují tyhle autoritativní servery.“ 3) Resolver se zeptá autority – a ta jako jediná odpověď vlastní: „www.example.com je 203.0.113.10.“ 4) Resolver výsledek uloží do cache a pošle klientovi. Všimni si dvou věcí. Za prvé: nikdo z těch tří nelhal ani nehádal – každý řekl jen to, co ví, a to je vždycky buď odkaz o patro níž, nebo hotová odpověď. Za druhé: tohle celé se děje jen při prvním dotazu. Odpovědi kořene i TLD mají dlouhé TTL, takže resolver má patra stromu dávno v cache a reálně obvykle chodí rovnou k autoritě. Ta „obchůzka kolem světa“ je tedy výjimka, ne pravidlo.

Krok za krokem

  1. Klient položí jednu otázku a čeká. Že za ní bude obchůzka po světě, ho nezajímá – to je rekurze.
  2. Kořen: odpověď nezná, vrátí odkaz – „na com se zeptej těchhle serverů“.
  3. TLD com: taky neví, ale ví o krok víc – „doménu example.com spravují tyhle autoritativní servery“.
  4. Autorita odpověď vlastní a řekne ji. 4) Resolver ji uloží do cache a vrátí klientovi. Na to samé jméno pak odpoví rovnou z cache – a na další jména v téhle doméně už chodí rovnou k autoritě.

Veřejné resolvery a soukromí

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKvýchozí: resolver od poskytovatele

Kdo je tedy tvůj resolver, když žádný vlastní nemáš? Ve výchozím stavu ten, kterého ti přidělí poskytovatel internetu – doma automaticky přes DHCP. Existuje ale i druhá možnost: veřejné resolvery, které kdokoli na světě smí použít zdarma. Nejznámější mají schválně adresy, co se dají zapamatovat: 8.8.8.8 (Google) a 1.1.1.1 (Cloudflare). Lákají tím, že bývají rychlé, spolehlivé a odpovídají i tam, kde resolver poskytovatele zlobí nebo některá jména cenzuruje. Než ale jeden z nich nastavíš, domysli si tenhle kurz do důsledku. Resolver vidí každý dotaz, který mu pošleš – tedy seznam všech jmen, na která se tvoje síť ptá. To je mimořádně výmluvný záznam: jaké weby čteš, jakou banku máš, jaké aplikace ti běží na pozadí a v kolik hodin. Zapamatuj si to takhle: kdo je tvůj resolver, ten vidí, na co se ptáš. Volba veřejného resolveru tedy není „lepší, nebo horší“ – je to volba, komu ten seznam dáš: poskytovateli, velké firmě na druhém konci světa, nebo (u vlastního resolveru) sobě. A ještě jeden důvod, proč to řešit vážně: dotazy jsou klasicky nešifrované, takže je po cestě vidí i kdokoli další – a odpověď jde podvrhnout. Obojí je téma poslední lekce. Praktické doporučení pro firmu: mít vlastní resolver pro interní jména, který zbytek forwarduje na jeden vědomě zvolený server ven. Nejlepší z obou světů: vlastní jména doma a jedno místo, kde je vidět a nastavit, komu se svěřuješ.

Krok za krokem

  1. Ve výchozím stavu je tvým resolverem ten, kterého ti přidělí poskytovatel internetu – doma automaticky přes DHCP.
  2. Druhá možnost: veřejné resolvery s adresou k zapamatování – 8.8.8.8, 1.1.1.1. Bývají rychlé a spolehlivé.
  3. Háček: kdo je tvůj resolver, ten vidí, na co se ptáš – jaké weby čteš, jakou máš banku, co ti běží na pozadí.
  4. Doporučení pro firmu: vlastní resolver na interní jména, který zbytek forwarduje na jeden vědomě zvolený server ven.

▶ Otevřít v simulátoru

Lekce 4: Typy záznamů a k čemu slouží

A a AAAA: jméno na IP adresu

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKA: web.acme.local → 10.0.2.20

Celý kurz jsme mluvili o „záznamu“, jako by byl jen jeden druh. Není – DNS není jen seznam adres, je to malá databáze o doméně a každý řádek v ní má svůj typ. Ten typ říká, na co se vlastně ptáš: jednu doménu se totiž můžeš zeptat na adresu jejího webu, na to, kam jí doručit poštu, nebo na to, kdo ji spravuje – a dostaneš pokaždé jinou odpověď. Nejdůležitější a nejčastější typ je A: dvojice jméno → IPv4 adresa. Tohle je ten záznam, který jsme celou dobu kreslili, a je to zdaleka nejčastější typ dotazu na světě. Vypadá prostě: web.acme.local → 10.0.2.20. Jeho dvojče je AAAA (čte se „quad A“, česky „čtyři áčka“): totéž, ale jméno → IPv6 adresa. Proč to jméno? IPv6 adresa je čtyřikrát delší než IPv4 – odtud čtyři písmena. Dobré vědět: jméno může mít oba záznamy naráz a moderní počítač si sám vybere, kterou verzí protokolu se připojí (obvykle zkusí obě a použije tu, co odpoví dřív). A ještě jedna věc, kterou začátečníci často nečekají: jedno jméno může mít víc A záznamů s různými adresami. Server pak odpovídá střídavě různými a provoz se tím zhruba rozdělí mezi víc strojů – je to nejlevnější (a nejhloupější) druh rozdělování zátěže, protože DNS na rozdíl od load balanceru z Kurzu 14 (Odolnost a škálování sítě) vůbec neví, jestli ty stroje ještě žijí. V simulátoru je záznam jméno → zařízení právě A záznam (střídání víc adres na jedno jméno zdejší model nedělá – dvě áčka se stejným jménem vrátí pořád to první) – v detailu DNS serveru ho v jednoduchém režimu zadáváš rovnou (jméno → cíl); v pokročilém režimu navíc vidíš u každého řádku rozbalovací typ a TTL (tlačítko „Doplnit ze jmen zařízení“ zakládá A záznamy – a u poštovních serverů i MX). Rovnou předesílám hranici, ať tě to v dalších modulech nepřekvapí: vyzkoušet si jde A, CNAME (z následujícího modulu) a MX (z modulu o poště). TXT, NS a PTR simulátor nemá – u nich zůstává výklad teorií, ale znát je potřebuješ, protože v reálné doméně na ně narazíš hned.

Krok za krokem

  1. A je dvojice jméno → IPv4 adresa – ten záznam, který jsme celou dobu kreslili. Devět z deseti dotazů míří na něj.
  2. AAAA („quad A“) je totéž pro IPv6. Čtyři písmena proto, že IPv6 adresa je čtyřikrát delší než IPv4.
  3. Jméno může mít oba záznamy naráz. Moderní počítač zkusí obě verze protokolu a použije tu, která odpoví dřív.
  4. Jedno jméno může mít víc A záznamů. Provoz se tím zhruba rozdělí – ale DNS neví, jestli ty stroje žijí (na rozdíl od LB, Kurz 14 – Odolnost a škálování sítě).

CNAME: přezdívka jiného jména

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKshop.example.com = ?

Druhý typ, který potkáš pořád, je CNAME – přezdívka (canonical name – „kanonické jméno“). Nemíří na adresu, ale na jiné jméno: „shop.example.com je ve skutečnosti web.example.com – zeptej se znovu na tohle“. Ten dotaz navíc pak položí resolver a klientovi vrátí obojí naráz – klient se podruhé neptá. Zní to jako zbytečná okružní jízda, ale řeší jednu konkrétní bolest: jedno místo pravdy. Představ si, že na jednom serveru máš pět jmen – shop, blog, intranet, wiki a www. Uděláš-li z každého A záznam s adresou, budeš při stěhování serveru přepisovat pět adres a na jednu určitě zapomeneš. Uděláš-li z nich CNAME na jediné jméno, které má A záznam, budeš při stěhování měnit jedno číslo na jednom místě. CNAME se proto masově používá i tam, kde adresu neznáš ani znát nemůžeš: cloudové služby a CDN ti řeknou „nasměruj na nás CNAME“, protože svoje adresy mění, jak potřebují. Dvě věci, které se vyplatí vědět. Řetězení: CNAME smí ukazovat na jméno, které je zase CNAME – každý článek ale znamená další dotaz, takže dlouhý řetěz zpomaluje a přidává místa, kde se to může rozbít (a nikdy se nesmí zacyklit). A omezení: jméno, které má CNAME, už u sebe zpravidla nesmí mít jiné záznamy – proto na kořen domény (example.com bez www) CNAME klasicky nedáš, potřebuješ tam A. Vyzkoušej si to: v detailu DNS serveru v pokročilém režimu přepni u záznamu typ na CNAME a místo zařízení zadej cílové jméno. Test podle jména ti pak ukáže celou cestu přezdívek. Zkus i řetěz zacyklit – simulátor to pozná a řekne ti to (skutečný resolver taky).

Krok za krokem

  1. Klient se ptá na shop.example.com. Čeká adresu – jenže tohle jméno žádnou vlastní adresu nemá.
  2. Odpověď je CNAME – přezdívka: „shop je ve skutečnosti web.example.com, zeptej se na tohle“.
  3. Resolver se tedy zeptá znovu – a až to jméno má A záznam s adresou. Přezdívka ho posunula o jeden dotaz dál.
  4. Smysl: jedno místo pravdy. Pět jmen jako CNAME na jedno jméno s A záznamem = při stěhování měníš jedno číslo, ne pět.

MX a TXT: pošta a ověření

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKMX: kam doručit poštu pro example.com?

Teď dva typy, které dohromady drží e-mail. Když napíšeš zprávu na nekdo@example.com, kam ji tvůj poštovní server doručí? Adresu webu použít nemůže – web a pošta klidně stojí na úplně jiných strojích. Proto existuje MX (mail exchanger – „výměník pošty“): záznam, který o doméně říká kam doručovat poštu. Odesílající server se zeptá na MX domény example.com, dostane jméno poštovního serveru, to si přeloží na adresu (A záznamem – vidíš, jak se typy skládají) a teprve tam se připojí. MX jich může být víc a každý má prioritu – číslo, kde nižší znamená přednější. To je jednoduchá redundance: když hlavní server neodpovídá, pošta jde na záložní. MX si můžeš vyzkoušet i v simulátoru: server s poštovní službou (port 25/143) má záložku Mail, kam zadáš doménu; DNS ji tlačítkem „Doplnit ze jmen zařízení“ nasaje jako MX záznam a v testu pak zvolíš cíl „Pošta pro doménu (MX)“ – uvidíš, na který mail server to míří. Rovnou ale hranice: priority simulátor nemá – MX tu míří přímo na zařízení, takže druhý MX jako zálohu si vyzkoušet nejde a zůstává u výkladu. TXT je oproti tomu prostě volný text u domény, který si tam vlastník smí napsat, co chce. Zní to jako nesmysl, ale právě z něj vyrostly dvě dnes nepostradatelné věci. Ověření vlastnictví domény: služba ti řekne „přidej si do TXT tenhle náhodný řetězec“ a pak si ho ověří. Když ho tam máš, prokázal jsi, že doménu opravdu ovládáš – protože do jejího DNS umí zapisovat jen její majitel. A SPF: TXT záznam, ve kterém vlastník vyjmenuje servery, které smějí odesílat poštu jeho jménem. Příjemce si pak ověří, jestli zpráva přišla z povoleného serveru – a když ne, je to nejspíš podvrh. Nejlepší na tom je ta myšlenka: DNS se tu z pouhého seznamu adres stalo místem, kde vlastník domény veřejně vyhlašuje pravidla o své doméně.

Krok za krokem

  1. Píšeš na nekdo@example.com. Kam to doručit? Adresu webu použít nejde – pošta stojí jinde. Od toho je MX.
  2. MX vrátí jméno poštovního serveru – to si odesílatel přeloží A záznamem. Víc MX má priority: nižší číslo je přednější, ostatní jsou záloha.
  3. TXT je volný text u domény. Slouží k ověření vlastnictví: zapiš si tam náhodný řetězec – zapsat ho umí jen majitel domény.
  4. A SPF: TXT, kde vlastník vyjmenuje servery, které smějí odesílat poštu jeho jménem. Zpráva odjinud je nejspíš podvrh.

NS a PTR: delegace a zpětný překlad

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKNS: tuhle doménu spravuje tenhle server

Poslední dva typy uzavírají obrázek. NS (name server) je záznam, který říká: tuhle část jmenného prostoru spravuje tenhle server. Je to přesně ta delegace ze třetí lekce, zapsaná jako řádek v databázi: v TLD com je NS záznam, který na dotaz po example.com vrátí jména autoritativních serverů té domény. Odkazy, po kterých resolver při rekurzi chodí, tedy nejsou žádná magie – jsou to NS záznamy. Firmy je používají i uvnitř: „o celou větev production.acme.local se stará jiný server“. PTR (pointer – „ukazatel“) jde naopak: IP adresa → jméno. Zpětný překlad. Ptáš se „kdo je 203.0.113.10?“ a dostaneš jméno. Dvě věci pozor: PTR se udržuje zvlášť od A záznamu (nevzniká automaticky) a nastavuje ho ten, komu adresa patří – tedy zpravidla poskytovatel, ne majitel jména. Proto se na PTR nedá spoléhat jako na důkaz. K čemu tedy je? Za prvé pro logy a diagnostiku: v záznamu incidentu je mail.example.com nesrovnatelně čitelnější než holé číslo. A za druhé, mnohem prakticky důležitěji, pro antispam: poštovní servery běžně odmítají zprávy ze strojů, které nemají rozumný PTR odpovídající jménu, kterým se představují. Logika je hezky prostá – nastavit PTR může jen ten, kdo tu adresu opravdu ovládá, takže je to laciné, ale účinné síto na náhodně infikované počítače, ze kterých se chrlí spam.

Krok za krokem

  1. NS říká, který server spravuje danou část jmen. Odkazy, po kterých resolver při rekurzi chodí, nejsou magie – jsou to NS záznamy.
  2. Firmy delegují i uvnitř: „o celou větev production.acme.local se stará jiný server“. Práce se tím rozdělí.
  3. PTR jde naopak: adresa → jméno. Udržuje se zvlášť od A záznamu a nastavuje ho ten, komu adresa patří – zpravidla poskytovatel.
  4. K čemu je: logy (jméno je čitelnější než číslo) a antispam – stroj bez rozumného PTR pošta odmítne.

▶ Otevřít v simulátoru

Lekce 5: Když DNS lže

Podvržený resolver: dostaneš adresu útočníka

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKklient odpověď nijak neověřuje

Poslední lekce vezme všechno, co víš, a otočí to naruby. Celý kurz stál na jednom nevysloveném předpokladu: že resolver mluví pravdu. Co když ne? Klient si odpověď nemá jak ověřit – prostě ji dostane a připojí se, kam mu bylo řečeno. Kdo tedy ovládá resolver, ten rozhoduje, kam tvoje spojení půjde, aniž by musel sáhnout na jediný router nebo kabel. Tomu se říká podvržený (rogue) DNS. Útočník ti buď resolvera podstrčí (třeba přes falešný DHCP nebo Wi-Fi z Kurzu 12 – Wi-Fi: zabezpečení do hloubky), nebo ovládne ten tvůj. Pak na jméno web.acme.local odpoví svou vlastní adresou – a ty se v nejlepší víře připojíš k němu. Nejděsivější na tom je, jak je to tiché: síť ani firewall nevidí nic divného. Spojení je z jejich pohledu naprosto normální – správný protokol, správný port, povolené pravidlo. Jen míří jinam, než sis myslel. Odborně se tenhle útok jmenuje DNS hijacking (únos DNS, podvržený resolver): rozhoduje o něm to, že útočník ovládá resolvera. Podvržení jednotlivé odpovědi po cestě je něco jiného – tomu se říká DNS spoofing a přijde na řadu hned v dalším modulu. Kurz 8 (Pokročilá bezpečnost) ukázal opačný problém, totiž tunel schovaný uvnitř DNS provozu; tady jde o DNS, které samo lže. Tady vidíš, proč to funguje: DNS odpověď je klasicky nešifrovaná a nepodepsaná, takže se nedá odlišit pravda od výmyslu. Co tě zachrání? HTTPS certifikát. Server útočníka sice vypadá jako ten pravý, ale nemá platný certifikát na to jméno – a prohlížeč zaječí. Proto se u varování o certifikátu nikdy neproklikává dál. Vyzkoušej si to v úloze „Podvržený DNS (rogue)“: síť má nastaveného útočníkova resolvera, vyber v cíli testu jméno a podívej se, na koho to ukázalo.

Krok za krokem

  1. Celý kurz stál na předpokladu, že resolver mluví pravdu. Klient si odpověď nemá jak ověřit – prostě ji dostane a věří.
  2. Podvržený (rogue) DNS: útočník ti resolvera podstrčí nebo ovládne ten tvůj – a na jméno odpoví svou vlastní adresou.
  3. Připojíš se k útočníkovi – a síť ani firewall nic divného nevidí. Správný protokol, port, povolené pravidlo. Jen jiný cíl (odborně: DNS hijacking).
  4. Zachrání tě HTTPS certifikát: útočník platný na to jméno nemá a prohlížeč zaječí. Zkus úlohu „Podvržený DNS (rogue)“.

Otrávená cache a DNSSEC

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKpoctivý resolver posílá dotaz ven

Rogue resolver z minulého modulu vyžaduje, aby útočník resolvera ovládl. Existuje ale i útok na poctivý resolver: otrávení cache (cache poisoning). Vzpomeň si na lekci 1 – resolver si odpovědi ukládá. Když do něj útočník propašuje jedinou podvrženou odpověď, resolver si ji uloží a pak ji sám od sebe rozdává všem svým uživatelům, dokud nevyprší TTL. Jeden úspěšný podvrh tedy odkloní celou firmu. Jak se to dá vůbec zkusit? Když resolver pošle dotaz ven, útočník se snaží stihnout odpovědět dřív než pravá autorita – dotaz i odpověď jsou nešifrované a resolver bere tu první, co dorazí a vypadá správně. Je to závod, ale závody se dají vyhrát. První a dodnes plošně nasazená obrana proto útočníkovi ten závod hlavně ztížila: resolver posílá dotaz z náhodného zdrojového portu (a náhodně střídá velikost písmen ve jméně – trik zvaný 0x20), takže podvrh musí uhodnout mnohem víc čísel. Plné řešení ale nespočívá v tom „rychleji běhat“, ale v tom, že odpověď se dá ověřit. K tomu slouží DNSSEC: každá odpověď je digitálně podepsaná tím, kdo záznam vlastní, a resolver si podpis ověří dřív, než odpověď přijme a uloží. Podvrh bez platného podpisu prostě zahodí – závod je najednou k ničemu. Důvěra se přitom staví po stejném stromu jako jména z lekce 3: kořen podepíše TLD, TLD podepíše doménu, doména podepíše záznam. Dvě upřímné poznámky. DNSSEC řeší pravost odpovědi, ne soukromí – dotaz je pořád čitelný pro každého po cestě (to řeší až další modul). A nasazený zdaleka není všude, protože stojí práci navíc. Ale myšlenka je čistá: nevěř odpovědi, ověř podpis.

Krok za krokem

  1. Tentokrát je resolver poctivý a posílá dotaz ven k autoritě. Dotaz i odpověď jsou ale nešifrované.
  2. Útočník se snaží odpovědět dřív než pravá autorita. Resolver bere tu první, co dorazí a vypadá správně – je to závod.
  3. Otrávení cache: resolver si podvrh uloží a pak ho sám rozdává všem, než vyprší TTL. Jeden podvrh odkloní celou firmu.
  4. DNSSEC: odpověď je podepsaná vlastníkem a resolver podpis ověří. Podvrh bez podpisu zahodí – závod je k ničemu.

DoH a DoT: šifrovaný dotaz

PCDNSNETROOT/TLDAUTHWEBÚTOČNÍKnešifrovaný dotaz: vidí ho každý po cestě

Zbývá poslední díra: DNSSEC ověří, že odpověď nikdo nezměnil, ale dotaz je pořád čitelný pro každého po cestě. Kdokoli mezi tebou a resolverem – poskytovatel, správce Wi-Fi v kavárně, kdokoli s přístupem k lince – tedy vidí seznam všech jmen, na která se ptáš. Řešení je nasnadě: dotaz zašifrovat. Máme na to dvě podoby téhož nápadu. DoT (DNS over TLS) posílá DNS ve vlastním šifrovaném tunelu na vyhrazeném portu – je jasně poznat, že to je DNS, jen není vidět obsah. DoH (DNS over HTTPS) zabalí dotaz do obyčejného HTTPS, takže na síti vypadá jako běžný web provoz a od ostatních spojení se nedá odlišit. Teď to zajímavé, protože tohle je klasická situace, kdy jedna technologie někomu pomůže a jinému uškodí. Pomůže uživateli: v cizí síti nikdo nevidí seznam jmen, na která se ptáš, a nikdo ti nemůže odpovědi cestou přepisovat. (Že se pak připojuješ zrovna na tuhle doménu, stejně prozradí cílová IP a SNI – jméno serveru, které prohlížeč posílá při navazování HTTPS nezašifrovaně, jak ukázal Kurz 1. DoH skryje dotaz, ne celé tvoje stopy.) Vadí správci hned dvakrát. Za prvé přijde o přehled z lekce 2 – když prohlížeč mlčky použije svůj vlastní DoH resolver na internetu, firemní resolver o dotazech vůbec neví, takže přestanou fungovat interní jména i blokování škodlivých domén. A za druhé, protože DoH vypadá jako web, hůř se rozpozná i zneužití – vzpomeň si na DNS tunneling z Kurzu 8 (Pokročilá bezpečnost). Rozumná odpověď není zakázat šifrování, ale vzít si tu volbu zpátky: nasadit vlastní resolver s DoT/DoH a nasměrovat na něj klienty. Provoz je šifrovaný a ptáš se serveru, kterému vědomě věříš.

Krok za krokem

  1. Zbývá díra: dotaz je čitelný pro každého po cestě. Poskytovatel i správce Wi-Fi vidí seznam jmen, na která se ptáš.
  2. Řešení: dotaz zašifrovat. DoT ho pošle vlastním tunelem (je poznat, že je to DNS), DoH ho zabalí do běžného HTTPS.
  3. Rub: když prohlížeč mlčky použije svůj DoH resolver venku, firemní resolver o dotazech neví – přestanou fungovat interní jména i blokování.
  4. Rozumná odpověď: vlastní resolver s DoT/DoH a nasměrovat na něj klienty. Šifrovaně a k serveru, kterému vědomě věříš.

▶ Otevřít v simulátoru