Jak funguje DNS: záznamy, propagace, diagnostika a bezpečnost

Proč web nefunguje, když je „vše správně nastaveno"

Klient přestěhoval web na nový server. IP se změnila, A záznam aktualizován, server funguje. Ale polovina uživatelů vidí starý web a druhá polovina vidí chybu. Podpora poskytovatele říká „počkejte 48 hodin". Klient je nervózní, protože každou hodinu ztrácí objednávky.

Důvod je DNS. Přesněji, nepochopení toho, jak funguje. Kdyby klient snížil TTL den před stěhováním — problém by trval 5 minut místo dvou dnů.

DNS (Domain Name System) je to, co transformuje hostiserver.com na IP adresu serveru. Systém, který funguje miliardykrát denně a je neviditelný — dokud se něco nerozbije. V tomto průvodci probereme, jak DNS funguje pod kapotou, jak se vyhnout nástrahám při migraci a které záznamy je potřeba nastavit, aby vaše e-maily nekončily ve spamu.

Jak DNS dotaz putuje od prohlížeče k serveru

Když zadáte adresu webu, dochází k řetězci dotazů. Celý proces trvá 20–100 ms, ale během této doby se zapojí až 4 typy serverů.

Takto to vypadá:

Prohlížeč → Cache OS → Recursive Resolver → Root Server → TLD Server (.com) → Authoritative Server → IP adresa!
                         (8.8.8.8)         ("kdo je .com?")   ("kdo je example.com?")   ("93.184.216.34")

Krok za krokem

1. Lokální cache — prohlížeč zkontroluje, zda už zná IP této domény. Pokud jste web navštívili dříve a TTL ještě nevypršel — dotaz dál nejde. To je nejrychlejší varianta: 0 ms.

2. Recursive resolver — pokud není v cache, dotaz jde na rekurzivní DNS server. To může být server vašeho poskytovatele nebo veřejné DNS (Google 8.8.8.8, Cloudflare 1.1.1.1). Tento server přebírá veškerou další práci.

3. Root servery — resolver se ptá jednoho z 13 kořenových serverů: „Kde hledat domény .com?" Root server nezná IP konkrétního webu, ale ví, kdo je zodpovědný za zónu .com.

4. TLD servery — server zóny .com říká: „Za example.com jsou zodpovědné tyto name servery." A dává jejich adresu.

5. Autoritativní server — finální bod. Obsahuje skutečné DNS záznamy domény a vrací IP adresu — například 93.184.216.34.

6. Cachování — výsledek se ukládá na každé úrovni (resolver, OS, prohlížeč) po dobu TTL. Další dotaz na stejnou doménu se zpracuje za 1–5 ms.

4 typy DNS serverů

DNS záznamy: co, proč a jak nastavit

DNS záznamy jsou instrukce, které serverům říkají, jak zpracovávat požadavky na vaši doménu. Každý typ záznamu je zodpovědný za svou funkci.

Hlavní typy záznamů

Kdy které záznamy potřebujete

Ne všechny záznamy jsou potřeba hned. Zde jsou typické scénáře:

