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
| 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 certifikáty | Flag, tag, value | 0 issue „letsencrypt.org“ |
| DS | DS záznam pro DNSSEC v nadřazené zóně | Key tag, alg, 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, alg, 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) | Priority, target, 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
A a AAAA záznamy určují, na kterou IPv4/IPv6 adresu se má klient připojit. Běžnou praxí je publikovat více záznamů (anycast, více backendů) a spolehnout se na happy eyeballs a round-robin. U IPv6 je vhodné používat AAAA rovnocenně 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 (nikoli CNAME) a reverzní PTR pro dobrou reputaci. Doporučuje se alespoň dvojice nezávislých MX serverů a správně nastavené SPF, DKIM a DMARC záznamy 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 představují 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 záznamech. - DKIM: veřejný klíč pro ověřování emailových podpisů (
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 na jméno. Jsou důležité pro antispamové filtry 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) záznamy konzistentní.
CAA: kontrola vydávání certifikátů
CAA záznamy omezují, které Certification Authorities mohou vydávat certifikáty pro vaši doménu (issue, issuewild, iodef). Doporučuje se nastavit alespoň jednu explicitní CA a zavést 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 procházení zóny.
- CDS/CDNSKEY: automatizace publikace DS záznamů v nadřazené zóně u některých registrů.
Správné rotace klíčů (ZSK častěji, KSK méně často) a sledování expirací jsou nutné, jinak hrozí nedostupnost domény pro validující resolvery.
TTL, kešování a „propagace“
TTL určuje dobu, po kterou jsou odpovědi uchovávány v cache. Snížení TTL před plánovanou změnou minimalizuje dobu nekonzistence. Negativní odpovědi (NXDOMAIN/NODATA) se také kešují – 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 provedení změn.
ALIAS/ANAME, váhované a geo DNS
Někteří poskytovatelé nabízejí ALIAS/ANAME typy pro apex domény: chovají se jako CNAME na úrovni serveru a vracejí A/AAAA klientům. 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 omezení úniku informací.
- Rate limiting a ochrana proti odraženým DDoS útokům (doporučení RFC 5358).
- Oddělené role: provoz autorit (AXFR/IXFR mezi primárním a sekundárními servery), změny záznamů přes 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á konfigurace MX (např. MX 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 a vyčkat na propagační dobu.
- NXDOMAIN vs. NODATA: neexistující jméno (NXDOMAIN) vs. existující jméno bez požadovaného typu (NODATA); rozdílné chování klientů a keší.
- DNSSEC „bogus“: expirované podpisy, chybné DS záznamy v nadřazené zóně, nesynchronizované systémové hodiny.
- Reverzní PTR: chybějící u veřejné IP adresy; 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
- Verzování: vést zónové soubory v Git repozitáři; kontinuální integrace validuje syntaxi a politiky (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: doby odezvy, úspěšnost odpovědí, dostupnost sekundárních serverů, velikost 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ů; provozní dopady zahrnují nutnost správně řídit latence, TLS certifikáty a politiky směrování
