TLSA records on OVH

Software dns, dnssec, security, SSL, TLSA

DANE is a great way of improving security on the web by replacing SSL certificate authorities with DNS records signed by DNSSEC. Basically, the certificate (or its fingerprint) is contained in a TLSA record, with some paremeters that specify how clients should validate it.

It is also extremely simple to generate TLSA records for your domain using online tools such as https://ssl-tools.net/tlsa-generator (which, amusingly, is not TLSA-enabled…)

However, if you’re hosting your DNS zone on OVH (or any other provider with a version of BIND that does not support the TLSA RRtype), it gets a little bit more complicated: adding a TLSA record to your zone will make the web interface complain that this RRtype is unknown.

EDIT: OVH now supports TLSA! See the update below.

However it is still possible to add TLSA records to OVH by using a “generic”, numeric RRtype. The format however is quite different. But it can be easily created using the tlsa tool included in hash-slinger:

$ tlsa --usage 1 --selector 1 --mtype 1 --output generic --certificate /path/to/certificate.pem example.com
_443._tcp.example.com. IN TYPE52 \# 35 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345

(Be sure to read the tlsa doc to understand what usage, selector and mtype are. Arch Linux users: hash-slinger is now available on the AUR.)

This record can then be added to the zone on OVH without any problem. By the way, my blog is now secured by DANE and TLSA, as demonstrated by the DNSSEC/TLSA-Validator Firefox add-on đŸ˜ƒ

TLSA FTW!

UPDATE: OVH now supports records with the TLSA type in its new Manager V6 when editing the zone in text mode. So now it’s possible to use the “RFC” output in tlsa:

$ tlsa --usage 1 --selector 1 --mtype 1 --output rfc --certificate /path/to/certificate.pem example.com
_443._tcp.example.com. IN TLSA 1 1 1 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

Thanks @slashdevsda!

Comments

Join the conversation by sending an email. Your comment will be added here and to the public inbox after moderation.

Jo

I can’t make it work. If I try to add a line to my OVH Bind configuration file (exactly like your _443._tcp.example.com. IN TYPE52 \# 35 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345, except that I stripped .example.com), OVH says success, but then no TLSA record is added.
I noticed that you use standard OVH NS, while I’m using OVH Anycast NS.
Did you just copy the line that tlsa outputs? Thanks

Schnouki

Yep, I just copied the line from tlsa. Using the standard OVH NS, with the old manager, in “expert” mode (i.e. editing the raw zone file without any helper). I’m not sure it can even be done with the new manager…

Jo

I used the old manager in “expert” mode. The messagge “success” appears but then no TLSA (or TYPE52) record appears in my DNS. I even tried with another domain which uses standard OVH NS, but in vain. I checked with dig and if I watch your TLSA, it appears, even if it’s different from what hash-slinger generates.

_443._tcp.schnouki.net TLSA_443._tcp.schnouki.net. 300 IN TLSA 1 1 1 07725B09B288B124093EB6A4FA2B699B98191FC3BDD1A583462E224A 9CCF3D1B

No success with my domains. I saw you use dns12.ovh.net as NS, while mine are dns109.ovh.net and dns200.anycast.me

flohtux

You have to switch into the “expert mode” (checkbox) - the text editor mode is also possible in non-expert mode, but it will silently (“Successfully…”) delete the TYPE52 records. So make sure you enter the expert mode before inserting the TYPE52 records. (TLSA record format still is not supported and will give an error on re-entering the editor)I had the same problem, so I post my answer for anyone finding this thread - like I was via a dominating search engine :)