How to use DANE/TLSA

DNS-based Authentication of Named Entities (DANE) is a great feature that uses the advantages of a DNSSEC signed zone in order to tell the client which TLS certificate he has to expect when connecting to a secure destination over HTTPS or SMTPS. Via a secure channel (DNSSEC) the client can request the public key of the server. This means, that a Man-in-the-Middle attack (MITM) with a spoofed certificate would be exposed directly, i.e., is not possible anymore. Furthermore, the trust to certificate authorities (CAs) is not needed anymore.

In this blog post, I will show how to use DANE and its DNS records within an authoritative DNS server to provide enhanced security features for the public.

This blogpost is part of a series about DNSSEC. Refer to this list for all articles.

In my last posts, I covered a secure installation of BIND as an authoritative DNS server, as well as the implementation of DNSSEC. This is really mandatory because without a signed DNS zone DANE would be useless. Though I am using BIND for the examples below, DANE can be used with any other DNS server, too.

What’s DANE?

The abstract of RFC 6698 “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA”, in which DANE is proposed, describes pretty well what DANE is: “Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain’s TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software.”

Today, a browser establishes a secure TLS connection to a known server (DNS name) with an “unknown” certificate (not proved by the end-user). We are relying on certificate authorities (CAs), which once verified the certificate to be owned by the server operator. Unluckily, any (!) CA is able to sign every (!) certificate in the world, even if a certificate is NOT owned by the server itself, but by a malicious third party that wants to intercept the secure communication via a man-in-the-middle (MITM) attack.

With the new DNS resource record “TLSA”, the hashed public key is publicized within the DNS server of the same authority/entity that owns the TLS server, e.g., an HTTPS server or an SMTPS mail gateway. Now, an end-user client can really validate that the server TLS certificate is owned by the same organization which owns the DNSSEC server. Hence, MITM attacks with spoofed certificates are not possible anymore.

For more information about DANE, refer to the RFCs: 6698, 7218, 7671, and 7672.

Generate TLSA Records

No changes must be made by the TLS servers. The only thing to do is to place the hashed public key into the DNS zone. For the most common scenarios, the fields within the TLSA record are the following (refer to RFC 7671, section 5.1):

  • Usage: 3 – DANE-EE: Domain Issued Certificate
  • Selector: 1 – SPKI: Use subject public key
  • Matching-Type: 1 – SHA-256

For an on-site generation of TLSA records the tool “tlsa” out of the “hash-slinger” toolkit can be used. On a Ubuntu server, this works as follows:

An easy-to-use online tool by Shumon Huque is here: Generate TLSA Record. Copy and paste your certificate, etc., and choose the selector field of “0 – Cert”:

In any way, the TLSA resource record for my test domain “” is this:

This string must be placed into the appropriate zone file on the DNSSEC signing server, in my case “”. After that, I can manually test/request the TLSA record _443._tcp. ...  via DNS and can see that it is authentic (AD flag):


I generated three different TLSA records for my test domains (IPv6-only):

  • <- with a trusted CA-signed certificate
  • <- with a self-signed (!) certificate
  • <- with a CA-signed certificate whose FQDN is NOT

The appropriate TLSA records are the following. Note that I have some different usage and matching type fields, e.g., SHA256 and SHA512:

Note that in all three cases, a TLSA check is valid though only the first TLS certificate is correctly signed by a trusted CA with its correct common name! This is the main advantage of DANE, that self-signed certificates can be used, even with incorrect names, as long as the certificate itself is the correct one published in the DNS.

Online Tools

There are great online tools for checking TLSA records either for HTTPS or for SMTPS:

Here are two sample screenshots of the tools for my test domains. The “host-dane-self” domain is valid though self-signed, while the “” is valid, too, though not congruent with the name of the certificate:

A more detailed view is the text output from Shumon’s SMTPS test with STARTTLS. It greatly shows the connection (via IPv4 and IPv6), the common name of the cert, as well as the matching TLSA record:

And by the way, for more information about DANE, have a look at the common mistakes help page from “sys4” as well.

Browser Add-On: DNSSEC/TLSA Validator

The only good browser plugin for checking DNSSEC and DANE records is the “DNSSEC/TLSA Validator“. Unluckily it has not been updated for almost two years (as of October 2016) and I ran into some Firefox errors while this plugin was enabled.

However, for some tests, it shows the status of the DNS name (first green icon) as well as the DANE/TLSA status (second green icon):

Problem: SSL Interception

One problem will arise if browsers do their own DANE check (which is unluckily not happening today) while organizations are using SSL/TLS interception at their firewalls/proxies. In these cases, the SSL man-in-the-middle “attack” will spoof the certificate to an own created one which is signed by the organizations CA. Though this CA is installed in the browsers, the TLSA check will fail. To my mind, the only way to accomplish this (while not stopping the MITM) is the creation of an “Island of Trust” for DNSSEC with real-time TLSA record spoofing. (Any other ideas?)


