Hur konfigurerar du CAA-poster för din domän?

Vad är en CAA-post?

En CAA-post är en DNS-resurspost, definierad i RFC 8659, som låter en domänägare ange vilka certifikatutfärdare som får utfärda certifikat för namnet. Dess presentationsform är CAA, följt av ett flaggvärde, en tagg och ett värde. Flaggfältet är en oktett, och bit 0 är issuer critical-flaggan, skriven som 128 när den är satt; nästan alla poster använder 0. Taggen är ett ord som issue, och värdet är en sträng, ofta inom citattecken.

Innan den utfärdar slår en certifikatutfärdare upp CAA-posterna för namnet den har bett att certifiera. Hittar den inga på det namnet klättrar den till varje överordnad etikett i tur och ordning och stannar vid den första uppsättningen CAA-poster den hittar, enligt RFC 8659; den kontrollerar aldrig roten. Om ingen uppsättning finns någonstans begränsas inte utfärdandet. En post på toppen täcker alltså varje underdomän som saknar en egen.

En användbar definition att citera: en CAA-post är en offentlig allow-lista på DNS-nivå över de certifikatutfärdare som får utfärda för en domän.

Varför behöver kryptoprojekt CAA-poster?

Eftersom en DNS-kapare behöver ett giltigt certifikat för att få den falska frontenden att se äkta ut, gör CAA det steget svårare. Blockaid följde fem frontend-kompromisser mellan den 16 och den 23 februari 2026 och noterade ett fingeravtryck: SSL-certifikat utfärdade samma dag som DNS-ändringen. I Nerochain-fallet utfärdades jokercertifikat för projektets domän.

Enligt Wardmints läsning av Blockaid-rapporten den 12 november 2026 gav fem kompromisser på sju dagar minst en upprepad angriparvana som en CAA-post kan störa. Om dina poster tillåter bara din egen utfärdare måste en angripare som ändrar DNS även ändra CAA-posterna innan en annan utfärdare skriver under, och den extra ändringen är en signal du kan bevaka.

CAA är inget försvar på egen hand. En angripare som kontrollerar din DNS kan också redigera CAA-poster, och RFC 8659 anger att CAA inte påverkar certifikat som redan utfärdats. Behandla det som ett lager vid sidan av kontrollerna i hur du säkrar din domän mot DNS-kapning, och kombinera det med larm från certifikattransparensövervakning.

Vad är den exakta syntaxen för issue, issuewild och iodef?

Varje post har formen namn, klass, CAA, flaggor, tagg, värde, och värdet följer taggen exakt som RFC 8659 anger. Taggen issue anger domännamnet för den utfärdare som får utfärda. Taggen issuewild gäller bara jokernamn, och när den finns åsidosätter den issue för jokerförfrågningar. Taggen iodef anger en rapporteringsadress med mailto, http eller https.

För att förbjuda all utfärdande för ett namn publicerar du en issue-post med en tom utfärdare, skriven som ett semikolon inom citattecken. För en vanlig domän publicerar du en issue-post per auktoritet som du använder, och en issuewild-post om du vill styra jokercertifikat separat. Ta den exakta utfärdaridentifieraren från din utfärdares dokumentation, eftersom det är ett domännamn som utfärdaren väljer.

example.com.  3600  IN  CAA  0 issue "ca.example.net"
example.com.  3600  IN  CAA  0 issuewild ";"
example.com.  3600  IN  CAA  0 iodef "mailto:[email protected]"

parked.example.com.  3600  IN  CAA  0 issue ";"

Hur konfigurerar du CAA-poster på en försvarsdomän?

På en försvarsdomän som bara omdirigerar, tillåt den enda utfärdare som betjänar omdirigeringen, eller förbjud utfärdande om inget svarar över HTTPS. En domän som är parkerad utan webbtjänst behöver inget certifikat, så 0 issue ";" tar bort alternativet för alla andra. En försvarsdomän som vidarebefordrar besökare till din huvudsajt över HTTPS behöver ett certifikat för det, så den måste tillåta den utfärdare som tillhandahåller det.

Utgå från planen i hur du omdirigerar försvarsdomäner till din huvudsajt, och lägg sedan till motsvarande CAA-poster. På Wardmint gratis DNS-hosting med A-, AAAA-, CNAME-, ALIAS-, MX-, TXT-, NS-, SRV- och CAA-poster, hanterad DNSSEC och egna nameservers om du föredrar det (2 till 13), så posterna läggs till i samma kundyta som vidarebefordringen. Ett projekt som har kärnuppsättningen .com, .net, .org, .io, .xyz, .app för $128.94 per år tillämpar samma CAA-uppsättning på alla sex namn.

Vilka misstag bryter utfärdandet av certifikat?

Det vanligaste misstaget är att ange en auktoritet som du har glömt att du använder. Hostingplattformar, innehållsleveranstjänster och e-postleverantörer begär ibland egna certifikat för dina underdomäner. Om din CAA-uppsättning utelämnar dem misslyckas förnyelsen, ofta tyst, tills ett certifikat löper ut. Lista varje tjänst som betjänar ett namn under din domän innan du publicerar.

Ett andra misstag är en felstavad utfärdaridentifierare, som blockerar alla, inklusive den auktoritet du menade att tillåta. Testa med en riktig förnyelse. Ett tredje är att glömma att en CAA-post högre upp gäller för en underdomän som saknar en egen, så en restriktiv topp kan blockera en underdomäns förnyelse.

Att ändra posten återkallar aldrig ett certifikat som redan finns. Om ett oväntat certifikat har utfärdats, behandla det som en incident och följ stegen i hur du säkrar din domän mot DNS-kapning. e-svar inom 12 timmar, 7 dagar i veckan, inklusive hjälp med DNSSEC, CAA-poster och missbruksanmälningar, inklusive hjälp med CAA-poster.