DANE Record Checker - Gratis zoeken naar TLSA-records

Zoek direct TLSA-records op voor elk domein, controleer je DANE DNS-configuratie en bekijk de velden voor certificaatgebruik – gratis en zonder dat je je hoeft aan te melden.

Domein Poort Protocol

Ik ben de TLSA-gegevens aan het opzoeken…

Naam van de query

-

Samenvatting

Cheques

Opmerking: Voor het vergelijken van certificaathashes is een actieve TLS-handshake vereist; dit wordt niet door deze tool uitgevoerd. De DNSSEC-status wordt gecontroleerd aan de hand van de AD-vlag in DNS-antwoorden.

Gratis DANE-opzoekfunctie · aanmelden is niet nodig

Hoe gebruik je de DANE-recordchecker?

Voer uw domeinnaam in (bijv. powerdmarc.com) - zonder https://

Stel de poort en het protocol in voor de te controleren dienst. Gebruik 25 / TCP voor SMTP-e-mail, 443 / TCP voor HTTPS

Klik op Check DANE – deze tool verwerkt uw MX-records, zoekt de TLS-records op de juiste mailhost op en controleert alle veldwaarden

Wat is DANE?

DANE (DNS-Based Authentication of Named Entities) is een internetbeveiligingsprotocol dat is gedefinieerd in RFC 6698 en dat gebruikmaakt van met DNSSEC ondertekende TLSA-records om TLS-certificaten aan domeinnamen te koppelen. In plaats van te vertrouwen op een certificeringsinstantie (CA) om de geldigheid van een certificaat te waarborgen, stelt DANE domeineigenaren in staat het verwachte certificaat rechtstreeks in het DNS te publiceren – beveiligd door DNSSEC.

DANE wordt vooral ingezet voor SMTP-e-mailbeveiliging, waarbij het voorkomt dat aanvallers e-mails tijdens het verzenden onderscheppen met behulp van valse certificaten. Het kan ook HTTPS, XMPP, SIP en elk ander op TLS gebaseerd protocol beveiligen.

→ Wat is DANE? Volledige technische handleiding

Certificaatpinning via DNS

Publiceert de verwachte certificaatvingerafdruk in DNS, zodat verbindende clients deze onafhankelijk van certificeringsinstanties kunnen verifiëren.

Preventie van MITM-aanvallen

Voorkomt man-in-the-middle-aanvallen door het onmogelijk te maken verbindingen met valse certificaten te onderscheppen.

Veilige SMTP-e-mailverzending

Zorgt ervoor dat ontvangende mailservers precies het verwachte TLS-certificaat tonen, waardoor versleutelde e-mailverzending wordt afgedwongen.

Preventie van downgrade-aanvallen

Voorkomt dat aanvallers e-mailservers tijdens de SMTP-onderhandelingen dwingen om over te schakelen naar leesbare tekst of zwakkere versleuteling.

Hoe werkt DANE?

DANE werkt door een TLSA-record in het DNS te publiceren waarin het verwachte TLS-certificaat voor een dienst wordt beschreven. Wanneer een client verbinding maakt, haalt deze het TLSA-record op via DNSSEC en vergelijkt het met het certificaat dat tijdens de TLS-handshake wordt aangeboden.

TLSA-record publiceren - De domeineigenaar maakt een TLSA-record aan op _port._protocol.domain met de verwachte certificaatparameters

DNSSEC-gevalideerde DNS-opzoeking – De verbindende client voert een DNSSEC-gevalideerde query uit om het TLSA-record op te halen en te verifiëren

Vergelijking van TLS-handshakes – Het aangeboden certificaat wordt vergeleken met de certificaatassociatiegegevens in het TLSA-record

Toepassen of weigeren – Als het certificaat overeenkomt, wordt de verbinding tot stand gebracht; zo niet, dan wordt deze geweigerd om misbruik te voorkomen

Wat is een TLSA-record?

Een TLSA-record is het DNS-recordtype dat door DANE wordt gebruikt. Het slaat een TLS-certificaatvingerafdruk (of het volledige certificaat) op onder een specifieke DNS-naam die aan een poort en protocol is gekoppeld, zodat elke verbinding makende client deze via DNSSEC kan ophalen en verifiëren voordat de TLS-handshake wordt voltooid.

TLSA-records volgen deze naamgevingsconventie:

_[port]._[protocol].[hostname] → e.g. _25._tcp.mail.example.com. IN TLSA 3 1 1 ab12cd34…

Bij SMTP staat het TLSA-record op de MX-hostnaam, niet op het hoofddomein. Daarom zoekt deze tool eerst automatisch de MX-records van uw domein op en controleert vervolgens de TLSA op de juiste host.

Inzicht in de velden van TLSA-records

Een album als 3 1 1 <hash> betekent DANE-EE, SubjectPublicKeyInfo, SHA-256 – de meest aanbevolen configuratie voor SMTP DANE.

Veld	Waarden	Betekenis
Gebruik van het certificaat	0 = PKIX-TA · 1 = PKIX-EE · 2 = DANE-TA · 3 = DANE-EE	Welk certificaat in de keten moet worden geverifieerd, en of PKIX CA-validatie ook vereist is
Keuzeschakelaar	0 = Volledig certificaat · 1 = SubjectPublicKeyInfo	Of het volledige certificaat of alleen de openbare sleutel moet worden vergeleken
Soort combinatie	0 = Exact · 1 = SHA-256 · 2 = SHA-512	Hoe de certificaatgegevens in het record worden gecodeerd
Certificaatgegevens	Hash met hexadecimale codering of volledige certificaatbytes	De vingerafdruk of het certificaat waarmee moet worden vergeleken wat de server aanbiedt

