DNSSEC för e-post: därför behöver era DNS-poster skyddas

Varför är e-postsäkerhet beroende av DNS?

En mottagande e-postserver hämtar nästan allt den behöver för att bedöma er e-post från DNS. Den läser er SPF-post för att se vilka servrar som får skicka åt er, er publika DKIM-nyckel för att kontrollera signaturer och er DMARC-post för att avgöra vad som ska hända när kontrollerna misslyckas. Avsändare slår upp era MX-poster för att veta vart e-post till er ska levereras, och posten _mta-sts för att hitta er TLS-policy.

Vanlig DNS kan inte bevisa att ett svar kommer oförändrat från er zon. En angripare som kan förfalska eller förgifta DNS-svar på vägen till mottagarens resolver kan ge den en annan SPF-post, en DKIM-nyckel som angriparen själv har, en DMARC-post med p=none eller en MX-post som pekar mot angriparens egen server. Ingen av kontrollerna märker det, eftersom var och en litar på det DNS svarar.

Vad skyddar DNSSEC, och vad skyddar det inte?

DNSSEC (RFC 4033, 4034 och 4035) lägger till digitala signaturer i DNS. Er zon signeras med nycklar vars publika del publiceras som DNSKEY-poster, och varje uppsättning poster får en RRSIG-signatur. En kontrollsumma av er nyckel publiceras som en DS-post i den överordnade zonen, till exempel .se eller .com, som i sin tur är signerad av rotzonen. En validerande resolver följer den förtroendekedjan och underkänner varje svar vars signatur inte stämmer. DNSSEC bevisar också när ett namn eller en post inte finns, så en angripare kan inte heller låtsas att en post saknas.

• Det skyddar DNS-svarens riktighet och ursprung: det resolvern får är det ni har publicerat.
• Det krypterar inte DNS. Frågor och svar syns fortfarande i nätet; DNS över TLS och DNS över HTTPS handlar om sekretess, inte om äkthet.
• Det skyddar inte mot någon som loggar in hos er DNS-leverantör eller registrar och ändrar posterna där. De ändrade posterna signeras som alla andra, så skydda de kontona med stark autentisering.
• Det hjälper bara när mottagarsidan validerar. Många stora e-postleverantörer och publika resolvrar gör det, men inte alla mottagare.

Hur slår jag på DNSSEC för min domän?

Att slå på DNSSEC består av två delar, och de sköts ofta av två olika företag. Er DNS-leverantör, företaget som har er zon, signerar den. Er registrar, företaget ni registrerade domänen genom, publicerar DS-posten i den överordnade zonen. Om samma företag gör båda kan det koppla ihop dem åt er.

1. Aktivera DNSSEC-signering i DNS-leverantörens kontrollpanel. De flesta leverantörer sköter nycklar och omsignering automatiskt. ECDSA P-256 med SHA-256, algoritm 13, är ett vanligt modernt val som håller svaren små.
2. Kopiera DS-posten som leverantören visar. Vissa registrarer vill ha DNSKEY-posten i stället och räknar fram DS-posten själva.
3. Lägg in DS-posten hos registraren. Den syns sedan i den överordnade zonen, oftast inom några minuter till några timmar beroende på registret.
4. Kontrollera att kedjan valideras med ett analysverktyg för DNSSEC innan ni bygger vidare på den.

example.com. 3600 IN DS 12345 13 2 (
    3B2A1F0E9D8C7B6A59483726150F4E3D2C1B0A99887766554433221100FFEEDD )

De fyra fälten är nyckelns tagg, algoritmen (13 är ECDSA P-256 med SHA-256), typen av kontrollsumma (2 är SHA-256) och kontrollsumman av er nyckel. Kopiera värdena exakt som leverantören anger dem; exemplet ovan är påhittat.

Den kostnadsfria e-postsäkerhetskontrollen letar efter en DS-post för er domän i den överordnade zonen. En domän utan DS-post rapporteras som att den behöver åtgärdas, eftersom varje annan inställning i rapporten då kan bytas ut utan att någon märker det.

Hur hänger DNSSEC ihop med DANE och TLSA-poster?

