DANE staat voor DNS-based Authentication of Named Entities. Het is een standaard die een TLS-certificaat via DNS aan een domeinnaam koppelt, zodat de andere kant kan controleren of het certificaat klopt.

Heb ik DNSSEC nodig voor DANE?

Ja. DNSSEC is verplicht voor DANE. Zonder ondertekende DNS-zone kan een aanvaller het TLSA-record vervalsen en biedt DANE geen bescherming. Zet DNSSEC daarom altijd eerst aan.

Wat is een TLSA-record?

Een TLSA-record is het DNS-record waarin DANE de vingerafdruk van je certificaat of publieke sleutel publiceert. Het bestaat uit een certificaatgebruik, een selector, een matchtype en de vingerafdruk zelf.

Werkt DANE ook voor websites?

Technisch kun je een TLSA-record voor HTTPS publiceren, maar browsers als Chrome en Firefox controleren DANE niet. In de praktijk wordt DANE vooral gebruikt voor e-mail tussen mailservers.

Vervangt DANE mijn SSL-certificaat?

Nee. Je hebt nog steeds een gewoon TLS-certificaat nodig. DANE bepaalt alleen welk certificaat vertrouwd mag worden, als extra controle bovenop of in plaats van het vertrouwen in certificaatautoriteiten.

Waarom mislukt mijn e-mail na het vernieuwen van het certificaat?

Waarschijnlijk paste het TLSA-record niet meer bij het nieuwe certificaat. Bij een 3 1 1-record verandert de sleutel bij vernieuwing. Publiceer het nieuwe record naast het oude voordat je het certificaat wisselt, of hergebruik dezelfde sleutel.

Wat is DANE? Veilige e-mail met TLSA en DNSSEC

DANE koppelt via een TLSA-record je TLS-certificaat aan DNSSEC. Lees wat DANE is, hoe het werkt en waarom DNSSEC voor DANE vereist is.

DANE (DNS-based Authentication of Named Entities) is een beveiligingsstandaard waarmee je in je DNS vastlegt welk TLS-certificaat bij jouw domein hoort. In plaats van alleen te vertrouwen op certificaatautoriteiten publiceer je een vingerafdruk van je certificaat in een speciaal DNS-record en beveilig je dat met DNSSEC. In dit artikel lees je wat DANE is, hoe het met TLSA-records werkt, wat het verschil is met gewoon SSL/TLS en waarom DNSSEC voor DANE noodzakelijk is.

Wat is DANE?

DANE staat voor DNS-based Authentication of Named Entities. Het is een internetstandaard, beschreven in RFC 6698 uit 2012, die een TLS-certificaat aan een domeinnaam koppelt via het Domain Name System (DNS). Daarmee kan de andere kant controleren of het certificaat dat een server aanbiedt echt het certificaat is dat jij hebt aangewezen.

De koppeling leg je vast in een TLSA-record. Omdat het gewone DNS te vervalsen is, leunt DANE op DNSSEC: dat ondertekent je DNS-records digitaal, zodat een aanvaller het TLSA-record niet ongemerkt kan aanpassen. Zonder DNSSEC biedt DANE geen echte bescherming.

Een CAA-record legt vast welke certificaatautoriteit een certificaat voor je domein mag uitgeven. DANE gaat een stap verder en legt vast welk certificaat of welke sleutel zelf geldig is.

Waarom gewoon SSL/TLS niet altijd genoeg is

Een gewone TLS-verbinding, zoals het slotje van HTTPS of TLS bij e-mail, vertrouwt op certificaatautoriteiten, kortweg CA's. Je browser of mailserver heeft een lijst met honderden CA's die hij vertrouwt, en elke CA kan in principe voor elk domein een certificaat uitgeven. Wordt zo'n CA gehackt of misleid, dan kan een aanvaller een geldig ogend certificaat voor jouw domein krijgen.

Bij e-mail speelt nog een tweede probleem. Mailservers gebruiken meestal STARTTLS, een opportunistische vorm van versleuteling. Een aanvaller die tussen twee servers zit, kan de STARTTLS-aankondiging weghalen, een zogeheten downgrade- of strip-aanval, zodat de mail alsnog onversleuteld wordt verstuurd. En zelfs als er wel TLS is, controleert de verzendende server het certificaat vaak niet. DANE pakt beide problemen aan.

Hoe werkt DANE?

