DNS záznamy A, CNAME, MX, TXT a CAA: k čemu slouží a jak je nastavit

DNS záznamy jsou řádky v zóně vaší domény, které internetu říkají, kde je web (A, AAAA), které jméno je aliasem jiného (CNAME), kam chodí pošta (MX) a jaké texty dokládají vlastnictví nebo chrání e-maily (TXT, CAA). Platí jen záznamy na jmenných serverech, na které ukazují záznamy NS domény. Upravujte je proto právě tam, v panelu svého DNS hostingu nebo registrátora, a výsledek ověřte příkazem dig dřív, než začnete na cokoli čekat.

Jak DNS převádí doménu na adresu

Když do adresního řádku napíšete example.com, stane se tohle:

1. Prohlížeč a operační systém se nejdřív podívají do vlastní mezipaměti.
2. Dotaz jde na rekurzivní resolver: DNS server vašeho poskytovatele připojení nebo veřejný, například 8.8.8.8 nebo 1.1.1.1.
3. Pokud resolver odpověď v mezipaměti nemá, zeptá se kořenových serverů, pak serverů domény nejvyšší úrovně (.com) a nakonec autoritativních serverů uvedených v záznamech NS domény.
4. Autoritativní server vrátí záznam A nebo AAAA s TTL, tedy počtem sekund, po který si resolver smí odpověď pamatovat.
5. Prohlížeč se připojí k této IP adrese a načte stránku.

Pokud je některý z těchto záznamů špatně, prohlížeč dostane chybnou adresu, nebo žádnou. Typickým příznakem je chyba DNS_PROBE_FINISHED_NXDOMAIN: z pohledu resolveru jméno neexistuje.

Hlavní typy záznamů a kdy je potřebujete

Tyto záznamy najdete téměř v každém DNS panelu. Ukázkové hodnoty používají adresy vyhrazené pro dokumentaci.

Záznamy často jde upravovat na dvou místech: u registrátora, kde jste doménu koupili, a u poskytovatele hostingu. Používá se jen zóna na jmenných serverech uvedených v záznamech NS; změny jinde nemají žádný účinek. Pokud DNS stěhujete, nejdřív zkopírujte všechny záznamy do nové zóny a teprve pak proveďte změnu DNS serverů domény. Registraci domény najdete na naší stránce s doménami.

Ověření záznamů příkazem dig: co jsme viděli 30. 10. 2026

dig (Linux, macOS, Windows přes WSL nebo nástroje BIND) ukazuje přesně to, co vrací resolver; ve Windows funguje i nslookup. Tyto příkazy pokrývají všechny typy z tabulky:

dig A example.com +short
dig AAAA example.com +short
dig MX example.com +short
dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig CAA google.com +short
dig SRV _submission._tcp.gmail.com +short
dig NS example.com +short
dig A example.com @8.8.8.8 +noall +answer
nslookup -type=mx example.com

Stejné dotazy jsme 30. 10. 2026 spustili přes Google Public DNS. Zkrácený výsledek:

Jsou tu vidět tři věci. example.com zveřejňuje nulový MX (0 .), tedy způsob podle RFC 7505, jak oznámit, že doména nepřijímá poštu, k tomu SPF s -all a přísnou politiku DMARC: běžné nastavení domény, která nikdy neposílá e-maily. Kromě SPF je tam druhý záznam TXT s ověřovacím tokenem; více TXT záznamů na jednom jménu je normální. Odpovědi MX a CAA mají „nekulaté“ TTL (195, 1976): přišly z mezipaměti resolveru a počítadlo klesá každou sekundu, dokud se záznam znovu nenačte.

TTL: jak dlouho změna doopravdy trvá

TTL je počet sekund, po který smí resolver držet záznam v mezipaměti. RFC 2181 ho definuje jako maximální, ne povinnou dobu a omezuje ho hodnotou 2147483647. Proto je rada „počkejte 24-48 hodin“ pravdivá jen napůl:

• Změněný záznam A, MX nebo TXT je všude vidět nejpozději po vypršení starého TTL: při 300 je to 5 minut, při 3600 hodina.
• Den před plánovaným stěhováním snižte TTL na 300 a potom ho zase zvyšte, například na 3600.
• Jméno, na které se někdo zeptal dřív, než jste ho vytvořili, se uloží do mezipaměti jako neexistující, podle RFC 2308 na menší z hodnot TTL záznamu SOA a pole MINIMUM v SOA. U example.com je to 1800 sekund.
• Změna jmenných serverů závisí na TTL delegace v zóně TLD: u .com a .net je to 172800 sekund, tedy až 48 hodin, u .org jen 3600 (měřeno v našem návodu na změnu DNS serverů). Odtud pochází známých 24-48 hodin.

