Wat is DANE? Uitleg over DNS-gebaseerde authenticatie van benoemde entiteiten (2026)
door
Laatst bijgewerkt:
7 leestijd: 7 minuten
Belangrijkste Conclusies
- DANE verplaatst de validatie van TLS-certificaten van externe certificeringsinstanties naar het DNS, waarbij met DNSSEC ondertekende TLSA-records worden gebruikt om vertrouwen te wekken.
- Het voorkomt STARTTLS-downgrade-aanvallen door versleutelde verbindingen verplicht te stellen, in plaats van een onopgemerkte terugval naar onversleutelde tekst toe te staan.
- DANE vermindert het risico op verkeerd uitgegeven of gecompromitteerde certificaten door domeineigenaren de mogelijkheid te bieden precies te bepalen welke certificaten geldig zijn.
- DNSSEC is vereist om DANE te laten werken. Zonder DNSSEC kunnen TLSA-records niet als betrouwbaar worden beschouwd of worden geverifieerd.
- Hoewel DANE zeer krachtig is, wordt het nog maar beperkt toegepast. Daarom wordt het vaak in combinatie met MTA-STS gebruikt en aangevuld met DMARC voor een volledige e-mailbeveiliging.
DNS-Based Authentication of Named Entities, oftewel DANE, is een methode om TLS-certificaten te verifiëren met behulp van DNS. Deze methode maakt gebruik van DNSSEC- en TLSA-records om te waarborgen dat versleutelde verbindingen niet worden onderschept of gedegradeerd.
Het probleem waarvoor DANE is ontworpen
Bij het verzenden van e-mails via het Simple Mail Transfer Protocol (SMTP) wordt vaak gebruikgemaakt van STARTTLS om verbindingen te versleutelen. Het probleem is dat STARTTLS opportunistisch werkt. Dit betekent dat als de versleuteling mislukt, de verbinding kan terugvallen op onversleutelde tekst. Deze terugval kan onopgemerkt plaatsvinden, waardoor aanvallers dit gedrag gemakkelijk kunnen misbruiken om e-mails te onderscheppen.
Het normale traject:
Het aanvalstraject:
Er is ook nog een tweede probleem met traditionele TLS:
TLS-certificaten worden gevalideerd door commerciële certificeringsinstanties (CA’s). Deze CA’s kunnen worden gehackt of certificaten op onjuiste wijze uitgeven. Als een aanvaller een geldig certificaat voor een domein in handen krijgt, kan hij zich voordoen als die server.
Door deze twee problemen zijn man-in-the-middle-aanvallen mogelijk, zelfs wanneer TLS wordt gebruikt. DANE lost beide problemen op door de validatie van certificaten te verplaatsen naar het DNS, dat wordt beveiligd door DNSSEC. Hierdoor is men niet langer afhankelijk van externe certificeringsinstanties en worden stille downgrade-aanvallen voorkomen.
Wat is DANE?
DANE is een internetbeveiligingsprotocol waarmee domeineigenaren informatie over hun TLS-certificaten rechtstreeks in het DNS kunnen publiceren met behulp van TLSA-records.
Deze records worden beveiligd door DNSSEC, wat het volgende garandeert:
- De gegevens kunnen tijdens het verzenden niet worden gewijzigd
- De klant kan controleren of het antwoord authentiek is
In plaats van te vertrouwen op een externe certificeringsinstantie, controleert de client het certificaat aan de hand van de gegevens die het domein zelf heeft gepubliceerd.
Hoe DANE werkt: stap voor stap
Stap 1: De domeineigenaar publiceert een TLSA-record in het DNS
De domeinbeheerder maakt een TLSA-bronrecord (Transport Layer Security Authentication) aan en publiceert dit in zijn DNS-zone. Dit record bevat de certificaatgegevens die clients later zullen gebruiken voor verificatie.
Stap 2: De DNS-zone wordt ondertekend met behulp van DNSSEC
DNSSEC (DNS Security Extensions) ondertekent de volledige DNS-zone cryptografisch, inclusief het nieuwe TLSA-record. Hierdoor ontstaat een vertrouwensketen vanaf de root-DNS-zone tot aan de records van het domein, waardoor manipulatie wordt voorkomen.
Stap 3: Een client maakt verbinding met de server en vraagt het TLSA-record op
Wanneer een client (zoals een mailserver of browser) een TLS-verbinding met de server tot stand wil brengen, vraagt hij eerst het DNS-systeem om het TLSA-record van het domein.
Stap 4: De client valideert het DNS-antwoord met behulp van DNSSEC
Voordat de resolver van de client het TLSA-record vertrouwt, controleert hij de DNSSEC-handtekeningen door de vertrouwensketen te doorlopen.
Stap 5: De server toont zijn TLS-certificaat
Tijdens de TLS-handshake stuurt de server zijn TLS-certificaat naar de client om zijn identiteit te bewijzen door zijn certificaatketen te tonen.
Stap 6: De klant vergelijkt het certificaat met het TLSA-record
Dit is het belangrijkste onderdeel van de DANE-controle. In deze stap haalt de client het relevante deel van het certificaat van de server op en vergelijkt dit met de gegevens die zijn opgeslagen in het TLSA-record.
Stap 7: Als ze overeenkomen, wordt de verbinding tot stand gebracht
Als de certificaatgegevens overeenkomen met het TLSA-record, verloopt de DANE-validatie succesvol, waardoor de TLS-verbinding met succes tot stand wordt gebracht.
Stap 8: Als ze niet overeenkomen, wordt de verbinding geweigerd
Als het certificaat niet overeenkomt met het TLSA-record, beschouwt de client dit als een beveiligingsfout en weigert hij de TLS-handshake te voltooien. Hierdoor worden man-in-the-middle-aanvallen al bij voorbaat onmogelijk gemaakt.
Wat is een TLSA-record?
Een TLSA-record is een DNS-record dat door DANE wordt gebruikt om te bepalen hoe een TLS-certificaat moet worden gevalideerd.
The format looks like this: <usage> <selector> <matching-type> <certificate-data>
Voorbeeld van een TLSA-record:
_25._tcp.mail.example.com. IN TLSA 3 1 1 (
2A3F5C7D8E9B1A2C3D4E5F67890123456789ABCDEF1234567890ABCDEF123456
)
Elk veld heeft een specifieke functie:
- Gebruik: Bepaalt hoe het certificaat moet worden vergeleken en als betrouwbaar moet worden beschouwd
- Selector: Geeft aan welk deel van het certificaat wordt gebruikt (volledig certificaat of openbare sleutel)
- Opslagtype: geeft aan hoe de gegevens worden opgeslagen (volledige waarde of hash)
- Certificaatgegevens: de werkelijke waarde of hash waarmee moet worden vergeleken
Waarden voor het gebruik van certificaten
Er zijn vier gebruikstypen:
0 (PKIX-TA): Vertrouwensankerbeperking met behulp van traditionele PKI
1 (PKIX-EE): Certificaat van eindentiteit gevalideerd via PKI
2 (DANE-TA): Vertrouwensanker gedefinieerd door DNS
3 (DANE-EE): Certificaat van eindentiteit rechtstreeks gedefinieerd in DNS
Wat e-mailbeveiliging betreft, zijn de gebruikswaarden 2 en 3 het meest relevant, omdat ze de afhankelijkheid van openbare certificeringsinstanties wegnemen.
Waar worden TLSA-records gepubliceerd?
TLSA-records worden gepubliceerd onder specifieke, op diensten gebaseerde subdomeinen. Voor SMTP ziet dit er doorgaans als volgt uit: _25._tcp.mail.example.com
DANE voor e-mail: hoe het SMTP beveiligt
DANE helpt de verzendende server om de authenticiteit van de certificaten van de ontvangende server te verifiëren. Deze verificatie helpt STARTTLS-downgrade- en man-in-the-middle-aanvallen te voorkomen, waardoor de SMTP-communicatie beter beveiligd wordt.
DANE dwingt het gebruik van TLS af bij e-mailverkeer, waardoor wordt voorkomen dat berichten in leesbare tekst worden verzonden of tijdens het transport worden gemanipuleerd.
Waarom DANE DNSSEC vereist
DANE is volledig afhankelijk van de integriteit van DNS-records. Zonder DNSSEC zouden TLSA-records kunnen worden vervalst en zouden aanvallers clients kunnen omleiden naar kwaadaardige certificaten. Deze afhankelijkheid werkt als volgt: DNSSEC ondertekent DNS-antwoorden met behulp van cryptografische sleutels. Hierdoor kan de client controleren of het antwoord niet is gewijzigd en of de gegevens authentiek zijn. Zonder DNSSEC biedt DANE dus geen echt beveiligingsvoordeel.
Wie maakt er gebruik van DANE?
De acceptatie van DANE verschilt wereldwijd, waarbij Europese overheidsinstanties en organisaties in de VS de hoogste acceptatiegraad laten zien. De acceptatie neemt toe in sectoren waar de vertrouwelijkheid van e-mail van cruciaal belang is. Veelgebruikers van DANE zijn onder meer:
- E-mailbeheerders als extra authenticatie- en beveiligingslaag
- Overheidsinstanties in Europese landen en de VS, om de e-mailverkeer binnen de publieke sector te beveiligen (bijvoorbeeld: het Duitse T-Online maakt in de praktijk gebruik van DANE)
- E-mailproviders zoals Comcast, Protonmail, enz.
- Microsoft heeft aangekondigd dat het vanaf juli 2024 ondersteuning biedt voor DANE bij inkomende SMTP-verkeer.
DANE versus MTA-STS: wat is het verschil?
Zowel DANE als Mail Transfer Agent – Strict Transport Security (MTA-STS) zijn bedoeld om SMTP-verbindingen te beveiligen, maar ze maken gebruik van verschillende vertrouwensmodellen. Terwijl MTA-STS steunt op HTTPS en certificeringsinstanties (CA’s), is DANE gebaseerd op DNSSEC en DNS. Hieronder volgen enkele van de belangrijkste verschillen tussen beide:
| Functie | DANE | MTA-STS |
|---|---|---|
| DNSSEC vereist | Ja | Geen |
| Locatie van het beleid | DNS | HTTPS-beleidsbestand |
| CA-afhankelijkheid | Optioneel | Vereist |
| Bescherming tegen verlaging van de rating | Sterk | Sterk |
| Adoptie | Laag | Hoog |
Lees onze uitgebreide gids over wat MTA-STS precies is voor meer informatie over MTA-STS. Bekijk onze implementatiegids voor MTA-STS om te zien hoe u MTA-STS op uw domein kunt implementeren.
Hoe TLS-RPT samenwerkt met DANE en MTA-STS
TLS-RPT is een rapportageprotocol dat inzicht biedt in mislukte TLS-onderhandelingen en bezorgingsproblemen die worden veroorzaakt door verkeerde configuraties van DANE of MTA-STS. Je kunt TLS-RPT zien als een transparantielaag bovenop DANE en MTA-STS (beveiligingslagen). Hoewel zowel DANE als MTA-STS helpen bij het afdwingen van TLS om e-mailverkeer te beveiligen, is er een cruciale lacune in de duidelijkheid over wanneer of waarom de bezorging mislukt.
Daar komt TLS-RPT om de hoek kijken. Het SMTP TLS-rapportageprotocol (TLS-RPT) stuurt dagelijks geaggregeerde feedbackrapporten terug naar de ontvangende servers met informatie over:
- Fouten bij TLS-onderhandelingen
- Problemen met de validatie van certificaten
- Beleidsconflicten (MTA-STS of DANE)
- Leveringsproblemen als gevolg van TLS-handhaving
Hoe controleer je of je domein een DANE-/TLSA-record heeft
Om de DANE-configuratie te controleren, moet u het volgende controleren:
- Of er een TLSA-record bestaat voor uw mailserver
- Of DNSSEC is ingeschakeld en geldig is
- Of het certificaat overeenkomt met het TLSA-record
U kunt de gratis DANE Record Checker van PowerDMARC gebruiken om uw configuratie snel te controleren.
Hoe implementeer je DANE voor e-mail?
Om DANE voor uw e-mail in te stellen, kunt u de onderstaande stappen volgen:
Stap 1: Schakel DNSSEC in
DANE werkt niet zonder DNSSEC, dus de eerste stap is het configureren van DNSSEC via uw DNS-provider of domeinregistrar. U kunt met onze DNSSEC-checker controleren of dit al voor uw domein is geconfigureerd.
Stap 2: Verzamel de gegevens van uw TLS-certificaat
Haal de hash van het certificaat of de openbare sleutel op van uw e-mailserver.
Stap 3: Maak het TLSA-record aan
Bepaal het juiste gebruik, de juiste selector en het juiste matchingtype, en publiceer vervolgens uw TLSA-record onder het juiste subdomein.
Stap 4: Controleer het record
Gebruik onze DANE-checker om te controleren of het record correct is en of DNSSEC werkt.
Stap 5: Wijzigingen in certificaten bijhouden
Wanneer uw TLS-certificaat wordt vernieuwd of gewijzigd, moet het TLSA-record worden bijgewerkt. Als u dit niet doet, kan de e-mailbezorging worden verstoord.
Laatste woorden
Als u de transportlaag van uw e-mail nog niet beveiligt met MTA-STS, kan DANE een uitstekend startpunt zijn. Vooral in sectoren die met gevoelige gegevens werken, zoals financiële instellingen en overheidsinstanties, is het van cruciaal belang om berichten te beveiligen tegen onderschepping.
DANE kan echter geen spoofing- of phishingaanvallen voorkomen waarbij uw eigen domeinnaam wordt gebruikt. Daarvoor is DMARC onmisbaar. Wilt u een complete beveiligingsoplossing voor uw domein die uw e-mailverificatie van begin tot eind regelt? Boek dan vandaag nog een demo met onze experts.
Veelgestelde Vragen
Is DANE hetzelfde als DNSSEC?
Nee, DANE en DNSSEC zijn niet hetzelfde, hoewel DANE DNSSEC nodig heeft om te kunnen functioneren. DNSSEC beveiligt DNS-records, terwijl DANE DNSSEC gebruikt om certificaatgegevens op een veilige manier te publiceren.
Heb ik zowel DANE als MTA-STS nodig?
Dat hoeft niet per se, maar het gebruik van beide zorgt voor een bredere compatibiliteit en een betere beveiliging. Over het algemeen wordt MTA-STS vaker toegepast dan DANE.
Vervangt DANE SPF, DKIM of DMARC?
Nee. DANE beveiligt de transportlaag , terwijl SPF, DKIM en DMARC zorgen voor e-mailverificatie en het voorkomen van spoofing. Voor een complete e-mailbeveiliging is een meerlaagse aanpak nodig, waarbij alle protocollen worden gecombineerd met voortdurende monitoring en updates.
Wat gebeurt er als mijn TLSA-record niet klopt?
Als uw TLSA-record onjuist is, zullen mailservers die DANE afdwingen verbindingen weigeren. Dit kan leiden tot mislukte e-mailbezorging. Het is belangrijk om uw DANE-configuratie (inclusief de geldigheid van uw TLSA-record) te controleren om eventuele problemen op te lossen.
Welke e-mailproviders ondersteunen DANE?
De ondersteuning voor DANE verschilt per land. Sommige Europese providers en op beveiliging gerichte organisaties stellen het verplicht, maar wereldwijd wordt het nog maar beperkt toegepast.
Expert domein- en e-mailbeveiliging bij PowerDMARC
Ahona is marketingmanager bij PowerDMARC en heeft meer dan vijf jaar ervaring met het schrijven over cybersecurity, gespecialiseerd in domein- en e-mailbeveiliging. Ahona heeft een masterdiploma in journalistiek en communicatie, en heeft sinds 2019 haar carrière in de beveiligingssector verder uitgebouwd.
Laatste berichten van Ahona Rudra (Bekijk alle berichten)