Veelvoorkomende problemen bij de DANE-DNS-configuratie

De meeste DANE-fouten zijn terug te voeren op een handvol veelvoorkomende configuratiefouten. Hieronder lees je waar je op moet letten als de controle van je DANE-record onverwachte resultaten oplevert.

Probleem	Oorzaak	Impact
Er is geen TLSA-record gevonden	Er is geen DANE gepubliceerd voor deze poort/dit protocol, of deze is gecontroleerd op de verkeerde hostnaam	DANE kan niet worden afgedwongen; verbindingen zijn uitsluitend afhankelijk van het vertrouwen in de certificeringsinstantie
DNSSEC is niet ingeschakeld	TLSA-records zonder DNSSEC kunnen tijdens het transport worden vervalst	DANE-clients wijzen het TLSA-record af of negeren het volledig
Certificaatconflict na verlenging	Het TLS-certificaat is vernieuwd, maar het TLSA-record is nog niet aangepast	Legitieme verbindingen geweigerd; e-mailbezorging mislukt
Ongeldig gebruik/selector/overeenkomende velden	Waarden in het TLSA-record die buiten het toegestane bereik vallen of niet worden ondersteund	De validatie mislukt altijd, zelfs als het certificaat correct is
Ontbrekend rollover-record	Er wordt slechts één TLSA-record gepubliceerd tijdens een certificaatovergang	Uitval als het oude record wordt verwijderd voordat de DNS het nieuwe record heeft doorgevoerd

Aanbevolen werkwijzen voor DANE-records

Rollover-TLSA-records publiceren

Zorg ervoor dat u altijd een tweede TLSA-record voor uw volgende certificaat klaar hebt liggen voordat u het certificaat verlengt, om te voorkomen dat de levering mislukt.

Schakel eerst DNSSEC in

DANE werkt alleen als DNSSEC is ingeschakeld. Publiceer je TLSA-records pas nadat is bevestigd dat DNSSEC werkt.

Werk TLSA bij voordat je het certificaat verlengt

Voeg het nieuwe TLSA-record toe aan het DNS voordat u het certificaat verlengt, zodat de verspreiding op tijd is voltooid.

De TLSA-records continu controleren

Detecteer automatisch discrepanties tussen certificaten en TLSA’s voordat deze tot mislukte e-mailbezorging leiden.

Veelgestelde Vragen

Wat is een TLSA-record?

Een TLSA-record is een DNS-recordtype (type 52) dat door DANE wordt gebruikt om een TLS-certificaat of openbare sleutel te koppelen aan een specifiek domein, een specifieke poort en een specifiek protocol. Het bevat een certificaatvingerafdruk die via DNSSEC is beveiligd, zodat verbindende clients het certificaat tijdens de TLS-handshake kunnen verifiëren zonder een beroep te doen op een certificeringsinstantie.

Wat is DANE in DNS?

DANE (DNS-Based Authentication of Named Entities) is een beveiligingsprotocol dat TLS-certificaatgegevens rechtstreeks in het DNS publiceert via TLSA-records, beveiligd door DNSSEC. Het maakt een einde aan de afhankelijkheid van externe certificeringsinstanties door domeineigenaren de mogelijkheid te bieden precies aan te geven welk certificaat voor hun diensten als betrouwbaar moet worden beschouwd.

Welke poort en welk protocol moet ik gebruiken voor e-mail-DANE?

Gebruik voor SMTP-e-mailverzending tussen mailservers poort 25 met TCP. Het TLSA-record is te vinden op _25._tcp.[mx-hostname]. Let op: voor e-mail moeten de TLSA-records op de MX-hostnaam staan — niet op het hoofddomein. Gebruik poort 443 / TCP voor HTTPS.

Kan ik DANE en MTA-STS samen gebruiken?

Ja, en dat wordt aanbevolen. DANE dwingt TLS af met behulp van via DNSSEC vastgezette certificaten, terwijlMTA-STSTLS afdwingt via een beleid dat via HTTPS wordt gehost. Door beide te gebruiken wordt de dekking gemaximaliseerd: DANE biedt bescherming tegen malafide certificeringsinstanties, terwijl MTA-STS dekking biedt voor verzendende servers die DANE niet ondersteunen.

Heb ik DNSSEC nodig om DANE te laten werken?

Ja — DNSSEC is een absolute vereiste voor DANE. Zonder DNSSEC zou iedereen een vals TLSA-record kunnen publiceren dat naar een kwaadaardig certificaat verwijst, waardoor de hele validatie zinloos zou worden. DNSSEC ondertekent je DNS-records cryptografisch, zodat resolvers kunnen controleren of er niet mee is geknoeid.

Wat is het verschil tussen DANE-TA (toepassing 2) en DANE-EE (toepassing 3)?

DANE-TA (Trust Anchor, gebruik 2) komt overeen met een tussencertificaat of een root-CA-certificaat — elk certificaat dat door die CA is ondertekend, zal de validatie doorstaan. DANE-EE (End Entity, gebruik 3) komt rechtstreeks overeen met het eigen certificaat of de openbare sleutel van de server. Voor SMTP is gebruik 3 met selector 1 (openbare sleutel) en matchingtype 1 (SHA-256) de aanbevolen configuratie volgens RFC 7672.