Validating an SMTP server
ietf-dane at dukhovni.org
Mon Sep 7 23:36:41 CEST 2015
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
;; ->>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
More information about the dane-users