Support for TLSA / DANE proto



I’m wondering if/when cloudflare will add support for TLSA records so that I can add DANE to my site.

Br. Niklas


Something we’ve considered. Don’t know that we have a roadmap date for it. We did recently release support for CAA records (not the same thing obviously, but in a similar vein).


Thank you for response, Since HPKP is on its way out DANE looks like its replacement (sort off), but it has still very limited support on browsers sadly.


Another vote for adding TLSA records. This is currently the only thing missing for me @cloudflare. This and my registrar’s inability to add a DS for dnssec for one of my domains, but that is something you guys cannot help with :slight_smile:


@jacco_vangent @Niklas @cscharff You can use a CNAME record to use any recoded type that Cloudflare doesn’t support. That’s because CNAME will forward all record type including A, AAAA, TLSA, MX, etc.

For example, the zone is using Cloudflare, the is using another DNS service that supports DNSSEC and TLSA: IN CNAME

For zone (Let’s Encrypt TLSA in this example): IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18

Also, you can use “” instead of to another DNS provider, but it is not recommended because Cloudflare doesn’t support DS record for NS and DNSSEC will not work for

For DNS service that supports TLSA, I recommend Google Cloud DNS since it’s very cheap.


Hey, that would be like taking one step forward and two back, native support is always preferred.


Yeah, that does not sound like an really great idea. First I would have to purchase another domain, just for absence of one record type. And the added administration.


Lack of support for the TLSA RR type is very frustrating since there is no way to fix this beyond what @ze3kr suggests in his response above. This is double bad, since DANE is the only scalable way to increase security of SMTP traffic today, regardless of what the major browser vendors decide to do. And, Cloudflare already has the best offering for cloud-based DNS, having to CNAME away from them to another vendor is nutty.

Could Cloudflare implement RFC3597 as a generic workaround for this? This would allow the use of future RR types without any additional work on Cloudflare’s part. Supporting RFC3597 would be a permanent fix those of us who want to adopt and test the bleeding edge.

@cscharff, is there a way to increase the importance/likelihood of getting either solution implemented? Thanks!


that would be truly awesome.


DNSSEC protects against DNS spoofing. TLS certificates should protect against identity spoofing in TLS connections. In reality this is subverted by hacked CAs or CAs issuing TLS certificates wrongfully. CAA RRs do not solve that problem as CAs (or hacked CAs) can ignore them. If a CAA-authorized CA issues certificates wrongfully CAA-RRs don’t help either.

TLSA ressource records publish a hash value of the currently used TLS certificate in a DNSSEC protected zone. That way a client can check if the certificate presented by a TLS server is valid.



To avoid bloating DNS zones I suggest to use CNAMES with SNI certificates, e.g.

_443._tcp.CommonName. 3600 IN TLSA 1 1 1 23ECDA1BAFF3350ADE5752800A79DAC0D91A121FCE40ED0D997B123D

_443._tcp.AlternateSubjectA. 3600 IN CNAME _443._tcp.CommonName.
_443._tcp.AlternateSubjectB. 3600 IN CNAME _443._tcp.CommonName.
_443._tcp.AlternateSubjectN. 3600 IN CNAME _443._tcp.CommonName.


I disagree with this issue being marked as solved! :disappointed:


Wassnet me who marked it


I check the dns record that can be created and they have just added TLSA record


Yup, I just tested it works fine :slight_smile:

Thank you @Cloudflare :smile: for implementing this feature along with other record types.


Great news! However, for resources going through the CDN, there should be TLSA record generated automatically as the certificate is not under my control.


Hint @ryan :wink:


I agree since CF manages certificates they should also mange DANE/TLSA for said records,