DNS záznamy

Role DNS a význam záznamů

Domain Name System (DNS) je distribuovaný hierarchický systém, který překládá čitelná doménová jména na technické identifikátory (IP adresy, porty, služby, klíče). Základní jednotkou informace v DNS je resource record (RR), tj. řádek v zóně reprezentující konkrétní typ údaje (A, AAAA, MX, CNAME aj.). Správná volba a konfigurace záznamů je zásadní pro dostupnost, bezpečnost a výkon webů, e-mailu, VoIP či moderních aplikačních protokolů.

Základní pojmy: zóna, záznam, autoritativní a rekurzivní servery

• Zóna: úsek jmenného prostoru spravovaný konkrétním správcem; obvykle jedna doména a její poddomény (např. example.com).
• Autoritativní server: server, který zónu uchovává a odpovídá za „pravdu“.
• Rekurzivní (resolver): klientský server, který dotazy zprostředkuje, kešuje a skládá odpověď z více autorit.
• TTL (Time To Live): doba platnosti záznamu v keších; ovlivňuje rychlost propagace změn.
• RRset: sada záznamů stejného jména a typu; podepisuje se u DNSSEC jako celek.

Nejpoužívanější typy záznamů a jejich účel

A a AAAA: přímé mapování jmen na IP

A a AAAA záznamy určují, na kterou IPv4/IPv6 adresu se má klient připojit. Běžnou praxí je publikace více záznamů (anycast, více backendů) a spolehnutí se na happy eyeballs a round-robin. U IPv6 je vhodné používat AAAA paritně s A a sledovat konektivitu z různých sítí.

MX: směrování pošty

MX záznamy definují poštovní servery pro doménu. Nižší hodnota preference znamená vyšší prioritu. Každý MX cíl musí mít A/AAAA (ne CNAME) a reverzní PTR pro reputaci. Doporučuje se minimálně dvojice nezávislých MX hostů a správně nastavené SPF, DKIM a DMARC v TXT.

CNAME: aliasy a omezení

CNAME přemapovává jméno na jiné jméno. Nelze jej kombinovat s jinými typy pro stejné jméno (výjimky jsou některé poskytovatelské „ALIAS/ANAME“ pseudo-typy, které server interně překládá na A/AAAA). Používejte jej pro aliasy (např. www → aplikace v CDN) a dávejte pozor na řetězení a TTL, které ovlivňuje latenci resolvování.

NS a delegace, glue záznamy

NS záznamy určují autoritativní nameservery pro zónu nebo poddelegovanou subdoménu. Pokud je nameserver ve stejné doméně (in-bailiwick), je potřeba glue (A/AAAA) v nadřazené zóně, aby nevznikla cirkularita při hledání.

SOA: metadata zóny a negativní kešování

SOA obsahuje referenční nameserver, kontakt správce, serial (inkrementovat při změnách) a časy pro sekundární servery (refresh, retry, expire). Pole „minimum“ historicky ovlivňovalo negativní kešování (TTL pro NXDOMAIN/NODATA); v moderních implementacích se používá explicitní TTL u příslušných záznamů.

TXT, SPF, DKIM, DMARC a ověřování domény

• SPF: seznam oprávněných odesílatelů pošty (v=spf1 …). Umístěn v TXT.
• DKIM: veřejný klíč pro ověřování podpisů e-mailů (selector._domainkey).
• DMARC: politika vyhodnocení (_dmarc), reportování a zarovnání identit.
• Ověřování služeb: poskytovatelé (GitHub, Google, MS 365) vyžadují specifické TXT tokeny.

SRV a moderní HTTPS/SVCB záznamy

SRV záznamy publikují port a hostitele pro daný protokol a transport (např. _ldap._tcp). Novější SVCB/HTTPS umožňují publikovat parametry jako ALPN, ECH, IP hinty či mandatory keys, čímž snižují počet RTT při navazování spojení a usnadňují nasazení HTTP/3.

PTR a reverzní DNS

PTR záznamy v doménách in-addr.arpa (IPv4) a ip6.arpa (IPv6) mapují IP na jméno. Důležité pro antispam a audit. Reverzní zóny často spravuje poskytovatel konektivity; pro správnou reputaci poštovního serveru musí být PTR a forward (A/AAAA) konzistentní.

CAA: kontrola vydávání certifikátů

CAA záznamy omezují, které Certification Authorities smějí vydávat certifikáty pro vaši doménu (issue, issuewild, iodef). Doporučuje se nastavit alespoň jednu explicitní CA a monitoring (IODEF na reporty).

DNSSEC: integrita a autenticita

• DNSKEY: publikuje KSK/ZSK klíče; KSK se obvykle referencuje v nadřazené zóně skrze DS.
• RRSIG: kryptografické podpisy RRsetů.
• NSEC/NSEC3: doklady o neexistenci; NSEC3 s „opt-out“ chrání proti zone walking.
• CDS/CDNSKEY: automatizace publikace DS v parent zóně u některých registrů.

