On 06-06-16 17:46, Viktor Dukhovni wrote: > On Mon, Jun 06, 2016 at 05:31:49PM +0200, Tom Hendrikx wrote: > >> I have been playing around with the dane check tool from sys4 too, and >> it seems it doesn't support the nice CNAME trick shown in >> https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022 > > In the dane.sys4.de test code CNAMEs in TLSA records are supported > and work, provided the target of the CNAME is in a signed zone of > course. MX hosts that are CNAMEs are deliberately not supported > as these violate the RFC requirements for MX records. > > For example: > > _25._tcp.gazonk.org. CNAME _tlsa.gazonk.org. > _tlsa.gazonk.org. TLSA 3 1 1 > 2EE262031C03AD1143E557074DADCE1F681F1818D6B0DC59ED33F472 6B180B6C > > For which https://dane.sys4.de correctly shows (that this domain > is misconfigured by promising and then not offering STARTTLS): > > 42 gazonk.org > 212.247.24.42: STARTTLS not offered > > IP Addresses > 212.247.24.42 > > Usable TLSA Records > 3, 1, 1 2ee262031c03ad11[...]ed33f4726b180b6c >
I did some further research. It seems that validns does not like this construct, because it insists that TLSA records are 'properly prefixed' (i.e. with a port and service prefix, see [1]). My dnssec auto-signing setup invalidated the zone because of this, so it was never published with these records, concluding in the sane tool not being able to see them. My bad... [1] https://github.com/tobez/validns/blob/5a374cf1d629d8d2fecdf6f215aec9b056370868/tlsa.c#L87 Regards, Tom
signature.asc
Description: OpenPGP digital signature
