DNSSEC, CAA-poster och namnservrar, förklarat

Det mesta säkerhetsarbetet kring en domän bygger på DNS: SPF, DKIM och DMARC är DNS-poster, certifikat utfärdas till den som kontrollerar ett DNS-namn, och besökare hittar er webbplats genom ett DNS-svar. De här tre inställningarna skyddar själva zonen.

Tre inställningar, tre risker.

Det här gör DNSSEC.

DNSSEC lägger till signaturer på era DNS-poster. En validerande resolver kontrollerar dem längs en kedja som börjar i roten: den överordnade zonen, till exempel .se eller .com, publicerar en DS-post med ett hashvärde av er zons nyckel, och den nyckeln signerar era poster. RFC 4033 beskriver det som skydd för DNS-datas ursprung och integritet.

När kontrollen misslyckas skickar en validerande resolver inte vidare svaret. Den svarar i stället med ett serverfel (SERVFAIL), som RFC 4035 kräver. Det är skyddet, men också risken: ett misstag i DNSSEC gör domänen onåbar för alla vars resolver validerar, till exempel användare av Google Public DNS.

DNSSEC har gränser som är bra att känna till:

• Det krypterar ingenting. RFC 4033 säger rakt ut att DNSSEC inte är byggt för konfidentialitet. DNS över HTTPS eller DNS över TLS krypterar frågorna mellan en enhet och dess resolver.
• Det stoppar inte överbelastningsattacker mot era namnservrar.
• Det hjälper inte om någon tar över ert konto hos DNS-leverantören eller registraren. Då kan de ändra och signera vad de vill. Skydda de kontona med tvåstegsinloggning och fråga registraren om Registry Lock.

Sverige har ett försprång: 2005 blev .se den första toppdomänen som signerade sin zon.

Aktivera DNSSEC i tre steg.

1. Signera zonen hos er DNS-leverantör. De flesta DNS-tjänster gör det med en inställning och byter sedan signeringsnycklarna automatiskt. Väljer ni algoritm själva, ta en av dem som i dag rekommenderas för signering: 13 (ECDSA P-256 med SHA-256), 8 (RSA med SHA-256) eller 15 (Ed25519). De gamla SHA-1-algoritmerna 5 och 7 rekommenderas inte.
2. Publicera DS-posten hos registraren. DNS-leverantören visar värdena ni ska ange: nyckel-id (key tag), algoritm, hashtyp och hashvärde. För .se och .nu kan Internetstiftelsen också läsa DS-uppgifterna från en CDS-post som er DNS-leverantör publicerar i zonen. Internetstiftelsen söker igenom alla domäner varje dag, och att aktivera DNSSEC för en osignerad domän på det sättet tar tre dagar.
3. Kontrollera kedjan. Zonemaster, från Internetstiftelsen och franska Afnic, och DNSViz visar båda om kedjan från den överordnade zonen till era poster går att validera. Från en terminal kan ni fråga en validerande resolver:

dig +dnssec example.se A @8.8.8.8

Flaggan ad i svaret betyder att resolvern har validerat det.

Där DNSSEC går fel.

• Byte av DNS-leverantör. Det är det riskabla ögonblicket. Ta bort DS-posten hos registraren, vänta tills dess TTL har gått ut i den överordnade zonen och flytta först därefter namnservrarna. Signera zonen hos den nya leverantören och publicera dess DS-post sist. Cloudflare varnar för att validerande resolvrar svarar SERVFAIL om namnservrarna byts innan den gamla DS-posten har gått ut. Vissa leverantörer kan flytta en signerad zon utan att stänga av DNSSEC, men det kräver att båda leverantörerna samarbetar.
• Signaturer som går ut. Varje signatur har ett slutdatum. En DNS-tjänst signerar om automatiskt; en signeringsserver som ni driver själva måste fortsätta köras, annars går signaturerna ut och domänen slutar fungera.
• En ny nyckel utan ny DS-post. När nyckeln som DS-posten pekar på byts ut måste DS-posten i den överordnade zonen också ändras. Automatisering med CDS, där registret stöder det, sköter det utan att någon behöver logga in hos registraren.
• DNSSEC tas bort i fel ordning. Ta bort DS-posten först, vänta ut dess TTL och sluta signera sist. Aldrig tvärtom.

CAA: bestäm vem som får utfärda certifikat.

Vilken allmänt betrodd certifikatutfärdare som helst kan utfärda ett certifikat för er domän till den som klarar dess domänvalidering. En CAA-post anger vilka som får göra det. Sedan den 8 september 2017 måste utfärdarna kontrollera CAA innan de utfärdar, enligt CA/Browser Forums beslut Ballot 187.

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issue "digicert.com"
example.com.  3600  IN  CAA  0 issuewild ";"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

