8. DNS — jak funguje a jak ho diagnostikovat (dig, nslookup)

Úvod a kontext

Lidé si pamatují jména, počítače pracují s čísly. DNS (Domain Name
System) je systém, který převádí čitelné doménové názvy jako
example.com na IP adresy, se kterými pak pracuje síťová vrstva popsaná
v předchozí lekci. Pro DevOps inženýra je DNS jednou z nejčastějších
příčin "záhadných" výpadků — aplikace se najednou "nemůže připojit k
databázi" nebo "web nejde najít", a příčinou je špatně nastavený nebo
neaktualizovaný DNS záznam. Tato lekce vysvětlí, jak DNS funguje, a
naučí vás ho diagnostikovat.

Teorie

Hierarchie DNS

DNS je distribuovaná, hierarchická databáze. Doménové jméno se čte
zprava doleva podle úrovně v hierarchii:

www.example.com.
         │    │  └─ TLD (top-level doména) — .com
         │    └──── doména druhé úrovně — example
         └───────── subdoména/hostname — www

(Tečka na konci značí kořen hierarchie — v praxi se obvykle nepíše, ale
DNS s ní interně pracuje.)

Nejvyšší úroveň tvoří kořenové servery (root servers), pod nimi
servery pro jednotlivé TLD (.com, .cz, .org...), pod nimi
autoritativní servery konkrétní domény (např. serverů, které spravují
záznamy pro example.com). Když se ptáte na www.example.com, resolver
postupně projde: kořen → .com server → autoritativní server pro
example.com, který vrátí konečnou odpověď (nebo poskytne odkaz dál).

Typy DNS záznamů

• A — mapuje jméno na IPv4 adresu (example.com → 93.184.216.34).
• AAAA — mapuje jméno na IPv6 adresu.
• CNAME — alias, jméno ukazuje na jiné jméno (např.
  www.example.com → example.com). CNAME nesmí koexistovat s jinými
  záznamy na stejném jméně (kromě speciálních DNSSEC případů).
• MX — určuje poštovní servery odpovědné za doručování e-mailu pro
  danou doménu, včetně priority.
• TXT — libovolný textový záznam; často se používá pro ověření
  vlastnictví domény nebo SPF/DKIM záznamy proti spamu.
• NS — určuje, které servery jsou autoritativní pro danou doménu/
  subdoménu (delegace).
• PTR — opačný směr než A: mapuje IP adresu zpět na doménové jméno
  ("reverse DNS"), používá se např. při ověřování legitimity mail
  serverů.

Proces rozlišení (resolution) a caching

Když aplikace na vašem serveru potřebuje zjistit IP adresu pro doménu,
zeptá se resolveru (obvykle DNS serveru nakonfigurovaného v
/etc/resolv.conf, nebo firemního/ISP resolveru, případně veřejného
jako 8.8.8.8 či 1.1.1.1). Resolver buď odpověď zná z vlastní
cache (mezipaměti), nebo ji rekurzivně dohledá přes hierarchii
popsanou výše a výsledek si zapamatuje na dobu určenou hodnotou TTL
(Time To Live) daného záznamu.

TTL má zásadní provozní dopad: pokud máte záznam s TTL 3600 (hodina) a
změníte IP adresu serveru, DNS resolvery po celém internetu budou po
dobu až hodiny vracet starou adresu, protože ji mají v cache. Proto se
před plánovanou migrací nebo výpadkem doporučuje TTL dopředu snížit
(např. na 60–300 sekund), počkat, až vyprší staré TTL, provést změnu a
až poté TTL zase zvýšit zpět.

Autoritativní vs. rekurzivní servery

• Autoritativní server zná přímo záznamy dané domény — je to
  "zdroj pravdy" (typicky provozovaný registrátorem domény nebo
  DNS poskytovatelem jako Cloudflare, Route 53 apod.).
• Rekurzivní resolver sám žádné záznamy nevlastní, ale jménem
  klienta prochází hierarchii a výsledek cachuje. Veřejné rekurzivní
  resolvery: Google (8.8.8.8), Cloudflare (1.1.1.1).

Praktický příklad

Nástroj dig je standardní diagnostický nástroj pro DNS na Linuxu
(modernější náhrada staršího nslookup):

# Základní A záznam
$ dig example.com A +short
93.184.216.34

# Plný výstup s TTL a sekcí AUTHORITY
$ dig example.com A

;; ANSWER SECTION:
example.com.        86400   IN      A       93.184.216.34

;; Query time: 24 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)

Zjištění, kdo je autoritativní pro doménu (NS záznamy), a MX záznamů:

$ dig example.com NS +short
a.iana-servers.net.
b.iana-servers.net.

$ dig example.com MX +short
10 mail.example.com.

Diagnostika konkrétním DNS serverem (obejde lokální resolver a cache —
užitečné, když chcete ověřit, jestli už se změna propagovala na
autoritativní server):

$ dig @8.8.8.8 example.com A +short
93.184.216.34

$ dig @a.iana-servers.net example.com A +short
93.184.216.34

Starší, ale stále běžný nástroj nslookup:

$ nslookup example.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   example.com
Address: 93.184.216.34

Typický troubleshooting scénář — web po nasazení na nový server
"nejede", ačkoliv na serveru samotném funguje:

# 1. Zjistíme, na jakou IP doména aktuálně ukazuje
$ dig www.example.com +short
203.0.113.10          # stará IP, ne nová!

# 2. Ověříme TTL — pokud je vysoké, čekáme na propagaci
$ dig www.example.com A
;; ANSWER SECTION:
www.example.com.    3600  IN  A  203.0.113.10

# 3. Ověříme přímo na autoritativním serveru, jestli je záznam už opravený
$ dig @ns1.example-registrar.com www.example.com +short
198.51.100.20         # nová IP je tam správně — jde jen o propagaci cache

Shrnutí

DNS převádí doménová jména na IP adresy pomocí hierarchického systému
autoritativních a rekurzivních serverů. Klíčové typy záznamů jsou A/AAAA
(adresa), CNAME (alias), MX (pošta) a TXT (libovolná data). TTL řídí,
jak dlouho se odpověď drží v cache, což má přímý dopad na rychlost
propagace změn — proto se před migracemi TTL preventivně snižuje.
Nástroj dig (případně starší nslookup) je základním nástrojem pro
diagnostiku DNS problémů, včetně možnosti dotázat se přímo konkrétního
serveru a obejít tak lokální cache.

Kontrolní otázky

1. Jaký je rozdíl mezi A záznamem a CNAME záznamem?
2. Co znamená TTL u DNS záznamu a proč byste ho před plánovanou migrací
   serveru dočasně snižovali?
3. Jakým příkazem zjistíte MX záznamy domény example.com pomocí
   dig?
4. Vysvětlete rozdíl mezi autoritativním DNS serverem a rekurzivním
   resolverem.