Bij DANE publiceer je in je DNS-zone een TLSA-record met een vingerafdruk van je certificaat of van de publieke sleutel daarvan. De controlerende kant, bijvoorbeeld een verzendende mailserver, doorloopt dan drie stappen:

Het TLSA-record opzoeken op de juiste naam in DNS.
De DNSSEC-handtekening controleren, zodat vaststaat dat het record echt en onveranderd is.
Het certificaat dat de server aanbiedt vergelijken met de vingerafdruk uit het record.

Komt het certificaat overeen, dan is de verbinding vertrouwd. Komt het niet overeen, of ontbreekt een geldige DNSSEC-handtekening, dan wordt de verbinding geweigerd. Voor e-mail betekent dit dat versleuteling verplicht en gecontroleerd wordt in plaats van vrijblijvend.

Het TLSA-record en zijn velden

Andere e-mailbeveiliging, zoals SPF, DKIM en DMARC, publiceer je in een TXT-record. DANE gebruikt daarvoor een eigen recordtype: het TLSA-record. Dat staat op een speciale naam die is opgebouwd uit de poort, het protocol en de hostnaam, in de vorm _poort._protocol.hostnaam. Voor een mailserver die SMTP op poort 25 gebruikt, is dat bijvoorbeeld _25._tcp.mail.jouwdomein.nl. Voor HTTPS zou het _443._tcp.www.jouwdomein.nl zijn.

Het record zelf bestaat uit drie parameters en de bijbehorende data:

De drie velden van een TLSA-record
Veld	Waarde	Betekenis
Certificaatgebruik	0, 1, 2 of 3	Wat er wordt vastgelegd: een CA (0 PKIX-TA of 2 DANE-TA) of het servercertificaat zelf (1 PKIX-EE of 3 DANE-EE). Voor e-mail is 3 (DANE-EE) gebruikelijk.
Selector	0 of 1	Waar de vingerafdruk over gaat: het hele certificaat (0) of alleen de publieke sleutel (1).
Matchtype	0, 1 of 2	Hoe de data is opgeslagen: volledig (0), als SHA-256-hash (1) of als SHA-512-hash (2).

Daarna volgt de certificaatassociatiedata: de eigenlijke vingerafdruk. Een veelgebruikte combinatie voor e-mail is 3 1 1, oftewel het servercertificaat, de publieke sleutel en een SHA-256-hash. Een volledig record ziet er dan zo uit:

_25._tcp.mail.jouwdomein.nl. IN TLSA 3 1 1 29c8d5f8e1b3a47c9d0e6f2a1b8c3d4e5f60718293a4b5c6d7e8f9012a3b4c5d6

Het verschil tussen DANE en gewoon SSL/TLS

Het grote verschil zit in wie bepaalt welk certificaat te vertrouwen is. Bij gewoon SSL/TLS is dat het CA-systeem: je vertrouwt elke CA in de lijst, en je hebt zelf geen invloed op welke CA voor jouw domein mag tekenen.

Bij DANE bepaal jij dat, door in DNS vast te leggen welk certificaat, welke sleutel of welke CA geldig is. De client controleert het aangeboden certificaat daartegen, en die informatie is met DNSSEC beveiligd. DANE vervangt je certificaat niet: je hebt nog steeds een gewoon TLS-certificaat nodig. Het voegt een extra, door jou beheerd controlepunt toe, en maakt versleuteling bij e-mail verplicht in plaats van vrijblijvend.

Waarom DNSSEC vereist is voor DANE

DANE staat of valt met DNSSEC. Het gewone DNS heeft geen ingebouwde beveiliging: een aanvaller die het verkeer onderschept of een resolver misleidt, kan andere antwoorden teruggeven dan de echte. Zou hij ook het TLSA-record kunnen vervalsen, dan wijst hij simpelweg zijn eigen certificaat als geldig aan en is de bescherming weg.

DNSSEC ondertekent je DNS-records digitaal. Een resolver kan zo controleren dat een antwoord echt van jouw domein komt en onderweg niet is aangepast. Pas als het TLSA-record via DNSSEC als geldig is bevestigd, mag de andere kant erop vertrouwen. Daarom is DNSSEC geen aanrader maar een vereiste: zonder ondertekende zone doet DANE niets. Lees zo nodig eerst wat DNSSEC is voordat je met DANE begint.

Waar wordt DANE in de praktijk gebruikt?