• issue anger en utfärdare som får utfärda, en post per utfärdare. Varje utfärdare publicerar vilket namn som ska stå där: letsencrypt.org för Let's Encrypt, digicert.com för DigiCert och pki.goog för Google Trust Services.
• issuewild gäller bara jokerteckencertifikat och går före issue för dem. ";" förbjuder dem helt.
• iodef anger en adress dit en utfärdare kan rapportera en beställning som bryter mot er policy.
• Underdomäner ärver. En utfärdare letar efter CAA på det exakta namnet först och sedan på varje nivå uppåt, så en post på example.com gäller även www.example.com och alla andra underdomäner som saknar en egen.

CAA verkar vid källan. Webbläsare kontrollerar det inte (RFC 8659 förbjuder att CAA används för att validera certifikat), och det påverkar inte certifikat som redan har utfärdats.

Inför det utan att förnyelser slutar fungera.

När en CAA-post väl finns nekas alla utfärdare som den inte nämner, även den som förnyar ett certifikat ni har glömt bort. Lista därför först vad ni använder:

1. Sök i loggarna för Certificate Transparency efter er domän, till exempel på crt.sh, för att se vilka utfärdare som har utfärdat era nuvarande certifikat. Checklistan för TLS-certifikat visar hur.
2. Ta med underdomäner som pekar på andra tjänster, till exempel en kundtjänstplattform, ett marknadsföringsverktyg eller ett CDN. De får ofta certifikat från en egen utfärdare, som då måste stå i er post.
3. Publicera en issue-post för varje utfärdare, issuewild om ni använder jokerteckencertifikat, och en iodef-adress.

Namnservrar: minst två, i olika nät.

RFC 1034, en av de ursprungliga DNS-standarderna, kräver att varje zon finns på minst två servrar. RFC 2182 lägger till att de ska placeras på platser som är spridda både geografiskt och i nätet, och rekommenderar tre för de flesta organisationers zoner.

Med en enda namnserver räcker ett fel. Resolvrar sparar svar en stund, men när de har gått ut slutar webbplatsen, e-posten och allt annat under domänen att fungera. De flesta DNS-tjänster ger er två till fyra namnservrar i olika nät. Kontrollera två saker:

• Varje namnserver som är angiven hos registraren svarar, med samma poster.
• NS-posterna hos registraren stämmer med dem i er zon. Zonemaster testar båda.

Två namnservrar hos samma leverantör skyddar mot att en server slutar fungera, men inte mot att hela leverantören ligger nere. En andra leverantör täcker det, men då måste båda hållas i synk, och med DNSSEC måste båda signera.

Det här kontrollerar TrustSek.

Modulen för e-postsäkerhet läser domänens CAA- och NS-poster och frågar en validerande resolver över DNS-over-HTTPS, först Cloudflares och sedan Googles, efter zonens DNSSEC-nycklar. Kontrollerna gäller alla domäner, oavsett om de tar emot e-post.

Kontrollerna har begränsningar. En zon räknas som signerad när den publicerar DNSSEC-nycklar: en zon med nycklar men utan DS-post hos registraren, eller med signaturer som inte går att validera, ger inget fynd, så kontrollera kedjan med Zonemaster när ni har aktiverat DNSSEC. Ger ingen av resolvrarna ett tydligt svar visas inget DNSSEC-fynd i stället för en gissning. CAA läses på den kontrollerade domänen. Kontrollen av namnservrar räknar NS-posterna; den testar inte om de finns i olika nät. Ni kan se DNSSEC-status för valfri domän med den kostnadsfria MTA-STS- och DNSSEC-kontrollen.

Frågor

Krypterar DNSSEC DNS-trafiken?

Nej. Det visar att ett svar är äkta, men alla på vägen kan fortfarande läsa det. Att kryptera frågorna är uppgiften för DNS över HTTPS eller DNS över TLS, mellan en enhet och dess resolver.

Kan DNSSEC göra vår domän onåbar?

Ja, om det är felkonfigurerat, eftersom validerande resolvrar vägrar svar de inte kan verifiera. Med en DNS-leverantör som signerar och byter nycklar automatiskt är de riskabla ögonblicken byte av leverantör och borttagning av DNSSEC. Båda är säkra om DS-posten tas bort först och dess TTL får gå ut.

Behöver vi CAA om alla våra certifikat kommer från en utfärdare?

Ja. Utan CAA får alla allmänt betrodda utfärdare utfärda certifikat för er domän, inte bara den ni använder. En issue-post med er utfärdare ändrar det.

Spelar DNSSEC någon roll för e-post?

Det skyddar era MX-, SPF- och DKIM-poster mot förfalskade svar, för avsändare vars resolvrar validerar. Det krävs också för DANE för SMTP (RFC 7672), som publicerar e-postserverns certifikat i DNS. MTA-STS gör ett liknande jobb utan DNSSEC, och en domän kan använda båda.

Kontrollera er domäns DNS-säkerhet

Den kostnadsfria kontrollen visar om er zon är signerad med DNSSEC, har en CAA-post och tillräckligt många namnservrar, tillsammans med SPF, DMARC och resten av bedömningen utifrån.

Er domän

Kontrollera er domän

Gratis, inget konto behövs. Tar ungefär 30 sekunder.