On 06-06-16 20:26, Tom Hendrikx wrote: > 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]).
Insists, as a policy check, which I have enabled (but is off by default)... > > 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