Správné klíčové rotace (ZSK častěji, KSK méně často) a hlídání expirací jsou nutné, jinak hrozí nedostupnost domény pro validující resolvery.

TTL, kešování a „propagace“

TTL rozhoduje, jak dlouho budou odpovědi v keších. Snížení TTL před plánovaným přepnutím minimalizuje dobu nekonzistence. Negativní odpovědi (NXDOMAIN/NODATA) se kešují také – hodnotou z SOA MINIMUM nebo explicitním TTL. Příliš nízké TTL zvyšuje zátěž a latenci, příliš vysoké komplikuje změny.

ALIAS/ANAME, váhované a geo DNS

Někteří poskytovatelé nabízejí ALIAS/ANAME pro apex domény: chovají se jako CNAME na úrovni serveru a vrací A/AAAA klientům. Pokročilé služby umožní váhované (weighted) a geografické směrování (GeoDNS) s měřením dostupnosti, což je vhodné pro active-active multiregionální architektury.

Bezpečnostní aspekty a nejlepší praxe

• DNSSEC na autoritativní zóně a validace u resolverů.
• Minimalizace dat (QName minimization, minimal responses) pro menší únik informací.
• Rate limiting a ochrana proti odraženým DDoS (RFC 5358 doporučení).
• Oddělené role: provoz autorit (AXFR/IXFR mezi primárem a sekundáry), změny recordů přes auditované workflow.
• Monitorování: dohled na expiraci domény/NS/DS, chybné RRSIG, anomálie v odpovědích a latenci.

Diagnostika: typické problémy a jak je odhalit

• Nefunkční e-mail: chybné MX (ukazuje na CNAME), chybějící A/AAAA, nesoulad SPF/DKIM/DMARC.
• „Propagation issues“: keše drží staré hodnoty kvůli vysokému TTL; řešení: plánovat snížení TTL, vyčkat na expirační časy.
• NXDOMAIN vs. NODATA: neexistující jméno (NXDOMAIN) vs. existující jméno bez typu (NODATA); různé chování klientů a keší.
• DNSSEC „bogus“: expirované podpisy, chybné DS v parent zóně, rozhozené hodiny.
• Reverzní PTR: chybí u veřejné IP; nutná koordinace s poskytovatelem konektivity.

Praktické nástroje: dig +dnssec, delv, kdig, testery DNSSEC/CAA, logy resolveru a měření z více vantage pointů.

Provozní doporučení pro změny a verze

• Versioning: vést zónové soubory v Git repozitáři; CI validace syntaxe a politik (lint).
• Atomické změny: měnit záznamy a TTL s ohledem na pořadí (nejprve přidat nové IP, snížit TTL, po přepnutí odstranit staré).
• Serial v SOA: konzistentní schéma (YYYYMMDDnn) a automatická inkrementace.
• Monitoring SLA: dotazové časy, úspěšnost odpovědí, dostupnost sekundárů, velikost UDP odpovědí (EDNS0, fallback na TCP).

DNS a moderní transporty: EDNS(0), DoT, DoH

EDNS(0) rozšiřuje limit velikosti zpráv a umožňuje přenášet DNSSEC podpisy bez fragmentace. DoT (DNS over TLS) a DoH (DNS over HTTPS) zvyšují soukromí klientů šifrováním dotazů; provozní dopady zahrnují nutnost správně řídit latence, TLS certifikáty a politiky směrování resolverů.

Modelové vzory nasazení

• Web + e-mail SME: A/AAAA pro apex a www, MX s dvěma servery, SPF/DKIM/DMARC, CAA, dohled nad TLS certifikací, nízké TTL na www pro rychlé přepínání.
• Globální aplikace: GeoDNS na HTTPS/SVCB s IP hinty, více A/AAAA (anycast), DNSSEC s automatizovanou rotací, monitorování latence a chyb na úrovni regionů.
• VoIP/SIP: SRV a NAPTR pro směrování služeb, redundance cílů a odlišné váhy/priority.

Shrnutí a závěr

DNS je základní stavební kámen internetu a správná práce se záznamy přímo ovlivňuje dostupnost, bezpečnost i uživatelskou zkušenost. Znalost klíčových typů (A, AAAA, MX, CNAME, NS, SOA, TXT, SRV, CAA, DNSSEC) a souvisejících principů (TTL, kešování, delegace, bezpečnost) umožňuje navrhovat robustní a škálovatelnou infrastrukturu. Moderní typy HTTPS/SVCB a důsledné využití DNSSEC a CAA posouvají DNS směrem k bezpečnějšímu a rychlejšímu doručování služeb. Při změnách respektujte TTL, testujte z více lokalit a vše verzujte – DNS pak bude spolehlivý, předvídatelný a připravený na další rozvoj.