Hoe stelt u CAA-records in voor uw domeinnaam?

Wat is een CAA-record?

Een CAA-record is een DNS-resourcerecord, gedefinieerd in RFC 8659, waarmee een domeineigenaar kan aangeven welke certificeringsinstanties certificaten voor de naam mogen uitgeven. De presentatievorm is CAA, gevolgd door een flagwaarde, een tag en een waarde. Het flagveld is één octet, en bit 0 is de issuer critical-vlag, geschreven als 128 wanneer die is gezet; vrijwel elk record gebruikt 0. De tag is een woord zoals issue, en de waarde is een string, vaak tussen aanhalingstekens.

Voordat een certificeringsinstantie uitgeeft, zoekt ze de CAA-records op van de naam die ze moet certificeren. Vindt ze er geen op die naam, dan klimt ze label voor label omhoog naar elke bovenliggende naam en stopt bij de eerste set CAA-records die ze vindt, volgens RFC 8659; de root controleert ze nooit. Bestaat er nergens een set, dan is uitgifte niet beperkt. Een record op de apex dekt dus elk subdomein dat geen eigen record heeft.

Een bruikbare definitie om te citeren: een CAA-record is een openbare toegestane lijst, op DNS-niveau, van de certificeringsinstanties die certificaten voor een domeinnaam mogen uitgeven.

Waarom hebben cryptoprojecten CAA-records nodig?

Omdat een DNS-hijacker een geldig certificaat nodig heeft om de nepfrontend echt te laten lijken, en CAA die stap moeilijker maakt. Blockaid volgde vijf frontend-compromittaties tussen 16 en 23 februari 2026 en merkte één vingerafdruk op: SSL-certificaten die op dezelfde dag als de DNS-wijziging werden uitgegeven. Bij het geval Nerochain werden wildcardcertificaten uitgegeven voor de domeinnaam van het project.

Volgens de lezing van Wardmint van het Blockaid-rapport op 12 november 2026 leverden vijf compromittaties in zeven dagen minstens één terugkerende gewoonte van de aanvaller op waar een CAA-record in kan grijpen. Als uw records alleen uw eigen instantie toestaan, moet een aanvaller die DNS wijzigt ook de CAA-records aanpassen voordat een andere instantie zal ondertekenen, en die extra wijziging is een signaal dat u kunt bewaken.

CAA is op zichzelf geen verdediging. Een aanvaller die uw DNS beheert, kan ook CAA-records bewerken, en RFC 8659 stelt dat CAA geen invloed heeft op certificaten die al zijn uitgegeven. Beschouw het als een laag naast de maatregelen in hoe u uw domeinnaam beveiligt tegen DNS-hijacking, en combineer het met meldingen van certificate transparency-monitoring.

Wat is de exacte syntaxis van issue, issuewild en iodef?

Elk record heeft de vorm naam, klasse, CAA, flags, tag, waarde, en de waarde volgt de tag precies zoals RFC 8659 voorschrijft. De tag issue noemt het uitgeversdomein dat mag uitgeven. De tag issuewild geldt alleen voor wildcardnamen en overschrijft, indien aanwezig, issue voor wildcardverzoeken. De tag iodef geeft een meld-URL met mailto, http of https.

Om alle uitgifte voor een naam te verbieden, publiceert u een issue-record met een lege uitgever, geschreven als een puntkomma tussen aanhalingstekens. Voor een gewone domeinnaam publiceert u één issue-record per instantie die u gebruikt, en één issuewild-record als u wildcards apart wilt beheren. Neem de exacte uitgeversidentificatie uit de documentatie van uw instantie, want het is een domeinnaam die de instantie zelf kiest.

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 ";"

Hoe stelt u CAA-records in op een defensieve domeinnaam?

Sta op een defensieve domeinnaam die alleen doorverwijst de ene instantie toe die de doorverwijzing bedient, of verbied uitgifte als er niets via HTTPS antwoordt. Een geparkeerde domeinnaam zonder webdienst heeft geen certificaat nodig, dus 0 issue ";" haalt de mogelijkheid voor iedereen anders weg. Een defensieve domeinnaam die bezoekers via HTTPS doorstuurt naar uw hoofdsite heeft daarvoor wel een certificaat nodig, dus moet hij de instantie toestaan die dat levert.

Begin bij het plan in hoe u defensieve domeinnamen doorverwijst naar uw hoofdsite en voeg daarna de bijpassende CAA-records toe. Bij Wardmint geldt: gratis DNS-hosting met A-, AAAA-, CNAME-, ALIAS-, MX-, TXT-, NS-, SRV- en CAA-records, beheerde DNSSEC en desgewenst uw eigen nameservers (2 tot 13), dus de records voegt u toe in hetzelfde klantgedeelte als de doorverwijzing. Een project dat de kernset van .com, .net, .org, .io, .xyz, .app bezit, $128.94 per jaar, past dezelfde CAA-set toe op alle zes de namen.

Welke fouten verstoren de certificaatuitgifte?

De gebruikelijke fout is een instantie noemen die u vergeten bent te gebruiken. Hostingplatforms, contentleveringsdiensten en e-mailproviders vragen soms zelf certificaten aan voor uw subdomeinen. Als uw CAA-set hen weglaat, mislukt de verlenging, vaak ongemerkt, tot een certificaat verloopt. Maak een lijst van elke dienst die een naam onder uw domeinnaam bedient voordat u publiceert.

Een tweede fout is een verkeerd gespelde uitgeversidentificatie, die iedereen blokkeert, ook de instantie die u wilde toestaan. Test met een echte verlenging. Een derde is vergeten dat een CAA-record hoger in de boom geldt voor een subdomein zonder eigen record, zodat een restrictieve apex de verlenging van een subdomein kan blokkeren.

Het wijzigen van het record trekt nooit een bestaand certificaat in. Als er een onverwacht certificaat is uitgegeven, behandel dat dan als een incident en volg de stappen in hoe u uw domeinnaam beveiligt tegen DNS-hijacking. antwoord per e-mail binnen 12 uur, 7 dagen per week, ook bij hulp met DNSSEC, CAA-records en misbruikmeldingen, inclusief hulp bij CAA-records.