You've seen something about DANE and it sounds exciting. A new world of complicated technology with which to impress friends at a party. But what on earth do those numbers mean?

RFCs aren't really introduction documents, so here's some explanations that will hopefully clarify some TLSA record basics.

Numbers? What Numbers?

So you might see something published like the TLSA records below:

1dig tlsa _443._tcp.kalfeher.com +short
22 1 1 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DC FBCF286D
33 1 1 9149091D7C5BB820468C8D5A5EACD1957C3E608A7B776A9A7127B7F0 AE0CB67F

The two TLSA records above both start with a group of 3 numbers before we get the record content. Just like MX or SRV records these values represent information the client uses to determine how to treat the data which follows.

The first number. Use Case Field.

In the responses above, the two records start with a '3' and a '2'. With DANE TLSA records, that first number describes the 'use case'. This tells the world that the record which follows represents a certain type of certificate. Here's a quick explanation of the 4 possible use cases:

0. (PKIX-TA) A Certificate Authority certificate. To clients, this record says "trust any certificate received from my host that has been signed by this record". This could be a root or an intermediate (also called 'issuer') certificate. Importantly, it must be an authority that the client already trusts.

1. (PKIX-EE) A Server certificate. This is a normal certificate as most people understand it. As with use case 0, the client must trust the authority that issued this certificate. There is no restriction on which particular CA issued the target certificate, only that it be from amongst those the client already trusts.

2. (DANE-TA) A Certificate Authority certificate. To clients, this record says "trust any certificate received from my host that has been signed by this record". This could be a root or an intermediate (also called 'issuer') certificate. Unlike use case 0 the client is not required to already trust this CA. This could even be the issuing certificate of a CA which is internal to your organisation.

3. (DANE-EE) A Server certificate. This is a normal certificate, just like use case 1, but without the constraint that the client already trust the CA which issued the target certificate. This is the most common TLSA use case you'll see. As with use case 2, this could be a self-signed certificate.

End Entities and Trust Anchors

DANE uses the terms End Entities and Trust Anchors. Put very simply, End Entities are the servers we deploy certificates on and Trust Anchors are the Certificate Authorities, either their root certificates or their issuing certificates. Since Certificate Authorities like to keep their root certificates offline and safe, they typically issue the certificates they give you and I, with an intermediate certificate. For TLSA use cases 0 and 2, either the root certificate or the issuing certificate can be used. In reality you are most likely to use your certificate authority's issuing certificate, since that is what your CA will bundle with your certificate.

• Let's Encrypt's X1 Root certificate is a trust anchor.
• Let's Encrypt's X3 Intermediate certificate is also a trust anchor and probably the certificate which signed your server certificate, if you use them.
• The certificate for this website is an end entity. Try the command below. Pay attention to the 'Issuer', it should be "Let's Encrypt"!

1openssl s_client -connect kalfeher.com:443 | openssl x509 -text

They sound the same to me

Use case 0 sounds a lot like use case 2 and use case 1 sounds like use case 3. The difference is that a client which sees records of use case 0 or 1 must already trust the Issuing CA. Whereas use cases 2 and 3 place no requirement on prior trust. Only the DNS record and the supplied certificate are used to decide trust.

I use $BigName CA so use-case 0 or 1 is a good idea, right?

Forcing pre-existing trust on a client seems like a good idea right up until you realise that you don't control the Internet. Since you can't know who trusts which CAs, forcing all clients of your services to trust your CA or fail, will create interoperability issues.

It is for this reason and the lack of opportunity to check a server's certificate prior to the commencement of secure transmissions, that neither use case 0 nor 1 are supported for TLSA for mail server to mail server secure SMTP. Since that is pretty much the most common use of TLSA records right now, you really should avoid using 0xx or 1xx TLSA records.

The second number. Selector Field.

TLSA records can either use the full certificate or just a portion of it called 'Subject Public Key Info' or SPKI. This field tells the client which of those two options the TLSA record refers to.

0. (Cert) The full certificate is used to generate the TLSA record
1. (SPKI) The SPKI is used to generate the TLSA record.

Using the SPKI is generally easier on you and easier on the client. It results in smaller DNS records and SPKI is easy to extract from a certificate. I recommend using the SPKI.

The third number. Matching Field.

This field tells the client how the component listed in the selector field is represented.

0. (Full) Exact match of the component. That is, a full certificate if the selector field (second number) is '0' or the full SPKI string if the selector is 1. Using this can result in very large DNS responses.
1. (SHA-256) SHA 256 hash of the content.
2. (SHA-512) SHA 512 hash of the content.

Putting it all together

Let's look at the records I showed earlier:

1dig tlsa _443._tcp.kalfeher.com +short
22 1 1 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DC FBCF286D
33 1 1 9149091D7C5BB820468C8D5A5EACD1957C3E608A7B776A9A7127B7F0 AE0CB67F

Above, we have a server or End Entity certificate(3), using the SPKI(1) of the certificate, hashed using SHA-256 (1). The second record refers to my CA's issuing certificate or Trust Anchor (Let's Encrypt), which is also using the SPKI, hashed with SHA-256.

Can I have just 1 TLSA record? Or maybe 3 records?

We now know what End Entity and Trust Anchor records represent. But do you need both?
You only need 1 TLSA record to match the certificate on your server.

• If you have your CA's issuing or root certificate as a 2xx record, that's a match
• If you have your server certificate as a 3xx record, that's also a match

So why have both?

It's a good idea to have at least your current server certificate as a 3xx record and your CA's trust anchor as a 2xx record so that when either needs updating, the other record is still valid.
But why??!! After all, it only takes a few moments to update a certificate. If you want the ugly details of coordinating DNS timing and certificates, checkout my Practical TLSA. There's also links in that post to other even more thorough TLSA timing discussions.
The truth is that you will have a much simpler operational experience if you have at least your current CA's root/issuing certificate as a 2xx record and your current server certificate as a 3xx record. You may even have an upcoming certificate as an additional 3xx record as part of rolling over from one certificate to your next. You can of course have even more records, but I'm keeping things simple in this article.

In summary

That's the quick version of TLSA records. Remember that they are representations of certificates you have on your servers. You're telling clients, via DNS, what certificates to expect and what types of validation they need to carry out on those certificates.