• Pouze web: A + AAAA (volitelně) + CNAME pro www
• Web + e-mail (Google Workspace / Microsoft 365): A + CNAME + MX + TXT (SPF) + TXT (DKIM) + TXT (DMARC)
• Web přes CDN: CNAME na CDN poskytovatele místo A záznamu
• Omezení SSL certifikátů: CAA záznam (např. povolit pouze Let's Encrypt)

SPF, DKIM, DMARC — ochrana e-mailu

Tři TXT záznamy, které jsou kriticky důležité, pokud odesíláte e-mail z vaší domény:

• SPF — určuje, které servery mají právo odesílat poštu jménem vaší domény. Bez SPF e-maily často končí ve spamu.
• DKIM — přidává digitální podpis ke každému e-mailu. Příjemce může ověřit, že e-mail nebyl podvržen.
• DMARC — politika, co dělat s e-maily, které neprošly SPF/DKIM ověřením (odmítnout, karanténa, propustit).

Jak zkontrolovat a diagnostikovat DNS

Když něco nefunguje — doména se neresolvuje, e-mail nedochází nebo web ukazuje starou verzi — první věc ke kontrole je DNS.

dig — hlavní nástroj

# A záznam domény
dig hostiserver.com A
# MX záznamy (mailové servery)
dig hostiserver.com MX
# TXT záznamy (SPF, DKIM, verifikace)
dig hostiserver.com TXT
# Dotaz přes konkrétní DNS server
dig @8.8.8.8 hostiserver.com A
# Zkrácený výstup
dig +short hostiserver.com A

nslookup — alternativa pro Windows

# Základní dotaz
nslookup hostiserver.com
# Přes konkrétní server
nslookup hostiserver.com 8.8.8.8
# MX záznamy
nslookup -type=MX hostiserver.com

Vymazání DNS cache

Pokud jste změnili DNS záznamy, ale vidíte starou verzi — problém je v cachování:

# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

DNS Propagation: proč se změny neaplikují ihned

Změnili jste A záznam, ale web stále ukazuje starou IP. Klienti v jedné zemi vidí nový web, zatímco v jiné — starý. To je DNS propagation — proces šíření změn po všech DNS serverech světa.

Proč to trvá

Každý DNS server cachuje odpovědi po dobu TTL (Time to Live). Pokud TTL vašeho A záznamu byl 86400 sekund (24 hodin) — některé servery budou vracet starou IP až 24 hodin po změně.

Jak urychlit propagaci

• Snižte TTL předem. 24–48 hodin před plánovanými změnami snižte TTL na 300 sekund (5 minut). Po změně — zvyšte zpět.
• Vymažte lokální cache. ipconfig /flushdns na vašem počítači.
• Použijte rychlé DNS. Veřejné DNS (Google 8.8.8.8, Cloudflare 1.1.1.1) se aktualizují rychleji než DNS poskytovatele.

DNS a bezpečnost: DNSSEC, DNS over HTTPS

Standardní DNS funguje jako prostý text — dotazy a odpovědi nejsou šifrovány ani podepsány. To vytváří zranitelnosti.

DNS Spoofing (otrávení cache)

Útočník nahradí odpověď DNS serveru a přesměruje uživatele na falešný web. Zvenčí vše vypadá normálně — adresa v prohlížeči je správná, ale IP ukazuje na server útočníka.

DNSSEC

DNS Security Extensions přidává digitální podpis k DNS odpovědím. Recursive resolver může ověřit, že odpověď nebyla po cestě změněna. DNSSEC nešifruje dotazy, ale garantuje jejich autentičnost.

DNS over HTTPS (DoH) a DNS over TLS (DoT)

Šifrují DNS dotazy, aby poskytovatel nebo někdo v síti nemohl vidět, které weby navštěvujete. Podporováno ve všech moderních prohlížečích a operačních systémech:

• DoH — DNS přes HTTPS (port 443). Používají Chrome, Firefox, Edge.
• DoT — DNS přes TLS (port 853). Používá Android, Linux.

5 chyb s DNS, které vidíme pravidelně

1. Zapomněli aktualizovat NS záznamy po migraci. Přestěhovali web na nový hosting, změnili A záznam, ale NS záznamy stále ukazují na starého poskytovatele. Výsledek: část dotazů jde na starý server.

2. Chybějící SPF/DKIM. E-mail z domény končí ve spamu nebo je blokován. Zvláště kritické pro eCommerce s transakčními e-maily.

3. Vysoké TTL před migrací. TTL 86400 (24 hodin) znamená, že po změně IP někteří uživatelé budou vidět starý web ještě den. Snižte TTL na 300 předem.

4. CNAME na kořenové doméně. example.com nemůže mít CNAME (pouze A/AAAA). CNAME funguje pouze pro subdomény (www, blog, shop). Někteří DNS poskytovatelé to obcházejí přes ALIAS/ANAME záznamy.

5. Nekontrolují DNS po změnách. Změnili záznamy a čekají, až to „začne fungovat". Použijte dig nebo online checkery pro potvrzení, že změny byly aplikovány správně.

Často kladené otázky