Bezpečnost DNS: DNSSEC a ochrana proti spoofingu

Účel a kontext: proč řešit bezpečnost DNS

Domain Name System (DNS) je kritická infrastruktura, která mapuje doménová jména na IP adresy a další zdroje. Jeho původní design nepočítal s integritou ani ověřováním původu odpovědí, což umožňuje útoky typu spoofing a cache poisoning. DNSSEC přidává kryptografické podepisování dat a řetězec důvěry, čímž umožňuje ověřit autenticitu odpovědí. Správně navržená ochrana kombinuje DNSSEC s dalšími protiopatřeními (randomizace, cookies, omezení fragmentace, RRL, DoT/DoH pro ochranu soukromí) a disciplinou provozu.

Hrozby: spoofing, cache poisoning a další útoky na DNS

  • DNS spoofing: podvržení odpovědí tak, aby resolver akceptoval falešná data (např. podvržené A/AAAA záznamy).
  • Cache poisoning: injekce škodlivých záznamů do cache rekurzivního resolveru, vedoucí k dlouhodobému přesměrování dotazů.
  • Off-path útoky: zneužití předvídatelného ID transakce, portu a fragmentace k injekci odpovědi bez viditelnosti provozu.
  • On-path útoky (MITM): modifikace odpovědí během přenosu, například v nedůvěryhodných sítích.
  • Amplifikace a DoS: zneužití otevřených rekurzorů a velkých odpovědí (DNSSEC, ANY) k zahlcení obětí.
  • NXNS a relaying: zneužití přesměrování na mnoho delegovaných jmenných serverů pro vyčerpání zdrojů resolveru.
  • DNS rebinding: obcházení stejnopůvodnostních politik prohlížeče pomocí dynamicky měněných odpovědí.

Základy DNS a důvěryhodnost dat

DNS je hierarchický, distribuovaný systém. Autoritativní servery drží zóny, rekurzivní resolvery odpovědi rekurzivně vyhledávají a ukládají do cache. Bez kryptografické validace spoléhá resolver na „důvěru v síť“, což je v dnešním prostředí nedostatečné. DNSSEC rozšiřuje DNS o digitální podpisy jednotlivých RRsetů a řetězec důvěry (root → TLD → doména).

DNSSEC: princip, záznamy a řetězec důvěry

  • Podpisy RRSIG: každý RRset (např. A záznamy) má kryptografický podpis RRSIG vytvořený soukromým klíčem zóny.
  • DNSKEY: veřejné klíče zóny publikované v DNS; obvykle rozdělené na KSK (Key Signing Key) a ZSK (Zone Signing Key).
  • DS záznam: hash KSK publikovaný v nadřazené zóně (např. u registru TLD), který vytváří vazbu parent → child a buduje řetězec důvěry.
  • NSEC/NSEC3: kryptografické důkazy neexistence jména nebo typu. NSEC3 s opt-out a salt omezuje enumeraci zóny.
  • CDS/CDNSKEY: záznamy pro automatizaci publikace a rotace DS u registru (delegovaná správa důvěry).

Volba algoritmů a velikostí klíčů

  • RSA (alg. 8/RSASHA256): běžný, ale s většími podpisy; doporučená délka 2048 bitů (ZSK) a 2048–3072 bitů (KSK).
  • ECDSA P-256 (alg. 13) a Ed25519 (alg. 15): moderní algoritmy s kratšími podpisy, rychlejší validací a menší fragmentací odpovědí.
  • Preferujte ECDSA/Ed25519 pro minimalizaci velikosti paketů a nároků na přenosovou kapacitu.

Provozní model: KSK/ZSK, podepisování a rotace klíčů

  • Oddělení rolí: ZSK podepisuje RRsety, KSK podepisuje DNSKEY RRset; DS drží rodičovská zóna.
  • Rotace klíčů: provádějte pravidelně (např. 6–12 měsíců pro ZSK, 1–2 roky pro KSK) s bezpečným přechodem (prepublish → sign → DS update → odstranění starých klíčů).
  • Bezpečnost klíčů: ukládejte privátní klíče v HSM nebo s odděleným přístupem a auditní stopou.
  • Automatizace: využijte CDS/CDNSKEY a protokoly u registrátorů pro bezvýpadkovou rotaci DS záznamů.

Validující resolvery: jak ověřovat DNSSEC

  • Anchor: kořenový klíč (trust anchor) pravidelně aktualizujte; validátor (BIND, Unbound, Knot Resolver) musí udržovat aktuální root KSK.
  • Stavy validace: Secure, Insecure, Bogus, Indeterminate. Odmítejte Bogus odpovědi.
  • Aggressive use of NSEC: validátor může syntetizovat negativní odpovědi z NSEC/NSEC3 a snižovat zátěž autoritativních serverů.

Posílení ochrany proti spoofingu (mimo DNSSEC)

  • Randomizace ID a portu: vysoká entropie (16bitové ID + 16bitový port) snižuje úspěšnost off-path injekcí.
  • 0x20 case randomization: zachování nebo střídání velikosti písmen v dotazu pro dodatečnou entropii (tam, kde je to bezpečné).
  • DNS Cookies: transakční cookies (RFC 7873/9018) pro mitigaci spoofingu a rozlišení legitimních klientů.
  • QNAME minimalizace: dotazování po hierarchii s minimem odhalených informací, což zlepšuje soukromí a snižuje útočnou plochu.
  • NXDOMAIN cut a serve-stale: lepší zacházení s negativní cache a dostupností při výpadcích.

EDNS(0), velikost odpovědí a fragmentace

