--On Wednesday, July 27, 2016 18:14 +0000 Viktor Dukhovni <[email protected]> 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 [email protected] is valid. The >> intent, which I hope is clear, is that the RCPT command >> transmitted to smtp1.example.com have <[email protected]> >> as its [primary] parameter and not anything involving "bar". >> That is important because it is SMTP-valid to treat the >> putative mailbox [email protected] as different from >> [email protected]. If there were an additional DNS record >> fuzz.example.net. CNAME bar.example.net. >> mail to [email protected] 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