That was easy! With only some little DNS resource records, much more security, i.e., authentication, can be achieved. Browsers can access self-signed websites without relying on (malicious) CAs, and MTAs (mail transfer agents) can send mails with the usage of TLS directly to the correct (authentic) destinations.

Today (2016), we are still stuck in the chicken-or-egg problem: Only some sites have DNSSEC signed TLSA records while only some end systems (browsers, MTAs) can validate them. To overcome this problem: Start signing your DNS zones now and insert as many TLSA records as you can. ;)

Featured image “KW5-Nummer-Martin” by Martin Ilich is licensed under CC BY-SA 2.0.

12 thoughts on “How to use DANE/TLSA

  1. Thanks for this. FYI, beginning with BIND 9.11.0, BIND will return TLSA records (if present) in the additional section when responding to a request for MX or SRV records.

  2. Hii ..According to the example which you explained you have a live domain registered with domain registery. I have a doubt, For example if we are running a completely private domain including root node and Top level domain without registering to the Domain registery , Is it possible to develop DNSSEC Hierarchy by our own and then implement DANE and TLSA over it?. Because normally in live domains according to DNSSEC hierarchy the hashed DS segment of the child node is stored in parent in domain registery.But how to implement for a completely private network?

    1. Hey Henderson,

      you are correct that all of my examples are real “live” domains. Just as the Internet works with its single root. ;)

      And yes, you can use DNSSEC for private/hidden domains. The DNSSEC validating resolvers simply need your “trust anchors”, which is the KSK, type 257. For example, BIND uses the “bind.keys” file which currently has the two KSKs for the “.” root domain. You can add your “private.domain.tld” KSK there. Or you can completely override the root domain with your own root KSK. But be sure about what you’re doing! When you’re overriding the root KSK you might get other problems when your using DNSSEC with “real” Internet domains.

      (And of course you can then use any other DNSSEC related feature such as DANE/TLSA or SSHFP with that.)


  3. A crucial part of implementing DANE is planning for key/cert rollover. This means that at least some of the time, a single TLSA record is not enough. At least one of the TLSA records needs to match the “previous” certificate chain, and at least another needs to match the “future” certificate chain.

    Introducing a second TLSA record a few DNS TTLs before rollover and then removing the original after can be a complicated process to execute correctly.

    Therefore, for the majority of DANE users, I *strongly* recommend that they *always* have at least two TLSA records, only *one* of which changes at the next key/cert replacement.

    The two approaches are:

    1. 3 1 1 (current) + 3 1 1 (next)
    2. 3 1 1 (volatile) + 2 1 1 (stable)

    With the first approach the key for the next rotation cycle is generated as soon as the current key is deployed. The TLSA record is then computed, and pre-published in the DNS (along with the 3 1 1 record for the new live key) as soon as the new key goes live. Later, when it is time to generate a new certificate, the pre-generated key is used, and the process repeats.

    With the second approach (potentially less secure when using a third-party CA) the stable “2 1 1” key that matches the key of an intermediate issuer CA (or root CA, but then the root CA MUST appear in the server’s full chain file, which users tend to neglect to do) ensures that DANE continues to work even as the server’s key is changed and the “3 1 1” record becomes stale. After the rollover, a new “3 1 1” is generated and published, making both records valid again. When the issuer key is about to change, the server must then make sure to use the same key as before to obtain a new certificate from the same issuer, and in that case replace the “2 1 1” record after the rollover.

    Regardless of the approach, MONORING and good scripting of the process (perhaps fully automated) is critical, so that key steps are not forgotten if done by hand.

    So my advice is by all means, please, implement DANE… BUT ONLY if you’re prepared to do it properly. Security is not “deploy and forget”, it needs to be monitored and properly planned. DO NOT deploy DANE as a mere fashion statement:

    1. This makes it perfectly clear again. That security engineers should get out of their bubble and design mechanisms which are easy to implement. I understand how DANE works but for people who don’t deal with this on a daily base, good luck!

      There is no way it will be widely adapted (it’s here since ages now) anytime soon, no wonder why browsers ignore it.

      IMHO the risk for availability is higher then the risk for an integrity failure (MITM).

      Nevertheless Viktor: excellent read!

  4. Great post,

    I wonder about port 25? You put it into the TLSA record.
    Will this mean that this port is opened for plain text messages too? This would be nothing anyone wants.

    1. Hey Martin,

      yes, you’re right that connecting to port 25 should use STARTTLS to encrypt the channel. You can configure this on your mail appliance. For example, on a Cisco ESA you can use “TLS required” for that. This still (!) uses port 25, but ONLY accepts messages with STARTTLS.

      However, you can also use implicit TLS on port 465 to use encryption by default.

      It’s always a bit confusing with those ports. For example, port 587 is *only* used for initial submission from a MUA to the MSA, but NOT between MTAs which is SMTP/message relay. Note that TLSA should be used for message relaying because those MTA parties do not know each other. Hence DANE. ;)
      Refer to:

      Cheers, Johannes

  5. I feel that in DANE the DNS Server is the replacement of certificate authority to be the trust anchor or the source of trust.

Leave a Reply

Your email address will not be published. Required fields are marked *