Pošta: MX, SPF, DKIM a DMARC

Pokud e-maily nechodí, přestože je adresa správná, příčina je téměř vždy v těchto záznamech. Zkontrolujte:

• MX ukazuje na název hostitele, ne na IP adresu a ne na CNAME (RFC 2181, oddíl 10.3); tento název potřebuje vlastní záznam A nebo AAAA.
• Priorita: nejdřív se zkouší menší číslo (RFC 5321). Stejná čísla rozkládají zátěž.
• SPF: přesně jeden záznam TXT začínající v=spf1 na doménu. Se dvěma takovými záznamy kontrola selže s výsledkem permerror (RFC 7208).
• DKIM: veřejný klíč se zveřejňuje jako TXT na selector._domainkey.example.com; selektor vám sdělí poskytovatel pošty.
• DMARC: TXT na _dmarc.example.com. Aktuální specifikace je RFC 9989 z května 2026, které nahradilo RFC 7489.

Záznamy krok za krokem s příklady najdete v návodu nastavení SPF, DKIM a DMARC, názvy serverů a porty pro poštovní klienty v článku o nastavení IMAP a SMTP.

Subdomény a CNAME: co funguje a co ne

Na blog, e-shop nebo testovací kopii nepotřebujete novou doménu, stačí subdoména. Dostane buď vlastní záznam A, nebo CNAME na jiné jméno, například když e-shop běží na externí platformě.

Důležité: jméno se záznamem CNAME nesmí mít žádné jiné záznamy (RFC 1034, oddíl 3.6.2; RFC 2181, oddíl 10.1). Holá doména má vždy záznamy SOA a NS, proto CNAME na @ standardní DNS nepovoluje. Někteří poskytovatelé DNS k tomu nabízejí vlastní typy jako ALIAS/ANAME nebo „CNAME flattening“: cíl přeloží na serveru a vracejí běžné záznamy A. Typická zóna vypadá takto:

$TTL 3600
@                 IN  A      203.0.113.10
@                 IN  AAAA   2001:db8::10
www               IN  CNAME  example.com.
shop              IN  CNAME  shop.example.net.
@                 IN  MX     10 mail.example.com.
@                 IN  MX     20 mail2.example.com.
mail              IN  A      203.0.113.20
mail2             IN  A      198.51.100.20
@                 IN  TXT    "v=spf1 mx -all"
_dmarc            IN  TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
@                 IN  CAA    0 issue "letsencrypt.org"
_submission._tcp  IN  SRV    0 1 587 mail.example.com.

Holá doména má A a AAAA, www je CNAME na ni, pošta má dva servery MX včetně záložního a k tomu SPF, DMARC, CAA a záznam SRV pro odesílací port 587. Dokumentační adresy nahraďte hodnotami z panelu hostingu.

HTTPS: TXT a CAA pro certifikáty

Let’s Encrypt i další certifikační autority musí ověřit, že doménu ovládáte. U metody DNS-01 přidáte záznam TXT na _acme-challenge.example.com. Wildcard certifikáty (*.example.com) lze vydat jen takto. Podle Let’s Encrypt potřebují někteří poskytovatelé DNS čas, než se změna dostane na všechny jejich servery; bez API nastavte klienta tak, aby čekal až zhruba hodinu. Staré ověřovací záznamy TXT mažte, jinak bude odpověď příliš velká.

Pokud má doména záznamy CAA, smějí certifikáty vydávat jen v nich uvedené autority (RFC 8659). CAA jen s pki.goog zablokuje Let’s Encrypt. Na hostingu RichHost jsou certifikáty Let’s Encrypt zdarma; kolik stojí komerční certifikáty a kdy se vyplatí, popisujeme v článku o ceně SSL certifikátu.

Tři chyby DNS, které jsme zopakovali na testovacím serveru

