Jak DNSSEC chrání SPF, DKIM a MX záznamy

Proč je DNS nejslabším článkem e-mailové autentizace

SPF, DKIM a DMARC tvoří základ ověřování e-mailů. Všechny tři protokoly ale závisí na jedné věci — DNS záznamech. Příjemce e-mailu se při každém doručení dotazuje DNS na SPF záznam odesílající domény, na veřejný DKIM klíč i na DMARC politiku. Pokud útočník dokáže DNS odpovědi podvrhnout, celá e-mailová autentizace ztrácí smysl.

DNSSEC tento problém řeší. Přidává kryptografické podpisy k DNS odpovědím, takže validující resolver dokáže ověřit, že data nebyla cestou pozměněna. Pro e-mail je DNSSEC důležitější než pro web — TLS certifikát, který chrání webový provoz, u e-mailu většinou chybí.

Jak DNS cache poisoning ohrožuje e-mail

DNS cache poisoning (otrava DNS cache) je útok, při kterém útočník podvrhne resolveru falešnou DNS odpověď. Resolver si ji uloží do cache a po dobu platnosti TTL ji vrací všem dotazujícím se klientům.

Pro webový provoz existuje pojistka — TLS certifikát. I když útočník přesměruje DNS na svůj server, prohlížeč ověří certifikát a spojení odmítne. U e-mailu ale tato pojistka často chybí:

• SMTP nemá povinné šifrování. Většina e-mailových serverů používá oportunistický STARTTLS — pokud druhá strana TLS nepodporuje, e-mail se pošle nešifrovaně.
• Certifikáty mailových serverů se běžně nevalidují. Na rozdíl od webových prohlížečů mnohé poštovní servery přijmou i neplatný nebo self-signed certifikát.
• DNS záznamy pro e-mail jsou kritičtější. Podvržení MX záznamu může přesměrovat celou příchozí poštu. Podvržení SPF záznamu může legitimizovat podvržené e-maily.

E-mail je proto na integritu DNS odpovědí citlivější než web. DNSSEC tuto integritu zajišťuje.

SPF záznam — autorizace odesílajících serverů

SPF záznam (RFC 7208) definuje, které servery smějí odesílat e-maily za danou doménu. Příjemce si tento TXT záznam vyžádá z DNS při každém příchozím e-mailu.

Útok bez DNSSEC

Útočník podvrhne SPF záznam domény firma.cz a nahradí ho vlastní verzí:

firma.cz.  IN TXT  "v=spf1 include:attacker.example -all"

Příjemce obdrží tento podvržený záznam a vyhodnotí e-maily z útočníkova serveru jako legitimní. Skutečné e-maily z autorizovaných serverů firmy naopak selžou — podvržený SPF je neobsahuje.

Ochrana pomocí DNSSEC

Když je doména firma.cz chráněna DNSSEC, každý TXT záznam nese kryptografický podpis (RRSIG). Validující resolver podvržený záznam rozpozná — podpis nesedí — a odpověď odmítne. Příjemce místo podvržených dat dostane buď pravý SPF záznam, nebo chybu SERVFAIL, která vede k dočasnému odložení doručení (temperror). V obou případech útočníkův e-mail neprojde.

RFC 7208 v sekci 11.3 popisuje riziko podvržení DNS dat jako hrozbu pro spolehlivost SPF — DNSSEC je přímou odpovědí na toto riziko.

DKIM záznam — veřejný klíč pro ověření podpisu

DKIM (RFC 6376) podepisuje e-maily digitálním podpisem. Veřejný klíč pro ověření podpisu je publikován v DNS jako TXT záznam na adrese selektor._domainkey.firma.cz.

Útok bez DNSSEC

Útočník podvrhne DKIM záznam a nahradí veřejný klíč vlastním:

s1._domainkey.firma.cz.  IN TXT  "v=DKIM1; k=rsa; p=UTOCNIKUV_KLIC"

Nyní může podepisovat e-maily vlastním soukromým klíčem a příjemce je vyhodnotí jako platné — veřejný klíč v DNS (podvržený) odpovídá. Útočník efektivně podepíše e-maily za doménu firma.cz.

Ochrana pomocí DNSSEC

DNSSEC chrání i záznamy na subdoménách včetně _domainkey. Validující resolver ověří podpis RRSIG a podvržený klíč odmítne. Útočník nemůže nahradit veřejný klíč, protože nedokáže vytvořit platný RRSIG podpis bez přístupu k privátnímu klíči DNSSEC zóny.

MX záznam — směrování příchozí pošty

MX záznam určuje, na které servery se doručují e-maily pro danou doménu. Podvržení MX záznamu je jeden z nejzávažnějších útoků — útočník přesměruje celou příchozí poštu.

Útok bez DNSSEC

Útočník podvrhne MX záznam pro firma.cz:

firma.cz.  IN MX  10 mail.attacker.example.

