This post contains a recollection of my last 4 years using DANE to secure the TLS certificates for all my projects and personal development.

DANE is a cool mechanism that allows site operators that use DNSSEC to publish information that describe the TLS certificate that clients can expect to receive when connecting to active services.

What’s the deal with DANE?

Judicious use of DANE in combination with a DNSSEC-validating resolver is a strong defence against a variety of attacks.

Man-in-the-middle (MITM) attacks

These attacks occur when an attacker intercepts and potentially alters communication between two parties. By using DNSSEC and DANE, the attacker’s ability to present a fraudulent certificate is significantly reduced, as the client verifies the certificate through a secure DNS chain of trust.

Rogue Certificate Authorities (CAs)

Occasionally, CAs might issue fraudulent certificates or get compromised, allowing attackers to present seemingly valid certificates. DANE provides an additional layer of security by enabling domain owners to specify which certificate or CA is authorized for their domain, reducing the impact of rogue CAs.

Domain validation vulnerabilities

Traditional methods of domain validation, like email or HTTP-based validation, can be susceptible to interception or forgery. DNSSEC ensures the integrity and authenticity of DNS data, while DANE specifies the allowed TLS certificates, making domain validation more secure.

Certificate Transparency (CT) log issues

CT logs can be tampered with or experience downtime. Although CT is an important mechanism for detecting fraudulent certificates, it does not prevent their use. DANE complements CT by providing a more direct way to validate certificates through the DNS system.

Certificate revocation issues

Traditional revocation methods like Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) have limitations, such as delays in propagating revocation information or privacy concerns. By using DANE, domain owners can quickly and effectively remove compromised certificates, minimizing the risk of their continued use.

Of course, DANE requires you to deploy DNSSEC for your DNS zones, which could be a burden for some. I have written a bit about how I manage my DNS zones with DNSSEC, in batch. I also have some useful scripts for managing TLSA records on my TLS certificate management skeleton.

DANE in a nutshell

When a TLS client is preparing to establish a connection, it issues a DNS query requesting DNSSEC validation for the TLSA records. The following diagram shows the overall process.

If the client received TLSA records in a secure response, it knows it will be able to validate the server certificate. This validation will be as thrustworthy as the domain name resolution itself thanks to the assurances provided by DNSSEC.

At this point, the TLS client initiates the connection, following these steps:

What all this means is that a DANE-aware TLS client using a DNSSEC validating resolver can immediately identify attempts to impersonate the server—or tamper with the connection—prior to sharing any sensitive information. This is definitely a step in the right direction for privacy and security.

For DANE-unaware TLS clients, or clients that use a non-validating DNS resolver, no additional guarantees are provided.

This is how I roll… my records

I typically have cron-based automation that makes sure the required TLSA records are always present on my zones. To this end, I invoke scripts like this on a daily basis:

#!/bin/bash
#
# add-tlsa.sh -- Run periodically to ensure TLSA
# records are in place

TTL=2592000 \
PUBKEYS=/etc/letsencrypt/seed/lem.click/cert-*.pub \
tlsa-auto-deploy.sh lem.click

This script ensures that lem.click has suitable TLSA wildcard records covering any protocol I wish to use. You can query those records using the dig command. The example below also includes the DNSSEC RRSIG record, a signature that ensures that the TLSA records themselves have not been tampered with.

dig +dnssec +noall +answer tlsa *._tcp.lem.click
*._tcp.lem.click.	604779	IN	TLSA	3 1 2 C2131AAFEA2B2A33CA42BAD268EEB5742AA694911139AA7740AA9742 8734FD3D5B5CF6E9BEFE369BC9DE110DA74DB49FBED15B28914BABB0 5707C6D94129636D
*._tcp.lem.click.	604779	IN	TLSA	3 1 2 62AD53D66CA743ED4CEEB490F2CE478C844C683144FA8D853614C9E8 4B3F03EAC6ACA7AD18A57F196D695E57E0139CB770B8D87620FD57B3 FEF36D08F46A7075
*._tcp.lem.click.	604779	IN	TLSA	3 1 2 81A9CFABEBC878A48A516E8BF6EE001681DDDCAD3988322AB1F4F903 FB8FC7712E9896B4739C72CE5BA35640B80A9DE5C565769AE0810558 A4CE29AA66081B95
*._tcp.lem.click.	604779	IN	TLSA	3 1 2 9578E9D0CACBE3D86160175FCA6A77A58FB3B8011358C1CA1076FE61 3BFC2B0C5D08C6931828C0F47B7DA453DF507F106703008B1FE51D18 21C8BE249242119C
*._tcp.lem.click.	604779	IN	RRSIG	TLSA 13 3 2592000 20230410205923 20230311205122 51465 lem.click. 0jEXigKUmEoLWMtzd+/ugo12UMou7Y5XKuT/EbfZwy6zxflPeAe2+mAZ PSBQVUzom8MtyOYoSLBamUPBidgBhA==

A DNSSEC validating DNS resolver—1.1.1.1 and 8.8.8.8 are examples of public DNSSEC validating resolvers-would handle the verification of the RRSIG signature and refuse to pass you an answer that does not validate. You should consider running your own DNSSEC validating resolver if you can. There are many privacy advantages to running your own resolver, which I won’t go into details here.

Note that my TLSA records start with 3 1 2. Those parameters inform clients on how to interpret the signature on the payload. However, this is a brief summary of what this all means:

Certificate Usage Field (3)

In this case, we instruct the client that the Certificate Association Data—the signature towards the end of the TLSA record—applies to the endpoint certificate provided by the TLS server that will terminate the TLS connection. In other words, the certificate issued to your webserver.

Selector Field (1)

Indicates that the Certificate Association Data refers to the public key of the TLS certificate. This ensures that no matter how many times the CSR is signed by the CA—Let’s Encrypt most likely—my TLSA records will continue to be valid.

Matching Type Field (2)

Specifies the hashing algorithm used to compose the Certificate Association Data. I chose SHA-512 because in this case, bigger is better. If you manage sites with lots of traffic, you should consider going with SHA-256.

A tradeoff of this technique is that changes to your keypair—say, as part of a certificate key rotation—become harder because the TTL of the TLSA records must be taken into consideration. I address this issue by pre-generating additional keys and storing their key pairs offline. This allows me to perform multiple key rotations right away, using a fresh key. I discuss this topic in a bit more detail on Certificate Rotation with Let’s Encrypt