Pravidla výše si snadno ověříte sami. Tři běžné chyby jsme zopakovali na testovacím stanovišti: kontejner Ubuntu 24.04, BIND 9.18.39, kontrola zón nástrojem named-checkzone a vyhodnocení SPF knihovnou pyspf 2.0.14 přes lokální DNS server (11.11.2026). Domény jsou testovací (.test) a IP adresy pocházejí z rozsahů vyhrazených pro dokumentaci.

1. CNAME na hlavní doméně. BIND takovou zónu odmítl načíst s chybou CNAME and other data (RFC 1034, oddíl 3.6.2; RFC 2181, oddíl 10.1). Pokud služba při nastavení CDN chce CNAME na hlavní doméně, dejte CNAME na www a pro hlavní doménu použijte záznam A nebo ALIAS.
2. MX mířící na CNAME nebo IP adresu. BIND zónu načetl, ale varoval: MX 'mail.mx.test' is a CNAME (illegal). IP adresa v MX vyvolala dvě varování, MX is an address a has no address records: odesílatelé by hledali neexistující jméno 192.0.2.10.mxip.test. Správně má MX mířit na název hostitele s vlastním záznamem A, jako při nastavení firemního e-mailu na vlastní doméně.
3. Dva záznamy SPF nebo více než 10 DNS dotazů v SPF. RFC 7208 povoluje jeden záznam v=spf1 na doménu a nejvýše 10 mechanismů, které vyvolávají DNS dotazy: include, a, mx, ptr, exists a modifikátor redirect (oddíl 4.6.4). pyspf vrátil permerror jak pro doménu se dvěma záznamy v=spf1, tak pro doménu s 11 mechanismy include.

$ named-checkzone apex.test apex.test.zone
dns_master_load: apex.test.zone:4: apex.test: CNAME and other data
zone apex.test/IN: not loaded due to errors.
$ named-checkzone mx.test mx.test.zone
zone mx.test/IN: mx.test/MX 'mail.mx.test' is a CNAME (illegal)
$ python3 spfcheck2.py
two.spf.test ip=198.51.100.1 -> ('permerror', 'SPF Permanent Error: Two or more type TXT spf records found.')
eleven.spf.test ip=198.51.100.11 -> ('permerror', 'SPF Permanent Error: Too many DNS lookups')
eleven.spf.test ip=198.51.100.1 -> ('pass', 'sender SPF authorized')

Poslední řádek ukazuje, proč je limit dotazů zrádný: pro odesílatele z prvního include vrátil stejný záznam pass, protože vyhodnocení končí u první shody, takže chyba se projeví jen u části zpráv. Dva záznamy obvykle vzniknou, když nová rozesílací služba požádá o „přidání SPF“ a vytvoří se samostatný záznam TXT. Místo toho připište include do stávajícího záznamu a dotazy počítejte i s vnořenými: každý include může přinést další.

Diagnostika za 10 minut: příznak, kontrola, řešení

Nahraďte example.com svou doménou a ns1.dns-host.example jedním ze svých jmenných serverů. Webové nástroje jako whatsmydns.net ukazují odpověď z mnoha oblastí, mxtoolbox.com kontroluje MX, SPF a DMARC.

Návyky, které šetří čas

• Před každou změnou zónu exportujte nebo zkopírujte všechny záznamy: obnova pak zabere minuty místo hodin.
• Den před stěhováním snižte TTL na 300 a potom ho zase zvyšte.
• Nejméně dva jmenné servery, ideálně v různých sítích: RFC 1034 vyžaduje, aby každá zóna byla dostupná alespoň na dvou serverech.
• Hlídejte důležité záznamy (NS, A, MX) monitorovací službou, která upozorní, když se odpověď změní.

Časté otázky

Jak dlouho trvá změna v DNS?

U běžného záznamu do vypršení starého TTL, často 5 až 60 minut. U změny jmenných serverů až 48 hodin kvůli TTL delegace v zóně TLD.

Můžu dát CNAME na holou doménu?

Ve standardním DNS ne, protože holá doména má záznamy SOA a NS. Použijte A/AAAA, nebo pokud to poskytovatel umí, ALIAS/ANAME či CNAME flattening.

Potřebuji záznam AAAA?

Jen pokud je server skutečně dostupný přes IPv6. Chybný AAAA je horší než žádný: uživatelé s IPv6 se pak na web nedostanou.

Proč moje změny nefungují?

Nejčastěji jste upravili zónu u registrátora, zatímco NS ukazují na hosting, nebo obráceně. Příkazem dig NS ověřte, které servery jsou odpovědné.