DANE för SMTP (RFC 6698 och RFC 7672) använder DNSSEC för att tala om för sändande servrar vilket certifikat eller vilken nyckel era MX-värdar kommer att visa. Ni publicerar en TLSA-post för port 25 på varje MX-värd:

_25._tcp.mail.example.com. TLSA 3 1 1 (
    0D1C2B3A49586776859403A2B1C0D9E8F7A6B5C4D3E2F1009988776655443322 )

3 1 1 betyder: matcha serverns eget certifikat (3), utifrån dess publika nyckel (1), med en SHA-256-kontrollsumma (1). Det är den form RFC 7672 rekommenderar för de flesta e-postservrar. Eftersom nyckeln låses fast ska ni publicera TLSA-posten för en ny nyckel innan servern börjar använda den.

DANE får all sin säkerhet från DNSSEC. Avsändare använder bara TLSA-poster som de kan validera, vilket kräver att zonen där MX-värden finns är signerad, och att era egna MX-poster också är signerade. TLSA-poster i en osignerad zon ignoreras, och e-postsäkerhetskontrollen rapporterar dem som ett fel eftersom de ger en falsk känsla av skydd.

DANE är valfritt. Om inga TLSA-poster finns rapporterar kontrollen att DANE inte används, och det är helt i sin ordning. Om er e-post ligger hos en leverantör finns MX-värdarna oftast i leverantörens zon, så om DANE är möjligt beror på leverantören.

Behöver jag DNSSEC för MTA-STS?

Nej. MTA-STS hämtar sin policy över HTTPS och bygger på webbens certifikatsystem, så det fungerar utan DNSSEC. Det är huvudskälet till att MTA-STS finns vid sidan av DANE: många domäner och e-postleverantörer kunde inte signera sina zoner.

De två kompletterar varandra. DNSSEC skyddar de poster som MTA-STS inte skyddar: SPF, DKIM, DMARC och TLS-RPT-posten. DANE och MTA-STS kan användas tillsammans, och en avsändare som stöder båda får inte låta MTA-STS åsidosätta en misslyckad DANE-kontroll.

Vad kan gå fel med DNSSEC?

En trasig DNSSEC-kedja är värre än ingen DNSSEC alls. När DS-posten i den överordnade zonen inte matchar en giltig nyckel i er zon, eller när signaturerna har gått ut, svarar validerande resolvrar med SERVFAIL i stället för ett svar. För alla som använder en sådan resolver försvinner er domän.

• E-post till er fördröjs och studsar till slut, eftersom sändande servrar inte kan slå upp era MX-poster.
• Mottagare kan inte läsa era SPF-, DKIM- eller DMARC-poster, så er utgående e-post kan underkännas eller skjutas upp.
• Er webbplats och andra tjänster under domänen blir onåbara för användare bakom validerande resolvrar.

De vanligaste orsakerna är ett nyckelbyte som inte följdes av en ny DS-post, en flytt till en DNS-leverantör som inte signerar zonen med samma nycklar, och att signeringen stängs av medan DS-posten fortfarande är publicerad.

Hur byter jag nycklar eller DNS-leverantör på ett säkert sätt?

1. Låt DNS-leverantören sköta de vanliga nyckelbytena. Nycklar som bara signerar zonen byts utan att ni behöver göra något. Byts nyckeln som DS-posten pekar på krävs däremot en ny DS-post hos registraren, om inte leverantören och registret stöder automatisk uppdatering med CDS-poster (RFC 7344 och 8078).
2. Innan ni byter DNS-leverantör, ta bort DS-posten hos registraren medan den gamla leverantören fortfarande levererar den signerade zonen.
3. Vänta tills den gamla DS-posten har gått ut ur resolvrarnas cache. Kontrollera dess TTL i den överordnade zonen; ett eller två dygn brukar räcka.
4. Flytta zonen till den nya leverantören och kontrollera att alla poster, även SPF, DKIM, DMARC, MX och _mta-sts, svarar rätt.
5. Aktivera signering hos den nya leverantören och publicera dess DS-post hos registraren.

Samma ordning gäller om ni någon gång vill stänga av DNSSEC: ta bort DS-posten först, vänta och sluta signera först därefter. Leverantörer som stöder DNSSEC med flera signerare (RFC 8901) kan flytta en zon utan en osignerad period, men det kräver noggrann samordning mellan båda leverantörerna.