DNSSEC zvětšuje velikost odpovědí kvůli přídavným RRSIG a DNSKEY záznamům, což zvyšuje riziko IP fragmentace (a tím zranitelnosti vůči injekcím). Doporučení:

  • Omezte EDNS buffer (např. na 1232 bajtů) a preferujte TCP fallback při velkých odpovědích.
  • Preferujte algoritmy s kratšími podpisy (ECDSA/Ed25519).
  • Zapněte minimal responses a vyhýbejte se používání typu ANY.

Autoritativní zóny: správná konfigurace a publikace DNSSEC

  • Signování zóny: používejte kontinuální podepisování (inline signing) a pečlivě sledujte expiraci RRSIG (správná TTL a jitter).
  • DS publikace: po nasazení nebo rotaci KSK zajistěte včasné nahrání DS záznamů u registru.
  • NSEC vs. NSEC3: pro veřejné zóny se obvykle používá NSEC3 se salt; u menších nebo necitlivých zón je jednodušší a efektivnější NSEC.
  • Anycast: distribuujte autoritativní servery pro odolnost vůči DoS útokům a zkrácení latence.
  • TSIG pro zabezpečení AXFR/IXFR a dynamických aktualizací; aplikujte ACL a split-horizon pokud je to nutné.

Rekurzivní resolvery: bezpečné nasazení

  • Neotevírejte rekurzi veřejně; omezte ji na interní IP rozsahy.
  • Zapněte DNSSEC validaci, QNAME minimalizaci, DNS Cookies, RRL (Response Rate Limiting) a nastavte vhodné limity současných dotazů.
  • Nastavte rozumné TTL limity a negativní cache dle RFC 2308; vyvarujte se příliš dlouhých TTL u kritických záznamů, což usnadní rotaci klíčů.
  • Monitorujte Bogus rate, velké odpovědi, časování, chybovost serverů a latenci vůči TLD a kořenovým serverům.

Soukromí vs. integrita: DoT/DoH a jejich vztah k DNSSEC

  • DNS over TLS (DoT) a DNS over HTTPS (DoH) šifrují transport mezi klientem a resolverem, čímž chrání soukromí a integritu přenosu, ale neověřují pravost autoritativních dat.
  • DNSSEC ověřuje autenticitu a integritu dat na aplikační vrstvě. Optimální je kombinace: DoT/DoH + DNSSEC validace.

Moderní typy záznamů a DNSSEC

  • CAA: omezení vydávání TLS certifikátů – podepsání CAA zvyšuje odolnost proti podvržení.
  • DANE/TLSA: vazba TLS certifikátů na DNSSEC; vyžaduje široké nasazení validace u klientů.
  • SVCB/HTTPS: moderní směrování klientů na služby a parametry; s DNSSEC eliminujete riziko podvržení alternativních koncových bodů.

Bezpečnostní a provozní best practices

  • Nasazujte DNSSEC se separací KSK/ZSK, preferujte ECDSA/Ed25519, držte malý EDNS buffer a TCP fallback.
  • Zapněte QNAME minimalizaci, DNS Cookies, 0x20 randomizaci a RRL.
  • Omezte dostupnost rekurze, udržujte aktuální software, sledujte CVE a aplikujte bezpečnostní záplaty.
  • Proveďte Anycast a geografickou diversifikaci autoritativních serverů; oddělte role (auth vs. recursor).
  • Pravidelně testujte validaci (např. domény s chybně publikovaným DS) a provádějte rotaci klíčů.

Procesní a compliance aspekty

  • Správa klíčů: dokumentované postupy, více osob při klíčových operacích (SoD), auditní logy, použití HSM, pravidelné testy obnovy po havárii (DR).
  • Incident response: scénáře pro chybně nasazený DS, expirované RRSIG, kompromitovaný klíč; plány na rollback.
  • Shoda: požadavky regulací (např. NIS2) na dostupnost a integritu; evidence změn a verze zón.

Časté chyby a jak se jim vyhnout

  • Publikace DS bez dostupného odpovídajícího DNSKEY → Bogus odpovědi a výpadky.
  • Příliš dlouhá expirace RRSIG a TTL znemožňující rychlou opravu či rotaci.
  • Velké odpovědi bez TCP fallback a s vysokým EDNS bufferem → fragmentace a injekce.
  • Otevřená rekurze dostupná z internetu → riziko amplifikace a cache poisoning.

Referenční návrh nasazení

  1. Autoritativní vrstva: anycast uzly, inline signing, NSEC3 se salt, TSIG pro AXFR/IXFR, monitoring expirace RRSIG a latence.
  2. Registr/registrátor: automatizace DS prostřednictvím CDS/CDNSKEY, pravidelné ověřování řetězce důvěry.
  3. Rekurze: validující resolver (Unbound/Knot Resolver/BIND) s QNAME minimalizací, cookies, RRL, EDNS 1232, TCP fallback, serve-stale.
  4. Klient: DoT/DoH k internímu validujícímu resolveru, případně lokální validace (stub s DNSSEC).
  5. Provoz: dashboard metrik (bogus rate, SERVFAIL, velké odpovědi, RTT), alerting, pravidelné testy selhání klíčů a obnovy.

Závěr

Bezpečnost DNS vyžaduje kombinaci kryptografické integrity (DNSSEC), transportních ochran (DoT/DoH), protispoofingových technik (randomizace, cookies), pečlivé práce s velikostí odpovědí a disciplinovaného provozu. DNSSEC je klíčový stavební kámen: ověřuje, že data skutečně pocházejí od autoritativního zdroje a nebyla po cestě změněna. Teprve v součinnosti s provozními a architektonickými opatřeními poskytuje DNS odolnou obranu proti spoofingu, cache poisoning útokům a celé řadě rizik, která by jinak mohla ohrozit dostupnost i důvěryhodnost vašich služeb.