Veškerá příchozí pošta se doručí na útočníkův server. Útočník čte e-maily v reálném čase, může je upravovat a přeposílat dál — oběť ani odesílatel nemusí nic poznat.

Ochrana pomocí DNSSEC

MX záznamy jsou chráněny RRSIG podpisem stejně jako ostatní záznamy v zóně. Validující resolver podvržený MX záznam odmítne. E-maily se doručí na správný server nebo se nedoručí vůbec — což je lepší než tichý odposlech.

DMARC záznam — politika a reporting

DMARC (RFC 7489) definuje, co má příjemce udělat s e-maily, které neprojdou SPF a DKIM kontrolou. Záznam se publikuje jako TXT na _dmarc.firma.cz.

Útok bez DNSSEC

Útočník podvrhne DMARC záznam a změní politiku:

_dmarc.firma.cz.  IN TXT  "v=DMARC1; p=none; rua=mailto:rua@attacker.example"

Dvě věci se stanou najednou:

1. Politika p=none říká příjemcům, aby podvržené e-maily propouštěli — skutečná politika reject je pryč.
2. Agregované DMARC reporty se posílají útočníkovi, který z nich získá informace o e-mailové infrastruktuře oběti.

Ochrana pomocí DNSSEC

DNSSEC chrání i záznamy na subdoméně _dmarc. Podvržený záznam s neplatným podpisem resolver odmítne. Politika reject zůstane v platnosti a reporty se posílají na správné adresy.

Proč je DNSSEC pro e-mail důležitější než pro web

Pro webový provoz funguje TLS certifikát jako druhá vrstva ochrany. Pro e-mail je DNS často jedinou vrstvou — a DNSSEC je jediný způsob, jak ji zabezpečit.

DANE — DNSSEC jako základ pro ověření certifikátu

DANE (DNS-Based Authentication of Named Entities, RFC 6698) posouvá zabezpečení e-mailu ještě dál. Umožňuje publikovat otisk TLS certifikátu mailového serveru přímo v DNS jako TLSA záznam.

Odesílající server pak ověří certifikát příjemce přes DNS — bez závislosti na certifikačních autoritách. DANE ale vyžaduje funkční DNSSEC — bez kryptograficky ověřených DNS odpovědí by útočník mohl podvrhnout i TLSA záznam a celý mechanismus by byl k ničemu.

DANE pro SMTP je definován v RFC 7672 a aktivně ho nasazují velcí poštovní provideři — například Postfix od verze 2.11 DANE plně podporuje. Více o DANE najdete v článku Co je DANE a jak zabezpečuje přenos e-mailů.

dig _25._tcp.mail.firma.cz TLSA +short

Pokud příkaz vrátí TLSA záznam, mailový server domény používá DANE.

Jak ověřit ochranu vaší domény

Online kontrola

Zkontrolujte svou doménu naším analyzérem — výsledek zobrazí stav DNSSEC, SPF, DKIM i DMARC najednou. Pokud DNSSEC chybí, uvidíte konkrétní doporučení.

Kontrola v terminálu

Ověřte, zda DNS záznamy vaší domény nesou platné DNSSEC podpisy:

dig firma.cz TXT +dnssec +short | grep spf
dig s1._domainkey.firma.cz TXT +dnssec +short
dig firma.cz MX +dnssec +short
dig _dmarc.firma.cz TXT +dnssec +short

Pokud ve výstupu dig (bez +short) vidíte příznak ad (Authentic Data) v záhlaví, váš resolver DNSSEC validoval a odpověď je autentická. Podrobný postup ověření najdete v článku o ověření DNSSEC domény.

Stav nasazení a praktická doporučení

Podle dostupných dat (2025) má DNSSEC aktivní jen asi 4 % domén pod .com. České domény .cz jsou na tom výrazně lépe díky podpoře CZ.NIC. Přesto řada domén — včetně těch, které mají správně nastavený SPF, DKIM a DMARC — DNSSEC nevyužívá.

Praktická doporučení:

1. Aktivujte DNSSEC u svého DNS poskytovatele. Většina moderních hostingů (Cloudflare, CZ.NIC, AWS Route 53) DNSSEC podporuje a aktivace je záležitost několika kliknutí.
2. Ověřte DS záznam u registrátora. Bez DS záznamu v nadřazené zóně DNSSEC nefunguje, i když máte zónu podepsanou. Podrobnosti najdete v článku Co je DNSSEC a jak funguje.
3. Monitorujte stav průběžně. DNSSEC se může rozbít při přenosu domény, změně DNS serverů nebo expiraci podpisů — a nefunkční DNSSEC je horší než žádný.
4. Zvažte DANE pro mailový server. Pokud provozujete vlastní mailový server a máte DNSSEC, DANE přidá další vrstvu ochrany bez závislosti na certifikačních autoritách.

Zkontrolujte zabezpečení vaší domény — analyzér ověří DNSSEC, SPF, DKIM i DMARC a upozorní na problémy dřív, než je pocítí vaši příjemci.