--On Wednesday, July 27, 2016 18:14 +0000 Viktor Dukhovni
<exim-users@???> wrote:
> On Wed, Jul 27, 2016 at 01:53:48PM -0400, John C Klensin wrote:
>
>> Please be careful when you interpret 2821 or 5321 as
>> prohibiting / deprecating some action.
>
> Of course, but this forum is perhaps not one where we need to
> be quite as careful as we might need to be in an RFC or IETF WG
> discussion. In the end it seems that at least for a length 1
> CNAME chain, we are in violent agreement:
>
>> Now, the text you quote from 2821 (and the slight more
>> detailed but essentially equivalent text in Section 2.3.5 of
>> RFC 5321) fairly explicitly say that
>>
>> foo.example.net. CNAME bar.example.net.
>> bar.example.net. MX 0 smtp1.example.com.
>>
>> and hence an address of user@??? is valid. The
>> intent, which I hope is clear, is that the RCPT command
>> transmitted to smtp1.example.com have <user@???>
>> as its [primary] parameter and not anything involving "bar".
>> That is important because it is SMTP-valid to treat the
>> putative mailbox user@??? as different from
>> user@???. If there were an additional DNS record
>> fuzz.example.net. CNAME bar.example.net.
>> mail to user@??? could legitimately be given yet
>> different treatment.
>
> This confirms what I understand to be the essential thrust of
> the relevant changes in 2821 and 5321. Specifically, it is
> now unwise to rewrite the domains in SMTP email addresses when
> CNAME indirection is encountered.
Or when MXs appear. E.g., if one had
foo.example.com. MX 0 smtp1.example.com.
bar.example.com. MX 0 smtp1.example.com.
it would be a really bad idea (and a violation of the spec) to
rewrite either foo or bar to smtp1 (and worse to rewrite either
to the other). Basically length 1 CNAME chains are no different.
>> However, when the name chain is rather more like
>>
>> foo.example.net. CNAME bong.example.net.
>> bong.example.net. CNAME bar.example.net.
>> bar.example.net. MX 0 smtp1.example.com.
>
> Indeed that rather risks interoperability issues.
And that, I thought, was the case we were being asked about.
What I was trying to clarify was the difference between "don't
configure things that way because it is a bad idea" as compared
to "don't do it because it is strictly prohibited". The bottom
line is "don't do it" either way.
>> Combine that with the unfortunate relationship between CNAME
>> records and DNSSEC, and the best practice advice is to avoid
>> them if possible.
>
> Can you elaborate on this "unfortunate relationship"? CNAME
> RRs get RRSIGs mostly just like any other RRset, except for the
> indirection when the CNAME is dynamically inferred from a
> signed DNAME. When a validating iterative resolver returns an
> answer that involves one or more CNAME expansions, the AD bit
> in the reply is only set when *all* the answers (CNAMEs and
> actual answer RRsets) are validated.
> I am not aware of what makes the situation an unfortunate one.
> An off-list response is fine, if you think this takes us too
> far off-topic for this forum. However, better understanding
> of DNSSEC is probably of some value to email administrators.
I'm going to respond on-list given your last sentence, but we
should probably stop the discussion here.
The above is not the issue. Take a step further back. Keep in
mind that a CNAME can point anywhere in the tree and that, in
the general case (the SMTP requirement that the
originally-specified domain appear in RCPT and that only final
names (no aliases) can appear in some other places is an
exception, applications may not find out the original name and
the DNS provides no "came from" function. In that kind of
situation, _especially_ in that kind of situation, one would
really like an integrity check on DNS replies to validate the
aliases including the technical and policy legitimacy of the
pointer relationship, not just that the label, RRTYPE, data,
etc., are what existed in the relevant authoritative server (and
that it _is_ the authoritative server). DNSSEC wasn't designed
to do that and doesn't. Whether it even could do that without
radical changes to the DNS design is, at best, questionable.
But the result is that, if a CNAME points out of zone, or
especially out of tree, DNSSEC doesn't provide nearly as much of
an integrity check on the relationships as many people have
inferred from the press releases.
best,
john
