On Mon, Sep 07, 2015 at 05:19:51PM -0400, Simson Garfinkel wrote:
The problem appears to with getdns... it's returning that CNAME lookups are bogus when in fact they are not.
Pity. In most cases however, you don't need to chase CNAMEs explicitly. Most validating resolvers (as shown by the example you included with the bug report) will automatically chase the CNAME for you.
So when you ask for the TLSA records of _25._tcp.mta.openssl.org, you get a validated response with both the CNAME and the final answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30434 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;_25._tcp.mta.openssl.org. IN TLSA _25._tcp.mta.openssl.org. CNAME wildcard._dane.openssl.org. _25._tcp.mta.openssl.org. RRSIG CNAME 8 5 <...> wildcard._dane.openssl.org. TLSA 3 1 1 687C07FBE2491E7035D0567FA42A503E1F163312B310B47B7B64B911C93ECACA wildcard._dane.openssl.org. RRSIG TLSA 8 4 <...>
So unless the resolver leaves you with a "dangling" CNAME (no answer for the RHS of the CNAME), you generally don't need to explicitly resolve CNAME RRs.
So if you parse the getdns replies for TLSA looks with more care, you don't have to wait for the bug fix. You can "chase" the CNAME expansion within the provided initial reply without additional queries.