On Fri, Apr 12, 2013 at 05:11:53PM +0100, Tony Finch wrote:
> Viktor Dukhovni <[email protected]> wrote:
> >
> > 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.
>
> That would be wrong. The specification is quite clear that the query name
> for the TLSA record is constructed from the target name in the SRV or MX
> record. Whether the target is an alias or not is immaterial.
It may be contrary to the current draft specification, but I am quite
sure that it is not "wrong", my contention is that either the
specification is wrong (if it is to be understood to say anything at
all about the illegal use of CNAMEs in SRV records) or it is simply
not pertinent since CNAMEs are illegal.
If you feel that the specification needs to addresses the CNAME
case, please make it handle key management in a sensible way (i.e.
by obviating the need for SNI, rather than further enshrining the
SNI work-around in new standards).
> > 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.
>
> Oh blimey. Thanks for pointing that out.
>
> In this situation I think the right thing would be to look for the TLSA in
> the same place as when connecting to a host, as in RFC 6698 section 3.
> That is, just add _25._tcp to the start of the domain.
>
> The reason I think this is right is that in the absence of MX records you
> should get the same behaviour when you specify (per Sendmail and Postfix
> notation) a relay host as "[hostname]" (i.e. without MX lookups) or as
> "hostname" (i.e. with MX lookups).
I read 6698 section 3 as a warning about the perils of mixing TLSA
RRs and CNAMEs, not an imperative to use the left-side of a CNAME
as the base domain for TLSA. DANE, properly defined, obviates the
need for SNI (an abominable work-around to support HTTPS virtual
hosting).
Therefore, even with explicit non-MX destinations:
transport:
example.com smtp:[mail.example.com]
Given a DNSSEC-validated chain of CNAMEs from mail.example.com to
some underlying hostname, the base domain used by Postfix for TLSA
will be the target host of the CNAME chain. If the CNAME chain is
NOT DNSSEC validated, Postfix will not look for TLSA RRs.
This behaviour is substantially more robust (is not predicated on
SNI and does not introduce a requirement for cross-organizational
transfer of key material and corresponding synchronization with
DNS changes). Therefore, it is the right behaviour, and standards
that say otherwise need revising.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
