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), tedy řádek v zóně reprezentující konkrétní typ údaje (A, AAAA, MX, CNAME a další). 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“ o dané části prostoru jmen.
- Rekurzivní (resolver): klientský server, který dotazy zprostředkuje, kešuje a skládá odpověď z více autoritativních zdrojů.
- TTL (Time To Live): doba platnosti záznamu v keších; ovlivňuje rychlost propagace změn v DNS.
- 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
| Typ | Účel | Klíčová pole | Příklad hodnoty |
|---|---|---|---|
| A | IPv4 adresa hostitele | IPv4 | 93.184.216.34 |
| AAAA | IPv6 adresa hostitele | IPv6 | 2606:2800:220:1:248:1893:25c8:1946 |
| MX | Poštovní směrování | Preference, hostname serveru | 10 mail1.example.com. |
| CNAME | Alias (kanonické jméno) | Cílové jméno | www → app.example.net. |
| NS | Delegace poddomény / autorita zóny | Hostname nameserveru | ns1.example.com. |
| SOA | Hlavní záznam zóny | MNAME, RNAME, serial, refresh/retry/expire/minimum | ns1.example.com. hostmaster.example.com. 2025102501 … |
| TXT | Libovolný text (SPF, DKIM, DMARC, ověřování) | Řetězce | v=spf1 include:_spf.provider -all |
| SRV | Obecná lokalizace služby | Priorita, váha, port, cílový hostitel | _sip._tcp → 10 60 5060 sip1.example.com. |
| PTR | Reverzní záznam (IP → jméno) | Hostname | 4.3.2.1.in-addr.arpa. → host.example.com. |
| CAA | Povolené CA pro vydávání certifikátů | Flag, tag, value | 0 issue „letsencrypt.org“ |
| DS | DS záznam pro DNSSEC v nadřazené zóně | Key tag, algoritmus, digest typ, digest | 2371 13 2 ABCDEF… |
| DNSKEY | Veřejné klíče DNSSEC v zóně | Flags, protocol, algorithm, key | 257 3 13 BASE64… |
| RRSIG | Podpisy RRsetů (DNSSEC) | Typ, algoritmus, expirace, key tag, podpis | RRSIG A 13 … |
| NSEC/NSEC3 | Doklad o neexistenci (DNSSEC) | Next name, typy | example.com. NSEC … |
| HTTPS / SVCB | Moderní publikace endpointů (ALPN, ESNI/ECH) | Priorita, cílový server, parametry (alpn, ipv4hint…) | _https → 1 . alpn=“h2,h3″ |
| NAPTR | Transformační pravidla (VoIP, ENUM) | Order, preference, flags, service, regexp | E2U+sip !^.*$!sip:info@example.com! |
A a AAAA: přímé mapování jmen na IP adresu
A a AAAA záznamy určují, na kterou IPv4 nebo 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 paralelně 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 záznam (nikoli CNAME) a reverzní PTR pro správnou reputaci. Doporučuje se minimálně dvojice nezávislých MX serverů a správně nastavené SPF, DKIM a DMARC v TXT záznamech.
CNAME: aliasy a omezení
CNAME přemapovává jméno na jiné jméno. Nelze jej kombinovat s jinými typy záznamů pro stejné jméno (výjimkou jsou některé poskytovatelé, kteří nabízejí „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 při 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 záznam (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 číslo (inkrementovat při změnách) a časové hodnoty 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ů e-mailů (
v=spf1…). Umístěn v TXT záznamech. - 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 adresu zpět na doménové jméno. Jsou 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 záznam.
- RRSIG: kryptografické podpisy RRsetů.
- NSEC/NSEC3: doklady o neexistenci; NSEC3 s „opt-out“ chrání proti zone walking.
- CDS/CDNSKEY: automatizace publikace DS v nadřazené 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 nezbytné, jinak hrozí nedostupnost domény pro validující resolvery.
TTL, kešování a „propagace“
TTL určuje, jak dlouho budou odpovědi uloženy v keších. Snížení TTL před plánovanou změnou 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é TTL ztěžuje provádění změn.
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í klientům A/AAAA záznamy. Pokročilé služby umožňují 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 (doporučení RFC 5358).
- Oddělené role: provoz autoritativních serverů (AXFR/IXFR mezi primárním a sekundárními), změny záznamů skrze auditované workflow.
- Monitorování: dohled nad expirací 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 (např. ukazuje na CNAME), chybějící A/AAAA záznamy, nesoulad SPF/DKIM/DMARC.
- „Propagation issues“: keše drží staré hodnoty kvůli vysokému TTL; řešení: plánovat snížení TTL, počkat na expirační časy.
- NXDOMAIN vs. NODATA: neexistující jméno (NXDOMAIN) vs. existující jméno bez daného typu (NODATA); různé chování klientů a keší.
- DNSSEC „bogus“: expirované podpisy, chybné DS záznamy v nadřazené zóně, nesynchronizované hodiny.
- Reverzní PTR: chybí u veřejných IP; nutná koordinace s poskytovatelem konektivity.
Praktické nástroje: dig +dnssec, delv, kdig, testery DNSSEC/CAA, logy resolverů 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: sledování dotazových časů, úspěšnosti odpovědí, dostupnosti sekundárních serverů, velikosti UDP odpovědí (EDNS0, fallback na TCP).
DNS a moderní transporty: EDNS(0), DoT, DoH
EDNS(0) rozšiřuje limit velikosti DNS 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ů; provo