DANE wordt vooral gebruikt om e-mail tussen mailservers te beveiligen. De regels daarvoor staan in RFC 7672. Grote partijen ondersteunen het inmiddels: Microsoft heeft DANE met DNSSEC voor inkomende e-mail van Exchange Online in 2024 en 2025 uitgerold, en Google Workspace controleert sinds 2023 de TLSA-records van ontvangers bij uitgaande e-mail.

In Nederland stimuleert het Forum Standaardisatie het gebruik: STARTTLS en DANE staan op de pas-toe-of-leg-uit-lijst en zijn verplicht voor overheidsorganisaties. Je kunt je domein testen op internet.nl.

Voor gewone websites is DANE een ander verhaal. Browsers als Chrome en Firefox ondersteunen DANE niet en hebben daar ook geen plannen voor. Een TLSA-record op poort 443 heeft in de browser dus geen effect. In de praktijk is DANE daarom vooral een e-mailmaatregel.

DANE en een TLSA-record instellen

DANE inschakelen bestaat uit een paar stappen. De precieze schermen verschillen per DNS-beheerder en mailserver, maar de aanpak is steeds hetzelfde:

Zet DNSSEC aan op je domein. Dit is de basis: zonder DNSSEC werkt DANE niet. Bij LJPc hosting is DNSSEC beschikbaar voor domeinen die bij LJPc geregistreerd zijn en de LJPc-nameservers gebruiken; je laat het via support controleren of aanzetten.
Zorg dat je mailserver TLS aanbiedt met een geldig certificaat.
Maak uit dat certificaat een TLSA-record aan, meestal in de vorm 3 1 1, de SHA-256-hash van de publieke sleutel.
Publiceer het TLSA-record op de juiste naam, bijvoorbeeld _25._tcp bij de hostnaam van je mailserver, in je met DNSSEC ondertekende zone.
Controleer de configuratie voordat je erop vertrouwt (zie hieronder).

De mogelijkheden voor TLSA-records hangen af van je DNS-beheerder en mailserver. Omdat DANE zowel DNSSEC als zorgvuldig certificaatbeheer vraagt, stem je de inrichting het beste af met support of je DNS-beheerder. Twijfel je hoe dit voor jouw domein zit, neem dan contact op met support.

Je DANE-configuratie controleren

Controleer altijd of je TLSA-record klopt voordat je ervan uitgaat dat het werkt. Op de commandoregel vraag je het record op met dig:

dig TLSA _25._tcp.mail.jouwdomein.nl +short

Belangrijk is ook dat DNSSEC voor je zone geldig is, want anders negeert de andere kant het record. Online controleer je dat bijvoorbeeld met internet.nl of met een TLSA-checker. Die tools laten zien of de vingerafdruk overeenkomt met het certificaat dat je server aanbiedt.

Veelvoorkomende problemen

De meeste DANE-problemen komen door DNSSEC of door een TLSA-record dat niet meer bij het certificaat past. Deze tabel helpt je op weg:

Veelvoorkomende DANE-problemen en oplossingen
Probleem	Oorzaak	Oplossing
DANE wordt genegeerd	DNSSEC staat niet aan voor je zone	Zet DNSSEC aan en controleer of de zone geldig is ondertekend.
Mail of verbindingen mislukken na een certificaatvernieuwing	Bij `3 1 1` verandert de publieke sleutel bij een nieuw certificaat, waardoor het TLSA-record niet meer klopt	Publiceer het nieuwe TLSA-record eerst naast het oude (current en next) en verwijder het oude pas als het nieuwe certificaat live is, of hergebruik dezelfde sleutel bij het vernieuwen.
Record wordt niet gevonden	Verkeerde naam, poort of protocol	Controleer dat de naam `_poort._protocol.hostnaam` klopt, bijvoorbeeld `_25._tcp` voor SMTP.
Ontvanger weigert of negeert het record	Een parametercombinatie die voor e-mail niet gangbaar is	Gebruik een ondersteunde combinatie, zoals `3 1 1` of `2 1 1`.

Met DANE koppel je je TLS-certificaat via DNSSEC aan je domein, zodat de andere kant zeker weet dat het certificaat echt van jou is. Vooral voor e-mail maakt dat je verbindingen een stuk moeilijker te onderscheppen. Kom je er niet uit? Neem dan contact op met support van LJPc hosting, we helpen je graag verder.