On Fri, Apr 12, 2013 at 12:15:08PM +0200, Jakob Schlyter wrote: > > In https://tools.ietf.org/html/draft-ietf-dane-srv-02#section-3.2 we have: > > > > The client SHALL construct the TLSA query name as described in > > [RFC6698] section 3, based on fields from the SRV record: port from > > the SRV RDATA, protocol from the SRV query name, and the TLSA base > > domain is the SRV target host name. > > > > thus in case a target hostname in the SRV RR is a CNAME: > > According to RFC 2782, the SRV target hostname MUST NOT be an alias (aka > CNAME).
Thanks, appreciated. I am aware of this for MX records, so I am not surprised by similar treatment of SRV records. Standards notwithstanding, sometimes it will be a CNAME in practice. Are you saying that because CNAME-valued SRVs violate 2782, it would be wrong for draft-ietf-dane-srv to define any particular treatment for these? If so, perhaps I'm free to do CNAME chasing or anything at all, since this case lies outside the scope of the standards. Given a choice of failing, doing something painful like SNI, or chasing the CNAME, Postfix will chase the CNAME. I should note that with SMTP, a non-MX destination (A or AAAA only) is per 5321 equivalent to an implicit MX, but its base is perhaps the target of the CNAME (second paragraph of): https://tools.ietf.org/html/rfc5321#section-5.1 The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found, the resulting name is processed as -------------------------------------------------------------- if it were the initial name. If a non-existent domain error is ---------------------------- returned, this situation MUST be reported as an error. If a temporary error is returned, the message MUST be queued and retried later (see Section 4.5.4.1). If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. If MX records are present, but none of them are usable, or the implicit MX is unusable, this situation MUST be reported as an error. My reading of this is that: example.com. IN CNAME example.net. example.net. IN MX (NODATA) example.net. IN A 192.0.2.1 is implicitly (initial name now example.net): example.net. IN MX 0 example.net. and that the relevant TLSA records for this case would be: _25._tcp.example.net. IN TLSA 3 1 1 ... -- Viktor. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
