DNS-based Authentication of Named Entities#TLSA RR

TLS/SSL encryption is currently based on certificates issued by certificate authorities (CAs). Within the last few years{{when|date=April 2024}}, a number of CA providers suffered serious security breaches, allowing the issuance of certificates for well-known domains to those who don't own those domains. Trusting a large number of CAs might be a problem because any breached CA could issue a certificate for any domain name. DANE enables the administrator of a domain name to certify the keys used in that domain's TLS clients or servers by storing them in the Domain Name System (DNS). DANE needs the DNS records to be signed with DNSSEC for its security model to work.

Additionally DANE allows a domain owner to specify which CA is allowed to issue certificates for a particular resource, which solves the problem of any CA being able to issue certificates for any domain.

DANE solves similar problems as:

; Certificate Transparency : Ensuring that rogue CAs cannot issue certificates without the permission of the domain holder without being detected

; DNS Certification Authority Authorization : Limiting which CAs can issue certificates for a given domain

However, unlike DANE, those technologies have wide support from browsers.

Until recently, there has been no widely implemented standard for encrypted email transfer.{{cite web|url=http://www.postfix.org/TLS_README.html#client_tls_secure |title=Postfix TLS Support - Secure server certificate verification |publisher=Postfix.org |access-date=2015-12-30}} Sending an email is security agnostic; there is no URI scheme to designate secure SMTP.{{cite conference |url=https://www.ietf.org/proceedings/87/slides/slides-87-dane-2.pdf | conference=IETF 87 Proceedings |title=DANE for SMTP |last1=Dukhovni |last2=Hardaker |publisher=IETF |date=2013-07-28}} Consequently, most email that is delivered over TLS uses only opportunistic encryption.{{cite web |url=https://blog.filippo.io/the-sad-state-of-smtp-encryption/ |title=The sad state of SMTP encryption |author=Filippo Valsorda |date=2015-03-31 |access-date=2015-12-30}} Since DNSSEC provides authenticated denial of existence (allows a resolver to validate that a certain domain name does not exist), DANE enables an incremental transition to verified, encrypted SMTP without any other external mechanisms, as described by {{IETF RFC|7672}}. A DANE record indicates that the sender must use TLS.

Additionally, {{IETF RFC|8162}} exists for applying DANE to S/MIME,{{cite IETF |rfc=8162 |title=Using Secure DNS to Associate Certificates with Domain Names For S/MIME |publisher=IETF |date=May 2017 |last=Hoffman |first=P. |access-date=2022-03-30}} and {{IETF RFC|7929}} standardises bindings for OpenPGP.{{cite IETF |rfc=7929 |title=DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP |publisher=IETF |date=August 2016 |last=Wouters |first=P. |access-date=2016-09-14}}

• Google Chrome does not support DANE, since Google Chrome wishes to eliminate the use of 1024-bit RSA within the browser{{Cite web|url=https://www.imperialviolet.org/2015/01/17/notdane.html|title=ImperialViolet - Why not DANE in browsers|last=Langley|first=Adam|date=2015-01-17|website=www.imperialviolet.org|language=en|access-date=2017-03-24}}{{Self-published source|date=April 2018}} (DNSSEC previously used a 1024-bit RSA signed root,{{cite web|author=Duane Wessels, Verisign |url=https://blog.verisign.com/security/increasing-the-strength-of-the-zone-signing-key-for-the-root-zone/ |title=Increasing the Strength Zone Signing Key for the Root Zone |publisher=Verisign.com |date=2016-05-16 |access-date=2016-12-29}} and many zones are still signed with 1024-bit RSA, although the modern default is 256-bit ECDSA{{Cite web|url=https://bind9.readthedocs.io/en/latest/dnssec-guide.html |title=Bind9 DNSSEC Guide |website=bind9.readthedocs.io |access-date=2021-08-22}}). According to Adam Langley the code was written{{cite web|author=Adam Langley |url=https://www.imperialviolet.org/2012/10/20/dane-stapled-certificates.html |title=DANE stapled certificates |publisher=ImperialViolet |date=2012-10-20 |access-date=2014-04-16}}{{Self-published source|date=April 2018}} and, although it is not in Chrome today,{{cite web|author=Adam Langley |url=https://www.imperialviolet.org/2011/06/16/dnssecchrome.html |title=DNSSEC authenticated HTTPS in Chrome |publisher=ImperialViolet |date=2011-06-16 |access-date=2014-04-16}}{{Self-published source|date=April 2018}} it remains available in add-on form.[http://www.internetsociety.org/deploy360/resources/how-to-add-dnssec-support-to-google-chrome/ How To Add DNSSEC Support To Google Chrome]
• Mozilla Firefox does not support DANE. Based on the reactions in tickets on the subjects ("We have no plans to implement this feature"), DNSSEC and DANE are currently seen by Mozilla developers as outside of the scope of Firefox.{{cite web | url=https://bugzilla.mozilla.org/show_bug.cgi?id=672600 | title=672600 - Use DNSSEC/DANE chain stapled into TLS handshake in certificate chain validation }}{{cite web | url=https://bugzilla.mozilla.org/show_bug.cgi?id=1479423 | title=1479423 - support for DNSSEC/DANE/TLSA validation }} Addon support was available until Firefox 56 (last updated 2016{{cite web |last1=Weber |first1=Johannes |title=How to use DANE/TLSA |url=https://weberblog.net/how-to-use-danetlsa/ |website=Weberblog.net |date=25 October 2016}}), but no longer exists. It can no longer be implemented with the more recent, more restrictive Firefox-extension APIs.[https://www.dnssec-validator.cz/ DNSSEC/TLSA Validator]
• GNU Privacy Guard Allows fetching keys via OpenPGP DANE (--auto-key-locate). New option --export-options export-dane. (version 2.1.14){{cite web|title=GnuPG - Release Notes |date=12 June 2021 |publisher=gnupg.org |url=https://gnupg.org/download/release_notes.html |access-date=2021-08-27}}{{Self-published source|date=April 2018|ABOUTSELF=y}}
• Cheogram Android allows verifying via DANE and shows the status if DANE was used or not{{cite web|url=https://git.singpolyma.net/cheogram-android/refs/2.13.0-1|title=cheogram-android 2.13.0-1|access-date=2021-02-11}}
• FairEmail for Android allows verifying DANE for SMTP and POP/IMAP servers{{cite web|title=FairEmail FAQ |date=3 May 2025 |publisher=m66b.github.io |url=https://m66b.github.io/FairEmail/#faq202 |access-date=2025-05-03}}{{Self-published source|date=May 2025|ABOUTSELF=y}}

• Postfix{{cite web|url=http://www.postfix.org/TLS_README.html#client_tls_dane |title=Postfix TLS Support - DANE |publisher=Postfix.org |access-date=2014-04-16}}
• PowerMTA {{cite web|url=https://www.sparkpost.com/docs/tech-resources/pmta-50-features/ |title= PowerMTA 5.0 Release |publisher=SparkPost.com |access-date=2020-04-26}}
• Exim{{cite web|url=http://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html#SECDANE |title=Exim 4.91 spec: Encrypted SMTP connections using TLS/SSL / 15. DANE|publisher=exim.org |access-date=2018-07-05}}
• Prosody{{cite web|url=https://prosody.im/doc/modules/mod_s2s_auth_dane_in|title=mod_s2s_auth_dane_in|publisher=prosody.im|access-date=2024-02-11}}

• Posteo{{Cite web |url=https://www.theguardian.com/technology/2014/aug/24/posteo-protect-email-the-german-way-patrik-lohr |title=Protect your email the German way |date=2014-08-24 |last1=Scaturro |first1=Michael |website=The Guardian |access-date=2018-04-29 |quote=... Last May, [Posteo] became the world's first email provider to adopt DNS-based Authentication of Named Entities (Dane) on its servers. ...}}
• Tutanota{{citation|url=https://tutanota.com/blog/posts/dane-everywhere |title=DANE Everywhere?! Let's Make the Internet a Private Place Again | publisher=tutanota.de|access-date=2015-12-17}}{{Self-published source|date=April 2018|ABOUTSELF=y}}

• OpenSSL{{cite web|url=https://github.com/openssl/openssl/commit/59fd40d4e5030a7257edd11d758eab1dcebb3787 |title=DANE CHANGES |author=Richard Levitte |website=GitHub |date=2016-01-07 |access-date=2016-01-13}}{{Self-published source|date=April 2018|ABOUTSELF=y}}
• GnuTLS{{cite web|url=http://www.gnutls.org/manual/html_node/Verifying-a-certificate-using-DANE.html|title=Verifying a certificate using DANE (DNSSEC) |publisher=Gnu.org}}{{Self-published source|date=April 2018|ABOUTSELF=y}}

The TLSA RR (Resource Record) for a service is located at a DNS name that specifies certificate constraints should be applied for the services at a certain TCP or UDP port. At least one of the TLSA RRs must provide a validation (path) for the certificate offered by the service at the specified address.

Not all protocols handle Common Name matching the same way. HTTP requires that the Common Name in the X.509 certificate provided by the service matches regardless of the TLSA asserting its validity. SMTP does not require the Common Name matches, if the certificate usage value is 3 (DANE-EE), but otherwise does require a Common Name match. It is important to verify if there are specific instructions for the protocol being used.

The RR itself has 4 fields of data, describing which level of validation the domain owner provides.

• the certificate usage field
• the selector field
• the matching type field
• the certificate association data

E.g. {{code|_25._tcp.somehost.example.com. TLSA 3 1 1 0123456789ABCDEF|zone}}

The first field after the TLSA text in the DNS RR, specifies how to verify the certificate.

• A value of 0 is for what is commonly called CA constraint (and PKIX-TA). The certificate provided when establishing TLS must be issued by the listed root-CA or one of its intermediate CAs, with a valid certification path to a root-CA already trusted by the application doing the verification. The record may just point to an intermediate CA, in which case the certificate for this service must come via this CA, but the entire chain to a trusted root-CA must still be valid.{{efn|An uncommon example where this could be useful would be if you don't trust the root-CA completely, but many applications do still use it, and you do trust a specific of the intermediate CAs, so you list the intermediate and still get full trust path verification.}}
• A value of 1 is for what is commonly called service certificate constraint (and PKIX-EE). The certificate used must match the TLSA record, and it must also pass PKIX certification path validation to a trusted root-CA.
• A value of 2 is for what is commonly called trust anchor assertion (and DANE-TA). The TLSA record matches the certificate of the root CA, or one of the intermediate CAs, of the certificate in use by the service. The certification path must be valid up to the matching certificate, but there is no need for a trusted root-CA.
• A value of 3 is for what is commonly called domain issued certificate (and DANE-EE). The TLSA record matches the used certificate itself. The used certificate does not need to be signed by other parties. This is useful for self-signed certificates, but also for cases where the validator does not have a list of trusted root certificates.

When connecting to the service and a certificate is received, the selector field specifies which parts of it should be checked.

• A value of 0 means to select the entire certificate for matching.
• A value of 1 means to select just the public key for certificate matching. Matching the public key is often sufficient, as this is likely to be unique.

• A type of 0 means the entire information selected is present in the certificate association data.
• A type of 1 means to do a SHA-256 hash of the selected data.
• A type of 2 means to do a SHA-512 hash of the selected data.

The actual data to be matched given the settings of the other fields. This is a long "text string" of hexadecimal data.

The TLSA record for {{URL2|www.ietf.org}} specifies to check the SHA-256 hash of the public key of the certificate provided, ignoring any CA.

{{sxhl|2=zone|_443._tcp.www.ietf.org. TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6}}

Their mail service has the same exact certificate and TLSA.

{{sxhl|2=zone|

ietf.org. MX 0 mail.ietf.org.

_25._tcp.mail.ietf.org. TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

}}

Finally, the following example, does the same as the others, but does the hash calculation over the entire certificate.

{{sxhl|2=zone|_25._tcp.mail.alice.example. TLSA 3 0 1 AB9BEB9919729F3239AF08214C1EF6CCA52D2DBAE788BB5BE834C13911292ED9}}

• {{IETF RFC|6394}} Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)
• {{IETF RFC|6698}} The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
• {{IETF RFC|7218}} Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)
• {{IETF RFC|7671}} The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
• {{IETF RFC|7672}} SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
• {{IETF RFC|7673}} Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records
• {{IETF RFC|7929}} DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP
• {{IETF RFC|4255}} Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
• {{IETF RFC|8162}} Using Secure DNS to Associate Certificates with Domain Names for S/MIME
• Draft: Opportunistic Encryption with DANE Semantics and IPsec: IPSECA{{Cite journal |last1=Osterweil |first1=Eric |last2=Wiley |first2=Glen |last3=Okubo |first3=Tomofumi |last4=Lavu |first4=Ramana |last5=Mohaisen |first5=Aziz |date=6 July 2015 |title=Opportunistic Encryption with DANE Semantics and IPsec: IPSECA |url=https://datatracker.ietf.org/doc/html/draft-osterweil-dane-ipsec-03 |journal=Internet Engineering Task Force}}

• DNS Certification Authority Authorization
• SMTP MTA Strict Transport Security (MTA-STS)

{{Notelist}}

{{Reflist|30em}}

• [https://sockpuppet.org/blog/2015/01/15/against-dnssec/ DNSSEC is unnecessary - Against DNSSEC]
• [https://easydns.com/blog/2015/08/06/for-dnssec/ For DNSSEC] - A rebuttal to the points in "Against DNSSEC"
• [https://www.internetsociety.org/resources/deploy360/dane-test-sites/ List of DANE test sites]
• [https://dane.sys4.de/ Online tool to check mail servers for DNSSEC and DANE support]
• [https://labs.ripe.net/Members/dennis_baaten/better-mail-security-with-dane-for-smtp Illustrated DANE advocacy] with links to howtos and tools

{{SSL/TLS}}

Category:Domain Name System Security Extensions

Category:Domain Name System

Category:Internet Standards

Category:Key management

Category:Public-key cryptography

Category:Transport Layer Security