# DHCP a DNS Dvě služby, které dělají úplně různé věci, ale spojuje je jedna vlastnost: fungují na pozadí, nikdo o nich nepřemýšlí, a když se rozbijí, vypadá to jako „nefunguje internet". # DHCP Když připojíš zařízení do sítě, nemá žádnou adresu. Nemůže tedy nic poslat, protože nemá zpáteční adresu, a nemůže se ani nikoho zeptat, protože neví, koho. DHCP tenhle problém řeší tím, že se nový klient zeptá úplně všech naráz. ## Čtyři kroky ```mermaid sequenceDiagram participant K as Klient participant S as DHCP server K->>S: DISCOVER (broadcast, kdokoliv?) S->>K: OFFER (nabízím 192.168.1.10) K->>S: REQUEST (beru ji) S->>K: ACK (je tvoje, na 24 hodin) ``` Zkratkou DORA. Klient křičí do sítě, server nabídne adresu, klient ji potvrdí a server ji zapíše. Druhý a třetí krok existují proto, že v síti může být víc DHCP serverů. Klient si vybere jednu nabídku a tou žádostí ostatním serverům oznámí, že jejich nabídku nepotřebují. ## Co všechno DHCP předává Zdaleka nejen adresu. V odpovědi je typicky: - IP adresa a maska - výchozí brána - adresy DNS serverů - doména pro hledání - doba zápůjčky - volitelně NTP server, adresa TFTP pro bootování a desítky dalších voleb Právě proto se špatně nastavený DHCP projevuje tak různorodě. Když chybí brána, funguje jen místní síť. Když chybí DNS, funguje ping na IP, ale ne na jména. ## Zápůjčka Adresa se nepřiděluje natrvalo, ale na dobu určitou. V polovině té doby si klient řekne o prodloužení. Když se server neozve, zkouší to znovu, a když ani pak, adresu po vypršení pustí. Doma nastav něco mezi 12 a 24 hodinami. Kratší doba znamená víc provozu, delší znamená, že se dlouho drží adresy zařízení, která už dávno odešla. ## Rezervace Když chceš, aby zařízení mělo pořád stejnou adresu, máš dvě možnosti. **Rezervace na DHCP serveru** je ta rozumná. Řekneš routeru „tahle MAC adresa vždycky dostane tuhle IP". Zařízení o ničem neví, dostává adresu normálně přes DHCP, jen pořád stejnou. Všechna nastavení zůstávají na jednom místě. **Statická adresa přímo na zařízení** je ta, co tě jednou kousne. Zařízení pak nemá ponětí o zbytku sítě, a když změníš rozsah nebo bránu, přestane fungovat a ty budeš půl hodiny hledat proč. Použij ji jen tam, kde nemáš na výběr. Pokud rezervuješ, drž si rezervace mimo dynamický rozsah. Například dynamicky `192.168.1.100` až `.200`, rezervace v `.10` až `.50`. Vyhneš se konfliktům a v seznamu klientů poznáš na první pohled, co je co. ## Dva DHCP servery v jedné síti Klasika, když někdo přinese domů router a zapojí ho do sítě jako switch, ale zapomene mu vypnout DHCP. Zařízení pak dostávají adresy náhodně od obou serverů, půlka sítě nefunguje a příčina je neviditelná. Když stavíš síť a připojuješ do ní jakoukoliv krabici s nápisem „router", první věc je vypnout na ní DHCP a WiFi. --- # DNS DNS překládá jména na adresy. To je popis, který znáte všichni, a nic nevysvětluje. Zajímavější je, jak se k té odpovědi vlastně dojde. ## Rekurzivní dotaz Když se tvůj počítač zeptá na `www.seznam.cz`, nezeptá se přímo. Zeptá se svého resolveru — obvykle routeru nebo serveru poskytovatele — a ten to vyřeší za něj: ```mermaid sequenceDiagram participant P as Tvůj počítač participant R as Resolver participant Root as Kořenový server participant CZ as Server pro .cz participant S as Server seznam.cz P->>R: kde je www.seznam.cz? R->>Root: kde je www.seznam.cz? Root->>R: nevím, ale .cz řeší tenhle server R->>CZ: kde je www.seznam.cz? CZ->>R: nevím, ale seznam.cz řeší tenhle server R->>S: kde je www.seznam.cz? S->>R: 77.75.79.222 R->>P: 77.75.79.222 ``` Systém je hierarchický a čte se zprava. Nejdřív se zjistí, kdo spravuje `.cz`, pak kdo spravuje `seznam.cz`, a teprve ten zná odpověď. Vypadá to zdlouhavě a taky to zdlouhavé je — proto se všechno kešuje. Druhý dotaz na tutéž doménu dostane odpověď okamžitě z paměti resolveru. ## Typy záznamů | Typ | K čemu | |---|---| | `A` | jméno na IPv4 adresu | | `AAAA` | jméno na IPv6 adresu | | `CNAME` | jméno na jiné jméno | | `MX` | kam doručovat poštu pro doménu | | `TXT` | libovolný text, používá se pro ověřování a SPF | | `PTR` | zpětný překlad z adresy na jméno | | `NS` | který server doménu spravuje | Když zapínáš [IPv6](Jak-funguje-IPv6), potřebuješ `AAAA`. Nepřidá se sám od sebe a to je jeden z nejčastějších důvodů, proč „IPv6 mám, ale nikdo se na mě nedostane". ## TTL a proč změny nejsou vidět hned Každý záznam má nastavenou dobu, po kterou si ho smí kdokoliv pamatovat. Když změníš IP adresu své domény, svět se to dozví až po vypršení téhle doby, ne okamžitě. Když plánuješ stěhování, sniž TTL na pár minut den předem. Po přesunu ho vrať zpátky nahoru. ## Kde všude se kešuje Tohle je zdroj věčného zmatku, protože keší je v řadě za sebou několik: 1. prohlížeč 2. operační systém 3. router 4. resolver poskytovatele Když ti změna „nefunguje", pravděpodobně koukáš na jednu z nich. Vyčištění: ``` ipconfig /flushdns # Windows sudo dscacheutil -flushcache # macOS sudo systemd-resolve --flush-caches # Linux ``` A v prohlížeči zkus anonymní okno, protože Chrome má vlastní keš nezávislou na systému. ## Vlastní DNS doma Stojí za zvážení. Když si pustíš vlastní resolver, dostaneš tři věci: lokální jména pro vlastní zařízení, blokování reklamy na úrovni sítě, a nezávislost na tom, co ti podstrkuje poskytovatel. Nejběžnější volby jsou Pi-hole nebo AdGuard Home. Obojí běží klidně na Raspberry Pi nebo v kontejneru na NASu. Když to uděláš, počítej se dvěma věcmi. Musíš mít záložní řešení, protože bez DNS ti v domácnosti přestane fungovat úplně všechno včetně televize. A moderní prohlížeče a operační systémy mají tendenci obcházet tvůj resolver přes DoH (DNS přes HTTPS), takže to je potřeba na klientech vypnout nebo to zablokovat na [firewallu](Firewall-a-zony). ## Diagnostika ``` dig seznam.cz # dotaz na výchozí resolver dig @8.8.8.8 seznam.cz # dotaz konkrétně na Google dig seznam.cz AAAA # jen IPv6 záznam dig +trace seznam.cz # celá cesta hierarchií ``` Když `dig @8.8.8.8` funguje a `dig` bez parametru ne, máš rozbitý vlastní resolver. To je nejrychlejší způsob, jak to rozlišit. Víc v [nástrojích](Nastroje).